Braintrust가 평가 플랫폼을 만들기 어려운 이유

URL: https://www.youtube.com/watch?v=S3knIZq7jM8 날짜: 2026-10-12 채널: Tech Bridge 원문 제목: [한영자막] 평가 플랫폼 만들기가 생각보다 어려운 이유 — Braintrust 발표자: Hossein Niazmandi, Braintrust

---

📌 핵심 질문 / AI 에이전트 평가 플랫폼은 왜 스프레드시트 UI를 넘어 시스템 문제가 되는가

==AI 에이전트(AI agent)의 품질을 지속적으로 높이려면 출시 전 평가(Evals)와 출시 후 관측 가능성(Observability)을 하나의 개선 순환(Improvement Loop)으로 연결해야 하며, 그 순간 평가 플랫폼은 단순한 UI가 아니라 대규모 데이터·쿼리·권한·운영 시스템이 된다.==

• 평가(Evals)는 에이전트가 프로덕션(Production)에 도달하기 전에 행동을 실험하고 테스트해 출시 신뢰도를 쌓는 과정이다.
• 관측 가능성(Observability)은 실제 사용자가 에이전트와 상호작용하는 프로덕션에서 모든 실패 모드와 실행 흔적을 계속 관찰하는 과정이다.
• 스프레드시트는 진입 장벽이 거의 없는 훌륭한 출발점이지만, 데이터셋·채점·리뷰·디버깅·협업·장기 분석·프로덕션 연결을 감당하지 못한다.
• 에이전트 트레이스(Agent Trace)는 깊게 중첩된 반구조화 JSON(Semi-structured JSON)이며 한 번의 상호작용이 수백 MB에 이를 수 있어, 실시간 수집과 대용량·장기 쿼리를 동시에 지원하려면 전용 시스템이 필요하다.
• 코딩 에이전트(Coding Agent)가 실패 사례를 찾아 평가를 실행하고 개선안을 반복 제안할 수 있어도, 무엇을 프로덕션에 보낼지는 사람이 결과를 검토하고 결정해야 한다.

Hossein Niazmandi는 Braintrust를 에이전트 품질(Agent Quality)에 초점을 둔 플랫폼으로 제시한다. 팀은 출시 전 오프라인 가설을 만들고, 출시 후 실제 사용 데이터로 그 가설을 검증하며, 실패를 다시 테스트 케이스로 환류해 품질을 계속 끌어올린다. 평가 플랫폼의 난점은 화면을 예쁘게 만드는 데 있지 않고, 여러 직군과 여러 규모의 데이터를 하나의 지속적인 운영 루프에 참여시키는 데 있다.

1. 에이전트 품질을 구성하는 두 기둥

1.1. 평가(Evals)로 출시 전 신뢰도 만들기

에이전트가 프로덕션에 도착하기 전에는 팀이 행동을 실험하고 테스트하면서 예상 결과에 대한 자신감을 쌓는다.

1. 평가의 시점과 목적

   1. 출시 전 검증: Evals는 에이전트를 프로덕션에 배포하기 전에 실행한다.
   2. 행동 실험: 다양한 입력에 에이전트를 실행하고 반응을 테스트해, 실제 출시 전에 원하는 동작을 확인한다.
   3. 신뢰도 형성: 평가 결과는 “이 에이전트가 예상한 결과를 안정적으로 낼 것인가”라는 불확실성을 줄인다.

2. LLM의 비결정성(Non-determinism)이 만드는 평가의 필요성

   1. 높은 변동성: LLM(Large Language Model)은 본질적으로 비결정적이고 결과 변동이 크다.
   2. 능력과 위험의 동전 양면: 같은 유연성이 여러 도메인에서 추론하고 다양한 문제를 풀며 넓은 사용자 요구를 처리하게 해주지만, 동시에 예측하기 어려운 실패를 만든다.
   3. 에이전트의 두뇌: 에이전트는 LLM을 두뇌로 사용하므로, 모델의 변동성이 전체 에이전트 경험으로 전파된다.

1.2. 관측 가능성(Observability)으로 출시 후 가설 검증하기

