ADK live evaluation으로 음성 AI 에이전트를 테스트하는 법

음성 AI 에이전트는 데모에서는 쉽게 좋아 보인다. 사용자가 또렷하게 말하고, 중간에 끼어들지 않고, 정해진 순서대로 답하면 대부분 잘 작동한다. 문제는 실제 통화다. 사용자는 질문을 건너뛰고, 말을 바꾸고, 생년월일을 다른 형식으로 말하고, 중간에 끼어들고, 에이전트가 아직 말하는데 다른 질문을 한다. Google은 ADK에 live evaluation을 넣어 이 문제를 자동 테스트 루프로 다루는 방법을 공개했다. simulated user가 실제 오디오를 생성하고, live agent가 음성 스트림으로 응답하며, rubric 기반 평가가 전체 대화 궤적을 점수화한다.

텍스트 에이전트 평가와 음성 에이전트 평가는 다르다

텍스트 에이전트는 주로 답변 내용, 도구 호출, 최종 상태를 본다. 음성 에이전트는 여기에 타이밍과 복구 능력이 추가된다. 사용자가 말을 끊었을 때 멈추는가, 한 번에 질문을 하나만 하는가, 민감한 정보를 말하기 전에 신원을 확인하는가, 잘못 들은 정보를 다시 확인하는가, 마지막에 통화를 자연스럽게 닫는가를 봐야 한다.

Google의 예시는 care-team assistant다. greeter_agent가 이름을 확인하고, dob_verifier_agent가 생년월일을 받아 validate_date_of_birth 도구를 호출하고, goals_agent가 검증 뒤 예약 정보를 안내한다. 각 단계는 gemini-live-2.5-flash-native-audio를 쓰고, Workflow가 순서를 연결한다. 사용자 입장에서는 agent handoff가 보이지 않고 하나의 통화처럼 이어진다.

eval set은 정답 스크립트보다 상황 설명이 중요하다

ADK live evaluation은 두 방식의 테스트 케이스를 지원한다. 하나는 conversation scenario다. starting_prompt, conversation_plan, user_persona를 적으면 simulated user가 목표를 따라 대화를 즉흥적으로 진행한다. 예를 들어 “John Doe로 응답하고, 생년월일은 July 12th, 1985라고 말하고, 예약 준비물을 묻고, 질문이 없으면 통화를 마무리하라”처럼 쓴다.

다른 하나는 fixed conversation이다. 사용자의 발화를 그대로 스크립트로 지정한다. 정해진 regression test에는 fixed가 좋고, 실제 변동성을 보려면 scenario가 좋다. 실무에서는 둘을 섞어야 한다. 결제 취소, 본인 확인, 의료 예약, 배송 변경처럼 법적·운영상 중요한 흐름은 fixed로 잠그고, 일반 상담은 scenario로 폭넓게 흔드는 편이 낫다.

live_model_config와 audio simulator 설정

테스트 설정에는 live_model_config를 넣어 live mode를 켠다. 이를 빼면 같은 케이스도 standard text mode로 돈다. user_simulator_config에서는 type을 llm_audio로 지정하고, simulated user의 turn-taking logic을 담당할 모델과 audio_model을 분리한다. Google 예시는 model에 gemini-3.7-flash, audio_model에 gemini-3.1-flash-tts-preview를 사용하고, voice_name과 language_code를 지정한다.

이 분리는 실무적으로 중요하다. 대화 전략을 만드는 모델과 음성을 합성하는 모델은 다른 문제를 푼다. 한국어 상담센터라면 language_code와 voice profile을 다양하게 바꿔야 한다. 젊은 사용자, 고령 사용자, 짧게 답하는 사용자, 말이 긴 사용자, 중간에 정정하는 사용자 persona를 나눠야 실제 실패가 보인다.

rubric은 “좋은 답변”보다 “위험한 순서”를 잡아야 한다

