핵심 인사이트 (3줄 요약)

  1. 본질: 공유기(NAT) 뒤에 숨어있는 두 PC가 P2P(1:1)로 실시간 화상통화나 게임을 하려 할 때, 서로의 진짜 공인 IP를 몰라 접속이 튕기는 문제를 해결하기 위해 고안된 NAT 횡단(NAT Traversal) 기술의 삼총사다.
  2. STUN과 TURN: STUN 서버는 "네 공인 IP는 이거야!"라고 거울처럼 알려주어 직접 통신을 돕는 가벼운 서버고, 통신사 방화벽이 너무 빡세서 STUN마저 실패하면 최후의 수단으로 TURN 서버가 두 사람의 데이터를 중간에서 100% 중계해 주는 무거운 우회 서버 역할을 한다.
  3. ICE의 역할: 개발자가 일일이 "STUN 써봐, 안 되면 TURN 써!"라고 코딩할 필요 없이, ICE 프레임워크가 양쪽의 네트워크 상태를 분석하여 "가장 빠르고 싼 통신 경로(로컬 -> STUN -> TURN 순서)"를 자동으로 찾아내어 뚫어주는 지휘관 역할을 한다.

Ⅰ. 개요 및 필요성 (Context & Necessity)

  • 개념: WebRTC(실시간 웹 통신), VoIP, P2P 게임 등에서 NAT나 방화벽을 뚫고 엔드포인트 간의 연결(Session)을 성사시키기 위한 일련의 프로토콜 집합.

  • 필요성: 내가 내 친구랑 카카오톡 화상통화를 하려고 한다. 내 폰은 우리 집 공유기(192.168.0.5), 친구 폰은 카페 공유기(10.1.1.20) 뒤에 있다. 내가 친구에게 "내 IP 192.168.0.5 니까 일로 영상 데이터 보내!"라고 해봤자 친구의 패킷은 인터넷에서 길을 잃는다. 서로의 진짜 얼굴(공인 IP와 포트)을 알아내고, 공유기의 빡빡한 방화벽(Symmetric NAT 등)을 속여서 통신 구멍을 뚫으려면 특수한 제3자(중개 서버)의 도움이 절대적으로 필요했다.

  • 💡 비유: 감옥(공유기)에 갇힌 A와 B가 서로 직통 전화를 뚫으려 합니다.

    • STUN: 교도소 담장 밖 산꼭대기에 있는 **"망원경을 든 친구"**입니다. A와 B에게 "너희 교도소 외부 담장(공인 IP) 주소는 이거야!"라고 알려주어 둘이 몰래 땅굴을 파서 만나게 도와줍니다.
    • TURN: A와 B가 땅굴을 파다 걸려서(방화벽) 도저히 못 만날 때, 산꼭대기 친구(TURN)가 **"아휴 답답해! 그냥 나한테 편지 던져! 내가 받아서 B한테 던져줄게!"**라며 직접 중계해 주는 녀석입니다.
    • ICE: 땅굴을 팔지, 돌을 던질지, 아니면 같은 감방 안인지 모든 수단을 시도해 보고 "가장 성공 확률이 높은 방법"을 골라주는 탈옥 브로커입니다.

📢 섹션 요약 비유: NAT 횡단 기술은 각자의 요새(사설망)에 틀어박혀 밖으로 나올 수 없는 두 성주가, 서로 직접 대화하기 위해 거울로 햇빛을 반사시켜 위치를 알리거나(STUN), 전령을 띄워(TURN) 어떻게든 소통의 다리를 놓는 눈물겨운 공병 작전입니다.

Ⅱ. 3대 프로토콜의 동작 메커니즘 (Deep Dive)

