에이전트 평가 체계 만들기: trace grading으로 회귀를 잡는 운영 루틴

에이전트를 붙인 서비스가 일정 규모를 넘기면 가장 먼저 듣는 말이 있습니다. “어제는 되던 게 오늘은 왜 안 되죠?” 문제는 모델이 틀렸다는 사실 자체가 아닙니다. 어떤 변경이 어떤 회귀를 만들었는지 설명할 수 없다는 점입니다. OpenAI의 agent evals 가이드는 이 지점을 정확히 짚습니다. 핵심은 프롬프트 한 줄 바꿀 때마다 감으로 판단하지 말고, trace와 grader, dataset, eval run을 이용해 에이전트 워크플로를 반복 측정 가능한 대상으로 만들라는 것입니다.

많은 팀이 아직도 모델 평가는 정답 문자열 비교 정도로 끝냅니다. 그런데 실제 에이전트 장애는 다른 곳에서 납니다. 잘못된 도구를 고르거나, handoff가 빠지거나, 안전 정책을 어기거나, 중간 실패 뒤 복구를 못 하거나, 마지막 보고 전에 검증을 생략하는 식입니다. 즉, 에이전트 평가는 답변 품질만이 아니라 행동 품질을 봐야 합니다.

trace grading이 먼저인 이유

문서에서는 에이전트 워크플로 디버깅 단계라면 먼저 traces에서 시작하라고 말합니다. 이 순서가 맞습니다. 초기 운영에서는 “좋은 결과가 무엇인지”보다 “실패가 어디서 생기는지”를 보는 편이 더 빠르기 때문입니다. trace에는 모델 호출, 도구 호출, handoff, guardrail 이벤트가 순서대로 남습니다.

실무에서 trace가 유용한 이유는 원인 분리가 되기 때문입니다. 예를 들어 사용자가 “환불 내역을 보여 달라”고 했는데 에이전트가 주문 조회만 하고 끝났다면, 문제는 모델 언어 능력이 아니라 도구 선택입니다. 반대로 도구는 잘 골랐는데 결과 해석이 틀리면 그때는 프롬프트나 모델 문제일 수 있습니다. trace가 없으면 둘을 구분하기 어렵습니다.

grader는 사람의 리뷰 기준을 구조화하는 도구입니다

grader를 만들 때 흔한 실수는 너무 거창한 기준부터 세우는 것입니다. 처음에는 단순하고 운영적인 질문이 더 좋습니다.

• 올바른 도구를 선택했는가
• 승인 필요한 작업에서 멈췄는가
• handoff가 필요한 상황에서 적절히 넘겼는가
• 실패 후 재시도를 합리적으로 했는가
• 최종 답변이 내부 정책을 위반하지 않았는가

이런 기준은 사람이 눈으로 보던 리뷰 항목을 구조화한 것입니다. 중요한 건 점수를 예쁘게 만드는 것이 아니라, 회귀를 빨리 발견하는 데 있습니다. 예를 들어 새 프롬프트 배포 후 “올바른 도구 선택률”이 92%에서 76%로 떨어졌다면, 전체 응답 평점보다 훨씬 먼저 경고를 줄 수 있습니다.

dataset과 eval run은 운영 리듬을 만드는 역할입니다

trace를 통해 실패 유형을 파악했다면, 그다음은 반복 가능한 dataset으로 옮겨야 합니다. 그래야 프롬프트 수정, 모델 교체, 도구 추가 같은 변화가 생길 때마다 같은 기준으로 다시 검증할 수 있습니다. 이때 dataset은 예쁜 예시보다 실제 운영 로그에서 뽑는 것이 낫습니다.

추천하는 구성은 아래와 같습니다.

1. 정상 케이스: 기대 동작이 분명한 요청
2. 경계 케이스: 모호하거나 정보가 일부 빠진 요청
3. 실패 복구 케이스: 도구 오류, 빈 결과, 권한 거부 상황
4. 안전 케이스: 승인이나 정책 체크가 필요한 요청
5. 장기 실행 케이스: 여러 단계의 추론과 도구 사용이 필요한 요청

이렇게 나누면 단순 정확도보다 운영 적합성을 더 잘 볼 수 있습니다. 특히 에이전트는 “모를 때 모른다고 말하는 능력”과 “막혀도 멈출 줄 아는 능력”이 중요하므로, 실패 유도 케이스를 반드시 넣어야 합니다.

점수 하나로 끝내면 오히려 위험합니다

에이전트 평가는 리더보드가 아닙니다. 총점 하나만 보고 의사결정하면 가장 위험한 회귀를 놓치기 쉽습니다. 예를 들어 전체 점수는 비슷한데 승인 누락 비율이 올라갔다면, 서비스 위험도는 훨씬 커졌을 수 있습니다. 따라서 최소한 지표를 분리해서 보셔야 합니다.

• 도구 선택 정확도
• 불필요한 도구 호출 비율
• 승인 누락 비율
• 안전 정책 위반 비율
• 중간 실패 후 복구 성공률
• 최종 보고 전 증거 확인 비율

이렇게 보면 모델이 “더 똑똑해졌는지”보다 “더 안전하고 운영 가능해졌는지”를 판단하기 쉬워집니다.

배포 프로세스에 붙여야 효과가 납니다

평가 체계는 문서로만 있으면 금방 죽습니다. 가장 현실적인 방법은 프롬프트 변경, 도구 추가, 모델 버전 교체가 있을 때 자동 또는 반자동으로 eval run을 돌리는 것입니다. 작은 팀이라면 매 PR마다 전부 돌리기 어려울 수 있으니, 우선 배포 전 핵심 20개 시나리오라도 고정해 두는 편이 좋습니다.

또 하나 중요한 점은 사람 리뷰와 자동 평가를 경쟁 관계로 두지 않는 것입니다. grader는 사람을 대체하기보다, 사람이 볼 대상을 좁혀 주는 도구에 가깝습니다. 예를 들어 200개 실행 중 grader가 이상 점수를 준 15개 trace만 사람이 다시 보면 운영 부담이 크게 줄어듭니다.

현업에서 바로 써먹는 시작 방법

처음부터 플랫폼 전체를 뜯어고칠 필요는 없습니다. 이번 주 안에 할 수 있는 가장 현실적인 시작은 최근 장애 10건을 뽑아 공통 실패 유형을 적는 것입니다. 그리고 각 유형에 대해 한 줄 grader 질문을 만드는 것입니다. “환불 요청인데 주문 조회만 했는가?”, “권한 거부 상황에서 우회 시도를 했는가?”처럼 아주 운영적인 질문이면 충분합니다.

이렇게 시작하면 평가 체계가 논문이 아니라 현장 도구가 됩니다. 에이전트 운영에서 중요한 것은 완벽한 벤치마크보다, 같은 실수를 반복하지 않는 루틴입니다.

바로 실행할 체크리스트

• 최근 2주간 에이전트 실패 사례를 10건만 뽑아 공통 유형 분류하기
• 답변 품질이 아니라 도구 선택, handoff, 승인, 복구 관점으로 실패 원인 다시 보기
• trace를 남기지 않는 워크플로가 있다면 우선 관측부터 추가하기
• 사람이 보던 리뷰 기준을 grader 질문 형태로 5개 이상 정리하기
• 정상, 경계, 실패 복구, 안전, 장기 실행 케이스로 dataset을 나누기
• 총점 하나만 보지 말고 승인 누락과 정책 위반처럼 위험 지표를 분리해 보기
• 프롬프트 변경이나 모델 교체 전후로 동일 eval run을 비교하는 습관 만들기