AI 음성 에이전트에게 TURN 서버가 필요할까요? 일반적으로는 그렇습니다. 그리고 그 정확한 이유는 단순한 슬로건보다 더 중요합니다.

음성 에이전트는 WebRTC를 통해 사용자의 브라우저를 클라우드에 있는 모델에 연결합니다. 많은 사용자가 직접 연결하지만, UDP를 차단하는 기업 네트워크에 있는 사람은 TCP 443 포트의 릴레이(Relay)를 통해서만 에이전트에 도달할 수 있습니다.

이러한 차단은 세션당이 아니라 네트워크당 발생합니다. 따라서 해당 사용자들에게 AI 에이전트를 위한 TURN 서버는 선택 사항이 아닙니다. 그들의 미디어는 100% 릴레이에 의존합니다.

이것이 아마도 여러분이 절대적인 주장으로 접했을 법한 내용에 대한 솔직한 버전입니다. 그 절대적인 주장을 바로잡은 다음, 언제 그리고 어떻게 릴레이를 연결해야 하는지 정확히 보여드리겠습니다.

요약 (TL;DR): AI 음성 에이전트 미디어는 피어 투 피어 (Peer-to-Peer, P2P)가 아니라 WebRTC를 통해 브라우저에서 클라우드로 이동합니다. 따라서 직접 경로가 차단되면 릴레이가 유일한 대안입니다. 대부분의 가정용 사용자는 직접 연결하지만, UDP를 차단하는 기업 방화벽은 모든 세션을 TCP/443을 통한 TURN 릴레이로 강제하며, 일부 플랫폼(AWS Bedrock AgentCore)은 TURN을 아예 의무화합니다. "100% 릴레이"는 해당 사용자들에게만 해당되지만, 어떤 프로덕션 음성 에이전트도 이들을 위한 릴레이 없이 출시되지 않습니다.

AI 음성 에이전트가 실제로 연결되는 방식

연결의 형태부터 시작해 보겠습니다. 모든 후속 과정은 여기서 결정되기 때문입니다.

음성 에이전트는 피어 투 피어 (Peer-to-Peer) 통화가 아닙니다. 단일 WebRTC 연결을 통해 브라우저가 클라우드 서버에서 실행되는 모델과 대화하는 것입니다. 사용자의 마이크 오디오는 위로 흐르고, 에이전트의 합성된 음성은 다시 아래로 스트리밍됩니다.

이는 정확히 하나의 원격 엔드포인트(Remote Endpoint) — 즉 클라우드 — 가 존재하며, 직접 경로가 실패할 경우 정확히 하나의 비직접 옵션 — 즉 릴레이 — 가 존재함을 의미합니다.

이를 사람 간의 통화와 비교해 보면, 두 피어(peer)가 때때로 서로에게 도달할 수 있는 로컬 네트워크 경로를 찾거나, 그렇지 못할 경우 릴레이(relay)를 통해 대체 경로를 사용할 수 있습니다. 하지만 에이전트에게는 시도할 수 있는 두 번째 피어가 없습니다. LAN 로컬 단축 경로도, 대체 경로도 없습니다. 오직 클라우드 엔드포인트(endpoint)와 그곳에 도달할 수 있는 경로만이 존재할 뿐입니다.

따라서 릴레이는 예외적인 상황을 위해 덧붙이는 있으면 좋은(nice-to-have) 기능이 아닙니다. 직접 경로가 차단되었을 때 아키텍처가 제공하는 유일한 보험입니다.

