320밀리초의 대화

AI 음성 모드가 어떻게 5초짜리 Q&A 봇에서 문장 중간에 말을 끊는 수준까지 발전했는지 — 그리고 그 단계에 도달하기 위해 무엇을 완전히 재구축해야 했는지에 대하여.

Bar chart comparing AI voice response times: GPT-4 Voice Mode's cascaded pipeline at roughly 5.4 seconds versus GPT-4o Realtime's native audio at 320 milliseconds, plotted on a 0–6 second timeline.

ChatGPT의 음성 모드나 Gemini Live를 열고, 문장 중간에 말을 가로채듯 대화해 보세요. AI는 즉시 멈춥니다. 자신이 말하던 문장을 마친 후가 아니라, 어색한 0.5초의 지연 시간 뒤에 멈추는 것도 아닙니다. 마치 상대방이 말을 시작했다는 것을 깨달았을 때 사람이 멈추는 방식 그대로 멈춥니다.

몇 년 전만 해도 이와 같은 상호작용은 고통스러웠습니다. 질문을 던지면 스피너(spinner)가 돌아가는 것을 지켜보며 3초에서 5초를 기다려야 했고, 돌아오는 결과물은 단조롭고 묘하게 박자가 맞지 않는 문단 낭독이었습니다. 이제는 전화 통화에 더 가깝게 느껴집니다. 기업도 같고, "AI와 대화한다"는 기본적인 개념도 같지만, 그 과정 어딘가에서 도구를 사용하는 느낌을 넘어 무언가와 대화하는 느낌으로 변했습니다.

그렇다면 실제로 무엇이 변했을까요? 단순히 "모델이 더 똑똑해졌다"는 것은 아닙니다 — 물론 조금은 더 똑똑해졌지만 말이죠. 더 큰 이야기는 모델이 학습되는 방식부터 브라우저가 사용하는 네트워크 프로토콜(network protocol)에 이르기까지, 휴대폰과 모델 사이에서 오디오가 이동하는 방식 전반을 거의 완전히 재구축했다는 점에 있습니다.

전화 놀이를 하는 세 가지 모델

최근까지 ChatGPT 음성 모드의 첫 번째 버전을 포함한 모든 AI 음성 비서는 내부적으로 동일한 방식으로 작동했습니다. 즉, 세 개의 별개 모델이 일렬로 결합되어 각각의 출력을 다음 모델로 전달하는 방식이었습니다.

Diagram of the old voice AI pipeline: three separate models in sequence — Speech-to-Text (Whisper), then an LLM (GPT-3.5/GPT-4), then Text-to-Speech — connected by arrows labeled

각각의 핸드오프 (handoff)는 지연 시간 (latency)을 추가하며, 이는 빠르게 누적됩니다. 음성 모드에서 응답하는 데 GPT-3.5는 약 2.8초, GPT-4는 5.4초가 소요됩니다. 하지만 솔직히 말해서, 지연 시간은 최악의 부분조차 아니었습니다. 진짜 손실은 정보였습니다. 당신의 목소리가 텍스트가 되는 순간, 문자 그대로의 단어가 아닌 모든 것들 — 당신의 어조 (tone), 속도 (pacing), 짜증이 났는지 혹은 즐거워하는지 등 — 이 사라졌습니다. LLM (Large Language Model)은 그 어떤 것도 듣지 못했습니다. 그리고 맨 마지막 단계의 TTS (Text-to-Speech) 모델 또한 답변이 어떤 감정을 담아야 하는지 전혀 알 수 없었습니다. 왜냐하면 그 모델이 받은 것도 결국 텍스트 문자열뿐이었기 때문입니다.

이는 전형적인 '전화기 게임 (telephone-game)' 문제입니다. 뇌를 공유하지 않는 세 개의 모델이 좁은 텍스트 형태의 틈을 통해 서로에게 쪽지를 전달하고 있는 셈입니다.

하나의 모델, 오디오 입력, 오디오 출력

해결책은 — OpenAI가 2024년 중반 GPT-4o를 통해 가장 먼저 출시했고, 얼마 지나지 않아 Google이 Gemini 2.5 Flash의 네이티브 오디오 (native-audio) 모델로 뒤를 이은 방식 — 이 세 단계를 하나의 단일 모델로 통합하는 것입니다.

Diagram of the unified voice AI architecture: a single omni model (GPT-4o / Gemini 2.5) that takes audio in and produces audio out directly, with one continuous waveform preserved through the box and no intermediate stages.

