6개월 만에 빠르게 반응하는 실시간 음성 AI 시스템을 구축한 방법

음성 AI에서 언제 말을 시작해야 하는지 판단하는 일은 생각보다 훨씬 어렵습니다. 사람은 순식간에 자연스럽게 대화의 차례를 주고받지만, 기존 음성 AI 시스템은 이러한 리듬을 따라가지 못했습니다. 기존 턴 기반 아키텍처는 '턴 감지기'라는 작은 모델에 의존했는데, 이 모델은 쉽지 않은 선택을 해야 했습니다. 너무 일찍 판단하면 사용자의 말을 끊게 되고, 너무 늦게 판단하면 응답이 굼뜨게 느껴집니다. 그리고 턴 감지기가 결정을 내려야만 훨씬 큰 LLM이 비로소 작업을 시작할 수 있었습니다.

3세대 음성 시스템인 GPT‑Live⁠는 오디오 처리 경로에서 턴 감지기를 제거했습니다. GPT‑Live의 음성 모델은 전이중 방식으로 동작해 듣기와 말하기를 동시에 수행할 수 있습니다. 덕분에 별도의 턴 감지기가 필요 없어졌고, 대화도 훨씬 즉각적이고 자연스러워졌습니다. 더 깊은 추론이나 툴 사용이 필요한 경우에도 GPT‑Live는 대화의 흐름을 끊지 않고 GPT‑5.5와 같은 프런티어 모델과 연동할 수 있습니다. 이러한 기능이 결합되면서 GPT‑Live는 뛰어난 대화 응답성과 추론 능력을 동시에 갖춘 새로운 음성 시스템으로 자리 잡았습니다.

이러한 경험을 대규모로 제공하려면 지연 시간을 최소화하도록 설계한 새로운 시스템 아키텍처가 필요했습니다. 일반적인 요청-응답 방식의 추론과 달리, 이 시스템은 들어오는 오디오를 음성 모델로 실시간 스트리밍하고, 생성된 음성은 다시 사용자에게 전달합니다. 위임 작업은 별도의 비동기 경로에서 처리됩니다. 지난 6개월 동안 모델 추론과 컨텍스트 관리, 미디어 전송 방식을 전면적으로 개선해 대화가 처음부터 끝까지 끊김 없이 이어지도록 했습니다.

또한 이 아키텍처는 핵심 음성 처리 경로와 애플리케이션 로직을 명확하게 분리합니다. 덕분에 응답성에는 영향을 주지 않으면서도 애플리케이션 동작을 쉽게 맞춤화할 수 있습니다. 이러한 기반은 ChatGPT 음성 대화의 기능을 계속 확장하고 있으며, 최근 추가된 컴퓨터 제어 기능과 ChatGPT 데스크톱 앱에서 에이전트를 조율하는 기능도 이 아키텍처를 기반으로 합니다.

이 글에서는 기존 턴 기반 시스템이 요구 사항을 충족하지 못했던 이유와, 모든 계층에서 응답성을 높이기 위해 새로운 시스템을 어떻게 설계했는지 설명합니다. 상태 유지형 추론과 동적 컨텍스트 관리, 비동기 위임, 프로토콜 수준의 최적화가 어떻게 함께 작동해 GPT‑Live를 실제 대화처럼 자연스럽게 만드는지 살펴보겠습니다.

기존 음성 아키텍처는 텍스트 LLM의 턴 기반 구조를 그대로 이어받았지만, 각 턴은 텍스트가 아니라 하나의 독립적인 오디오 블록으로 처리되었습니다. 계단식 시스템에서는 음성 인식(STT), LLM, 음성 합성(TTS)이 순차적으로 실행됐습니다. 이러한 구조는 지연 시간을 늘렸을 뿐 아니라 말투나 억양, 말의 속도 같은 중요한 단서도 활용하지 못했습니다.

음성-음성 모델은 오디오를 직접 처리함으로써 이러한 방식을 한 단계 발전시켰습니다. 모델이 음성을 직접 이해하고 생성하도록 학습하면서 전사 과정에서 사라지던 정보를 유지할 수 있었고 응답 속도도 빨라졌습니다. 하지만 추론을 언제 시작할지는 여전히 턴 감지기가 결정했습니다. 모델이 처리하는 역할은 늘어났지만, 대화 방식 자체는 여전히 턴 기반이었습니다.

