AI 관측 가능성으로 에이전트 품질을 개선하는 실전 워크플로

URL: https://www.youtube.com/watch?v=hfEczxdNyvU 날짜: 2026-10-06 채널: aiDotEngineer

---

📌 핵심 질문 / 이 영상이 다루는 핵심 논점

==에이전트가 운영 환경에서 남기는 방대한 trace를 단순히 저장하는 데서 멈추지 않고, scores와 Topics로 실행 가능한 신호로 바꾼 뒤 다시 eval·코드·배포로 연결하는 자동화된 품질 개선 flywheel을 어떻게 만들 것인가?==

• tracing 없이는 에이전트의 도구 호출, 입력·출력, 중간 판단이 블랙박스로 남아 품질 저하 지점을 찾을 수 없다.
• offline eval과 online scoring은 이미 아는 실패 모드를 측정하고, Topics는 아직 몰랐던 사용자 의도·감정·실패 패턴을 발견한다.
• 발견한 운영 사례를 데이터셋과 새 score로 되돌리고, coding agent가 SQL·trace 분석·eval·코드 변경·PR 작성까지 수행하게 하면 production이 development를 직접 개선한다.

Doug Guthrie는 Braintrust를 Evals와 observability를 한 플랫폼에서 연결하는 도구로 소개한다. 핵심은 로그를 많이 모으는 것이 아니라 대규모 로그 위에 저비용의 분류·평가·검색·자동화를 쌓아 사람과 coding agent가 실제로 수정할 수 있는 신호만 뽑는 데 있다. 워크숍에서는 OpenAI Agents SDK로 만든 간단한 support agent를 대상으로 조직·프로젝트를 만들고, trace를 수집하고, score와 Topics를 실시간 automation으로 실행한 뒤, 발견한 record lookup failure를 데이터셋과 eval에 편입하는 전 과정을 시연한다.

1. AI observability의 출발점: trace를 품질 신호로 바꾸기

에이전트 품질은 최종 답변만 보아서는 진단할 수 없으며, 모든 중간 실행을 보존하고 해석 가능한 신호를 붙여야 한다.

1.1. Tracing이 없으면 품질 문제는 블랙박스가 된다

1. 에이전트의 전체 경로를 기록해야 한다

   1. 최종 출력 이전의 단계: 어떤 도구를 어떤 순서로 호출했는지, 각 도구에 어떤 입력을 넣었고 어떤 출력을 받았는지 기록해야 한다.
   2. 중간 결과의 폭발적 증가: 에이전트가 취할 수 있는 단계와 분기가 늘면 하나의 trace가 빠르게 거대해지므로, 저장 자체보다 그 안에서 패턴을 찾아내는 일이 어려워진다.
   3. 누락의 비용: stack의 어느 부분이라도 trace에 없으면 그 부분은 블랙박스가 된다. Codex나 Cloud Code 같은 coding agent에게 개선을 지시하려 해도 근거가 사라진다.

2. Braintrust는 다양한 stack에 trace를 연결한다

   1. 프레임워크·언어 중립성: 데모는 Python과 OpenAI Agents SDK로 만들지만 TypeScript, Java, Ruby, Go와 여러 agent framework, OpenTelemetry, 직접 만든 orchestration도 연결할 수 있다.
   2. 공급자와 gateway 연결: 여러 AI provider를 설정할 수 있고, 조직이 운영하는 gateway를 custom provider로 붙일 수도 있다.
   3. 여러 고객의 운영 지식: Doug는 Cloudflare와 Dropbox 엔지니어가 어떤 score와 automation을 만드는지 듣고, 그런 실전 학습이 제품과 고객 지원에 반영된다고 설명한다.

1.2. Passive observability에서 active observability로

1. 관측의 두 단계

   1. 수집: trace와 span을 플랫폼에 넣어 무슨 일이 있었는지 확인한다.
   2. 해석: 대규모 데이터에서 품질 저하나 새로운 사용 패턴을 사람이 직접 찾아야 한다면 관측만으로는 부족하다.

2. Active observability의 역할

   1. 신호를 사용자에게 가져오기: 사용자가 모든 로그를 내려받아 의미를 해석하는 대신, score·분류·topic 같은 primitive가 먼저 의미 있는 패턴을 붙인다.
   2. 개선 행동과 연결하기: 단순히 “문제가 있었다”에서 끝나지 않고, 어떤 trace를 dataset에 추가하고 어떤 score를 새로 만들지 결정하게 한다.
   3. 규모에 맞는 지능 계층: Netflix·Microsoft·Dropbox 같은 대규모 고객의 traffic을 사람이 일일이 검토할 수 없으므로, 자동 분류와 coding agent가 human analysis의 앞단을 맡는다.

