DarkGarden

Topics

Sections

The maturity phases of running evals — Phil Hetzel, Braintrust

25 min read

AI 에이전트 Eval의 성숙도 단계 — Phil Hetzel (Braintrust)

📺 원본 영상: The maturity phases of running evals — Phil Hetzel, Braintrust 🎙️ 채널: AI Engineer 📅 정리 일자: 2026-05-28 ⚠️ Note: 본 리포트는 영상의 음성을 텍스트로 변환(STT)하여 정리한 것입니다. 화면에 표시된 자료(차트, 코드, 슬라이드 등)는 포함되지 않을 수 있습니다.

개요

이 강연은 AI Engineer 컨퍼런스에서 Braintrust의 솔루션 엔지니어링 책임자 Phil Hetzel이 발표한 18분 분량의 세션으로, AI 에이전트를 개발하는 팀이 Eval(평가)을 수행하는 과정에서 자연스럽게 거치게 되는 4가지 성숙도 단계를 체계적으로 분류하고 설명한다. 단순한 직관적 점검(Vibe Check)에서 시작해 LLM as Judge 자동화, 외부 시스템 연동, 그리고 고급 자동화 기법으로 나아가는 성장 경로를 실전 경험을 바탕으로 소개하며, 각 단계에서 무엇을 해야 하는지, 그리고 왜 그것이 중요한지를 명확히 짚어준다.

강연자와 Braintrust 소개

Phil Hetzel은 Braintrust에서 솔루션 엔지니어링을 이끌고 있으며, 그의 역할은 고객들이 플랫폼에서 최대한 빠르게 가치를 얻을 수 있도록 돕는 것이다. Braintrust에 합류하기 전에는 12년간 컨설팅과 시스템 구현 분야에서 일했는데, 첫 4년은 KPMG에서, 이후 8년은 Slalom Consulting에서 글로벌 Databricks 사업부를 이끌었다. 그가 Braintrust를 알게 된 계기는 흥미롭다. 당시 그는 많은 고객들이 생성형 AI(Generative AI) 개념 검증(PoC, Proof of Concept)을 만드는 데는 능숙하지만 이를 실제 프로덕션으로 전환하는 데는 어려움을 겪는다는 사실을 발견했다. 그 간극을 메우기 위해 직접 Braintrust를 사용자로서 도입했고, 제품이 마음에 들어 결국 회사에 합류해 현재 재직한 지 약 1년이 되었다.

Braintrust는 스스로를 “에이전트 품질(Agent Quality) 회사”라고 정의한다. 이 회사가 에이전트 품질에 기여하는 핵심 방법은 두 가지인데, 바로 Eval(평가)과 옵저버빌리티(Observability)다. Hetzel은 이 두 가지를 시스템적 관점에서 사실상 동일한 문제로 간주한다. Eval이 에이전트를 프로덕션으로 배포하기 전에 신뢰를 확보하는 과정이라면, 옵저버빌리티는 배포 이후에도 지속적으로 그 신뢰를 유지하는 실천이다. 이 두 활동이 하나의 연속적인 품질 관리 사이클을 형성한다는 관점은 Braintrust의 제품 철학을 잘 보여준다.

왜 Eval이 필요한가 — 품질, 리스크, 그리고 공격적 활용

Eval을 수행하는 궁극적인 이유는 에이전트 품질(Agent Quality)의 확보다. 실제 사용자와 실제 사용 패턴 앞에 놓였을 때 에이전트가 우리가 기대하는 대로 동작하는지를 검증하는 것이 목표다. Hetzel은 이것이 단순한 기술적 안정성의 문제를 넘어선다고 강조한다. 에이전트가 고객에게 불친절하거나 쓸모없는 응답을 내놓으면 브랜드 리스크가 되고, 지나치게 많은 토큰이나 비용을 소모하면 시스템 리스크가 되며, 심각한 경우 법적·컴플라이언스 리스크로도 이어질 수 있다. 에이전트의 실수 하나가 단순한 버그 수준을 넘어 비즈니스 전체에 파급될 수 있다는 점에서, Eval은 출시 전 필수 관문이 아닐 수 없다.

