🔥 Austin's Wiki

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

Jun 07, 202618 min read

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

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

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

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

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

2. 무엇을 평가하는가

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

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

단발성 응답은 Single call에 대한 평가만으로 충분합니다. 하지만 자율적으로 여러 스텝을 거치는 Agent는 Trajectory와 Long horizon까지 봐야 합니다. 그래야 결과는 맞았지만 과정이 위험했던 경우뿐 아니라, Agent가 거부했지만 결과물에 영향을 주었거나 Side Effect가 남은 경우까지 잡을 수 있습니다. Long-running task는 한 덩어리로 평가하면 어디서 잘못됐는지 알기 어렵습니다. 최종 결과물, 진행도, 필수 단계와 디테일의 누락 여부를 나눠서 봐야 합니다.

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% 수준의 정확도에 도달합니다.

중요한 점은 Golden Set이 매우 중요하고, 한 번 보정하고 끝이 아니라 주기적으로 재보정이 필요하다는 것입니다. Eval에 사용되는 도구와 기준도 예외는 아닙니다. Task, dataset, rubric, grader와 verifier 역시 감사하고 버전을 관리해야 합니다. 다만 감사를 검증하기 위한 감사를 끝없이 쌓지는 않도록 합니다.

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 기준을 공급한다고 보면 됩니다.

또한 평가는 정확성과 유용성을 서로 독립적으로 평가해야 합니다. 사용자 관점에서는 답이 올바른지와 실제로 쓸 만한지를 따로 평가해야 합니다. 개발자 관점에서도 조사나 PLAN 자체를 목표로 삼지 말고, 그것이 어떤 의사결정을 지원하고 어떤 행동으로 이어지는지 명확히 해야 합니다.

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 점수는 실제 사용자 가치를 대체하지 못합니다.
  • 측정 환경은 정답 누설 채널을 닫아야 합니다. 에이전트에게 task 필수 입력만 주고, 정답이 흘러들 수 있는 외부 소스를 모두 차단해야 “정답 회수 능력”이 아니라 “스스로 푸는 실력”을 잽니다. 누설 채널은 환경마다 다릅니다 — 인터넷, git history, 같은 repo의 다른 브랜치, 캐시된 빌드 산출물, 테스트에 적힌 expected값 등. 닫지 않으면 점수가 부풀려져, 그 숫자로 신규 입력 성능을 예측할 수 없게 됩니다(예: SWE-bench에서 .git·egress를 막자 87→73%로 정상화). 폐쇄망에서 순수 KB·내장 MCP만으로 성능을 잴 때도 같은 원칙이 적용됩니다.
  • 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)와 함께 검색·인용 품질을 차원별로 채점합니다. 표준은 3축으로 봅니다. Context Relevance(검색된 문서가 질문에 맞는가), Faithfulness/Groundedness(답이 그 문서에 근거하며 환각이 없는가), Answer Relevance(답이 질문에 실제로 답하는가)입니다. golden set(정답셋)이 있으면 정량 비교까지 되고, 없어도 이 3축은 Judge로 채점할 수 있습니다. 프레임워크는 RAGAS와 TruLens의 RAG Triad를 참고합니다.
  • 감사 가능성: 평가의 과정·기준·근거(골든셋·trace·판정 사유)를 남기면 그 기록이 곧 감사 증적이 됩니다. ISO 42001(성능평가·내부감사 기록)이나 EU AI Act Article 12(고위험 AI 자동 로깅)처럼 AI를 직접 겨냥한 기준이 바로 이 기록을 요구합니다. 일반 SOC2·ISO 27001은 보안 통제라 AI 평가 자체를 다루지 않으므로, 이 부분은 AI 관리체계 기준 쪽에 매핑해야 합니다.

References

빅테크 1차·실측 사례에 한정한 인용입니다.

Graph View

Backlinks