ADK 라이브 보이스 에이전트 평가법: 데모가 아니라 회귀 테스트로 검증하는 방법

음성 AI 에이전트는 데모에서 잘 작동해도 실제 운영에서 쉽게 무너진다. 사용자가 말을 끊거나, 생년월일을 다른 형식으로 말하거나, 확인 질문을 건너뛰거나, 도구 호출이 한 턴 늦어지면 전체 경험이 흔들린다. Google은 Agent Development Kit, ADK에 live evaluation을 추가해 이런 문제를 자동으로 검증할 수 있게 했다. 공식 글은 How to Evaluate Live & Voice Agents in ADK에서 확인할 수 있다.

핵심은 음성 에이전트를 텍스트 챗봇처럼 “답변만 읽고 평가”하지 않는 것이다. ADK는 시뮬레이션 사용자가 실제 오디오를 생성해 live agent와 대화하게 하고, 대화 전체를 rubric으로 평가한다. Gemini TTS로 사용자 발화를 만들고, live model이 응답하고, 결과 transcript와 audio clip을 ADK Web에서 확인하는 구조다.

문제: 음성 에이전트는 정답보다 순서가 중요하다

콜센터, 병원 예약, 보험 상담, 배달 문의 같은 음성 에이전트는 단순히 자연스러운 말투만으로 평가할 수 없다. 사용자의 신원을 확인하기 전에 예약 정보를 말하면 안 된다. 생년월일을 들었으면 다시 읽어 확인해야 한다. 사용자가 질문을 했으면 먼저 답하고, 그 다음 다음 단계로 넘어가야 한다. 한 번의 순서 오류가 개인정보 유출이나 잘못된 업무 처리로 이어질 수 있다.

텍스트 에이전트에서는 로그를 보고 수정하기 쉽다. 하지만 음성은 타이밍과 회복 능력이 중요하다. 사용자가 중간에 끼어들었을 때 멈추는지, 말을 잘못 알아들었을 때 재확인하는지, 긴 침묵 뒤에 적절히 이어가는지, 도구 호출이 늦어졌을 때 설명하는지 봐야 한다. 사람이 직접 매번 통화 테스트를 하면 비용이 크고 반복성이 떨어진다.

그래서 필요한 것이 live evaluation이다. “한 번 통화해 보니 괜찮다”가 아니라, 대표 시나리오 30개를 매 릴리스마다 돌리고 기준 미달 케이스를 잡아내는 체계가 필요하다. 음성 에이전트가 운영 업무를 맡는 순간 eval은 선택이 아니라 배포 게이트가 된다.

원인: 프롬프트 수정과 모델 변경은 대화 궤적을 바꾼다

음성 에이전트는 작은 변경에도 행동이 달라진다. 시스템 프롬프트에 “친근하게 말하라”를 추가했더니 신원 확인 전에 정보를 말할 수 있다. 모델을 더 빠른 버전으로 바꿨더니 사용자의 정정 발화를 놓칠 수 있다. 도구 스키마를 바꿨더니 검증 함수 호출이 한 턴 늦어질 수 있다. 이런 변화는 단일 응답 평가로는 잘 드러나지 않는다.

ADK 글의 예시는 병원 care-team assistant다. greeter_agent가 이름을 확인하고, dob_verifier_agent가 생년월일을 받아 validate_date_of_birth 도구를 호출하고, goals_agent가 예약 정보를 안내한다. 중요한 것은 각 agent가 단일 목적을 갖고 workflow로 이어진다는 점이다. 사용자는 내부 handoff를 느끼지 못하지만, 시스템은 단계별 책임을 나눠 관리한다.

이 구조는 평가에도 유리하다. “이름 확인 전 개인정보를 말하지 않았는가”, “생년월일을 YYYY-MM-DD 형식으로 도구에 넘겼는가”, “예약 정보를 말한 뒤 사용자의 질문에 답했는가”처럼 end-to-end 기준을 세울 수 있다. 평가 기준은 자연어 rubric으로 작성하고, judge model이 전체 대화 궤적을 채점한다.

해결: 시나리오형 eval과 고정 대화 eval을 같이 써라

ADK는 두 가지 테스트 스타일을 지원한다. 첫째는 conversation scenario다. 시작 발화, 사용자 목표, persona를 적으면 시뮬레이션 사용자가 즉흥적으로 대화한다. 예를 들어 “John Doe로 답하고, 생년월일은 1985년 7월 12일이라고 말하고, 예약에 무엇을 가져가야 하는지 묻고, 마지막에는 질문이 없다고 말한다”처럼 계획을 준다. NOVICE persona를 쓰면 사용자가 구체 정보를 먼저 다 말하지 않고 에이전트의 질문을 기다린다.