그러나 Eval은 단순히 방어적 도구에 머물지 않는다. Hetzel은 Eval을 “공격적으로” 활용할 수도 있다고 말한다. 에이전트에 조금씩 변화를 가할 때마다 그 개선 효과를 Eval을 통해 측정함으로써, 개발 방향을 직관이 아닌 데이터에 기반해 결정할 수 있기 때문이다.

Eval을 처음 도입할 때 흔히 저지르는 실수는 이것을 단위 테스트(Unit Test)처럼 접근하는 것이다. 단위 테스트는 발생 가능한 모든 케이스를 망라하려 하지만, Eval은 그렇게 할 수 없다. 에이전트가 잘못될 수 있는 경우의 수는 사실상 무한하기 때문에, 모든 케이스에 대한 Eval을 작성하다 보면 정작 제품을 배포할 시간이 없어진다. 그래서 Hetzel은 에이전트의 핵심 실패 모드(Failure Mode)에 집중해야 한다고 강조한다. Eval 결과 역시 완벽할 필요가 없다. LLM as Judge처럼 비결정론적(Non-deterministic) 기법은 100%의 정확도를 보장하지 않지만, 올바른 방향으로 개선되고 있다는 추세를 보여주는 것으로 충분하다.

Eval의 세 가지 구성 요소

Eval은 세 가지 기본 요소로 이루어진다. 첫째는 태스크(Task) — 테스트 대상 에이전트 또는 프롬프트다. 둘째는 데이터셋(Dataset) — 그 태스크를 시작하는 데 사용할 예시 입력들의 모음이다. 셋째는 스코어링 함수(Scoring Function) — 태스크의 유용성과 품질을 판단하는 기준이다. 이 세 가지가 조화롭게 설계될 때 비로소 의미 있는 Eval이 가능해지며, 이후 소개할 성숙도 단계들은 결국 이 세 요소를 어떻게 발전시켜 나가느냐의 이야기이기도 하다.

성숙도 단계 1 — 시작하기 (Vibe Checking)

Hetzel은 “바이브 체크(Vibe Check)“라는 표현이 이 컨퍼런스에서 부정적인 뉘앙스로 쓰인다는 사실을 알면서도, 사실 이것이 나쁜 출발점이 아니라고 주장한다. 처음 시작할 때는 어떤 방식으로든 바이브 체크에서 시작할 수밖에 없으며, 그것이 아무것도 하지 않는 것보다는 분명히 낫다는 것이다. 아직 평가 인프라를 구축하지 못한 팀이라도 에이전트를 실행해보고 출력을 살펴보는 행위 자체가 이미 첫 번째 Eval의 시작이다.

이 단계에서 핵심적인 권고사항은 하나다. 바이브 체킹을 하는 동안 반드시 문서화를 병행해야 한다. 에이전트에 10개 정도의 예시 입력을 주고 출력을 살펴보는 과정에서, 에이전트를 만든 개발자 또는 이상적으로는 품질 높은 응답이 어떤 모습인지 아는 도메인 전문가(Subject Matter Expert)를 참여시켜야 한다. 이들에게는 두 가지를 요청해야 한다. 응답이 좋은지 나쁜지에 대한 “엄지 위/아래(Thumbs Up/Down)” 판정, 그리고 더 중요하게는 그 판정의 **이유를 설명하는 정당화(Justification)**다.

이 정당화가 중요한 이유는 나중에 LLM as Judge 같은 기법을 통해 이 도메인 지식을 자동화하기 위해서는 먼저 그 지식을 인간의 머릿속에서 추출해야 하기 때문이다. 초기의 인간 어노테이션(Human Annotation)은 바로 이 지식 추출 과정의 핵심 첫 단계이며, 이 시점에서 충실하게 문서화된 정당화가 많을수록 이후 자동화의 품질도 높아진다.

