프로덕션 AI 에이전트 평가를 위한 전체 프로세스 (데이터셋, 평가자, 오프라인 + 온라인)

대부분의 팀은 AI 에이전트를 출시하고, 데모에서 작동하는 것을 지켜본 뒤, 프로덕션(Production) 환경에 배포합니다. 그러다 실제 트래픽이 발생하면 에이전트가 고장 나고, 아무도 그 이유를 설명하지 못합니다. "데모에서 작동함"과 "프로덕션에서 작동함" 사이의 간극은 거의 항상 평가의 간극(evaluation gap)입니다. 즉, 실제 사용자가 접속했을 때 에이전트가 실제로 무엇을 하는지 측정할 체계적인 방법이 없었던 것입니다. 이것은 제가 감사(audit)하는 모든 프로덕션 에이전트에 적용하는 전체 평가 프로세스입니다. 이 방식은 특정 벤더에 종속되지 않습니다(vendor-neutral). LangSmith, Braintrust, Langfuse, Arize 또는 자체 제작한 하네스(harness)를 사용하든 상관없이 이 개념들은 동일하게 적용됩니다. 제품을 출시하기 전에 누군가가 당신에게 건네주었기를 바랐던 참조 가이드로 생각하십시오.

멘탈 모델: 두 가지 모드, 하나의 루프
모든 진지한 평가 관행에는 정확히 두 가지 모드가 있으며, 이들은 하나의 연속적인 루프를 형성합니다:

오프라인 평가 (Offline evaluation) — "출시 전 테스트". 개발 중에 큐레이션된 데이터셋(dataset)을 대상으로 평가하여, 버전 간 비교를 수행하고 사용자에게 도달하기 전에 회귀(regression)를 포착할 수 있습니다.

온라인 평가 (Online evaluation) — "프로덕션 모니터링". 실제 트래픽 상의 실제 사용자 상호작용을 실시간으로 평가하여, 사용자가 실제로 보내는 입력값에서 발생하는 문제를 감지합니다.

프로덕션의 실패한 트레이스(trace)가 오프라인 데이터셋으로 다시 흘러 들어갈 때 루프가 완성됩니다. 모니터링을 통해 포착된 실제 실패 사례는 새로운 테스트 케이스(test case)가 되며, 따라서 다음 버전은 당신을 힘들게 했던 바로 그 요소를 대상으로 평가됩니다. 이 피드백 루프는 시간이 지날수록 더 신뢰할 수 있게 되는 에이전트와 성능이 저하되는 에이전트를 가르는 차이점입니다.

┌─────────────── 오프라인 평가 (offline evaluation) ───────────────┐
│ 데이터셋 (datasets) → 평가자 (evaluators) → 실험 (experiments) → 분석 (analysis) │
└───────────────────────┬────────────────────────────┘
│ 통과한 버전을 출시 ▼
┌─────────────── 온라인 평가 (online evaluation) ───────────────┐
│ 프로덕션 실행 (production runs) → 평가자 (evaluators) → 모니터링 (monitoring) │
└───────────────────────┬────────────────────────────┘
│ 실패한 트레이스가 테스트 케이스가 됨 └──────────► 데이터셋으로 복귀

5가지 구성 요소
1.

Datasets — 무엇을 기준으로 테스트하는가: 데이터셋은 테스트 케이스(examples)의 집합이며, 각 케이스는 입력값과 (오프라인 평가의 경우) 참조 출력값(reference output)을 가집니다. 전체 평가 프로세스에서 가장 영향력이 큰 단일 결정은 데이터셋이 어디에서 왔는가 하는 점입니다. 세 가지 출처가 있으나, 그 가치가 동일하지는 않습니다.