1.3. Production이 development를 알려주는 flywheel

1. 품질 개선의 기본 순환

   1. 변경: prompt, tool, model, runtime 또는 agent architecture를 수정한다.
   2. 검증: dataset과 eval로 개선인지 regression인지 비교한다.
   3. 배포·관측: production에 배포하고 모든 실행을 trace하며, scale에서 score와 topic으로 신호를 얻는다.
   4. 되먹임: 운영에서 드러난 edge case와 새 기능 요구를 다시 개발·eval 데이터에 편입한다.

2. 사람이 모든 로그를 읽을 수 없는 이유

   1. 규모의 문제: 고객 traffic이 커지면 사람이 trace를 훑는 방식은 비용과 시간이 맞지 않는다.
   2. 지능의 위치: 관측 시스템 위에 분류·요약·검색·코드 실행을 올려야 운영 데이터가 실제 변경으로 이어진다.
   3. 워크숍의 목표: support agent에서 신호를 자동 추출하고, 그 신호로 dataset과 score를 고치고, 다시 eval하는 짧은 순환을 구현한다.

2. Signal 설계: Scores와 Topics를 함께 사용하기

Scores는 이미 정의한 품질 기준을 엄격하게 측정하고, Topics는 테스트에 포함되지 않은 unknown unknowns를 찾아낸다.

2.1. Score의 네 가지 방식

1. Code-based score

   1. 빠르고 저렴한 검증: schema가 맞는지, Tool A가 Tool B보다 먼저 호출됐는지, 도구 순서가 올바른지처럼 결정적인 조건을 코드로 평가한다.
   2. LLM이 필요 없는 영역: 명확한 규칙은 모델 호출 없이 실행해 비용과 지연을 줄인다.

2. LLM judge

   1. 주관적 품질의 수치화: 대화나 출력에 대한 평가 기준을 prompt로 주고, LLM이 사람과 유사한 판단과 score를 내게 한다.
   2. 사용 범위: offline eval뿐 아니라 실제 production interaction에 online score로 적용할 수 있다.

3. Human review와 정렬된 LLM judge

   1. 검토가 필수다: judge가 낸 결과를 의사결정에 사용한다면 그 결과가 좋은지 사람이 확인해야 한다.
   2. 계속 보정한다: agent가 진화하면 score도 진화한다. 특히 online judge는 사용자에게 검토 인터페이스를 제공해 calibration해야 하며, 한 번 켜고 잊는 기능이 아니다.

4. 코드 안에서 LLM을 호출하는 score

   1. 복합 규칙의 구현: branching logic나 여러 조건을 코드로 제어하면서 일부 판단은 LLM에 맡길 수 있다.
   2. 구조화된 제어: 단순 LLM judge보다 애플리케이션의 특정 계산·조건·의존성을 함께 다룰 수 있다.

2.2. 좋은 score를 만드는 운영 원칙

1. 이유(reasoning)를 보존한다

   1. LLM이 왜 특정 점수를 냈는지 알아야 human review에서 판단을 이해할 수 있다.
   2. 그 이유를 보고 score 기준과 prompt를 다시 조정할 수 있다.

2. 초기에는 binary scoring과 어려운 사례를 사용한다

   1. A·B·C·D 등 넓은 등급보다 pass/fail이 초기 production 품질 기준을 명확하게 만든다.
   2. 모든 eval에서 100%가 나오면 테스트 케이스가 약하거나 score가 충분히 엄격하지 않은지 의심해야 한다.
   3. 고난도·경계 사례를 dataset에 넣어 실제 실패를 드러내야 한다.

3. 평가 모델은 생성 모델보다 강하게 선택할 수 있다

   1. judge 모델을 generation 모델보다 강하게 두면 사람의 주관성에 조금 더 가까운 평가를 기대할 수 있다.
   2. prompt에 좋은 예시와 나쁜 예시를 포함하면 기준을 안정시키는 데 도움이 된다.
   3. traffic 종류와 online/offline 용도에 따라 모델·비용·sampling을 조정해야 한다.

2.3. Offline score와 Online score

1. Offline

   1. dataset의 입력을 agent에 통과시키고 변경 전후의 score를 비교한다.
   2. CI나 자동 pipeline에 연결해 production 배포 전 개선·regression 여부를 확인한다.

