5개의 Voice AI 스택을 벤치마킹했습니다. 단 2개만이 300ms 미만을 유지했습니다.

Voice AI 에이전트들이 300ms 미만으로 응답한다는 글을 계속 읽어왔습니다. AssemblyAI도 그렇게 말하고, Vapi도 그렇게 말하며, 모든 Realtime API 출시 게시물들이 그렇게 말합니다. 그래서 저는 다섯 개의 스택을 구축하고, 각 파이프라인에 스톱워치를 투입한 뒤, 동일한 1분간의 대화를 모든 스택에 실행해 보았습니다.

다섯 개 중 세 개는 근처에도 가지 못했습니다.

나머지 두 개는 제가 조용히 "마케팅용 숫자"라고 가정했던 것들이었습니다. 알고 보니 마케팅이 맞았고, 제가 직접 손으로 만든 파이프라인이 문제였습니다.

아무도 슬라이드에 넣지 않는 세 개의 절벽

수치를 보기 전에, 인식 모델부터 살펴보겠습니다. 음성 지연 시간(Latency)은 부드럽게 저하되지 않습니다. 절벽처럼 떨어집니다. AssemblyAI, Vapi, 그리고 Retell은 모두 대략 동일한 세 가지 임계값으로 수렴하며, 일주일간의 사용자 테스트를 거친 후 저는 이제 그들의 말을 믿게 되었습니다.

지연 시간 (Latency)	사용자의 행동
0-300ms	정상적으로 대화하며, AI에 대해 전혀 생각하지 않음
...

300ms가 첫 번째 절벽입니다. 이 수치를 넘어서면 사용자는 기계임을 인지하기 시작합니다. 500ms를 넘어가면 사용자는 대화 순서 교대(turn-taking) 모델과 싸우기 시작하며, 사용자가 계속 말을 가로채기 때문에 STT(Speech-to-Text)가 계속 리셋됩니다. 800ms에 도달하면, 제 테스터 중 절반이 "여보세요? 여보세요?"라고 말했습니다. 이는 "이거 작동하고 있나요?"를 의미하는 보편적인 소리입니다. 재생 화면을 통해 그 모습을 지켜보는 것만큼 저를 겸허하게 만든 코드 리뷰의 일주일은 없었습니다.

300ms 예산이 소비되는 곳

제 다섯 개 스택 중 세 개가 왜 실패했는지 알고 싶다면, 예산 계산을 살펴보십시오. 계단식 파이프라인(Cascaded pipeline)은 네 가지 직렬 작업을 300ms 안에 맞춰야 합니다:

• STT (Speech-to-Text): 모델과 VAD(Voice Activity Detection) 설계에 따라 80-300ms
• LLM TTFT (Time to First Token): 모델 크기, 컨텍스트 길이, 콜드 스타트(Cold-start)에 따라 100-500ms
• TTS TTFB (Time to First Byte of audio): 보코더(Vocoder)에 따라 75-300ms
• 네트워크 왕복 시간 (Network round-trip): 빛의 속도와 데이터 센터(Colo) 선택에 의해 제한되며 50-200ms

모든 행에서 가장 빠른 숫자들만 더하면 305ms가 됩니다. 일반적인 숫자들을 더하면 1초가 넘습니다. "지연 시간의 구조 (anatomy of latency)"가 주는 결론은, 모든 구성 요소가 서로 바로 옆에 붙어 있지 않는 한, 연쇄적인 구조 (cascade)는 수학적으로 300ms 미만을 유지하는 것이 불가능에 가깝다는 것입니다.

Voice-to-voice 엔드 투 엔드 (end-to-end) 모델들은 STT + LLM + TTS를 오디오 토큰 스트림에 대한 단일 순전파 (forward pass)로 통합함으로써 속임수를 씁니다. 두 번째 홉 (second hop)이 없습니다. TTS 웜업 (warmup)도 없습니다. 서비스 간의 핸드오프 (inter-service hand-off)도 없습니다. 그것이 핵심이며, 승리한 두 개의 스택이 제가 코드를 가장 적게 작성한 두 스택인 이유이기도 합니다.

5개의 스택

저는 "내가 좋아하는 벤더를 보세요" 식의 글이 아닌, 진정한 비교를 원했습니다. 동일한 1분 고객 지원 스크립트를 사용했습니다. 동일한 WebRTC 인그레스 (ingress)를 사용했습니다 (OpenAI Realtime은 자체 방식을 사용하므로 이를 제외한 모든 곳에 Daily.co 사용). 동일한 프롬프트 (prompt). 동일한 클라이언트 머신, US-East 지역. 스택당 10회의 턴 (turn), 스택당 50회의 측정. 저는 P50, P95, P99를 보고하는데, 이는 평균값이 음성 사용자에게 물리적으로 느껴지는 방식으로 거짓말을 하기 때문입니다.

