ADK Live Voice Agent 평가법: 음성 에이전트를 데모가 아니라 회귀 테스트로 검증하는 순서

음성 에이전트는 데모에서 속이기 쉽다. 조용한 환경에서 정해진 질문을 던지면 그럴듯하게 대답한다. 하지만 실제 고객은 끼어들고, 날짜를 애매하게 말하고, 같은 말을 반복하고, 중간에 질문을 바꾼다. 텍스트 챗봇보다 실패 모드가 많다. 그래서 “한 번 통화해 보니 괜찮다”는 기준으로 배포하면 위험하다.

Google은 2026년 8월 24일 Agent Development Kit(ADK)에 live evaluation을 제공한다고 설명했다. 핵심은 live voice agent를 실제 오디오 입력으로 테스트하고, 시뮬레이션 사용자가 음성으로 대화하며, 결과를 transcript와 audio clip으로 다시 확인하는 루프다. 기존 텍스트 에이전트 평가처럼 CI/CD에 넣을 수 있다는 점도 중요하다.

이 글은 ADK 사용법을 그대로 번역하는 글이 아니다. 실무 개발자가 음성 에이전트 평가를 설계할 때 어떤 순서로 케이스를 만들고, 어떤 rubrics를 넣고, 어느 지점에서 release gate를 걸어야 하는지 정리한다.

음성 에이전트는 최종 답변만 보면 안 된다

텍스트 챗봇은 최종 응답만 봐도 어느 정도 품질을 판단할 수 있다. 음성 에이전트는 그렇지 않다. 사용자의 말을 제대로 들었는지, 끼어들기를 처리했는지, 신원 확인 전에 민감 정보를 말하지 않았는지, 도구 호출이 알맞은 시점에 일어났는지, 잘못 들은 값을 다시 확인했는지까지 봐야 한다.

예를 들어 병원 예약 안내 에이전트라면 “화요일 3시 예약입니다”라는 최종 문장이 맞아도 실패일 수 있다. 이름과 생년월일 확인 전에 예약 정보를 말했으면 정책 위반이다. 생년월일을 들었지만 YYYY-MM-DD로 정규화하지 못해 검증 도구를 잘못 호출했어도 실패다. 사용자가 “잠깐만요”라고 끼어들었는데 계속 말하면 경험 품질도 낮다.

따라서 평가 단위는 response가 아니라 trajectory여야 한다. 각 turn, tool call, state change, handoff, 종료 조건을 함께 본다. ADK의 live evaluation이 유용한 이유도 여기 있다. 음성 입력과 multi-turn 흐름을 같은 평가 루프에서 다룰 수 있기 때문이다.

1단계: 대화 흐름을 작은 agent로 나눈다

처음부터 하나의 거대한 음성 에이전트에 모든 instruction을 넣으면 평가하기 어렵다. ADK 예시는 greeter, date-of-birth verifier, goals agent처럼 역할을 나눈 graph workflow를 사용한다. 이 구조는 실무에서도 좋다. 실패한 구간을 찾기 쉽고, rubric도 단계별로 명확해진다.

예를 들어 고객지원 음성 에이전트라면 다음처럼 나눌 수 있다. 첫 번째 agent는 신원 확인만 한다. 두 번째 agent는 문제 유형을 분류한다. 세 번째 agent는 환불, 배송, 계정 변경 같은 workflow를 처리한다. 네 번째 agent는 요약과 종료를 맡는다. 각 agent는 하나의 책임만 가져야 한다.

이렇게 나누면 “환불 처리 실패”가 모델 문제인지, 분류 문제인지, tool parameter 문제인지 구분할 수 있다. 음성 품질 문제도 분리된다. greeting 단계에서 사용자의 이름을 잘못 들었다면 뒤 workflow가 아무리 좋아도 전체 call은 실패다. 평가 보고서가 이 구조를 따라가야 디버깅이 빨라진다.

2단계: scenario case와 fixed case를 둘 다 만든다

ADK는 conversation scenario와 fixed conversation을 모두 지원한다. scenario case는 목표와 persona를 주고 simulated user가 자연스럽게 대화를 진행한다. fixed case는 사용자의 발화를 고정한다. 둘 중 하나만 쓰면 빈틈이 생긴다.

fixed case는 회귀 테스트에 좋다. 예전에 실패했던 발화, 정책 경계, 특정 날짜 형식, 특정 상품명처럼 재현해야 하는 케이스를 그대로 넣는다. 코드의 unit test에 가깝다. prompt를 바꿔도 이 케이스는 계속 통과해야 한다.

scenario case는 실제 사용자 다양성을 보는 데 좋다. “초보 사용자가 본인 확인 후 예약 준비물을 묻는다”처럼 목표만 주면 simulator가 turn을 구성한다. 이 방식은 대화 길이, 끼어들기, 애매한 표현, 불완전한 답변을 더 잘 드러낸다. 다만 무한 대화가 되지 않도록 max_allowed_invocations 같은 turn limit을 꼭 둬야 한다.

