Gemini Agent Evaluation GA: 에이전트 품질을 개발과 운영에서 같은 기준으로 재는 시대

요약: Google이 Gemini Enterprise Agent Platform의 Agent and Model Evaluations를 GA로 공개했습니다. 핵심은 개발 중 eval, 배포 후 production trace 평가, drift alert, user/environment simulator, 20개 이상 pre-built metric을 하나의 평가 엔진에서 다루는 것입니다.

에이전트 평가는 왜 배포 후에 다시 무너지는가

많은 팀이 AI 에이전트를 만들 때 처음에는 간단한 테스트셋으로 품질을 확인합니다. “환불 요청 처리”, “문서 검색”, “티켓 분류” 같은 케이스를 몇 개 만들고, 답변이 그럴듯하면 배포합니다. 문제는 운영에 들어간 뒤입니다. 실제 사용자의 요청은 테스트셋보다 길고, 애매하고, 중간에 조건이 바뀌고, 도구가 실패합니다.

Google이 2026년 7월 31일 GA로 공개한 Agent and Model Evaluations는 이 문제를 정면으로 다룹니다. 핵심 문장은 이것입니다. “개발 중 작성한 케이스로 측정하고, 출시 후 실제 수행한 작업으로 다시 측정해야 한다.” 즉, eval은 배포 전 체크리스트가 아니라 운영 시스템의 일부입니다.

이번 GA에서 중요한 점은 같은 engine과 같은 metric registry를 개발 실험과 production monitor에서 함께 쓴다는 것입니다. 로컬 실험에서는 90점이었는데 운영 모니터에서는 60점이라면, 측정 방식 차이가 아니라 agent 자체나 traffic 변화가 원인일 가능성이 커집니다.

무엇이 GA 되었나

Google 문서 기준으로 이번 평가 기능은 크게 세 가지 묶음입니다.

첫째, metric입니다. 품질, 안전성, grounding, agent tool use, trajectory, summarization, translation 같은 작업을 위한 20개 이상 pre-built metric이 제공됩니다. ROUGE, BLEU, MetricX, COMET, exact match 같은 계산 기반 metric도 있고, LLM-as-a-judge 기반 metric도 있습니다.

둘째, experiment입니다. client-side 또는 server-side로 실행할 수 있고, server-side run은 Cloud Storage에 artifact가 남아 audit과 재현이 가능합니다. eval case generation, user simulator, environment simulator도 제공됩니다. user simulator는 multi-turn conversation을 자동으로 만들어주고, environment simulator는 느린 백엔드나 실패하는 tool call을 production에 영향을 주지 않고 재현합니다.

셋째, online monitor입니다. 이미 수집한 trace와 session을 평가하고 score-over-time chart와 drift alert를 만들 수 있습니다. 모든 요청을 평가하면 비용이 커지므로 sampling과 filter를 적용할 수 있습니다.

Adaptive rubric이 필요한 이유

LLM-as-a-judge를 써본 팀은 judge prompt 하나로 모든 케이스를 평가하는 방식의 한계를 압니다. 어떤 케이스는 정확한 JSON shape가 중요하고, 어떤 케이스는 tool selection이 중요하며, 어떤 케이스는 안전 정책 위반 여부가 중요합니다.

Google의 adaptive rubric은 eval case definition, developer instruction, tool declaration을 바탕으로 케이스별 pass/fail 기준을 만듭니다. 예를 들어 예약 변경 agent라면 “사용자가 명시한 날짜를 보존했는가”, “환불 정책 조회 tool을 올바른 인자로 호출했는가”, “확정 전 사용자 확인을 받았는가” 같은 rubric을 케이스별로 생성할 수 있습니다.

이 접근은 완벽하지 않습니다. LLM judge도 오류가 있고, 비용도 듭니다. 하지만 하나의 고정 prompt로 모든 케이스를 채점하는 것보다는 failure reason을 구조화하기 쉽습니다. 특히 Google은 failure clustering과 taxonomy를 제공해 대량 eval 실패를 해석 가능한 그룹으로 묶는 흐름을 강조합니다.

실무에서 가장 쓸모 있는 부분: 시뮬레이터

개발자가 손으로 만든 eval case는 보통 정상 경로에 치우칩니다. 사용자는 이름을 틀리게 말하고, 중간에 목표를 바꾸고, tool은 timeout이 나고, API는 일부 필드만 반환합니다. 이런 케이스를 수동으로 다 만들기는 어렵습니다.

이번 GA에서 눈에 띄는 기능은 user simulator와 environment simulator입니다. user simulator는 persona와 conversation plan을 기준으로 multi-turn interaction을 만들어줍니다. environment simulator는 agent가 호출하는 시스템을 대신해 mock data, forced error, artificial latency를 반환합니다.

이것은 단순 테스트 편의 기능이 아닙니다. 에이전트 품질은 “답변 한 번”이 아니라 trajectory의 문제입니다. 좋은 agent는 tool을 골라야 하고, 실패를 감지해야 하며, 재시도하거나 사용자에게 확인해야 합니다. 그래서 환경 실패를 의도적으로 넣어보는 테스트가 중요합니다.

운영 모니터링으로 보는 drift

배포 전 eval을 통과해도 시간이 지나면 품질이 흔들립니다. 프롬프트가 바뀌고, tool schema가 바뀌고, 사용자 traffic mix가 달라지고, 모델 버전이 바뀔 수 있습니다. 이런 변화는 일반 로그만으로는 잘 보이지 않습니다.

온라인 evaluation monitor는 production trace를 샘플링해 같은 metric으로 계속 채점합니다. 여기서 score가 떨어지면 drift alert를 만들 수 있습니다. 중요한 것은 score 하나만 보는 것이 아니라 어떤 metric이 떨어졌는지 보는 것입니다. Task Success가 떨어졌는지, Tool Use Quality가 떨어졌는지, Grounding이 떨어졌는지에 따라 대응이 완전히 달라집니다.

A/B 테스트도 같은 맥락입니다. 새 prompt가 더 짧은 답변을 만든다고 좋은 것이 아닙니다. tool call 수가 줄어 비용은 낮아졌지만 task success가 떨어질 수 있습니다. 반대로 grounding은 좋아졌지만 latency가 늘어날 수 있습니다.

도입 전 체크리스트

• agent의 성공 기준을 “좋은 답변”이 아니라 task success, tool use, grounding, safety, latency로 나눈다.
• 개발 eval과 production monitor에서 같은 metric registry를 사용한다.
• 정상 케이스뿐 아니라 tool timeout, 빈 검색 결과, 잘못된 사용자 입력을 넣는다.
• LLM judge metric은 버전 관리하고, judge model 변경도 실험으로 다룬다.
• production trace 평가는 전수 대신 sampling과 high-risk filter로 시작한다.
• failure taxonomy를 만들어 “왜 실패했는지”를 팀 언어로 축적한다.
• CI에는 작은 eval set을, 릴리즈 전에는 확장 eval set을, 운영에는 online monitor를 둔다.

Gemini Agent Evaluation GA는 특정 클라우드 기능 이상의 신호입니다. 에이전트 개발의 중심이 prompt 작성에서 품질 운영으로 이동하고 있습니다. 이제 “잘 되는 것 같다”는 배포 기준이 되기 어렵습니다. 개발팀은 eval dataset, metric versioning, production trace scoring을 제품 코드와 같은 수준으로 관리해야 합니다.