‘환불 완료’라는 답변을 어떻게 검증할까: 상태·권한·중복 실행 평가
자연스러운 완료 문장과 실제 환불 상태를 나눠 검사한다. 성공률과 함께 권한 위반·중복 처리·성공당 비용을 확인하는 예제를 제시한다.

"환불 처리가 완료됐습니다"라는 답변을 받더라도 환불 레코드, 주문 소유자, 도구 호출 권한은 각각 따로 확인해야 한다. 에이전트는 여러 번 판단하고 도구를 호출하며 외부 상태를 바꾸기 때문에, 마지막 답변만 채점하면 실제로 수행한 작업이나 실패 지점을 놓치기 쉽다.
| 근거 | 확인할 것 |
|---|---|
| 실행 기록 | 도구 사용, 권한, 실행 경로 |
| 최종 환경 상태 | 요청한 상태 변화와 부작용 |
| 품질 비교 | 필수 조건 통과 결과 간 비교 |
실행 기록과 실제 환경 상태 구분
Anthropic은 에이전트 평가 단위를 작업(task), 시도(trial), 채점기(grader), 실행 기록(transcript), 결과(outcome)로 나눈다. 에이전트가 주고받은 대화와 호출 내역은 transcript이고, 데이터베이스에 반영된 실제 상태는 outcome이다.
prompt → response → gradertask
→ plan
→ tool selection
→ tool arguments
→ environment state change
→ observation
→ retry / recovery
→ final response평가 대상 7단계 구분
평가 단계를 세분화하면 성능이 떨어진 원인을 구체적으로 짚어낼 수 있다. 예를 들어 모델을 바꾼 뒤 작업 완료율은 그대로인데 도구 호출 횟수만 늘었다면, 경로 효율성(trajectory efficiency)이 퇴보했다는 뜻이다.