Braintrust 플랫폼의 인간 어노테이터 뷰 화면

09:16 - Braintrust 플랫폼의 인간 어노테이터 뷰 화면 — 에이전트 트레이스에 Thumbs Up/Down과 정당화 메모를 입력하는 커스텀 어노테이션 UI

또한 Hetzel은 어노테이션 플랫폼을 일반적(Generic)으로 제공하지 말라고 강조한다. 에이전트 트레이스가 어떻게 보여야 하는지에 대한 맥락은 사용자마다 다르기 때문에, 그 맥락에 맞는 구체적인 어노테이션 환경을 제공해야 평가자들이 적절하게 검토하도록 유도할 수 있다. Braintrust는 사용자가 직접 어노테이션 뷰를 커스터마이징할 수 있도록 지원하는데, 이 유연성 자체가 고품질 어노테이션을 이끌어내는 중요한 설계 선택이다.

성숙도 단계 2 — 측정을 통한 관리 (Measuring to Manage)

어노테이션이 어느 정도 쌓이면, 이제 그 데이터를 활용해 확장성 있는 평가 체계를 구축할 차례다. 이 단계는 단순히 “잘 되는 것 같다”는 느낌에서 벗어나, 실제로 무엇이 잘못되고 있는지를 체계적으로 이해하고 그 판단을 자동화하는 것을 목표로 한다.

첫 번째 핵심 전략은 LLM as Judge 기법이다. 인간이 남긴 정당화(Justification)를 Cursor, Claude Code, Codex 같은 AI 코딩 도구를 통해 분석함으로써, 에이전트의 핵심 실패 모드를 체계적으로 도출한다. 일단 실패 모드를 이해하면, 그 판단 기준을 LLM에게 학습시켜 이후 평가를 자동화할 수 있다. 그러나 Hetzel은 중요한 경고도 빠뜨리지 않는다. “LLM에게 판사 가운을 입혔다고 해서 그것이 자동으로 더 신뢰할 수 있는 존재가 되는 것은 아니다.” LLM Judge 자체도 평가의 대상이 되어야 하며, 그것을 맹목적으로 신뢰하는 것은 위험하다.

LLM as Judge 스코어링 함수 설정 예시 화면

12:49 - LLM as Judge 스코어링 함수 설정 예시 화면 — 인간 어노테이션 없이도 대규모 에이전트 출력 평가가 가능하도록 구성하는 방법 시연

두 번째 전략은 결정론적 코드(Deterministic Code)를 활용한 평가다. 모든 실패 모드가 LLM을 통해서만 발견되는 것은 아니다. 예를 들어 에이전트가 지나치게 많은 툴 콜(Tool Call)을 수행하거나 토큰을 과도하게 소모하는 경우는 코드로도 충분히 판단할 수 있다. 두 접근법은 서로 경쟁 관계가 아니라 보완 관계에 있으며, 각 실패 모드의 성격에 따라 적절한 방법을 선택하는 것이 중요하다.

이 단계에서 Hetzel이 가장 강조하는 포인트는 프로덕션 데이터를 Eval 데이터셋에 적극적으로 수집해야 한다는 것이다. “Eval을 테스트를 돌리는 것으로 생각하지 말고, 프로덕션을 재실행하는 것으로 생각하라”는 그의 말은 이 단계의 핵심 철학을 담고 있다. 우리가 궁극적으로 원하는 것은 프로덕션 환경에서의 신뢰이기 때문에, 프로덕션 또는 사용자 인수 테스트(UAT, User Acceptance Testing) 수준의 트레이스를 평가 데이터셋에 끌어들이는 것이 가장 직접적인 접근법이다.

프로덕션/UAT 트레이스를 포함한 Eval 데이터셋 구성 슬라이드

11:40 - 프로덕션/UAT 트레이스를 포함한 Eval 데이터셋 구성 슬라이드 — 슬라이드 우측에 데이터셋 구조가 시각화되어 있음

