GPT-Live의 실시간 음성 AI 아키텍처, 자연스러운 대화를 만드는 6개월의 시스템 설계

음성 AI가 사람과 대화할 때 가장 중요한 것은 단순히 얼마나 똑똑한 답변을 내놓느냐가 아닙니다. 사용자가 말을 끝내기도 전에 너무 빨리 끼어들면 대화가 어색해지고, 반대로 답변을 시작하는 데 시간이 오래 걸리면 시스템이 느리게 느껴집니다.

사람은 대화 중 상대방의 말이 끝나는 시점과 자신의 말을 시작할 시점을 자연스럽게 판단합니다. 하지만 기존 음성 AI는 이 과정을 작은 ‘턴 감지 모델’에 의존하는 경우가 많았습니다. 너무 일찍 판단하면 사용자의 말을 끊고, 너무 늦게 판단하면 응답이 굼떠지는 문제가 발생합니다.

GPT-Live는 이 구조를 바꾸는 데서 출발합니다. 음성을 한 번의 입력 단위로 처리하고 기다리는 대신, 음성을 지속적으로 주고받는 스트리밍 구조를 사용합니다. 음성 모델은 듣는 동시에 말할 수 있는 Full-duplex 방식으로 동작하고, 더 깊은 추론이나 검색, 도구 사용이 필요할 때는 프런티어 모델에 비동기적으로 작업을 위임합니다.

중요한 점은 빠른 음성 모델 하나만으로 이러한 경험을 만든 것이 아니라는 것입니다. 음성 전송부터 모델 추론, 대화 상태 관리, 컨텍스트 관리, 모델 간 위임, 네트워크 연결까지 전체 시스템을 실시간 대화에 맞게 다시 설계했습니다.

반응형

기존 턴 기반 음성 AI가 가진 한계

기존 음성 AI의 구조는 텍스트 기반 LLM의 처리 방식과 비슷했습니다. 사용자가 말을 하고, 하나의 입력이 완성되면 시스템이 이를 처리한 뒤 답변하는 방식입니다.

특히 음성 AI에서는 여러 단계가 순차적으로 연결되기도 했습니다.

음성 입력을 텍스트로 변환하고, LLM이 텍스트를 처리한 다음, 다시 음성을 생성하는 구조입니다. 이 과정은 각 단계가 끝나야 다음 단계가 시작되기 때문에 자연스럽게 지연시간이 발생합니다.

Speech-to-Speech 모델은 이런 문제를 줄였습니다. 음성을 텍스트로 완전히 변환한 뒤 처리하는 것이 아니라 음성을 직접 이해하고 생성하기 때문에 말투나 속도와 같은 음성의 특징을 더 잘 유지하면서 빠르게 응답할 수 있습니다.

하지만 여전히 문제가 남아 있었습니다.

모델이 아무리 빠르게 처리하더라도 먼저 ‘사용자가 말을 끝냈는가’를 판단해야 했기 때문입니다. 결국 음성 모델이 개선되어도 대화 자체는 턴 기반으로 동작했습니다.

GPT-Live는 여기에서 한 단계 더 나아갑니다.

음성 모델이 대화 흐름을 직접 처리하고, 오디오가 모델 안으로 계속 들어오고 나가도록 구성합니다. 즉, 대화의 중심을 ‘한 턴씩 처리하는 것’에서 ‘끊기지 않는 미디어 흐름을 유지하는 것’으로 바꾼 것입니다.

GPT-Live의 핵심은 지속적인 스트리밍 추론

실시간 음성 AI에서 가장 중요한 것은 음성이 계속 흘러가는 것입니다.

일반적인 요청-응답 방식에서는 입력 데이터가 조금 늦게 도착해도 어느 정도 허용할 수 있습니다. 하지만 실시간 음성에서는 이야기가 다릅니다. 오디오 프레임이 일정한 시간에 전달되지 않으면 사용자는 바로 끊김이나 지연을 느낄 수 있습니다.

그래서 GPT-Live는 입력 음성을 음성 모델까지 스트리밍하고, 모델에서 생성되는 음성 역시 사용자에게 지속적으로 전달하는 구조를 사용합니다.

여기서 중요한 설계가 하나 더 들어갑니다.

미디어 흐름과 애플리케이션 로직을 분리한 것입니다.

음성 데이터는 클라이언트와 음성 모델 사이의 빠른 전용 경로를 통해 전달됩니다. 반면 도구 호출이나 백엔드 작업, 모델 위임과 같은 작업은 비동기 RPC 경계를 통해 별도로 처리합니다.