에이전트가 실제 사용자와 상호작용하는 프로덕션에 들어가면, 오프라인 개발 과정에서 세운 가설을 지속적인 모니터링(Continuous Monitoring)으로 강화해야 한다.

1. 실제 환경에서의 검증

   1. 상호작용 기록: 프로덕션 에이전트는 실제 사용자의 요청과 응답을 생성하며, 각 상호작용은 품질을 판단할 운영 데이터가 된다.
   2. 가설과 현실의 대조: 오프라인 평가로 세운 기대가 실제 사용자 환경에서도 유지되는지 관측한다.
   3. 지속적 강화: 관측 가능성은 한 번의 출시 승인으로 끝나지 않고, 운영 중 데이터를 계속 모니터링한다.

2. Evals와 Observability의 관계

   1. 서로 다른 시점: Evals는 개발(Development)에서 일어나고 Observability는 프로덕션(Production)에서 일어난다.
   2. 같은 문제: 두 활동의 공통 목적은 에이전트 품질을 이해하고 개선하는 것이다.
   3. 연결 없이는 품질 루프가 끊김: 출시 전 큐레이션된 테스트만으로는 라이브 환경에서 에이전트가 실제로 어떤 단계를 거치며 언제 실패하는지 알 수 없다.

2. 평가가 없을 때 생기는 사업 위험

2.1. 에이전트 경험이 기업과 사용자의 기본 접점이 되는 변화

에이전트 기반 경험(Agentic Experience)은 기업과 사용자가 상호작용하는 주된 방식으로 자리 잡고 있다. 따라서 팀은 에이전트가 신뢰성 있게 행동하고 기대한 결과를 내리라는 확신을 가져야 한다.

1. 브랜드(Brand) 위험

   1. 일관성 붕괴: 사용자마다 에이전트가 일관되지 않게 행동하면 브랜드 경험 자체가 손상된다.
   2. 기대와 결과의 불일치: 팀이 약속한 경험과 에이전트의 실제 응답이 달라지면 고객 신뢰가 흔들린다.

2. 컴플라이언스(Compliance) 위험

   1. 잘못된 말과 행동: 에이전트가 해서는 안 될 말을 하거나 잘못된 행동을 하면 규정 준수 문제가 발생한다.
   2. 평가의 역할: 출시 전에 불확실성을 줄여, 금지된 행동이나 위험한 응답이 고객에게 도달할 가능성을 낮춘다.

3. 비용·유지보수 위험

   1. 디버깅 난이도: 시스템이 디버그(Debug)하기 어렵거나 신뢰할 수 없으면 문제 하나를 찾는 데 지속적인 엔지니어링 비용이 든다.
   2. 통제 난이도: 에이전트 동작을 제어하기 어렵다면 운영 중 장애와 회귀(Regression)를 예방하기 힘들다.

2.2. 평가의 최소 구성요소

평가 시스템의 가장 단순한 형태도 세 가지 요소를 필요로 한다.

1. 에이전트 실행기(Executor)

   1. 테스트 입력 실행: 에이전트를 정해진 테스트 입력(Test Input)에 대해 실행할 수 있어야 한다.
   2. 반복 가능성: 같은 예제에 에이전트를 반복 실행해 변경에 따른 반응 차이를 관찰해야 한다.

2. 출력·점수 뷰어(Viewer)

   1. 결과 확인: 에이전트가 낸 출력(Output)이나 점수(Score)를 볼 수 있어야 한다.
   2. 초기 구현의 유연성: 결과를 스프레드시트에 기록하더라도 최소한 이 기능은 충족된다.

3. 입력 예제 집합(Examples)

   1. 실행을 시작하는 정보: 입력 예제는 에이전트 실행을 시작하는 데 필요한 모든 정보다.
   2. 형태의 다양성: 프롬프트(Prompt), 사용자 요청(Request), 에이전트를 움직이게 하는 컨텍스트(Context)가 될 수 있다.

3. 스프레드시트에서 평가 플랫폼으로 진화하는 네 단계

3.1. 1단계 — 스프레드시트: 거의 0에 가까운 진입 장벽

