AI 에이전트 평가 플라이휠 운영법: 프롬프트 수정이 회귀를 만들지 않게 하는 방법

AI 에이전트를 운영하면서 가장 위험한 순간은 장애가 난 직후가 아니다. 장애 하나를 고치려고 프롬프트를 바꿨는데, 조용히 다른 10개 케이스를 망가뜨리는 순간이다. Google Developers Blog가 2026년 6월 30일 공개한 “Agent Quality Flywheel” 글은 이 문제를 정면으로 다룬다. 핵심은 vibe check를 그만하고, 평가 데이터를 만들고, 추론을 돌리고, 독립 채점하고, 실패를 분석한 뒤, 수정 효과를 이전 baseline과 비교하라는 것이다.

이 글은 특정 Google 도구만의 사용법보다 방법론이 더 중요하다. 어떤 프레임워크를 쓰든 에이전트 품질은 “좋아 보인다”가 아니라 “같은 기준에서 재현 가능하게 좋아졌다”로 관리해야 한다.

플라이휠의 5단계

Google이 설명한 흐름은 다섯 단계다.

1. Prepare Data: 기존 OTel trace, 손으로 만든 케이스, 합성 시나리오에서 평가 데이터를 만든다.
2. Run Inference: 에이전트를 데이터셋에 실행해 trace를 만든다. 이미 trace가 있으면 생략할 수 있다.
3. Grade: adaptive AutoRaters나 custom metric으로 trace를 채점한다.
4. Analyze Failures: 루브릭 verdict를 읽고 실패 원인을 분석한다. 실패가 10개 이상이면 클러스터링한다.
5. Optimize & Iterate: 타깃 수정 후 2~4단계를 반복하고 baseline과 비교한다.

여기서 실무적으로 가장 중요한 단계는 3번과 5번이다. 채점 기준이 없으면 개선 여부를 모른다. baseline 비교가 없으면 회귀를 모른다. 팀이 “프롬프트를 조금 다듬었더니 좋아졌다”고 말할 때, 대부분은 이 두 가지가 비어 있다.

optimizer와 evaluator를 분리한다

Google 글에서 가장 좋은 문장은 “optimizer never grades its own work”에 가깝다. 수정안을 제안하는 주체와 채점하는 주체를 분리해야 한다. 프롬프트를 고친 같은 에이전트가 자기 결과를 채점하면 metric gaming이 생긴다. 모델은 사람이 생각하는 의미의 정직한 개선보다 채점 기준을 만족하는 문장 패턴을 학습할 수 있다.

실무 구조는 이렇게 잡으면 된다.

• Coding agent: 실패 원인을 읽고 수정안을 만든다.
• Evaluation service: 수정 전후 trace를 독립 채점한다.
• Human reviewer: 지표 변화와 샘플 실패를 보고 승인한다.
• CI gate: 핵심 metric 하락이나 안전 위반이 있으면 merge를 막는다.

작은 팀도 같은 구조를 흉내 낼 수 있다. 꼭 대형 플랫폼이 필요하지 않다. eval_cases.jsonl, run_eval.ts, grade_with_rubric.ts, baseline.json만 있어도 시작할 수 있다.

metric은 제품 문제에서 출발한다

나쁜 평가 지표는 “답변이 좋은가?”처럼 넓다. 좋은 지표는 제품에서 실제로 실패한 행동을 직접 겨냥한다. Google 예시는 여행 concierge agent가 대화 중 변경된 날짜나 호텔을 최종 계획에 반영하는지 테스트한다. 일반적인 multi_turn_task_success만 보면 문제를 놓칠 수 있어, revision_honored라는 custom rubric을 추가한다.

이 접근을 다른 서비스에 적용하면 다음과 같다.

• 고객지원 agent: 환불 정책을 최신 정책 기준으로 적용했는가
• 코드리뷰 agent: 보안 취약점과 스타일 nitpick을 구분했는가
• 리서치 agent: 출처 없는 주장을 최종 답변에서 제거했는가
• 예약 agent: 사용자가 중간에 바꾼 날짜를 최종 예약 요청에 반영했는가
• 데이터 분석 agent: SQL 결과와 자연어 요약의 숫자가 일치하는가

metric은 모델 중심이 아니라 업무 중심이어야 한다.

최소 평가셋을 만드는 법

처음부터 1,000개 케이스를 만들 필요는 없다. 제품에서 가장 비싼 실패 5개를 고르고, 실패마다 정상 케이스 3개, 경계 케이스 3개, 악성 또는 혼란 케이스 2개를 만든다. 그러면 40개 정도의 평가셋이 생긴다. 이 정도면 프롬프트 변경 전후의 큰 회귀는 잡기 시작한다.

평가 케이스 포맷은 단순해야 한다.

• input: 사용자 대화 또는 요청
• expected_behavior: 반드시 만족해야 하는 행동
• forbidden_behavior: 절대 하면 안 되는 행동
• tools_available: 호출 가능한 도구
• rubric: PASS, PARTIAL, FAIL 기준
• tags: 기능, 리스크, 난이도, 언어

중요한 건 정답 문장 하나가 아니라 행동 기준이다. 에이전트는 같은 목표를 여러 방식으로 달성할 수 있으므로 exact match보다 rubric 기반 채점이 잘 맞는다.

실패 분석은 숫자보다 샘플이 먼저다

평균 점수는 방향을 보여주지만 원인을 말해주지 않는다. 실패 trace를 직접 읽어야 한다. 특히 multi-turn agent는 내부 state는 맞는데 최종 메시지가 틀리는 경우, tool call은 성공했는데 사용자에게 stale value를 말하는 경우, 이전 turn의 제약을 잊는 경우가 자주 나온다.

실패가 10개 미만이면 사람이 직접 읽는 편이 빠르다. 10개 이상이면 클러스터링을 붙인다. 예를 들어 “중간 변경 무시”, “도구 결과 요약 오류”, “권한 없는 액션 제안”, “출처 누락”처럼 유형을 나누면 다음 수정이 명확해진다.

CI에 붙일 때의 기준

에이전트 평가는 너무 느리면 개발자가 우회한다. 따라서 두 단계로 나누는 편이 좋다.

• PR gate: 2050개 핵심 케이스, 35분 안에 끝나는 smoke eval
• nightly eval: 300개 이상 케이스, production trace sampling 포함

PR gate에서는 핵심 지표 하락, 금지 행동 발생, 보안 tool call 위반만 막는다. nightly eval은 추세를 본다. 이 구조가 되어야 프롬프트와 도구 변경을 자주 하면서도 품질 회귀를 잡을 수 있다.

실행 체크리스트

• 제품에서 가장 비싼 실패 5개를 고른다.
• 실패마다 정상, 경계, 혼란 케이스를 만든다.
• exact answer가 아니라 행동 rubric을 작성한다.
• 수정 agent와 채점 evaluator를 분리한다.
• baseline 점수를 저장하고 모든 변경과 비교한다.
• PR에는 작은 smoke eval, nightly에는 큰 trace eval을 돌린다.
• 실패 샘플을 사람이 읽고 유형 태그를 붙인다.
• metric이 좋아져도 금지 행동이 나오면 배포하지 않는다.

출처: Google Developers Blog, “Driving the Agent Quality Flywheel from Your Coding Agent”