OpenAI의 자체 시스템 카드 (system card)는 GPT-4o를 다음과 같이 설명합니다: "텍스트, 오디오, 이미지, 비디오의 어떠한 조합이라도 입력으로 받아들이고 텍스트, 오디오, 이미지의 어떠한 조합이라도 출력으로 생성하는 자기회귀 옴니 모델 (autoregressive omni model)이다... 텍스트, 비전 (vision), 오디오 전반에 걸쳐 엔드투엔드 (end-to-end)로 학습되었으며, 이는 모든 입력과 출력이 동일한 신경망 (neural network)에 의해 처리됨을 의미한다." 쉽게 말해, 더 이상 핸드오프 (handoff)가 존재하지 않습니다. 당신의 말을 듣는 네트워크가 무엇을 말할지 결정하는 네트워크와 동일하며, 그것을 실제로 말하는 네트워크도 동일합니다.

Three stat cards: GPT-4o's fastest audio response time of 232 milliseconds, its average response time of 320 milliseconds, and Gemini 2.5 Flash native audio's first-response time of 320–800 milliseconds.

오디오가 실제로 이동하는 방식

이를 실시간으로 구현하기 위해 OpenAI는 새로운 것, 즉 Realtime API를 구축해야 했습니다. 모든 메시지가 각각 새로운 API 호출이 되는 일반적인 요청-응답 (request-response) 패턴 대신, WebSocket 또는 WebRTC 연결 중 하나를 통해 하나의 지속적인 연결을 열고 대화 전체 동안 이를 유지합니다.

Diagram of a WebRTC connection between a browser or mobile app and the Realtime API, exchanging UDP, auto-timestamped audio in both directions.

Diagram of a WebSocket connection chain: a phone system (e.g. Twilio) connects to your server, which holds a persistent socket connection to the Realtime API, exchanging base64-encoded PCM audio events.

오디오 자체는 보통 16kHz 또는 24kHz의 16비트 PCM 방식으로 전송됩니다 (Gemini의 Live API는 구체적으로 입력은 16kHz PCM, 출력은 24kHz PCM을 요구합니다). 전화 통신용인 G.711도 작동하지만, 한 가지 문제가 있습니다. 8kHz 오디오를 모델의 네이티브 24kHz로 변환하는 과정에서 50~100ms의 시간이 추가로 소요되며 음질도 저하됩니다.

언제 말을 멈출지 판단하기

"말하는 즉시 멈추는" 동작은 음성 활동 감지 (Voice Activity Detection, VAD) 덕분입니다. 기본적인 버전인 **서버 VAD (server VAD)**는 단순히 침묵을 감시합니다. 약 500ms 동안 멈추면 사용자가 말을 마친 것으로 간주합니다. **시맨틱 VAD (Semantic VAD)**는 더 새롭고 흥미로운 방식입니다. 이는 방금 한 말이 끝난 것처럼 들리는지를 판단하는 분류기 (classifier)입니다. "음..." 하며 말을 흐리면 더 오래 기다리고, 완전한 생각처럼 들리는 문장으로 끝내면 거의 즉시 대화에 끼어듭니다.

실제로 말을 가로챌 때, 시스템은 response.cancelled를 발생시키며 모델이 재생을 완료하지 못한 오디오는 대화 기록에서 잘려 나갑니다 (truncated). 따라서 모델은 자신이 실제로 소리 내어 말한 내용만 "기억"하며, 말하려고 했던 내용은 기억하지 못합니다. WebRTC는 서버가 이미 오디오가 얼마나 재생되었는지 정확히 알고 있기 때문에 이 부분을 자동으로 처리합니다. 일반적인 WebSocket을 사용할 경우, 클라이언트가 이를 직접 추적하여 어디서 끊겼는지 서버에 알려주어야 합니다.

트레이드오프 (The Trade-offs)

첫 번째 트레이드오프: 검사할 수 있는 텍스트 기록(transcript)을 잃게 됩니다. 모든 것이 텍스트로 처리될 때는 모더레이션 (moderation)이 간단했습니다. 그냥 텍스트를 읽으면 되었으니까요. 오디오 네이티브 모델 (audio-native models)의 경우, OpenAI는 여전히 전사 (transcription)된 내용에 대해 기존의 텍스트 기반 검사를 수행하지만, 오디오가 생성되는 동안 이를 감시하는 두 번째 실시간 분류기 (classifier)를 추가합니다. 이 분류기는 목소리가 승인된 프리셋 중 하나와 일치하는지 확인하며, 범위를 벗어날 경우 작동을 중단시킵니다. OpenAI는 내부 테스트 결과 이 설정이 **"시스템 음성으로부터의 의미 있는 편차를 100% 포착한다"**고 밝혔습니다. 이는 주로 모델이 사용자의 목소리를 실수로 복제하는 것을 방지하기 위함입니다.