2. Online

   1. 실제 유입 traffic에 score를 붙여 routing accuracy, support resolution, communication quality 같은 신호를 실시간으로 남긴다.
   2. 거대한 로그를 “routing accuracy가 0인 사례”처럼 좁힌 뒤, 공통 패턴을 찾아 수정한다.
   3. score는 이미 예상한 failure mode를 찾는 장치이며, 그것만으로 agent가 만날 수 있는 모든 상황을 포괄할 수는 없다.

2.4. Topics가 찾는 unknown unknowns

1. 알려진 실패와 알려지지 않은 실패의 차이

   1. factuality·moderation 같은 전통적 score와 bespoke score는 이미 알고 있는 작은 오류 집합을 검증한다.
   2. 실제 사용자는 테스트 시나리오 밖의 입력과 edge case를 계속 던진다.
   3. Topics는 사용자가 실제로 무엇을 하려 했고, 어떤 감정이었으며, 어떤 조용한 실패(silent failure)가 있었는지 패턴으로 묶는다.

2. Built-in facet과 Custom facet

   1. 기본 facet은 task, sentiment, issues다. 사용자 의도, 감정, 광범위한 agent 문제를 미리 정한 taxonomy 없이 찾는다.
   2. custom facet은 조직이 원하는 질문을 직접 prompt로 정의한다. 예를 들어 support workflow에서 어떤 조회 실패가 발생하는지 별도로 찾을 수 있다.
   3. 오류뿐 아니라 feature request나 사용자가 agent에 기대하는 새로운 일도 roadmap의 근거가 된다.

3. Topics pipeline의 내부 구조와 규모 설계

Topics는 trace를 바로 군집화하지 않고, 거대한 실행 기록을 LLM이 처리할 수 있는 표현으로 줄인 뒤 facet·embedding·topic map을 순차적으로 만든다.

3.1. Trace에서 topic map까지

1. Preprocessor

   1. 기본 preprocessor는 thread view에 보이는 user·assistant·tool call의 왕복을 추출한다.
   2. 거대한 trace를 의미 있는 작은 표현으로 축약하며, metadata나 기본 parser가 다루지 않는 span을 넣고 싶으면 custom preprocessor를 가져올 수 있다.

2. Facet과 요약

   1. 전처리된 데이터를 task·sentiment·issues 또는 custom facet prompt에 넣는다.
   2. facet이 trace를 요약하고, 그 요약으로 이후 비교 가능한 표현을 만든다.

3. Embedding과 Topic map

   1. 요약을 vector embedding으로 바꾼다.
   2. embedding으로 topic map을 생성하고 trace에 분류 label과 classifier를 붙인다.
   3. 이 label을 UI나 SQL에서 필터링하면 전체 trace를 읽지 않고 관련 사례만 가져올 수 있다.

4. Hosted model과 scale

   1. preprocessor·facet·embedding을 포함하는 복합 pipeline은 Braintrust가 운영하는 hosted model을 사용한다.
   2. 데모 전용이 아니라 trace의 100%에 실행할 수 있도록 설계했으며, 발표자가 제시한 비용은 입력 100만 token당 6센트, 출력 100만 token당 40센트다.
   3. summarization과 vector embedding은 품질과 pipeline 복잡성 때문에 Braintrust hosted model만 선택할 수 있다. 임의의 모델을 허용했던 초기 실험에서 topic 품질이 좋지 않아 제한을 둔 것이다.

3.2. Topic map을 읽는 법

1. 사용자 의도와 빈도

   1. topic map은 시간 범위 안에서 어떤 패턴이 몇 번 나타났는지 보여준다.
   2. 데모의 다른 프로젝트에서는 “damage and transit resolution”이 가장 빈번한 task로 나타났고, 이는 아직 만들지 않은 agent 기능이나 우선순위를 알려준다.

2. Sentiment와 custom support issue

   1. 한 trace에서는 반품 상품의 refund 상태를 확인하려는 사용자가 나타났고, pending transaction 때문에 frustration과 dissatisfaction을 표현해 negative sentiment로 분류됐다.
   2. custom facet은 specific order ID lookup과 broader customer search 모두에서 order record retrieval failure가 난다는 패턴을 포착했다.
   3. 기본 issues topic이 생성되지 않은 것은 최소 100개의 match/facet을 요구하는 조건과 기본 prompt가 이 agent의 데이터에 맞지 않았기 때문이다. 관련 없는 topic을 억지로 생성하지 않는 것이 오히려 좋은 동작이다.

