한눈에 보기
"NAT 유형"이라는 말은 세 가지 서로 다른 체계를 가리키는 데 쓰입니다. 하나는 2003년 RFC 3489(STUN)의 4분류, 하나는 2007년 RFC 4787의 매핑·필터링 용어, 나머지 하나는 게임 콘솔이 화면에 보여주는 제조사 표기입니다. 위 카드는 4분류를 하나씩 설명했고, 아래에서는 이 체계들이 서로 어떻게 대응하고 어디서 어긋나는지, 왜 분류가 바뀌었는지를 정리합니다.
- RFC 3489 분류(Full Cone, Restricted Cone, Port Restricted Cone, Symmetric)는 STUN 초기 규격의 용어이며, RFC 4787은 이 용어가 실제 동작을 설명하기에 부적절했다고 평가합니다.
- RFC 4787의 기준은 "매핑"(내부 주소·포트가 어떤 외부 주소·포트가 되는가)과 "필터링"(어떤 외부 패킷을 들여보내는가) 두 축입니다.
- RFC 3489 자체는 2008년 RFC 5389에 의해 대체(obsoleted)되었습니다.
- 콘솔의 NAT 타입 1/2/3 또는 Open/Moderate/Strict는 표준 용어가 아니라 제조사 표기입니다.
분류가 나온 배경과 바뀐 이유
RFC 3489(2003년 3월)의 제목은 "STUN - Simple Traversal of User Datagram Protocol (UDP) Through Network Address Translators (NATs)"입니다. UDP 패킷이 NAT을 통과해 P2P 연결이 되려면 NAT이 어떻게 동작하는지 알아야 했고, 이 문서가 그 동작을 네 가지로 묶었습니다. 2008년 10월의 RFC 5389는 3489를 대체하면서, 고전 STUN의 NAT 유형 분류 방식에 결함이 있었다고 적습니다. 많은 NAT이 그 정의에 깔끔하게 들어맞지 않았기 때문입니다. 또 STUN 자체가 NAT 통과의 완전한 해법이 아니라 더 큰 해법 속에서 쓰는 도구라고 밝히고, NAT 동작 탐색은 별도의 사용 규격으로 넘겼습니다. 앞서 2007년 RFC 4787(BCP 127)은 UDP 유니캐스트에 대한 NAT 요구 사항을 정하면서 RFC 3489의 용어가 "실제 NAT 동작을 설명하기에 부적절하다"고 평가하고 개별 동작을 기술하는 방식을 택했습니다.
두 분류 체계 대응표
아래 대응은 위키백과(Network address translation)가 RFC 4787 용어로 정리한 내용을 따랐습니다. 실제 장비는 여러 동작을 섞기도 하므로 표의 행이 장비 한 대를 정확히 나타낸다는 보장은 없습니다.
| RFC 3489 분류 | RFC 4787 매핑 | RFC 4787 필터링 | RFC 3489의 서술 요약 |
|---|---|---|---|
| Full Cone | Endpoint-Independent | Endpoint-Independent | 같은 내부 주소·포트는 같은 외부 주소·포트로 매핑되고 어떤 외부 호스트든 그 주소로 보낼 수 있음 |
| Restricted Cone | Endpoint-Independent | Address-Dependent | 내부 호스트가 먼저 패킷을 보낸 적 있는 IP에서 온 패킷만 허용 |
| Port Restricted Cone | Endpoint-Independent | Address and Port-Dependent | IP와 포트 모두 먼저 보낸 적 있는 조합이어야 허용 |
| Symmetric | Address and Port-Dependent | Address-Dependent 또는 Address and Port-Dependent | 목적지(IP·포트)마다 다른 외부 매핑을 사용하고, 패킷을 받은 호스트만 되돌려 보낼 수 있음 |
RFC 4787이 요구하는 방향도 확인할 수 있습니다. REQ-1은 NAT이 Endpoint-Independent 매핑을 가져야(MUST) 한다고 하며, 그렇지 않으면 UDP 릴레이를 써야 하는데 그것이 흔히 비현실적이기 때문이라고 이유를 듭니다. 필터링은 애플리케이션 투명성이 중요하면 Endpoint-Independent 필터링을, 더 엄격한 필터링을 원하면 Address-Dependent 필터링을 권장하며 관리자가 설정할 수 있어도 좋다고 합니다. 매핑 방식은 보안 특성에 차이를 만들지 않는다는 점도 같은 문서가 지적합니다.
콘솔의 NAT 타입 표기는 표준 용어가 아니다
게임 콘솔과 서비스는 NAT 타입 1·2·3 또는 Open·Moderate·Strict처럼 제조사가 정한 표기를 화면에 보여줍니다(어느 기기가 어느 표기를 쓰는지는 기기와 시기에 따라 다를 수 있어 제조사 문서를 확인하세요). 이 표기가 위 RFC의 분류와 일대일로 대응한다고 단정할 근거를 이 글에서는 확인하지 못했습니다. 제조사 공식 문서가 아니라 제3자 설명 글들을 종합하면 타입 1은 사실상 직접 연결에 가까운 개방 상태, 2는 필요한 포트가 열려 있어 대체로 문제없는 상태, 3은 호스팅·음성 채팅 등이 제한되는 상태로 쓰이는 경향이 있습니다. 이는 확인된 사양이 아니라 일반적 설명이므로, 정확한 의미는 해당 제조사의 지원 문서를 확인하세요. 표기와 기술적 NAT 동작은 분리해서 생각하는 것이 안전하며, 콘솔 쪽 설명은 게임 콘솔 NAT 유형 가이드에서 이어 볼 수 있습니다.
실제 사례
사례 1. 분류의 교체: RFC 3489에서 RFC 5389와 4787로
2003년의 4분류는 단순하고 직관적이어서 널리 퍼졌지만, 2007년 RFC 4787이 그 용어를 부적절하다고 평가했고 2008년 RFC 5389가 STUN 규격에서 이 분류 방식을 걷어냈습니다. 그런데도 오늘날 많은 설명 글과 도구가 여전히 4분류를 씁니다. 배울 점은 같은 단어가 서로 다른 시기의 규격에서 나왔고 규격 자체는 이미 대체되었을 수 있다는 것, 그래서 용어를 만날 때 출처를 확인해야 한다는 점입니다.
사례 2. 대칭형 NAT에서 홀 펀칭이 실패하고 중계가 필요해지는 경우
위키백과(NAT traversal)는 STUN과 ICE의 홀 펀칭이 대칭형 NAT에는 릴레이 서버 없이는 실패한다고 설명합니다. 해법으로 TURN이라는 중계 프로토콜이 쓰이며, 모든 데이터를 서버로 중계하면 필요한 대역폭과 지연이 늘어 실시간 음성·영상에 불리하다고도 적습니다. ICE는 STUN과 TURN을 활용해 가장 좋은 경로를 고르는 완전한 NAT 통과 프로토콜로 소개됩니다. 그래서 WebRTC나 VoIP 앱은 먼저 직접 연결을 시도하고 안 될 때 중계로 내려가는 구조를 갖습니다. 직접 연결과 중계 연결의 지연 차이는 환경마다 다르므로 수치로 단정하지 않습니다.
사례 3. 헤어피닝과 포트 보존
RFC 4787은 포트 보존(port preservation, 내부 포트를 외부 포트로 가능한 한 유지)과 포트 중복 사용(port overloading)을 구분해 정의하고, 후자는 금지하며 대부분의 애플리케이션이 실패한다고 경고합니다. 위키백과는 TCP 홀 펀칭이 나가는 TCP에 대해 NAT이 포트를 보존할 때만 동작한다고 설명합니다. 즉 같은 "콘" 계열이라도 포트 선택 방식에 따라 P2P 성공 여부가 달라질 수 있어, 4분류만으로 결과를 예측하기 어렵습니다.
내 환경을 점검하는 방법
- 화상통화·게임 앱이 제공하는 연결 진단을 먼저 확인하고, 표기가 제조사 용어임을 염두에 두세요.
- NAT이 겹쳐 있는지(공유기 뒤에 공유기, 통신사 장비의 NAT) 확인합니다. 겹치면 한쪽 설정만으로 개선되지 않을 수 있습니다.
- 포트포워딩이나 UPnP 사용 여부는 보안과 맞바꾸는 선택입니다. 필요한 포트만 열고 사용하지 않는 규칙은 지우세요(포트포워딩 가이드).
- 통신사 CGNAT 환경이면 공유기 설정만으로 해결되지 않을 수 있으므로 NAT 기초의 확인 방법을 참고하세요.
흔한 오해와 정정
- 오해: 대칭 NAT가 가장 안전하다. 실제: RFC 4787은 매핑 방식이 NAT의 보안 특성에 차이를 만들지 않는다고 정리합니다. 보안은 필터링 쪽에 달려 있습니다.
- 오해: NAT에는 정확히 4종류가 있다. 실제: 4분류는 RFC 3489 당시의 구분이며, 실제 NAT은 매핑·필터링·포트 선택 등이 섞여 있어 개별 동작으로 기술하는 쪽이 정확합니다.
- 오해: 콘솔의 Open/Strict는 RFC의 Full Cone/Symmetric이다. 실제: 제조사 표기이며 공식 대응표는 확인되지 않았습니다.
- 오해: NAT 유형만 좋으면 항상 직접 연결이 된다. 실제: 상대방의 NAT, 방화벽, 포트 선택 방식도 함께 작용합니다.
한계와 더 알아볼 점
여기 표는 위키백과와 RFC 본문에서 확인한 범위에 한정되며, 실제 제품의 동작은 펌웨어와 설정에 따라 달라집니다. 직접 확인하려면 STUN 기반 테스트나 제조사 진단 도구를 쓰되, 결과의 용어가 어느 체계인지 확인하세요. 심화 내용은 RFC 4787 본문과 RFC 5389를 읽어 보시길 권합니다.
게임 콘솔의 NAT 유형 표시가 궁금하다면
PS5나 Xbox에서 표시되는 Open·Moderate·Strict 같은 사용자 친화적 표시가 궁금하다면게임 콘솔 NAT 유형(Open·Moderate·Strict) 이해하고 해결하기를 참고해보세요. 이 페이지는 그 밑바탕이 되는 기술적 분류를 다룹니다.
인터넷전화(VoIP)의 연결 원리도 함께 보면 좋아요
NAT 유형이 통화 연결에 어떻게 영향을 주는지 더 알고 싶다면VoIP(인터넷전화) 기초 개념 알아보기도 확인해보세요.
자주 묻는 질문
지금도 풀콘·심메트릭 분류를 그대로 쓰나요?
이 4가지 분류는 2003년 RFC 3489 문서에서 제시된 것으로, 2007년 RFC 4787이 용어가 부적절하다고 보고 매핑·필터링 동작을 따로 기술하는 방식을 택했으며 RFC 3489는 2008년 RFC 5389로 대체되었습니다. 다만 실무에서 NAT의 개방성을 직관적으로 설명할 때는 지금도 이 고전적 분류가 널리 쓰입니다.
내 네트워크가 어떤 NAT 유형인지 어떻게 확인하나요?
일반 사용자가 정확한 유형을 직접 확인하기는 쉽지 않지만, 게임 콘솔이나 화상통화 앱이 자체적으로 표시해주는 NAT 상태를 참고하거나, 온라인 STUN 테스트 도구를 이용해 대략적인 개방성을 가늠해볼 수 있습니다. 결과의 용어가 RFC 체계인지 제조사 표기인지 구분해서 읽으세요.
RFC 4787에서 가장 중요한 요구는 무엇인가요?
REQ-1이 NAT은 Endpoint-Independent 매핑을 가져야 한다고 요구하는 점이 핵심으로 꼽힙니다. 이 밖에 UDP 매핑 타이머를 2분 미만으로 만료시키지 않을 것(예외 있음), 포트 중복 사용 금지, 헤어피닝 지원 등이 포함됩니다.
STUN과 TURN, ICE는 무엇이 다른가요?
STUN은 자신의 외부 주소·포트를 알아내는 도구(RFC 5389는 이것만으로 NAT 통과 해법은 아니라고 명시), TURN은 직접 연결이 불가능할 때 쓰는 중계 프로토콜, ICE는 STUN과 TURN을 활용해 가장 적합한 경로를 고르는 완전한 NAT 통과 방식입니다.
이중 NAT이면 무조건 연결이 안 되나요?
그렇지 않습니다. 다만 NAT이 겹치면 포트포워딩 같은 설정이 안쪽 장비에만 적용되어 외부에서 도달하지 못하는 경우가 많아 연결이 불리해질 수 있습니다. 실제 영향은 장비와 서비스에 따라 달라집니다.
이 글은 일반 정보이며, 특정 서비스나 장비의 연결 성공을 보증하지 않습니다.