AI 음성 에이전트(AI voice agent)는 당신과 대화할 수 있는 소프트웨어입니다. 당신이 말하는 것을 듣고, 당신이 한 말에 대해 추론하며, 실시간으로 대답합니다. 즉, 전화 메뉴를 따라가게 만드는 대신 자연스러운 구어체 대화를 나눕니다.

그 정의는 쉬운 부분입니다. 인터넷상의 모든 설명서는 음성 에이전트가 음성-텍스트 변환 (Speech-to-Text, STT), 언어 모델 (Language Model, LM), 텍스트-음성 변환 (Text-to-Speech, TTS)의 결합이라고 말할 것입니다.

여기 거의 아무도 기록하지 않는 부분이 있습니다: 음성 에이전트는 프롬프트 (Prompt) 문제가 아니라, 지연 시간 (Latency)과 연결성 (Connectivity)의 문제입니다.

언어 모델은 쉬운 80%에 불과합니다. 세 개의 모델을 함께 연결하는 것은 주말 동안 할 수 있는 프로젝트 수준입니다. 어려운 부분, 즉 당신의 에이전트가 인간처럼 느껴질지 아니면 고객의 사무실에서 그냥 침묵할지를 결정하는 부분은 그 아래의 배관(plumbing)입니다. 즉, 오디오가 실제로 어떻게 이동하는지, 얼마나 빠른지, 그리고 연결이 가능한지 여부입니다.

이 가이드는 전체 스택 (Stack)을 다룹니다. 표준 아키텍처 (Architecture), 2026년의 솔직한 트레이드오프 (Trade-offs), 우리가 직접 측정한 수치가 포함된 실제 지연 시간 예산 (Latency budget), 그리고 상위권 가이드들이 완전히 생략하는 전송 계층 (Transport layer)을 다룰 것입니다.

요약 (TL;DR): AI 음성 에이전트는 당신의 말을 듣고 (음성-텍스트 변환, STT), 생각하며 (LLM), 다시 말합니다 (텍스트-음성 변환, TTS). 이 과정은 대화의 순서와 중단을 관리하는 오케스트레이터 (Orchestrator)에 의해 조정되며, 대화가 자연스럽게 느껴지도록 유지하는 약 800ms 미만의 시간을 맞추기 위해 모든 단계가 스트리밍됩니다. 대부분의 가이드가 건너뛰는 계층은 전송 (Transport)입니다. 오디오는 WebRTC를 타고 이동하며, 실제 네트워크 환경에서는 TURN 릴레이 (Relay)가 필요합니다. 그렇지 않으면 에이전트가 연결된 후 침묵하게 됩니다.

AI 음성 에이전트란 무엇인가?

AI 음성 에이전트는 자연스러운 구어체 대화를 나누고, 대규모 언어 모델 (Large Language Model, LLM)을 통해 실시간으로 추론하며, 사람이 각 대화 순서를 스크립트로 작성하지 않아도 연결된 시스템 전반에서 작업을 수행하는 자율적인 음성 우선 (Voice-first) 시스템입니다. 이는 음성-텍스트 변환 (STT), LLM, 텍스트-음성 변환 (TTS)을 결합하며, WebRTC와 같은 실시간 미디어 전송 (Real-time media transport)을 통해 연결됩니다.

마지막 문구는 당신이 거의 보지 못하는 부분이며, 바로 이 글이 존재하는 이유입니다.

음성 에이전트(voice agent)와 그것이 대체하는 기존 시스템의 차이점은 의도(intent)에 있습니다. IVR(Interactive Voice Response)은 발신자를 "판매를 원하시면 1번을 누르세요"와 같이 고정된 메뉴 트리로 강제합니다. 챗봇(chatbot)은 입력된 텍스트를 처리합니다. 반면, Aircall의 2026년 설명서와 Deepgram의 2026년 가이드에서 구분한 바와 같이, 음성 에이전트는 자연스러운 구어(natural spoken language)를 이해하고, 무엇을 할지 결정하며, 백엔드(backend)를 호출하고, 음성으로 답변합니다.

따라서 음성 에이전트는 블랙박스(black box)가 아니라 하나의 루프(loop)입니다. 에이전트는 듣고, 생각하고, 말하며, 이 세 가지를 올바른 순서로, 사용자가 이음새를 느끼지 못할 만큼 충분히 빠르게 수행하는 무언가가 반드시 필요합니다.