핵심 개념 — 플라이휠 (Flywheel)

Braintrust 내부에서 “플라이휠(Flywheel)“이라고 부르는 이 개념은 이 단계의 정수를 보여준다. 프로덕션에서 에이전트 트레이스를 수집하고, 인간 또는 자동화 도구를 통해 무엇이 잘못되었는지 파악한 뒤, 그 예시들을 오프라인 실험 환경으로 가져와 Eval을 통해 재실행하고, 그 결과를 바탕으로 에이전트 개선 방향을 결정하는 순환 구조다. 이 플라이휠이 한 번 돌아가기 시작하면 에이전트의 품질은 지속적이고 데이터 기반으로 개선될 수 있다. 반대로 이 순환 구조를 갖추지 못한 팀은 에이전트가 프로덕션에서 어떻게 성능이 변화하는지 사실상 알 수 없게 된다.

성숙도 단계 3 — 복잡성 수용 (Accounting for Complexity)

에이전트가 단순한 모델 호출을 넘어 외부 시스템과 상호작용하기 시작하면, Eval의 난이도는 급격히 높아진다. Hetzel은 툴 콜(Tool Call)을 두 가지로 분류한다. 하나는 컨텍스트 수집 도구 — LLM에 주입할 데이터를 조회해오는 용도이고, 다른 하나는 CRUD 기반 도구(CRUD-based Tools) — 데이터베이스나 외부 시스템에 데이터를 생성(Create), 읽기(Read), 수정(Update), 삭제(Delete)하는 용도다. 이 두 유형 모두 에이전트 품질에 직접적인 영향을 미치며, 그만큼 잘못될 수 있는 지점도 많아진다.

이 단계에서는 단순히 에이전트의 최종 출력만 평가하는 것으로는 부족하다. 에이전트가 목표를 달성하기 위해 거친 전체 트레이스(Trace) 를 평가해야 한다. 어떤 툴을 호출했는지, 각 단계에서 무슨 결정을 내렸는지, 심지어 개별 MCP(Model Context Protocol) 콜 하나하나까지도 추적하고 평가의 대상으로 삼을 수 있어야 한다. 이를 위해서는 방대한 트레이스를 캡처하고 특정 단계를 핀포인트로 분석할 수 있는 플랫폼 차원의 지원이 필수적이다.

또 다른 과제는 오프라인 Eval 환경에서 외부 시스템 상태를 재현하는 문제다. 에이전트가 프로덕션에서 실행된 특정 시점의 데이터베이스 상태나 외부 API 상태를 Eval 환경에서 그대로 재현하는 것은 매우 어렵다. 특히 CRUD 작업은 오프라인 Eval 중에 프로덕션 데이터를 덮어쓸 위험이 있어 직접 수행할 수도 없다. Hetzel은 이 문제가 현재 완전히 해결된 것은 아니라고 솔직하게 인정한다.

그럼에도 불구하고 현실적인 접근법은 존재한다. 에이전트 트레이스는 일반적인 애플리케이션 로그와 달리 임의로 방대해질 수 있다는 특성을 역으로 활용하는 방식이다. 트레이스 내부에 외부 시스템의 당시 상태 정보를 함께 저장해두면, 별도의 테스트 인프라를 구축하지 않더라도 트레이스 안에 당시 컨텍스트를 캡슐화할 수 있다. 또한 타임스탬프 쿼리(Timestamp Query)를 지원하는 시스템, 예컨대 벡터 데이터베이스(Vector Database)의 경우 특정 시점의 버전을 조회하는 방식으로 당시 상태를 근사적으로 재현하는 기법도 점차 활용되고 있다. 이러한 방법들은 아직 성숙 단계에 이르지 못했지만, 빠르게 발전하고 있는 영역이다.

성숙도 단계 4 — 고급 기법 (Advanced Eval Techniques)