• Production traces (가장 좋음) — 실제 입력값: 형식이 잘못되었거나(malformed), 여러 부분으로 구성되었거나(multi-part), 주제에서 벗어난(off-topic) 경우 등, 직접 만들어낼 수 없는 에지 케이스(edge cases)를 포함합니다. 프로덕션 트레이스(Production traces)로 구축된 평가는 프로덕션의 동작을 예측합니다. 그 외의 것으로 구축된 평가는 그렇지 못합니다.
• Manual curation (알려진 리스크에 좋음) — 컴플라이언스(compliance) 시나리오, 적대적 입력(adversarial inputs), "절대로 일어나서는 안 되는" 케이스를 다루는 수동 작성 케이스입니다.
• Synthetic generation (확장용으로 사용하되, 시드용으로 사용하지 말 것) — LLM이 생성한 변형들입니다. 실제 시드 세트(seed set)가 확보된 후에는 유용하지만, 모델이 생각하는 사용자의 행동을 반영하기 때문에 주요 소스로 사용하는 것은 위험합니다.

제가 가장 많이 보는 실수는 이렇습니다: 팀이 사용자가 어떻게 행동할지 상상하며 데이터셋을 구축합니다. 평가는 통과합니다. 하지만 프로덕션은 실패합니다. 해결책은 언제나 실제 트레이스(real traces)로부터 다시 구축하는 것입니다. 만약 평가 세트가 전혀 없다면(흔한 경우), 이것이 첫 번째 세트를 구축하는 방법이기도 합니다.

2. Evaluators — 출력을 어떻게 점수 매기는가: 네 가지 유형이 있으며, 기준별로 적절한 유형을 선택하는 것이 실제 평가와 보여주기식 평가(theater)를 가르는 차이점입니다.

• Code/heuristic — 결정론적 검사(deterministic checks): (유효한 JSON인가? 올바른 도구가 호출되었는가? 비용이 임계값 미만인가?) 항상 첫 번째 방어선이 되어야 합니다. 정규 표현식(regex)으로 검증할 수 있다면, 절대로 LLM 호출에 비용을 쓰지 마십시오.
• LLM-as-judge — 모델이 루브릭(rubric)에 따라 점수를 매깁니다. 주관적 기준(정확성, 근거성(groundedness), 어조)에 강력하지만, 보정(calibrated)되지 않으면 위험합니다.
• Human review — 그라운드 트루스(ground truth, 정답): 느리지만, LLM-judge를 보정할 수 있는 유일한 수단입니다.
• Pairwise comparison — "A가 B보다 나은가?": 주관적 판단에 있어 절대 점수보다 훨씬 더 신뢰할 수 있습니다.

3. Offline evaluation — 배포 전 테스트하기: 데이터셋에 대해 평가자(evaluators)를 실행하여 실험(experiment)을 생성합니다. 실험이란 하나의 데이터셋에 대한 하나의 에이전트 버전의 측정값입니다.

네 가지 유스케이스(use cases):

• 벤치마킹 (Benchmarking) — 버전 간 비교 (한 번에 하나의 변수만 변경)
• 유닛 테스트 (Unit tests) — 하나의 개별적인 동작 검증
• 회귀 테스트 (Regression tests) — 점수가 하락할 경우 빌드를 실패 처리 (대부분의 팀이 건너뛰지만 ROI가 가장 높은 인프라)
• 백테스팅 (Backtesting) — 수정 사항이 작동함을 증명하기 위해 과거의 입력값(historical inputs)을 대상으로 새 버전을 실행

4. 온라인 모니터링 (Online monitoring) — 실제 트래픽 평가
   핵심적인 차이점: 참조 출력(reference output)이 존재하지 않는다는 것입니다. 실제 사용자가 실제 입력을 보내며, 아무도 "정답"을 알지 못합니다. 따라서 다음과 같은 참조 없는 평가자 (reference-free evaluators)를 사용합니다: 근거성 (groundedness), 형식 유효성 (format validity), 안전성 체크 (safety checks), 거절 정확도 (refusal correctness), 도구 호출 유효성 (tool-call validity), 궤적 건전성 (trajectory sanity).

