AI 에이전트 평가 플라이휠 구축법: 프롬프트 감이 아니라 지표로 개선하기

AI 에이전트가 "그럴듯하게" 작동하는 것과 실제로 좋아지는 것은 다릅니다. Google은 Agent Quality Flywheel을 설명하면서, 코딩 에이전트가 평가 데이터 준비, 추론 실행, 채점, 실패 분석, 최적화 반복을 돕는 구조를 소개했습니다. 핵심 메시지는 명확합니다. 프롬프트를 조금 고쳐서 샘플 세 개가 나아졌다고 운영 품질이 개선됐다고 말할 수 없다는 것입니다.

실무에서 에이전트 실패는 대개 조용합니다. 답변은 자신 있어 보이고, 계획도 그럴듯합니다. 하지만 사용자의 실제 목표를 놓치거나, 중간에 바뀐 요구사항을 반영하지 않거나, 내부 상태는 맞게 저장해놓고 최종 답변에는 예전 값을 말합니다. 이런 문제는 데모에서는 잘 안 보이고, 운영에서 신뢰를 깎습니다.

왜 평가 플라이휠이 필요한가

대부분의 팀은 처음에 이렇게 시작합니다.

• 프롬프트를 수정한다.
• 몇 가지 예시를 직접 돌려본다.
• 좋아 보이면 배포한다.
• 사용자 불만이 오면 다시 수정한다.

이 방식은 빠르지만 위험합니다. 한 케이스를 고치면서 다른 열 케이스를 망가뜨렸는지 알 수 없습니다. 특히 멀티턴 에이전트는 실패 원인이 복합적입니다. 사용자 의도를 잘못 잡았는지, 도구를 잘못 골랐는지, 내부 상태 업데이트가 누락됐는지, 마지막 답변 생성에서 오래된 정보를 썼는지 분리해서 봐야 합니다.

평가 플라이휠은 이 과정을 반복 가능한 루프로 만듭니다.

1. 평가 데이터를 준비합니다.
2. 에이전트를 같은 데이터에 실행합니다.
3. 결과 trace를 채점합니다.
4. 실패 유형을 분석합니다.
5. 수정 후 이전 baseline과 비교합니다.

중요한 것은 한 번 평가하고 끝내는 게 아니라, 변경할 때마다 같은 기준으로 비교하는 것입니다.

평가 데이터는 어디서 가져오나

처음부터 완벽한 평가셋을 만들 필요는 없습니다. 시작점은 세 가지입니다.

첫째, 실제 운영 trace입니다. 고객지원, 검색, 예약, 리서치, 코드수정 등 에이전트가 이미 처리한 대화와 도구 호출 기록이 있다면 가장 좋습니다. 개인정보와 민감정보를 제거한 뒤 평가 케이스로 바꿉니다.

둘째, 수작업 케이스입니다. PM, 엔지니어, CS 담당자가 "이건 꼭 맞아야 한다"고 보는 시나리오를 직접 씁니다. 수는 적어도 품질이 높습니다.

셋째, 합성 시나리오입니다. Google 문서에서는 User Simulator를 사용해 revision type별 시나리오를 생성하는 예시를 들었습니다. 합성 데이터는 cold start에 좋지만 실제 트래픽을 대체하지는 못합니다.

추천은 30개로 시작하는 것입니다. 너무 적으면 지표가 흔들리고, 너무 많으면 첫 구축이 늦어집니다. 30개를 만들고 나서 운영 trace를 매주 추가하세요.

무엇을 채점해야 하나

단일 점수 하나로 에이전트를 평가하면 원인을 알기 어렵습니다. 최소한 다음 축을 나눠야 합니다.

• task_success: 사용자의 목표를 달성했는가
• trajectory_quality: 중간 도구 호출과 판단 흐름이 합리적인가
• instruction_following: 시스템/도메인 규칙을 지켰는가
• state_consistency: 중간에 바뀐 요구사항과 저장 상태가 최종 답변에 반영됐는가
• safety_boundary: 승인 없이 위험한 액션을 하지 않았는가
• final_answer_quality: 사용자가 실행할 수 있는 형태로 답했는가

