AI 에이전트 평가표 만드는 법: 정확도보다 작업 성공률을 먼저 보세요

에이전트를 처음 만들 때는 한두 번의 성공이 크게 보인다. 문의를 분류하고, 코드를 수정하고, 리서치 초안을 만드는 장면이 데모에서 잘 나오면 팀은 곧바로 실무 투입을 생각한다. 그런데 실제 업무에는 빈 입력, 모순된 문서, 오래된 정책, 권한 오류, 애매한 요청이 들어온다.

이때 필요한 것은 더 강한 프롬프트가 아니다. 어떤 결과를 성공으로 볼지 먼저 고정하는 평가 설계다. 평가가 없으면 모델을 바꿔도 좋아졌는지 모른다. 도구를 추가해도 실패 원인을 알 수 없다.

정확도 하나로는 왜 부족한가?

정확도는 업무에 따라 의미가 다르다. 고객 문의 분류에서는 분류값이 맞는 것뿐 아니라 담당자에게 제대로 전달되어야 한다. 코딩 에이전트에서는 코드가 컴파일되는 것뿐 아니라 요구사항을 지키고 테스트를 통과해야 한다. 리서치 에이전트에서는 문장이 자연스러운 것보다 주장마다 출처가 붙어 있는지가 중요하다.

나쁜 평가 질문	바꿔야 할 질문
답변이 자연스러운가?	필수 사실과 근거를 빠뜨리지 않았고, 다음 담당자가 바로 처리할 수 있는가?
자동화율이 높은가?	완료 조건을 통과한 작업의 비율이 높고 사람이 되돌리는 시간이 줄었는가?
모델 점수가 높은가?	실패했을 때 위험 행동을 시도하지 않고 적절히 사람에게 넘겼는가?
한 번 성공했는가?	대표 데이터와 예외 데이터에서 같은 기준을 반복해서 통과하는가?

AI 에이전트 평가의 5가지 구성요소

1. 업무 단위

평가 대상의 시작과 끝을 정한다. "영업을 자동화한다"는 업무 단위가 아니다. "새 웹 문의를 분류하고, 최근 정책 문서에서 근거를 찾아 답변 초안을 담당자 큐에 넣는다"처럼 하나의 실행으로 나눠야 한다.

2. 대표 데이터셋

최근 정상 사례만 모으지 않는다. 정상·빈 값·오타·중복·정책 충돌·권한 부족·악의적인 입력을 함께 넣는다. 실제 개인정보는 익명화하고, 테스트 데이터에 원본 고객 정보가 들어가지 않도록 한다.

3. 성공 조건과 실패 조건

필수 필드, 근거 링크, 금지 행동, 승인 라우팅, 오류 메시지, 중단 조건을 체크리스트로 적는다. 성공 조건이 없는 평가는 사람마다 다른 감상을 점수처럼 기록하는 것에 가깝다.

4. 채점 방식

정확한 값은 코드로 비교하고, 문장 품질은 사람 또는 별도 채점 모델로 평가할 수 있다. 채점 모델을 쓸 때도 무엇을 근거로 점수를 줬는지와 사람 검수 샘플을 함께 보관한다.

5. 실행 trace

최종 답변만 보면 원인을 알 수 없다. 어떤 도구를 불렀는지, 어떤 문서를 읽었는지, 어디에서 재시도했는지, 왜 사람에게 넘겼는지 기록해야 한다. OpenAI의 trace grading 문서처럼 실행 흐름을 채점 단위로 보는 접근이 필요한 이유다.

업무별 평가표 예시

업무	필수 성공 조건	위험 실패	사람 검수 포인트
고객 문의 분류	유형·우선순위·담당 큐·근거가 존재한다.	환불·법무 문의를 일반 문의로 보내는 것	라우팅이 맞고 답변 초안이 정책을 넘지 않는지
코딩 에이전트	요구사항·테스트·변경 범위·PR 설명이 맞는다.	테스트를 지우거나 보안 검사를 우회하는 것	diff가 작고 필요한 테스트를 추가했는지
리서치 브리프	주장별 출처·기준일·불확실성·다음 질문이 있다.	출처가 주장과 맞지 않거나 오래된 수치를 단정하는 것	핵심 결론이 원문을 과장하지 않는지

