배포 전 테스트는 왜 항상 배포 후에 무너질까
에이전트를 만들 때 가장 흔한 착각이 있어요. "테스트 케이스 200개 다 통과했으니까 괜찮겠지"라는 생각이죠. 그런데 배포 일주일 뒤, 아무도 예상 못 한 입력이 들어오면 에이전트가 슬금슬금 이상해지기 시작합니다.
이건 테스트를 대충 짠 문제가 아니라, 프로덕션의 실제 태스크가 우리가 미리 작성할 수 있는 어떤 스위트보다 크고 낯설다는 사실 그 자체의 문제예요. 그래서 필요한 건 "개발 중 평가"와 "배포 후 평가"를 같은 자로 재는 시스템입니다. 측정 방식이 다르면, 프로덕션에서 점수가 흔들릴 때 그게 에이전트 문제인지 측정 방식 문제인지 구분할 수가 없거든요.
Google Cloud의 Gemini Enterprise Agent Platform에서 에이전트·모델 평가 기능이 정식 출시(GA)됐습니다. 개발 단계의 로컬 실험부터 라이브 트래픽 모니터링까지, 하나의 엔진 위에서 일관된 메트릭으로 돌린다는 게 핵심이에요. 근거자료는 Google Developers Blog의 공식 발표에서 확인하실 수 있습니다.
국내 SI·금융권 프로젝트에서는 "에이전트가 왜 이 답을 했는지"에 대한 감사 로그 요구가 이미 나오고 있어요. 이 평가 아티팩트가 Cloud Storage에 버전별로 남는다는 점이 컴플라이언스 관점에서 꽤 매력적입니다.
실험(Experiment) 단위로 돌아가는 평가 파이프라인
평가의 기본 단위: Experiment
Agent Platform 평가의 1차 작업 단위는 experiment예요. 구성은 단순합니다.
- eval cases 데이터셋: 채점 대상이 되는 입력/기대값 세트
- metrics + scores 세트: 무엇으로, 어떻게 채점할지
이걸 UI에서 정의하고, 돌리고, 결과를 리뷰합니다. 실패 케이스 하나까지 파고들면 에이전트의 전체 trace와 세션 로그를 열어서 "무슨 일이 있었는지" 정확히 볼 수 있어요.
실행 경로 4가지
| 경로 | 용도 |
|---|---|
| Agent Platform SDK | 코드 기반 CI/CD 통합 |
| agents-cli | 터미널 워크플로우 (ADK-Python 지원) |
| Google Cloud Console | UI에서 실험 정의·실행·리뷰 |
| ADK 직접 호출 | 개발 중 로컬 반복 (pytest 포함) |
로컬 vs 서버사이드
- 로컬 실행: 빠른 반복. 모든 프로바이더의 모델 사용 가능
- 서버사이드 실행: 이미 배포된 에이전트의 세션·trace를 그대로 채점, 또는 user simulator를 켜서 사용자 반응이 오기 전에 trace를 미리 생성
모든 실험 아티팩트는 Cloud Storage에 투명하게 저장돼서 버전 관리와 감사(audit)가 가능합니다.
코드 기반 커스텀 메트릭 예시
# code-based metric: 정확히 이런 형태의 함수를 등록한다
from agent_platform.eval import code_metric
@code_metric(name="json_shape_check")
def json_shape_check(response: str, expected: dict) -> float:
"""응답이 기대한 JSON 스키마를 따르는지 확인한다."""
import json
try:
parsed = json.loads(response)
except json.JSONDecodeError:
return 0.0
# 필수 키가 모두 있는지 확인
required_keys = set(expected.keys())
if not required_keys.issubset(parsed.keys()):
return 0.0
return 1.0
코드 기반 메트릭과 계산 기반 메트릭(ROUGE, BLEU, MetricX, COMET, exact match)은 추가 비용이 들지 않습니다. LLM-as-a-judge 계열만 모델 호출 표준 요금이 붙어요.
Adaptive Rubric — Google DeepMind와 공동 개발한 LLM-judge
왜 "적응형"인가
일반적인 LLM-judge는 고정된 프롬프트로 채점해요. Adaptive Rubric은 다릅니다. eval case 정의 + 개발자 지시문 + 도구 선언을 읽고, 그 케이스에만 해당하는 pass/fail 루브릭을 즉석에서 생성합니다. 그리고 그 루브릭 하나하나에 대해 판정(verdict)과 근거(rationale)를 함께 돌려줘요.
기본 제공 메트릭 (20종 이상)
- Task Success: 대화 전반에 걸친 목표 달성도 (관찰 가능한 결과 + 확인 응답 기준)
- Tool Use Quality: 도구 선택, 인자 정확성, 스키마 준수
- Safety: 혐오·괴롭힘·위험 콘텐츠·성적 표현·PII 정책 위반 여부
- Trajectory Quality / Final Response Quality / Hallucination / Grounding
- 이미지·비디오 품질 메트릭
이슈 클러스터링
대규모 평가 잡에서는 실패 케이스를 자체 실패 분류 체계(taxonomy)에 맞춰 클러스터링해줍니다. 분류 체계가 없다면 사전 구축된 adaptive rubrics용 taxonomy를 쓸 수 있어요.
한계와 주의사항 (비판적 시각)
솔직히 짚어야 할 부분이 있습니다.
- LLM-judge의 판정은 여전히 확률적입니다. Adaptive Rubric이 근거를 함께 주는 건 큰 진전이지만, judge 모델 자체가 틀릴 수 있다는 전제는 유지돼요. 특히 도메인 특화 판단(의료·법률·금융)에서는 자체 코드 기반 메트릭을 반드시 병행하세요.
- 비용 구조가 트래픽에 비례합니다. 온라인 모니터를 전수(full)로 돌리면 요금이 급증해요. 내장된 샘플링과 타겟 필터를 반드시 설정하고, 드리프트 알림은 임계값 기반으로 걸어두는 게 안전합니다.
- 국내 규제 환경: PII 정책 위반 스코어가 나온다고 해서 그게 곧 컴플라이언스 통과를 의미하지는 않아요. 개인정보보호법 관점의 별도 검토가 필요합니다.
자연어 가이드라인
루브릭 생성을 자연어 지침으로 유도할 수 있고, 생성된 루브릭 그룹은 리뷰 후 다른 에이전트에 재사용 가능합니다. 팀 단위로 루브릭 자산을 축적하는 워크플로우가 가능해진다는 뜻이에요.
배포 후에는 Cloud Trace에서 trace를 원클릭으로 평가하거나, 온라인 모니터를 세워 라이브 트래픽을 채점합니다. 대시보드에서 시간에 따른 점수 추이를 보고, 드리프트 알림을 이메일·Slack 등으로 받을 수 있어요.
정리 — "날카로운 테스트"보다 "지속되는 측정"이 이긴다
이번 GA의 진짜 의미는 기능 추가가 아니라 측정의 연속성입니다.
- 개발 중 로컬 실험과 배포 후 라이브 트래픽이 같은 메트릭, 같은 레지스트리로 돌아감
- 프로덕션 점수가 흔들리면, 그건 에이전트 문제지 측정 방식 문제가 아님
- 아티팩트는 Cloud Storage에 남아서 감사·버전 관리 가능
- 케이스 생성기 + user simulator + environment simulator로 손으로 못 만드는 시나리오까지 커버
특히 environment simulator는 실무에서 체감이 큽니다. 백엔드가 느리거나 실패할 때 에이전트가 어떻게 버티는지, 프로덕션을 건드리지 않고 미리 볼 수 있거든요. 국내 환경처럼 외부 API 장애가 잦은 곳에서는 거의 필수에 가깝습니다.
다음 단계 학습 방향
- ADK 기반 에이전트에 eval 세트를 붙이고 pytest로 CI에 태워보기 — 여기서부터 시작하세요.
- Adaptive Rubric으로 자체 taxonomy 만들기 — 팀 도메인에 맞는 실패 유형을 정의하는 게 자산입니다.
- 온라인 모니터 + 드리프트 알림 세팅 — 배포 다음 주에 반드시 필요해집니다.
함께 보면 좋은 글
- AI 에이전트가 돈을 내고 API를 쓴다? 클라우드플레어의 새로운 결제 게이트웨이 분석 — 에이전트가 실제 결제 주체가 되는 시대의 인프라 변화
- Claude Opus 4.6, Microsoft Foundry 공식 출시 — 코딩과 에이전트 워크플로우의 새로운 기준 — 평가 대상이 되는 모델 쪽의 최신 동향