3. Topic을 행동으로 바꾼다

   1. online score와 topic을 함께 보면 “무엇이 나빴는가”와 “사용자가 어떤 맥락에서 겪었는가”를 결합할 수 있다.
   2. record lookup failure처럼 반복되는 새 edge case는 다음 offline eval 전에 별도 score로 승격할 수 있다.

4. 워크숍 실습: Support agent를 관측 가능하게 만들기

실습은 간단한 chatbot을 만드는 데 목적이 있지 않고, OpenAI Agents SDK 실행을 Braintrust에 연결하고 운영 신호를 품질 개선으로 되돌리는 데 목적이 있다.

4.1. 조직·프로젝트·provider 초기화

1. Braintrust organization과 project

   1. 새 organization을 만들고 자동으로 생기는 my project 대신 AIE-workshop이라는 project를 만든다.
   2. repo의 코드가 이 project 이름을 전제로 하므로, 다른 이름을 쓰면 설정을 함께 수정해야 한다.
   3. 첫 organization 생성자는 AI provider 설정과 API key 생성 화면을 추가로 보게 된다.

2. AI provider와 API key

   1. Settings에서 OpenAI와 Anthropic API key를 등록하고, workload identity federation이나 custom provider로 조직의 gateway도 연결할 수 있다.
   2. online LLM judge는 사용자가 등록한 provider와 model을 사용한다.
   3. Topics pipeline만 Braintrust hosted model을 사용한다. 발표자는 API key를 화면에 노출하지 않도록 공유를 잠시 멈추는 운영 습관도 보여줬다.

3. 로컬 실행 환경

   1. Python 의존성은 uv로 설치하고 uv sync와 dev dependency를 실행해 virtual environment를 만든다.
   2. .env에 Braintrust API key와 기본 model을 넣되, 기본 model은 Braintrust에 등록한 provider와 일치해야 한다.
   3. Braintrust CLI를 설치하면 arbitrary SQL 실행, eval 실행, log 조회, dataset 생성이 가능해진다.

4.2. CLI·Coding agent·Trace 연동

1. CLI 초기화

   1. bt setup skills로 Codex·Claude Code·Open Code·Cursor·Qwen·Gemini 같은 coding agent가 dataset 생성, eval 실행, SQL 작성법을 알도록 skill을 설치한다.
   2. bt init은 organization과 project를 가리키는 config.json을 만들며, 팀 repo에 넣으면 모든 엔지니어가 같은 대상에 접근할 수 있다.
   3. make ready 또는 그 아래의 개별 명령으로 CLI, API key, 기본 model 등 설정이 맞는지 smoke check한다.

2. OpenAI Agents SDK instrumentation

   1. Braintrust SDK에서 BraintrustTracingProcessor를 trace processor로 설정하면 agent가 내보내는 trace와 span이 Braintrust로 간다.
   2. 한 줄짜리 auto-instrumentation도 있지만, 데모는 Braintrust gateway를 함께 사용해 직접 processor를 설정했다.
   3. gateway는 Braintrust에 등록한 여러 provider를 단일 인터페이스로 접근하게 한다.

3. 첫 로그와 eval

   1. chatbot에서 질문을 보내고 Braintrust logs에 새 trace가 나타나는지 확인한다.
   2. repo의 dummy dataset을 CLI로 Braintrust dataset에 올린 뒤 각 row를 agent에 통과시켜 eval telemetry와 결과를 저장한다.
   3. eval에는 required tools called 같은 code-based score와 support resolution, tool use quality 같은 LLM judge score를 함께 넣는다.
   4. 변경 후에는 마지막 experiment와 비교해 개선인지 regression인지 확인한다.

4.3. Online score automation 설정

1. Score를 code와 UI에서 관리한다

   1. repo의 score 정의를 make push scores로 Braintrust에 올릴 수 있고, UI에서 직접 정의할 수도 있다.
   2. code로 관리하면 version control을 유지하면서 online automation과 playground에서 같은 score를 재사용할 수 있다.

2. Automation scope

   1. trace scope는 해당 trace의 모든 span을 평가한다.
   2. multi-turn conversation의 각 turn이 별도 trace라면 group scope와 공통 conversation ID metadata로 묶는다.
   3. 특정 intermediate output만 평가하려면 span scope와 span attribute name 필터를 사용한다. 기본 대상은 root span이다.