두 번째 트레이드오프이며, 대부분의 사람들이 생각하는 것보다 더 큰 문제입니다: 음성은 그저 비쌉니다. 원래 Realtime API의 토큰당 가격 구조는 다음과 같았습니다:

Bar chart comparing OpenAI Realtime API token pricing: text input at $5 per million tokens, text output at $20, audio input at $100, and audio output at $200 per million tokens.

이는 대략 텍스트 입력 가격의 20배, 텍스트 출력 가격의 10배에 달합니다. 이것이 바로 텍스트 채팅은 기본적으로 무료처럼 느껴지는 반면, 음성 기능은 일일 제한이 있는 유료 티어 뒤에 숨겨져 있는 실제 이유입니다. 대화에 사용하는 매 초마다, 타이핑할 때는 결코 발생하지 않았던 방식의 계량기가 돌아가고 있기 때문입니다.

세 번째: WebRTC로 전환한다고 해서 자동으로 승리하는 것도 아닙니다. 일부 팀들은 기본적으로 더 나은 오디오를 기대하며 잘 작동하던 WebSocket 파이프라인을 WebRTC로 교체했다가, 오히려 정반대의 결과를 얻기도 했습니다. WebRTC의 지터 버퍼 (jitter buffer)는 두 네트워크 피어 (peer) 사이의 예측 불가능한 타이밍을 부드럽게 만들기 위해 설계되었지만, AI가 생성한 오디오는 그런 방식의 스케줄로 도착하지 않습니다. 동일한 프레임 페이싱 (frame-pacing) 로직 (프리버퍼링을 포함하여 한 번에 20ms 프레임씩 처리하는 방식)을 다시 구축하지 않으면, WebRTC를 통한 오디오는 일반 소켓 (socket)을 사용할 때보다 실제로 더 나쁘게 들립니다.

철학적 마무리

이 모든 것에 대해 제가 느끼는 핵심은 이것입니다. 이 과정의 거의 대부분은 모델이 더 "똑똑해지는" 것과는 관련이 없습니다. 더 나은 추론 (reasoning), 더 많은 사실, 더 큰 컨텍스트 윈도우 (context window) — 이것이 여기서 말하는 진짜 이야기가 아닙니다. 이것은 생각과 말 사이의 간극을 더 이상 느껴지지 않을 때까지 좁히는 것에 관한 것이며, 그 후 이 기업들이 저렴하게 검열(moderate), 기록(log), 가격을 책정할 수 있었던 유일한 형식인 텍스트가 더 이상 중간 단계로서 존재하지 않을 수도 있다는 사실을 바탕으로 안전 및 가격 모델 전체를 재구축하는 것에 관한 것입니다.

곰곰이 생각해보면 이는 기묘한 거래입니다. 대화에서 느껴지는 현존감 — 중단 가능하고, 정서적으로 반응하며, 즉각적인 — 이 AI가 실제로 무엇을 말했는지 확인할 수 있는 능력보다 더 가치 있다고 베팅하는 것이니까요.

생각해 보면 232밀리초는 진정한 성취가 아닙니다. 진정한 성취는 그 단계에 도달하기 위해 이 기업들이 의도적으로 자신들의 시스템을 검사하기 더 어렵게 만들어야 했고, 이를 보완하기 위해 분류기 (classifier)라는 완전히 새로운 레이어를 구축해야 했다는 점입니다. 실제로 사람처럼 느껴지는 AI와 대화하는 것은 훨씬 더 어려운 문제와 분리될 수 없음이 드러났습니다. 바로, 더 이상 단순히 읽을 수만으로는 안 되는 시스템을 신뢰해야 한다는 문제입니다.

Sources

OpenAI — GPT-4o System Card (arXiv:2410.21276)
OpenAI — "Realtime API 소개"
OpenAI — "gpt-realtime 및 프로덕션용 음성 에이전트를 위한 Realtime API 업데이트 소개"
OpenAI Platform Docs — 실시간 대화 (Realtime conversations), 음성 활동 감지 (Voice Activity Detection), 비용 관리 (Managing costs)
Google AI for Developers — Gemini Live API 개요 및 Gemini 2.5 Flash Native Audio
Latent Space — "OpenAI Realtime API: Missing Manual"
프로덕션 엔지니어링 기술 문서: Skywork, Effloow, Forasoft, DEV Community (WebRTC/WebSocket 페이싱 (pacing))