ADK 11종 선정 근거 — eval_ph1 메트릭 매핑 전수표

2026. 7. 2. · "왜 이 11개인가"와 "우리 지표에 어떻게 대응되는가"에 대한 방어 문서

1. 왜 이 11개인가 — "선별"이 아니라 "전수(全數)"

이 11종은 누군가 골라낸 목록이 아니라, Google이 ADK 평가 모듈의 공식 지원 기준(supported criteria)으로 선언한 전부다. 세 곳이 같은 11개를 가리킨다:

공식 문서 — ADK Criteria 페이지가 정확히 이 11개를 "지원 평가 기준"으로 나열
소스코드 — PrebuiltMetrics enum의 전체 항목과 1:1 일치
레지스트리 — 기본 메트릭 레지스트리(DEFAULT_METRIC_EVALUATOR_REGISTRY)에 등록되는 evaluator 전부와 1:1 일치

따라서 "왜 11개를 골랐나"라는 질문은 성립하지 않는다. 취사선택 의혹 자체가 불가능한 구성이며, 선택이 들어간 지점은 그 다음 단계 — 전수 검토 후 우리 환경 기준의 채택/배제(§2)다.

구글의 공식 선언 근거

근거	내용
평가 철학 선언	공식 문서가 에이전트 평가를 두 축으로 명시 — 궤적·도구 사용(trajectory & tool use) + 최종 응답(final response). 근거 논리: "LLM 에이전트는 확률적 특성 때문에 결정론적 합/불 단정이 부적절 → 산출물과 궤적 모두의 정성 평가 필요"
공식 기준 목록	Criteria 페이지에 11종 전체가 지원 기준으로 등재
확장 이력 공식 발표	Google Developers Blog (2025-11-07) — user simulation + 멀티턴 평가 발표. 멀티턴 4종의 출처
제품 계보	4종(safety_v1 + 멀티턴 3종)이 위임하는 대상이 Vertex AI Gen AI Evaluation Service — 구글 클라우드의 정식(GA) 평가 제품
교육 자료	공식 Codelab 존재 — 정식 기능으로 교육 체계까지 구축

11개의 내적 구조 — 두 축 + 확장의 스냅샷

응답 축의 진화: response_match_score(결정론) → final_response_match_v2(LLM 심판) → rubric_based_..._v1(루브릭) — v1/v2 접미사가 진화 중이라는 증거
도구 축: tool_trajectory_avg_score → rubric_based_tool_use_quality_v1
신뢰성 확장: hallucinations_v1(근거성) · safety_v1(안전)
멀티턴 확장 (2025-11 공식 발표): 시뮬레이터 품질 + 멀티턴 3종

과장하면 안 되는 선: ① 업계 합의 표준이 아니라 구글 프레임워크의 내장 기준이다 (에이전트 평가에 업계 표준은 아직 없음). ② 문서에는 표기가 없지만 소스코드에는 9종에 @experimental 데코레이터가 붙어 있다 — 발표에선 "일부는 아직 진화 중"으로 정직하게.

2. ADK 11종 → eval_ph1 메트릭 매핑 전수표

eval_ph1에서 취합·운영해 온 성과·운영 지표 — pass@1 · pass^k · grounded% · claim_verified_rate · cite_f1 · recency/stale · format_valid · loop_rate · tool_error · tokens/latency(p95) · 6차원(Task/Coordination/Tool/Efficiency/Safety/Alignment) — 에 ADK 11종을 하나씩 매핑한 결과:

채택 — 기존 지표의 상위 호환

배제 — 근거 있는 탈락

보류 — 멀티턴 도입 시 재검토

채택 5종 기존 지표의 판정 방식을 업그레이드

ADK 메트릭	대응 eval_ph1 지표	선정 이유
final_response_match_v2	pass@1 · pass^k 판정기, Task 차원(expect_contains)	pass@1의 근간인 "정답과 일치하는가" 판정을 문구 포함 체크 → 의미 동치 판정(심판 5회 다수결)으로 업그레이드. 표현이 달라도 맞으면 pass — 오탐·미탐 동시 감소. pass^k 집계는 유지, 판정기만 교체
hallucinations_v1	grounded% · grounded_pct · claim_verified_rate, Safety 근거모순 게이트	플라이휠 핵심 지표 grounded%의 판정이 기존엔 도메인 규칙(수치 대조) → 문장 분해 → 문장별 supported/unsupported 라벨 → 비율 산출로 일반화. grounded%의 정의를 그대로 문장 단위로 계산하는 구현체. claim_verified_rate와 개념 동일
tool_trajectory_avg_score	Tool 차원(도구 선택·인자), tool_error 보완	기존은 도구명 포함 + 인자 존재만 확인 → 이름+인자 내용을 기대 궤적과 대조, EXACT/IN_ORDER/ANY_ORDER 완화 옵션. 더 엄격한 상위 호환
rubric_based_final_response_quality_v1	Alignment 차원(톤·형식), format_valid · format_invalid_rate	Tier 2로 보류했던 Alignment의 실제 구현체. format_valid가 잡던 형식 준수를 yes/no 루브릭 명세로 정성 확장 (예: "존댓말인가", "다음 단계를 안내했는가")
rubric_based_tool_use_quality_v1	Tool·Coordination 정성 측면, loop_rate의 정성 판정	기대 도구 목록을 사전 정의할 수 없는 태스크용 reference-free 판정. loop_rate가 수치로 잡던 "불필요한 반복 호출"을 루브릭 항목으로 정성 검증 가능