GPT‑Live는 음성 모델이 대화의 흐름을 직접 제어합니다. 오디오는 모델로 실시간 입력되고 다시 출력되며, 더 깊은 추론과 툴 사용은 별도의 비동기 경로에서 수행됩니다. 시스템의 가장 중요한 역할은 미디어 루프를 끊김 없이 유지하는 것입니다. 프런티어 모델 호출이나 대화 저장과 같은 작업은 모두 실시간 경로 밖에서 처리됩니다.

미디어 루프를 끊김 없이 유지하는 일은 생각만큼 간단하지 않습니다. 전송이나 처리, 추론 과정에서 조금이라도 지연이 발생하면 사용자는 이를 음성의 끊김이나 잡음으로 느낄 수 있습니다. 기존 턴 기반 시스템은 오디오 데이터가 조금 늦게 도착해도 어느 정도는 허용할 수 있었지만, 실시간 미디어 시스템에서는 모든 오디오 프레임을 정해진 시간 안에 전달해야 합니다.

ChatGPT 음성 대화와 Realtime API를 개발하며 쌓은 경험은 중요한 기반이 되었습니다. OpenAI는 이미 음성 인프라를 전면 개편⁠해 오디오와 비디오를 더 낮고 예측 가능한 지연 시간으로 시스템과 직접 주고받을 수 있도록 했습니다. GPT‑Live는 이를 한 단계 더 발전시켜, 연속적인 대화를 위해 설계한 새로운 상태 유지형 추론 시스템을 통해 미디어를 모델까지 실시간으로 스트리밍합니다.

하지만 스트리밍 추론만으로는 충분하지 않았습니다. 실제 서비스 환경에서 안정적으로 동작하려면 클라이언트에서 추론 스택까지 오디오를 안정적으로 전달하는 것은 물론, 상태를 유지하는 시스템이 갖는 여러 과제도 함께 해결해야 했습니다.

초기에 내린 중요한 설계 결정 중 하나는 미디어 전송 경로를 애플리케이션 및 비즈니스 로직과 분리하는 것이었습니다. 오디오는 전용 고속 경로를 통해 클라이언트와 음성 모델 사이를 오갑니다. 반면 위임과 툴 사용, 기타 애플리케이션 작업은 비동기 RPC 경계 뒤에서 처리됩니다. 따라서 툴 호출이나 백엔드 서비스가 느려지더라도 해당 작업의 결과만 늦어질 뿐, 오디오 스트림 자체는 멈추지 않습니다.

이처럼 역할을 분리하면 시스템을 훨씬 유연하게 맞춤화할 수 있습니다. 애플리케이션은 툴이나 정책, 백엔드 동작을 자유롭게 변경하더라도 오디오 전송을 담당하는 미디어 프런트엔드에는 영향을 주지 않습니다. 덕분에 실시간 경로는 규모를 작게 유지하면서도 예측 가능하게 동작하며, 반드시 실시간으로 처리해야 하는 작업에만 집중할 수 있습니다.

미디어 프런트엔드와 추론 로직은 기존 Python asyncio 구현을 대신해 Go로 새롭게 작성했습니다. 그 결과 오디오 프레임 전달이 훨씬 안정적으로 이루어졌으며, 새 시스템의 p95 성능이 이전 시스템의 p50 수준에 이를 만큼 크게 개선되었습니다.

전송 계층은 WebRTC를 기반으로 합니다. WebRTC는 지연 시간이 짧은 미디어 전송을 위해 설계되었으며, 패킷 손실이나 송수신 장치 간의 시간 오차, 클라이언트 연결 변화가 발생해도 안정적으로 동작합니다. 패킷이 늦게 도착하면 오디오를 아주 미세하게 늘려 재생이 끊기지 않도록 하고, 이후에는 잠시 재생 속도를 높여 다시 실시간 재생 속도에 맞춥니다.

시스템 전반에서 버퍼링과 블로킹을 최소화한 덕분에 사람의 대화에서 기대하는 1초 미만의 빠른 응답성을 구현할 수 있었습니다.

