NAT 순회 기술 설명

모든 영상 통화에는 당신이 절대 보지 못하는 불가능한 순간이 있다.

당신의 컴퓨터와 친구의 컴퓨터 — 둘 다 라우터 뒤에 숨어 있고, 둘 다 공개 인터넷에서 아무 의미 없는 주소를 사용하면서도 — 어떻게든 서로를 찾아내어 직접 연결을 맺는다. 이는 정확히 그것을 막도록 설계된 네트워크를 가로질러 일어난다.

이것이 NAT 순회다. P2P 통신이 작동하는 이유가 바로 이것이다.

NAT가 만드는 문제

당신의 홈 라우터는 매일 마술을 부린다. 하나의 공인 IP 주소를 가지고 집 안의 모든 기기에서 작동하게 만든다. 노트북은 192.168.1.100을 받는다. 스마트폰은 192.168.1.101을 받는다. 스마트 TV는 192.168.1.102를 받는다. 이 주소들은 어느 것도 집 밖에서는 존재하지 않는다.

웹사이트를 방문할 때 NAT(네트워크 주소 변환)이 변환을 처리한다. 라우터는 당신이 그 웹페이지를 요청했다는 것을 기억하기 때문에, 응답이 공인 IP 주소에 도착하면 192.168.1.100으로 전달해야 한다는 것을 안다. 이 시스템은 이런 방식에서는 아름답게 작동한다: 당신이 먼저 요청하고, 서버가 응답하면, 모두가 만족한다.

그런데 양쪽 모두 NAT 뒤에 있으면 어떻게 될까? 당신이 친구에게 영상 통화를 걸고 싶다고 하자. 둘 다 먼저 연결을 시도할 수 없다 — 상대방이 인터넷에서 실제로 어디 있는지 아무도 모르기 때문이다. 사설 주소는 각자의 네트워크 밖에서는 아무 의미가 없다. 공인 주소는 라우터에 속한 것이지, 당신에게 속한 것이 아니다.

NAT는 P2P 연결성을 망가뜨렸다. 이제 살펴볼 기술들은 인터넷이 그것을 되찾은 방법이다.

STUN: 자신의 모습 파악하기

누군가에게 당신이 어디 있는지 알려주기 전에, 먼저 자신이 어디 있는지 알아야 한다.

STUN — Session Traversal Utilities for NAT — 은 하나의 질문에 답한다: "내 공인 주소가 뭐지?"

교환 과정은 다음과 같다:

1. 애플리케이션이 공개 인터넷의 STUN 서버에 바인딩 요청을 보낸다
2. STUN 서버는 도착한 패킷을 검사하여 출발지 IP 주소와 포트를 기록한다
3. 그것은 당신의 사설 주소가 아니다 — NAT 변환 후 외부에서 바라본 라우터의 모습이다
4. 서버는 이 정보를 돌려보낸다: "당신은 203.0.113.42, 포트 54321로 보입니다"

이제 당신은 중요한 정보를 갖게 된다. 이 주소를 다른 채널을 통해 — 보통 둘 다 접근 가능한 시그널링 서버를 통해 — 상대방과 공유한다. 상대방도 같은 작업을 한다. 이제 서로의 공개 위치를 알게 된다.

STUN(RFC 8489)은 놀랍도록 가볍다. 단 한 번의 교환, 수 밀리초의 지연, 거의 없는 대역폭 사용.

하지만 STUN이 알려주지 않는 게 있다: 그 주소가 실제로 작동할지 여부다.

NAT 유형이 운명을 결정하는 이유

모든 NAT가 동일하게 동작하지는 않는다. 당신과 인터넷 사이의 NAT 유형이 공인 주소를 아는 것만으로 패킷을 받을 수 있는지를 결정한다.

Full Cone NAT는 허용적이다. 라우터가 한 번 매핑을 생성하면 — 예를 들어 내부 포트 50000이 외부 포트 54321에 매핑되면 — 인터넷의 누구든 그 외부 포트로 패킷을 보내 당신에게 도달할 수 있다. 패킷 하나를 보냈을 뿐인데, 이제 누구든 응답할 수 있다.