음성 에이전트 평가는 정답 문장 하나로 채점하기 어렵다. 같은 의미를 수백 가지 표현으로 말할 수 있기 때문이다. 그래서 ADK는 rubric 기반 multi-turn trajectory quality 평가를 사용한다. 예시 rubric은 “에이전트가 예약 정보를 공개하기 전에 이름과 생년월일을 확인했는가” 같은 end-to-end 기준이다.

좋은 rubric은 문체를 평가하지 않는다. 위험한 순서와 필요한 상태 변화를 평가한다. 예를 들어 금융 에이전트라면 “계좌 잔액을 말하기 전 2단계 인증을 완료했는가”, “사용자가 송금을 취소한다고 말한 뒤 도구 호출을 중단했는가”, “인증 실패 후 개인정보를 반복해서 말하지 않았는가”가 중요하다. 친절한 말투보다 이런 기준이 먼저다.

CI에 넣을 때 현실적인 기준

음성 평가는 텍스트 테스트보다 느리고 비싸다. 모든 PR마다 전체 suite를 돌리면 개발 속도가 떨어진다. 좋은 전략은 계층화다. 빠른 unit-style text eval은 모든 PR에서 돌리고, 핵심 음성 scenario 3~5개만 PR gate에 넣는다. 전체 persona와 음성 조합은 nightly로 돌린다. 모델이나 prompt를 바꾸는 PR에는 live eval 범위를 넓힌다.

또한 max_allowed_invocations를 둬야 한다. simulated user가 목표를 만족하지 못하거나 agent가 루프에 빠지면 비용이 계속 늘 수 있다. timeout_seconds도 필수다. 실패 로그에는 transcript뿐 아니라 inline playable audio를 남겨야 한다. 텍스트상 문제없어 보이는 응답도 음성으로 들으면 끊김, 반복, 이상한 억양, 너무 긴 침묵이 드러난다.

운영팀이 보는 지표

개발팀은 eval pass rate를 보지만 운영팀은 다른 지표를 봐야 한다. 평균 통화 길이, 본인 확인 실패율, 도구 호출 실패율, 사용자의 반복 질문 비율, human handoff 비율, 민감정보 노출 시도 차단률을 함께 봐야 한다. live eval은 출시 전 테스트고, 실제 운영 로그는 출시 후 테스트다. 둘이 연결되어야 한다.

실패 사례는 rubric으로 되돌려야 한다. 실제 상담에서 사용자가 “아까 말했잖아요”라고 했는데 에이전트가 다시 같은 질문을 했다면, 다음 eval suite에 “이미 제공한 정보를 다시 묻지 않음” rubric과 scenario를 추가한다. 음성 에이전트 품질은 한 번에 완성하는 것이 아니라 실패를 테스트 케이스로 바꾸는 루프에서 좋아진다.

실행 체크리스트

• demo 통화가 아니라 실제 실패할 상황을 conversation scenario로 쓴다.
• fixed conversation과 scenario 기반 테스트를 섞는다.
• persona, voice, language_code를 다양화한다.
• rubric은 말투보다 순서, 인증, 도구 호출, 정보 공개 조건에 맞춘다.
• max_allowed_invocations와 timeout_seconds를 반드시 둔다.
• PR gate에는 핵심 live eval만, nightly에는 전체 suite를 둔다.
• 실패 transcript와 audio를 함께 저장해 사람이 재검토한다.
• 운영 로그에서 나온 실패를 다음 eval case로 되돌린다.

ADK live evaluation의 핵심은 음성 에이전트를 “느낌상 괜찮다”에서 “반복 측정 가능하다”로 옮기는 것이다. 실제 통화는 텍스트보다 지저분하다. 그래서 더더욱 자동화된 simulated user, 오디오 기반 테스트, rubric 점수, CI 연결이 필요하다. 음성 AI를 프로덕션에 넣는 팀이라면 첫 기능보다 먼저 평가 루프를 설계해야 한다.