상태 유지형 추론에는 운영상의 여러 트레이드오프가 따릅니다. 음성 세션은 오랫동안 유지될 수 있지만 대화 컨텍스트는 계속 커지고, 모델 인스턴스도 수요에 따라 생성되고 종료됩니다.

이러한 문제를 해결하기 위해 모델 인스턴스 간에 끊김 없이 전환할 수 있는 핸드오프 메커니즘을 구축했습니다. 전환이 필요하면 기존 인스턴스를 계속 실행하는 동시에 새로운 인스턴스를 미리 준비하고, 현재 세션의 컨텍스트를 미리 로드한 뒤 두 인스턴스에서 병렬로 추론을 수행합니다. 새로운 인스턴스의 준비가 완료되면 즉시 전환할 수 있습니다.

이 메커니즘은 동적 컨텍스트 압축에도 활용됩니다. 대화가 길어질수록 누적된 컨텍스트는 결국 모델의 컨텍스트 한도를 초과하게 됩니다. 컨텍스트 압축을 수행하면 한도 안으로 줄일 수 있지만, 이 과정에는 시간이 걸립니다. 또한 과거 컨텍스트가 변경되면 이전에 처리한 토큰의 어텐션 키와 값을 저장한 키-값(KV) 캐시도 더 이상 사용할 수 없게 됩니다. 이 상태를 다시 만들려면 컨텍스트를 다시 미리 로드해야 하므로 추가 지연이 발생합니다.

그래서 컨텍스트 압축도 또 하나의 전환 과정으로 처리합니다. 기존 모델 인스턴스가 계속 대화를 이어가는 동안 시스템은 컨텍스트를 압축하고, 새 컨텍스트를 적용한 대체 모델 인스턴스를 준비합니다. 새로운 인스턴스의 준비가 끝나면 오디오를 끊지 않고 바로 전환할 수 있습니다. 덕분에 장시간 이어지는 통화에서도 필요할 때마다 컨텍스트를 압축하면서 대화를 계속 이어갈 수 있습니다.

무거운 작업은 모두 실시간 경로 밖에서 처리되므로, 핸드오프가 진행되는 동안에도 대화는 한순간도 끊기지 않습니다.

GPT‑Live는 기존 프런티어 모델을 호출할 수 있기 때문에, '말하기'와 더 깊은 '추론'을 사실상 분리해 수행할 수 있습니다. 하지만 이러한 두 모델 구조를 사용자에게 하나의 시스템처럼 자연스럽게 느끼게 하려면, 서로 맞물린 두 가지 엔지니어링 과제를 해결해야 했습니다.

먼저, 진행 중인 대화에 도움이 되려면 결과가 충분히 빠르게 반환되어야 했습니다. 이를 위해 라우팅과 프롬프트 처리부터 추론, 툴 호출에 이르는 위임 경로 전체에서 지연 시간을 최소화해야 했습니다. 동시에 제품의 다른 시스템은 여전히 개별 메시지 단위로 동작하기 때문에, 이어지는 음성 대화를 해당 시스템이 이해할 수 있는 형태의 메시지로 표현하는 방법도 필요했습니다.

위임이 시작되면 프런티어 모델이 대화에 도움이 되는 결과를 최대한 빨리 생성하도록 최적화합니다. 프런티어 모델이 추론하거나 툴을 사용하는 동안에도 음성 모델이 잠시 대화를 이어갈 수는 있지만, 지나치게 느린 응답까지 감출 수는 없습니다. 따라서 라우팅과 프롬프트 처리, 추론, 툴 호출로 이어지는 위임 과정 전체를 응답성 예산의 일부로 보고 최적화했습니다.

첫 번째 최적화는 위임이 요청되기 전에 프런티어 모델과 필요한 툴을 미리 준비하는 것입니다. 음성 세션이 시작되면 애플리케이션 서버는 프런티어 모델용 추론 세션을 생성하고 초기 대화 컨텍스트를 미리 로드해 둡니다. 이렇게 하면 첫 번째 위임 요청이 들어오기 전에 프롬프트 처리가 모두 완료됩니다.