실무에서는 release gate를 fixed case 70%, scenario case 30% 정도로 시작하는 편이 안전하다. 실패 재현과 실제 다양성을 동시에 잡을 수 있다. production 로그가 쌓이면 실패 사례를 fixed case로 승격한다.

3단계: rubric은 정책과 행동을 같이 본다

음성 에이전트 rubric은 “친절하게 답했는가”처럼 추상적이면 쓸모가 없다. 평가자가 사람이어도 흔들리고, LLM judge를 써도 일관성이 낮다. 좋은 rubric은 관찰 가능한 행동으로 써야 한다.

예를 들어 “신원 확인을 잘한다”보다 “예약 정보를 공개하기 전에 caller name과 date of birth를 모두 확인한다”가 낫다. “자연스럽다”보다 “사용자에게 한 turn에 하나의 질문만 묻고, 사용자가 답하지 않은 정보를 추측하지 않는다”가 낫다. “도구를 잘 쓴다”보다 “생년월일 검증 도구는 YYYY-MM-DD 형식으로 한 번만 호출한다”가 낫다.

rubric은 end-to-end와 per-turn으로 나눈다. end-to-end는 전체 통화 목표 달성, 정책 준수, 종료 조건을 본다. per-turn은 끼어들기 처리, 재확인, 도구 호출 형식, 금지 발화 여부를 본다. 음성 에이전트는 한 문장 실수로 신뢰가 깨지기 때문에 per-turn 지표가 특히 중요하다.

4단계: 오디오 조건을 테스트 변수로 둔다

텍스트 테스트와 달리 음성 테스트는 입력 조건이 품질을 크게 바꾼다. TTS voice, language_code, accent, speech rate, background noise, interruption timing에 따라 결과가 달라질 수 있다. ADK 예시는 Gemini TTS로 simulated user turn을 audio로 합성한다. 이걸 한 가지 voice로만 돌리면 coverage가 부족하다.

한국어 고객지원이라면 최소한 빠른 말투, 느린 말투, 숫자를 끊어 말하는 케이스, 영어 상품명이 섞인 케이스를 넣어야 한다. 날짜, 주소, 주문번호, 이메일은 음성 인식 오류가 잦다. 모델이 한 번 들은 값을 그대로 확정하지 않고 read-back confirmation을 하는지 봐야 한다.

또한 timeout_seconds를 현실적으로 잡아야 한다. 너무 짧으면 긴 통화가 실패하고, 너무 길면 runaway conversation이 비용을 태운다. 데모에서는 2분짜리 통화가 괜찮아 보여도 실제 콜센터에서는 평균 처리 시간(AHT)과 연결된다. 평가에는 품질 점수와 함께 통화 길이, turn 수, tool call 수를 남겨야 한다.

5단계: CI/CD release gate로 연결한다

음성 에이전트 평가가 진짜 힘을 가지려면 pull request나 배포 파이프라인에 들어가야 한다. prompt 한 줄, tool schema 하나, model version 하나가 통화 흐름을 바꿀 수 있기 때문이다. 수동 QA만으로는 이 변화를 따라가기 어렵다.

추천 구조는 이렇다. 개발 브랜치에서는 작은 fixed case suite를 빠르게 돌린다. main 병합 전에는 핵심 scenario suite를 추가한다. 배포 전에는 production-like voice profiles와 다국어 케이스를 돌린다. 실패하면 transcript, audio clip, tool trace를 artifact로 저장한다. 리뷰어는 최종 점수만 보지 말고 실패 turn을 바로 재생할 수 있어야 한다.

점수 기준도 하나로 끝내면 안 된다. 전체 trajectory quality가 0.7 이상이어도 개인정보 공개 rubric이 실패하면 배포를 막아야 한다. 반대로 말투 점수가 조금 낮지만 정책과 도구 호출이 모두 맞으면 warning으로 둘 수 있다. gate는 중요도별로 hard fail과 soft fail을 나눠야 한다.

실행 체크리스트

• 음성 에이전트를 greeting, verification, workflow, closing처럼 작은 단계로 나눈다.
• fixed conversation에는 과거 장애, 정책 경계, 숫자·날짜 오류 케이스를 넣는다.
• scenario case에는 persona, 목표, max turn limit을 함께 정의한다.
• rubric은 “친절함”이 아니라 확인 순서, 금지 정보 공개, tool argument 형식처럼 관찰 가능한 행동으로 쓴다.
• TTS voice, 언어, 말 속도, 숫자 표현을 테스트 변수로 둔다.
• transcript, audio clip, tool trace를 CI artifact로 저장한다.
• hard fail rubric과 soft fail rubric을 분리한다.

ADK Live Voice Agent 평가는 음성 에이전트를 “느낌상 괜찮다”에서 “변경할 때마다 검증한다”로 옮기는 장치다. 제품에 음성 권한과 실제 업무 도구를 붙일수록 이 차이는 커진다. 데모가 잘 되는지보다 다음 배포에서도 같은 정책을 지키는지가 더 중요하다.