Restricted Cone NAT는 조건을 추가한다. 라우터는 이전에 당신이 접속한 주소에서 오는 패킷만 전달한다. IP 주소 X에 패킷을 보냈다면, X는 응답할 수 있다. 하지만 당신의 공인 주소와 포트를 알고 있어도 Y는 그렇게 할 수 없다.

Port Restricted Cone NAT는 이를 더 강화한다. 들어오는 패킷은 당신이 처음에 접속한 것과 동일한 IP 주소 및 동일한 포트에서 와야 한다.

Symmetric NAT는 직접 연결이 종종 실패하는 지점이다. 라우터는 접속하는 각 목적지마다 다른 외부 포트 매핑을 생성한다. STUN 서버 A에 쿼리하면 라우터가 외부 포트 54321을 할당한다. 상대방 B에 연결하려 하면 라우터가 외부 포트 54322를 할당한다. STUN 서버가 알려준 주소는 상대방이 사용해야 할 주소가 아니다. 당신에게는 단일한 "공인 주소"가 없다 — 목적지마다 다른 주소가 있다.

실제로 대부분의 홈 라우터와 셀룰러 네트워크는 Cone NAT 변형을 구현한다. 기업용 방화벽과 보안 장비는 종종 Symmetric NAT를 구현한다. 기업 사용자들이 P2P 연결에 더 많은 어려움을 겪는 이유가 바로 이것이다.

홀 펀칭: 조율된 타이밍

홀 펀칭은 NAT가 포트 매핑을 생성하고 유지하는 방식을 이용한다.

핵심 통찰: 아웃바운드 패킷을 보내면 NAT는 응답을 허용하는 임시 매핑을 생성한다. 두 상대방이 동시에 서로에게 패킷을 보내면 어떨까?

UDP 홀 펀칭 과정:

1. 양쪽 모두 랑데부 서버에 접속하여 공인 주소를 공유한다 (STUN으로 발견)
2. 서버가 각각에게 상대방의 위치를 알려준다
3. 양쪽이 동시에 상대방의 공인 주소로 UDP 패킷을 보낸다
4. 상대방에게 패킷을 보내면 NAT가 아웃바운드 매핑을 생성한다 — 구멍을 뚫는다
5. 상대방의 패킷이 도착하면, 그 구멍이 이미 존재하므로 라우터가 통과시켜 전달한다
6. 반대 방향에서도 같은 일이 일어난다
7. 직접 연결 완료

조율이 전부다. 양쪽 모두 받기 전에 먼저 보내야 한다. 아웃바운드 패킷이 인바운드 패킷이 통과할 수 있는 상태를 만든다.

TCP 홀 펀칭도 존재하지만 불안정하다. TCP는 3방향 핸드셰이크가 필요하기 때문에 양쪽이 정확히 적절한 시점에 "동시 연결 시도"를 수행해야 한다. 많은 NAT가 이를 잘 처리하지 못한다. WebRTC와 대부분의 P2P 시스템이 UDP를 선호하는 이유가 이것이다.

홀 펀칭은 Symmetric NAT에 대해 실패한다. 상대방이 접속하려는 포트가 NAT가 그들과 통신하기 위해 할당한 포트가 아니기 때문이다.

TURN: 직접 연결이 실패할 때

TURN — Traversal Using Relays around NAT — 은 모든 것이 실패했을 때의 탈출구다.

TURN 서버는 공개 인터넷에 위치하며 단순히 패킷을 중계한다:

1. TURN 서버에 연결하고 릴레이 할당을 요청한다
2. 서버가 서버 자체의 공인 주소와 포트를 할당한다
3. 이 릴레이 주소를 시그널링을 통해 상대방과 공유한다
4. 상대방이 릴레이 주소로 패킷을 보낸다
5. TURN 서버가 그것을 당신에게 전달한다
6. 아웃바운드 패킷에 대해서는 반대 방향으로 흐른다