| 평가 층 | 질문 | 권장 grader |
|---|---|---|
| 1. Task completion | 사용자가 원한 상태가 실제로 생성되었는가 | 데이터베이스·API·파일 상태 검사 |
| 2. Tool selection | 상황에 맞는 도구를 선택했는가 | 허용 및 금지 도구 규칙 |
| 3. Tool arguments | 대상, 금액, 날짜, 권한 범위가 일치하는가 | 스키마 및 도메인 검증기 |
| 4. Trajectory | 불필요한 반복, 우회, 정책 위반이 없는가 | 추적 규칙 및 대형언어모델(LLM) 심사관 |
| 5. Final answer | 실행 결과를 정확하고 명확하게 전달했는가 | 기준(rubric) 기반 심사 |
| 6. Efficiency | 허용된 시간·토큰·비용 내에 완료되었는가 | 계측값 임계값 |
| 7. Escalation | 판단 불가 시 사람에게 이관했는가 | 정책 및 상태 기반 검사 |
최종 답변과 실제 결과 대조
최종 답변 평가도 여전히 필요하지만, 실제 실행 결과를 함께 입력받아 대조해야 한다. 답변만 보고 채점하면 실제로는 실패했으면서 성공한 것처럼 꾸민 문장에 높은 점수를 주게 된다.
완료한 작업과 미완료 작업의 구분 여부
주요 제약 사항이나 실패의 은폐 여부
실제 결과와 답변 내용의 일치 여부
사용자에게 요청하는 후속 행동의 명확성
문장이 얼마나 자연스러운지보다 실제 결과와의 일관성(outcome consistency)이 우선이다.
도구 선택과 인자 오류 분리
도구 호출의 성공과 실패를 이분법으로 단순화해서는 안 된다. 알맞은 도구를 골랐지만 인자를 잘못 넘긴 경우와 아예 위험한 도구를 선택한 경우는 해결 방법이 다르다. 스키마 검증은 형식 오류만 잡아내므로, 도메인 검증기와 환경 상태 검사를 함께 구성해야 한다.
| 행동 | 평가 | 원인 후보 |
|---|---|---|
| 환불 도구 대신 주문 조회만 반복 | 도구 선택 실패 | 도구 설명·라우팅·권한 인식 |
| 환불 도구에 다른 주문 번호 전달 | 인자(argument) 실패 | 개체 접지(grounding) 및 상태 추적 |
| 한도 초과 금액 무승인 환불 | 정책 실패 | 안전장치(guardrail) 및 이관 규칙 |
| 정상 환불 후 확인 조회 생략 | 검증 실패 | 실행 경로 설계 |
대안 경로 허용과 행동 검사
같은 결과에 도달하는 경로는 여러 가지이므로 특정 정답 경로만 강제하면 유효한 대안까지 실패로 처리할 위험이 있다.
실행 경로 평가기(trajectory grader)는 다음 항목을 확인한다.
금지된 도구나 데이터에 접근했는지 여부
근거 없이 같은 실패를 반복하는지 여부
되돌릴 수 없는 행동을 하기 전에 검증하고 확인했는지 여부
새로 관찰한 결과를 반영해 계획을 수정했는지 여부
충분한 근거를 확보했을 때 멈추는지 여부
실패한 뒤 안전한 상태로 복구했는지 여부
OpenAI의 실행 기록 평가(trace grading) 역시 에이전트 워크플로우 전체를 살펴 문제가 발생한 단계를 찾아내는 데 초점을 맞춘다.
필수 통과 조건과 품질 점수 분리
모든 평가 항목을 가중 평균하면 위험한 실패가 다른 점수에 가려질 수 있으므로, 엄격한 기준(hard gate)과 유연한 점수(soft score)로 나누어 평가한다.
필수 통과 조건
필수 결과 생성 여부
권한·개인정보·금액 정책 준수 여부
금지된 외부 행동이 없었는지 여부
필수 승인 절차 이행 여부
이 중 하나라도 충족하지 못하면 해당 시도는 전체를 실패로 처리한다.
품질 비교
필수 조건을 통과한 시도들을 대상으로 답변의 명확성, 불필요한 도구 호출 횟수, 지연 시간과 토큰 사용량, 근거 설명의 품질, 복구 경로의 효율성 등을 비교한다.
가상의 환불 과제에서 10,000원이 한 번만 환불되어야 한다고 해보자. 에이전트가 ‘환불 완료’라고 답했더라도 환불 레코드가 남지 않았다면 결과 실패다. 레코드가 두 개 생성됐다면 중복 실행 실패이고, 다른 사용자의 주문에 환불이 반영됐다면 금액이 맞아도 권한 실패다. 마지막 답변의 정확성뿐만 아니라 실제 상태, 대상, 실행 횟수를 각각 검사해야 한다.
모의 평가기에는 이 세 가지 잘못된 상태를 의도적으로 주입해 모두 거절하는지 시험한다. 반대로 올바른 결과를 거절하는 평가기도 문제이므로, 승인된 다른 도구 경로를 거쳐 같은 상태에 도달한 참조 실행은 통과시켜야 한다. 정답 도구 순서를 하나만 정해 외우게 하기보다 필요한 최종 상태와 금지 행동을 명시하는 편이 평가 범위를 설명하기 쉽다.
비용을 비교할 때도 기준 분모를 맞춰야 한다. 가상 구성 A가 100번 시도해 80번 성공하고 총비용 100단위를 썼다면 성공당 비용은 1.25단위다. B가 100번 중 90번 성공하면서 180단위를 썼다면 성공당 비용은 2단위다. B의 성공률이 높다고 해서 무조건 더 경제적이라고 할 수 없고, A의 총비용이 낮다고 해서 실패에 따른 비용을 무시할 수도 없다. 동일한 과제·권한·재시도 예산 아래에서 지표를 나란히 비교하고, 실제 업무의 실패 비용을 고려해 선택한다.
pass = outcome_ok
AND policy_ok
AND permission_ok
AND irreversible_action_ok
quality = 0.35 * answer_quality
+ 0.25 * trajectory_efficiency
+ 0.20 * citation_quality
+ 0.20 * recovery_quality코드 검사·모델 판정·사람 검토의 역할 분담
코드로 검사할 수 있는 항목은 먼저 처리하고, 주관적인 판단이 필요한 영역만 모델 평가기에 맡긴다. 모델 평가기에는 전체 점수를 매기게 하는 대신 근거성, 완전성, 정책 준수 여부 같은 세부 기준을 따로 평가하게 하고, 판단 근거가 부족할 때는 미확정(Unknown)을 반환하도록 설정한다.
| Grader | 잘하는 것 | 약점 |
|---|---|---|
| 코드 기반(Code-based) | 상태·형식·수치·정책 규칙 | 개방형 품질 판단의 한계 |
| 모델 평가기(LLM judge) | 설명 품질·근거성·경로 패턴 | 편향·비일관성·심사관 해킹(grader hacking) |
| 사람(Human) | 모호한 사례·제품 가치·심사관 보정 | 비용 및 속도 |
반복 실행을 통한 성공률 확인
같은 작업이라도 실행할 때마다 결과가 달라질 수 있으므로 1회만 수행해 얻은 점수는 신뢰하기 어렵다.
‘pass@k’는 k번 시도 중 1회 이상 성공할 확률로, 코드 생성 과제를 평가할 때 유용하다. 반면 ‘pass^k’는 k번 모두 성공할 확률이며, 높은 신뢰성이 필요한 업무 자동화 평가에 적합하다.
각 시도가 서로 독립적이고 성공 확률이 모두 75%라면, 세 번 연속 성공할 확률은 0.75³ ≈ 42%다. 만약 독립 시행과 동일 성공 확률이라는 가정이 맞지 않으면 단순히 세제곱해 계산할 수 없다.
개별 실행의 성공률과 연속 실행의 신뢰성은 구분해서 측정해야 하며, 모델을 비교할 때는 시도 횟수, 재시도 정책, 토큰 예산, 제한 시간(timeout)을 동일하게 고정해야 한다.
실제 실패 사례 기반 평가셋 구축
처음부터 수백 개 규모의 벤치마크를 만들 필요는 없다. Anthropic은 실제 실패 사례에서 추려낸 20~50개의 작업으로 시작할 것을 제안한다.
평가셋 구성 순서
프로덕션에서 발생한 실패를 수집해 재현 가능한 작업으로 변환
초기 환경(데이터베이스, 파일, 권한, 시간) 고정
성공 결과 정의
반대 사례(도구를 사용할 필요가 없는 경우 등) 포함
참조 솔루션을 실행해 평가셋 검증
반복 실행을 통해 결과 분산 확인
실패 원인을 추적해 에이전트 오류와 평가기 오류 구분
개선 과제와 회귀 방지 과제 분리
역량 평가(Capability eval)는 에이전트의 한계를 파악하기 위해 어려운 작업을 대상으로 수행한다. 회귀 평가(Regression eval)는 기존 기능을 안정적으로 유지하는지 확인하는 용도이므로 통과율이 100%에 가까워야 한다. 역량 평가 과제의 성공률이 충분히 높아지면 회귀 평가셋으로 옮긴다.
에이전트 평가에서 흔히 겪는 실패 요인
최종 문장만 채점
출력된 답변만 평가해서는 외부 상태가 제대로 바뀌었는지 검증할 수 없다.
정답 경로 강제
유효한 우회 경로까지 실패로 처리하게 된다.
모델 평가기 맹신
사람의 평가와 얼마나 일치하는지 측정하고, 코드로 확인할 수 있는 항목은 코드 검사기로 넘겨야 한다.
쉬운 작업만 유지
이미 점수가 포화된 평가는 다음 개선 방향을 알려주지 못한다.
하니스(harness) 변경 미기록
모델뿐만 아니라 하니스와 환경 요소의 변경 사항도 함께 기록해야 한다.
비용과 성공을 분리해 해석
자원을 과도하게 소모하는 시스템은 제품 관점에서 불리할 수 있다.
배포 게이트 연동
평가가 단순 리포트로만 끝나면 개발 속도를 높일 수 없다. 위험도에 따라 배포 게이트를 다르게 적용해야 한다.
정책·권한·금액 관련 엄격한 기준(hard gate): 회귀 발생 시 배포 중단
작업 완료: 기준선 이하이면 배포 중단
지연 시간 및 비용: 예산 초과 시 검토
자동 평가와 프로덕션 모니터링은 함께 운영해야 한다.
production failure
→ eval task 추가
→ prompt / tool / harness 변경
→ regression suite
→ capability suite
→ trace sample review
→ canary deployment
→ production monitoring상태를 검사할 수 있는 과제부터 시작하기
처음에는 실제 실패 사례에서 뽑은 과제에 성공 상태와 금지 행동을 정의한다. 깨끗한 환경에서 반복 실행하며 도구 선택, 인자, 권한, 최종 상태를 각각 따로 기록한다.
필수 조건을 통과한 결과들만 모아 답변 품질과 지연 시간, 비용을 비교한다. 실패 원인이 에이전트에 있는지 평가기에 있는지 확인한 뒤 회귀 검사에 반영해야, 평가 점수가 다음 배포 여부를 결정하는 실질적인 근거가 된다.
참고: Anthropic — Demystifying evals for AI agents (https://www.anthropic.com/engineering/demystifying-evals-for-ai-agents (새 창)) · OpenAI — Trace grading and Evals (https://openai.com/index/introducing-agentkit/ (새 창)) · OpenAI — How evals drive the next chapter in AI (https://openai.com/index/evals-drive-next-chapter-of-ai/ (새 창)) · OpenAI — A shared playbook for trustworthy evaluations (https://openai.com/index/trustworthy-third-party-evaluations-foundations/ (새 창))
참고 자료
Demystifying evals for AI agents — Anthropic (https://www.anthropic.com/engineering/demystifying-evals-for-ai-agents (새 창))
Introducing AgentKit: trace grading and Evals — OpenAI (https://openai.com/index/introducing-agentkit/ (새 창))