이렇게 하면 특정 도구나 백엔드 서비스가 느려져도 음성 자체가 멈추지 않습니다.

예를 들어 검색이나 다른 작업의 결과를 기다리는 동안에도 음성 모델은 대화 흐름을 유지할 수 있습니다. 느린 작업은 자신의 결과만 늦어질 뿐, 실시간 음성 경로 전체를 막지 않는 구조입니다.

Go와 WebRTC를 활용한 미디어 경로 최적화

GPT-Live의 미디어 프론트엔드와 추론 로직은 Go로 작성됐습니다. 이전 Python asyncio 기반 구현을 교체하면서 오디오 프레임 전달의 부드러움이 크게 개선됐으며, 새로운 시스템의 p95 지연시간이 이전 시스템의 p50 수준에 해당할 정도로 개선됐습니다.

음성 전송의 기반에는 WebRTC가 사용됩니다.

WebRTC는 낮은 지연시간의 실시간 미디어 전송을 위해 설계됐으며 패킷 손실이나 클라이언트 연결 변화 같은 상황에서도 미디어 흐름을 유지할 수 있습니다.

예를 들어 패킷이 늦게 도착했을 때 오디오에 빈 구간이 생기지 않도록 재생을 미세하게 조절하고, 이후 재생 속도를 잠시 높여 다시 실시간 상태로 따라잡을 수 있습니다.

결국 목표는 단순합니다.

불필요한 버퍼링과 블로킹을 최대한 줄이고, 사용자가 기대하는 1초 이하 수준의 반응성을 유지하는 것입니다.

장시간 대화를 유지하려면 상태 관리가 필요하다

실시간 음성 대화가 길어지면 또 다른 문제가 발생합니다.

대화가 계속될수록 컨텍스트가 커지기 때문입니다. 동시에 사용량에 따라 모델 인스턴스가 시작되고 종료될 수도 있습니다.

따라서 단순히 하나의 모델 인스턴스를 계속 유지하는 것만으로는 충분하지 않습니다.

GPT-Live는 모델 인스턴스를 변경해야 할 때도 대화가 끊기지 않도록 Seamless Handoff 방식을 사용합니다.

기존 모델이 대화를 계속 처리하는 동안 새로운 모델 인스턴스를 미리 준비합니다. 현재 대화 컨텍스트를 새로운 인스턴스에 미리 채우고, 두 모델에서 동시에 추론을 수행한 뒤 새로운 인스턴스가 준비되면 전환합니다.

사용자 입장에서는 모델 인스턴스가 바뀌었다는 사실을 느끼지 못합니다.

컨텍스트가 길어져도 대화를 멈추지 않는 방법

장시간 대화에서는 컨텍스트가 모델의 한계를 넘어설 수도 있습니다. 이때는 기존 컨텍스트를 압축하는 과정이 필요합니다.

하지만 컨텍스트 압축은 시간이 걸립니다. 더 큰 문제는 과거 컨텍스트가 변경되면서 기존 KV Cache 역시 사용할 수 없게 된다는 점입니다.

KV Cache는 이전에 처리한 토큰의 어텐션 키와 값을 저장해 추론을 빠르게 하는 역할을 합니다. 컨텍스트가 변경되면 이 상태를 다시 만들어야 하고, 그 과정에서 추가적인 prefill 작업이 필요합니다.

GPT-Live는 이 역시 대화 중단 없이 처리합니다.

기존 모델 인스턴스가 계속 대화하는 동안 백그라운드에서 컨텍스트를 압축하고 새로운 모델 인스턴스를 준비합니다. 새로운 인스턴스가 준비되면 그때 전환합니다.

즉, 무거운 작업을 실시간 음성 경로에서 분리하는 것입니다.

이를 통해 장시간 통화에서도 컨텍스트 관리 때문에 사용자의 대화가 끊기는 상황을 줄일 수 있습니다.

빠른 대화와 깊은 추론을 분리하다

GPT-Live가 모든 작업을 직접 처리해야 하는 것은 아닙니다.

음성 대화에서는 빠른 반응이 중요하지만 검색이나 복잡한 추론, 도구 사용이 필요한 순간에는 더 많은 계산이 필요할 수 있습니다.

이때 GPT-Live는 음성 대화를 계속 담당하면서 필요한 작업을 프런티어 모델에 비동기적으로 위임합니다. 제공된 자료에서는 GPT-5.5가 이러한 검색과 추론을 담당하는 사례가 소개됩니다.

