
Google Developers Blog에 따르면 Google은 코딩 에이전트가 AI 에이전트의 품질 평가와 개선 반복을 주도하도록 하는 ‘Agent Quality Flywheel’ 방식을 공개했다. 이 방식은 에이전트가 실제 목표를 제대로 달성하는지 확인하기 위해 평가 데이터 준비, 추론 실행, 자동 채점, 실패 분석, 수정 반복을 하나의 개발 루프로 묶는 접근이다.
Google은 에이전트 개발에서 흔히 발생하는 문제로 “몇 개의 예시는 좋아 보이지만 전체 품질이 실제로 좋아졌는지 알기 어렵다”는 점을 지적했다. 프롬프트를 조금 바꿔 특정 사례가 개선돼도, 다른 사용 흐름이나 장기 대화에서 회귀가 생길 수 있다는 것이다. 특히 에이전트는 답변이 자연스럽고 계획이 그럴듯해 보여도 사용자의 실제 의도를 놓치는 방식으로 실패할 수 있다.
이번에 공개된 흐름은 Build & Test, Ship & Monitor, Learn & Refine으로 이어지는 품질 개선 루프 가운데 개발자가 빠르게 반복하는 내부 루프에 초점을 둔다. Google은 코딩 에이전트가 기존 OpenTelemetry traces, 수작업 사례, 합성 시나리오로 평가 데이터를 만들고, 에이전트를 실행해 traces를 생성한 뒤, Google의 AutoRaters 또는 사용자 정의 지표로 결과를 채점한다고 설명했다.
핵심은 수정하는 주체와 평가하는 주체를 분리하는 데 있다. Google은 코딩 에이전트나 자동 최적화 도구가 개선안을 제안할 수 있지만, 그 결과는 Gemini Enterprise Agent Platform의 GenAI evaluation service가 독립적으로 평가해야 한다고 밝혔다. 개선을 제안한 시스템이 스스로 점수를 매기면 실제 품질 향상보다 지표를 맞추는 방향으로 움직일 수 있기 때문이다.
Google은 여행 계획 에이전트 사례도 소개했다. 사용자가 대화 중 날짜, 호텔, 여행자 수 같은 조건을 바꿨을 때 최종 계획이 최신 변경을 반영하는지 평가하도록 코딩 에이전트에 지시했고, 에이전트는 다중 턴 작업 성공률과 경로 품질 지표에 더해 ‘변경사항 반영 여부’를 별도 사용자 정의 지표로 만들었다. 첫 평가에서는 일부 사례에서 내부 상태는 맞게 업데이트됐지만 최종 사용자 응답이 이전 값을 반복하는 문제가 드러났다고 Google은 설명했다.
이 사례는 에이전트 품질 관리가 단순한 프롬프트 감각 테스트에서 측정 가능한 소프트웨어 엔지니어링 절차로 이동하고 있음을 보여준다. 에이전트가 고객지원, 예약, 운영 자동화처럼 다중 단계 업무를 맡을수록 “정답처럼 보이는 응답”보다 사용자의 최신 의도, 도구 호출 경로, 최종 결과의 일치 여부를 반복적으로 검증하는 체계가 중요해진다.
Google은 이 기능을 두 가지 패키지로 제공한다고 밝혔다. ADK와 agents-cli 도구 체계를 사용하는 경우 `google-agents-cli-eval`을, 특정 프레임워크에 묶이지 않고 Evaluation SDK를 쓰는 경우 `agent-platform-eval-flywheel`을 사용할 수 있다. 운영 환경의 실제 트래픽을 평가하려면 에이전트가 traces를 남겨야 하며, ADK는 기본적으로 OpenTelemetry traces를 내보낸다고 Google은 설명했다.
다만 블로그에 제시된 개선 수치와 사례는 특정 샘플 에이전트와 평가 구성에서 나온 결과다. 따라서 이를 모든 에이전트에 적용되는 성능 보장으로 보기는 어렵다. 그럼에도 이번 공개는 주요 AI 플랫폼이 에이전트 개발의 다음 병목을 모델 성능만이 아니라 평가, 관측, 회귀 방지 체계로 보고 있음을 보여주는 신호다.
출처: Google Developers Blog https://developers.googleblog.com/driving-the-agent-quality-flywheel-from-your-coding-agent/ · Google Cloud Documentation https://docs.cloud.google.com/vertex-ai/generative-ai/docs/models/metrics-templates