스프레드시트 기반 평가(Spreadsheet-based Eval)는 틀린 방식이 아니다. 많은 팀이 이 방식에서 시작하며, 문제를 인식하고 입력별 에이전트 행동을 이해하려는 첫 실험으로 적절하다.

1. 구현 방식

   1. 기본 루프: for 루프에 입력 예제 집합과 에이전트 실행 방법을 넣는 것이 기본 구조다.
   2. 반복 실행: 같은 예제를 수정해 반복 실행하고, 시간에 따른 에이전트 출력 변화를 기록한다.
   3. 청중의 실제 경험: 발표자가 청중에게 평가를 실행하고 결과를 스프레드시트에 기록해 본 사람을 손들어 표시해 달라고 묻자 한두 명이 손을 들었다. 발표자는 이를 부끄러워할 일이 아니며 좋은 첫 단계라고 말했다.

2. 장점과 빠른 한계

   1. 접근성(Accessibility): 시작 장벽이 거의 0에 가깝고, 별도 플랫폼을 만들지 않아도 바로 실행할 수 있다.
   2. 시간 절약: 작은 팀이 즉시 입력·출력·점수 기록을 시작할 수 있다.
   3. 기록에 머무름: 수익(Return)은 빠르게 감소하고, 이 단계에서 하는 일은 거의 문서화(Documenting)에 그친다.
   4. 진짜 실험의 어려움: 반복 비교를 넘어서는 실험이나 시간에 따른 분석을 수행하기 어렵다.

3. 스프레드시트의 구조적 제약

   1. 분석(Analytics)의 수작업화: 데이터를 축적해도 분석이 어렵고 수동 작업이 많다.
   2. 사람의 채점: 인간 채점(Human Scoring)은 가치 있지만 많은 결과를 일관되게 검토하기 어렵다.
   3. 협업(Collaboration) 약화: 여러 사람이 동시에 리뷰하고 논의를 이어가는 기능이 약하다. 발표자는 이 대목에서 짧게 코웃음치는 반응을 보였다.
   4. 도메인 전문가(SME) 배제: 제품 도메인 지식을 가진 전문가가 평가 결과와 과정에서 소외되기 쉽다.
   5. 진화의 어려움: 스프레드시트는 시작점으로는 좋지만, 장기적으로 확장하기 어렵다.

3.2. 2단계 — 맞춤 UI: 보기 좋고 참여자는 늘지만 리포팅에 머무름

문제를 본 프로덕트 엔지니어(Product Engineer)가 평가 전용의 맞춤 UI(Bespoke UI)를 만들면서 다음 단계가 시작된다.

1. 맞춤 UI의 개선

   1. 여러 직군의 진입: 스프레드시트보다 직관적인 화면은 기존에 참여하기 어려웠던 여러 페르소나(Persona)를 평가 루프에 끌어들인다.
   2. PM 참여: 제품 관리자(Product Manager, PM)가 평가를 실행하는 과정에 들어올 수 있다.
   3. 빠른 반복: 화면과 워크플로가 정리되면서 반복 주기가 빨라진다.

2. 여전히 남는 문제

   1. 문서화와 리뷰: 화면이 더 보기 좋아져도 평가 문서화와 검토 프로세스 자체가 자동으로 해결되지는 않는다.
   2. 협업 부족: 여러 사람이 결과를 함께 해석하고 협업하는 일은 여전히 어렵다.
   3. 장기 분석의 부재: 데이터를 지속적으로 저장하고 긴 시간 범위(Long Horizon)에 걸쳐 분석하기가 쉽지 않다.
   4. 리포팅 도구의 한계: 맞춤 UI는 결국 결과를 보여주는 리포팅 도구(Reporting Tool)에 머물 수 있다.

3.3. 3단계 — 공동 실험: 비기술 사용자의 나란히 비교

평가 플랫폼은 비기술 사용자(Non-technical User)가 결과를 단순히 기록하는 데서 벗어나 직접 실험하도록 진화한다.

1. 실험 가능한 인터페이스

   1. 시스템 프롬프트(System Prompt) 변경: 사용자가 시스템 프롬프트를 조정해 에이전트의 지시 조건을 바꾼다.
   2. 기저 모델(Underlying Model) 교체: 모델을 바꿔 결과 차이를 비교한다.
   3. 파라미터(Parameter) 조정: 여러 파라미터 값을 바꿔 출력에 미치는 영향을 확인한다.