작업 성공률과 함께 볼 지표

• 작업 성공률: 모든 필수 조건을 통과한 실행 비율
• 근거 완성도: 주장이나 결과마다 필요한 근거가 붙은 비율
• 에스컬레이션 적중률: 실제로 사람이 봐야 하는 건을 제대로 넘긴 비율
• 재작업시간: 에이전트 결과를 사람이 고쳐 완료하는 데 든 시간
• 단위 비용: 모델·도구·사람 시간을 합친 완료 작업 한 건의 비용
• 위험 행동 시도율: 금지된 도구 호출이나 외부 행동을 시도한 비율
• 지연시간: 실행 시작부터 사람이 승인할 수 있는 결과가 나올 때까지의 시간

자동화율은 보조 지표로 둔다. 결과의 90%를 자동으로 만들었지만 사람이 10%를 되돌리느라 더 오래 걸리면 업무는 빨라진 것이 아니다.

2주 평가 파일럿은 어떻게 구성할까?

1. 1일차: 하나의 업무 단위를 고르고 완료 조건을 5~10개로 쪼갠다.
2. 2~3일차: 정상 20건과 예외 10건을 익명화해 기준 데이터셋을 만든다.
3. 4~5일차: 수동 기준 결과를 만들고 코드 비교·사람 채점·모델 채점의 역할을 나눈다.
4. 6~8일차: 에이전트 실행 trace를 저장하고 실패 유형을 분류한다.
5. 9~11일차: 작업 계약·도구 권한·중단 조건을 고친 뒤 같은 데이터로 재실행한다.
6. 12~14일차: 성공률뿐 아니라 재작업시간·비용·위험 행동 시도율을 비교해 다음 범위를 결정한다.

평가가 실패하는 5가지 패턴

1. 쉬운 사례만 넣는다. 실제 실패를 담지 않은 데이터셋은 데모를 반복할 뿐이다.
2. LLM 채점 하나를 정답처럼 믿는다. 채점 기준을 명시하고 일부는 사람이 확인해야 한다.
3. 최종 답변만 저장한다. trace가 없으면 잘못된 도구 호출과 근거 선택을 고칠 수 없다.
4. 점수를 높이려고 기준을 바꾼다. 데이터셋과 성공 기준은 변경 이력과 함께 관리한다.
5. 배포 후 평가를 멈춘다. 정책·웹페이지·도구가 바뀌면 회귀 평가를 다시 돌린다.

평가 데이터와 보안

• 실제 고객 데이터 대신 익명화·합성 데이터를 우선 사용한다.
• 평가 결과에 이메일·주민번호·계약서 원문이 남지 않도록 필터링한다.
• 채점 모델에 민감한 원문을 보낼 때 데이터 보존·접근 정책을 확인한다.
• 실패 trace에 포함된 도구 토큰과 내부 URL을 마스킹한다.
• 점수와 함께 평가셋 버전·모델 버전·도구 버전·프롬프트 버전을 기록한다.

Anthropic은 성공 기준을 먼저 정의하고 평가를 개발하는 흐름을 안내하고, OpenAI는 evals와 trace grading을 별도 문서로 설명한다. 제품 문서가 제공하는 기능을 그대로 가져오는 것보다, 우리 업무의 완료 조건을 먼저 써야 평가가 실제 개선으로 이어진다.

LeanX는 에이전트 구축보다 먼저 평가표를 만듭니다. 어떤 일을 맡길지, 성공을 어떻게 정의할지, 실패했을 때 누가 멈출지를 정하면 2주 파일럿의 결과가 선명해집니다. AX 진단으로 첫 평가 대상을 정해보세요.

공식 참고자료

• OpenAI Working with evals
• OpenAI Trace grading
• Anthropic Define success criteria and build evaluations
• NIST AI Risk Management Framework