스택 1 — OpenAI Realtime API. 공식 WebRTC 엔드포인트를 통한 gpt-4o-realtime. 별도의 연결 코드(glue) 없이 Voice-in, voice-out 방식.

스택 2 — Deepgram + Claude + ElevenLabs 연쇄 (cascade). STT를 위한 Deepgram Nova-3, LLM을 위한 Claude Sonnet 4.6, TTS를 위한 ElevenLabs Turbo v2.5. 화이트보드에 그릴 법한 "최고의 조합 (best-of-breed)" 연쇄 구조.

스택 3 — 로컬 엣지 (Local Edge) (Whisper + Llama + Coqui). Whisper Large v3 Turbo, 단일 H100에서 실행되는 로컬 Llama 3.3 70B, TTS를 위한 Coqui XTTS. 네트워크 왕복 시간 (Network round-trip): 0ms. 이는 Hacker News가 열광하는 "개인정보 보호 및 주권 (privacy and sovereignty)"에 대한 해답입니다.

스택 4 — LiveKit Agents + Gemini 2.0 Flash Live. 미디어 플레인 (media plane)으로서 LiveKit의 에이전트 프레임워크, 두뇌 역할로서 Google의 네이티브 오디오 Gemini Live. 이 또한 Voice-to-voice 엔드 투 엔드 방식이지만, 다른 SDK를 통해 구현되었습니다.

스택 5 — Pipecat + Claude + Cartesia. 오케스트레이터 (orchestrator)로서 Pipecat, LLM을 위한 Claude Sonnet 4.6, TTS를 위한 Cartesia Sonic. ElevenLabs보다 빠른 TTS를 사용하는, 보다 주관이 뚜렷한 연쇄 구조.

결과

스택 (Stack)	P50	P95	P99	300ms 미만?
1. OpenAI Realtime (voice-to-voice)	232ms	281ms	320ms	✅
...

스택 1과 스택 4는 P95 기준 300ms 미만을 유지한 유일한 두 가지 방식입니다. 두 방식 모두 voice-to-voice (음성 대 음성) 방식입니다. 두 방식 모두 릴레이 경주(relay race) 방식 대신 단일 순방향 패스 (single forward pass)를 제공합니다. 스택 5는 세심하게 설계된 연쇄 구조 (cascade)의 모습이지만 (Cartesia의 TTS는 진정으로 빠릅니다: TTFB 90ms), 여전히 임계점(cliff)을 넘지 못하는데, 이는 LLM의 TTFT (첫 토큰 시간)와 서비스 간 홉 (inter-service hops)이 예산을 모두 소모하기 때문입니다.

스택 3은 고통스러운 결과였습니다. 저는 네트워크가 없기 때문에 로컬 (local) 방식이 적어도 연쇄 구조보다는 빠를 것이라고 기대했습니다. 때로는 그렇기도 합니다. 하지만 Llama 3.3 70B는 작은 모델이 아니며, 범용 GPU에서 LLM TTFT만 600ms가 걸린다면 "네트워크 없음"은 당신을 구원해주지 못합니다. 엣지 AI (edge AI)에 대한 솔직한 분석은, 오늘날 현실적인 엣지의 승리는 풀스펙 70B 로컬 모델이 아니라 더 작은 모델 (Qwen2.5 1.5B 급)이라는 것입니다. 로컬 하드웨어에서 70B 모델을 돌리는 것은 두 세계의 최악만을 모아놓은 것과 같습니다. GPU 비용은 지불하면서도 여전히 임계점을 넘지 못하기 때문입니다.

왜 voice-to-voice가 (오늘날) 승리하는가

제가 받은 충격이 큰 순서대로 세 가지 이유를 나열하겠습니다:

첫째 — TTFT-then-TTFB의 중첩이 없음. 연쇄 구조 (cascade)에서는 LLM의 첫 번째 토큰을 기다린 다음 TTS를 시작해야 하며, TTS는 자체적인 첫 바이트 지연 시간 (TTFB)을 가집니다. Voice-to-voice는 오디오 토큰을 직접 방출합니다. 두 번째의 예열 과정이 필요 없습니다.

둘째 — 핸드오프 직렬화 (hand-off serialization)가 없음. Deepgram → Claude → ElevenLabs는 세 개의 별도 API 엔드포인트입니다. 각 엔드포인트가 빠르더라도 TLS, 커넥션 풀링 (connection pooling), 프레임 버퍼 (frame-buffer) 오버헤드를 세 번 지불해야 합니다. Pipecat이 도움이 되긴 하지만 이를 완전히 없애지는 못합니다.

