AI 에이전트·LLM 기능의 품질을 어떻게 측정하고 개선 루프에 연결하는지 정리합니다. 코딩 에이전트 운영 전반은 AI 코딩 에이전트 운영 가이드를 보고, 본 문서는 “평가” 한 축만 다룹니다. 빅테크 1차 출처·실측 사례에 한정합니다.
1. 정적 벤치마크에서 동적 평가로
- 모델 단위 정적 벤치마크(MMLU류)는 에이전트 시스템 품질을 대변하지 못한다. 에이전트는 긴 시간축·다단계 도구 호출·외부 상태와 상호작용하므로, 한 번의 정답률이 아니라 궤적(trajectory)과 최종 outcome을 봐야 한다. (Cameron Wolfe)
- 코딩·의료·법률 등 고위험 역할이 늘면서 outcome 중심 평가의 중요도가 커진다. “그럴듯한 답”이 아니라 “실제로 목표를 달성했는가”가 기준.
2. 무엇을 평가하는가
| 축 | 질문 | 예 |
|---|---|---|
| outcome | 최종 결과가 맞는가 | 생성된 PR이 테스트 통과·요구 충족 |
| trajectory | 과정이 옳은가 | 불필요 도구 호출·잘못된 경로·정책 위반 없음 |
| single-call | 1회 응답 품질 | RAG 답변 정확도·인용 적합성 |
| long-horizon | 수십~수백 스텝 누적 | 장기 세션에서 목표 달성·일관성 유지 |
단발 응답은 single-call 평가로 충분하지만, 자율 에이전트는 trajectory + long-horizon까지 봐야 실패를 잡는다.
3. Judge vs Verifier
- LLM-as-a-Judge: LLM이 출력에 점수를 매긴다. 빠르고 범용이나 score granularity가 낮아 tie(동점)가 잦고, 자기 출력엔 관대하다.
- LLM-as-a-Verifier: 점수 대신 평가 기준을 분해해 반복 검증하고 token 단위 granularity로 판정 → tie 제거, 정확도 상승.
- 원칙: 구현 AI와 평가 AI는 분리한다. 같은 모델·편향이면 같은 오류에 함께 빠진다. AI 코딩 에이전트 운영 가이드의 “gen ≠ eval”과 같은 선상.
4. LLM-as-a-Judge 설계 (Netflix)
신뢰할 만한 judge를 만드는 구체 패턴:
- 품질 차원 분해: 단일 “좋음/나쁨”이 아니라 명시적 4개 차원으로 나눠 채점.
- golden set: ~600개 전문가 라벨 정답셋으로 judge를 보정(calibration).
- tiered reasoning + consensus: 다단 추론 + 복수 판정 합의 → 83~92% 정확도.
- 함의: judge도 검증·보정 대상이다. 라벨셋 없이 judge 점수를 신뢰하지 말 것.
5. 궤적(trajectory) 평가
장기·다단계 에이전트는 단일 judge로 부족하다.
- Agent Judge (judgmentlabs): 평가 자체를 다중 에이전트로 — Search(증거 탐색)·Verification(DB/GitHub/API 실측)·Adaptation(Rubric Builder) 3축. 정확도 0.86으로 일반 judge(0.74)·Claude Code(0.73)를 상회, 난이도 높은 케이스에서 우위. 핵심은 실측 검증 + 루브릭 적응.
- macro-evaluation (OpenAI): 개별 실패를 하나씩 보지 말고 trace population 전반의 패턴을 분석 → 체계적 실패 모드를 발견.
6. 평가를 운영 루프에 연결
평가는 1회성 점수가 아니라 개선 루프의 입력이다.
- funnel, not a fork (Spotify): offline eval과 online experiment를 하나의 깔때기로 연결한다. offline eval로 후보를 거르고 online으로 실측, 피드백을 다시 eval로. 둘을 분리(fork)하지 말 것.
- self-improving loop (OpenAI Codex 세무 에이전트): 실무자 수정 → 구조화 eval → 자동 수정의 반복. 7,000건 처리·정확도 97%, 6주 내 86%가 목표 도달. production 실패가 곧 다음 eval 케이스.
- self-healing eval (Raindrop): trace를 읽어 eval을 작성·수정하고 로컬 replay로 회귀 검증.
- AI 코딩 에이전트 운영 가이드의 “3-phase 자가 교정 루프”가 이 평가 피드백의 실행 형태다.
7. 미해결·주의
- 자가 검증 신뢰성은 여전히 미해결. judge/verifier를 늘려도 구현 AI와 편향을 공유하면 같이 틀린다. deterministic check(테스트·lint·스키마)와 human-in-the-loop가 최종 안전판.
- 지표 ≠ 목표: judge 점수·통과율을 목표로 삼으면 Goodhart. 점수는 진단 도구일 뿐 본질(실제 사용자 가치)을 대체하지 않는다.
- judge tie·score 인플레이션을 경계하고, golden set으로 주기적으로 재보정한다.
8. 도입 체크리스트
평가 파이프라인을 처음 세울 때 순서:
- 구현/평가 분리: 생성 모델과 평가 모델·기준을 분리한다 (§3).
- golden set 확보: 소수라도 전문가 라벨 정답셋을 만들어 judge를 보정한다 (§4).
- 기준 분해: 단일 점수 대신 차원별·verifier식 기준으로 나눈다 (§3~4).
- 궤적까지 평가: 단발 응답이면 single-call, 자율 에이전트면 trajectory·실측 검증을 추가한다 (§5).
- 루프 연결: offline eval → online 실측 → 피드백을 하나의 깔때기로 잇고, production 실패를 다음 eval 케이스로 회수한다 (§6).
- RAG 평가: 답변 정확도(single-call) + 인용·검색 품질을 차원 분해해 채점하고 golden set으로 보정하면, 검색·프롬프트 변경을 빠르게 비교·개선할 수 있다.
- 감사 가능성: 평가 과정·기준·근거를 기록하면 규제·컴플라이언스 대응에서 그 자체가 강점이 된다.
References
빅테크 1차·실측 사례에 한정한 인용입니다.
- Evaluating Netflix show synopses with LLM-as-a-judge — Netflix (차원 분해·golden set·consensus)
- LLM-as-a-Verifier — judge tie 문제와 verifier 개선
- Agent evals — Cameron Wolfe (정적→동적)
- Agent Judge: solving long-context evaluations — judgmentlabs (Search/Verification/Adaptation)
- Macro-evals for agentic systems — OpenAI Cookbook (trace population)
- Better experiments with LLM evals: a funnel, not a fork — Spotify
- Building self-improving tax agents with Codex — OpenAI (self-improving loop)
- Raindrop Workshop — trace 기반 self-healing eval