Voice AI WebRTC 세션 계약: Realtime API를 운영 가능한 고객 접점으로 만드는 법
OpenAI Realtime API와 Google Gemini Live API가 보여주는 다음 경쟁력은 모델 호출이 아니라 WebRTC·WebSocket·SIP를 묶는 세션 계약입니다.
OpenAI Realtime API와 Google Gemini Live API 문서를 나란히 보면 신호가 분명합니다. Voice AI의 경쟁력은 더 이상 “어떤 모델을 호출했는가”만으로 결정되지 않고, 실시간 세션을 어떻게 열고·통제하고·증명하는가로 이동하고 있습니다.
WebRTC는 데모 기능이 아니라 운영 경계입니다
MDN은 WebRTC를 브라우저와 애플리케이션이 오디오·비디오를 캡처하고 스트리밍하며 데이터를 교환할 수 있게 하는 기술로 설명합니다. OpenAI Realtime 문서는 브라우저 연결에 WebRTC를 사용하고, 세션 초기화에 ephemeral API key 또는 unified interface를 선택하도록 안내합니다. Google Gemini Live API도 실시간 오디오·비디오 앱에서 WebRTC 또는 WebSocket 기반 파트너 통합을 언급합니다.
핵심 변화는 “모델이 말을 잘한다”가 아니라 “실시간 세션이 안전하게 시작되고, 중간에 무너지지 않으며, 종료 후 설명 가능하다”입니다.
이 관점에서 Voice AI 프로젝트는 음성 모델 PoC가 아니라 session product가 됩니다. 즉, 브라우저·전화망·SIP·WebSocket·도구 호출·감사 로그가 하나의 계약으로 묶여야 합니다.
세션 계약에 들어가야 할 5개 필드
엔터프라이즈 Voice AI에서 session contract는 SDK 옵션 묶음이 아닙니다. 배포 전 승인·보안·운영팀이 함께 읽을 수 있는 실행 단위입니다.
Voice AI session contract
1. Identity: caller/user/session id, consent state, tenant boundary
2. Media path: WebRTC, WebSocket, SIP, phone bridge, fallback route
3. State events: started, listening, interrupted, tool_waiting, escalated, ended
4. Tool lane: CRM lookup, booking, payment, ticket creation, policy guard
5. Evidence lane: transcript policy, event log, redaction, retention, audit export
이 5개가 분리되어 있으면 데모는 빨라도 운영은 흔들립니다. 예를 들어 WebRTC 연결은 성공했지만 상담 전환 시 CRM 상태가 전달되지 않거나, 도구 호출 실패가 고객에게 침묵으로 보이면 실제 고객 경험은 실패입니다.
Realtime API 선택은 네트워크 선택입니다
OpenAI 문서는 Realtime 연결 방식으로 WebRTC, WebSocket, SIP를 구분합니다. Google Live API는 raw WebSocket, session management, ephemeral tokens를 별도 항목으로 둡니다. 이 구분은 단순한 개발자 편의가 아니라 운영 설계의 시작점입니다.
- 브라우저 상담·웹 데모는 WebRTC가 자연스럽습니다. 사용자 기기에서 마이크 권한과 미디어 트랙을 직접 다루기 때문입니다.
- 서버 중계·관제형 콜센터는 WebSocket 또는 SIP 브리지가 필요합니다. 통화 녹취, 콜 라우팅, 방화벽 정책이 서버 쪽에 있기 때문입니다.
- 전화망 기반 고객 접점은 전화번호, SIP trunk, 통화 큐, 상담원 전환까지 포함해야 합니다.
따라서 “Realtime API를 붙였다”는 표현은 충분하지 않습니다. 어떤 media path가 어느 고객 접점에 쓰이고, 장애 시 어떤 경로로 빠지는지까지 문서화되어야 합니다.
ephemeral token은 보안 기능이 아니라 책임 분리입니다
Realtime 세션에서 ephemeral token을 쓰는 이유는 브라우저에 장기 권한을 노출하지 않기 위해서입니다. 하지만 엔터프라이즈에서는 여기서 한 단계 더 가야 합니다.
- 누가 token을 발급했는가
- 어떤 고객·조직·상담 목적에 한정되는가
- 몇 분 뒤 만료되는가
- 세션 종료 후 어떤 로그가 남는가
- 도구 호출 권한은 token과 분리되어 있는가
이 질문이 빠지면 Voice AI는 “통화 가능한 모델”에 머뭅니다. 반대로 이 질문이 답변되면 보안팀은 배포 경계를 이해하고, 운영팀은 장애 재현 경로를 확보합니다.
BringTalk 관점: Agent Gateway는 session contract의 집행자입니다
BringTalk이 보는 Agent Gateway의 역할은 모델 앞단 프록시가 아닙니다. 세션 계약을 실행하는 control plane입니다. WebRTC·WebSocket·SIP 중 어떤 경로로 들어오든, 고객 상태와 도구 권한, interruption 이벤트, fallback 정책, 감사 증적을 같은 언어로 정리해야 합니다.
운영팀이 바로 확인할 체크리스트
- 세션 시작 전 consent와 tenant boundary가 확정되는가
- barge-in, silence, tool timeout이 각각 별도 이벤트로 남는가
- 상담원 전환 시 고객 의도와 마지막 상태가 전달되는가
- transcript와 event log의 보존 정책이 분리되어 있는가
- 모델 교체 후에도 session contract가 유지되는가
이 체크리스트가 있으면 모델·STT·TTS를 교체해도 운영 기준은 유지됩니다. 반대로 계약이 없으면 모델을 바꿀 때마다 품질·보안·관측성을 다시 협상해야 합니다.
결론: 모델 호출보다 세션 계약이 먼저입니다
2026년 Voice AI 팀이 봐야 할 지표는 모델 이름만이 아닙니다. WebRTC 연결 방식, ephemeral token, session state, tool lane, evidence lane이 한 문서 안에 들어있는지가 더 중요한 배포 기준이 됩니다.
Realtime Voice AI의 다음 경쟁력은 “빠른 응답”을 넘어 “통제 가능한 세션”입니다. 세션 계약이 있어야 속도, 보안, 고객 경험이 같은 방향으로 움직입니다.
Sources: OpenAI Realtime API with WebRTC documentation; Google Gemini Live API documentation; MDN WebRTC API overview; Vapi documentation index for WebSocket transport, SIP integration, real-time call control, and call queue concepts.