강연 시간의 한계로 이 단계는 간략하게만 언급되었지만, Hetzel이 지목한 두 가지 방향은 이 분야의 미래를 보여주는 중요한 신호다.

첫 번째는 프로덕션 환경에서 에이전트 실패 모드를 자동으로 발견하기 위한 토픽 모델링(Topic Modeling) 활용이다. 수많은 트레이스 속에서 패턴을 찾아내어, 개발팀이 미처 인지하지 못한 실패 모드를 선제적으로 파악하는 접근법이다. 두 번째는 AI 코딩 어시스턴트와 Eval 프로바이더의 CLI(Command-Line Interface)를 결합해 Eval 실행 자체를 완전히 자동화하는 패턴이다. 이 두 가지 모두 현재 이 분야에서 빠르게 부상하고 있는 접근법이며, Hetzel은 Braintrust 부스에서 더 자세한 논의를 이어가겠다고 밝혔다.

Q&A — 결정론적 평가 vs LLM as Judge

강연 말미에 청중 중 한 명이 중요한 질문을 던졌다. 많은 실무자들이 결정론적 평가자(Deterministic Grader)에 더 높은 신뢰를 부여하는 경향이 있는데, Eval 플랫폼들도 결정론적 평가를 더 강조해야 하는지, 아니면 LLM as Judge를 수용해야 하는지를 물었다.

Hetzel의 답은 균형 잡혀 있었다. 에이전트가 사랑받는 이유 중 하나가 바로 주관적인 판단을 처리할 수 있다는 점이기 때문에, LLM as Judge를 적극 수용해야 한다는 입장이었다. 단, 조건이 있다. LLM Judge의 출력 자체를 또 다른 Eval의 대상으로 삼아야 한다는 것이다. LLM Judge는 이진 분류나 점수 같은 결정론적 출력을 내놓기 때문에 정답 데이터셋(Ground Truth Dataset)을 구성하는 것이 비교적 용이하다. 즉, “Eval을 Eval하라(Eval the eval)“는 메타적 접근법을 통해 LLM Judge의 신뢰성 자체를 검증할 수 있다는 것이 Hetzel의 핵심 주장이다. 결국 LLM as Judge를 믿되, 맹목적으로 믿지 말고 검증하라는 메시지다.

마무리 / 핵심 정리

Phil Hetzel의 강연은 AI 에이전트 Eval이 단순히 “테스트를 돌리는 것”이 아니라는 사실을 명확하게 보여준다. 처음에는 직관적인 바이브 체크와 인간 어노테이션으로 시작하지만, 에이전트가 복잡해질수록 LLM as Judge를 통한 자동화, 프로덕션 데이터 기반의 플라이휠 구축, 그리고 외부 시스템 상태까지 고려한 복잡한 트레이스 평가로 자연스럽게 발전해야 한다. 이 네 단계는 개발팀이 선택하는 것이 아니라 에이전트의 복잡성이 높아지면서 자연스럽게 직면하게 되는 과제들의 순서다.

무엇보다 중요한 것은 Eval을 “프로덕션 재실행”으로 바라보는 관점의 전환이다. 실제 사용 환경을 최대한 가깝게 재현하는 것이 Eval의 핵심이기 때문에, 프로덕션 데이터를 적극적으로 수집하고 활용하는 플라이휠 구조가 장기적으로 가장 강력한 품질 보증 메커니즘이 된다. 에이전트의 복잡성은 계속 높아질 것이고, 그에 비례해 Eval의 성숙도도 함께 높아져야 한다. 이 강연은 그 여정의 지도를 제시한다.

📚 출처 및 참고

구분내용
원본 영상The maturity phases of running evals — Phil Hetzel, Braintrust
채널AI Engineer
리포트 작성2026-05-28
작성 방식YouTube 영상 STT 변환 후 에디팅

💬 본 리포트는 영상 내용을 바탕으로 재구성되었습니다. 정확한 내용은 원본 영상을 참조해 주세요.

그래프 뷰

Related Reports

백링크