TURN(RFC 8656)은 모든 시나리오에서 작동한다. 가장 제한적인 기업 방화벽, 양쪽 모두 Symmetric NAT인 경우에도. TURN 서버로 아웃바운드 연결을 만들 수 있다면 TURN은 작동한다.

비용은 실질적이다. 모든 패킷이 상대방 간에 직접 이동하는 대신 릴레이를 통해 이동한다. 지연이 증가한다 — 추가 홉이 왕복 20-100ms를 더한다. 서버 대역폭은 돈이 든다. 릴레이는 잠재적인 병목과 장애 지점이 된다.

하지만 필요하다. 업계 데이터에 따르면 WebRTC 연결의 15-30%가 TURN 릴레이를 필요로 하며, Symmetric NAT와 엄격한 방화벽이 일반적인 기업 환경에서는 더 높은 비율을 보인다. TURN이 없다면 이러한 연결은 단순히 실패할 것이다.

TURN은 "가끔 작동"과 "안정적으로 작동"의 차이다.

ICE: 동시에 모든 것 시도하기

ICE(Interactive Connectivity Establishment)는 조율자다. ICE(RFC 8445)는 STUN, TURN, 홀 펀칭을 대체하지 않는다 — 이들을 체계적인 프로세스로 결합하여 가능한 모든 연결 방법을 동시에 시도하고 최선의 것을 선택한다.

후보 수집: 각 상대방은 도달 가능한 모든 방법을 수집한다:

• 호스트 후보: 각 네트워크 인터페이스의 로컬 IP 주소
• 서버 반사 후보: STUN으로 발견된 공인 주소
• 릴레이 후보: TURN 서버에서 할당된 주소

일반적인 상대방은 다양한 네트워크 경로를 나타내는 10-20개의 후보를 수집한다.

후보 교환: 상대방들은 시그널링을 통해 — 보통 양쪽이 접근 가능한 서버에 대한 WebSocket을 통해 — 이 후보들을 교환한다.

연결성 확인: ICE는 모든 후보 조합을 동시에 테스트한다. 각 상대방은 로컬 및 원격 후보의 모든 쌍에 STUN 바인딩 요청을 보낸다. 성공적인 교환을 완료하는 첫 번째 쌍이 승리한다.

우선순위 체계: ICE는 더 빠르고 저렴한 경로를 선호한다:

1. 호스트 후보 (직접 로컬 네트워크) — 최고 우선순위
2. 서버 반사 후보 (STUN을 통한 직접 인터넷 연결) — 중간 우선순위
3. 릴레이 후보 (TURN) — 최저 우선순위

이를 통해 릴레이로 대체되기 전에 직접 연결이 먼저 발견되고 사용된다. 애플리케이션이 선택하는 것이 아니다 — ICE가 최적 경로를 자동으로 찾는다.

Trickle ICE: 전통적인 ICE는 모든 후보가 수집될 때까지 기다린 후에 교환한다. Trickle ICE는 발견되는 대로 후보를 점진적으로 보낸다. STUN 응답이 돌아오는 순간, 그 후보가 상대방에게 전송되고 테스트가 시작된다. 이 최적화는 연결 설정 시간을 수 초에서 1초 이내로 줄인다.

ICE의 철저함은 놀랍도록 강건하게 만든다. 적대적인 조건에서도 — 다양한 NAT 유형, 기업 방화벽, 여러 네트워크 인터페이스 — ICE는 모든 가능성을 체계적으로 테스트한다. 경로가 존재한다면 ICE가 찾아낸다.

WebRTC: 완전한 스택

WebRTC — Web Real-Time Communication — 는 이 모든 기술들이 어떻게 함께 작동하는지 보여준다.

WebRTC 통화를 시작하면:

시그널링: 브라우저가 상대방과 조율하기 위해 시그널링 서버(보통 WebSocket)에 연결된다

ICE 수집: WebRTC가 후보를 수집한다:

