AI 에이전트를 만들었는데 제대로 작동하는지 어떻게 확인하시나요? 수동으로 몇 번 테스트해보고 “괜찮네” 하고 넘어가셨다면, 나중에 큰 문제를 만날 수 있습니다. 사용자가 “예전보다 못하다”고 불평하는데 뭐가 잘못됐는지 알 방법이 없는 상황 말이죠.
Anthropic이 Claude Code, Claude for Chrome 같은 AI 에이전트 제품을 개발하며 배운 평가(evaluation) 노하우를 엔지니어링 블로그에 공개했습니다. 단순 LLM과 달리 에이전트는 여러 턴에 걸쳐 도구를 쓰고 상태를 바꾸기 때문에 평가가 훨씬 복잡한데, 이를 어떻게 체계적으로 해결할지에 대한 실전 가이드입니다.
Anthropic의 엔지니어링 팀이 내부 개발과 고객사 협업을 통해 축적한 AI 에이전트 평가 방법론을 정리한 글입니다. 에이전트 유형별(코딩, 대화형, 리서치, 컴퓨터 사용) 구체적인 평가 전략과 20-50개 태스크로 시작하는 실전 로드맵을 제시하며, “평가 시스템을 일찍 만들수록 개발이 빨라진다”는 역설적이지만 검증된 원칙을 강조합니다.
출처: Demystifying evals for AI agents – Anthropic
에이전트 평가는 왜 어려운가
일반적인 LLM 평가는 간단합니다. 프롬프트 하나 주고 답변 하나 받아서 채점하면 끝이죠. 하지만 에이전트는 다릅니다. 여러 턴에 걸쳐 도구를 호출하고, 중간 결과를 보며 전략을 바꾸고, 환경의 상태를 수정합니다. 실수가 누적되고 증폭될 수 있어요.
더 복잡한 건 에이전트의 창의성입니다. Anthropic의 Opus 4.5는 τ2-bench 평가에서 항공권 예약 문제를 풀 때 정책의 허점을 발견해 더 나은 해결책을 제시했습니다. 평가 기준으로는 “실패”했지만 실제로는 사용자에게 더 좋은 결과를 준 거죠. 정해진 답만 체크하는 방식으론 이런 경우를 놓칩니다.
많은 팀들이 초기엔 수동 테스트와 직감으로 버티다가, 프로덕션에 배포한 후 문제가 터지면서야 평가 시스템의 필요성을 깨닫습니다. 하지만 그때는 이미 늦었어요. 뭐가 잘못됐는지 알 방법이 없고, 한 버그를 고치면 다른 게 망가지는 악순환에 빠집니다.
에이전트 유형별 평가 전략
Anthropic은 에이전트 유형에 따라 다른 평가 방식이 필요하다고 강조합니다.
코딩 에이전트는 가장 평가하기 쉽습니다. 코드는 실행하면 되거든요. SWE-bench Verified나 Terminal-Bench 같은 벤치마크는 GitHub 이슈를 주고 테스트 통과 여부로 채점합니다. 단위 테스트가 통과하면 성공, 실패하면 실패. 명확하죠. 실제로 LLM은 1년 사이에 SWE-bench Verified에서 40%에서 80% 이상으로 성능이 급상승했습니다. 여기에 코드 품질 체크나 보안 검사 같은 추가 평가를 더할 수 있고요.
대화형 에이전트는 좀 더 복잡합니다. 고객 지원 에이전트를 생각해보세요. 환불 처리가 됐는지(상태 체크), 10턴 이내에 끝났는지(효율성), 고객에게 공감을 표현했는지(품질)를 모두 봐야 합니다. τ-Bench와 그 후속작인 τ2-Bench 같은 벤치마크는 한 모델이 사용자 역할을 하고 에이전트가 상황을 해결하는 방식으로 대화를 시뮬레이션합니다.
리서치 에이전트는 가장 주관적입니다. “포괄적”이나 “잘 정리된”의 기준이 사람마다 다르고, 참고 자료가 계속 바뀌거든요. 여기선 출처 검증(주장이 검색한 자료로 뒷받침되는가), 커버리지 체크(핵심 사실이 빠지지 않았나), 출처 품질(권위 있는 자료를 썼나)을 조합합니다. LLM 기반 채점을 쓰되, 전문가 판단으로 자주 보정해야 합니다.
컴퓨터 사용 에이전트는 실제 소프트웨어를 사람처럼 조작합니다. 스크린샷 보고 클릭하고 타이핑하는 방식이죠. WebArena는 브라우저 작업을, OSWorld는 운영체제 전체를 테스트합니다. 환경 상태를 확인해야 하는데, 예를 들어 주문 확인 페이지가 뜬 게 아니라 실제로 데이터베이스에 주문이 기록됐는지 봐야 합니다. Anthropic은 Claude for Chrome을 개발하면서 에이전트가 상황에 맞는 도구를 선택하는지(위키피디아 요약은 DOM 추출, 아마존 검색은 스크린샷) 평가했다고 합니다.
0에서 1까지, 실전 로드맵
Anthropic이 제안하는 가장 중요한 원칙은 “일찍 시작하라”입니다. 수백 개 태스크가 필요하다고 생각해 미루는 팀이 많은데, 실제로는 20-50개 실제 실패 사례만 모아도 충분합니다. 초기엔 작은 변화도 큰 영향을 주니까요.
시작은 이미 수동으로 테스트하는 것들부터입니다. 릴리스 전에 확인하는 동작, 버그 트래커의 이슈, 고객 지원 티켓을 태스크로 만드세요. 각 태스크는 명확해야 합니다. 두 전문가가 독립적으로 같은 판정을 내릴 수 있을 정도로요. 모호하면 노이즈가 됩니다.
채점 방식(grader)은 세 가지를 섞어 씁니다. 코드 기반 채점(문자열 매칭, 단위 테스트)은 빠르고 객관적이지만 융통성이 없습니다. 모델 기반 채점(LLM이 루브릭으로 평가)은 유연하지만 보정이 필요해요. 사람 채점은 골드 스탠다드지만 비싸고 느립니다. 상황에 맞게 조합하는 게 핵심입니다.
그리고 트랜스크립트를 읽으세요. 실제 에이전트가 한 행동을 보지 않으면 채점 시스템이 제대로 작동하는지 알 수 없습니다. Anthropic은 트랜스크립트를 보는 도구에 투자했고, 정기적으로 읽는다고 합니다. 실패가 공정해 보이는지, 에이전트가 정말 잘못했는지 확인하는 유일한 방법이거든요.
한 가지 재미있는 개념은 pass@k와 pass^k입니다. pass@k는 k번 시도 중 최소 한 번은 성공할 확률이고, pass^k는 k번 모두 성공할 확률입니다. k가 늘어날수록 pass@k는 올라가고 pass^k는 떨어집니다. 예를 들어 성공률이 75%인 에이전트를 3번 돌리면, 적어도 한 번 성공할 확률은 높지만 세 번 모두 성공할 확률은 (0.75)³ ≈ 42%로 떨어지죠. 한 번만 맞아도 되는 코딩 작업엔 pass@k가, 매번 일관되게 작동해야 하는 고객 응대엔 pass^k가 중요합니다.
평가만으론 부족하다
자동화된 평가는 강력하지만 전부가 아닙니다. Anthropic은 “스위스 치즈 모델”을 제시합니다. 여러 층의 구멍 뚫린 치즈처럼, 한 방법이 놓친 문제를 다른 방법이 잡아낸다는 거죠.
자동화 평가는 개발 중에 빠른 피드백을 주고, 프로덕션 모니터링은 실제 사용 패턴에서 문제를 찾아내고, A/B 테스트는 변경 사항의 실제 영향을 측정합니다. 사용자 피드백은 예상 못한 문제를 알려주고, 트랜스크립트 리뷰는 미묘한 품질 이슈를 잡아냅니다. 이들을 조합해야 완전한 그림이 나옵니다.
또 하나 중요한 건 평가가 “살아있는” 시스템이라는 점입니다. 에이전트가 발전하면 평가도 함께 진화해야 합니다. 100% 통과율이 된 평가는 더 이상 개선 신호를 주지 않으니 어려운 태스크를 추가해야 하고요. 제품 팀이 평가를 소유하고 유지보수하는 문화가 필요합니다.
Anthropic이 강조하는 핵심은 이겁니다. 평가 없이는 반응적 루프에 갇혀 한 실패를 고치면 다른 게 망가지고, 진짜 문제와 노이즈를 구분 못 합니다. 하지만 초기에 투자하면 개발이 가속화됩니다. 실패가 테스트 케이스가 되고, 테스트가 회귀를 막고, 메트릭이 추측을 대체하죠.
AI 에이전트 시대에 “품질”을 어떻게 정의하고 측정할지는 이제 핵심 경쟁력입니다. 이 가이드가 그 출발점이 될 수 있습니다.
참고자료:
답글 남기기