그 지휘자가 바로 오케스트레이터(orchestrator)이며, 이는 단순히 단계 간에 데이터를 전달하는 것 이상의 역할을 수행합니다. 루프를 단계별로 자세히 살펴보겠습니다.

음성 에이전트는 어떻게 작동하는가? 4단계

음성 에이전트는 네 가지 실시간 단계를 긴밀한 루프로 실행합니다. 음성-텍스트 변환(speech-to-text, STT)이 당신이 말하는 내용을 전사(transcribe)하고, LLM(Large Language Model)이 답변을 결정하며 도구(tools)를 호출하고, 텍스트-음성 변환(text-to-speech, TTS)이 이를 말하며, 오케스트레이터가 발화 차례가 언제 끝나는지, 그리고 중단(interruption) 시 언제 멈춰야 하는지를 관리합니다. 스트리밍(Streaming)은 단계들을 중첩시켜 모델이 생각을 마치기 전에도 답변이 시작될 수 있도록 합니다.

각 단계와 실제 담당 역할은 다음과 같습니다.

**음성-텍스트 변환 (Speech-to-text, STT)**은 오디오를 모델이 읽을 수 있는 단어로 변환합니다. 성능이 좋은 에이전트에서는 사용자가 말을 마칠 때까지 기다리는 대신, 대화하는 동안 부분적인 전사 내용(partial transcripts)을 지속적으로 내보내며 연속적으로 실행됩니다.

LLM은 전사된 내용을 읽고, 무엇을 말할지 결정하며, 필요할 때 도구(tools)를 호출합니다: 주문 조회, 예약, 재고 확인 등입니다. 이것이 "두뇌" 역할을 하지만, 지연 시간(latency) 섹션에서 확인하게 되겠지만, 이것이 느린 부분인 경우는 드뭅니다.

**Text-to-speech (TTS)**는 답변을 다시 오디오로 변환합니다. 스트리밍 TTS (Streaming TTS)는 문장의 나머지 부분이 생성되는 동안에도 첫 단어들을 말하기 시작하며, 이것이 일시 정지 시간을 짧게 유지하는 비결입니다.

**오케스트레이터 (The orchestrator)**는 숨은 영웅입니다. 오케스트레이터는 사용자의 차례가 언제 끝났는지 결정하고 (turn detection), 답변을 시작하며, — 결정적으로 — 사용자가 말을 가로채는 즉시 문장 중간에 에이전트를 멈춥니다. 이러한 중단 동작을 **바지인 (barge-in)**이라고 하며, 이를 제대로 구현하는 것이 에이전트를 로봇처럼 느껴지게 하지 않고 인간처럼 느끼게 만드는 핵심 요소입니다.

핵심 테마를 주목하세요: 모든 것이 스트리밍됩니다. 다음 단계가 시작되기 전에 각 단계가 완전히 끝나기를 기다리는 음성 에이전트는 침묵이 쌓이기 때문에 고장 난 것처럼 느껴집니다.

AssemblyAI의 2026년 4월 아키텍처 분석에 따르면, 스트리밍을 지원하지 않는 단순한 파이프라인은 턴당 2초에서 4초의 무음 시간을 추가합니다. 아무도 "안녕"이라는 말을 듣기 위해 4초를 기다리지 않습니다.

이것이 표준 모델입니다. 하지만 2026년에는 아키텍처의 진정한 갈림길이 존재합니다. 하나의 모델인가, 아니면 세 개의 모델인가?

계단식 파이프라인 (Cascaded Pipeline) vs 음성 대 음성 (Speech-to-Speech)

"듣고-생각하고-말하는" 루프를 구축하는 방법에는 두 가지가 있으며, 이 선택은 2026년 현재 진정한 엔지니어링 트레이드오프 (engineering trade-off)입니다. **계단식 파이프라인 (Cascaded pipeline)**은 STT, LLM, TTS라는 세 개의 별도 모델을 각 단계 사이에 읽을 수 있는 텍스트를 두어 체인 형태로 연결합니다. 음성 대 음성 (Speech-to-speech, S2S) 모델은 이를 한 번에 처리합니다: 오디오 입력, 오디오 출력, 중간에 텍스트가 없습니다.