배제 5종 매핑은 되지만 근거 있는 탈락

ADK 메트릭	대응 지표	배제 이유
response_match_score	Task의 expect_contains, field_accuracy류 결정론 비교	같은 계열(결정론 텍스트 비교)이나 ROUGE-1 + 영어 stemmer라 한국어 부적합. 기존 방식이 우리 언어 환경에서 더 신뢰 가능
safety_v1	Safety 차원의 유해성 부분	Vertex AI(GCP 유료) 위임 — 환경 제약. PII 탐지는 ADK에 아예 없어 기존 커스텀 유지
multi_turn_task_success_v1	pass@1의 멀티턴 확장 개념	GCP 위임 + 판정 기준 불투명
multi_turn_trajectory_quality_v1	loop_rate · terminated_by가 보던 경로 품질의 멀티턴판	GCP 위임
multi_turn_tool_use_quality_v1	tool_error · Tool 차원의 멀티턴판	GCP 위임

보류 1종

ADK 메트릭	사유
per_turn_user_simulator_quality_v1	대응 기존 지표 없음 — 멀티턴 시뮬레이션 미운영. 멀티턴 평가셋 도입 시 재검토

ADK가 못 덮는 우리 고유 지표 → 커스텀 유지 (하이브리드의 근거)

운영성 전부: total_tokens · tokens_per_success · overhead_tokens · p95_latency · loop_rate · terminated_by · kill_rate — ADK의 Invocation 스키마에는 usage/지연 필드 자체가 없음
협업: Coordination(역할 준수) — ADK에 멀티에이전트 협업 메트릭 없음
인용·최신성: cite_f1 · recency_score · stale — ADK 전무
PII — ADK 전무
pass^k 집계 체계 — ADK는 단건 채점만, 반복 신뢰성 집계는 우리 하네스 고유

3. 최종선정표 — 이식 후 확정 메트릭 구성

매핑 결과를 반영한 최종 메트릭 라인업. 채택된 ADK 5종 + 커스텀 유지 지표가 어떤 기존 지표를 계승하고 어떤 역할(가중 차원 / 거부권 게이트 / 운영 진단 / 집계)을 맡는지의 확정안:

영역	최종 메트릭	출처	계승하는 기존 지표	채점 방식	역할
응답 정확성	final_response_match_v2	ADK	pass@1·pass^k 판정기, Task(expect_contains)	LLM 심판 5회 다수결	가중 차원 (Task)
응답 금지어	must_not_contain	커스텀	Task의 must_not_contain (대표 환각 차단)	결정론 (문구 검사)	가중 차원 (Task 보조)
근거성 (환각)	hallucinations_v1	ADK	grounded% · claim_verified_rate · Safety 근거모순	LLM 문장 단위 검증	거부권 (veto)
개인정보	pii_gate	커스텀	Safety PII 정규식 (이메일·전화·주민번호)	결정론 (정규식)	거부권 (veto)
도구 궤적	tool_trajectory_avg_score	ADK	Tool 차원 (선택·인자), tool_error 보완	결정론 (IN_ORDER 대조)	가중 차원 (Tool) · 도구 재활성화 시
도구 정성	rubric_based_tool_use_quality_v1	ADK	loop_rate 정성 판정, 기대 궤적 없는 태스크의 Tool	LLM 루브릭 (reference-free)	선택 적용 (진단 보조)
톤·형식	rubric_based_final_response_quality_v1	ADK	Alignment(Tier 2 스텁 → 실구현), format_valid	LLM 루브릭 (yes/no)	가중 차원 (Alignment)
협업	role_participation	커스텀	Coordination 역할 준수 (info_fidelity는 hallucinations_v1이 흡수)	결정론 (author 검사)	가중 차원 (Coordination)
효율	efficiency	커스텀	tokens_per_success · overhead_tokens · p95_latency · 턴 수	결정론 (예산 대비 정규화)	가중 차원 (Efficiency)
운영 진단	loop_rate · terminated_by · tool_error · kill_rate	커스텀	(그대로 유지)	로그 집계	대시보드 진단 (채점 밖)
신뢰성 집계	pass^k (k=5)	커스텀	pass^k — 판정기만 v2로 교체, 집계 방식 유지	동일 작업 5회 반복	종합 신뢰성 지표
최종 합성	가중평균 + veto + A~F	커스텀	ScoringPipeline (거부권·등급) 유지	가중합산 → 게이트 → 등급	최종 판정

