결론 먼저 — Symmetric NAT가 양쪽이면 STUN은 0%다
| A 측 NAT | B 측 NAT | STUN만으로 P2P 가능? | fallback 필요 |
|---|---|---|---|
| Full Cone | 아무거나 | O | — |
| Restricted Cone | Full / Restricted | O | — |
| Restricted Cone | Symmetric | X (조건부) | TURN |
| Port Restricted | Port Restricted | O | — |
| Port Restricted | Symmetric | X | TURN |
| Symmetric | Symmetric | 0% | TURN 필수 |
“기본은 STUN, 안 되면 TURN” — 표준 fallback 패턴은 모든 1:1 통화 인프라에서 동일하다. 차이는 비용과 운영 책임을 어디까지 가져갈 것인가에서 갈린다.
STUN과 TURN의 역할
- STUN (RFC 8489) — 단말이 NAT 뒤에서 자기 공인 IP/Port를 알아내게 도와주는 “거울” 서버. 서버는 패킷을 중계하지 않는다.
- TURN (RFC 8656) — STUN으로 안 될 때 패킷을 실제로 중계해 주는 relay 서버. 양쪽 트래픽이 모두 서버를 통과하므로 대역폭과 비용이 든다.
핵심: STUN은 거의 공짜에 가깝고, TURN은 실제 트래픽이 흐르므로 통화 분당 비용이 발생한다.
NAT 4종류와 STUN의 한계
| NAT 종류 | 외부 → 내부 매핑 규칙 | STUN으로 P2P 가능? |
|---|---|---|
| Full Cone | 한 번 매핑되면 외부 누구나 들어올 수 있음 | 가장 쉬움 |
| Restricted Cone | 같은 IP만 들어올 수 있음 | 가능 |
| Port Restricted Cone | 같은 IP+Port만 | 가능 |
| Symmetric | 외부 목적지마다 다른 매핑을 만든다 | STUN으로 안 됨 |
Symmetric NAT는 단말이 STUN 서버에 보낸 매핑과 상대 단말에 보낼 매핑이 다르다. 그래서 STUN이 알려준 주소는 상대 단말 입장에서 무효다. 두 사람이 모두 Symmetric NAT 뒤에 있으면 어떤 STUN 마법으로도 P2P 경로가 만들어지지 않는다.
현실 비율 — 실제 트래픽에서 TURN으로 떨어지는 비율
대중적으로 인용되는 숫자는 모바일 환경 약 8–20%, 사무실/공공 Wi-Fi 환경에서 더 높은 비율로 TURN relay가 필요하다는 보고다 (출처: 각 WebRTC 인프라 벤더의 공개 통계, 아래 인용 참조). 절댓값은 회선·국가·통신사 분포에 따라 달라지지만, “한 자리 % 미만”인 경우는 사실상 없다.
운영 의미: TURN을 안 깔면 N분의 1의 통화가 무조건 실패한다. 1:1 통화 서비스에서 이 비율은 그대로 사용자 이탈률이 된다.
의사결정 — 외부 TURN을 쓸 것인가, 직접 띄울 것인가
| 축 | 외부 TURN 서비스 | self-host (Coturn / Pion TURN) |
|---|---|---|
| 월 통화 1만분 비용 (대중적 가격대 기준) | 수만~수십만 원 | VM 한 대 고정비 |
| 지연 (지역 라우팅) | 글로벌 PoP, 보통 우수 | 본인이 deploy한 리전에 의존 |
| 인증·자격증명 회전 | SDK 제공 | 직접 구현 (HMAC 토큰 등) |
| 운영 책임 (장애·확장) | 벤더 | 본인 |
| 트래픽 사용 가시성 | 벤더 대시보드 | 본인 메트릭 수집 필요 |
의사결정 기준:
- 월 통화량이 매우 적고 출시 초기다 → 외부 TURN이 압도적으로 싸고 운영도 가볍다.
- 통화량이 늘어 월 비용이 self-host VM 비용을 넘기 시작한다 → 자체 운영을 검토할 시점.
- 지역별 latency를 직접 통제해야 한다 (의료·상담·교육 등) → self-host가 유리할 수 있음.
- 인증 자격증명을 자기 시스템 안에서만 발급하고 싶다 → self-host 또는 hybrid.
개인 메모 — STUN과 TURN의 경계를 직접 그려보기 전까지
WebRTC를 처음 공부할 때 헷갈렸던 부분이 “STUN과 TURN 둘 다 필요하다”는 표현이었다. 보통 자료에는 “기본은 STUN, fallback이 TURN” 정도까지만 적혀 있어서, 둘의 경계가 어디서 갈리는지 감이 잘 잡히지 않았다.
RFC 4787과 RFC 8489를 천천히 읽고, 다른 네트워크 환경(개인 인터넷·모바일 핫스팟·공용 Wi-Fi)에서 Pion 데모를 직접 띄워 본 뒤에야 경계가 명확해졌다 — Symmetric NAT 양쪽이 만나면 STUN의 거울 동작 자체가 무효라는 사실, 그리고 그런 NAT가 사무실/공공 Wi-Fi 환경에서 결코 드물지 않다는 점이었다. 이걸 알고 나니, 이후 1:1 통화 인프라를 짠다면 TURN을 처음부터 함께 두는 쪽이 자연스러운 결론이라는 생각이 됐다 — relay 비용은 정량 가능한 비용이지만, 연결 실패는 추적 자체가 어려운 비용이기 때문이다.
참고
- RFC 8489 — Session Traversal Utilities for NAT (STUN)
- RFC 8656 — Traversal Using Relays around NAT (TURN)
- RFC 4787 — NAT Behavior 분류 (Endpoint-Independent / Address-Dependent / Symmetric)
- Coturn — 가장 널리 쓰이는 오픈소스 TURN 서버
- Pion TURN — Go 기반 TURN 서버 라이브러리
관련 글
이 글은 9개월 운영한 1:1 AI 음성 상담 시스템 시리즈의 일부입니다. 전체 그림과 학습 순서는 허브에서, 이웃 주제는 아래에서 이어집니다.
답글 남기기