AI 에이전트 평가(Eval) 가이드

이 문서는 AI 에이전트·LLM 기능의 품질을 어떻게 측정하고, 그 결과를 개선과 출시 결정으로 되돌리는지를 정리합니다. 코딩 에이전트 운영 전반은 AI 코딩 에이전트 운영 가이드, 보안 경계는 AI 에이전트 보안 가이드를 보고, 본 문서는 “평가” 한 축에 집중합니다.

LLM 출력은 결정적이지 않기 때문에 “정답 하나와 일치하는가”로 검증할 수 없습니다. 같은 입력이라도 모델 버전·세션·맥락에 따라 다른 답이 나오므로, 품질은 한 번의 정답률이 아니라 분포와 궤적으로 봐야 합니다. 그리고 측정한 결과는 반드시 개선 루프로 되돌아와야 의미가 있습니다. 점수 자체는 진단이지 목표가 아닙니다.

1. 정적 벤치마크로는 부족하다

MMLU 같은 모델 단위 벤치마크는 한 번의 정답률을 재는 도구입니다. 그러나 에이전트는 긴 시간축에서 여러 단계의 도구 호출을 하고 외부 상태와 상호작용하기 때문에, 모델의 단발 점수가 시스템 전체의 품질을 대변하지 못합니다. 그래서 봐야 하는 것은 한 번의 정답이 아니라 궤적(trajectory)과 최종 outcome입니다.

코딩·의료·법률처럼 실패 비용이 큰 영역이 늘어날수록 이 차이는 더 중요해집니다. 기준은 “그럴듯한 답을 했는가”가 아니라 “실제로 목표를 달성했는가” 여야 합니다.

2. 무엇을 평가하는가

평가는 하나의 축이 아니라 네 개의 축으로 나눠 보는 것이 좋습니다. 작업의 성격에 따라 어디까지 볼지가 달라집니다.

축	질문	예
outcome	최종 결과가 맞는가	생성된 PR이 테스트를 통과하고 요구를 충족
trajectory	과정이 옳은가	불필요한 도구 호출·잘못된 경로·정책 위반이 없는가
single-call	1회 응답 품질	RAG 답변의 정확도와 인용 적합성
long-horizon	수십~수백 스텝 누적	장기 세션에서 목표 달성과 일관성 유지

단발성 응답이라면 single-call 평가만으로 충분합니다. 하지만 자율적으로 여러 스텝을 도는 에이전트는 trajectory와 long-horizon까지 봐야 “결과는 맞았지만 과정이 위험했던” 실패를 잡을 수 있습니다.

3. 어떻게 채점하는가 — Judge와 Verifier

사람이 모든 출력을 채점할 수 없으므로 LLM에게 채점을 시키게 되는데, 방식이 두 가지로 갈립니다.

• LLM-as-a-Judge: LLM이 출력을 보고 점수를 매깁니다. 빠르고 범용적이지만, 점수 해상도가 낮아 동점(tie)이 자주 나고 자기 출력에는 관대한 경향이 있습니다.
• LLM-as-a-Verifier: 점수를 바로 매기는 대신 평가 기준을 잘게 분해해 항목별로 반복 검증합니다. 판정이 token 단위로 세분화되어 동점이 줄고 정확도가 올라갑니다.

어느 쪽이든 지켜야 할 원칙은 하나입니다. 구현하는 AI와 평가하는 AI를 분리합니다. 같은 모델·같은 편향이면 같은 오류에 함께 빠져서, 틀린 답을 틀렸다고 잡지 못하는 경우가 많습니다.

4. 신뢰할 수 있는 Judge 만들기

Judge를 쓰기로 했다면, Judge 자체도 검증과 보정의 대상이라는 점을 잊으면 안 됩니다. Netflix가 신뢰할 만한 Judge를 만들 때 쓴 패턴이 참고가 됩니다.

• 품질 차원 분해: “좋음/나쁨” 하나로 뭉뚱그리지 않고, 명시적인 여러 차원으로 나눠 각각 채점합니다.
• golden set: 전문가가 라벨링한 정답셋(~600개)으로 Judge를 보정(calibration)합니다.
• 다단 추론 + 합의: 여러 단계로 추론하고 복수 판정을 합의시키면 83~92% 수준의 정확도에 도달합니다.

핵심 함의는, 정답셋 없이 Judge 점수를 그대로 믿으면 안 된다는 것입니다. Judge도 한 번 보정하고 끝이 아니라 주기적으로 재보정해야 합니다.

5. 궤적(trajectory) 평가

장기·다단계 에이전트는 결과만 보는 단일 Judge로는 부족합니다. 과정에서 무엇이 잘못됐는지를 봐야 하기 때문입니다.

• Agent Judge (judgmentlabs): 평가 자체를 여러 에이전트로 구성합니다. 증거를 찾는 Search, DB·GitHub·API로 실제 확인하는 Verification, 평가 기준을 상황에 맞게 만드는 Adaptation 세 축으로 나눕니다. 일반 Judge(0.74)나 Claude Code(0.73)보다 높은 0.86 정확도를 보였고, 특히 어려운 케이스에서 앞섭니다. 핵심은 실측으로 검증하고 루브릭을 적응시키는 것입니다.
• macro-evaluation (OpenAI): 실패를 하나씩 들여다보는 대신, 전체 trace 모집단의 패턴을 분석해 체계적인 실패 모드를 찾아냅니다. 개별 사례가 아니라 경향을 봅니다.

6. 평가를 운영 루프에 연결한다

