ADK Live Voice Agent 평가 자동화: 음성 에이전트를 데모에서 운영으로 옮기는 방법

음성 AI 에이전트는 데모가 쉽고 운영이 어렵다. 한두 번 자연스럽게 대화하는 영상은 만들 수 있지만, 실제 고객은 끊어 말하고, 말을 바꾸고, 주변 소음 속에서 질문하고, 답변 도중 새로운 요청을 던진다. Google Developers Blog가 2026년 8월 24일 소개한 ADK의 Live & Voice Agents 평가 기능은 이 문제를 정면으로 다룬다. 핵심은 음성 에이전트를 사람이 직접 몇 번 테스트하는 수준에서 벗어나, 시나리오와 루브릭 기반으로 자동 평가하는 것이다.

ADK는 Agent Development Kit의 약자로, Google 생태계에서 에이전트 워크플로우를 만들고 테스트하기 위한 도구다. 이번 글에서 강조된 지점은 LLM 기반 simulated user가 실제 오디오를 생성하고, graph-based agent workflow를 여러 턴에 걸쳐 테스트하며, 응답과 tool execution을 자동 채점할 수 있다는 점이다. 개발팀 입장에서는 “음성 품질이 괜찮다”라는 감상 대신 “예약 변경 시나리오에서 도구 호출 정확도 92%, 중간 끼어들기 처리 실패 6건” 같은 지표를 만들 수 있다.

음성 에이전트 테스트가 텍스트 챗봇보다 어려운 이유

텍스트 챗봇은 입력과 출력이 비교적 명확하다. 사용자가 문장을 보내고, 모델이 답하고, 필요하면 도구를 호출한다. 반면 음성 에이전트는 음성 인식, 턴 감지, 중간 끼어들기, TTS 지연, 배경 소음, 발화 속도, 감정 톤이 모두 품질에 영향을 준다. 모델 답변이 맞아도 너무 늦게 말하면 사용자는 실패로 느낀다.

또한 음성 대화는 복구가 중요하다. 사용자가 “아니 그거 말고 내일 오후로”라고 말했을 때 에이전트가 이전 의도를 어떻게 수정하는지 봐야 한다. “네”와 “아니요”가 문맥에 따라 반대로 해석될 수도 있다. 고객센터, 예약, 의료 문진, 금융 상담처럼 실수 비용이 있는 영역에서는 몇 가지 happy path만 통과해서는 부족하다.

그래서 음성 에이전트 평가는 세 층으로 나눠야 한다. 첫째, 대화 이해 평가다. 의도, 엔티티, 제약 조건을 맞게 잡는지 본다. 둘째, 행동 평가다. 올바른 도구를 올바른 순서와 파라미터로 호출하는지 본다. 셋째, 경험 평가다. 응답 지연, 끼어들기 처리, 확인 질문, 말투가 사용자를 불편하게 만들지 않는지 본다.

시나리오를 먼저 만들고 루브릭을 붙인다

자동 평가를 시작할 때 가장 먼저 할 일은 모델을 바꾸는 것이 아니라 시나리오 목록을 만드는 것이다. 예를 들어 병원 예약 음성 에이전트라면 다음 상황을 포함해야 한다. 신규 예약, 예약 변경, 예약 취소, 진료과 혼동, 보험 질문, 응급 증상 감지, 사용자가 말을 끊는 경우, 잘못 들은 이름을 정정하는 경우, 개인정보 확인 실패가 있다.

각 시나리오에는 성공 기준이 필요하다. “친절하게 답변” 같은 기준은 평가하기 어렵다. “예약 변경 전 기존 예약을 확인한다”, “날짜와 시간을 다시 읽어준다”, “응급 증상 언급 시 예약 플로우를 멈추고 즉시 안내 문구를 말한다”, “도구 호출 전에 사용자의 동의를 받는다”처럼 관찰 가능한 기준으로 써야 한다.

루브릭은 점수화할 수 있어야 한다. 예를 들어 의도 이해 02점, 필수 정보 수집 02점, 도구 호출 정확도 03점, 안전 정책 준수 03점으로 나눈다. 이렇게 하면 특정 모델 버전이나 프롬프트 변경 후 어떤 항목이 좋아지고 나빠졌는지 볼 수 있다.

