에이전트를 붙인 서비스가 일정 규모를 넘기면 가장 먼저 듣는 말이 있습니다. “어제는 되던 게 오늘은 왜 안 되죠?” 문제는 모델이 틀렸다는 사실 자체가 아닙니다. 어떤 변경이 어떤 회귀를 만들었는지 설명할 수 없다는 점입니다. OpenAI의 agent evals 가이드는 이 지점을 정확히 짚습니다. 핵심은 프롬프트 한 줄 바꿀 때마다 감으로 판단하지 말고, trace와 grader, dataset, eval run을 이용해 에이전트 워크플로를 반복 측정 가능한 대상으로 만들라는 것입니다.
많은 팀이 아직도 모델 평가는 정답 문자열 비교 정도로 끝냅니다. 그런데 실제 에이전트 장애는 다른 곳에서 납니다. 잘못된 도구를 고르거나, handoff가 빠지거나, 안전 정책을 어기거나, 중간 실패 뒤 복구를 못 하거나, 마지막 보고 전에 검증을 생략하는 식입니다. 즉, 에이전트 평가는 답변 품질만이 아니라 행동 품질을 봐야 합니다.
문서에서는 에이전트 워크플로 디버깅 단계라면 먼저 traces에서 시작하라고 말합니다. 이 순서가 맞습니다. 초기 운영에서는 “좋은 결과가 무엇인지”보다 “실패가 어디서 생기는지”를 보는 편이 더 빠르기 때문입니다. trace에는 모델 호출, 도구 호출, handoff, guardrail 이벤트가 순서대로 남습니다.
실무에서 trace가 유용한 이유는 원인 분리가 되기 때문입니다. 예를 들어 사용자가 “환불 내역을 보여 달라”고 했는데 에이전트가 주문 조회만 하고 끝났다면, 문제는 모델 언어 능력이 아니라 도구 선택입니다. 반대로 도구는 잘 골랐는데 결과 해석이 틀리면 그때는 프롬프트나 모델 문제일 수 있습니다. trace가 없으면 둘을 구분하기 어렵습니다.
grader를 만들 때 흔한 실수는 너무 거창한 기준부터 세우는 것입니다. 처음에는 단순하고 운영적인 질문이 더 좋습니다.
이런 기준은 사람이 눈으로 보던 리뷰 항목을 구조화한 것입니다. 중요한 건 점수를 예쁘게 만드는 것이 아니라, 회귀를 빨리 발견하는 데 있습니다. 예를 들어 새 프롬프트 배포 후 “올바른 도구 선택률”이 92%에서 76%로 떨어졌다면, 전체 응답 평점보다 훨씬 먼저 경고를 줄 수 있습니다.
trace를 통해 실패 유형을 파악했다면, 그다음은 반복 가능한 dataset으로 옮겨야 합니다. 그래야 프롬프트 수정, 모델 교체, 도구 추가 같은 변화가 생길 때마다 같은 기준으로 다시 검증할 수 있습니다. 이때 dataset은 예쁜 예시보다 실제 운영 로그에서 뽑는 것이 낫습니다.
추천하는 구성은 아래와 같습니다.
이렇게 나누면 단순 정확도보다 운영 적합성을 더 잘 볼 수 있습니다. 특히 에이전트는 “모를 때 모른다고 말하는 능력”과 “막혀도 멈출 줄 아는 능력”이 중요하므로, 실패 유도 케이스를 반드시 넣어야 합니다.
에이전트 평가는 리더보드가 아닙니다. 총점 하나만 보고 의사결정하면 가장 위험한 회귀를 놓치기 쉽습니다. 예를 들어 전체 점수는 비슷한데 승인 누락 비율이 올라갔다면, 서비스 위험도는 훨씬 커졌을 수 있습니다. 따라서 최소한 지표를 분리해서 보셔야 합니다.
이렇게 보면 모델이 “더 똑똑해졌는지”보다 “더 안전하고 운영 가능해졌는지”를 판단하기 쉬워집니다.
평가 체계는 문서로만 있으면 금방 죽습니다. 가장 현실적인 방법은 프롬프트 변경, 도구 추가, 모델 버전 교체가 있을 때 자동 또는 반자동으로 eval run을 돌리는 것입니다. 작은 팀이라면 매 PR마다 전부 돌리기 어려울 수 있으니, 우선 배포 전 핵심 20개 시나리오라도 고정해 두는 편이 좋습니다.
또 하나 중요한 점은 사람 리뷰와 자동 평가를 경쟁 관계로 두지 않는 것입니다. grader는 사람을 대체하기보다, 사람이 볼 대상을 좁혀 주는 도구에 가깝습니다. 예를 들어 200개 실행 중 grader가 이상 점수를 준 15개 trace만 사람이 다시 보면 운영 부담이 크게 줄어듭니다.
처음부터 플랫폼 전체를 뜯어고칠 필요는 없습니다. 이번 주 안에 할 수 있는 가장 현실적인 시작은 최근 장애 10건을 뽑아 공통 실패 유형을 적는 것입니다. 그리고 각 유형에 대해 한 줄 grader 질문을 만드는 것입니다. “환불 요청인데 주문 조회만 했는가?”, “권한 거부 상황에서 우회 시도를 했는가?”처럼 아주 운영적인 질문이면 충분합니다.
이렇게 시작하면 평가 체계가 논문이 아니라 현장 도구가 됩니다. 에이전트 운영에서 중요한 것은 완벽한 벤치마크보다, 같은 실수를 반복하지 않는 루틴입니다.
