Agent Evaluation Readiness Checklist

한 줄 요약

에이전트 평가를 체계적으로 수행하기 위한 실전 체크리스트. 가장 간단한 eval부터 시작하고, 인프라 구축 전에 20-50개 트레이스를 수동으로 먼저 리뷰하라.

가장 먼저 신호를 주는 가장 단순한 eval로 시작해라. 아키텍처가 아직 변하고 있어도, 핵심 과업을 수행하는지 테스트하는 엔드투엔드 eval이 베이스라인을 준다.

20-50개 실제 에이전트 트레이스를 수동 리뷰 — 어떤 자동화 시스템보다 실패 패턴을 잘 알려줌
단일 과업에 대한 명확한 성공 기준 정의 — 두 전문가가 동의할 수 없는 기준은 재설계 필요
Capability eval과 Regression eval 분리
- Capability: “뭘 할 수 있는가?” → 낮은 패스율에서 시작
- Regression: “아직 잘 되는가?” → ~100% 패스율 목표
각 실패의 원인을 명확히 설명할 수 있어야 함 — eval 노력의 60-80%를 여기에 써야 함
eval 소유권을 단일 도메인 전문가에게 할당 — 위원회 설계 금지
인프라/파이프라인 문제를 먼저 배제 — 단일 추출 버그가 벤치마크를 50% → 73%로 바꾼 사례 있음

원인	해결 방법
프롬프트 문제	지시가 불명확 → 프롬프트 수정
툴 설계 문제	인터페이스가 에이전트 실수 유발 → 파라미터 재설계, 예제 추가
모델 한계	지시가 명확하지만 LLM이 엣지케이스 일반화 실패 → 아키텍처 변경 또는 모델 교체
아직 모름	충분한 실패를 안 봤음 → 더 많은 에러 분석 필요

세 가지 차원으로 평가:
- 최종 응답 — 출력이 정확하고 유용한가?
- 경로 — 에이전트가 합리적인 경로를 거쳤는가? (기대와 다를 수 있으나 유효한지)
- 상태 변경 — 에이전트가 올바른 아티팩트를 생성했는가? (파일, DB 업데이트, 캘린더 일정 등)

💡 상태 변경 평가가 가장 간과됨. “회의가 예약되었습니다!”라고 말했지만 실제 캘린더 이벤트가 없으면 실패.

Guardrails(인라인, 런타임)와 Evaluators(오프라인, 배치)를 구분할 것.