결론 먼저 — 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 검토의 출발점이었다.
답글 남기기