AI agent success rate는 에이전트가 한 번 멋진 답변을 했는지가 아니라, 주어진 작업을 끝까지 제대로 완료했는지를 보는 지표입니다. 에이전트는 답변 생성뿐 아니라 도구 호출, 상태 관리, 재시도, 사용자 확인까지 포함하기 때문입니다.
핵심은 답변 품질 평가와 작업 완료 평가를 분리하는 것입니다. 문장은 좋아 보여도 파일을 잘못 수정하거나, 도구를 틀리게 호출하거나, 중간에 멈추면 성공한 작업이 아닙니다.
왜 답변 점수만으로 부족할까
챗봇 평가는 최종 답변만 보면 어느 정도 판단할 수 있습니다. 하지만 에이전트는 중간 행동이 많습니다. 검색하고, 파일을 읽고, 코드를 고치고, 테스트를 돌리고, 결과를 보고합니다. 마지막 문장이 자연스러워도 중간 행동이 틀리면 실패입니다.
- 도구를 잘못 골랐다
- 필요한 파일을 읽지 않았다
- 수정은 했지만 테스트를 돌리지 않았다
- 사용자 승인이 필요한 작업을 그냥 진행했다
- 실패했는데 성공한 것처럼 보고했다
AI agent success rate를 위해 task success를 먼저 정의한다
success rate를 측정하려면 먼저 성공 조건을 써야 합니다. 성공 조건이 없으면 평가자는 매번 다른 기준으로 판단하게 됩니다.
작업: WordPress draft 생성
성공 조건:
- brief, factpack, article_package가 생성됐다
- validator를 통과했다
- WordPress draft가 생성됐다
- preview_url, link, edit_url을 모두 보고했다
- publish는 실행하지 않았다이렇게 성공 조건을 구체화하면 단순히 ‘잘 썼다’가 아니라 작업이 완료됐는지 판단할 수 있습니다.
tool call accuracy를 따로 본다
에이전트의 큰 실패는 도구 선택에서 자주 나옵니다. 읽기 도구를 써야 하는데 쓰기 도구를 쓰거나, 승인 후에만 가능한 도구를 먼저 호출하는 식입니다. 그래서 tool call accuracy는 별도 지표로 보는 것이 좋습니다.
- 필요한 도구를 호출했는가
- 호출 순서가 맞았는가
- 인자가 정확했는가
- 부작용 있는 도구에 승인 조건을 지켰는가
- 도구 실패 후 복구 행동이 적절했는가
retry count와 recovery rate
한 번에 성공하지 못해도 복구해서 끝내는 에이전트는 실무에서 가치가 있습니다. 다만 retry가 너무 많으면 비용과 시간이 커지고, 같은 실패를 반복한다면 품질 문제가 됩니다.
따라서 retry count, recovered success rate, repeated failure rate를 함께 보면 좋습니다. 성공률만 보면 느리고 불안정한 에이전트도 좋아 보일 수 있습니다.
human handoff를 실패로만 보면 안 된다
일부 작업은 사용자의 승인이나 판단이 필요합니다. 이때 handoff는 실패가 아니라 안전한 중단일 수 있습니다. 예를 들어 publish 승인, 결제, 삭제, 개인정보 접근은 에이전트가 멈추고 확인해야 합니다.
- 필수 승인 요청: 정상 handoff
- 정보 부족으로 질문: 조건부 정상
- 스스로 해결할 수 있는데 질문만 반복: 품질 문제
- 승인 없이 진행: 안전 실패
작은 regression test 세트를 만든다
에이전트 프롬프트나 도구 설명을 고쳤다면 이전보다 좋아졌는지 비교해야 합니다. 이를 위해 자주 들어오는 작업 20~50개 정도를 작은 평가셋으로 만들어 두는 것이 좋습니다.
- 대표 작업을 고른다
- 각 작업의 성공 조건을 쓴다
- 필수 도구 호출과 금지 행동을 표시한다
- 변경 전후 success rate를 비교한다
- 실패 로그를 유형별로 묶는다
지표 예시
{
"task_success_rate": 0.82,
"tool_call_accuracy": 0.91,
"avg_retry_count": 1.4,
"recovered_success_rate": 0.63,
"unsafe_action_rate": 0.0,
"human_handoff_rate": 0.18
}이 지표들은 단독으로 보지 말고 같이 봐야 합니다. success rate가 높아도 unsafe action rate가 높으면 운영에 넣기 어렵습니다. 반대로 handoff rate가 높아도 민감 작업에서만 발생한다면 오히려 안전한 설계일 수 있습니다.
LLM judge를 쓸 때의 주의점
LLM judge는 로그를 빠르게 분류하는 데 도움이 될 수 있지만 최종 진실은 아닙니다. 작업 성공 여부가 파일 생성, 테스트 통과, HTTP 200처럼 객관적으로 확인 가능한 경우에는 자동 측정값을 우선해야 합니다.
정리
AI agent success rate는 답변 하나의 점수가 아니라 작업 완료율입니다. task success, tool call accuracy, retry, recovery, handoff, 안전 실패를 나눠 봐야 실제 운영 품질이 보입니다.
평가 체계는 OpenAI Evals 문서를 기준으로 시작할 수 있습니다. 자동 평가의 한계는 LLM judge 글과 함께 보면 좋습니다.
