The Evaluation Debt You Don't Know You Have: Why Agent Evals Fail in Production

개요

Agent의 프로덕션 환경에서의 실패는 오프라인 평가로는 탐지하기 어려운 '평가 부채(Evaluation Debt)'에서 발생하며, 특히 멀티 에이전트 시스템에서는 복잡성이 증대되어 더욱 심각해집니다.

주요 내용

* 평가 부채의 근본 원인: 기존의 오프라인 평가 방식은 이미 알고 있는 문제에 대한 데이터셋을 기반으로 하지만, 실제 프로덕션 환경은 끊임없이 변화하므로 이러한 평가는 과거의 상태만을 측정하게 됩니다.
* 구조적 문제: LangSmith, Braintrust, Phoenix 등 모든 평가 프레임워크는 동일하게 홀드아웃(held-out) 테스트셋을 사용하며, 이 테스트셋은 실시간 프로덕션 트래픽의 변화를 따라가지 못합니다.
* 프로덕션 환경에서의 실제 실패: 오프라인 평가는 에이전트가 최종 답변을 정확히 얻었는지, 회귀 테스트를 통과했는지 등을 측정하지만, 무한 루프, 잘못된 도구 호출 후 복구, 시스템 프롬프트 유출, 실패 모드까지의 턴 수 등은 파악하지 못합니다.
* 멀티 에이전트 시스템의 문제 증폭: 여러 에이전트가 상호작용할 때 실행 경로가 기하급수적으로 증가하며, 예측 불가능한 신규 행동이 발생하여 개별 에이전트 평가로는 탐지가 어렵습니다.
* LLM-as-Judge의 한계: LLM-as-judge 방식은 수작업 레이블링을 줄이지만, 위치 편향, 길이 편향, 동의 편향, 높은 오류율, 전문가와의 낮은 일치율 등의 문제점을 가지고 있습니다.
* 실질적인 프로덕션 신호: 실제 프로덕션 실패를 예측하는 신호는 실제 트래픽에서 발생하는 턴별 레이블, 세션 수준의 관찰 가능성(observability), 실시간 트래픽에 대한 온라인 점수 평가에서 나옵니다.
* 멀티 에이전트 평가의 어려움: 여러 런타임(runtime)에서 작동하는 에이전트들의 로그와 평가 데이터를 통합하는 것은 복잡하며, 이를 해결하기 위해 에이전트 세션 데이터를 중앙 집중화하는 인프라 구축이 중요합니다.
* 세션 기반 평가 인프라: 에이전트 세션을 기본 단위로 취급하고, 각 턴별 데이터를 기록하며, 이를 기반으로 평가를 수행하고 피드백 루프를 구축하는 것이 필요합니다.
* 2026년 평가 체크리스트: 평가 플랫폼 선택 시, 턴별 신호 발생 여부, 멀티 에이전트 상호작용 추적 가능성, 프로덕션 트래픽 자동 레이블링, 피드백 루프 폐쇄, 멀티 런타임 지원, 확장성 등을 고려해야 합니다.

시사점

에이전트의 성공적인 프로덕션 적용을 위해서는 오프라인 평가에만 의존하지 않고, 실시간 프로덕션 데이터에 기반한 세션 중심의 평가 인프라를 구축하여 지속적인 개선과 안정성을 확보해야 합니다.