음성 AI는 텍스트 챗봇과 평가 기준이 다릅니다. 답변이 맞는지만으로는 부족합니다. 사용자가 먼저 느끼는 건 정답률이 아니라 박자입니다. 말이 끊기거나, 끼어들기가 늦거나, 네트워크가 불안해져서 한 박자씩 밀리면 똑똑한 모델도 바로 어색해집니다. 그래서 실시간 음성 AI를 붙이는 팀은 모델보다 먼저 transport와 media path를 봐야 합니다.
OpenAI가 2026년 5월 4일 공개한 저지연 음성 AI 인프라 글은 이 점을 아주 잘 보여줍니다. 공식 설명에 따르면 OpenAI는 주 9억 명 이상 규모의 사용자 환경에서 WebRTC 기반 실시간 상호작용을 운영하며, 빠른 연결 설정, 낮고 안정적인 미디어 RTT, 낮은 jitter와 packet loss를 핵심 요구사항으로 봤습니다. 그리고 이 요구사항을 맞추기 위해 relay와 transceiver를 분리한 구조를 도입했다고 설명합니다.
실시간 음성에서 사용자는 300ms 차이를 바로 느낍니다. 텍스트 채팅에서는 1초 늦어도 크게 거슬리지 않던 구간이, 음성에서는 대화 리듬을 깨버립니다. 특히 아래 문제가 바로 드러납니다.
그래서 음성 AI는 ‘모델 추론 시간’ 하나만 줄인다고 해결되지 않습니다. 세션 시작, NAT traversal, DTLS handshake, 패킷 라우팅, jitter buffer, 지역 간 first hop latency가 전부 체감 품질에 섞입니다.
공식 글의 핵심은 WebRTC session termination을 transceiver가 담당하고, 외부 공개 UDP 표면은 relay가 담당하는 분리 구조입니다. relay는 패킷을 해독하거나 codec negotiation을 하지 않고, 최소한의 메타데이터만 읽어 올바른 transceiver로 전달합니다. transceiver는 ICE, DTLS, SRTP, 세션 lifecycle 같은 상태를 책임집니다.
이 설계가 중요한 이유는 두 가지입니다.
첫째, 공개해야 하는 UDP 포트 범위를 작게 유지할 수 있습니다. Kubernetes나 로드밸런서 환경에서 수만 개 포트를 안정적으로 노출하는 건 운영 난도가 높습니다.
둘째, 세션 소유권을 한 곳에 유지할 수 있습니다. ICE와 DTLS는 상태ful 프로토콜이라 세션을 만든 프로세스가 계속 같은 패킷을 받아야 안정적입니다. 패킷이 다른 인스턴스로 튀면 설정 실패나 미디어 깨짐이 생길 수 있습니다.
즉, 음성 AI에서 relay는 빠른 입구이고, transceiver는 상태를 들고 있는 실제 종착지입니다.
음성 AI 지연 문제를 다룰 때 많은 팀이 평균 응답 시간 하나만 봅니다. 그걸로는 거의 안 보입니다. 최소한 아래 지표를 따로 봐야 합니다.
이걸 안 나누면 모델이 느린 건지, WebRTC 설정이 느린 건지, 지역 라우팅이 꼬인 건지 구분이 안 됩니다.
relay를 넣었다고 무조건 빨라지지는 않습니다. 실제 병목은 보통 여기서 나옵니다.
첫째, 첫 패킷 라우팅이 느립니다. 공식 글에서도 첫 STUN 패킷에서 ufrag를 읽어 라우팅 힌트를 해석하는 흐름이 핵심이라고 설명합니다. 이 구간이 느리면 세션 시작이 둔해집니다.
둘째, transceiver ownership이 흔들립니다. 세션 패킷이 같은 인스턴스로 안정적으로 가지 못하면 DTLS나 SRTP 처리에서 깨집니다.
셋째, 글로벌 ingress는 가까운데 backend가 멉니다. relay를 사용자 근처에 놔도 실제 추론 백엔드나 음성 합성 백엔드가 멀면 체감 개선이 적습니다.
넷째, 패킷 포워딩 이후 observability가 약합니다. relay에서 느린지, transceiver에서 느린지, inference에서 느린지 구간별 지표가 없으면 원인 추적이 안 됩니다.
음성 AI latency 최적화는 보통 모델 최적화부터 시작하지만, 저는 순서를 반대로 추천합니다.
특히 음성 AI에서는 p50보다 p95가 더 중요합니다. 평균이 좋아도 가끔 크게 튀면 사용자는 전체 시스템을 불안정하다고 느낍니다.
이 내용은 ChatGPT voice 같은 대규모 서비스만의 이야기가 아닙니다. 아래 제품은 바로 적용할 포인트가 많습니다.
이런 제품들은 정답률보다 대화 리듬이 먼저 평가됩니다. 따라서 모델 업그레이드보다 연결 품질과 interrupt 처리 품질을 먼저 잡는 편이 효과가 큽니다.
OpenAI의 사례가 보여주는 핵심은 분명합니다. 자연스러운 음성 AI는 단순히 똑똑한 모델로 만들어지지 않습니다. 세션 설정, 패킷 라우팅, relay 배치, transceiver ownership, inference 연결까지 한 묶음으로 맞아야 합니다. 실시간 대화에서는 가장 느린 구간 하나가 전체 경험을 무너뜨립니다.
지금 음성 에이전트가 어색하다면 ‘모델을 바꿔볼까’보다 ‘어디서 한 박자가 밀리는가’를 먼저 물어보는 게 맞습니다. 대개 답은 프롬프트가 아니라 네트워크와 media path 안에 있습니다.
공식 출처: OpenAI Engineering, How OpenAI delivers low-latency voice AI at scale (2026-05-04)