셋째 — VAD (음성 활동 감지)를 인지하는 턴 테이킹 (turn-taking). Voice-to-voice 모델은 오디오 스트림에서 자체적으로 엔드포인트 감지 (endpoint detection)를 수행합니다. 연쇄 구조는 STT 출력을 확정하기 위해 VAD 신호를 기다린 다음 이를 전송해야 합니다. 이러한 확정 지연 (commitment delay)은 "사용자가 말을 멈춘 시점"부터 측정을 시작하는 벤치마크에서는 보이지 않지만, 사용자는 자신이 언제 "공식적으로" 말을 멈췄는지 알지 못합니다. 그들은 이를 침묵으로 느낍니다.

2026년 5월에 300ms를 달성하는 가장 저렴한 방법은 파이프라인 작성을 건너뛰는 것입니다. 제 지연 시간의 대부분은 제가 작성한 코드에서 발생했습니다.

Edge AI가 따라잡을 때

Edge(엣지)는 특정 유형의 문제에 대한 올바른 해답입니다. 로컬 전용 프라이버시, 네트워크가 없는 키오스크, 오프라인 로보틱스 등이 이에 해당합니다. 하지만 아직 "300ms 미만의 클라우드 에이전트를 원한다"는 요구에 대한 정답은 아닙니다. Whisper v3 Turbo는 1000배 이상의 실시간 계수(Real-time factor)를 기록하며, 1.5B급 LLM(대규모 언어 모델)은 CPU에서 200ms 내에 첫 번째 토큰을 반환할 수 있습니다. 이러한 조합—작은 모델, 빠른 STT(음성 인식), 로컬 TTS(음성 합성)—은 총 300~350ms를 달성할 수 있습니다. 제가 Stack 3에서 테스트했던 H100 기반의 70B 모델 경로는 이를 달성할 수 없습니다.

다른 경로는 하이브리드(Hybrid) 방식입니다: Edge STT, Cloud LLM, Cloud TTS를 사용하는 방식입니다. 이 방식은 가장 긴 동기적 단계(오디오 프레임 캡처)에서의 네트워크 왕복 시간(Round trip)을 건너뛰면서도, 두뇌 역할에는 클라우드급 모델의 품질을 유지할 수 있습니다. 350~500ms는 현실적이지만, 300ms 미만의 클라우드 캐스케이드(Cascade)는 불가능합니다.

인지(Perception) 측면(어떻게 하면 500ms 에이전트를 300ms 에이전트처럼 느껴지게 만들 것인가)에 대한 더 자세한 내용은 Voice AI를 위한 인지 해킹(perception hacks for voice AI)에 관한 동반 기사를 작성했습니다. 필러 오디오(Filler audio), 마이크로 컨퍼메이션(Micro-confirmations), 점진적 토큰 재생(Progressive token playback)은 체감 속도를 획기적으로 높여줄 수 있습니다. 하지만 이것이 실제 지연 시간의 절벽을 옮겨주지는 않습니다.

내가 오늘 구축한다면

만약 제가 2026년 5월에 음성 에이전트를 시작한다면 다음과 같이 할 것입니다:

• 신규 소비자 제품 (Greenfield consumer product) — OpenAI Realtime 또는 Gemini Live를 직접 사용합니다. 생각보다 더 빨리 멈추고 그냥 출시하십시오.
• Claude를 루프에 포함해야 하는 경우 — Pipecat + Claude + Cartesia 조합을 사용합니다. P95 지연 시간 500~600ms 환경에서 운영하게 될 것입니다. 필러(Filler) 전략을 나중이 아닌 지금 계획하십시오.
• 프라이버시 또는 에어갭(Air-gap) 요구사항이 있는 경우 — Whisper Turbo + Qwen2.5 1.5B + 로컬 TTS를 사용합니다. TTFB(첫 토큰까지의 시간) 350ms를 목표로 하십시오. 다음 GPU 세대가 나오기 전까지 로컬 70B 모델은 잊으십시오.
• 엔터프라이즈 전화 시스템 (Enterprise telephony) — 하이브리드 방식: Edge STT, 그리고 두뇌를 위한 Cloud Voice-to-Voice를 사용합니다. PSTN 코덱 계층이 이미 지연 시간의 이점을 상쇄시키므로, 대신 대화 차례 주고받기(Turn-taking)의 품질을 최적화하십시오.

제가 저지른 가장 깊은 실수는 "300ms"가 제가 선택한 _모델 (model)_의 속성이라고 가정했던 것입니다. 그것은 제가 선택한 _아키텍처 (architecture)_의 속성입니다. 모델은 단지 그 아키텍처가 얼마나 쾌적한지를 결정할 뿐입니다.

관련 읽을거리

• Your Voice Agent Has 300ms Before Users Bail — 동일한 절벽(cliff)이지만, 다른 관점에서 다룹니다.

지연 시간의 해부학, 인지 모델(perception model), 그리고 스택 3(Stack 3)의 기반이 된 엣지 AI (edge AI) 장에 대한 전체 내용은 책으로 구성되어 있습니다.

Voice AI 300ms UX: Design and Engineer the Conversation Cliff