탈락분의 커버 경로 — "빠진 구멍 없음" 확인

탈락 메트릭	그 역할을 대신 맡는 것
response_match_score	커스텀 `must_not_contain` + `final_response_match_v2` — 결정론 비교가 필요한 케이스는 기존 substring, 의미 비교는 v2가 커버 (한국어 안전)
safety_v1	유해성 일반 판정은 공백으로 인정(현 도메인상 위험 낮음) — PII는 `pii_gate`, 환각은 `hallucinations_v1`이 커버. GCP 도입 시 재검토
multi_turn_* 3종	현재 싱글턴 평가만 운영 — 공백 아님. 멀티턴 도입 시 시뮬레이터(`per_turn_user_simulator_quality_v1`)와 함께 일괄 재검토

요약: 최종 구성 = ADK 5종 + 커스텀 7계열. 가중 차원 6개 구조와 pass^k·거부권·등급 합성은 유지되고, 차원별 판정기가 ADK 상위 호환으로 교체되는 그림. 탈락 6종의 역할은 전부 대체 경로가 있거나 현 운영 범위 밖임을 명시.

4. 왜 최종 형태가 "Google ADK 중심"인가 — 대안 비교와 결정 구조

프레임부터 정정: 최종 형태는 "ADK 중심"이 아니다. 중심은 우리 6차원 설계·평가셋·축적 데이터·pass^k이고, ADK는 그 안의 판정기 엔진으로 채택된 부품이다. 질문이 나오면 이 정정이 첫 문장 — "중심은 바뀌지 않았습니다. 판정기를 교체한 것입니다."

그래도 "왜 엔진이 ADK인가" — 근거 5가지

#	근거	내용
1	런타임 진영에 대안이 없다 (필요의 근거)	우리 실행 런타임은 AutoGen인데, AutoGen 공식 평가 도구 AutoGenBench는 벤치마크 실행 하네스(다운로드·실행·로깅)일 뿐 — 로그를 "메트릭 스크립트로 분석하라"는 구조이고 핵심 메트릭(비용·완료시간·턴수)은 로드맵 단계다. 자체 휴리스틱의 한계(도메인 하드코딩·매직 넘버)는 이미 확인 → 메트릭 체계는 밖에서 가져와야 했다
2	범주 적합성 (에이전트 네이티브)	대안들(RAGAS·DeepEval·TruLens)은 RAG/단일 LLM 앱 평가에서 출발해 에이전트로 확장 중인 계보. ADK는 처음부터 에이전트 평가 전용 — 궤적+응답 2축 선언, Invocation 스키마에 서브에이전트 author 명시(멀티에이전트 1급 시민), 도구 궤적 EXACT/IN_ORDER/ANY_ORDER 매칭. 우리 평가 대상이 정확히 MAS다
3	종속 없는 채택 가능성 (소스 실사로 확인)	Apache-2.0 오픈소스·로컬 실행(SaaS 아님), `evaluate_invocations()` 라이브러리 호출 가능, 심판 모델은 LLMRegistry로 자유(GLM 가능 — Gemini 잠금 아님), `custom_function_path`로 우리 지표를 1급 등록. LangSmith(SaaS·LangChain 종속)나 Vertex 직접 사용(GCP 종속)과 달리 폐쇄망·정액 플랜 환경에서 돈다
4	운영 엔지니어링 품질 (검증된 노하우)	심판 5회 다수결·동점 보수 판정·메트릭별 장애 격리(NOT_EVALUATED)·num_samples 설정화 — 자체 구현하면 다시 밟아야 할 지뢰들이 이미 밟혀 있다. 구글이 자사 제품군에 쓰며 다듬은 운영 설계
5	지속 가능성·수렴 베팅 (bus factor)	에이전트 평가에 업계 표준이 아직 없는 상황에서, 후원자 규모가 가장 큰 후보 — 구글 대표 에이전트 프레임워크, Vertex 정식 제품 계보, 2025-11 공식 로드맵 발표, Codelab 교육 체계. 표준이 어디로 수렴하든 "궤적+응답" 2축 구조는 공통분모