• 로컬 IP 주소 발견 (호스트 후보)
• 공인 주소를 위한 STUN 서버 접속 (서버 반사 후보)
• TURN 서버에서 릴레이 주소 할당 (릴레이 후보)

오퍼/앤서 교환: 브라우저가 미디어 기능과 ICE 후보를 담은 SDP(Session Description Protocol) 오퍼를 생성한다. 이것이 시그널링 서버를 통해 상대방에게 전달된다. 상대방은 자신의 후보를 포함한 SDP 앤서로 응답한다.

연결성 확인: 양쪽 브라우저가 모든 후보 쌍을 동시에 테스트한다

미디어 전송: 연결이 확립되면 암호화된 오디오와 영상이 상대방 간에 직접 — 또는 필요한 경우 TURN을 통해 — 흐른다

최적 조건에서 이 전체 과정은 1초 이내에 완료된다. TURN이 필요한 어려운 시나리오는 보통 2-3초 내에 연결된다.

WebRTC는 완전한 NAT 순회 스택을 표준화한다. Google Meet, Microsoft Teams, Discord, 그리고 수백 개의 다른 애플리케이션이 네트워크 복잡도에 관계없이 P2P 연결을 맺을 수 있는 이유가 바로 이것이다.

왜 중요한가

NAT 순회는 학문적 호기심이 아니다. 이것은 핵심 인프라다.

영상 회의: 1080p 영상 스트림은 2-4 Mbps를 소비한다. 모든 통화가 중앙 서버를 거친다면 서비스 제공자는 스트림을 받고 상대방에게 보내는 비용을 부담해야 한다 — 대역폭 비용이 두 배가 된다. NAT 순회를 통한 P2P로, 스트림은 참가자들 사이에서 직접 흐른다. 서비스 제공자는 그 대역폭에 아무것도 지불하지 않는다. 지연은 릴레이를 통한 300-500ms에서 직접 연결의 100-200ms로 줄어든다.

게임: 경쟁 게임에서 100ms의 지연은 승패를 가르는 차이다. NAT 순회는 한 플레이어가 서버 역할을 하는 P2P 호스팅을 가능하게 하여, 원거리 데이터센터의 지연 불이익을 피한다.

파일 공유: 릴레이를 통해 큰 파일을 보내는 것은 서버 대역폭을 소비하고 일반적으로 직접 전송보다 느리다. BitTorrent, 브라우저 기반 공유, 동기화 도구는 가능할 때마다 직접 연결을 위해 NAT 순회를 사용한다.

IoT와 원격 접속: 스마트홈 기기와 보안 카메라는 기기를 공개적으로 노출하거나 모든 것을 클라우드 서버를 통해 라우팅하지 않고, 스마트폰에서 집으로의 직접 연결을 위해 NAT 순회를 사용한다.

패턴: NAT 순회는 애플리케이션을 더 빠르고, 저렴하고, 더 프라이빗하며, 더 확장 가능하게 만든다.

현재 상태

2025년에 NAT 순회는 성숙하고 표준화된 인프라다. 주요 RFC들 — ICE를 위한 8445, STUN을 위한 8489, TURN을 위한 8656 — 은 브라우저, 네이티브 앱, IoT 기기 전반에서 작동하는 상호운용 가능한 프로토콜을 정의한다.

성공률은 환경에 따라 다르다. Cone NAT를 사용하는 소비자 네트워크는 일반적으로 70-85%의 직접 P2P 연결을 달성한다. Symmetric NAT와 엄격한 방화벽이 있는 기업 환경에서는 TURN 사용률이 더 높다 — 때로는 30% 이상의 연결이 릴레이를 필요로 한다.

IPv6 도입은 결국 NAT가 광범위하게 쓰이는 현실을 바꿀 수 있다 — 모든 기기가 전 세계에서 라우팅 가능한 주소를 갖게 될 것이다. 하지만 IPv6 배포는 여전히 더디고, 모바일 네트워크의 캐리어급 NAT(CGNAT)는 추가적인 변환 계층을 더한다. NAT 순회는 앞으로도 수년간 필수적으로 남을 것이다.

