AI 에이전트를 만들다 보면 가장 위험한 순간은 실패를 발견한 직후입니다. 사용자가 문제를 제보했고, 개발자는 프롬프트 한 줄을 고칩니다. 손으로 몇 번 돌려보니 좋아 보입니다. 하지만 정말 좋아졌을까요? 다른 케이스 10개를 망가뜨렸는지는 어떻게 알 수 있을까요?
Google이 소개한 Agent Quality Flywheel은 이 문제를 정면으로 다룹니다. 핵심은 prompt tweak를 감으로 판단하지 말고, 데이터 준비, 추론 실행, 채점, 실패 분석, 최적화 반복의 루프로 관리하자는 것입니다. 이 글은 agent evaluation, AutoRaters, prompt regression test, AI agent 품질 관리 방법을 찾는 개발자를 위한 운영 가이드입니다.
에이전트는 겉으로는 성공처럼 보이는 실패를 자주 만듭니다. 답변은 자신감 있고, 계획도 그럴듯하고, 문장도 자연스럽습니다. 하지만 사용자의 실제 목표를 놓치거나, 중간 변경사항을 반영하지 않거나, 내부 상태는 맞는데 최종 메시지가 틀릴 수 있습니다.
수동 테스트 3개로는 이런 실패를 잡기 어렵습니다. 개발자가 방금 고친 케이스는 좋아질 가능성이 높습니다. 문제는 주변 케이스입니다. refund 정책을 고쳤더니 cancellation 정책이 깨지고, 날짜 변경 처리를 고쳤더니 인원 변경 처리가 흔들릴 수 있습니다.
따라서 에이전트 품질 관리는 일반 소프트웨어의 regression test와 비슷해야 합니다. 수정 전 baseline을 만들고, 수정 후 같은 데이터셋으로 다시 돌리고, metric delta를 봐야 합니다. 감으로 “나아진 듯”이 아니라 숫자와 실패 사례로 판단해야 합니다.
Google이 설명한 flywheel은 5단계입니다. Prepare Data, Run Inference, Grade, Analyze Failures, Optimize & Iterate입니다. 이 순서를 처음부터 완벽하게 자동화할 필요는 없습니다. 중요한 것은 각 단계를 분리하는 것입니다.
Prepare Data는 평가 데이터를 만드는 단계입니다. production trace, 손으로 만든 케이스, synthetic scenario를 섞을 수 있습니다. Run Inference는 같은 데이터셋에 대해 현재 agent를 실행해 trace를 만드는 단계입니다. 이미 production trace가 있다면 생략할 수 있습니다.
Grade는 평가 단계입니다. Google은 adaptive AutoRaters나 custom metric을 사용할 수 있다고 설명합니다. Analyze Failures는 실패 원인을 읽고 cluster로 묶는 단계입니다. Optimize & Iterate는 수정 후 다시 2~4단계를 반복하는 단계입니다.
실무에서는 Grade가 항상 독립적이어야 합니다. Google 글에서도 optimizer가 자기 작업을 직접 채점하지 않는다고 강조합니다. 프롬프트를 고친 agent가 자기 결과를 채점하면 metric gaming이 생깁니다. 수정자와 평가자는 분리해야 합니다.
처음부터 수천 개가 필요하지 않습니다. 중요한 workflow별로 20~50개부터 시작하면 됩니다. 예를 들어 여행 계획 agent라면 날짜 변경, 목적지 변경, 인원 변경, 호텔 변경, 일정 삭제처럼 실패 비용이 큰 변형을 나눕니다. 고객 지원 agent라면 환불 가능, 환불 불가, 정책 예외, 감정적 고객, 정보 부족 케이스를 나눕니다.
production trace는 현실성이 높지만 정답 라벨이 부족합니다. synthetic scenario는 통제하기 쉽지만 현실성이 낮을 수 있습니다. 둘을 섞어야 합니다. 초기에는 synthetic으로 실패 유형을 찌르고, 운영이 시작되면 production trace에서 반복 실패를 뽑아 회귀 테스트에 추가합니다.
각 케이스에는 기대 행동을 짧고 명확하게 써야 합니다. “좋은 답변” 같은 기준은 약합니다. “사용자가 중간에 날짜를 바꾸면 최종 일정의 모든 날짜가 새 값이어야 한다”, “환불 불가 정책이면 대안을 제시하되 환불 가능하다고 말하면 안 된다”처럼 판정 가능한 기준이 필요합니다.
에이전트 품질을 하나의 평균 점수로만 보면 원인을 놓칩니다. task_success, trajectory_quality, instruction_following, safety, tool_correctness, final_answer_consistency처럼 나눠야 합니다. 특히 multi-turn agent는 “내부 상태는 맞았는데 사용자에게 틀리게 말했다” 같은 문제가 생기므로 final response consistency를 별도로 보는 것이 좋습니다.
Google 예시에서도 mid-conversation change를 agent가 반영하는지 보기 위해 revision_honored 같은 custom rubric을 추가합니다. built-in metric은 전반적 품질을 보지만, 제품의 핵심 위험은 별도 metric으로 승격해야 합니다.
threshold도 정해야 합니다. 예를 들어 revision ignored가 20%를 넘으면 수정 필요, safety violation은 0건이 아니면 release block, tool schema error는 p95 기준 1% 미만처럼 운영 기준을 둡니다. 기준이 없으면 회의 때마다 “이 정도면 괜찮지 않나”로 돌아갑니다.
실패가 2~3개라면 사람이 직접 읽으면 됩니다. 하지만 30개가 넘으면 개별 사례만 봐서는 패턴이 보이지 않습니다. failure clustering이 필요합니다. 날짜 변경 미반영, tool result 무시, final message stale value, 권한 오류 후 hallucination, retry 후 중복 실행처럼 묶어야 합니다.
cluster 단위로 보면 수정 방향도 달라집니다. tool result 무시라면 prompt보다 state injection 방식이 문제일 수 있습니다. stale final message라면 마지막 답변 생성 전에 canonical state를 다시 읽게 해야 합니다. 권한 오류 후 hallucination이라면 tool error handling policy를 바꿔야 합니다.
이 단계에서 중요한 것은 실패를 모델 탓으로 뭉뚱그리지 않는 것입니다. 많은 agent 실패는 orchestration, state management, tool schema, UI confirmation, retry policy 문제입니다. 평가가 좋아야 원인이 보입니다.
Agent Quality Flywheel은 일회성 리포트가 아니라 배포 습관이어야 합니다. prompt, tool, model, retrieval index, system policy가 바뀌면 최소 평가 세트를 자동 실행해야 합니다. 모든 케이스를 매번 돌리기 어렵다면 smoke suite와 nightly full suite로 나눕니다.
CI에서는 빠른 synthetic 20개를 돌려 release blocker를 잡습니다. nightly job에서는 production trace sample과 더 큰 synthetic set을 돌립니다. 주요 metric이 baseline보다 떨어지면 Slack이나 Discord로 알리고, 실패 cluster와 대표 trace를 함께 보여줍니다.
비용도 관리해야 합니다. 평가 자체가 모델 호출을 많이 씁니다. 그래서 tiering이 필요합니다. 작은 변경은 cheap model judge와 핵심 케이스만, 큰 변경이나 릴리스 전에는 강한 judge와 전체 케이스를 사용합니다.
프롬프트 수정은 코드 수정과 같습니다. 테스트 없이 배포하면 언젠가 회귀가 납니다. Agent Quality Flywheel의 핵심은 에이전트 개선을 감이 아니라 반복 가능한 절차로 바꾸는 것입니다. AI 제품이 데모를 넘어 운영 단계로 가려면, 프롬프트 엔지니어링보다 평가 엔지니어링이 먼저 성숙해야 합니다.
