결론 먼저 — 4축 비교
| 축 | 외부 TURN 서비스 | self-host (Coturn / Pion TURN) |
|---|---|---|
| 시작 비용 | 0 (가입 즉시) | VM/리전 설정 필요 |
| 변동 비용 | 분당 / 트래픽 과금 | 트래픽 + VM 고정비 |
| 인증 자격증명 통제 | 벤더 SDK | 직접 발급 (HMAC 등) |
| 운영 책임 (장애·확장) | 벤더 | 본인 |
| 지역 라우팅 | 글로벌 PoP, 보통 우수 | deploy한 리전 의존 |
| 가시성 | 벤더 대시보드 | 본인 메트릭 수집 필요 |
비용·통제·운영 책임 — 셋 중 어느 축을 우선할 것인가에서 갈린다.
외부 TURN의 강점 — 시작이 가볍다
가입하고 자격증명을 받으면 끝. SDK가 NAT 통과 통계까지 보여주고, 글로벌 PoP을 알아서 라우팅한다. 데모 단계에서는 거의 항상 외부 서비스가 압도적으로 빠르다.
자주 쓰이는 옵션:
Public STUN(stun.l.google.com 등)은 무료지만, TURN은 트래픽이 실제로 흐르므로 무료 옵션이 거의 없다.
외부 TURN의 약점 — 인증 통제가 본인 시스템 밖에 있다
자격증명을 외부 SDK가 발급한다. 이 모델이 다음과 같은 상황에서 부담이 된다.
- 인증을 본인 시스템 안에서만 발급하고 싶다 (보안 정책)
- 자격증명 회전 주기를 본인이 정하고 싶다
- 통화 시작 권한을 본인 사용자 모델과 결합하고 싶다
이때는 외부 TURN의 토큰 발급 API를 wrapping해서 쓰는 hybrid도 가능하고, 처음부터 self-host로 가는 게 단순할 수도 있다.
self-host의 강점 — 통제와 통합
Coturn 또는 Pion TURN으로 직접 띄우면 다음을 얻는다.
- HMAC 기반 단기 토큰 인증을 본인 시스템 안에서 발급 (RFC 8489 / 8656 메커니즘)
- 서버 리전을 직접 선택 (latency 통제)
- TURN 서버의 로그·메트릭을 자기 모니터링 스택에 통합
- 사용량이 매우 커지면 분당 과금보다 고정비가 싸지는 분기점이 존재
self-host의 약점 — 운영 책임이 따라온다
- VM/Pod 한 대를 직접 운영해야 하고, 장애 복구도 본인 몫
- 글로벌 사용자에 대응하려면 멀티 리전 deploy 필요
- TURN 트래픽이 한 노드에 쏠리지 않게 분산 설계
- 인증 자격증명 회전·키 관리를 직접 구현
의사결정 기준 — 무엇이 바뀌면 결정이 바뀌나
데모 / 작은 PoC 단계
- 외부 TURN. 시작 비용이 압도적으로 작다.
규모가 커지고 다음 중 둘 이상이 해당된다면 self-host 검토
- 인증·자격증명을 본인 시스템 안에서만 발급해야 한다
- 분당/트래픽 비용이 self-host VM 고정비를 넘기 시작했다
- 지역별 latency를 직접 통제해야 한다 (의료·교육·상담 등)
- TURN 메트릭을 자기 모니터링 스택에 통합해야 한다
가장 자주 보는 hybrid 패턴: 인증·자격증명만 직접 발급 + relay는 외부 + 일부 핵심 리전에 self-host TURN 추가.
개인 메모 — STUN은 공짜처럼 시작하고, TURN은 비용을 의식한다
처음 WebRTC 데모를 띄울 때는 stun.l.google.com 같은 public STUN을 무비판적으로 썼다. STUN은 패킷을 중계하지 않으므로 트래픽이 거의 없고, 그래서 “공짜라고 둬도 된다”는 인상이 자연스러웠다.
TURN으로 넘어오면 그 인상이 바뀐다. 트래픽이 실제로 서버를 통과하기 때문에 분당 비용이 발생하고, 자격증명도 통제 대상이 된다. 그래서 STUN은 거의 자동으로 외부 서비스를 쓰지만, TURN은 “어디까지 외부에 맡길지”를 의식적으로 결정해야 한다 — 이 한 줄이 self-host 검토의 출발점이었다.
비용 분기점 — 외부 과금 vs self-host 고정비
“언제 self-host가 싸지나”는 결국 한 식으로 정리된다. 외부 TURN은 relay된 트래픽 GB당 과금, self-host는 VM 고정비 + egress 다. 분기점은 다음과 같다.
월 외부비용 ≈ relay_GB × 외부단가($/GB)
월 self비용 ≈ VM고정비 + relay_GB × egress단가($/GB)
분기 relay_GB ≈ VM고정비 ÷ (외부단가 − egress단가)개략 계산(공개 단가 기준, 리전·벤더로 달라짐): 외부 TURN을 GB당 약 $0.4, 클라우드 egress를 GB당 약 $0.1, self-host TURN VM을 월 $30로 잡으면 분기점은 $30 ÷ ($0.4 − $0.1) = 100GB/월 부근이다. 1:1 음성 통화에서 TURN을 타는 비율(대부분은 STUN으로 P2P 성립)을 감안하면, relay 트래픽이 월 100GB를 넘기 전까지는 외부가 거의 항상 싸고 단순하다. 핵심은 절대 단가가 아니라 “고정비를 회수할 만큼 relay가 흐르는가”라는 점이다.
| 월 relay 트래픽 | 외부 TURN(≈$0.4/GB) | self-host(VM $30 + egress $0.1/GB) | 유리한 쪽 |
|---|---|---|---|
| 20 GB | ≈ $8 | ≈ $32 | 외부 |
| 100 GB | ≈ $40 | ≈ $40 | 분기점 |
| 500 GB | ≈ $200 | ≈ $80 | self-host |
단, self-host 쪽 표에는 보이지 않는 비용이 있다 — 장애 대응·키 회전·멀티 리전 운영 시간이다. 그래서 분기점을 넘겨도 “운영 인력이 그 시간을 감당할 수 있는가”가 실제 결정 변수가 된다.
리전별 latency — 직접 운영하며 관측한 결
외부 TURN의 글로벌 PoP은 사용자 근처에서 relay를 잡아주므로, 멀티 리전을 직접 깔기 전까지는 latency 측면에서 외부가 유리한 경우가 많았다. self-host는 deploy한 리전에 묶이므로, 같은 나라 사용자에게는 더 짧지만 먼 리전 사용자에게는 왕복이 길어진다.
| 사용자 위치 | 외부 TURN(글로벌 PoP) | self-host(서울 단일 리전) |
|---|---|---|
| 국내 | 짧음 | 가장 짧음 |
| 아시아 인접 | 짧음 | 중간 |
| 대륙 밖 | 중간(근처 PoP) | 긺(서울까지 왕복) |
결론적으로 latency를 직접 통제하려면 self-host + 멀티 리전이 필요한데, 이건 위 비용표의 VM 고정비를 리전 수만큼 늘리는 결정이다. “국내 사용자만 본다”면 서울 단일 self-host가 비용·latency 둘 다 유리하고, “전 세계를 본다”면 외부 TURN의 PoP 망을 사는 게 합리적이었다.
참고
- RFC 8656 — Traversal Using Relays around NAT (TURN)
- Coturn — 오픈소스 TURN/STUN 서버
- Pion TURN — Go 기반 TURN 서버
- Twilio Network Traversal Service 문서
- Cloudflare TURN
관련 글
이 글은 9개월 운영한 1:1 AI 음성 상담 시스템 시리즈의 일부입니다. 전체 그림과 학습 순서는 허브에서, 이웃 주제는 아래에서 이어집니다.
답글 남기기