이 구조의 핵심은 ‘말하기’와 ‘깊게 생각하기’를 분리하는 것입니다.

사용자와의 대화를 담당하는 음성 모델은 빠르게 반응하고, 더 많은 작업이 필요한 경우에는 별도의 모델이 뒤에서 처리합니다.

하지만 여기에도 중요한 조건이 있습니다.

위임된 작업이 너무 늦게 끝나면 결국 사용자가 지연을 느끼게 됩니다.

따라서 라우팅, 프롬프트 처리, 추론, 도구 호출을 포함한 전체 위임 경로를 하나의 반응성 예산으로 보고 최적화해야 합니다.

위임 요청 전에 미리 준비한다

GPT-Live는 사용자가 실제로 위임을 요청하기 전에 프런티어 모델과 필요한 도구를 준비합니다.

음성 세션이 시작되면 애플리케이션 서버가 프런티어 모델을 위한 추론 세션을 생성하고 초기 대화 컨텍스트를 미리 처리합니다.

이렇게 하면 실제 위임 요청이 발생했을 때 처음부터 모든 작업을 시작할 필요가 없습니다.

또한 음성 대화가 이어지는 동안 해당 추론 세션을 유지하고, 연속적인 요청에는 안정적인 세션 연결을 사용합니다.

여기에 프롬프트 캐싱 등을 함께 적용해 위임 과정에서 발생하는 지연을 줄입니다.

추론에 필요한 작업량, 출력 제한, 도구 스키마, 모델과 도구 사이의 반복적인 요청 횟수 역시 응답 속도에 영향을 미치기 때문에 이런 요소들도 조정합니다.

결과적으로 음성 모델은 프런티어 모델의 결과를 빠르게 대화에 반영할 수 있습니다.

연속적인 음성을 다시 대화 메시지로 만드는 과정

GPT-Live의 음성 모델은 지속적인 음성 스트림을 처리합니다.

하지만 ChatGPT의 화면이나 분석 시스템, 안전 관련 인프라 등 주변 시스템은 여전히 사용자 메시지와 어시스턴트 메시지처럼 구분된 대화 단위를 필요로 합니다.

여기서 문제가 생깁니다.

사람의 실제 대화는 그렇게 명확하게 나뉘지 않기 때문입니다.

사용자가 말을 하는 도중 어시스턴트가 짧게 “음”, “알겠습니다”와 같은 반응을 할 수도 있습니다. 이런 짧은 반응을 별도의 메시지로 기록하는 것이 항상 적절한 것은 아닙니다.

반대로 의미 있는 어시스턴트의 개입은 별도의 메시지로 처리해야 할 수도 있습니다.

GPT-Live의 애플리케이션 서버는 음성이 들어오는 동안 부분적인 전사 결과와 타이밍 정보를 활용해 누가 발언권을 가지고 있는지 판단하고 메시지 큐를 구성합니다.

다만 가장 최신 메시지는 처음부터 확정하지 않습니다.

추가 음성이 들어오면 텍스트나 발화 시점, 발화자 정보가 바뀔 수 있기 때문입니다.

그래서 시스템은 두 가지 관점을 유지합니다.

하나는 현재 상태를 빠르게 보여주기 위한 추측적 관점이고, 다른 하나는 최종적으로 확정된 발화를 기록하는 권위 있는 기록입니다.

화면에서는 변화가 가능한 추측적 상태를 활용할 수 있지만, 분석 시스템에서는 최종적으로 확정된 전사가 필요합니다.

이렇게 하면 음성 대화 자체에는 턴 기반 제약을 적용하지 않으면서도 다른 시스템에는 안정적인 대화 기록을 제공할 수 있습니다.

대화 시작부터 줄여야 하는 지연시간

실시간성은 사용자가 말을 시작한 뒤에만 중요한 것이 아닙니다.

사용자가 음성 기능을 누르는 순간부터 실제 대화가 시작될 때까지의 시간도 중요합니다.

GPT-Live에서는 미디어 경로를 만들고 모델에 음성을 전달하는 과정 자체가 대화 시작의 중요한 지연 요소가 됩니다.

WebRTC는 실시간 미디어를 위한 강력한 기반이지만 일반적인 WebRTC 세션을 시작하려면 여러 프로토콜의 핸드셰이크와 네트워크 왕복이 필요합니다.

GPT-Live 개발팀은 이 부분을 분석하고 WARP(WebRTC Abridged Roundtrip Protocol)를 개발했습니다.

WARP는 미디어와 데이터 연결을 시작하는 데 필요한 네트워크 왕복 횟수를 기존 6회에서 1회까지 줄이는 것을 목표로 설계됐습니다.

