AI 에이전트 evals 해부하기

좋은 evals는 AI 에이전트를 운영 환경에 올리기 전에 문제와 행동 변화를 드러내 준다. 에이전트는 여러 턴에 걸쳐 tool calls를 하고 상태를 바꾸며 적응하기 때문에, 단순한 single-turn 테스트보다 훨씬 정교한 평가가 필요하다.

평가를 설계할 때는 용어부터 분명히 해야 한다.

• task: 입력과 성공 기준이 정해진 하나의 테스트
• trial: 같은 task를 한 번 시도한 실행
• grader: transcript나 outcome의 일부를 채점하는 로직
• transcript: reasoning, tool calls, 중간 결과까지 포함한 전체 기록
• outcome: 환경에 실제로 남은 최종 상태
• evaluation harness: eval을 끝까지 실행하고 기록·집계하는 인프라
• agent harness: 모델이 에이전트처럼 행동하도록 orchestrate하는 시스템
• evaluation suite: 비슷한 목적의 task 묶음

에이전트 평가에서는 code-based, model-based, human grader를 조합하는 경우가 많다. 코드 기반 grader는 빠르고 재현 가능하지만 경직될 수 있고, model-based grader는 유연하지만 비결정적이며 인간 채점으로 보정이 필요하다. 인간 grader는 가장 신뢰할 만하지만 느리고 비싸서, 보통 표본 점검이나 기준 정렬에 쓰인다.

평가는 크게 두 종류로 나뉜다. capability evals는 "무엇을 잘할 수 있는가"를 보며 처음엔 통과율이 낮아도 된다. 반면 regression evals는 "예전에 되던 것이 아직도 되나"를 보므로 거의 100%에 가까운 안정성이 필요하다.

실전에서는 coding agent, research agent, computer use agent, conversational agent처럼 서로 다른 형태의 에이전트도 비슷한 원리로 평가할 수 있다. 특히 coding agents는 테스트가 명확해서 deterministic grader가 잘 맞고, SWE-bench Verified나 Terminal-Bench처럼 실제 코드 실행과 테스트 통과 여부로 판정하는 방식이 유효하다. 다만 통과 여부만 보면 부족하므로, 코드 품질이나 tool 사용 방식은 LLM rubric이나 transcript 기반 규칙으로 추가 채점한다.

예시로, 인증 우회 취약점을 고치는 태스크는 unit test, static analysis, state check, tool call verification, LLM rubric을 함께 묶어 평가할 수 있다. 이처럼 outcome 검증과 transcript 검증을 같이 써야 에이전트의 실제 동작과 품질을 동시에 볼 수 있다.

이 접근은 Claude Code나 Descript, Bolt처럼 실제 제품을 운영하는 팀에서도 중요하다. evals가 있으면 사용자 불만에만 의존하지 않고, 모델 업그레이드 속도, latency, token usage, cost per task, error rate까지 정량적으로 관리할 수 있다. 결국 evals는 단순한 테스트가 아니라, 에이전트 개발과 개선을 계속 밀어주는 기준선이 된다.