이후에는 음성 대화가 이어지는 동안 해당 추론 세션을 계속 유지하고, 연속된 요청은 안정적인 세션 어피니티를 사용해 동일한 세션으로 전달합니다. 이러한 방식은 프롬프트 캐싱과 함께 지연 시간을 줄이면서도, 워커에 장애가 발생했을 때 쉽게 복구할 수 있도록 해 줍니다.

추론 수준과 출력 제한, 툴 스키마, 모델과 툴 간 왕복 호출 횟수도 대화가 유용한 결과를 받는 시점에 영향을 미칩니다. 그래서 이러한 요소를 조정해 응답 속도를 높였습니다. 위임 경로에서 필요한 작업을 최소화함으로써 음성 모델이 프런티어 모델의 결과를 빠르게 반영할 수 있도록 했습니다.

음성 모델은 연속적인 음성 스트림을 처리하지만, ChatGPT 대화 UI를 비롯해 분석 및 안전 인프라의 여러 구성 요소는 여전히 사용자와 어시스턴트의 턴 단위로 동작합니다. 따라서 애플리케이션 서버는 서로 겹치거나 경계가 모호한 대화를 개별 메시지로 나누어 처리합니다.

오디오가 들어오면 서버는 부분 전사 결과와 타이밍 신호를 이용해 현재 누가 발화하고 있는지 판단하고, 이를 바탕으로 메시지 큐를 구성합니다. 가장 최근 메시지는 임시 상태로 유지되며, 이후 음성이 더 들어오면 내용과 시점, 화자 구분이 모두 변경될 수 있습니다. 화자 판별에 충분한 확신이 생기면 해당 메시지를 최종 확정합니다.

화자가 동시에 말하는 상황에서는 처리가 더욱 복잡해집니다. 사용자가 말하는 도중 어시스턴트가 "음", "네"처럼 짧게 반응한 경우에는 이를 별도의 메시지로 만들 필요가 없습니다. 반면 의미 있는 개입이라면 독립된 메시지로 처리하는 편이 적절합니다. 또한 사용자가 중간에 말을 시작하더라도 화면에 표시되는 어시스턴트의 응답은 최대한 자연스럽고 일관성 있게 유지되도록 합니다.

메시지를 어디에서 나눌지 결정하는 모든 정책은 최신성과 확실성 사이에서 균형을 맞춰야 합니다. 너무 일찍 확정하면 대화 기록이 잘게 나뉘고 순서도 불안정해집니다. 반대로 너무 오래 기다리면 전사 결과와 이를 사용하는 기능들이 모두 늦어집니다. 그래서 시스템은 두 가지 형태의 대화 기록을 유지합니다. 하나는 현재 상태를 반영하는 추정 기록이고, 다른 하나는 실제 발화를 확정한 최종 기록입니다. 애플리케이션 UI의 대화 화면은 업데이트를 지원하므로 추정 기록을 사용하고, 분석 파이프라인에 남기는 로그에는 최종 전사 결과를 사용합니다.

이를 통해 실시간 음성 경로에는 턴 기반 제약을 적용하지 않으면서도, ChatGPT의 다른 시스템에서는 대화를 안정적인 형태로 활용할 수 있습니다.

응답성은 사용자가 버튼을 누르는 순간부터 시작됩니다. GPT‑Live에서는 대화를 시작하기 전에 미디어 경로를 설정하고 오디오를 모델로 전달하기 시작해야 합니다. 따라서 시작 과정의 모든 단계가 성능을 좌우하는 핵심 경로가 됩니다.

앞에서 설명했듯이 WebRTC는 실시간 통신을 위한 훌륭한 기반이지만, 기본 WebRTC 세션을 시작하려면 예상보다 많은 프로토콜 핸드셰이크와 네트워크 왕복이 필요합니다. WebRTC는 QUIC처럼 왕복 횟수를 최소화하는 방향으로 설계된 최신 프로토콜보다 먼저 만들어졌습니다. 그 결과 여러 하위 프로토콜을 함께 사용할 때 동일한 작업이 중복 수행되는 경우가 있습니다. 예를 들어 각 프로토콜은 전체 WebRTC 스택에서는 필요하지 않은 상황에서도 자체적인 DoS 방어 메커니즘을 포함하고 있었습니다.