2. 사이드 바이 사이드(Side-by-side) 비교

   1. 동시 비교: 서로 다른 설정으로 실행한 결과를 나란히 놓고 비교한다.
   2. 평가 사이클의 진화: 이 기능은 평가를 기록하는 단계를 넘어, 비기술 직군도 개선 실험에 참여하는 다음 단계가 된다.

3. 오프라인 테스트의 근본적 공백

   1. 큐레이션된 테스트 사례: 비교에 사용하는 테스트 케이스(Test Case)는 여전히 오프라인 평가에서 사람이 골라 놓은 제한적인 집합이다.
   2. 프로덕션의 블라인드 상태: 오프라인에서 충분히 반복해도 프로덕션에 배포하는 순간 어떤 단계가 실행되고 언제 실패하는지 알 수 없는 상태가 된다.
   3. 현실과 기대의 거리: “프로덕션에서 무엇이 일어날지 잘 안다”는 감각이 라이브 환경의 실제 실패를 보장하지 않는다.

3.4. 4단계 — 프로덕션 연결: 실패 모드를 다시 평가로 환류

완성도 높은 시스템은 오프라인 평가와 프로덕션 관측을 연결해 개선 플라이휠(Flywheel)을 만든다.

1. 관찰에서 테스트 케이스까지

   1. 실패 모드 관찰: 프로덕션에서 사용자의 좋지 않은 상호작용과 에이전트 실패 모드를 찾아낸다.
   2. 전체 실행 기록: 모든 입력과 출력, 에이전트가 거친 모든 트레이스 실행 단계(Trace Execution)를 기록한다.
   3. 원인 분석: 기록을 분석해 무엇이 잘못됐는지 이해한다.
   4. 성공·실패 차원 정의: 실제 결과를 바탕으로 품질을 판단할 성공과 실패의 차원(Dimensions)을 만든다.

2. 실패를 오프라인 평가로 변환하기

   1. 실패 사례 추출: 사용자가 나쁜 경험을 한 구체적인 시나리오를 골라낸다.
   2. 테스트 케이스화: 추출한 시나리오를 오프라인 평가의 테스트 케이스로 만든다.
   3. 회귀 없는 개선: 새 실패를 만들지 않으면서 에이전트를 반복 개선한다.
   4. 다시 프로덕션으로 배포: 개선된 버전을 배포하고 품질 목표를 향해 계속 언덕을 오르는(Hill Climbing) 식으로 반복한다.

3. 시간에 따른 드리프트(Drift)

   1. 사용자 행동 변화: 고전적 머신러닝(Classical ML)과 마찬가지로 사용자가 에이전트와 상호작용하는 방식은 시간이 지나며 바뀐다.
   2. 에이전트 구축 방식 변화: 팀이 에이전트를 만드는 방법도 계속 변한다.
   3. 영구적 루프의 필요성: 한 번 만든 평가 세트는 영원한 정답이 아니므로, 운영 실패를 다시 평가에 넣는 순환을 유지해야 한다.

4. 플라이휠을 제품으로 만들 때 나타나는 시스템 난제

4.1. POC에서 운영 시스템으로 넘어가는 순간

팀이 개선 플라이휠을 플랫폼 안에 모두 넣으면 개발 주기 전체를 한곳에서 돌릴 수 있지만, 동시에 그 플랫폼 자체를 유지보수하고 소유해야 한다.

1. 작은 규모의 착시

   1. POC(Proof of Concept): 소규모 개념검증 단계에서는 직접 만든 시스템이 쉽게 작동하는 것처럼 보인다.
   2. 데모 환경: 데모(Demo) 환경도 데이터와 부하가 제한적이어서 문제가 늦게 드러난다.
   3. 운영 규모의 전환: 실제 프로덕션 트레이스와 사용자 수가 들어오면 저장·조회·권한·분석 요구가 급격히 커진다.