이를 위해 여러 프로토콜 수준의 개선을 적용했습니다.

• DTLS 핸드셰이크를 ICE 위에 함께 전달하는 방식
• 더 빠른 DTLS 1.3 핸드셰이크 활용
• SCTP 핸드셰이크 사전 협상
• DCEP를 통한 데이터 채널 협상 대신 데이터 채널 사전 협상

WARP는 특정 서비스에만 종속되는 방식이 아니라 오픈 사양으로 설계됐으며 WebRTC 생태계와 함께 발전시키는 방향으로 추진됐습니다. 자료에 따르면 libwebrtc와 Pion에도 WARP 지원이 추가됐습니다.

Instant Connect로 신호 교환까지 최적화

WebRTC의 핸드셰이크를 줄인 뒤에도 또 하나의 지연 요소가 남았습니다.

WebRTC 연결 전에 SDP 파라미터를 교환해야 하는 과정입니다.

이를 해결하기 위해 개발된 것이 Instant Connect입니다.

Instant Connect는 기존 WebRTC 구현을 변경하지 않고도 SDP 파라미터를 미리 협상할 수 있도록 합니다.

미리 협상한 파라미터가 유효하다면 첫 번째 미디어 패킷이 도착했을 때 서버가 세션을 바로 구성할 수 있습니다.

만약 미리 협상한 정보가 오래됐거나 유효하지 않더라도 기존 신호 교환 과정이 이미 진행되고 있기 때문에 별도의 추가 지연 없이 기존 방식으로 전환할 수 있습니다.

결과적으로 Instant Connect와 WARP를 함께 적용하면 사용자가 음성 기능을 사용하려는 순간부터 실제 미디어 흐름이 시작되기까지의 시간을 크게 줄일 수 있습니다.

자료에서는 SDP 교환을 핵심 경로에서 제외하고 WARP로 전송 계층의 핸드셰이크를 줄여 클라이언트가 하나의 UDP 패킷으로 세션 시작을 요청할 수 있는 구조를 설명합니다.

실제 사용자 환경에서 테스트해야 알 수 있는 문제

실시간 시스템은 테스트 환경에서 빠르게 동작한다고 해서 실제 서비스에서도 빠른 것은 아닙니다.

GPT-Live는 실제 사용자에게 제공하기 전에 기존 Advanced Voice Mode와 새로운 시스템에 동일한 ChatGPT Voice 세션을 동시에 전달하는 Silent Test를 진행했습니다.

기존 시스템은 사용자가 실제로 듣는 서비스를 계속 제공하고, GPT-Live는 뒤에서 읽기 전용 방식으로 추론을 수행했습니다.

이 방식은 사용자에게 영향을 주지 않으면서 실제 클라이언트, 네트워크 환경, 세션 길이, 지역별 트래픽을 경험할 수 있다는 장점이 있습니다.

그리고 실제 환경에서는 예상하지 못한 문제가 나타났습니다.

GPU만으로는 실시간 시스템의 용량을 판단할 수 없다

일반적인 AI 시스템에서는 GPU가 얼마나 많은 요청을 처리할 수 있는지가 중요한 용량 기준이 될 수 있습니다.

하지만 음성 AI에서는 이것만으로 부족합니다.

음성 세션은 오랫동안 연결된 상태로 계속 오디오 프레임을 전송합니다. 따라서 CPU 기반 스트림 처리기, 큐, 네트워크 경로 등도 함께 확장되어야 합니다.

실제 부하 테스트에서는 GPU 처리량보다 다른 지원 구성 요소가 먼저 포화되는 문제가 나타났고, 이로 인해 추론 요청이 쌓이면서 지연시간이 증가했습니다.

따라서 실시간 음성 시스템에서 중요한 질문은 단순히 다음과 같은 것이 아닙니다.

“GPU가 몇 개의 요청을 처리할 수 있는가?”

대신 다음과 같은 질문이 필요합니다.

“모든 오디오 프레임을 일정하게 처리하면서 시스템이 동시에 몇 개의 세션을 유지할 수 있는가?”

이 차이가 실시간 시스템과 일반적인 요청-응답 시스템의 중요한 차이점입니다.

지역과 장시간 세션도 성능에 영향을 미친다

사용자와 멀리 떨어진 곳에서 모델을 실행하면 세션 시작과 스트리밍 과정 여러 지점에서 지연이 추가될 수 있습니다.