평가는 출시 전에 한 번 점수를 내고 끝나는 것이 아니라, 개선을 위한 입력입니다. 평가 결과가 다시 시스템으로 돌아오는 고리를 만들어야 합니다.

• funnel, not a fork (Spotify): offline 평가와 online 실험을 따로 굴리지 말고 하나의 깔때기로 잇습니다. offline 평가로 후보를 거르고 online으로 실측한 뒤, 그 피드백을 다시 평가로 되돌립니다.
• self-improving loop (OpenAI): 실무자가 고친 내용을 구조화된 평가로 만들어 자동 수정에 반영하는 반복 구조입니다. production에서 난 실패가 곧 다음 평가 케이스가 됩니다.
• self-healing eval (Raindrop): trace를 읽어 평가 케이스를 자동으로 만들고 고치며, 로컬 replay로 회귀를 검증합니다.

이 피드백 고리의 실행 형태가 운영 가이드의 “자가 교정 루프(Review → Repair → Validate)“입니다. 평가가 그 루프의 Validate 기준을 공급한다고 보면 됩니다.

7. 출시 기준: “done”의 재정의

결정적인 일반 소프트웨어는 “테스트가 모두 통과하면 완료”라는 정의가 통했습니다. 그러나 AI 기능은 같은 입력에도 출력이 흔들리기 때문에 이 정의가 깨집니다. “all tests pass”나 “스펙대로 동작”이라는 말 자체가 성립하지 않습니다. 그래서 done의 정의를 calibration, 즉 “허용 가능한 변동을 받아들이고 어긋났을 때 대응할 수 있는 상태”로 바꿔야 합니다.

구체적으로는 세 가지를 출시 전에 갖춰야 비로소 done입니다.

• 분포형 합격 기준: “이 입력엔 정확히 Y” 같은 단일 정답이 아니라, “카테고리 X 입력의 80%는 품질 기준 Y를 충족하고, 나머지 20%는 우아하게 실패(graceful degrade)한다”처럼 허용 변동을 분포로 명시합니다.
• 실패 대응자 사전 지정: 출시 후 모델 품질·UX·콘텐츠·평판 중 어디서 문제가 터졌을 때 누가 처리하는지를 배포 전에 정해 둡니다. 기능이 배포된 순간이 아니라, downstream에서 오작동했을 때 무엇을 할지를 관련된 사람들이 알 때가 done입니다.
• tripwire와 리허설된 롤백: 에러율·환각율처럼 넘으면 위험한 임계 지표(tripwire)를 정하고, 그 지표가 울리면 즉시 되돌릴 롤백 절차를 문서로만 두지 말고 실제로 리허설해 둡니다.

요점은, AI 기능에서 배포는 끝이 아니라 학습의 시작이라는 것입니다. done은 “분포 합격 + 실패 대응 체계”가 갖춰진 상태이지, 테스트 초록불 하나가 아닙니다. 이렇게 출시하면 기능 수는 줄지만 그만큼 사후 티켓과 평판 사고가 줄어듭니다.

8. 미해결 영역과 주의점

• 자가 검증의 신뢰성은 아직 풀리지 않은 문제입니다. Judge나 Verifier를 아무리 늘려도, 구현 AI와 평가 AI가 편향을 공유하면 틀린 부분을 잡아낼 수 없습니다. 그래서 Deterministic Check와 Human in the loop는 계속 중요합니다.
• 지표는 목표가 아닙니다. Judge 점수나 통과율을 목표로 삼으면 안 됩니다. Benchmark 점수는 실제 사용자 가치를 대체하지 못합니다.
• Judge의 동점과 점수 인플레이션을 경계하고, golden set으로 주기적으로 재보정합니다.

9. 도입 체크리스트

평가 파이프라인을 처음 세울 때의 순서입니다.

• 구현/평가 분리: 생성하는 모델과 평가하는 모델·기준을 분리합니다 (§3).
• golden set 확보: 소수라도 전문가 라벨 정답셋을 만들어 Judge를 보정합니다 (§4).
• 기준 분해: 단일 점수가 아니라 차원별·Verifier식 기준으로 나눕니다 (§3~4).
• 궤적까지 평가: 단발 응답이면 single-call로, 자율 에이전트면 trajectory와 실측 검증까지 추가합니다 (§5).
• 루프 연결: offline 평가 → online 실측 → 피드백을 하나의 깔때기로 잇고, Production 실패 데이터를 다음 평가에 활용합니다 (§6).
• 출시 기준 정의: “테스트 통과”가 아니라 분포 합격 + tripwire + 리허설된 롤백 + 실패 대응자 사전 지정을 done의 기준으로 삼습니다 (§7).
• RAG 평가: 답변 정확도(single-call)와 함께 인용·검색 품질을 차원별로 채점하고 golden set으로 보정하면, 검색이나 프롬프트를 바꿨을 때의 효과를 빠르게 비교할 수 있습니다.
• 감사 가능성: 평가의 과정·기준·근거(골든셋·trace·판정 사유)를 남기면 그 기록이 곧 감사 증적이 됩니다. ISO 42001(성능평가·내부감사 기록)이나 EU AI Act Article 12(고위험 AI 자동 로깅)처럼 AI를 직접 겨냥한 기준이 바로 이 기록을 요구합니다. 일반 SOC2·ISO 27001은 보안 통제라 AI 평가 자체를 다루지 않으므로, 이 부분은 AI 관리체계 기준 쪽에 매핑해야 합니다.

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
• What “done” means when you’re shipping AI features — Jeff Gothelf (done = calibration·실패 대응자·rehearsed rollback)