CI/CD에 넣을 때의 기준

음성 에이전트 평가는 모든 케이스를 매 커밋마다 돌리면 느리고 비싸다. 테스트 피라미드가 필요하다. 가장 아래에는 빠른 텍스트 기반 단위 테스트를 둔다. 의도 분류, 슬롯 추출, 도구 파라미터 검증 같은 것은 오디오 없이도 점검할 수 있다. 중간에는 짧은 음성 회귀 테스트를 둔다. 핵심 happy path와 자주 깨지는 edge case를 포함한다. 맨 위에는 야간 또는 배포 전 전체 음성 시나리오 테스트를 둔다.

CI에서 막아야 할 기준도 명확히 해야 한다. 예를 들어 안전 정책 위반은 1건만 나와도 배포를 막는다. 도구 호출 파라미터 오류는 2% 이상이면 막는다. 응답 지연은 p95가 2초를 넘으면 경고, 4초를 넘으면 실패로 둔다. 자연스러움 점수는 주관성이 크기 때문에 배포 차단보다 추세 관찰에 쓰는 편이 낫다.

테스트 결과는 transcript와 audio artifact를 함께 저장해야 한다. 숫자만 보면 왜 실패했는지 모른다. 개발자가 실패 케이스를 바로 재생하고, 어떤 턴에서 의도가 바뀌었는지, 어떤 도구 호출이 틀렸는지 확인할 수 있어야 한다.

운영 로그와 평가 데이터를 연결한다

자동 평가는 출시 전 품질을 높이지만, 운영 중 실패는 반드시 새 테스트 케이스로 돌아와야 한다. 실제 사용자가 “상담원 연결해줘”를 세 번 반복했거나, 같은 날짜를 여러 번 정정했거나, 도구 호출 후 침묵이 길어졌다면 해당 세션을 익명화해 회귀 테스트에 추가해야 한다.

로그 설계도 중요하다. 음성 파일 원본을 오래 보관하면 개인정보 리스크가 커진다. 필요한 경우 짧은 보관 기간, 마스킹된 transcript, 이벤트 로그 중심으로 설계한다. 최소한 session id, turn id, ASR 결과, 모델 응답, 도구 호출, 지연 시간, 사용자의 interrupt 이벤트, fallback 발생 여부는 남겨야 한다.

평가 데이터셋은 제품의 실제 실패를 반영해야 한다. 데모용 문장만 모으면 점수는 높지만 운영 품질은 낮다. 지역 억양, 빠른 말, 배경 소음, 반말과 존댓말 혼용, 숫자 발음 오류, 외래어 발음 같은 데이터를 꾸준히 넣어야 한다.

실무 적용 체크리스트

• 음성 에이전트의 주요 업무를 신규 요청, 변경, 취소, 예외, 안전 중단으로 나눈다.
• 각 업무별로 10개 이상의 대화 시나리오와 관찰 가능한 성공 기준을 만든다.
• 의도 이해, 필수 정보 수집, 도구 호출, 안전 정책, 응답 지연을 별도 점수로 분리한다.
• 빠른 텍스트 테스트, 짧은 음성 회귀 테스트, 전체 음성 테스트를 계층화한다.
• 안전 정책 위반과 고위험 도구 호출 오류는 배포 차단 기준으로 둔다.
• transcript, audio artifact, tool call log를 함께 저장해 실패를 재현 가능하게 한다.
• 운영 실패 세션을 익명화해 다음 회귀 테스트에 추가한다.
• 개인정보 보관 기간과 마스킹 정책을 평가 시스템 설계에 포함한다.

ADK의 Live Voice Agent 평가는 음성 에이전트 개발의 방향을 잘 보여준다. 이제 중요한 것은 더 자연스러운 목소리 데모가 아니라, 반복 가능한 평가와 배포 차단 기준이다. 음성 에이전트를 실제 업무에 넣고 싶다면 먼저 테스트 시스템을 제품 기능처럼 설계해야 한다.