3. 비용과 sampling

   1. 새 log가 들어올 때 communication quality, support resolution, tool use quality를 trace 전체에 실행할 수 있다.
   2. 100% sampling은 좋은 신호를 보여주지만 LLM judge 호출에 실제 model compute 비용이 든다.
   3. 새 agent는 높은 sampling으로 시작하고, 알려진 failure가 줄어 maturity가 높아지면 sampling을 낮출 수 있다. classification/taxonomy 목적이라면 100% trace에 저비용으로 실행 가능한 Topics로 대체하는 방법도 있다.

4.4. Topics automation 설정

1. 기본 topic과 custom facet을 켠다

   1. task, sentiment, issues built-in topic을 기존 trace에 적용한다.
   2. repo의 support workflow issue facet Markdown prompt를 custom facet으로 등록한다.
   3. “문제가 없음”에 해당하는 출력은 none으로 내보내게 하고, 그 값을 제외하는 regex를 설정해 유용한 실패만 남긴다.
   4. 기본 thread preprocessor를 쓰되, metadata나 다른 span까지 필요하면 custom preprocessor를 등록한다.

2. 실시간 pipeline의 범위

   1. 어떤 trace에 실행할지 filter로 제한하고, 비용에 맞춰 sampling rate를 정한다.
   2. topic map을 만들 trace의 시간 범위인 topic window를 설정한다.
   3. 장기 대화는 하루나 이틀처럼 window를 늘리고, 여러 trace에 걸친 turn은 conversation ID로 group한다.

3. Trace import와 화면 읽기

   1. S3에 저장한 trace를 BT sync로 Braintrust에 가져올 수 있으며, LangSmith 같은 다른 provider의 trace를 보존하기 위해 import하는 고객 사례도 있다.
   2. 데모에서는 968개 trace와 5,260개 span을 빠르게 로드했다.
   3. thread view는 agent의 user·assistant 왕복을 읽는 데 좋고, timeline view는 병목과 LLM call별 cache hit를 파악하는 데 좋다.
   4. OpenAI Agents SDK가 이전 11개 message를 현재 trace에 함께 붙이는 경우가 있어, 별도 trace를 conversation ID로 묶는 일을 줄여주는 “cheat code”가 된다.

5. 생성된 신호에서 Agent 개선까지

관측의 완성은 dashboard를 보는 것이 아니라, 신호가 가리킨 사례를 수정 가능한 artifact로 변환하고 다음 배포를 검증하는 데 있다.

5.1. UI의 반응형 분석과 Loop의 보완

1. 수동 UI 흐름

   1. topic classifier와 score label로 결과를 필터링한다.
   2. 좁혀진 결과에서 trace와 span을 열고 input·output을 확인해 실패 원인을 찾는다.
   3. task와 sentiment를 조합해 특정 상황의 패턴을 분석한다.

2. 수동 방식의 한계

   1. 사용자가 계속 버튼을 누르고 filter를 조정하며 trace를 읽어야 하므로 reactive하다.
   2. 전체 scale에서는 모든 trace를 coding agent에 넘겨 신호를 찾게 할 수 없고, trace에 먼저 신뢰할 수 있는 score·topic이 붙어 있어야 한다.

3. Loop와 BrainStore SQL

   1. Braintrust 안의 Loop에 “최근 log를 보고 support agent에서 무엇을 개선해야 하는가?”를 묻는다.
   2. Loop는 BrainStore의 trace·span에 직접 SQL query를 여러 번 실행하고, 질문에 관련된 context만 가져온다.
   3. 사람이 SQL을 직접 쓰지 않아도 coding agent가 flexible query를 작성하며, 발견한 trace의 특정 span으로 drill down해 input·output을 읽을 수 있다.
   4. Loop는 trace data 위에 human review UI를 vibe-code해 LLM judge와 agent 출력을 사람이 calibration하는 화면을 만들 수도 있다.

5.2. 운영 사례를 eval dataset으로 되돌린다

1. 대표 edge case를 큐레이션한다

   1. signal로 찾은 대표 trace를 UI에서 기존 dataset 또는 새 dataset에 추가한다.
   2. 사용자가 실제로 시도한 기능, 실패했던 lookup, 새 feature 요구처럼 테스트에 없던 사례를 우선 추가한다.
   3. 중요한 것은 로그에서 아무 사례나 넣는 것이 아니라, 생성된 signal과 실제 개선 행동을 연결하는 사례를 넣는 것이다.

2. Eval과 score를 진화시킨다

   1. dataset·agent function·score의 조합은 현재 운영에 대한 baseline이다.
   2. 새로운 record lookup failure가 반복되면 production 배포 전에 포착할 별도 score를 만든다.
   3. agent가 prompt·tool·model·runtime·architecture를 바꿀 때 eval도 함께 변해야 하며, 과거에 큐레이션한 사례에 대한 regression을 막아야 한다.