이 단계는 에이전트 성능 저하 (agent decay)를 포착하는 지점입니다. 즉, 에이전트를 정상 작동하는 상태로 배포했으나 두 달 뒤 조용히 성능이 나빠지는 현상을 말합니다. 이는 제품 대시보드에 나타나기 훨씬 전부터 평가 지표 (eval metrics: 환각률 (hallucination rate), 도구 호출 정확도 (tool-call accuracy), 작업당 비용 (cost per task))에서 먼저 나타납니다. 아무도 열어보지 않는 대시보드가 아니라, Slack/PagerDuty에 이상 징후 알림 (anomaly alerts)을 연결하세요.

5. 기준 및 지표 (Criteria and metrics) — "좋음"의 의미
   대부분의 팀이 놓치는 근본적인 구분은 출력 지표 (output metrics) 대 궤적 지표 (trajectory metrics)입니다.

• 출력 지표 (Output metrics) — 최종 답변이 정확하고, 근거가 있으며, 형식이 잘 갖춰졌는가?
• 궤적 지표 (Trajectory metrics) — 에이전트가 어떤 경로를 거쳤는가? 어떤 도구를 사용했는가, 단계는 몇 단계였는가, 루프(loop)에 빠지지는 않았는가, 비용은 얼마나 들었는가?

대부분의 팀은 출력값만을 측정합니다. 에이전트는 0.02달러짜리 작업에 동일한 도구를 14번 호출하고 3달러를 써가면서도 정답을 만들어낼 수 있습니다. 출력 전용 평가는 이를 "통과"로 점수 매깁니다. 하지만 이것은 통과가 아닙니다. 규모가 커지면 반드시 터질 프로덕션 장애 (production incident)입니다.

그리고 단일 합계 지표인 "87% 통과율"은 버리십시오. 이는 실패한 13%가 무엇인지 (중요도가 높은 케이스인가?), 실패가 특정 카테고리에 몰려 있는지, 그리고 성능이 퇴보했는지 여부를 숨깁니다. 카테고리별로 분해하고, 시간에 따라 추적하며, 구체적인 실패 사례를 드러내십시오.

대부분의 평가가 실패하는 이유
실제 감사(audit)를 통해 발견된 네 가지 패턴:

• 데이터셋이 없거나, 상상 속의 데이터셋을 사용함. 프로덕션은 팀이 볼 수 없었던 방식으로 실패합니다.
• 출력 전용 지표만 사용함. 가장 많은 비용을 발생시키는 궤적 실패(trajectory failures)가 측정되지 않습니다.
• 온라인 평가가 전혀 없음.

출시 전 단 한 번 평가되고, 그 이후로는 다시 평가되지 않습니다. 에이전트는 몇 주 동안 성능이 저하(decaying)되고 있습니다. 루프가 열려 있습니다(The loop is open). 프로덕션에서의 실패가 테스트 케이스로 전환되지 않으므로, 각 실패로부터 아무것도 배우지 못합니다. 이 중 그 어느 것도 모델의 문제는 아닙니다. GPT-4에서 Claude, Gemini로 교체한다고 해서 해결되지 않습니다. 이것들은 이미 알려진 해결책이 있는 엔지니어링 문제입니다. 저는 이 내용을 데이터셋(datasets), 평가자(evaluators), 오프라인(offline), 온라인(online), 지표(metrics)별로 장을 나누어 이곳에 완전한 가이드로 작성했습니다: The complete AI agent evaluation process . 이것은 저희 회사가 감사(audit)하는 모든 프로덕션 에이전트에 적용하는 정확한 프로세스입니다. 만약 귀하의 에이전트가 프로덕션 환경에 있으며 측정할 수 없는 방식으로 고장 나고 있다면, 그것이 바로 그 격차(gap)입니다. 이에 대해 논의하고 싶다면 언제든 연락해 주세요 — fixmyagent.agency .