목차
이 글은 Anthropic 엔지니어링 블로그에 2026년 1월 9일 게재된 “Demystifying evals for AI agents” 를 읽고, 내용을 정리한 글입니다. 원문: https://www.anthropic.com/engineering/demystifying-evals-for-ai-agents
한 줄로 말하면 #
평가 없이 에이전트를 운영하면 사고만 잡으러 다니게 된다. 20~50개 작은 평가셋부터, 그리고 트랜스크립트를 읽어라.
어떤 문제를 해결하려 했나 #
평가 없이 에이전트를 운영하는 팀이 흔히 빠지는 흐름:
사용자 신고 → 임시 수정 → 며칠 후 다른 부분에서 비슷한 문제 → 또 수정 → 회귀…
반응적 디버깅 루프. 원문 인용: “좋은 평가는 팀이 에이전트를 자신 있게 출시하게 한다. 평가가 없으면 운영에서 문제 잡으러 다니는 반응적 루프에 갇힌다.”
그런데 단일 응답 LLM 평가와 에이전트 평가는 본질이 다릅니다. 에이전트는 여러 턴 + 도구 호출 + 상태 변경이 누적되니, 정적인 입력·출력 비교로는 못 잡습니다.
해결책: 에이전트 평가의 핵심 부품과 설계법 #
1. 평가의 구성 요소 #
| 요소 | 의미 |
|---|---|
| Task(과제) | 입력 + 성공 기준 한 묶음 |
| Trial(시도) | 한 번 실행 (비결정성 때문에 여러 번 필요) |
| Grader(채점기) | 결과 점수 매기는 로직 (여러 개 조합 가능) |
| Transcript(트랜스크립트) | 도구 호출·추론·중간 결과 전체 기록 |
| Outcome(결과 상태) | 작업 후 환경의 최종 상태 |
2. 세 가지 채점기 #
| 채점기 | 강점 | 약점 |
|---|---|---|
| 코드 기반 (문자열 매칭, 단위 테스트) | 빠르고 객관적, 재현 가능 | 유효한 변형에 부서지기 쉬움 |
| 모델 기반 (LLM-as-judge, 루브릭) | 유연·확장 가능 | 비결정적, 사람 보정 필요 |
| 사람 기반 | 골드 스탠다드 | 비싸고 느림 |
핵심은 세 가지를 섞어 쓰는 것. 한 층이 놓친 실패를 다른 층이 잡습니다.
3. 비결정성 측정: pass@k vs pass^k #
에이전트는 같은 입력에도 결과가 흔들립니다. 그래서 두 지표를 같이 봅니다.
- pass@k: k번 중 한 번이라도 성공할 확률 (능력 측정)
- pass^k: k번 모두 성공할 확률 (신뢰성 측정)
k가 커지면 둘 사이 격차가 벌어집니다. pass@5는 100%에 가까운데 pass^5는 급격히 떨어지면 “가끔 잘하지만 일관성 없다” 는 신호예요.
흔한 평가 설계 실패 #
원문이 강조한 인상적인 사례. Opus 4.5가 CORE-Bench에서 처음에 42% 점수를 받았는데, 알고 보니:
- 채점기가 너무 엄격 — “96.12"를 정답 “96.124991"이 아니라고 reject
- 과제 명세가 모호 — 에이전트가 잘못된 게 아닌데 떨어짐
- 확률적 과제를 단일 정답으로 채점
평가를 고치자 점수가 42% → 95% 로 뛰었습니다. 모델이 부족했던 게 아니라 평가가 부족했던 거죠.
| 흔한 실패 | 처방 |
|---|---|
| 모호한 과제 명세 | 도메인 전문가 2명이 독립적으로 같은 판정 내는지 확인 |
| 경직된 채점 | 유효한 변형(예: 반올림 차이) 허용 |
| 클래스 불균형 | “X를 해야 할 때” 와 “X를 하면 안 될 때” 둘 다 평가 |
| 시도 간 상태 공유 | 매 시도마다 깨끗한 환경 |
| 채점기 자체 버그 | 트랜스크립트를 사람이 직접 읽어 검증 |
실무 로드맵 #
- 20~50개 작은 평가셋부터 — 실제 사고와 신고에서 뽑기
- 참조 솔루션 작성 — “이게 풀린다는 증거” 확보
- 균형 잡힌 문제 셋 — 행동 유무 양쪽 검사
- 격리된 환경 — 시도 간 노이즈 차단
- 트랜스크립트 정기 읽기 — 채점기가 진짜 중요한 걸 재는지 확인
- 포화 감시 — 통과율 100%에 가까워지면 더 어려운 과제로 교체
- 소유권 명확화 — 평가셋도 살아있는 산출물로 관리
핵심 인용: “트랜스크립트를 읽는 것이, 평가가 진짜 의미 있는 걸 재는지 확인하는 유일한 방법이다.”
핵심 결론 #
에이전트 품질을 올리고 싶을 때 사람들은 “더 좋은 프롬프트·모델"을 본능적으로 떠올립니다. 이 글의 답은 다릅니다.
“품질이 문제인 줄 알았는데, 사실은 무엇이 좋은지 잴 방법이 없는 게 문제였다.”
평가는 부수 작업이 아니라 에이전트 개발의 핵심 부품입니다. 가치는 누적되지만, “평가를 부속이 아니라 본체로 다룰 때만” 가능합니다.
내 작업에 적용한다면 #
시나리오 1 — 일반적인 데이터 분석 과정 #
분석에서도 평가가 빠지면 같은 실수를 반복합니다. “이번엔 잘 나왔네” 하는 자가 점검만으론 부족해요.
[Before — 분석 평가 없음]
새 분석 끝낼 때마다 "결과가 그럴듯하네" 확인
→ 같은 종류 실수 반복
[demystifying evals 적용]
[과거 실수를 평가셋으로]
- 예전에 잘못된 결과를 냈던 분석 케이스 20~50개 모으기
- 각 케이스에 "이래야 한다"는 기대 결과 정의
[세 가지 채점기 조합]
- 코드: 수치 정확성·범위 체크
- 모델: 해석의 합리성 LLM-as-judge
- 사람: 핵심 비즈니스 결정에는 도메인 전문가 검토
[균형 테스트]
- "이상치 잡아야 할 때" + "잡으면 안 될 때" 둘 다 평가
[트랜스크립트 읽기]
- 분석 자동화 로그를 정기적으로 사람이 직접 훑어보기핵심: 분석 품질의 향상은 “통과 기준을 명확히 한 평가셋” 위에서만 일어납니다.
시나리오 2 — 웹 사이트를 자동으로 운영할 때 #
운영 자동화도 평가 없이 굴리면 사일런트 실패가 누적됩니다.
[Before — 운영 평가 없음]
콘텐츠 자동 발행이 "별일 없이 돌아가면 OK"
→ 가끔 톤 이상한 글, SEO 누락, 링크 깨짐
[demystifying evals 적용]
[운영 평가셋]
- 과거 사고 사례 20~50건을 평가 과제로 변환
- "톤 가이드 위반 글", "잘못된 메타", "롤백 실패 상황" 등
[세 채점기 조합]
- 코드: 메타 태그·링크 유효성·빌드 상태 자동 체크
- 모델: 톤·맥락 적절성 LLM-as-judge
- 사람: 법적 리스크 있는 콘텐츠는 사람 리뷰
[pass^k 측정]
- 발행 작업을 5번 반복했을 때 모두 통과하는지
- "한 번 잘되지만 가끔 망함"이 가장 위험한 패턴
[트랜스크립트 정기 검토]
- 운영 자동화 로그를 주간 단위로 사람이 직접 읽기핵심: 운영 자동화의 신뢰성은 “사고를 평가셋으로 박제하는 습관” 에서 옵니다. 같은 사고가 또 나지 않게 하는 가장 확실한 방법이에요.
Anthropic 엔지니어링 블로그를 오래된 순서대로 읽고 정리합니다.