1. STUN (Session Traversal Utilities for NAT)

  • 동작: 클라이언트가 인터넷망에 있는 STUN 서버에 "Hello" 패킷을 보낸다. STUN 서버는 응답 패킷에 "내가 보기에 네 패킷은 211.x.x.x의 5000번 포트에서 날아왔어!"라고 적어서 돌려준다.
  • 효과: 클라이언트는 자기의 공인 IP와 포트를 최초로 깨닫게 된다. 이 정보를 카카오톡 중앙 서버(Signaling Server)를 통해 친구에게 전달하면, 친구는 그 공인 주소로 P2P 데이터를 쏠 수 있게 된다.
  • 한계: 통신사의 빡센 방화벽(Symmetric NAT)은 "어? 아까 STUN 서버랑 통신할 때 열어둔 포트로 친구 놈이 접속하려 하네? 차단!" 해버려서 STUN이 실패하는 경우가 약 20% 존재한다.

2. TURN (Traversal Using Relays around NAT)

  • 동작: STUN으로 P2P 직통 연결에 실패했을 때 가동되는 최후의 보루다. A와 B는 억지로 직통 연결을 하지 않고, 클라우드에 떠 있는 TURN 서버와 각각 세션을 맺는다. A가 영상 데이터를 TURN 서버로 보내면, TURN 서버가 B에게 그대로 전달(Relay)해 준다.
  • 단점: 트래픽의 100%가 TURN 서버를 거쳐 가므로, TURN 서버의 트래픽 비용(AWS 요금 등)이 미친 듯이 폭발하며, 중계로 인한 핑(Delay) 지연이 발생한다.

3. ICE (Interactive Connectivity Establishment)

  • 동작: STUN과 TURN을 조립하여 100% 통신 성공을 보장하는 프레임워크(규칙)다.
  • ICE는 통신 후보지(Candidate) 목록을 뽑아 우선순위를 매긴다.
    1. Direct (우선순위 1등): "혹시 같은 집 공유기 안(사설 IP)에 있니?" (가장 빠름)
    2. STUN (우선순위 2등): "공유기 밖(공인 IP)을 통해 P2P로 직통 뚫을 수 있니?"
    3. TURN (우선순위 꼴찌): "다 안 되면 어쩔 수 없지... 비싼 중계 서버 쓰자."
  • WebRTC는 이 ICE 프레임워크를 기본 탑재하고 있어, 개발자가 별도로 셋업하지 않아도 알아서 최적의 통신망을 찾아낸다.
 ┌─────────────────────────────────────────────────────────────┐
 │                 WebRTC의 ICE 구동 (NAT 횡단) 시나리오            │
 ├─────────────────────────────────────────────────────────────┤
 │                                                             │
 │   [ PC A (사설 10.x) ]                       [ PC B (사설 192.x) ] │
 │         │                                            │        │
 │         │   1. 내 공인 IP가 뭐야?                      │        │
 │         ├────────────────▶ [ STUN 서버 ] ◀──────────┤        │
 │         │                   (거울 역할)                │        │
 │         │                                            │        │
 │         │   2. 서로 공인 IP 알아냄 -> P2P 직통 시도!      │        │
 │         └─────── (방화벽 때문에 실패 X) ───────────────┘        │
 │                                                             │
 │         3. ICE 왈: "안 되겠다, 3안(TURN)으로 간다!"                 │
 │         │                                            │        │
 │         └─────────▶  [ TURN 중계 서버 ]  ◀───────────┘        │
 │                      (모든 데이터 패킷을 중계)                  │
 └─────────────────────────────────────────────────────────────┘

📢 섹션 요약 비유: ICE는 **"만남 주선 앱"**입니다. 두 남녀가 같은 동네면 바로 카페에서 만나게 해주고(Direct), 다른 동네면 서로의 주소를 알려줘서 중간 지점에서 만나게 해주며(STUN), 상대방 부모님이 너무 엄해서 외출이 안 되면(Symmetric NAT), 앱 관리자가 **직접 편지를 배달(TURN)**해 주는 완벽한 매칭 알고리즘입니다.