2. 에이전트 트레이스의 특성

   1. 반구조화 JSON: 트레이스는 정형 테이블이 아니라 구조가 일정하지 않은 반구조화 JSON이다.
   2. 상호작용당 영화 한 편 분량: 어떤 팀은 상호작용 하나마다 영화 한 편을 기록하는 것처럼 방대한 데이터를 남긴다.
   3. 수백 MB 규모: 한 번의 상호작용 로그가 수백 MB에 이를 수 있다.
   4. 조회 난이도: 이 데이터를 빠르게 질의하는 일은 어렵고, 일반적인 클라우드 데이터 웨어하우스(Cloud Data Warehouse)는 이런 볼륨과 부하에서 무너질 수 있다.

4.2. 두 종류의 읽기 부하를 동시에 만족시키기

프로덕션 트레이스가 유입될 때는 실시간성과 장기 분석이라는 서로 다른 워크로드(Workload)를 모두 지원해야 한다.

1. 실시간 쿼리(Real-time Query)

   1. 도착 즉시 조회: 트레이스가 플랫폼에 들어오는 순간 데이터를 질의할 수 있어야 한다.
   2. 사용자 경험 보호: 사용자가 나쁜 경험을 하고 있다면 무엇이 일어났는지 실시간으로 알고, 왜 문제가 생겼는지 파악하며, 가능한 한 빨리 고쳐야 한다.

2. 장기 실행 쿼리(Long-running Query)

   1. 에이전트 경험 미세조정: 긴 시간 범위의 데이터를 살펴보며 에이전트 경험을 파인튜닝(Fine-tuning)해야 한다.
   2. 사람의 정렬(Alignment): 사람이 평가자(Judge)의 결과를 주석 처리(Annotation)해 모델·평가 기준을 정렬하는 작업도 필요하다.
   3. 서로 다른 설계 요구: 실시간 질의와 장기 실행 질의는 같은 데이터를 읽지만 요구하는 성능·저장·실행 방식이 서로 다르다.

3. Braintrust의 BTQL

   1. 추상화 계층(Abstraction Layer): Braintrust는 이 복잡한 트레이스 데이터를 사람이 질의할 수 있도록 BTQL이라는 추상화 계층을 만들었다.
   2. 새로운 복잡성: 사용자에게 질의 인터페이스를 제공하는 BTQL 자체가 또 다른 시스템 복잡성을 만든다.
   3. 핵심 결론: 평가 플랫폼은 단지 UI(User Interface)나 UX(User Experience)의 문제가 아니라 시스템(System) 문제다.

4.3. 기존 관측 가능성과 다른 데이터 모델

ChatGPT 붐 이후 새롭게 등장한 에이전트 데이터는 전통적인 관측 가능성(Observability)과 크기·구조·읽기 패턴이 다르다.

1. 수집(Real-time Ingest)과 페이로드(Payload)

   1. 실시간 수집: 시스템은 데이터가 생성되는 즉시 받아들여야 한다.
   2. 대형 페이로드: 데이터는 수십 MB에서 때로 수백 MB에 이른다.
   3. 기존 관측 데이터와의 차이: 전통적인 heartbeat observability 데이터가 KB 단위인 것과 대조된다.

2. 구조와 텍스트

   1. 깊은 중첩: 데이터는 깊게 중첩된 반구조화 구조다.
   2. 긴 원문 텍스트: full text가 함께 들어가므로 일반적인 정형 질의로 다루기 어렵다.
   3. 검색의 어려움: 구조와 텍스트가 결합된 데이터는 원하는 실패 단계와 문맥을 찾는 일을 복잡하게 만든다.

3. 서로 다른 읽기 패턴

   1. 대규모 집계: 많은 데이터를 한꺼번에 집계할 수 있어야 한다.
   2. 시점 스냅샷(Snapshot): 동시에 특정 시점의 데이터를 그대로 포착하는 읽기도 지원해야 한다.
   3. 한 저장소의 다중 목적: 운영 중 즉시 원인을 찾는 읽기와 장기 추세를 집계하는 읽기를 같은 시스템이 감당해야 한다.

5. 사람과 에이전트가 함께 운영하는 평가 루프

5.1. AI 엔지니어·PM·SME를 모두 참여시키기

