[WebRTC 핵심 개념] STUN과 TURN 서버는 왜 필요할까? (NAT 방화벽과 P2P 통신)

[WebRTC 핵심 개념] STUN과 TURN 서버는 왜 필요할까? (NAT 방화벽과 P2P 통신)

 

서론

 

“[WebRTC 핵심 개념] STUN과 TURN 서버는 왜 필요할까? (NAT 방화벽과 P2P 통신)”

 

이 글은 해당 기술을 직접 도입하고 다듬으면서 겪은 실무 경험과 이해를 담고 있다.

부족한 내용이 있을 수 있지만, 나처럼 막 시작한 사람에게는 도움이 될 거라 생각한다.

---

실시간 음성 및 영상 통화”WebRTC”를 구현하다 보면 반드시 마주치는 개념이 있습니다. 바로 STUN과 TURN 서버입니다. 두 브라우저가 직접 데이터를 주고받는 P2P 통신인데, 왜 중간에 ‘서버’가 필요할까요? 그 이유를 네트워크의 근본적인 구조와 함께 아주 쉽게 알아보겠습니다.

1. P2P 통신의 이상과 현실 “NAT의 등장”

graph LR
    ClientA[📱 Client A] <--> |P2P / TURN Relay| ClientB[📱 Client B]
    ClientA --> |WebRTC / ICE| STUN_TURN[🌐 STUN/TURN Server]
    ClientA --> |Signal / Room Token| LiveKit[⚡ LiveKit SFU Server]
    LiveKit --> |Webhook Event| Backend[☕ Spring Boot Backend]

WebRTC는 서버를 거치지 않고 사용자 A와 사용자 B가 직접 데이터를 주고받는 통신 방식입니다. 서버 유지비용이 획기적으로 줄어들고 속도가 매우 빠르다는 장점이 있죠. 하지만 현실의 네트워크 환경은 생각보다 훨씬 가혹합니다.

전 세계의 기기 수는 IPv4 주소”약 43억 개”보다 훨씬 많습니다. 그래서 우리는 공유기”라우터”를 사용해 하나의 공인 IP를 여러 기기가 사설 IP로 쪼개어 나눠 씁니다. 이를 NAT”Network Address Translation”라고 부릅니다.

문제는 사설 IP”예: 192.168.0.2″로는 외부 인터넷에서 내 기기를 찾아올 수 없다는 것입니다. 서로의 주소를 모르는 상태에서는 P2P 직접 연결이 아예 불가능합니다.

2. STUN 서버: “내 진짜 주소가 뭐야?”

이 문제를 해결하기 위해 등장한 것이 STUN “Session Traversal Utilities for NAT” 서버입니다.

STUN 서버는 아주 단순한 거울 같은 역할을 합니다. 내 컴퓨터가 STUN 서버에 요청을 보내면, STUN 서버는 “너 방금 공유기 거쳐서 나한테 왔지? 공유기 밖에서 보이는 너의 진짜 공인 IP와 포트는 이거야!” 라고 알려줍니다.

• 서로 STUN 서버를 통해 자신의 진짜 공인 IP를 알아냅니다.
• 알아낸 주소를 서로 교환합니다.
• 이제 진짜 주소를 알았으니, P2P로 직접 연결합니다!

3. TURN 서버: “도저히 길이 없으니 네가 대신 전해줘!”

STUN 서버 덕분에 모든 문제가 해결된 것 같지만, 세상에는 Symmetric NAT나 엄격한 기업용 방화벽처럼 보안이 매우 철저한 네트워크가 존재합니다. LTE/5G 모바일 네트워크 환경에서도 자주 발생하죠. 이런 환경에서는 공인 IP를 알아내도 외부에서의 직접 접속을 방화벽이 튕겨내 버립니다.

이럴 때 최후의 보루로 사용하는 것이 TURN “Traversal Using Relays around NAT” 서버입니다.

직접 연결”P2P”이 도저히 불가능할 때, 두 사용자는 공용 우체국 역할을 하는 TURN 서버에 데이터를 보냅니다. TURN 서버가 중간에서 데이터를 받아 상대방에게 전달해 주는 릴레이”중계” 역할을 합니다. 서버를 거치기 때문에 엄밀히 말하면 P2P가 아니게 되며, 트래픽 비용과 지연 시간이 발생하지만 어떤 환경에서도 무조건 연결을 보장한다는 엄청난 장점이 있습니다.

4. ICE “Interactive Connectivity Establishment”

WebRTC는 이 모든 과정을 ICE 프레임워크를 통해 자동으로 처리합니다. ICE는 두 기기가 연결될 수 있는 모든 경우의 수”직접 연결, STUN을 통한 연결, TURN을 통한 중계”를 수집하고, 가장 빠르고 효율적인 경로를 스스로 선택하여 통화를 연결시킵니다.

VoiceLink 서비스에서도 모바일 네트워크 등에서의 직접 연결이 실패하는 환경에서 릴레이 경로를 확보하기 위해 자체 TURN 서버를 구축하였으며, 덕분에 릴레이가 필요한 환경에서도 대체 연결 경로를 확보했습니다. 실제 성공률과 통화 품질은 네트워크별 측정으로 확인해야 합니다.

함께 읽으면 좋은 글

• [백엔드 아키텍처] Spring Boot @Async와 ThreadPool을 활용한 대규모 트래픽 병목 해소
• Flutter Isolate로 UI Jank 줄이기
• Redis Pub/Sub을 활용한 분산 서버 동기화 운영 가이드

공식 문서와 확인 자료

아래 1차 자료를 기준으로 명령 동작과 적용 조건을 다시 확인할 수 있습니다.

• WebRTC 연결성 문서
• RFC 8445 ICE