핵심 정리

NAT는 근본적인 문제를 만든다: P2P 연결은 기본적으로 불가능해진다. 인터넷은 종단 간 통신을 위해 설계되었다. NAT가 그 모델을 망가뜨렸다.

STUN은 당신의 공개 정체성을 발견하게 한다. 홀 펀칭은 임시 경로를 만들기 위해 NAT 동작을 이용한다. TURN은 직접 경로가 존재하지 않을 때 릴레이를 제공한다. ICE는 전체 프로세스를 조율하여 모든 것을 동시에 시도하고 최선의 결과를 선택한다.

이 기술들이 함께 NAT가 빼앗아간 것을 되돌려준다.

당신이 하는 모든 P2P 연결은 이 협상이 밀리초 단위로 일어나는 것을 포함한다. 기술들이 너무나 안정적으로 작동해서 당신은 절대 알아차리지 못한다. 하지만 이것들 없이는 현대 인터넷 — 어떤 기기든 다른 기기와 직접 통신할 수 있는 — 은 존재하지 않을 것이다.

NAT 순회는 우리가 P2P 인터넷을 되찾은 방법이다.

NAT 순회에 관한 자주 묻는 질문

NAT 뒤의 두 컴퓨터는 왜 그냥 직접 연결할 수 없나요?

NAT는 실제 주소를 숨긴다. 컴퓨터는 192.168.1.100 같은 사설 IP를 갖고 있지만, 그 주소는 홈 네트워크 밖에서는 아무 의미가 없다 — 수백만 개의 다른 기기들이 자신의 라우터 뒤에서 같은 주소를 사용한다. 라우터의 공인 IP만이 인터넷에서 볼 수 있는 유일한 주소이며, 라우터는 어떤 내부 기기가 받아야 하는지 알지 못하는 한 들어오는 연결을 전달하지 않는다. 이전에 아웃바운드 연결이 그 매핑을 만들어놓지 않았다면, 들어오는 패킷은 갈 곳이 없다.

STUN과 TURN 서버를 직접 운영해야 하나요?

개발과 테스트를 위해서는 공개 STUN 서버로도 충분하다. 프로덕션을 위해서는 안정성을 위해 자체 STUN 서버를 운영하는 것이 좋다. TURN이 더 중요한데 — 공개 TURN 서버는 드물다. 트래픽 중계가 실질적인 비용이 들기 때문이다. 대부분의 프로덕션 애플리케이션은 자체 TURN 인프라를 운영하거나 클라우드 서비스 제공자의 관리형 서비스를 사용한다.

WebRTC가 때로는 즉시 연결되고 때로는 수 초가 걸리는 이유는 무엇인가요?

속도는 네트워크 조건에 달려 있다. 양쪽 모두 허용적인 NAT(Cone NAT)를 가지고 있으면 홀 펀칭이 빠르게 성공하고 ICE가 1초 이내에 직접 경로를 찾는다. 한쪽 또는 양쪽이 Symmetric NAT나 엄격한 방화벽 뒤에 있으면 ICE는 TURN 릴레이로 대체해야 하며, 이는 협상에 더 긴 시간이 걸린다. 2-3초 연결은 대개 TURN 폴백이다.

IPv6가 NAT 순회의 필요성을 없애줄까요?

이론적으로는 그렇다. IPv6는 모든 기기가 전 세계에서 라우팅 가능한 주소를 가질 수 있도록 충분한 주소를 제공하여 NAT를 완전히 없앤다. 실제로는 IPv6 도입이 느리고, 많은 네트워크가 여전히 NAT와 함께 IPv4를 사용한다. IPv6가 있어도 방화벽이 여전히 들어오는 연결을 차단할 수 있어 유사한 순회 기술이 필요할 수 있다. NAT 순회는 가까운 미래에도 관련성을 유지할 것이다.

출처