에이전트 평가를 위한 실용적 준비 체크리스트
TL;DR
AI 에이전트 평가는 전통적인 소프트웨어 테스트와 다르다. 복잡한 평가 시스템을 구축하기 전에 20
50개의 실제 트레이스를 직접 읽고, end-to-end 태스크 완수를 검증하는 단순한 eval부터 시작하라. 6080%의 시간을 에러 분석에 투자하고, capability eval(무엇을 할 수 있는가)과 regression eval(여전히 작동하는가)을 명확히 분리하며, 차원별 전문 채점기를 설계하라. 프로덕션 트레이스를 지속적으로 데이터셋에 편입하는 플라이휠을 구축하면, 시간이 지남에 따라 에이전트가 개선된다.
Key Takeaways
- 단순함부터 시작: 복잡한 인프라를 만들기 전에 30분간 실제 트레이스를 수동으로 읽어라. 자동 시스템보다 더 많은 실패 패턴을 발견할 수 있다.
- 에러 분석에 60~80% 투자: 실패 트레이스를 도메인 전문가와 함께 분석하여 프롬프트 문제, 툴 설계 문제, 모델 한계를 구분하고, 각 유형에 맞는 대응을 취하라.
- 평가 레벨의 전략적 선택: Single-step(툴 선택), Full-turn(end-to-end 태스크 완수 + 상태 변경), Multi-turn(대화 맥락 유지) 중 Full-turn부터 시작하여 안정화 후 확장하라.
- 차원별 전문 채점기: "정확성" 하나로 뭉뚱그리지 말고 콘텐츠 정확성, 구조, 포맷, 효율성 등 차원별로 독립된 채점기를 설계해 실패 원인을 명확히 파악하라.
- Trace-to-Dataset 플라이휠: 프로덕션의 성공/실패 트레이스가 자동으로 데이터셋에 편입되고, 개선된 에이전트가 다시 프로덕션에 배포되는 순환 구조가 장기적 개선의 핵심이다.
상세 내용
에이전트 평가의 핵심 원칙
AI 에이전트는 전통적인 소프트웨어와 근본적으로 다르다. 소프트웨어는 결정론적이고 코드가 진리의 원천이지만, 에이전트는 LLM의 추론에 의존하며 같은 입력에도 다른 경로를 선택할 수 있다. 에이전트가 200단계를 거쳐 2분간 작업한 후 실패했을 때, 스택 트레이스는 없다. 코드가 실패한 것이 아니라 추론이 실패한 것이기 때문이다.
가장 중요한 원칙은 단순함부터 시작하는 것이다. 몇 개의 end-to-end eval로 에이전트가 핵심 태스크를 완수하는지 검증하는 것만으로도 즉시 baseline을 확보할 수 있다. 복잡한 구조는 단순한 방법이 실제 실패를 놓칠 때만 추가한다.
Eval 구축 전 준비사항
수동 트레이스 리뷰: 30분의 투자
자동화된 평가 인프라를 만들기 전에 반드시 해야 할 일이 있다. 실제 에이전트 트레이스 20~50개를 직접 읽어라. 30분의 수동 리뷰가 어떤 자동 시스템보다 많은 실패 패턴을 알려준다. LangSmith의 트레이스 뷰어와 Annotation Queue를 활용하면 트레이스를 효율적으로 수집하고 검토할 수 있다.
에이전트는 LLM과 툴을 여러 턴에 걸쳐 호출하고, 중간 결과에 따라 행동을 조정하며, 상태를 수정한다. 이러한 복잡한 행동은 코드를 읽는 것만으로는 예측할 수 없으며, 실제 실행 트레이스가 진리의 원천이 된다.
명확한 성공 기준 정의
두 명의 전문가가 pass/fail에 합의할 수 없다면, 태스크 자체를 재정의해야 한다.
나쁜 예: "이 문서를 잘 요약해줘"
좋은 예: "이 회의록에서 핵심 액션 아이템 3개를 추출하라. 각각 20단어 이내, 담당자가 언급되었으면 포함할 것"
모호한 기준은 채점기의 불일치를 만들고, 무엇이 개선인지 판단할 수 없게 만든다.
Capability Eval vs Regression Eval 분리
이 두 가지는 목적이 완전히 다르기 때문에 반드시 분리해서 관리해야 한다.
- Capability Eval ("무엇을 할 수 있는가?"): 어려운 태스크에 대한 진전을 측정한다. 초기 pass rate가 낮고, 개선의 방향을 제시한다.
- Regression Eval ("여전히 작동하는가?"): 이미 작동하는 기능을 보호한다. pass rate가 ~100%여야 하며, 기존 기능의 퇴보를 감지한다.
Capability eval만 있으면 기존 기능이 깨지고, regression eval만 있으면 개선이 멈춘다. 두 가지 모두 필요하다.
에러 분석에 60~80% 투자하라
전체 eval 노력의 60~80%를 에러 분석에 투자해야 한다. 이것이 가장 높은 ROI를 제공하는 활동이다. 절차는 다음과 같다:
- 대표적인 실패 트레이스를 수집한다.
- 도메인 전문가와 함께 사전 분류 없이 모든 이슈를 기록한다(open coding).
- 이슈를 실패 유형으로 분류한다(프롬프트 문제, 툴 설계 문제, 모델 한계, 인프라 이슈 등).
- 새로운 실패 유형이 나오지 않을 때까지 반복한다.
실패 유형에 따라 대응이 완전히 달라진다:
- 프롬프트 문제: 지시가 불명확 → 프롬프트 수정
- 툴 설계 문제: 인터페이스가 오용을 유발 → 파라미터 재설계, 예시 추가
- 모델 한계: 지시는 명확하지만 일반화 실패 → few-shot 예시 추가, 아키텍처 변경, 모델 교체
- 아직 모름: 충분한 실패 사례를 보지 못한 상태 → 에러 분석 계속
Anthropic 팀은 SWE-bench 에이전트를 만들 때 프롬프트 최적화보다 툴 인터페이스 최적화에 더 많은 시간을 썼다고 보고했다. 예를 들어 절대 경로를 강제하면 경로 관련 에러 전체를 제거할 수 있다.
Eval 오너십과 인프라 검증
데이터셋 유지보수, 채점기 재캘리브레이션, 새 실패 모드 분류, "충분히 좋은" 기준 결정을 한 명의 도메인 전문가가 책임져야 한다. 위원회식 의사결정은 책임 소재를 흐리고 진전을 늦춘다.
또한 인프라 문제를 먼저 배제해야 한다. Witan Labs 팀은 단일 추출 버그를 고쳤을 때 벤치마크가 50%에서 73%로 뛴 사례를 보고했다. 타임아웃, 잘못된 API 응답, 오래된 캐시 같은 인프라 이슈가 추론 실패로 위장하는 경우가 잦다.
평가 레벨 선택
에이전트 평가는 세 가지 레벨로 나뉘며, Trace-level(Full-turn)부터 시작하는 것을 권장한다.
Single-step Eval (Run 레벨)
"올바른 툴을 선택했는가?", "유효한 API 호출을 생성했는가?"를 평가한다. 자동화가 가장 쉽지만, 에이전트 아키텍처가 안정적일 때만 유효하다. 아키텍처가 자주 바뀌는 초기 단계에서는 특정 툴 호출 패턴에 의존하는 평가가 빠르게 obsolete해진다.
Full-turn Eval (Trace 레벨)
대부분의 팀이 시작해야 할 레벨이다. 세 가지 차원을 함께 평가한다:
- 최종 응답: 출력이 정확하고 유용한가?
- 경로(Trajectory): 합리적인 경로를 거쳤는가? (정확한 경로가 아닌, 유효한 경로)
- 상태 변경: 올바른 아티팩트가 생성되었는가? (파일 작성, DB 업데이트, 캘린더 이벤트 등)
상태 변경 검증은 자주 간과되지만 매우 중요하다. 에이전트가 "미팅 잡았습니다!"라고 말했더라도, 실제 캘린더에 올바른 시간·참석자·설명으로 이벤트가 존재하는지 확인해야 한다. 코딩 에이전트의 경우 생성된 파일이 실행 가능한지, 유닛테스트를 통과하는지 검증해야 한다.
Multi-turn Eval (Thread 레벨)
가장 구현이 어렵다. Trace-level eval이 안정된 후에 추가한다. N-1 테스팅 기법이 유용하다: 프로덕션의 실제 대화에서 앞 N-1턴을 그대로 주고 마지막 턴만 에이전트가 생성하게 한다. 이를 통해 완전 합성 멀티턴 시뮬레이션의 compounding error를 회피할 수 있다.
데이터셋 구성 전략
품질이 양을 이긴다
검증된 20~50개가 미검증 수백 개보다 낫다. 모든 태스크는 참조 솔루션(reference solution)을 포함해야 하며, 이를 통해 태스크가 풀 수 있다는 것을 증명하고 채점의 기준선을 제공한다.
나쁜 예: "NYC행 좋은 항공편 찾아줘"
좋은 예: "SFO→JFK 왕복, 12/15~17 출발, 12/22 복귀, $400 이하, 이코노미"
포지티브 + 네거티브 케이스
"검색해야 할 때 검색하는가?"만 테스트하면, 모든 것을 검색하는 에이전트에 최적화된다. 네거티브 케이스(해당 행동을 하면 안 되는 경우)도 반드시 포함해야 한다. Anthropic은 프론티어 모델이 정적 eval의 한계를 넘어서는 창의적 해법을 발견한 사례를 보고했다—Opus 4.5가 항공권 예약 문제에서 정책의 허점을 발견해 더 나은 해법을 제시했으나, 기존 채점기로는 "실패"로 판정되었다.
에이전트 유형별 맞춤
- 코딩 에이전트: 결정적 테스트 스위트(유닛테스트 pass/fail) + 품질 루브릭
- 대화형 에이전트: 태스크 완수 + 상호작용 품질(공감, 명확성) 다차원 평가
- 리서치 에이전트: 근거성 체크(주장이 소스에 뒷받침되는가?) + 커버리지 체크(핵심 사실이 포함되었는가?)
데이터 소싱: 3가지 전략 병행
- 독파운딩(Dogfooding): 팀이 매일 에이전트를 스트레스 테스트하고, 모든 에러를 eval로 전환한다.
- 외부 벤치마크 적응: Terminal Bench, BFCL 등에서 관련 태스크를 선별하여 자신의 에이전트에 맞게 변환한다.
- 수작업 행동 테스트: "에이전트가 툴 호출을 병렬화하는가?", "모호한 요청에 명확화 질문을 하는가?" 등 특정 행동을 검증하는 테스트를 직접 작성한다.
Trace-to-Dataset 플라이휠
프로덕션의 성공/실패 트레이스가 지속적으로 데이터셋에 편입되는 파이프라인을 구축한다. LangSmith를 사용하면 트레이스 → 어노테이션 큐 → 데이터셋 → 실험의 흐름을 자동화할 수 있다.
채점기(Grader) 설계
차원별 전문 채점기
하나의 "정확성" 채점기 대신 차원별로 분리하라. Witan Labs 팀은 콘텐츠 정확성, 구조, 시각 포맷, 수식 시나리오, 텍스트 품질 등 5개의 전문 평가기를 만들어 어디가 실패하는지 명확한 시그널을 얻었다.
| 채점기 유형 | 적합한 용도 | 주의점 |
|---|---|---|
| 코드 기반 | 결정적 체크, 툴 호출 검증, 출력 포맷, 실행 결과 | 유효하지만 예상치 못한 포맷에서 false-fail 가능 |
| LLM-as-judge | 뉘앙스 있는 품질, 루브릭 기반 채점, 개방형 태스크 | 사람과의 캘리브레이션 필수 |
| 사람 | 캘리브레이션, 주관적 기준, 엣지 케이스 | 비용 높고 느리며 확장 어려움 |
객관적 정답이 있는 경우 코드 기반을 기본으로 사용한다. LLM-as-judge를 객관적 태스크에 쓰면 불일치가 실제 regression을 가릴 수 있다.
Guardrail vs Evaluator 구분
| Guardrail | Evaluator | |
|---|---|---|
| 실행 시점 | 실행 중, 사용자가 출력을 보기 전 | 생성 후, 비동기 |
| 속도 | 밀리초 (빠를 것) | 초~분 (비용 투자 가능) |
| 목적 | 위험하거나 잘못된 출력 차단 | 품질 측정 및 regression 감지 |
| 예시 | PII 탐지, 포맷 검증, 안전 필터 | LLM-as-judge 채점, 경로 분석 |
바이너리 pass/fail 선호
1~5점 척도는 인접 점수 간 주관적 차이를 만들고, 통계적 유의미성을 위해 더 큰 샘플이 필요하다. 바이너리는 더 명확한 사고를 강제한다: 성공했거나 실패했거나. 복잡한 태스크는 여러 개의 바이너리 체크로 분해한다.
LLM-as-judge 캘리브레이션
- LangSmith Align Evaluator로 20개 이상의 라벨 예시로 시작, 프로덕션급 신뢰도를 위해 ~100개까지 확대
- 채점기의 출력에 **판단 근거(reasoning)**를 포함시켜 정확도를 높이고 감사 가능성 확보
- 정기적 재캘리브레이션 필수 — 채점기는 시간이 지나면 드리프트함
- few-shot 예시를 사용해 일관성 향상
결과를 채점하라, 경로가 아니라
에이전트는 창의적인 경로를 찾는다. "check_availability → create_event 순서로 호출했는가?"가 아니라 **"미팅이 올바르게 잡혔는가?"**를 평가해야 한다. 다만 효율성 측정을 위해 이상적 경로 대비 실제 스텝 수를 추적하는 것은 유용하다. 이것은 정확성 채점이 아니라 효율성 메트릭이다.
부분 점수(partial credit)도 고려한다. 문제를 정확히 식별했지만 마지막 단계에서 실패한 에이전트는, 처음부터 실패한 에이전트보다 낫다.
커스텀 평가기 사용
"helpfulness"나 "coherence" 같은 범용 메트릭은 거짓 확신을 만든다. 에러 분석에서 발견한 특정 실패 모드를 잡는 커스텀 평가기가 실제로 의미 있는 시그널을 준다. Deep Agents 팀은 각 eval에 docstring을 작성하여 무엇을 측정하는지 자체 문서화하고, tool_use 같은 카테고리 태그로 그룹 실행을 가능하게 한다.
실행 및 반복
세 가지 평가 타이밍
| 타이밍 | 정의 | 용도 |
|---|---|---|
| Offline | 큐레이션된 데이터셋, 배포 전 실행 | 변경사항을 출시 전에 검증 |
| Online | 프로덕션 트래픽에 대한 지속적 평가 | 실 트래픽에서 실패 포착 |
| Ad-hoc | 수집된 트레이스에 대한 탐색적 분석 | 예상 못한 패턴 발견 |
세 가지를 모두 활용해야 한다. Offline은 배포 전 품질 게이트, online은 프로덕션 모니터링, ad-hoc은 새로운 인사이트 발견에 각각 필수적이다.
비결정성 대응
모델 출력은 실행마다 달라진다. 태스크당 여러 번 반복 실행하고, 개선을 선언하기 전에 신뢰구간을 계산한다. 제품 요구사항에 따라 pass@k(k번 중 1번 이상 성공) 또는 pass^k(k번 모두 성공) 메트릭을 선택한다.
실행 환경 격리
시행 2가 시행 1의 아티팩트를 볼 수 있으면 결과가 독립적이지 않다:
- 코딩 에이전트: 시행마다 새 컨테이너/VM
- API 호출 에이전트: 스테이징 환경 또는 모의 서비스
- DB 에이전트: 시행 간 스냅샷 복원
메타데이터와 효율성 메트릭
실험마다 모델, 프롬프트 버전, 검색 전략 등의 메타데이터를 기록하여, "GPT-4.1에서 Claude Sonnet으로 바꾸면 정확도가 오르는가?" 같은 질문에 답할 수 있게 한다.
품질과 함께 효율성 메트릭도 추적한다: 실제 스텝 수 / 이상적 스텝 수, 툴 호출 횟수, 토큰 사용량, 지연시간. 정확도 95%이지만 10배 느린 에이전트는 개선이 아닐 수 있다.
Pass Rate 정체 시 대응
같은 유형의 태스크를 더 추가해도 새로운 실패 모드가 발견되지 않으면, 더 어려운 태스크를 추가하거나, 새로운 기능을 테스트하거나, 다른 차원으로 이동한다. 포화된 eval 세트를 반복하는 것은 시간 낭비다.
의미 있는 Eval만 유지하라
모든 eval은 시스템에 압력을 가한다. 무분별하게 수백 개를 추가하면 프로덕션에서 중요하지 않은 것에 최적화하게 된다. 더 많은 eval이 더 나은 에이전트를 의미하지는 않는다. 주기적으로 시그널을 주지 않는 eval을 제거한다.
Task Failure vs Evaluation Failure 구분
실행 상태를 명시적으로 추적한다(완료, 에러, 타임아웃). 타임아웃을 "추론 실패"로 채점하면 메트릭이 오염된다. 에이전트의 실패와 채점기의 실패를 분리해야 한다.
프로덕션 준비
CI/CD 파이프라인 통합
일반적인 흐름:
- 코드/프롬프트 변경이 파이프라인을 트리거한다.
- Offline eval 실행: 유닛테스트, 통합테스트, 큐레이션 데이터셋 대비 평가 (저비용·고속 코드 기반 채점기).
- offline eval 통과 시 preview 배포.
- preview에서 online eval 실행 (LLM-as-judge 채점기).
- 모든 품질 게이트 통과 시에만 프로덕션 프로모트. 실패 시 해당 트레이스를 annotation queue로 라우팅하고 팀에 알림.
매 커밋마다 저비용 코드 기반 채점기를 CI에서 돌리고, 비용이 높은 LLM-as-judge는 preview/프로덕션 단계에 사용한다.
유저 피드백의 중요성
자동 eval은 이미 알고 있는 실패 모드만 잡는다. 사용자가 발견하는 것들이 있다: 데이터셋이 놓친 엣지 케이스, 기술적으로는 맞지만 도움이 안 되는 출력, 예상 못한 방식으로 깨지는 워크플로우. 구조화된 피드백을 데이터셋에 편입하고, 채점기를 실제 기대치에 맞게 캘리브레이션하고, 사용자에게 실제로 중요한 개선에 우선순위를 둔다.
프로덕션 플라이휠
프로덕션의 성공과 실패가 데이터셋, 에러 분석, eval 개선으로 되돌아가는 순환 구조를 구축한다. 이것이 에이전트를 시간이 지남에 따라 개선시키는 플라이휠이다:
프로덕션 트레이스 → 에러 분석 → 데이터셋 업데이트 → Eval 개선 → 에이전트 개선 → 프로덕션 배포 → (반복)
Capability → Regression 승격
꾸준히 높은 pass rate를 보이는 capability eval을 regression suite로 승격한다. "할 수 있는가?"를 검증한 태스크가 "여전히 할 수 있는가?"를 보호하는 태스크로 전환된다.
전체 체크리스트 요약
Eval 구축 전
- ☑️ 20~50개 실제 트레이스 수동 리뷰
- ☑️ 명확한 성공 기준 정의
- ☑️ Capability/Regression eval 분리
- ☑️ 실패 원인 식별 및 분류
- ☑️ 단일 도메인 전문가에게 오너십 부여
- ☑️ 인프라 문제 배제
평가 레벨 선택
- ☑️ Trace-level(Full-turn)부터 시작
- ☑️ 최종 응답 + 경로 + 상태 변경 함께 평가
- ☑️ 아키텍처 안정화 후 Single-step 추가
- ☑️ Multi-turn은 N-1 테스팅 기법 활용
데이터셋 구성
- ☑️ 모든 태스크에 참조 정답 포함
- ☑️ 포지티브 + 네거티브 케이스 균형
- ☑️ 검증된 20~50개부터 시작
- ☑️ 독파운딩 + 외부 벤치마크 적응 + 수작업 병행
- ☑️ Trace-to-Dataset 파이프라인 구축
- ☑️ 에이전트 유형별 맞춤 설계
채점기 설계
- ☑️ 차원별 전문 채점기 분리
- ☑️ Guardrail과 Evaluator 구분
- ☑️ 바이너리 pass/fail 선호
- ☑️ LLM-as-judge는 20+ 예시로 캘리브레이션
- ☑️ 결과를 채점, 경로는 효율성 메트릭으로
- ☑️ 에러 분석 기반 커스텀 평가기
실행 및 반복
- ☑️ Offline/Online/Ad-hoc 세 가지 타이밍 활용
- ☑️ 비결정성 대응: 반복 실행 + 신뢰구간
- ☑️ 실행 환경 격리
- ☑️ 메타데이터 + 효율성 메트릭 추적
- ☑️ 실패 트레이스 수동 검토
- ☑️ 포화된 eval 제거, 의미 있는 것만 유지
- ☑️ Task/Evaluation Failure 구분
프로덕션 준비
- ☑️ CI/CD 파이프라인 통합
- ☑️ 온라인 평가 지속 실행
- ☑️ 유저 피드백 구조화 수집
- ☑️ 프롬프트/툴 정의 버전 관리
- ☑️ Capability → Regression 승격
- ☑️ 프로덕션 플라이휠 구축
References
- Agent Evaluation Readiness Checklist — Victor Moreira, LangChain
- Agent Observability Powers Agent Evaluation — LangChain
- How we build evals for Deep Agents — LangChain
- Demystifying Evals for AI Agents — Anthropic Engineering
- Building Effective Agents — Anthropic Research
- LLM Evals: Everything You Need to Know — Hamel Husain
- Witan Labs Research Log — Witan Labs