따라서 GPT-Live의 운영 과정에서는 모델 배포와 지역별 용량, 트래픽 라우팅을 함께 검증했습니다.

또한 사용자의 지역에 따른 지연시간을 별도로 분석했습니다.

모델 추론을 사용자와 가까운 곳으로 이동하면 성능이 개선됐지만, 동시에 중요한 사실도 확인할 수 있었습니다.

실시간 반응성은 모델 서버 하나만의 문제가 아니라 전체 서비스 경로의 문제라는 것입니다.

장시간 세션에서도 여러 문제가 발견됐습니다.

긴 대화는 메모리와 데이터 저장에 대한 부담을 높였고, 재접속 과정에서는 컨텍스트 압축과 상태 복원이 테스트됐습니다. 일반적인 클라이언트 연결 종료에서는 종료 과정의 경쟁 상태도 발견됐습니다.

이런 문제들은 짧은 부하 테스트에서는 쉽게 나타나지 않습니다.

시간이 흐르면서 상태가 쌓이고 여러 서비스가 서로 연결되는 실제 세션 환경에서야 확인할 수 있는 문제이기 때문입니다.

실시간 음성 AI에서 중요한 것은 전체 경로다

GPT-Live의 시스템 설계를 하나로 묶는 핵심 원칙은 명확합니다.

음성이 흘러야 한다는 것입니다.

이를 위해 각각의 구성 요소가 서로 다른 역할을 맡습니다.

첫째, 스트리밍 추론은 음성 모델에 오디오를 계속 공급합니다.

둘째, 전용 미디어 경로는 오디오 프레임이 안정적으로 이동하도록 합니다.

셋째, 비동기 모델 위임은 검색이나 깊은 추론 같은 무거운 작업이 실시간 대화를 막지 않도록 합니다.

넷째, 상태 관리와 컨텍스트 전환은 장시간 대화에서도 모델 인스턴스 변경이나 컨텍스트 압축으로 인해 대화가 중단되지 않도록 합니다.

다섯째, WARP와 Instant Connect는 사용자가 음성 대화를 시작하는 순간부터 실제 미디어가 흐르기까지 발생하는 네트워크 지연을 줄입니다.

마지막으로 실제 운영 환경을 활용한 Silent Test를 통해 GPU뿐 아니라 CPU, 네트워크, 지역, 세션 수명, 장애 복구 등 전체 시스템을 검증합니다.

728x90

자연스러운 음성 AI는 모델만으로 만들어지지 않는다

GPT-Live 사례에서 가장 눈여겨볼 부분은 단순히 음성 모델의 성능을 높였다는 점이 아닙니다.

사람처럼 자연스럽게 대화하는 음성 AI를 만들기 위해서는 모델이 빠르게 답변하는 것 이상의 시스템 설계가 필요합니다.

기존 방식에서는 사용자가 말을 끝내기를 기다리고, 그다음 모델이 응답하는 구조가 중심이었다면 GPT-Live는 음성이 계속 흐르는 구조를 중심에 둡니다.

음성 모델은 듣고 말하는 작업을 지속적으로 수행합니다. 검색이나 깊은 추론은 별도의 프런티어 모델에 비동기적으로 위임합니다. 컨텍스트가 길어지면 새로운 모델 인스턴스를 준비해 대화를 중단하지 않고 전환합니다. 네트워크 연결 과정에서도 불필요한 왕복을 줄여 사용자의 의도부터 실제 음성 흐름까지 걸리는 시간을 단축합니다.

결국 실시간 음성 AI의 반응성은 특정 모델 하나의 속도로 결정되지 않습니다.

클라이언트에서 네트워크를 거쳐 미디어 처리, 모델 추론, 상태 관리, 다른 모델과의 위임까지 이어지는 전체 경로가 얼마나 빠르고 안정적으로 연결되는지가 핵심입니다.

이러한 구조는 ChatGPT Voice의 대화 기능을 넘어 에이전트 간 협업이나 컴퓨터 제어와 같은 실시간 상호작용으로 확장될 수 있는 기반이 됩니다.

GPT-Live의 사례가 보여주는 방향도 여기에 있습니다.

앞으로 음성 AI가 더 많은 기기와 애플리케이션, 다양한 모달리티로 확장되더라도 사용자가 사람과 대화하는 것처럼 자연스럽다고 느끼려면, 결국 기술의 중심에는 끊기지 않고 즉각적으로 이어지는 실시간 상호작용이 있어야 합니다.

300x250

https://openai.com/index/continuous-voice-interaction-with-gpt-live/

How we built a realtime system for responsive voice AI in six months