알맞은 시스템은 AI 엔지니어(AI Engineer)만 돕는 도구가 아니라 제품 관리자(Product Manager, PM)와 주제별 전문가(Subject Matter Expert, SME)도 평가 루프에 참여시키는 기반이 되어야 한다.

1. 역할의 확장

   1. AI 엔지니어: 트레이스와 모델 동작을 기술적으로 분석한다.
   2. PM: 제품 요구와 사용자 경험을 평가 기준에 반영한다.
   3. SME: 구축 중인 제품의 도메인 전문성을 활용해 결과의 실제 적합성을 판단한다.

2. 평가 플랫폼의 사용자 경계 확장

   1. 단일 팀 도구 탈피: 품질은 코드만의 문제가 아니므로 소프트웨어 엔지니어와 AI 엔지니어만으로 완결되지 않는다.
   2. 지식의 결합: 기술 데이터, 제품 목표, 도메인 판단을 한 루프에서 결합해야 품질 기준이 현실에 가까워진다.

5.2. 코딩 에이전트를 평가 플랫폼의 일급 시민으로 만들기

최근 평가 플랫폼은 에이전트를 일급 시민(First-class Citizen)으로 취급한다. 자연어로 명령하면 코딩 에이전트가 헤드리스(Headless) 환경에서 데이터를 찾고 평가를 실행할 수 있다.

1. 자연어 기반 실행

   1. 실패 트레이스 탐색: 사용자는 코딩 에이전트에게 “지난 24시간 동안 사용자가 나쁜 경험을 한 모든 트레이스를 찾아라”라고 요청할 수 있다.
   2. 평가 자동 실행: 이어서 “나를 위해 평가를 실행하라”라고 명령할 수 있다.
   3. 헤드리스 워크플로: 별도 UI에서 한 단계씩 클릭하지 않고 자연어 명령으로 분석과 실행을 이어간다.

2. 코딩 에이전트가 실행 주체가 되는 이유

   1. 인프라 접근: 코딩 에이전트는 팀의 기반 인프라(Underlying Infrastructure)에 접근할 수 있다.
   2. 코드베이스 접근: 에이전트는 코드베이스(Codebase)도 볼 수 있으므로, 실패 사례를 코드와 연결하고 결과를 기록할 수 있다.
   3. 자동화된 평가 루프: 에이전트가 실패 사례 탐색, 평가 실행, 결과 기록의 메커니즘이 된다.

5.3. 자동화의 목표와 인간의 최종 책임

평가 개선 과정은 엔지니어와 PM이 깊이 관여해야 하므로 때로 노동집약적이다. Braintrust가 말하는 확장성(Scale)의 목표는 이 부담을 줄이고 사람이 더 중요한 판단에 집중하게 하는 것이다.

1. Braintrust의 자동 인사이트

   1. 트레이싱 데이터 기록: Braintrust는 플랫폼에 트레이싱 데이터(Tracing Data)를 기록한다.
   2. 추론(Inference): 축적된 데이터에 추론을 수행해 사람이 미리 정의하지 않은 패턴을 찾는다.
   3. Unknown Unknowns 발견: 팀이 무엇을 물어봐야 하는지도 몰랐던 실패를 표면화한다.

2. 발견 가능한 숨은 실패

   1. 조용한 실패(Silent Failure): 에이전트가 겉으로 큰 오류를 내지 않으면서 조용히 실패하는 시나리오를 찾아낸다.
   2. 반복 프롬프트: 사용자가 같은 요청을 계속 반복해서 입력한다면, 에이전트가 문제를 해결하지 못해 사용자가 좌절하고 있을 가능성이 있다.
   3. 사용자 좌절의 신호화: 반복 요청은 단순한 로그가 아니라 품질 저하와 사용자 경험 악화를 알려주는 신호가 된다.

