Why Building an Eval Platform Is Harder Than It Looks — Braintrust

한 줄 핵심

이 영상은 에이전트 품질을 평가하는 eval 플랫폼이 단순한 스프레드시트가 아니라, 오프라인 평가와 프로덕션 관측, 대용량 트레이스 처리, 협업과 자동화까지 아우르는 복합 시스템이라는 점을 보여준다.

시간별 요약

1. 0:00
   소개 Braintrust의 솔루션 엔지니어링을 맡은 발표자가 에이전트 품질 플랫폼이 왜 어려운지 설명할 배경과 경험을 소개한다. 이 세션의 초점은 AI 기능과 에이전트의 품질을 어떻게 안정적으로 관리하느냐에 있다.
2. 0:52
   Braintrust가 하는 일 Braintrust는 팀이 배포하는 AI 기능과 에이전트에 대한 신뢰를 높이는 데 초점을 맞춘 플랫폼이다. 핵심 목적은 품질을 측정하고 유지할 수 있는 기반을 제공하는 것이다.
3. 1:12
   Evals와 관측 가능성 에이전트 품질은 배포 전의 evals와 배포 후의 observability라는 두 축으로 다뤄진다. 전자는 실험과 검증으로 신뢰를 쌓고, 후자는 실제 사용자 상호작용을 지속적으로 감시하며 개선을 이어간다.
4. 2:21
   왜 evals가 중요한가 LLM은 비결정적이고 변동성이 크기 때문에 강력하지만 동시에 위험도 크다. 따라서 에이전트가 일관되게 동작하고 브랜드, 컴플라이언스, 유지보수 리스크를 줄이도록 하기 위해 evals가 필요하다.
5. 3:51
   그냥 스프레드시트 아닌가? 가장 단순한 eval은 실행, 결과 확인, 테스트 입력 관리라는 세 가지 요소로 구성된다. 스프레드시트는 출발점으로는 유효하지만, 그것만으로는 제대로 된 eval 워크플로를 만들기 어렵다.
6. 5:11
   빙산 아래에 있는 것 겉으로 보이는 평가 화면 뒤에는 데이터셋 구축, 점수화, 리뷰 프로세스, 디버깅, 프로덕션 연결 같은 많은 기반 기능이 숨어 있다. 에이전트 품질 관리는 여러 역할이 함께 움직이는 운영 문제이기도 하다.
7. 6:55
   개선 루프 좋은 시스템은 프로덕션에서 실패를 관측하고, 그 실패를 테스트 케이스로 옮겨 오프라인에서 반복 개선하는 개선 루프를 만든다. 시간이 지나며 사용자 행동과 에이전트 자체가 바뀌므로 지속적인 반복이 필수다.
8. 7:35
   1단계: 스프레드시트 처음에는 입력 예시를 돌려 결과를 기록하는 단순한 구조로 시작할 수 있다. 진입 장벽은 낮지만 분석, 협업, 인간 평가, 장기적 추적은 빠르게 한계에 부딪힌다.
9. 9:00
   2단계: 맞춤형 UI 전용 UI를 만들면 PM 같은 비기술 인력도 eval에 참여하기 쉬워진다. 하지만 보기 좋아져도 장기 분석과 데이터 지속성, 협업 문제는 크게 달라지지 않아 결국 보고 도구에 머무르기 쉽다.
10. 9:50
    3단계: 모두를 위한 실험 다음 단계는 비기술 사용자도 system prompt, 모델, 파라미터를 바꿔가며 비교 실험할 수 있게 하는 것이다. 단순 기록을 넘어 실제로 실험하고 차이를 비교하는 기능이 중요해진다.
11. 10:20
    4단계: 프로덕션 연결 오프라인 테스트만으로는 실제 프로덕션에서 무슨 일이 일어나는지 알 수 없다는 공백이 남는다. 따라서 모든 입력, 출력, 실행 단계를 기록하고 실패 패턴을 다시 평가 데이터로 환원하는 구조가 필요하다.
12. 11:49
    에이전트 트레이스는 거대하고 지저분하다 에이전트 트레이스는 반구조화된 JSON이고 때로는 수백 MB에 이르는 대용량 데이터라 다루기 어렵다. 실시간 조회와 장기 쿼리를 모두 지원하려면 일반적인 데이터웨어하우스만으로는 부족하다.
13. 13:19
    BTQL로 조회하기 Braintrust는 트레이스 데이터를 다루기 위한 추상화 계층인 BTQL을 만든다. 이는 단순 UI 문제가 아니라, 실시간 적재·대용량 집계·시점 스냅샷을 모두 처리해야 하는 시스템 문제라는 점을 드러낸다.
14. 14:39
    에이전트가 eval을 실행한다 이제는 coding agent가 자연어 지시를 받아 트레이스를 찾고 eval을 실행하는 주체가 된다. 하지만 여전히 결과를 해석하고 무엇을 배포할지 결정하는 최종 책임은 사람에게 있다.
15. 15:53
    보이지 않던 문제 찾기 플랫폼은 트레이스 데이터를 바탕으로 조용히 실패하는 경우나 사용자가 반복적으로 같은 요청을 하며 불만을 드러내는 패턴 같은 숨은 문제를 찾아낸다. 권한, 마스킹, 제어 등도 포함되어 eval 플랫폼이 단순한 화면이 아님을 보여준다.
16. 16:43
    에이전트는 반복하고, 사람은 결정한다 coding agent가 여러 버전의 개선안을 반복 생성할 수는 있지만, 어떤 버전을 프로덕션에 보낼지는 사람이 최종 판단해야 한다. 자동화는 속도를 높이지만, 배포 결정은 인간의 검토가 중심이 된다.

실무 인사이트

• eval 플랫폼은 단순한 점수표가 아니라, 프로덕션 로그 수집·실패 분석·재현 가능한 테스트 생성까지 연결되는 운영 체계로 설계해야 한다.
• 초기에는 스프레드시트로 시작하더라도, 곧 협업, 장기 분석, 대용량 트레이스 조회를 고려한 데이터 모델과 쿼리 계층이 필요해진다.
• 자동화가 확대될수록 중요한 역할은 더 많이 실행하는 것이 아니라, 좋은 기준으로 결과를 해석하고 배포 결정을 내리는 것이다.