OpenAI가 선택한 저지연 음성 AI 아키텍처: WebRTC 릴레이+트랜시버 구조 분석 (openai.com)

한줄 요약

OpenAI가 대규모 실시간 음성 AI 서비스를 위해 WebRTC 릴레이+트랜시버 분리 아키텍처를 설계·적용한 방식을 공개했다.

무엇이 달라지나?

실시간 음성 AI는 응답 속도가 곧 사용자 경험이다. 말이 끊기거나 반응이 0.5초만 늦어도 대화가 어색해진다. OpenAI는 ChatGPT 음성 기능과 Realtime API를 주간 활성 사용자 9억 명 이상 규모로 운영하면서, 기존 WebRTC 구조가 Kubernetes 기반 인프라와 충돌하는 세 가지 병목을 발견했다.

첫째는 포트 고갈 문제다. 전통적인 WebRTC 방식은 세션 하나당 UDP 포트 하나를 점유한다. 수만 개의 동시 세션이 생기면 클라우드 로드 밸런서와 방화벽 정책이 감당하기 어려운 규모의 포트 범위가 필요해진다. 둘째는 세션 상태의 고착성이다. ICE와 DTLS는 상태 기반 프로토콜이기 때문에, 세션을 처음 생성한 프로세스가 해당 세션의 패킷을 계속 수신해야 한다. Kubernetes 환경에서는 파드가 언제든 재스케줄링될 수 있어 이 조건을 유지하기 어렵다. 셋째는 글로벌 라우팅의 첫 번째 홉 레이턴시다.

이 세 문제를 해결하기 위해 OpenAI가 설계한 것이 릴레이 + 트랜시버 분리 구조다. 개념 자체는 단순하다. 외부에 노출되는 경량 UDP 포워딩 레이어(릴레이)와, 실제 WebRTC 세션 상태를 소유하는 내부 서비스(트랜시버)를 분리한다. 릴레이는 미디어를 복호화하거나 ICE 상태 머신을 실행하지 않는다. 패킷 메타데이터만 읽어 어느 트랜시버로 보낼지 결정하고 포워딩한다.

라우팅의 핵심은 ICE 사용자명 프래그먼트, 즉 ufrag다. WebRTC 세션 협상 단계에서 교환되는 이 짧은 식별자에 라우팅 힌트를 인코딩해 넣는다. 릴레이는 최초 STUN 패킷에서 ufrag를 읽어 별도의 외부 조회 없이 즉시 올바른 트랜시버로 패킷을 전달할 수 있다. 클라이언트 입장에서는 표준 WebRTC 동작이 그대로 유지된다. 내부 라우팅 구조가 바뀌었을 뿐 프로토콜 수준에서는 변화가 없다.

구현 언어로는 Go를 선택했고, WebRTC 오픈소스 라이브러리인 Pion을 기반으로 트랜시버 서비스를 구축했다. SDP 협상과 세션 설정은 트랜시버가 직접 처리하고, 미디어는 릴레이 VIP(가상 IP)를 통해 진입한다. 트랜시버는 세션 수에 상관없이 공유 UDP 소켓 하나로 내부 수신을 처리한다.

실무에서 어떤 의미인가?

이 아키텍처가 흥미로운 이유는 WebRTC를 버린 게 아니라, WebRTC를 클라우드 네이티브 인프라에 맞게 재해석했기 때문이다. SFU(선택적 전달 유닛) 방식은 멀티파티 화상 회의처럼 여러 참여자가 있는 구조에 적합하다. 반면 AI 음성 서비스는 대부분 1:1 구조이고, 레이턴시 민감도가 극단적으로 높다. OpenAI는 이 트래픽 형태에 맞는 별도 아키텍처를 선택했고, 그 선택이 Kubernetes 오토스케일링과 글로벌 라우팅 모두에서 유리하게 작용했다.

개발자 관점에서 주목할 포인트는 ufrag 기반 라우팅이다. 프로토콜 레벨의 기존 필드를 재활용해 별도의 외부 상태 저장소 없이 첫 패킷부터 정확한 라우팅을 구현한 방식은, 분산 시스템 설계에서 자주 참고할 만한 패턴이다. 외부 API 조회 없이 패킷 자체에 라우팅 컨텍스트를 실어 보내는 접근은 레이턴시와 의존성 양쪽을 동시에 줄인다.

또한 이 구조는 Realtime API를 통해 외부 개발자도 동일한 인프라 위에서 음성 AI 서비스를 구축한다는 점을 시사한다. 인프라 내부 구현이 공개된 만큼, API 사용자는 레이턴시 특성과 장애 모드를 보다 현실적으로 예측할 수 있게 됐다.

도입 전 체크포인트

WebRTC 기반 실시간 AI 서비스를 직접 구축하거나 OpenAI Realtime API를 도입할 때 확인해야 할 사항들이다.

• 세션 수와 포트 관리: 예상 동시 세션 수를 기준으로 UDP 포트 전략을 먼저 설계해야 한다. 세션당 포트 방식은 소규모에서는 단순하지만, 수천 세션 이상에서는 운영 부담이 급격히 커진다.
• Kubernetes 친화성 확인: WebRTC 미디어 서버를 파드로 운영할 경우, 재스케줄링 시 세션 상태 보존 전략이 반드시 필요하다. 릴레이 레이어 분리가 한 가지 해법이 될 수 있다.
• 첫 홉 레이턴시 측정: 글로벌 서비스라면 클라이언트와 미디어 엣지 간 물리적 거리가 체감 품질을 결정한다. 지역별 릴레이 배치와 지오 스티어링 시그널링을 설계 초기부터 고려해야 한다.
• SFU vs 트랜시버 선택: 멀티파티 기능(녹음, 다자 통화, 핸드오프)이 필요하면 SFU가 낫고, 순수 1:1 AI 음성이라면 트랜시버 모델이 레이턴시와 운영 복잡도 양쪽에서 유리하다.
• Go + Pion 생태계 검토: OpenAI가 직접 선택한 스택인 만큼, 동일 기술 스택을 고려 중이라면 Pion 커뮤니티와 문서를 사전에 충분히 검토할 것을 권장한다.