3. 사람이 가진 마지막 결정권

   1. 코딩 에이전트의 반복 개선: 코딩 에이전트는 여러 평가 반복을 실행하고 애플리케이션을 어떻게 개선할지 제안할 수 있다.
   2. 결과 검토: 인간은 각 반복의 결과를 직접 확인해야 한다.
   3. 프로덕션 버전 선택: 여러 버전 중 무엇을 실제 프로덕션에 배포할지는 사람이 목표에 가장 잘 맞는 결과를 보고 결정한다.
   4. 자동화와 책임의 분리: 실행과 제안은 에이전트에게 위임할 수 있지만, 배포 판단과 결과에 대한 책임은 인간에게 남는다.

6. 평가 플랫폼에 숨어 있는 운영 요구사항

6.1. 보이지 않는 기반 계층

화면에 드러나는 평가 기능만으로 플랫폼이 완성되지는 않는다.

1. 기반 데이터베이스(Database)

   1. 대용량 저장: 깊게 중첩된 트레이스와 full text를 저장해야 한다.
   2. 다중 읽기 대응: 실시간 조회와 장기 집계를 모두 지원해야 한다.

2. 백엔드 제어 계층(Backend Controls)

   1. 통제와 권한(Permissions): 누가 어떤 평가·트레이스·결과에 접근하고 변경할 수 있는지 관리해야 한다.
   2. 운영 안전성: 여러 직군과 코딩 에이전트가 같은 플랫폼을 쓰면 접근 제어가 필수다.

3. 데이터 마스킹(Data Masking)

   1. 민감정보 보호: 실제 사용자 상호작용과 트레이스에는 보호해야 할 정보가 포함될 수 있다.
   2. 분석과 보호의 균형: 데이터 마스킹을 적용하면서도 실패 원인을 분석할 수 있어야 한다.

6.2. “UI와 스프레드시트”라는 축소 모델의 한계

데이터베이스, 권한 제어, 마스킹 같은 기반 기능을 포함하면 평가 플랫폼은 명확히 시스템 문제로 드러난다. 스프레드시트와 UI는 사용자가 보는 표면일 뿐이고, 품질 개선을 실제로 떠받치는 저장·처리·보안 계층이 핵심이다.

주요 발언 모음

“Evals와 Observability는 같은 문제와 밀접하게 연결되어 있습니다. 하나는 프로덕션에서, 다른 하나는 개발에서 일어나며, 둘 다 에이전트 품질을 이해하고 개선하기 위한 것입니다.”

“스프레드시트는 좋은 출발점이지만, 발전시키기는 어렵습니다.”

“에이전트 트레이스는 끔찍할 정도로 다루기 어렵습니다. 반구조화 JSON이고, 어떤 경우에는 상호작용 하나에 영화 한 편 분량의 데이터가 쌓입니다.”

“평가 플랫폼을 만드는 일은 진정한 시스템 문제입니다.”

“지난 24시간 동안 사용자가 나쁜 경험을 한 모든 트레이스를 찾아서 평가를 실행해 줘.”

“코딩 에이전트가 반복적으로 평가를 실행하고 개선을 제안할 수 있지만, 최종적으로 사람은 결과를 검토하고 프로덕션에 보낼 버전을 결정합니다.”

핵심 데이터 & 수치

• 영상 길이: 약 16분 25초(985초)다.
• 평가 최소 구성: 에이전트 실행 방법, 출력·점수 확인 방법, 실행을 시작할 입력 예제 집합이라는 세 가지 요소가 필요하다.
• 트레이스 크기: 한 상호작용이 수백 MB에 이를 수 있고, “영화 한 편 분량”의 데이터가 기록되는 사례가 있다.
• 기존 관측 데이터와의 대비: 전통적인 heartbeat observability가 KB 단위인 반면, 에이전트 페이로드는 수십 MB에서 수백 MB까지 커질 수 있다.
• 자연어 운영 예시: 코딩 에이전트에게 최근 24시간의 나쁜 사용자 경험 트레이스를 찾고 평가를 실행하라고 요청할 수 있다.
• 품질 시간축: 출시 전 오프라인 평가와 출시 후 실시간 관측을 연결하고, 사용자 행동과 에이전트 구축 방식의 드리프트에 맞춰 계속 반복해야 한다.

결론 및 시사점