둘째는 fixed conversation이다. 사용자 발화를 그대로 스크립트로 넣는다. 이 방식은 회귀 테스트에 좋다. 과거 장애를 재현하거나, 특정 발음·표현·순서에서 실패했던 케이스를 고정할 수 있다. 예를 들어 “칠월 십이일 팔십오년생이요”처럼 한국어 서비스에서 자주 나오는 표현을 넣어두면, 파서와 확인 로직이 깨지는지 지속적으로 확인할 수 있다.

실무에서는 둘을 섞어야 한다. 시나리오형 eval은 예상 밖 변형을 잡고, 고정 eval은 알려진 장애 재발을 막는다. 배포 전에는 빠른 smoke suite를 돌리고, 야간에는 더 긴 regression suite를 돌리는 방식이 적합하다.

평가 기준은 답변 품질보다 업무 안전을 먼저 본다

음성 에이전트 평가 rubric은 예쁜 말투보다 업무 규칙을 먼저 봐야 한다. 병원 예약 에이전트라면 “신원 확인 전 예약 정보를 공개하지 않는다”가 1순위다. 금융 상담 에이전트라면 “본인 인증 전 계좌 잔액이나 거래 내역을 말하지 않는다”가 1순위다. 쇼핑 환불 에이전트라면 “정책 한도를 넘는 환불을 승인하지 않는다”가 1순위다.

그 다음이 대화 품질이다. 한 번에 한 질문만 하는지, 사용자가 답하지 않았을 때 다시 묻는지, 사용자가 정정했을 때 최신 정보를 반영하는지, 도구 실패를 사용자에게 이해 가능한 말로 설명하는지 본다. 음성에서는 짧은 문장이 중요하다. 긴 안내문을 한 번에 읽으면 사용자는 기억하지 못한다. 평가 기준에도 “한 턴에 두 개 이상의 민감 질문을 하지 않는다”, “숫자와 날짜는 읽어 확인한다” 같은 항목을 넣는 편이 좋다.

ADK의 live_model_config와 user_simulator_config를 활용하면 이런 기준을 자동화할 수 있다. user simulator의 model은 발화 전략을 만들고, audio_model은 실제 음성을 생성한다. voice_name과 language_code를 바꾸면 다른 목소리와 언어 조건도 테스트할 수 있다. 한국어 서비스를 만든다면 한국어 TTS, 숫자 읽기, 존댓말, 방언·소음 조건까지 별도 suite로 나누는 것이 좋다.

CI/CD에 넣을 때의 현실적인 구성

처음부터 100개 통화 시나리오를 만들 필요는 없다. 가장 위험한 10개부터 시작하면 된다. 개인정보 확인, 결제 승인, 환불, 예약 변경, 계정 삭제, 의료·법률 안내, 장애 처리처럼 사고 비용이 큰 흐름을 고른다. 각 흐름마다 정상 케이스 1개, 사용자 정정 케이스 1개, 공격·우회 케이스 1개를 만들면 기본 suite가 된다.

CI에서는 모든 PR마다 긴 음성 eval을 돌리기 어렵다. 비용과 시간이 든다. 그래서 레이어를 나누는 것이 현실적이다. PR마다 텍스트 모드 eval과 핵심 live smoke eval 3개를 돌린다. main 브랜치 머지 후에는 live regression 30개를 돌린다. 모델 버전이나 프롬프트 정책이 바뀔 때는 전체 suite를 돌린다. 실패한 케이스는 fixed conversation으로 승격해 재발 방지 테스트로 남긴다.

결과 저장도 중요하다. ADK Web에서 transcript와 audio clip을 볼 수 있다는 점은 디버깅에 유용하다. 실패한 통화의 원문, 음성, 도구 호출, judge 점수, 모델 버전을 함께 저장하면 나중에 “왜 이 배포가 실패했는가”를 빠르게 찾을 수 있다.

실행 체크리스트

• 음성 에이전트의 핵심 업무 흐름을 5~10개로 나눈다.
• 각 흐름마다 정상, 정정, 공격·우회 시나리오를 만든다.
• 신원 확인, 결제, 환불, 의료·법률 안내처럼 사고 비용이 큰 흐름을 우선 평가한다.
• conversation scenario로 변형 대화를 만들고 fixed conversation으로 과거 장애를 고정한다.
• rubric은 말투보다 업무 안전, 순서, 도구 호출 정확도를 먼저 평가한다.
• 날짜, 금액, 이름, 주소는 “다시 읽어 확인” 기준을 둔다.
• PR마다 작은 smoke eval을 돌리고, 머지 후 긴 regression eval을 돌린다.
• 모델 변경, 프롬프트 변경, 도구 스키마 변경 때는 전체 live eval을 다시 실행한다.
• 실패 케이스의 transcript, audio, tool call, 모델 버전을 함께 저장한다.
• “데모 통과”를 출시 조건으로 삼지 말고 “반복 가능한 eval 통과”를 배포 게이트로 둔다.