3. Agent improvement skill

   1. Braintrust skills repo의 skill을 coding agent에 설치하면 SQL 작성, trace·span 조회, score 생성, dataset 생성, eval 실행을 하나의 workflow로 제공한다.
   2. 실행 중인 Codex는 BT SQL로 968개 support trace를 조회하고, scored failure와 escalate to human tool error의 cluster를 발견한 뒤 representative failed trace를 검사한다.
   3. 새 사례를 dataset에 만들고 eval을 다시 실행하며, 실험 결과를 직접 query해 변경의 효과를 비교한다.

5.3. 자동 PR까지 연결하기

1. 자동 flywheel의 형태

   1. GitHub Action이나 Slack message를 trigger로 삼아 일정 주기 또는 특정 조건에 skill을 실행할 수 있다.
   2. coding agent가 production signal을 SQL로 조사하고, 변경할 prompt·tool·code를 제안하고, eval을 실행한다.
   3. 결과에는 무엇이 바뀌었는지, 왜 바꿨는지, eval impact와 regression, Braintrust inspection link를 담아 사람이 PR reviewer로 최종 판단한다.

2. 실제 운영 가능성

   1. 데모에서는 Claude Code와 Braintrust CLI·skill을 포함한 YAML GitHub Action을 사용한다.
   2. Braintrust가 codebase를 직접 알지 못해도, repo 안의 coding agent에 관측 context를 공급하면 함수와 agent architecture를 수정할 수 있다.
   3. 한 고객은 이 방식을 사용해 기존보다 하루 5~10개의 PR을 더 만들고 있다고 소개됐다.
   4. 현재 플랫폼에 “flywheel 실행” 단일 버튼은 없지만, SQL·score·dataset·eval·skill이 모두 공개된 primitive이므로 GitHub Action이나 Slack으로 조립할 수 있다.

6. 운영·배포·제품 설계에 관한 Q&A

6.1. Braintrust가 강조한 차별점

1. 프레임워크·언어 유연성

   1. 특정 framework에만 묶이지 않고 여러 언어와 agent framework, OpenTelemetry, custom orchestration을 통합한다.
   2. LangSmith도 일부 유연성을 갖지만 LangGraph·LangChain·deep agents 중심 기능이 더 강하다는 비교가 나왔다.

2. BrainStore를 직접 만든 이유

   1. Braintrust는 2024년 말 자체 backend인 BrainStore를 구축했다.
   2. 초기에는 ClickHouse를 썼지만 Netflix·Microsoft·Dropbox 같은 고객을 온보딩하며 agent trace 규모에서 빠르게 한계가 드러났다.
   3. 자체 목적형 database로 sub-second query와 Topics 같은 대규모 signal pipeline을 만들었고, 발표자는 일부 경쟁사보다 약 1년 앞서 이 문제를 해결했다고 주장했다.

3. 의미 있는 signal을 만드는 방향

   1. 비슷해 보이는 trace도 실제 사용자 의도와 agent 복잡성이 달라지면 서로 다른 classifier가 된다.
   2. dummy demo보다 실제 사용자 trace에서 더 많은 차이가 나타나며, 무료 account에서도 일정량의 data와 Topics를 시험할 수 있다.

6.2. SaaS·BYOC·Hybrid 배포

1. 데이터 plane과 control plane

   1. full SaaS는 오늘 워크숍에서 사용하는 방식이다.
   2. hybrid에서는 web app과 metadata를 Braintrust control plane에 두고, trace·dataset·experiment가 있는 data plane은 고객 VPC와 infrastructure에 둔다.
   3. BYOC는 고객 infrastructure에 data plane을 배포하되 Braintrust가 관리하고, 더 강한 hybrid는 고객 팀이 직접 관리한다.

2. 보안과 규모

   1. 주요 cloud provider에 배포할 수 있고 Terraform provider나 cloud별 Helm chart를 제공한다.
   2. 발표자는 앞서 언급한 대형 고객의 약 90%가 self-hosted 형태라고 추정했으며, hybrid deployment는 enterprise plan에서 제공된다고 답했다.
   3. 조직이 trace를 직접 보지 못하게 하고 싶다면 접근이 제한된 project에 원본을 저장하고 service account만 자동 flywheel을 실행하게 할 수 있다. 사람에게는 SQL aggregate와 분석 결과만 전달해도 된다.

6.3. 모델·sampling·score 실행 제어

