AIREITER사용자가 말을 멈출 때까지 기다렸다가 생각하는 음성 에이전트는 빠를 수는 있어도 어딘가 기계적으로 느껴집니다. GPT-Live는 이 문제를 아키텍처 차원에서 풀어냅니다. 음성 에이전트가 계속 듣고 말하는 동안 검색, 도구 호출, 심층 추론은 오디오 루프 바깥에서 나란히 실행됩니다. 대화는 한층 자연스러워지지만, 그만큼 운영 난도도 크게 올라갑니다.
1분 만에 이해하는 GPT-Live 풀 듀플렉스 API 아키텍처
GPT-Live는 단순히 더 빠른 음성-대-음성 엔드포인트가 아닙니다. OpenAI는 이를 입력 오디오를 처리하면서 동시에 출력 오디오를 생성하고, 초당 여러 차례 상호작용을 판단하며, 더 깊은 작업은 프런티어 모델에 위임하는 풀 듀플렉스 음성 시스템으로 설명합니다. OpenAI의 엔지니어링 글에 따르면 이 시스템은 스트리밍 추론, 상태를 유지하는 대화, WebRTC 전송, 미디어 경로 밖에서 실행되는 비동기 작업을 중심으로 설계됐습니다.
실제 구조는 다음과 같습니다.
| 계층 | 책임 | 설계상 의미 |
|---|---|---|
| 미디어 경로 | 클라이언트와 음성 모델 사이에서 오디오 프레임을 전달 | 짧고 예측 가능하게 유지하며 비즈니스 API와 분리 |
| 풀 듀플렉스 음성 모델 | 듣기, 말하기, 멈춤, 끼어들기, 대화 타이밍 관리 | 침묵 기반 턴 감지를 핵심 제어 장치로 삼지 않음 |
| 위임 계층 | 검색, 추론, 도구 호출을 비동기로 실행 | 위임된 작업을 지연 시간에 민감한 백그라운드 작업으로 취급 |
| 애플리케이션 계층 | 도구, 권한, 확인 절차, 비즈니스 규칙 검증 | 유창한 음성이 중요한 작업을 승인하도록 두지 않음 |
| 제품 기록 | 트랜스크립트, 분석 데이터, UI 메시지 관리 | 임시 대화 화면과 최종 확정 기록을 분리 |
가장 큰 변화는 시간의 주도권입니다. 기존 음성 에이전트는 사용자의 발화가 끝나기를 기다린 뒤 모델에 보내고, 응답을 재생합니다. GPT-Live 구조에서는 음성 세션이 계속 유지되는 동안 여러 종류의 작업이 동시에 진행됩니다.
순차적인 턴 처리 방식은 뒤로 물려야 한다
전형적인 캐스케이드 음성 시스템은 음성-텍스트 변환, 언어 모델, 텍스트-음성 변환을 차례로 실행합니다. 네이티브 음성-대-음성 모델은 일부 단계를 줄여주지만, 별도의 음성 활동 감지기(VAD)가 추론에 들어가기 전에 사용자의 발화가 끝났는지를 판단하는 구조는 여전히 남을 수 있습니다. 짧은 생각의 공백을 발화 종료로 오인하거나, 주변 소리를 새로운 발화로 판단할 가능성도 있습니다.
GPT-Live의 풀 듀플렉스 방식은 이 타이밍 문제를 음성 모델 안으로 가져옵니다. 모델은 말하는 중에도 계속 들을 수 있고, 끼어들기를 감지해 잠시 멈추거나 말을 이어가며 짧은 맞장구를 보낼 수도 있습니다. 그렇다고 모든 곳에서 턴 경계가 사라지는 것은 아닙니다. 다만 턴 경계가 실시간 오디오 루프를 막도록 내버려두지 않는다는 뜻입니다.
GPT-Live가 실시간 경로를 바꾸는 방식
턴 게이팅 대신 연속 추론을 사용한다
풀 듀플렉스 세션에서는 입력과 출력이 번갈아 오가는 오디오 덩어리가 아니라 스트림으로 처리됩니다. 모델은 이전 응답을 재생하는 동안에도 새로운 음성을 받을 수 있습니다. 들어온 오디오가 실제 끼어들기인지, 짧은 맞장구인지, 단순한 주변 소음인지도 판단할 수 있습니다.
클라이언트 로직도 달라져야 합니다. 클라이언트는 오디오 이벤트를 동시에 보내고, 받고, 취소하고, 교체할 수 있어야 합니다. 단일 await response() 추상화는 이런 동작과 잘 맞지 않습니다. 음성 시작, 어시스턴트 오디오 시작, 끼어들기 감지, 도구 요청, 응답 취소, 세션 종료처럼 실제로 중요한 이벤트를 숨겨버리기 때문입니다.
그래도 UI, 분석, 안전 기능을 위해 음성 활동 신호는 유지해야 합니다. 문제는 VAD를 모델 추론 시작 시점을 결정하는 유일한 권한으로 사용하는 것입니다.
미디어는 빠르게, 나머지 작업은 경로 밖에서
OpenAI의 엔지니어링 설명은 전용 오디오 경로와 애플리케이션 로직을 분리합니다. 오디오는 클라이언트와 음성 모델 사이를 직접 오가고, 도구 호출, 정책 검사, 데이터 저장, 백엔드 작업은 비동기 경계를 통과합니다.
이 경계에는 분명한 원칙이 있습니다. CRM 조회가 느려지더라도 그 작업의 응답만 늦어질 뿐, 오디오 프레임이 제때 도착하는 데 영향을 줘서는 안 됩니다. WebRTC는 지연 시간이 짧은 미디어 전송을 담당하고, 애플리케이션 서비스가 모든 마이크 프레임과 모델 사이에 동기식으로 끼어들어서는 안 됩니다.
위임된 작업이 진행되는 동안 음성 계층은 짧게 상황을 알릴 수 있습니다. 하지만 필러 음성이 실행 시간 제한이 있는 작업을 대신할 수는 없습니다. 모든 도구에 데드라인, 취소 규칙, 안전한 결과 상태를 지정해야 합니다.
위임으로 반응성과 지능을 분리한다
GPT-Live는 검색, 심층 추론, 복잡한 작업을 프런티어 모델에 위임할 수 있습니다. OpenAI의 출시 글과 엔지니어링 글은 출시 시점 위임 모델로 GPT-5.5를 언급합니다. 음성 모델은 즉각적인 상호작용을 맡고, 프런티어 모델은 짧은 지연 시간의 대화 루프 안에서 처리하기 어려운 작업을 담당합니다.
프로덕션에서는 위임을 별도의 파이프라인으로 다루는 편이 좋습니다.
- 요청에 검색, 추론 또는 도구가 필요한지 감지합니다.
- 미디어 경로를 막지 않은 채 짧게 응답하거나 잠시 멈춥니다.
- 관련 대화 맥락과 함께 백그라운드 작업을 시작합니다.
- 사용자가 방향을 바꾸거나 세션을 종료하면 작업을 취소합니다.
- 애플리케이션에서 결과를 검증합니다.
- 간결한 결과를 실시간 세션에 다시 주입합니다.
위임 추론 세션을 미리 초기화하고, 세션 친화성을 유지하며, 반복되는 맥락을 캐시하면 유용한 출력이 나오기까지의 시간을 줄일 수 있습니다. 전체 지연 시간에는 모델 토큰 처리 시간만이 아니라 라우팅, 프롬프트 처리, 모델 추론, 도구 호출, 모델과 도구 사이의 모든 왕복 시간이 포함됩니다.
상태 유지 세션에는 별도의 아키텍처가 필요하다
긴 음성 통화는 일회성 요청을 이어 붙인 것이 아닙니다. 맥락은 계속 늘어나고, 모델 워커가 교체될 수 있으며, 세션을 압축해야 할 때도 있습니다. OpenAI는 교체할 모델 인스턴스를 미리 준비하고 현재 맥락을 채운 뒤, 준비가 끝났을 때 전환하는 방식을 설명합니다. 이렇게 하면 인프라 전환이 통화 중인 사용자에게 들리지 않습니다.
맥락 압축도 비슷한 문제를 만듭니다. 이전 턴을 요약하면 모델의 키-값 캐시를 뒷받침하는 맥락이 바뀝니다. 이 캐시를 포그라운드에서 다시 만들면 대화가 멈출 수 있습니다. 더 안전한 방식은 맥락 압축을 병렬로 진행하고, 교체 인스턴스를 준비한 뒤, 전환할 준비가 끝날 때까지 기존 인스턴스가 계속 응답하도록 하는 것입니다.
따라서 음성 에이전트 백엔드의 세션 상태에는 트랜스크립트 외에도 다음 정보가 필요합니다.
- 현재 오디오 및 응답 상태
- 진행 중인 도구 호출과 취소 토큰
- 모델 인스턴스 또는 워커 친화성
- 임시 메시지와 최종 확정 메시지
- 맥락 압축 상태
- 재연결 및 복구 상태
- 안전 및 확인 상태
API 계약은 요청-응답이 아니라 이벤트 시스템이다
풀 듀플렉스는 외부 API가 익숙한 SDK 메서드를 제공하더라도 내부 프로토콜을 바꿉니다. 애플리케이션은 흔히 하나로 묶어 처리하는 다음 이벤트를 명확히 구분해야 합니다.
| 이벤트 | 의미 | 올바른 대응 |
|---|---|---|
| 취소 | 대기 중인 작업을 중단 | 작업을 취소하고 리소스를 해제 |
| 끼어들기 | 사용자가 현재 출력 위에 말을 시작 | 세션을 종료하지 않고 어시스턴트 오디오를 멈추거나 수정 |
| 세션 종료 | 통화 또는 대화가 끝남 | 미디어, 도구, 저장, 과금 상태를 모두 종료 |
| 도구 실패 | 위임된 작업이 완료되지 않음 | 안전하게 설명하고 대안을 제시 |
| 재연결 | 미디어 경로가 끊김 | 작업을 중복 실행하지 않도록 상태를 복구 |
GPT-Live는 계속 작동할 수 있지만, 제품의 UI·분석·안전 시스템에는 여전히 메시지가 필요합니다. OpenAI는 트랜스크립트가 들어오는 동안 수정할 수 있는 추정 뷰와, 나중에 확정하는 권위 있는 기록을 별도로 유지하는 방식을 설명합니다. 유용한 패턴입니다. 반응성 높은 자막을 보여주되, 모든 부분 트랜스크립트를 변경할 수 없는 사실로 취급하지 않는 것입니다.
음성 에이전트 팀이 다시 설계해야 할 것
미디어 어댑터와 에이전트 오케스트레이션을 분리한다
공급자별 전송 방식과 이벤트 처리는 어댑터 뒤에 숨기세요. 애플리케이션은 user_audio_started, assistant_interrupted, tool_requested, confirmation_required, response_completed처럼 표준화된 이벤트를 소비하도록 설계하는 편이 좋습니다.
모델 ID, 음성, 프롬프트, 도구 스키마, 비용 제한은 설정으로 분리하세요. 이는 단순한 마이그레이션 대비책이 아닙니다. 지금은 문서화된 Realtime 모델을 테스트하면서도, 향후 GPT-Live 의미 체계로 전환할 명확한 목표를 유지할 수 있습니다.
도구에 대해서는 모델이 제안하고 애플리케이션이 검증해야 합니다. 결제, 계정 변경, 취소, 주소 수정, 의료 분류, 금융 작업, 신원 확인 절차에는 모델이 말하는 자신감과 무관하게 별도의 확인 규칙이 필요합니다.
오디오를 어디서 제어하는지에 따라 전송 방식을 고른다
브라우저와 모바일 클라이언트에서 오디오를 직접 캡처하고 재생한다면 WebRTC가 자연스러운 선택입니다. 서버가 미디어 파이프라인을 제어하는 경우에는 WebSocket도 유용할 수 있습니다. 다만 모든 실시간 모델이 모든 전송 방식에서 동일한 세션 구조를 지원한다고 가정해서는 안 됩니다.
OpenClaw 통합 이슈는 실제로 발생할 수 있는 실패 사례를 보여줍니다. gpt-live-1을 일반적인 GA Realtime WebSocket 세션처럼 처리하자 invalid_model 응답이 발생했고, 제안된 GPT-Live 브라우저 흐름은 별도의 WebRTC 세션 구조를 사용했습니다. 이 이슈는 OpenAI API 계약이 아니라 구현 사례에 대한 보고입니다. 그럼에도 모델 계열을 감지하고 지원되는 세션 유형을 명시적으로 협상해야 한다는 설계 원칙을 뒷받침합니다.
토큰 지연 시간이 아니라 제때 도착한 프레임을 측정한다
OpenAI의 엔지니어링 글에 따르면 프로덕션 테스트에서 GPU 용량보다 이를 지원하는 스트림 컴포넌트가 먼저 포화됐습니다. 유용한 용량 단위는 GPU당 요청 수가 아니라, 오디오 프레임을 제때 전달하면서 동시에 유지할 수 있는 세션 수였습니다.
최소한 다음 지표는 추적해야 합니다.
- 오디오 프레임 지연 및 손실
- 재생 가능한 첫 오디오까지 걸린 시간
- 끼어든 뒤 출력이 멈추기까지 걸린 시간
- 지역별 동시 세션 수
- 재연결 및 중복 도구 호출
- 위임 작업 완료 시간
- 도구 시간 초과 및 취소율
- 임시 트랜스크립트가 최종본으로 바뀌는 과정에서 발생한 수정
- 중단된 세션과 세션당 비용
자연스러움에도 제어 문제가 있습니다. 어떤 상황에서는 사용자가 끼어들기와 맞장구를 반길 수 있지만, 다른 상황에서는 불쾌하게 느낄 수 있습니다. 한 초기 사용자 보고는 이 위험을 직설적으로 요약했습니다. “진짜 계속 말을 끊네 ㅋㅋ” (@AutismCapital). 이 사례는 대본으로 만든 데모가 아니라 실제 대화를 기준으로 끼어들기 정책을 조정해야 한다는 점을 보여줍니다.
GPT-Live와 현재 Realtime 중 무엇을 선택할 것인가
현재 OpenAI 공식 모델 카탈로그는 GPT-Live 1을 자연스럽고 표현력이 풍부한 음성 대화용 모델로 소개하며, 매끄러운 끼어들기 처리를 주요 특징으로 강조합니다. 하지만 해당 카탈로그가 완전한 통합 계약을 의미하는 것은 아닙니다. 여기서 검토한 별도의 GPT-Live API 페이지는 여전히 엔드포인트, 속도 제한, 사용량 제한에 대한 세부 정보 없이 알림 신청 양식만 제공합니다. 출시 계획을 확정하기 전에 최신 개발자 문서와 계정 사용 권한을 확인해야 합니다.
| 필요 사항 | 실용적인 선택 |
|---|---|
| 지금 문서화된 음성 에이전트를 출시해야 함 | 문서화된 Realtime 스택을 어댑터 뒤에 두고 사용 |
| 자연스러운 겹침과 모델 주도 턴 전환이 핵심 요구 사항임 | GPT-Live의 풀 듀플렉스 이벤트 모델을 기준으로 설계하고 먼저 사용 권한을 확인 |
| 브라우저 또는 모바일 오디오 | 공급자가 지원하는 WebRTC 경로를 우선 사용 |
| 복잡한 비즈니스 작업 | 비동기 도구와 애플리케이션 측 확인 절차를 유지 |
| 긴 통화 | 출시 전에 핸드오프, 맥락 압축, 재연결, 영속 상태 처리를 구축 |
모든 계정에서 해당 모델을 사용할 수 있게 되기 전이라도 이 아키텍처는 도입할 가치가 있습니다. 지속적인 미디어 처리, 표준화된 이벤트, 비동기 도구, 명시적인 취소 처리는 기존 실시간 모델로 만든 음성 에이전트에도 도움이 됩니다.
GPT-Live 풀 듀플렉스 API FAQ
GPT-Live는 GPT-Realtime과 같은 모델인가요?
아닙니다. OpenAI는 GPT-Live를 별도의 음성 대화 모델 계열로 소개하고 있으며, GPT-Realtime은 문서화된 실시간 API 계열입니다. 오디오 기능이 비슷하더라도 세션 의미 체계, 전송 방식, 모델 ID가 동일하다고 볼 수는 없습니다.
풀 듀플렉스라면 모델이 절대 기다리지 않나요?
아닙니다. 풀 듀플렉스는 시스템이 듣기와 말하기를 동시에 처리할 수 있다는 뜻입니다. 모델은 여전히 잠시 멈추거나 조용히 있거나, 추가 설명을 기다리거나, 더 안전하고 유용한 결과를 위해 위임 작업의 응답을 늦출 수 있습니다.
개발자에게 여전히 VAD가 필요한가요?
미디어 UX, 분석, 자막, 안전 신호를 위해 필요합니다. 다만 VAD가 모델을 사용자의 턴과 어시스턴트의 턴이 엄격히 순서대로 이어지는 구조에 가두는 유일한 관문이 되어서는 안 됩니다.
음성 에이전트에는 어떤 전송 방식을 사용해야 하나요?
사용하는 클라이언트와 모델이 지원하는 전송 방식을 선택해야 합니다. 일반적으로 브라우저나 모바일에서 오디오를 직접 처리한다면 WebRTC가 적합하고, 백엔드 미디어 파이프라인에서는 문서에 명시된 경우 WebSocket을 사용할 수 있습니다. 모델 이름만 보고 전송 방식 지원 여부를 추론해서는 안 됩니다.
사용 권한이 확정되기 전에 무엇을 준비해야 하나요?
어댑터, 표준화된 이벤트 스키마, 도구 검증 계층, 취소 모델, 비용 측정, 폴백, 장시간 세션 복구 기능을 먼저 구축하세요. 최종 GPT-Live API 계약이 바뀌더라도 이 구성 요소들은 그대로 활용할 수 있습니다.
모델 이름이 아니라 아키텍처를 선택하라
지속적으로 가져갈 수 있는 결정은 음성을 텍스트 모델 위에 얹은 요청-응답 래퍼로 취급하지 않는 것입니다. 오디오 경로는 계속 열어두고, 느린 작업은 비동기 경계 뒤로 보내며, 끼어들기와 취소를 핵심 이벤트로 다뤄야 합니다. 최종 확정 전까지 수정할 수 있는 트랜스크립트도 별도로 유지해야 합니다.
GPT-Live의 트레이드오프는 분명합니다. 더 자연스러운 대화 겹침과 작업 위임을 얻는 대신 더 많은 상태 관리와 관측 가능성이 필요하고, 단순한 턴 경계만으로 시스템을 제어하기는 어려워집니다. 이 복잡성을 감수할 수 있는 팀이라면 지금부터 풀 듀플렉스 계약을 기준으로 설계하면 됩니다. 문서화된 프로덕션 엔드포인트가 필요한 팀이라면 Realtime으로 출시하되, 동일한 이벤트 기반 분리 구조를 적용하는 것이 현실적인 선택입니다.