“이번 달 매출을 알려줘.” AI는 확인하겠다고 대답한 뒤 조용해집니다. 몇 초가 지나면 사용자는 다시 묻습니다. “듣고 있어?” 이제 같은 조회가 두 번 실행되고, 먼저 시작한 결과가 나중 질문을 끊으며 재생될 수도 있습니다.
음성 AI의 품질은 목소리의 자연스러움만으로 결정되지 않습니다. 사용자가 말할 때 듣고, 기다려야 할 때 이유를 알려주며, 실제로 끝난 일만 완료라고 말하는 능력이 중요합니다. 외국어 연습, 고객 상담, 업무 브리핑과 음성 기반 제작 도구에 공통으로 적용되는 문제입니다.
이 글은 2026년 10월 23일 확인한 공식 기술 문서를 바탕으로 한 설계 가이드입니다. 특정 제품의 실측 리뷰나 작동하는 앱의 배포 사례는 아닙니다. 아래 여섯 이미지는 대표 이미지와 본문 삽화로 생성한 개념 그림이며 실제 서비스 화면·성능 측정 결과가 아닙니다.
1. 첫 대답과 작업 완료는 다른 시계다
Google의 10월 19일 ADK 가이드는 느린 도구를 실행하면서 대화를 이어가는 방식을 소개합니다. 판매 보고서 데모에서 첫 발화까지 시간이 14.4초에서 1.2초로 줄었다고 보고하지만, 이는 공급사의 특정 구성 결과이며 최종 조회가 그만큼 빨라졌다는 뜻이 아닙니다. 백엔드 작업 시간은 별도로 남습니다.
이 차이를 놓치면 “바로 확인해 드릴게요”를 빠르게 말하는 시스템을 빠른 업무 처리 시스템으로 오해합니다. 평가할 때는 사용자의 말이 끝난 시점부터 접수 안내, 실제 진행 증거, 검증된 최종 결과까지를 나누어 기록하세요. 숫자 하나로 합치지 않는 것이 핵심입니다.
첫 반응에는 무엇을 이해했는지와 무엇을 할 것인지가 담겨야 합니다. 아직 시작하지 않은 조회를 진행 중이라고 말하거나, 계산 중이라는 사실만으로 성공을 선언해서는 안 됩니다. 로딩을 가리는 잡담보다 확인 가능한 상태 한 문장이 낫습니다.
2. 대화 경로와 작업 경로를 분리한다
ADK의 실시간 도구 문서는 일반 도구, 백그라운드 실행과 중간 결과를 보내는 스트리밍 도구를 구분합니다. 도구 실행 중 대화가 막히는 구조는 “계속 친절하게 말해라”라는 프롬프트만으로 해결되지 않습니다. 실제 이벤트와 실행 경로를 설계해야 합니다.
실무에서는 대화를 담당하는 경로가 사용자 질문을 받고, 작업 경로가 조회·변환·생성을 처리하도록 구분해 생각하면 편합니다. 여기서 두 경로는 서로 다른 제품이나 두 개의 모델을 반드시 의미하지 않습니다. 한 애플리케이션 안에서도 대화 상태와 작업 상태를 별도로 관리할 수 있습니다.
아래는 AIZIGOO가 제안하는 최소 상태 장부입니다. 구현용 API 스키마가 아니라 개발자·기획자가 함께 합의할 운영 계약입니다.
| 상태 | 사용자에게 알릴 내용 | 남겨야 할 증거 |
|---|---|---|
| 접수 | 이해한 요청과 범위 | 작업 ID·요청 버전 |
| 실행 중 | 확인된 현재 단계 | 실행 이벤트·단계 시각 |
| 확인 중 | 결과가 왔지만 검수 중 | 원본 결과·검사 기록 |
| 완료 | 확인한 결과와 남은 한계 | 결과 ID·출처·완료 시각 |
| 취소·미결 | 중단 여부 또는 확인 불가 | 취소 응답·현재 서버 상태 |
사용자가 조건을 바꾸면 요청 버전을 올리고 이전 결과를 새 조건의 답으로 쓰지 마세요. 같은 질문이 반복돼도 동일 작업을 조회할지 새 작업을 만들지 먼저 판단합니다. 특히 발송·예약처럼 외부 상태를 바꾸는 행동은 작업 ID와 중복 방지 키를 연결하는 편이 안전합니다.
3. 진행 상황은 진짜 변화가 있을 때만 말한다
“처리 중입니다”를 몇 초마다 반복한다고 신뢰가 쌓이지는 않습니다. 파일이 열렸는지, 조회가 끝났는지, 결과 검사가 남았는지처럼 실제 이벤트에 연결된 안내가 필요합니다. 진행률을 모르면 퍼센트를 만들어내지 말고 현재 확인된 단계와 다음 확인 시점을 알려주세요.
결과를 언제 말할지도 별도 선택입니다. ADK 문서는 자연스러운 발화 공백에 전달하는 WHEN_IDLE, 즉시 반응하는 INTERRUPT, 문맥만 갱신하는 SILENT를 설명합니다. 지원은 모델·SDK·세션 구성에 따라 확인해야 하며, 모든 음성 앱에서 같은 선택자를 쓸 수 있다는 뜻은 아닙니다.
| 결과 성격 | 권장 전달 방식 | 피해야 할 행동 |
|---|---|---|
| 일반 보고서·조회 | 사용자의 말이 끝난 뒤 | 문장 중간에 숫자 낭독 |
| 즉시 알아야 할 실패 | 중요성을 짧게 알리고 전달 | 실패를 숨긴 채 대화 지속 |
| 후속 답에만 필요한 정보 | 조용히 상태 갱신 | 무관한 중간 결과를 강제 발표 |
| 말하기·면접 연습 | 사용자가 생각할 시간 보장 | 모든 침묵을 실패로 판단 |
위 권장안은 AIZIGOO의 설계 제안이지 제품별 기본 동작을 비교한 측정표가 아닙니다. 자연스러움의 목표는 빈틈없이 떠드는 것이 아니라 필요한 순간에만 개입하는 것입니다.
4. “잠깐”과 “그 작업 취소해”를 구분한다
말 끊기에는 두 의미가 섞입니다. “잠깐, 다른 질문이 있어”는 오디오 재생을 멈추라는 요청일 수 있습니다. “보고서 생성을 취소해”는 백그라운드 작업 중단 요청입니다. 전자를 처리했다고 후자까지 완료된 것으로 안내하면 안 됩니다.
Google의 10월 가이드는 끼어말하기가 진행 중인 도구를 자동 취소하지 않는다고 명시합니다. ADK 스트리밍 도구의 stop_streaming 같은 별도 취소 경로가 필요합니다. 이미 외부 서버에 전달된 작업이나 발송까지 되돌렸다는 의미는 아니므로 애플리케이션에서 결과 상태를 다시 확인해야 합니다.
OpenAI Realtime의 중단·잘라내기 문서는 재생하지 못한 응답을 대화 기록과 맞추는 문제도 설명합니다. WebRTC·SIP와 WebSocket의 책임 구분이 다르므로 오디오를 멈추는 것만으로 처리를 끝내지 마세요. 사용자가 듣지 못한 설명을 이미 들었다고 가정하면 다음 답변이 어긋납니다.
실제 설계에서는 음성 재생 상태와 업무 상태를 분리하세요. “설명은 멈췄습니다. 조회도 중단할까요?”처럼 범위가 불분명할 때 한 번 확인할 수 있습니다. 취소 응답이 오지 않았다면 “취소 완료” 대신 “중단을 요청했고 상태를 확인 중”이라고 알립니다.
5. 유창한 음성이 권한 확인을 대신하지 않는다
“네, 진행해요”라는 말은 직전 설명이 무엇이었는지에 따라 의미가 달라집니다. 조회에 동의한 말을 이메일 발송이나 예약 확정의 승인으로 확대하면 안 됩니다. 실제 적용 시 대상, 범위, 금액·수신자 같은 중요한 변경 내용을 먼저 제시하고 그 행동에 대한 확인을 받아야 합니다.
ADK Guardrails 문서는 지시문뿐 아니라 입력·응답·도구 단계의 독립 검증을 함께 다룹니다. 음성은 실시간으로 흘러가므로 사후 전사문 검사가 모든 발화를 사전에 차단한다고 가정해서도 안 됩니다. 특히 도구 실행 전에 권한과 매개변수를 검사하는 경계를 별도로 두세요.
파일럿은 가상 주문·샘플 문서·읽기 전용 조회로 시작하는 것이 좋습니다. 녹음·전사 저장 여부와 보관 정책도 사용자에게 알리고 필요한 최소 정보만 남기세요. 전화 속 배경 목소리나 외부 자료에 담긴 문장을 작업 지시로 취급하지 않도록, 요청자와 작업 범위를 확인하는 절차를 둡니다.
6. 30분 파일럿: 목소리보다 상태를 시험한다
다음은 AIZIGOO가 제안하는 소규모 점검 절차입니다. 이 글을 위해 실제 음성 API를 호출해 아래 테스트를 실행한 것은 아니며 공식 벤치마크도 아닙니다. 같은 테스트를 텍스트로만 읽어서는 마이크·발화 감지·중첩 발화의 실패를 찾기 어렵습니다. ADK의 음성 평가 문서도 실제 오디오 경로와 대화 전체의 검토를 강조합니다.
처음 5분은 읽기 전용 작업 하나와 예상 결과를 고정합니다. 다음 15분 동안 아래 상황을 같은 기기와 네트워크에서 반복합니다. 마지막 10분은 녹음 동의를 받은 대화·작업 로그를 나란히 보고 실패 원인을 분류합니다. 가능하면 같은 대본을 한국어·영어·일본어로 각각 시험하되 번역문이 같다는 이유만으로 음성 동작까지 같다고 가정하지 마세요.
| 시험 상황 | 합격 증거 | 실패 시 먼저 볼 곳 |
|---|---|---|
| 일부러 느린 조회 | 접수 안내와 최종 결과가 구분됨 | 작업 시작·결과 이벤트 |
| 말 도중 끼어들기 | 오디오가 멈추고 새 질문을 받음 | 발화 감지·재생 버퍼 |
| 작업 취소 요청 | 서버 상태로 중단 여부 확인 | 취소 경로·후속 요청 |
| 기다리며 조건 변경 | 이전 결과를 새 답으로 오인하지 않음 | 작업 ID·요청 버전 |
| 연결 끊김 뒤 재시도 | 중복 실행 없이 현재 상태 확인 | 결과 조회·중복 방지 |
| 생각 중 긴 침묵 | 불필요하게 답을 재촉하지 않음 | 대화 모드·종료 감지 |
평균 응답 시간 하나보다 첫 반응·최종 완료 시간의 분포, 잘못 끊긴 발화, 중복 실행, 거짓 완료 안내를 따로 기록하세요. 성공 대화당 비용에는 오디오·모델 호출뿐 아니라 재시도, 외부 도구와 사람 검수도 포함합니다. 표본이 작으면 모델 순위를 발표하기보다 반복되는 실패 한 가지를 고치는 데 쓰는 편이 낫습니다.
좋은 음성 AI는 필요할 때 조용할 줄 안다
자연스러운 대화의 조건은 빠른 첫마디만이 아닙니다. 들을 때와 말할 때를 구분하고, 작업이 바뀌면 오래된 답을 내려놓고, 취소되지 않은 일을 취소됐다고 말하지 않는 것이 중요합니다. 처음부터 만능 비서보다 하나의 읽기 전용 작업을 명확하게 접수·진행·확인하는 에이전트부터 설계해 보세요.
확인한 공식 자료
- Google Developers: 비차단 음성 에이전트 제작 가이드, 2026-10-19
- ADK: 실시간 에이전트 도구
- ADK: 실시간 에이전트 안전장치
- ADK: 실시간 에이전트 평가
- OpenAI: Realtime 중단과 미재생 응답 처리
자료 확인일은 2026년 10월 23일입니다. 이 글의 개발자용 API·ADK 설명을 일반 소비자 앱의 설정과 혼동하지 마세요. 모델 지원, SDK 버전, 계정 접근, 데이터 처리와 과금은 도입 전에 해당 서비스의 최신 문서로 재확인해야 합니다.