대안 비교 요약

후보	출발 범주	멀티에이전트 궤적	배포 형태	종속성	판정
Google ADK eval	에이전트 평가 전용	◎ (2축 설계·author 스키마)	오픈소스·로컬	낮음 (심판 모델 자유)	채택
DeepEval	LLM 앱 전반 (50+ 메트릭)	○ (agentic 확장)	오픈소스 + 상용 SaaS 견인	단일 벤더(Confident AI)	차선 — §반론 참조
RAGAS	RAG 특화	△ (후발 확장)	오픈소스	낮음	범주 불일치 (RAG 아님)
LangSmith	관측+평가 플랫폼	○	SaaS (유료)	LangChain 생태계	배제 — SaaS·생태계 종속
AutoGenBench	벤치마크 실행 하네스	— (메트릭 없음)	오픈소스	AutoGen	메트릭 라이브러리 아님
자체 유지	—	—	—	—	한계 확인 (하드코딩·매직넘버·스텁)

예상 반론 처리

"DeepEval이 메트릭은 더 많지 않나?" — 맞다(50+). 하지만 필요한 건 개수가 아니라 우리 6차원에 대응하는 판정기 품질과 확장점이고, ADK는 그 대응을 소스 수준까지 실사 완료했다. DeepEval은 단일 스타트업의 상용 SaaS 견인 구조라 지속 가능성 축에서 열세.
"구글 것이라 고른 것 아닌가?" — 구글이라는 사실이 주는 실질 가치는 두 가지로 한정해 답한다: 운영 노하우의 선반영(근거 4)과 지속 투자 신호(근거 5). 나머지는 브랜드가 아니라 기술 실사(근거 1~3) 결과다.
"실험 단계 API인데 확정해도 되나?" — 이 결정은 가역적(two-way door)으로 설계됐다. ADK 접점을 어댑터 한 파일로 국소화해 스위칭 비용을 낮췄기 때문에, "확정"의 실질 부담이 낮다. 락인 없이 채택했다는 것 자체가 채택 근거다.

한 문장 답변: "체계의 중심은 저희가 운영해 온 6차원 설계와 축적 데이터 그대로이고, ADK는 판정기 엔진으로 채택한 것입니다. 엔진 후보 중 ADK를 고른 이유는 — 저희 런타임 진영에는 메트릭 체계가 아예 없고, 대안들은 RAG 평가에서 출발한 반면 ADK만이 멀티에이전트 궤적을 처음부터 1급으로 설계했으며, 소스 실사 결과 심판 모델 자유·커스텀 등록·로컬 실행까지 종속 없이 쓸 수 있음을 확인했기 때문입니다. 그리고 어댑터 한 파일로 격리해 언제든 되돌릴 수 있는 구조라, 확정의 리스크 자체가 낮습니다."

5. 발표용 멘트

"선정 과정은 이렇습니다. ADK가 공식 지원하는 11종 전수를, 저희가 eval_ph1에서 운영해 온 지표 체계 — pass@1, grounded%, loop_rate, 형식 준수율 같은 성과·운영 지표들 — 에 하나씩 매핑했습니다. 그 결과 5종은 기존 지표의 판정 방식을 업그레이드하는 상위 호환으로 확인되어 채택했습니다. 예를 들어 pass@1의 판정기는 문구 포함 체크에서 의미 동치 판정으로, grounded%의 판정은 도메인 규칙에서 문장 단위 검증으로 올라갑니다. 5종은 GCP 종속·한국어 부적합으로 근거를 남기고 배제, 1종은 멀티턴 도입 시점으로 보류했습니다. 그리고 비용·지연·협업·인용 같은 저희 운영 지표는 ADK에 존재하지 않아 커스텀으로 유지합니다 — 이것이 하이브리드 구성의 이유입니다."

이 서사의 방어선: "왜 11개냐" → 구글 공식 전수 · "왜 이걸 채택했냐" → 기존 지표별 매핑 근거 · "기존 작업은 버려지냐" → 지표 정의는 유지, 판정기만 교체. 세 질문이 한 줄기로 방어된다.

관련: 5분 발표 최종 대본 · eval_ph1 한 장 요약 (화면 2) · ADK 메트릭 정리 (화면 3) · 보고용 브리핑 6버전
출처: ADK — Why evaluate agents · ADK — Criteria (지원 메트릭 목록) · Google Developers Blog — User Simulation in ADK Evaluation · Google Codelabs — Evaluating Agents with ADK · github.com/google/adk-python (PrebuiltMetrics · llm_as_judge.py · metric_evaluator_registry.py 직접 확인)