AI 음성 에이전트 평가법: ADK Live Eval로 CI에 넣는 기준

음성 에이전트는 데모에서는 잘 보이지만, 프로덕션에서는 테스트가 까다롭습니다. 텍스트 챗봇처럼 입력과 출력 문자열을 비교하는 방식만으로는 부족합니다. 사용자의 말이 끊기고, 발음이 다르고, 배경 소음이 있고, 도구 호출 타이밍까지 맞아야 합니다. Google Developers Blog가 소개한 ADK live evaluation은 이 문제를 CI/CD에 넣을 수 있는 형태로 다룹니다.

이 글은 “AI voice agent evaluation”, “ADK Live Eval”, “voice agent CI test”를 찾는 개발자를 위한 실무 가이드입니다. 목표는 음성 에이전트를 멋지게 만드는 팁이 아니라, 배포 전에 어떤 실패를 자동으로 잡을지 정하는 것입니다.

왜 음성 에이전트 평가는 텍스트보다 어렵나

텍스트 에이전트는 최소한 입력과 출력이 명확합니다. 사용자가 쓴 문장, 모델 답변, 도구 호출 로그를 보면 대체로 문제를 재현할 수 있습니다. 음성 에이전트는 여기에 시간이 추가됩니다. 언제 끼어들었는지, 사용자의 말을 끝까지 들었는지, 음성 인식이 틀렸는지, 모델 판단이 틀렸는지, TTS가 어색했는지 구분해야 합니다.

예를 들어 사용자가 “내일 오후 3시에 민수랑 회의 잡아줘”라고 말했는데 에이전트가 “민수”를 “민주”로 인식했다면 문제는 자연어 이해가 아니라 음성 인식일 수 있습니다. 반대로 인식은 맞았지만 캘린더 API에 잘못된 timezone을 넘겼다면 도구 호출 문제입니다. 최종 답변만 비교하면 원인을 알 수 없습니다.

또 하나의 문제는 multi-turn입니다. 음성 에이전트는 사용자가 중간에 말을 바꾸거나, 질문을 끊거나, 확인을 요구하는 상황을 자주 만납니다. “아 아니, 내일 말고 금요일” 같은 수정 발화를 처리하지 못하면 실제 사용성이 크게 떨어집니다.

ADK Live Eval이 보는 포인트

Google 설명에 따르면 ADK의 live evaluation은 graph-based agent workflow를 LLM 기반 simulated user와 테스트하고, Gemini TTS를 통해 실제 오디오를 생성하며, natural-language rubric으로 응답과 도구 실행을 평가할 수 있습니다. 결과 transcript는 ADK Web에서 확인하거나 CLI로 CI에 넣을 수 있습니다.

여기서 중요한 것은 평가 대상이 최종 문장만이 아니라는 점입니다. 음성 응답, 대화 흐름, 도구 실행, 중간 상태를 함께 봐야 합니다. 예를 들어 예약 에이전트라면 다음 항목을 평가할 수 있습니다.

• 사용자의 날짜와 시간을 정확히 해석했는가.
• 참석자 이름이 모호할 때 확인 질문을 했는가.
• 캘린더 쓰기 전에 사용자 확인을 받았는가.
• timezone을 올바르게 적용했는가.
• 실패 시 사용자가 이해할 수 있는 대안을 제시했는가.

이런 평가 기준은 문자열 exact match보다 자연어 rubric이 더 잘 맞습니다. 같은 의미의 답변이 여러 방식으로 나올 수 있기 때문입니다.

CI에 넣을 테스트 시나리오 설계

음성 에이전트 테스트는 “많이”보다 “대표 실패를 잘 고르는 것”이 중요합니다. 처음에는 10~20개 시나리오면 충분합니다. 핵심 플로우, 모호한 입력, 중간 수정, 권한 거부, 도구 실패를 포함하세요.

예를 들어 고객지원 음성 에이전트라면 다음 시나리오를 만들 수 있습니다.

1. 주문번호를 말하고 배송 상태를 묻는 기본 플로우.
2. 주문번호 중 한 자리를 잘못 말한 뒤 수정하는 플로우.
3. 본인 확인이 필요한 정보를 물었을 때 인증으로 유도하는 플로우.
4. 환불 요청에서 정책 설명 후 사람 상담으로 넘기는 플로우.
5. 배송 API가 실패했을 때 재시도와 안내를 하는 플로우.

각 시나리오에는 기대 도구 호출과 금지 행동을 함께 적어야 합니다. “친절하게 답한다”는 기준은 약합니다. “본인 확인 전에는 주소를 읽어주지 않는다”, “환불 실행 API를 바로 호출하지 않는다”처럼 행동 기준이 필요합니다.

음성 품질과 업무 정확도를 분리해서 봐야 합니다

음성 에이전트의 평가는 두 층으로 나누는 것이 좋습니다. 첫째는 대화 품질입니다. 사용자가 말을 끊었을 때 멈추는지, 너무 길게 말하지 않는지, 확인 질문이 자연스러운지, 침묵 시간이 과하지 않은지 봅니다.

둘째는 업무 정확도입니다. 도구를 올바른 순서로 호출했는지, 입력값이 맞는지, 승인 없이 실행하지 않았는지, 실패를 처리했는지 봅니다. 실제 서비스에서는 업무 정확도가 더 중요합니다. 목소리가 자연스러워도 개인정보를 인증 없이 말하면 실패입니다.

CI에서는 두 점수를 따로 관리하세요. 대화 품질 점수가 낮으면 UX 개선 backlog로 보내고, 업무 정확도나 보안 기준이 실패하면 배포를 막는 게 맞습니다.

운영 로그를 평가 데이터로 되돌리는 방법

초기 테스트 시나리오는 개발팀이 만듭니다. 하지만 시간이 지나면 실제 사용자 로그가 더 좋은 평가 재료가 됩니다. 단, 개인정보를 제거하고 동의를 확인한 데이터만 사용해야 합니다.

운영 로그에서 봐야 할 신호는 반복 확인, 긴 침묵, 사용자의 “아니”, “그게 아니라”, “상담원 연결해줘”, 도구 실패, 세션 중단입니다. 이런 구간을 익명화해 eval case로 만들면 실제 실패가 줄어듭니다.

모델이나 프롬프트를 바꿀 때도 이 eval set을 다시 돌려야 합니다. 음성 에이전트는 작은 instruction 변경으로 말투와 행동 타이밍이 바뀔 수 있습니다. 특히 확인 질문을 줄이는 튜닝은 전환율을 높일 수 있지만 보안 사고를 만들 수 있습니다.

실행 체크리스트

• 핵심 플로우, 모호한 입력, 중간 수정, 권한 거부, 도구 실패 시나리오를 만든다.
• 각 시나리오에 기대 도구 호출과 금지 행동을 적는다.
• 대화 품질 점수와 업무 정확도 점수를 분리한다.
• 보안·개인정보·결제 관련 실패는 배포 차단 조건으로 둔다.
• simulated user만 믿지 말고 익명화된 운영 실패 로그를 eval case로 추가한다.
• 모델, 프롬프트, TTS, ASR 설정 변경 시 같은 eval set을 다시 실행한다.
• 긴 침묵, 반복 확인, 사용자 정정 발화, 도구 실패를 별도 지표로 추적한다.
• 최종 답변 문자열보다 transcript와 도구 호출 순서를 함께 검토한다.

출처: Google Developers Blog, “How to Evaluate Live & Voice Agents in ADK”