1. 현재 모델 사용 경향

   1. 고객은 주로 대형 model provider를 사용하지만 자체 fine-tuned model로 이동하는 사례도 생기고 있다.
   2. eval은 model을 교체할 때 품질 regression을 측정하는 안전망이다.

2. Sampling 성숙도

   1. 새 agent는 높은 sampling으로 많은 신호를 확보한다.
   2. 알려진 문제가 줄어들면 score의 정보량도 줄어들므로 sampling을 낮추고, taxonomy 중심 judge는 Topics로 옮길 수 있다.
   3. Dropbox는 복잡한 classification score를 100% trace에 적용하기 어려워 Topics를 실험했으며, 더 저렴하게 큰 비율의 trace에서 신호를 얻는 점을 장점으로 삼았다.

3. 조건부·연쇄 score

   1. UI에 score A의 결과로 score B를 실행하는 직접 기능은 없지만, code-based score의 함수에서 score 객체 배열을 반환하거나 score span의 존재를 filter로 확인하는 방식으로 구현할 수 있다.
   2. code-based score에 필요한 Python·TypeScript dependency를 함께 bundle해 Braintrust에서 실행할 수도 있다.
   3. 기존 span은 mutable하므로 span ID로 metadata·score·metric을 나중에 붙이거나 바꿀 수 있다.

6.4. Remote eval과 비개발자 참여

1. Playground에 eval을 노출한다

   1. remote eval은 task·dataset·agent를 playground에서 실행할 수 있게 한다.
   2. local에서는 eval filename --dev로 dev server를 띄우고 기본적으로 localhost:8300을 사용한다.
   3. 서버에 공개된 eval endpoint로 Braintrust가 POST request를 보내며, Modal의 create app으로 여러 eval을 외부 playground에 노출할 수도 있다.

2. 조직의 flywheel을 넓힌다

   1. product manager나 subject-matter expert가 system prompt, tool description, model 같은 parameter를 직접 바꿔 실행할 수 있다.
   2. AI engineer가 매번 중간 bottleneck이 되지 않아도 비개발자가 저코드 방식으로 개선에 참여한다.
   3. Braintrust는 coding agent skill의 효율과 Cloud Code·Codex session 자체를 평가하는 primitive도 준비 중이라고 밝혔다.

주요 발언 모음

“Production should inform development.”

“Tracing is the foundation.”

“This isn't a set it and forget it type thing. Your agent will evolve, so too will your scores.”

“If you get 100% on every single one of your evals, you probably don't have strong enough test cases.”

“You need that signal attached to your traces in some way, and you need that signal to be real.”

“Your evals should evolve with your agent.”

“The whole idea here is for us to start to generate some signal and start to understand where we can make some improvements within our agent.”

“There isn't a button that you hit that says, ‘Hey, go do the flywheel.’ But you can very easily plug into this using all of the tools that you already have.”

핵심 데이터 & 수치

• 6센트 / 40센트: Topics pipeline의 발표상 비용은 입력 100만 token당 6센트, 출력 100만 token당 40센트다.
• 100%: Topics는 설계 목표상 모든 trace에 실행할 수 있으며, LLM judge보다 대규모 classification에 적합한 비용 구조를 지향한다.
• 100개 match: 기본 issues topic은 최소 100개 match/facet이 생성돼야 topic을 만들며, 데이터와 prompt가 맞지 않으면 억지로 생성하지 않는다.
• 968 traces / 5,260 spans: S3에 있던 support trace를 BT sync로 가져온 데모 수치다.
• 11개 이전 message: OpenAI Agents SDK trace 화면에서 현재 turn에 이전 message 11개가 함께 보이는 사례가 있었다.
• 2024년 말: Braintrust가 ClickHouse의 scale 한계를 보고 BrainStore를 자체 구축하기 시작한 시점이다.
• 약 90%: 발표자가 대형 고객 가운데 self-hosted 형태가 약 90%라고 추정했다.
• 하루 5~10개 PR 증가: 한 고객이 자동 분석·코드 변경 flywheel로 기존보다 하루 5~10개의 PR을 더 생성한다고 소개됐다.
• 8300: remote eval을 local dev server로 노출할 때 자동 탐색하는 localhost port다.
• 1년: BrainStore와 대규모 signal 기능에서 Braintrust가 일부 경쟁사보다 약 1년 앞섰다는 발표자의 주장이다.

결론 및 시사점