[

"100% 릴레이" 밈 — 그리고 무엇이 잘못되었는가

"voice agents를 위한 TURN"을 검색해 보면 수십 개의 벤더 블로그에서 똑같은 문구를 마주하게 될 것입니다. 에이전트 트래픽은 예외 없이 100% 릴레이라는 내용입니다. 이는 깔끔하게 들리는 문구입니다. 하지만 이를 일반적인 주장으로 삼는 것은 틀렸으며, 그 틀린 방식은 시사하는 바가 큽니다.

클라우드 에이전트는 **공인 IP (public IP)**를 가지고 있으므로, 개방된 홈 네트워크를 사용하는 유저는 보통 에이전트에 직접 (directly) 도달하며, 이 과정에서 릴레이는 전혀 관여하지 않습니다. 저명한 독립 WebRTC 권위자인 Tsahi Levent-Levi는 네트워크 환경에 따라 일반적인 릴레이 사용률을 세션의 약 "0에서 50퍼센트" 사이로 보고 있습니다 (bloggeek.me, TURN glossary). 100%가 아닙니다.

이 밈이 정말로 실수하고 있는 부분은 바로 여기입니다. 이 밈은 종종 OpenAI의 자체적인 실시간 음성(realtime voice) 작업을 증거로 인용하곤 하는데, 정작 그 작업은 전통적인 릴레이에 대해 정반대의 이야기를 하고 있습니다.

OpenAI는 저지연(low-latency) 음성 아키텍처에서 미디어 경로의 중개자로서 너무 무거운 TURN 방식의 릴레이를 명시적으로 거부했습니다. 대신 ICE-TCP 상에서 프라이빗 릴레이-트랜시버(relay-transceiver) 설계를 구축했습니다. 이는 OpenAI가 사용자 한 명과 모델 간의 대부분 1:1 세션이라고 설명하는 워크로드에 적용된 것입니다 (InfoQ, 2026-05-20). 그 동기는 무차별적인 NAT 트래버설(NAT traversal)이 아니라, 공인 UDP 노출과 운영 복잡성을 줄이는 것이었습니다.

따라서 "OpenAI가 TURN이 필요하다는 것을 증명했다"는 말은 앞뒤가 바뀐 것입니다. OpenAI가 실제로 증명한 것은 더 미묘하며, 그것이 바로 게임의 핵심입니다.

OpenAI는 전통적인 TURN 없이 방화벽 트래버설 (firewall traversal)을 구현하기 위해 글로벌 릴레이 (relay) 네트워크를 직접 구축했습니다. 하지만 당신은 OpenAI가 아닙니다. 자체 호스팅되는 에이전트를 출시하는 팀은 전 세계에 걸쳐 ICE-TCP 릴레이 함대를 보유하고 있지 않습니다. 하이퍼스케일러 (hyperscaler)가 아닌 모든 이들에게, 443 포트의 TURN 서버는 OpenAI가 수작업으로 설계한 것과 동일한 엔터프라이즈 방화벽 트래버설을 달성할 수 있는 접근 가능하고 기성품화된 방법입니다.

이것이 제목에 "(거의)"라는 표현이 핵심적인 이유입니다. 이 단어를 빼버리면 거짓을 반복하는 것이 되지만, 이 단어를 유지하면 진실을 정확하게 말할 수 있습니다.

정확한 진실: 음성 에이전트의 트래픽이 정말로 (거의) 100% 릴레이인 경우

여기 주목할 만한 주장이 있습니다. "모든 에이전트 트래픽이 100% 릴레이이다"가 아니라, 음성 에이전트의 미디어가 완전히 릴레이에 의존하게 되는 세 가지 구체적이고 방어 가능한 사례와, 이들을 하나로 묶는 네 번째 현실에 대한 이야기입니다.

첫째: 두 번째 피어 (peer)가 없으면 지름길도 없습니다. 에이전트는 단일 클라우드 엔드포인트 (endpoint)를 가지기 때문에, 릴레이는 유일한 비직접 경로입니다. 직접 경로가 실패하면 시도할 수 있는 다른 방법이 없습니다.

둘째: 네트워크별로 UDP 차단은 이진법적(binary)입니다. UDP가 개방된 대부분의 홈 유저는 에이전트에 직접 연결하며, TURN이 필요하지 않습니다. 하지만 보안이 엄격한 기업용 또는 엔터프라이즈 LAN은 UDP를 완전히 차단하고 오직 몇 개의 포트로만 아웃바운드 트래픽을 허용합니다. 그런 환경에서는 443 포트의 TLS 기반 TURN이 "해당 포트가 일반적인 HTTPS 트래픽처럼 보이기 때문에 통과할 수 있는 유일한 경로인 경우가 많습니다". 해당 사용자층에게 이는 15%가 아니라 사실상 100%입니다. 왜냐하면 차단은 세션 단위가 아니라 네트워크 단위로 이루어지기 때문입니다.

셋째: 일부 플랫폼은 아키텍처상 TURN을 의무화합니다. AWS Bedrock AgentCore의 WebRTC 런타임은 "클라이언트와 에이전트 사이의 미디어 트래픽에는 TURN 릴레이 (relay)가 필수적입니다"라고 명시하고 있으며, 관리형 TURN 서비스로 Amazon KVS를 제공합니다 (AWS docs, 2026-03). 이러한 플랫폼에서 TURN은 사용자의 네트워크 환경과 관계없이 연결 경로의 일부가 됩니다.

그리고 네 번째 현실: 사용자가 UDP를 차단하는 방화벽이나 캐리어급 NAT (CGNAT) 뒤에 있는지 예측할 수 없기 때문에, 모든 사용자를 위해 릴레이를 프로비저닝(provisioning)하게 됩니다. "데모에서는 잘 작동하는" 에이전트는 이 단계를 건너뛰었으며, 아직 기업 사용자를 만나지 못한 에이전트일 뿐입니다.

지원 과정에서 목격되는 패턴: 내 네트워크에서는 작동하지만, 모바일과 사무실에서는 실패함

저희는 TURN 인프라를 운영하며 생계를 유지하고 있으며, 반복해서 접하게 되는 지원 상담 내용이 있습니다. 이 내용은 이 글이 다루고자 하는 정확한 실패 사례이기에 재현해 볼 가치가 있습니다.

한 개발자의 음성 에이전트가 로컬 네트워크에서는 완벽하게 작동합니다. 그러다 모바일 폰을 통해 연결하거나 사무실 네트워크 내부에서 연결하면 작동하지 않습니다. 앱에는 "연결됨"이라고 표시되지만, 오디오는 전혀 전달되지 않습니다.

거의 매번 원인은 동일합니다: TURN이 제대로 설정되지 않았기 때문입니다. 저희가 팀에게 올바른 TURN 설정을 안내하고 나면, 에이전트는 사무실 내부뿐만 아니라 모바일 네트워크에서도 어디서든 잘 작동합니다.

이러한 하나의 증상 뒤에는 두 가지 메커니즘이 자리 잡고 있습니다. 모바일 네트워크는 일반적으로 대칭형 NAT (symmetric NAT)처럼 동작하는 캐리어급 NAT (CGNAT)를 실행하며, 이는 STUN이 발견한 주소를 상대방 측에서 사용할 수 없게 만듭니다. 사무실 및 캠퍼스 Wi-Fi는 방화벽에서 UDP를 완전히 차단합니다.

메커니즘은 다르지만 결과는 같습니다: 직접 경로(direct path)는 끊어지고, 오직 TCP/443을 통한 릴레이만이 살아남습니다.

이러한 사실을 놓치기 쉬운 이유는 개발 환경(development machine)이 이러한 제약 사항이 전혀 적용되지 않는 유일한 환경이기 때문입니다. localhost에서는 통과해야 할 네트워크가 없습니다. 하지만 실제 네트워크를 사용하는 실제 사용자들에게 배포하면, 릴레이(relay)가 갑자기 핵심적인 역할을 수행하게 됩니다.

배포 시나리오별 TURN 요구 사항 (2026년)

백분율을 두고 논쟁하기보다는, 시나리오별로 정리된 결정 사항을 확인해 보십시오. 각 행에는 날짜와 출처가 명시되어 있으므로, 자신의 배포 환경을 행에 대조하여 현재 상황을 파악할 수 있습니다.

배포 시나리오별 TURN 요구 사항 — 2026-07-15 검증 완료:

"TURN 릴레이 필요 여부?" 열을 따라 내려가 보면 패턴이 명확합니다. 릴레이를 건너뛸 수 있는 유일한 경우는 개방형 가정 환경과, 사용자 대신 조용히 자체 릴레이를 실행해 주는 호스팅 플랫폼뿐입니다. 모든 셀프 호스팅(self-hosted) 또는 엔터프라이즈 대상 배포는 "예"에 해당합니다.

음성 에이전트에 TURN을 연결하는 방법

먼저 메커니즘을 살펴본 뒤 설정을 알아보겠습니다. WebRTC는 연결 후보(connection candidates)를 수집하며, 이때 시도할 ICE 서버 목록을 전달받습니다. STUN은 공인 주소(public address)를 찾아내고, TURN은 직접 경로가 불가능할 때 미디어를 릴레이(relay)합니다. 만약 이 세 가지 약어가 모호하다면, 이 STUN vs TURN vs ICE 설명 가이드가 깔끔한 입문서가 될 것입니다.

음성 에이전트(voice agent)의 경우, 순수 WebRTC를 사용하든 프레임워크를 사용하든 동일한 형태의 iceServers 배열을 피어 연결(peer connection)에 전달합니다. 최소한의 설정에는 STUN 항목과 자격 증명이 포함된 TURN 항목이 포함됩니다.

const iceServers = [
  { urls: "stun:<your-stun-url>" },
  { 
...

두 가지 세부 사항이 핵심적인 역할을 합니다. 443 포트의 transport=tcp는 기업 방화벽을 통과할 수 있는 진입점이며, turns: (TLS 기반의 TURN) 항목은 해당 트래픽이 일반적인 HTTPS처럼 보이게 만듭니다. 이 두 가지를 모두 제공하면, 앞서 시나리오 표에서 언급한 엄격한 네트워크 환경의 사용자들도 마침내 연결할 수 있습니다.

디버깅을 위해 알아두면 좋은 설정이 하나 있습니다: iceTransportPolicy: "relay"는 모든 후보(candidate)가 TURN을 통과하도록 강제합니다. 실제 방화벽 문제가 발생하기 전에 릴레이(relay) 경로가 제대로 작동하는지 확인하려면 테스트 중에 이 설정을 사용하세요. 만약 relay를 강제했을 때 연결이 된다면, 보안이 강화된 네트워크의 사용자들도 연결될 것입니다.

에이전트에게 필요한 두 번째 요소가 있는데, 미디어(media)에 집중하다 보면 잊기 쉽습니다. 바로 SDP 오퍼(offer)와 ICE 후보(candidate)를 교환하기 위한 **시그널링 채널 (signalling channel)**입니다. 이것은 "양측이 서로를 어떻게 찾아내는가?"라는 질문에 대한 답입니다. Metered Realtime은 MIT 라이선스의 오픈 소스 클라이언트를 통해 100개의 동시 연결과 월 100,000개의 메시지를 무료로 제공하는 관리형 시그널링을 제공합니다. 따라서 릴레이를 담당하는 동일한 벤더를 사용하면 별도의 통합 과정 없이 제어 채널(control channel)까지 함께 해결할 수 있습니다.

이 과정을 처음부터 끝까지 확인하고 싶다면, 저희는 TURN 단계를 포함하여 마이크에서 모델로, 그리고 다시 돌아오는 전체 TypeScript 음성 에이전트를 구축하고 측정했습니다. 자세한 내용은 이 음성 에이전트 구축 가이드를 참조하세요. 이 인프라 관련 글의 빌드 측면 보완 자료입니다.

셀프 호스팅 LiveKit 에이전트를 위한 TURN