계단식 방식은 매 단계마다 텍스트 결과물을 제공하므로, 이를 로그로 남기거나, 검열(moderate)하거나, 필터링하거나, 이를 기반으로 라우팅(route)할 수 있습니다. 음성 대 음성 방식은 종종 더 자연스럽고 더 빠를 수 있지만, 디버깅이 더 어렵고 비용이 많이 들며 투명성이 떨어집니다.

Deepgram과 Softcery의 실험실 테스트에 따르면, 2026년 4월 현재까지도 캐스케이드 (Cascade) 방식이 실제 서비스 환경을 지배하고 있습니다. 다음은 사람들이 실제로 논쟁하는 수치들을 바탕으로 두 방식의 차이점을 비교한 것입니다.

비용 격차는 단순한 오차 범위 수준이 아닙니다. Softcery의 2026년 4월 측정 결과에 따르면, 가장 저렴한 캐스케이드 스택과 프리미엄 실시간 음성 대 음성 (Speech-to-speech) 모델 사이에는 최대 182배의 차이가 나타났습니다. 이는 1분당 1센트 미만의 비용과 약 30센트 사이의 차이를 의미합니다.

캐스케이드 방식은 분당 약 $0.05–$0.15가 소요되며 매 단계마다 깨끗한 텍스트 로그를 생성합니다. 반면 프리미엄 음성 대 음성 모델은 분당 약 $0.15–$0.60가 소요되며 더 자연스럽게 느껴지지만 감사 (Audit)하기가 훨씬 어렵습니다. 이들의 첫 오디오 출력 시간은 가장 빠른 모델의 경우 약 0.78초에서 다른 모델의 경우 거의 3초까지 다양하며, 잘 구축된 캐스케이드 방식의 엔드 투 엔드 (End-to-end) 시간인 약 1.5–3초와 비교됩니다.

대부분의 팀이 실제로 사용하는 방식은 다음과 같습니다: 하이브리드 (Hybrid) 방식입니다. 자연스러운 느낌을 주는 도입부에는 음성 대 음성 모델을 사용하고, 텍스트 로그와 도구 호출 (Tool calls)이 필요한 트랜잭션 단계에서는 캐스케이드 파이프라인 (Cascaded pipeline)으로 전환하여 사용합니다.

현재 위의 모든 출처는 모델을 측정하고 있습니다. 하지만 오디오가 전송되는 통신 선로 (Wire)를 측정하는 곳은 없습니다. 그것이 바로 저희가 설명하고자 하는 계층 (Layer)입니다.

대부분의 가이드가 생략하는 계층: 오디오가 실제로 전송되는 방식

여기에 간극이 있습니다. 가장 훌륭한 음성 에이전트 아키텍처 (Architecture) 가이드들 — AssemblyAI (2026년 4월)와 Deepgram (2026년) 등이 그 예입니다 — 는 STT, LLM, 그리고 TTS를 상세히 설명한 뒤 멈춥니다. Deepgram은 WebRTC를 전송 (Transport) 수단으로 명시하고 다음 단계로 넘어갑니다. 그들 중 누구도 그 아래에 있는 계층, 즉 오디오가 사용자의 마이크에서 에이전트로, 그리고 다시 돌아오는 실제 방식에 대해서는 설명하지 않습니다.

이제 그 부분을 채워보겠습니다.

오디오는 무언가를 타고 이동해야 합니다. 실시간 음성을 이동시키기 위한 세 가지 실제 선택지가 있으며, 이들은 서로 대체 가능하지 않습니다.

WebRTC는 정확히 이 작업을 위해 구축된 전송 (Transport) 수단입니다. UDP 위에서 실행되며, 저지연 (Low-latency) 실시간 미디어를 위해 설계되었고, 패킷 손실 (Packet loss)을 유연하게 처리하며, 방화벽을 통과할 수 있는 메커니즘을 포함하고 있습니다. 프로덕션 (Production) 환경의 음성 에이전트를 위한 신흥 합의안은 WebSockets 기반의 WebRTC입니다.