1. 평가를 스프레드시트로 시작하는 것은 실패가 아니라 문제를 빠르게 인식하고 진입하는 실용적인 방법이다.
2. 그러나 실행·출력 확인·입력 예제라는 최소 기능만으로는 실험, 협업, 장기 분석, 도메인 리뷰를 지원할 수 없다.
3. 맞춤 UI는 PM과 SME를 참여시키지만, 화면 개선만으로 데이터 지속성·권한·리뷰·프로덕션 연결이 해결되지는 않는다.
4. 진짜 평가 플랫폼은 프로덕션 실패를 관측하고 트레이스에서 원인을 분석해, 실패 사례를 오프라인 평가로 되돌리는 플라이휠을 제공해야 한다.
5. 이 플라이휠은 반구조화 JSON·대형 페이로드·실시간 수집·대규모 집계·시점 스냅샷을 함께 처리하는 데이터 시스템을 요구한다.
6. AI 엔지니어, PM, SME가 서로 다른 관점에서 품질을 판단할 수 있어야 하며, 코딩 에이전트는 반복 실행을 자동화할 수 있다.
7. 자동화가 확대되어도 어떤 평가 버전을 프로덕션에 배포할지는 인간이 결과를 검토해 결정해야 한다.
8. Braintrust의 핵심 주장은 평가 플랫폼의 본질이 스프레드시트나 UI가 아니라 사람·데이터·에이전트·운영을 묶는 시스템이라는 데 있다.

핵심 요약 (20줄)

1. Braintrust는 AI 에이전트 품질을 높이기 위해 평가와 관측 가능성을 함께 제공한다.
2. 평가(Evals)는 에이전트가 프로덕션에 도달하기 전에 행동을 시험하고 신뢰도를 쌓는 과정이다.
3. 관측 가능성(Observability)은 실제 사용자가 에이전트와 상호작용하는 운영 환경을 지속적으로 모니터링하는 과정이다.
4. 두 기둥은 개발 단계와 프로덕션 단계에서 같은 품질 개선 문제를 해결한다.
5. LLM의 비결정성과 높은 변동성은 강력한 범용성과 예측하기 어려운 위험을 동시에 만든다.
6. 평가가 없으면 브랜드 일관성, 규정 준수, 디버깅 비용과 시스템 통제력이 모두 위험해진다.
7. 최소한의 평가 시스템은 에이전트 실행기, 출력·점수 뷰어, 테스트 입력 예제 집합으로 구성된다.
8. 스프레드시트는 진입 장벽이 거의 없고 빠르게 시작할 수 있는 좋은 첫 단계다.
9. 스프레드시트는 분석, 인간 채점, 협업, 장기 추적과 도메인 전문가 참여에 약하다.
10. 맞춤 UI는 PM을 평가 루프에 넣지만 여전히 리포팅 도구에 머물 수 있다.
11. 공동 실험 단계는 시스템 프롬프트, 모델, 파라미터를 바꾸고 결과를 나란히 비교하게 한다.
12. 큐레이션된 오프라인 테스트만으로는 프로덕션에서 일어나는 실제 실패와 실행 단계를 알 수 없다.
13. 개선 플라이휠은 프로덕션 실패를 관측하고 테스트 케이스로 만들어 오프라인에서 반복 개선한다.
14. 사용자 행동과 에이전트 구축 방식은 시간이 지나며 변하므로 평가 세트도 계속 진화해야 한다.
15. 에이전트 트레이스는 깊게 중첩된 반구조화 JSON이고 상호작용 하나가 수백 MB에 이를 수 있다.
16. 실시간 트레이스 조회와 장기 분석은 서로 다른 워크로드이므로 전용 데이터 시스템이 필요하다.
17. BTQL은 복잡한 트레이스 데이터를 사람이 질의할 수 있도록 제공하는 추상화 계층이다.
18. 평가 플랫폼은 데이터베이스, 권한 제어, 백엔드 통제, 데이터 마스킹까지 포함하는 시스템 문제다.
19. 코딩 에이전트는 최근 24시간의 실패 트레이스를 찾고 평가를 실행하는 헤드리스 작업자가 될 수 있다.
20. 코딩 에이전트가 개선을 반복해도 인간이 결과를 검토하고 프로덕션 배포 버전을 최종 선택한다.