1. AI observability의 첫 조건은 멋진 dashboard가 아니라 agent의 모든 도구 호출·입력·출력·중간 단계를 빠짐없이 trace하는 것이다.
2. offline eval은 배포 전 regression을 잡고, online score는 실제 traffic에서 이미 알고 있는 failure mode를 측정한다.
3. Topics는 score가 정의하지 못한 unknown unknowns, 사용자 의도, sentiment, feature request와 silent failure를 발견하는 보완 계층이다.
4. LLM judge는 human review로 계속 calibration해야 하며, binary score와 어려운 사례로 초기 기준을 엄격하게 잡아야 한다.
5. Topics pipeline은 preprocessor → facet → summary → embedding → topic map 순서로 거대한 trace를 실행 가능한 label로 바꾼다.
6. sampling은 새 agent에서 높게 시작하고 성숙도와 signal의 정보량에 따라 낮추며, 대규모 taxonomy는 Topics와 비용을 비교해야 한다.
7. 운영에서 발견한 대표 trace를 dataset에 추가하고, 반복되는 failure를 새 score로 승격해야 eval이 agent의 진화 속도를 따라간다.
8. Braintrust CLI와 SQL 접근성을 coding agent에 주면 사람은 원본 로그 전체가 아니라 분석된 신호와 제안된 PR을 검토할 수 있다.
9. 자동 flywheel은 아직 단일 버튼 제품이 아니지만 GitHub Action·Slack·skills·CLI·eval primitive를 조합해 구축할 수 있다.
10. 최종 reviewer는 사람이어야 한다. agent가 무엇을 바꿨는지, eval 점수가 좋아졌는지, 새로운 regression은 없는지 확인한 뒤 배포해야 한다.

20줄 핵심 요약

1. 에이전트 품질 개선의 출발점은 최종 답변이 아니라 도구 호출과 중간 판단을 포함한 전체 trace다.
2. trace의 일부라도 빠지면 해당 구간은 블랙박스가 되어 실패 원인을 찾거나 coding agent에 수정 근거를 줄 수 없다.
3. Braintrust는 여러 언어와 프레임워크, OpenTelemetry, 직접 만든 orchestration, AI gateway를 연결한다.
4. Active observability는 로그를 저장하는 데서 멈추지 않고 신호를 추출해 다음 개선 행동으로 전달한다.
5. Production 데이터가 development를 알려주는 flywheel은 변경, eval, 배포, 관측, 되먹임의 순환으로 작동한다.
6. Code-based score는 schema와 도구 순서처럼 결정적인 조건을 빠르고 저렴하게 검증한다.
7. LLM judge는 대화 품질처럼 주관적인 기준을 평가하지만 human review를 통한 지속적인 보정이 필요하다.
8. 초기에는 binary score와 어려운 테스트 사례를 사용해야 하며 모든 eval이 만점이면 기준이 약한지 의심해야 한다.
9. Offline score는 CI에서 변경 전후를 비교하고 online score는 실제 사용자 traffic의 알려진 실패를 측정한다.
10. Topics는 기존 score가 놓치는 unknown unknowns와 silent failure, 새로운 사용자 의도를 찾아낸다.
11. 기본 Topics는 task, sentiment, issues를 제공하고 custom facet으로 조직만의 문제 분류 기준을 추가할 수 있다.
12. Topics pipeline은 trace를 전처리하고 facet으로 요약한 뒤 embedding과 topic map으로 분류 label을 만든다.
13. 발표상 Topics 비용은 입력 100만 token당 6센트와 출력 100만 token당 40센트이며 100% trace 실행을 목표로 한다.
14. support agent 실습은 조직과 AIE-workshop project를 만들고 provider, API key, uv 환경, Braintrust CLI를 설정하는 과정으로 시작한다.
15. OpenAI Agents SDK에 Braintrust tracing processor를 연결하면 실행 span이 logs로 유입되고 gateway로 여러 provider를 통합할 수 있다.
16. 968개 trace와 5,260개 span을 불러온 뒤 score automation과 custom support workflow facet을 실시간으로 실행했다.
17. negative sentiment와 order record lookup failure 같은 패턴은 운영 중 발견한 구체적인 개선 신호가 된다.
18. Loop와 BrainStore SQL은 관련 trace만 조회하고 대표 실패 사례를 찾아 dataset과 offline eval로 되돌린다.
19. coding agent skill은 SQL, trace 분석, score 생성, dataset 갱신, eval 실행, 코드 변경과 PR 작성을 하나의 흐름으로 묶는다.
20. 관측의 성공 기준은 dashboard의 양이 아니라 신뢰할 수 있는 신호가 검토 가능한 코드 변경과 더 나은 agent 품질로 이어지는지다.