WebSockets는 TCP 위에서 실행됩니다. 제어 메시지 (Control messages), 전사 (Transcripts), 그리고 프로토타입 (Prototypes)에는 완벽하지만, TCP의 헤드 오브 라인 블로킹 (Head-of-line blocking) 현상으로 인해 하나의 패킷이 늦어지면 그 뒤의 모든 것이 중단됩니다. 이는 라이브 오디오에 있어 정확히 잘못된 특성입니다. 데모용으로는 괜찮지만, 프로덕션에서 선택하는 방식은 아닙니다.

SIP는 전화 통신 (Telephony) 경로입니다. 만약 당신의 에이전트가 PSTN을 통해 실제 전화 통화를 받는다면 SIP가 고려 대상이 됩니다. relinns의 2026년 비교 분석에서 설명하듯, 이는 전화 기반 에이전트를 위한 실시간 전송 결정 사항입니다. 웹 또는 앱 기반 에이전트의 경우, WebRTC가 기본값입니다.

따라서 대부분의 사람들이 구축하고 있는 에이전트 — 웹 및 앱 — 의 경우 정답은 WebRTC입니다. 하지만 WebRTC를 선택하는 것은 연결성 문제가 끝나는 지점이 아니라, 비로소 시작되는 지점입니다.

WebRTC는 직접적인 UDP 경로를 선호하지만, 많은 실제 네트워크 환경에서는 그러한 직접 경로가 존재하지 않기 때문입니다. 이 부분은 잠시 미뤄두세요. 두 섹션 뒤에서 그 이유를 설명하겠습니다. 먼저, "충분히 빠른" 수준에 대해 실제 수치를 적용해 보겠습니다.

실제 지연 시간 예산 (측정된 수치 기준)

목표는 다음과 같습니다: 사용자가 말을 멈춘 순간부터 에이전트가 시작되는 순간까지, 95번째 백분위수(95th percentile) 기준으로 엔드 투 엔드(end-to-end) 응답 시간을 약 800밀리초(ms) 미만으로 유지하는 것입니다. 500~700ms 미만은 자연스럽게 느껴지지만, 이를 넘어서면 좋지 않은 전화 연결처럼 느껴지기 시작합니다.

이러한 임계값은 실무자들로부터 나온 것입니다. AssemblyAI의 2026년 4월 분석에 따르면, 완전히 스트리밍되는 파이프라인(pipeline)의 예산은 600~900ms입니다. Prodinit의 2026년 프로덕션 가이드는 신뢰성의 하한선을 p95 기준 800ms 미만으로 설정하며, p50 기준 250ms 미만은 달성 가능하다고 명시합니다. AssemblyAI 또한 500~700ms를 초과하는 응답은 "부자연스럽게 느껴지기 시작한다"고 언급했습니다.

다음은 발표된 자료의 단계별 예산과 저희가 직접 측정한 빌드를 비교한 것입니다.

저희의 수치에 대해 솔직하게 말씀드리겠습니다. 저희는 실제 음성 에이전트를 구축하고 2026년 7월 14일에 이를 측정했습니다. 환경은 MacBook Pro, 16GB RAM, 가정용 네트워크이며, 스트리밍이 활성화된 OpenAI GPT, Whisper STT, OpenAI TTS의 클라우드 스택을 실행했습니다. 이것은 저희 하드웨어에서의 수치이며, 벤더의 성능 보증이 아닙니다. 전체 빌드 및 방법론은 저희의 TypeScript 음성 에이전트 튜토리얼에서 확인하실 수 있습니다.

엔드 투 엔드 (End-to-end)로 측정했을 때, 기본 버퍼링 파이프라인 (buffered pipeline)에서 첫 오디오가 나오기까지 약 2.5~3.9초가 소요되었습니다. 이는 스트리밍 방식의 이상적인 업계 기준치보다 느린 수치입니다. 이상적인 기준은 STT에 약 200500ms, LLM의 첫 토큰(first token) 생성에 150400ms, TTS에 200400ms, 그리고 네트워크에 50150ms를 소요하여 엔드 투 엔드로 약 600900ms가 걸리는 것입니다 (AssemblyAI, 2026-04-29). 교과서적인 600900ms와 실제 2.5~3.9s 사이의 격차는 모델의 품질 때문이 아니라 버퍼링 (buffering)과 콜드 스타트 (cold starts) 때문이며, 이것이 바로 핵심입니다.