OpenAI는 WebRTC 스택을 분석해 WARP⁠(새 창에서 열기)(WebRTC Abridged Roundtrip Protocol)를 개발했습니다. WARP는 미디어와 데이터 연결을 시작하는 데 필요한 네트워크 왕복 횟수를 여섯 번에서 한 번으로 줄여 줍니다. 이를 위해 DTLS 핸드셰이크를 ICE에 함께 전송하는 SPED⁠(새 창에서 열기), 더 빠른 DTLS 1.3⁠(새 창에서 열기) 핸드셰이크, SCTP 핸드셰이크를 미리 협상하는 SNAP⁠(새 창에서 열기), DCEP⁠(새 창에서 열기) 대신 데이터 채널을 사전 협상하는 방식 등 기존과 호환되는 여러 프로토콜 개선 사항을 적용했습니다.

WARP는 WebRTC 커뮤니티와 협력해 누구나 활용할 수 있는 공개 규격으로 설계했습니다. 현재 관련 제안은 IETF TSVWG 작업 그룹에서 표준화를 추진하고 있으며, WARP는 이미 libwebrtc와 Pion에 적용되었습니다. 다른 WebRTC 구현체에도 지원을 확대하기 위한 작업이 진행 중입니다.

미디어 핸드셰이크를 최적화한 뒤에도 한 가지 지연 요인이 남아 있었습니다. 바로 WebRTC 연결 전에 SDP 파라미터를 주고받는 시그널링 과정입니다. 이 과정을 핵심 경로에서 제거하기 위해 Instant Connect를 개발했습니다. Instant Connect는 서버 리소스를 미리 예약하지 않고도 SDP 파라미터를 사전에 협상하며, 기존 WebRTC 구현을 변경할 필요도 없습니다.

Instant Connect는 기존 시그널링 절차와 함께 동작합니다. 사전에 협상한 파라미터가 유효하면 첫 번째 미디어 패킷이 도착하는 즉시 서버에서 세션을 생성할 수 있습니다. 파라미터가 오래되었거나 유효하지 않더라도 기존 시그널링이 이미 진행 중이므로 추가 지연 없이 기존 방식으로 전환할 수 있습니다.

Instant Connect와 WARP를 함께 적용하면 사용자가 대화를 시작하려는 순간부터 실시간 미디어 전송이 시작되기까지 걸리는 시간을 크게 줄일 수 있습니다. SDP 교환을 핵심 경로에서 제거하고 WARP가 전송 핸드셰이크를 하나로 줄인 덕분에 이제 클라이언트는 UDP 패킷 하나만으로 세션을 시작할 수 있습니다. 서버도 즉시 응답을 시작할 수 있어, 시스템은 사용자가 가장 중요하게 생각하는 일인 듣고 응답하는 것에 바로 집중할 수 있습니다.

시스템은 이론상으로는 충분히 빠르게 보일 수 있지만, 실제 음성 트래픽이 들어오면 쉽게 병목이 발생할 수 있습니다. GPT‑Live를 실제 사용자에게 제공하기 전에, 운영 중인 ChatGPT 음성 대화 세션 가운데 일부를 기존 고급 음성 모드와 새 시스템으로 동시에 점진적으로 분산하는 사일런트 테스트를 진행했습니다. 고급 음성 모드는 평소처럼 사용자에게 서비스를 제공했고, 섀도 경로에서는 읽기 전용 모드로 추론만 수행했습니다. 덕분에 사용자가 실제로 듣는 결과는 그대로 유지하면서도 실제 클라이언트, 네트워크, 세션 길이, 지역별 분포 환경에서 시스템을 검증할 수 있었습니다.

가장 먼저 얻은 교훈은 시스템 용량을 GPU 처리량만으로 판단해서는 안 된다는 점이었습니다. 음성 세션은 연결을 유지한 채 오디오 프레임을 계속 전송하기 때문에 CPU 측 스트림 처리기와 큐, 네트워크 경로도 추론 성능에 맞춰 함께 확장되어야 합니다. 실제 부하 환경에서는 지원 컴포넌트 하나가 부하 테스트에서 예상했던 것보다 먼저 한계에 도달했고, 그 결과 추론 요청이 쌓이면서 지연도 연쇄적으로 증가했습니다. 이에 따라 용량을 평가하는 기준도 "GPU 한 대가 요청을 몇 건 처리할 수 있는가?"에서 "모든 프레임을 제시간에 처리하면서 시스템이 동시에 몇 개의 세션을 안정적으로 유지할 수 있는가?"로 바꾸었습니다.