Google 예시에서 흥미로운 부분은 revision_honored라는 custom rubric입니다. 사용자가 대화 중 날짜, 호텔, 인원수 같은 조건을 바꿨을 때 최종 계획이 그 변경을 반영했는지를 별도 지표로 만든 것입니다. built-in 점수는 전체적으로 높게 나올 수 있지만, 특정 실패를 안정적으로 추적하려면 별도 rubric이 필요합니다.

실무에서도 마찬가지입니다. 우리 서비스의 핵심 실패 유형을 custom metric으로 빼야 합니다.

평가자와 최적화자는 분리해야 한다

Google 글에서 가장 중요한 문장 중 하나는 optimizer never grades its own work입니다. 프롬프트를 고치는 에이전트가 자기 결과를 직접 채점하면, 품질을 개선하는 대신 채점 기준을 속이는 방향으로 움직일 수 있습니다.

구조는 이렇게 나누는 것이 안전합니다.

• optimizer: 프롬프트, 도구 설명, 라우팅 규칙, 후처리 코드를 수정합니다.
• evaluator: 고정된 평가셋과 rubric으로 이전/이후 결과를 비교합니다.
• reviewer: 지표 변화와 실패 샘플을 보고 배포 여부를 결정합니다.

작은 팀이라도 역할은 분리할 수 있습니다. 같은 사람이 하더라도, 평가 스크립트와 rubric은 수정 작업과 독립적으로 관리하세요.

실패 분석은 평균 점수보다 중요하다

평균 점수가 0.72에서 0.76으로 올랐다는 사실만으로는 배포 결정을 내리기 어렵습니다. 어떤 실패가 줄었고, 어떤 실패가 늘었는지를 봐야 합니다.

실패 분석에서는 다음 질문을 던집니다.

• 실패가 특정 intent에 몰리는가
• 특정 도구 호출 뒤에 자주 실패하는가
• 사용자가 중간에 조건을 바꾸면 실패율이 올라가는가
• 최종 답변만 틀리고 내부 state는 맞는가
• 프롬프트 수정 후 새로 생긴 regression이 있는가

실패가 10개 이상이면 클러스터링이 유용합니다. 실패 원인을 사람이 하나씩 읽기보다, 비슷한 실패를 묶어보면 수정 우선순위가 보입니다.

운영 파이프라인에 넣는 방법

처음부터 거창한 플랫폼을 만들 필요는 없습니다. GitHub Actions나 내부 CI에 간단히 넣을 수 있습니다.

권장 흐름은 다음과 같습니다.

1. eval_cases 디렉터리에 JSON 또는 YAML 케이스를 저장합니다.
2. 에이전트 실행 결과를 trace 파일로 남깁니다.
3. evaluator가 각 trace를 rubric별로 채점합니다.
4. 이전 baseline과 비교해 regression을 계산합니다.
5. 기준 이하이면 PR을 막거나 경고를 띄웁니다.
6. 실패 샘플 5개를 PR 코멘트에 붙입니다.

여기서 중요한 것은 개발자가 지표를 읽을 수 있어야 한다는 점입니다. 단순히 "eval failed"가 아니라 "중간 변경사항 반영 실패 18% → 29%로 악화"처럼 행동 가능한 메시지를 줘야 합니다.

오늘 적용할 체크리스트

• 운영 trace, 수작업 케이스, 합성 시나리오를 섞어 첫 평가셋 30개를 만든다.
• task_success 하나만 보지 말고 trajectory, state consistency, safety, final answer를 분리한다.
• 우리 서비스에서 가장 치명적인 실패 유형을 custom rubric으로 만든다.
• 프롬프트를 고치는 optimizer와 결과를 채점하는 evaluator를 분리한다.
• baseline을 저장하고 변경 전후 지표를 같은 케이스로 비교한다.
• 평균 점수뿐 아니라 실패 클러스터와 regression 샘플을 PR에 노출한다.
• 합성 데이터는 출발점으로만 쓰고, 매주 실제 운영 trace를 평가셋에 추가한다.

출처: Google Developers Blog Agent Quality Flywheel, Gemini Enterprise Agent Platform evaluation documentation.