5 Voice Agent Failure Modes You'll Hit in Week One — Venky B, Plivo

한 줄 핵심

음성 에이전트는 데모에서는 잘 보이지만, 생산 환경에선 지연·전사·데이터 수집·합성·턴 감지 같은 경계 지점이 무너지기 쉬워서 처음부터 구조적으로 설계해야 한다.

시간별 요약

1. 0:00
   음성 에이전트가 데모와 운영에서 갈라지는 지점 음성 에이전트는 개발 환경에서는 그럴듯해 보여도 실제 배포 단계에서 실패 양상이 급격히 드러난다. 대규모 음성 통화 운영 경험을 바탕으로, 생산에서 반복적으로 터지는 다섯 가지 실패 모드를 정리한다.
2. 2:20
   매달 10억 통화가 드러낸 패턴 음성·SMS API에서 출발해 AI agent 플랫폼으로 확장한 경험과, 매달 10억 건 이상의 음성 통화가 쌓이면서 관찰된 운영 패턴을 공유한다. programmable AI agent, no-code studio, SIP trunking·audio streaming을 모두 직접 다루는 구조가 전제 조건으로 제시된다.
3. 4:28
   대부분이 먼저 만드는 파이프라인 대부분의 팀은 speech-to-text, LLM, TTS, turn detection을 오케스트레이션 프레임워크 위에 얹어 데모를 완성한다. 하지만 각 구간의 지연을 단순 합산해도 실제 체감 품질은 충분히 예측되지 않으며, 운영에서는 여기서부터 여러 실패가 시작된다.
4. 5:34
   실패 1: 지연과 첫 음성까지의 시간 핵심 지표는 사용자가 말을 멈춘 뒤 에이전트가 첫 음성을 내기까지의 time to first audio다. 보통 550ms 이하를 목표로 하지만 실제 현장에서는 750ms~1.2s에 머무는 경우가 많고, 1.2s를 넘기면 이탈이 급격히 늘어난다.
5. 6:42
   비용·지능·지연의 균형 음성 에이전트는 비용, 지능, 지연을 동시에 만족시켜야 하며 세 요소는 서로 충돌한다. 최근 LLM의 'thinking' 계열 발전은 빠른 응답이 필요한 음성에서는 사실상 꺼야 하는 경우가 많아, 최신 모델의 이점이 그대로 적용되지 않는다.
6. 7:48
   생각하는 모델이 맞지 않는 이유 Frontier model은 평균 지연도 높고 P90~P95가 쉽게 1.2~1.3초까지 튄다. 반면 초저지연을 얻기 위해 고정 용량을 예약하는 경로는 비용이 매우 크고 장기 계약 부담이 커서, 생산용 음성 에이전트에는 현실적이지 않다.
7. 9:56
   오픈소스 모델의 선택과 크기 조정 Under 300ms를 목표로 하면 오픈소스 모델이 가장 현실적인 균형점이 된다. 영어 중심이면 quen 3.5와 Gemma 4가 모두 가능하지만, 다국어 환경에서는 Gemma 4가 더 유리하고, fine-tuning을 고려하면 최소 8B~12B급이 필요하다.
8. 13:06
   실패 2: 전사는 본질적으로 취약하다고 가정하기 최신 transcription 엔진도 실제 noisy call에서는 word error rate가 4~6%를 넘기기 쉽고, 억양·도메인 용어가 섞이면 두 자릿수로 악화된다. proper noun, 약어, 전화번호, 주소처럼 구조가 까다로운 입력은 전사 엔진만 믿으면 자주 깨진다.
9. 15:14
   코드 스위칭 언어가 하위 단계 전체를 망가뜨린다 영어와 다른 문자 체계가 섞이거나, 같은 언어를 로마자 표기로 말하는 순간 전사부터 LLM, TTS까지 연쇄적으로 무너질 수 있다. 따라서 transcription engine 독립성을 확보하려면 입력을 정규화하는 별도 레이어가 필요하다.
10. 16:17
    동적 키워드 부스팅과 LLM 후처리 고정된 keyword boosting보다 호출 상태에 따라 필요한 키워드만 동적으로 넣는 방식이 더 정확하다. 전사 결과는 LLM으로 후처리해 문맥에 맞게 숫자·고유명사·전사 오류를 교정하고, 최종적으로 정규화된 transcript를 LLM에 넘겨야 한다.
11. 18:24
    실패 3: 데이터를 텍스트가 아니라 필드로 수집하기 50~60%의 에이전트가 데이터 수집 단계에서 크게 실패하는 이유는, 대화를 자유 텍스트가 아니라 구조화된 필드로 다루지 않기 때문이다. phone number, 이름, 주소, 날짜 같은 항목을 typed field로 정의하면 정확도가 30%대에서 95% 수준까지 올라간다.
12. 20:31
    상대 날짜와 다른 함정들 next week Wednesday 같은 상대 표현은 datetime field로 받고 현재 시점과 결합해 해석해야 한다. 이런 입력은 unit test처럼 필드 단위 eval로 검증해야 하며, end-to-end 테스트만으로는 어떤 필드가 깨졌는지 빠르게 찾기 어렵다.
13. 21:37
    종단 간 테스트보다 필드 단위 평가 프롬프트를 조금씩 바꿔가며 문제를 해결하려는 방식보다, 상태별 컨텍스트를 쪼개고 각 필드를 unit test처럼 평가하는 쪽이 더 안정적이다. 이렇게 하면 fine-tuning 없이도 95~97% 수준의 정확도를 달성할 수 있다.
14. 22:47
    실패 4: 합성 전에 정규화하기 LLM 출력은 TTS에 바로 넣지 말고 중간 정규화 레이어를 둬야 한다. emojis, markdown, 이메일, 통화, 날짜, 약어, 고유명사 발음은 제거·변환·속도 조절을 거쳐야 하며, custom dictionary와 발음 규칙을 내부에서 관리하는 편이 이식성도 높다.
15. 25:00
    실패 5: 턴 감지와 끼어들기 turn detection과 barge-in은 별도 난제로 다뤄야 하며, speech-to-speech 모델이 아니어도 파이프라인 수준에서 구현할 수 있다. 고객이 직접 이름·회사명 발음을 제어할 수 있게 하면 실제 사용성 문제가 크게 줄어든다.

실무 인사이트

• 음성 에이전트는 모델 성능보다 지연 예산과 정규화 레이어 설계가 품질을 좌우하므로, first token/first audio 기준의 SLO를 먼저 정해야 한다.
• 전사 오류를 '예외'로 취급하지 말고, 필드 단위 스키마·검증·후처리를 전제로 파이프라인을 설계해야 운영 안정성이 나온다.
• 데모용 end-to-end 성공률보다, call state별 키워드 주입·필드 단위 eval·TTS 전 정규화처럼 경계면을 잘라서 관리하는 구조가 생산성의 핵심이다.