이번 테스트를 통해 사용자와 인프라의 물리적 거리도 성능에 큰 영향을 미친다는 사실을 확인했습니다. 세션을 멀리 떨어진 리전의 처리 리소스로 라우팅하면 연결을 시작하거나 스트리밍하는 과정 곳곳에서 지연이 발생할 수 있습니다. 이에 따라 모델 배포를 검증할 때는 지역별 처리 용량과 트래픽 분산 설정도 함께 점검하고, 지연 시간을 사용자의 접속 지역별로 분석하기 시작했습니다. 추론을 사용자와 더 가까운 위치에서 수행하자 응답 속도는 개선됐지만, 더 중요한 교훈도 얻었습니다. 엔드 투 엔드 응답성은 모델 서버 하나만이 아니라 요청이 거치는 모든 서비스가 함께 만들어 낸다는 점입니다.

실제와 유사한 세션 수명 주기에서만 드러나는 문제도 있었습니다. 장시간 유지되는 세션에서는 메모리와 영속성 계층에 부담이 가중됐고, 재연결 과정에서는 컨텍스트 압축과 상태 복원이 제대로 동작하는지 확인할 수 있었습니다. 일반적인 클라이언트 연결 종료 과정에서는 종료 핸드셰이크에서 경쟁 상태가 발생하는 문제도 드러났습니다. 이러한 문제는 시간의 경과와 누적된 상태, 그리고 여러 서비스 간 상호작용에 영향을 받기 때문에 짧은 부하 테스트에서는 거의 발견되지 않았습니다.

마지막으로 프로덕션 환경에서의 테스트는 옵저버빌리티와 배포 제어 체계도 개선하도록 만들었습니다. 서로 다른 지연 원인을 하나로 집계하는 지표와 개별 엔진의 이상 상태를 숨기는 대시보드 집계 방식, 그리고 테스트 환경과 실제 배포 환경 사이의 설정 불일치 문제를 발견했습니다. 이를 해결하기 위해 더 세분화된 텔레메트리를 추가하고, 검증된 설정과의 일치 여부를 확인하는 검증 절차와 단계적 트래픽 확대, 특정 경로를 빠르게 격리하거나 비활성화할 수 있는 기능을 도입했습니다. 사일런트 테스트는 단순히 시스템이 얼마나 많은 트래픽을 처리할 수 있는지 확인하는 단계를 넘어, 장애를 얼마나 빠르게 탐지하고 격리하며 복구할 수 있는지까지 점검하는 출시 리허설 역할을 했습니다.

GPT‑Live를 ChatGPT 규모로 제공하려면 하나의 원칙을 중심으로 완전히 새로운 시스템을 설계해야 했습니다. 바로 음성이 끊김 없이 이어져야 한다는 것입니다. 스트리밍 추론은 전이중 모델에 오디오를 지속적으로 공급하고, 전용 미디어 경로는 오디오 프레임을 안정적으로 전달합니다. 비동기 위임은 더 깊은 추론을 병렬로 수행할 수 있게 하며, 최적화된 전송 계층은 사용자에게 전달되는 마지막 순간까지 빠르고 자연스러운 응답성을 유지합니다.

GPT‑Live의 아키텍처는 이미 실시간 상호작용을 위한 범용 플랫폼으로 발전하고 있습니다. 이 아키텍처는 ChatGPT 음성 대화가 단순한 대화를 넘어 에이전트 간 협업까지 지원하도록 기반을 제공하고 있으며, 앞으로 공개될 GPT‑Live API의 토대가 될 것입니다. 장기적으로는 음성 대화 특유의 즉각적인 반응성을 그대로 유지하면서도 더 다양한 기기와 앱, 여러 상호작용 방식으로 음성 경험을 확장할 수 있게 될 것입니다.

이런 엔지니어링 문제를 함께 해결하고 싶다면, OpenAI와 함께하세요⁠.