NAT와 방화벽 (1) - NAT의 탄생과 주소 변환의 원리 - soo:bak

작성일 : 2026년 01월 20일

왜 사설 IP와 NAT가 필요했는가

IP 주소에서 32비트 IPv4 주소 체계를 살펴보았습니다.

32비트는 약 43억 개의 주소를 제공합니다. 1981년 IPv4가 설계될 당시에는 인터넷에 연결된 컴퓨터가 수백 대에 불과했으므로 충분해 보였습니다.

하지만 1990년대에 상황이 바뀌었습니다. PC가 보급되고, 웹이 등장하면서 인터넷에 연결되는 장비 수가 급격히 증가했습니다. IPv4 주소가 부족해질 것이 명확해졌습니다.

클래스 기반 할당의 비효율

주소 부족의 원인 중 하나는 할당 방식 자체에 있었습니다. 초기 IP 주소는 클래스(Class) 단위로 할당되었습니다.

클래스란 IP 주소 범위를 네트워크 규모에 따라 미리 나누어 놓은 등급입니다. 총 5개 클래스가 있으며, 이 중 호스트 주소 할당에 사용되는 것은 A, B, C 세 가지입니다.

클래스 A: 0.0.0.0 ~ 127.255.255.255
          첫 8비트가 네트워크, 나머지 24비트가 호스트
          약 1,677만 개의 호스트 주소 — 대규모 기관용

클래스 B: 128.0.0.0 ~ 191.255.255.255
          첫 16비트가 네트워크, 나머지 16비트가 호스트
          약 65,534개의 호스트 주소 — 중규모 기관용

클래스 C: 192.0.0.0 ~ 223.255.255.255
          첫 24비트가 네트워크, 나머지 8비트가 호스트
          254개의 호스트 주소 — 소규모 기관용

클래스 D: 224.0.0.0 ~ 239.255.255.255 — 멀티캐스트 전용
클래스 E: 240.0.0.0 ~ 255.255.255.255 — 실험/예약 용도

1000개의 호스트가 필요한 조직을 예로 들어 보겠습니다.

클래스 C(254개)로는 부족합니다.

클래스 C 여러 개를 따로 받을 수도 있었지만, 라우팅 테이블이 커지고 관리가 복잡해지는 문제가 있었기 때문에 실제로는 한 단계 위인 클래스 B(65,534개)를 통째로 받는 경우가 많았습니다.

결과적으로 64,000개 이상의 주소가 사용되지 않은 채 낭비됩니다. 이런 낭비가 전 세계적으로 누적되었습니다.

CIDR의 등장

이 낭비를 줄이기 위해, 1993년에 CIDR(Classless Inter-Domain Routing)이 도입되었습니다.

클래스 구분을 없애고, 비트 단위로 네트워크 크기를 지정합니다.

서브넷에서 설명한 것처럼:

168.1.0/24  → 256개 주소
168.1.0/25  → 128개 주소
168.1.0/26  → 64개 주소

CIDR 덕분에 필요한 만큼만 할당할 수 있게 되어 주소 낭비가 크게 줄었습니다.

하지만 할당 효율을 개선해도 근본적인 문제는 남아 있습니다.

43억 개라는 숫자는 여전히 유한하며, 전 세계 인구보다도 적습니다. 근본적으로 다른 접근이 필요했습니다.

사설 IP 주소 대역

1996년, RFC 1918이 사설 IP 주소(Private IP Address)를 정의했습니다.

인터넷에서 사용하지 않기로 약속한 주소 대역입니다.

10.0.0.0/8      → 10.0.0.0 ~ 10.255.255.255
                  약 1,677만 개

172.16.0.0/12   → 172.16.0.0 ~ 172.31.255.255
                  약 104만 개

192.168.0.0/16  → 192.168.0.0 ~ 192.168.255.255
                  약 65,536개

이 대역들은 당시 사용되지 않던 주소 블록이었기에, 기존 인터넷과 충돌하지 않으면서 충분히 큰 공간을 확보할 수 있었습니다.

사설 IP의 핵심 특성:

인터넷 라우터는 이 주소 대역을 라우팅하지 않도록 설정되어 있습니다. 사설 IP를 목적지로 하는 패킷은 인터넷에서 전달되지 않습니다.
라우팅되지 않으므로, 서로 다른 조직이 같은 사설 주소를 중복 사용해도 충돌하지 않습니다.
내부 네트워크에서 자유롭게 사용합니다.

전 세계 수백만 개의 가정에서 192.168.1.1을 공유기 주소로 사용합니다.

사설 주소는 인터넷에서 라우팅되지 않으므로, 서로 다른 가정이 같은 주소를 사용해도 충돌하지 않습니다.

NAT의 기본 개념

사설 IP 덕분에 내부 네트워크를 자유롭게 구성할 수 있게 되었지만, 그것만으로는 인터넷에 접속할 수 없습니다.

인터넷 라우터가 사설 주소를 라우팅하지 않기 때문입니다.

NAT(Network Address Translation)는 사설 IP를 공인 IP로 변환하여 이 문제를 해결합니다.

내부 네트워크                NAT                  인터넷

168.1.10 ───┐
168.1.20 ───┼──► [주소 변환] ──────► 203.0.113.5
168.1.30 ───┘    (사설 → 공인)       (공인 IP)

내부 장비가 여러 대여도 NAT를 거치면 모두 같은 공인 IP로 변환됩니다. 외부에서 보면 하나의 장비처럼 보입니다.

NAT는 패킷의 IP 주소를 변경합니다.

나가는 패킷: 출발지 주소를 사설 → 공인으로 변환
들어오는 패킷: 목적지 주소를 공인 → 사설로 변환

NAT 테이블: 변환 기록

내부 장비가 외부로 패킷을 보내면, 응답은 공인 IP로 돌아옵니다.

여러 내부 장비가 하나의 공인 IP를 공유하므로, NAT는 응답을 올바른 내부 장비로 전달하기 위해 변환 내역을 NAT 테이블에 기록합니다.

이때 각 연결을 구분하기 위해 포트 번호도 함께 기록하는데, 이 방식의 자세한 원리는 뒤에서 PAT/NAPT를 다룰 때 설명합니다.

예를 들어, 내부 장비 192.168.1.10이 외부 웹 서버에 접속하는 과정을 따라가 보겠습니다.

1. 내부 → NAT
   192.168.1.10:12345 ──────► NAT
   출발지: 192.168.1.10:12345

2. NAT가 출발지를 공인 주소로 변환하고, 테이블에 기록
   NAT ──────► 외부 서버
   출발지: 203.0.113.5:40001  (변환됨)

   NAT 테이블:
   ┌──────────────────────┬──────────────────────┐
   │   내부 주소:포트     │   외부 주소:포트     │
   ├──────────────────────┼──────────────────────┤
   │ 192.168.1.10:12345   │ 203.0.113.5:40001    │
   └──────────────────────┴──────────────────────┘

3. 외부 서버가 응답
   외부 서버 ──────► NAT
   목적지: 203.0.113.5:40001

4. NAT가 테이블을 조회하여 원래 내부 주소로 복원
   NAT ──────► 192.168.1.10:12345
   목적지: 192.168.1.10:12345  (복원됨)

내부 장비가 여러 대이면, 테이블에 항목이 추가됩니다.

NAT 테이블:
┌──────────────────────┬──────────────────────┐
│   내부 주소:포트     │   외부 주소:포트     │
├──────────────────────┼──────────────────────┤
│ 192.168.1.10:12345   │ 203.0.113.5:40001    │
│ 192.168.1.11:54321   │ 203.0.113.5:40002    │
│ 192.168.1.10:12346   │ 203.0.113.5:40003    │
└──────────────────────┴──────────────────────┘

같은 장비(192.168.1.10)라도 포트가 다르면 별도 항목으로 기록됩니다. NAT는 이 테이블을 통해 어떤 응답을 어떤 내부 장비로 돌려보낼지 판단합니다.

테이블 항목은 일정 시간 동안 유지되다가, TCP 연결이 종료되거나 타임아웃이 지나면 삭제됩니다.

Outbound vs Inbound 흐름

앞에서 살펴본 NAT 테이블의 변환 과정을 방향별로 정리하면:

Outbound(내부 → 외부): 내부 호스트가 패킷을 보내면 NAT가 출발지를 변환하고 테이블에 기록합니다.
Inbound(외부 → 내부): 응답이 돌아오면 NAT가 테이블을 조회하여 원래 내부 호스트로 전달합니다.

여기서 중요한 점은, 내부에서 먼저 연결을 시작해야 한다는 것입니다. NAT 테이블에 매핑이 없으면 외부에서 들어오는 패킷을 어느 내부 장비로 전달해야 할지 판단할 수 없기 때문입니다.

즉, NAT 환경에서는 Outbound 연결이 있어야만 그에 대한 Inbound 응답이 가능합니다. 외부에서 먼저 시작하는 연결은 기본적으로 차단됩니다.

NAT의 유형

지금까지 살펴본 예시에서는 여러 사설 IP가 하나의 공인 IP를 공유했습니다.

하지만 이것은 NAT의 여러 방식 중 하나입니다. NAT는 사설 IP와 공인 IP를 어떤 비율로 대응시키는지에 따라 구분됩니다.

Static NAT (1:1 NAT)

하나의 사설 IP를 하나의 공인 IP에 고정 매핑합니다.

192.168.1.10 ←──────────────→ 203.0.113.10
192.168.1.11 ←──────────────→ 203.0.113.11

매핑이 고정되어 있으므로, 외부에서 203.0.113.10으로 접속하면 항상 192.168.1.10에 도달합니다.

내부에 웹 서버를 운영하는 경우를 생각해 보겠습니다. 외부 사용자는 이 서버의 공인 IP를 알아야 접속할 수 있습니다.

그런데 매핑이 동적이면, 같은 내부 서버라도 연결을 맺을 때마다 다른 공인 IP가 배정될 수 있습니다.

오늘은 203.0.113.10이었지만 내일은 203.0.113.11일 수 있다는 뜻입니다.

외부 사용자 입장에서는 서버의 주소가 계속 바뀌므로 안정적으로 접근할 수 없습니다.

Static NAT는 이 문제를 해결합니다. 192.168.1.10은 항상 203.0.113.10에 대응되므로, 외부 사용자는 203.0.113.10만 기억하면 됩니다.

다만 공인 IP가 사설 IP 수만큼 필요하므로 주소 절약 효과는 없습니다.

Dynamic NAT (N:M NAT)

사설 IP 풀을 공인 IP 풀에 동적으로 매핑합니다.

사설 IP 풀                공인 IP 풀
192.168.1.10 ─┐           ┌─ 203.0.113.10
192.168.1.11 ─┼──[동적]──┼─ 203.0.113.11
192.168.1.12 ─┤           ├─ 203.0.113.12
...           ─┘           └─ ...

Static NAT는 내부 장비마다 공인 IP를 하나씩 고정해야 했습니다. 내부 장비가 100대이면 공인 IP도 100개가 필요합니다.

Dynamic NAT는 연결이 필요한 순간에만 공인 IP 풀에서 하나를 빌려 쓰고, 연결이 끝나면 반환합니다.

100대의 내부 장비가 동시에 모두 접속하지 않는다면, 공인 IP를 100개보다 적게 확보해도 됩니다.

다만 공인 IP가 모두 사용 중이면 새 연결이 불가능합니다.

PAT / NAPT (N:1 NAT)

Dynamic NAT는 공인 IP 수를 줄였지만, 여전히 동시에 접속하는 장비 수만큼 공인 IP가 필요합니다. 내부 장비 50대가 동시에 접속하면 공인 IP도 50개가 필요합니다.

PAT(Port Address Translation) 또는 NAPT(Network Address Port Translation)는 이 한계를 해결합니다. 공인 IP는 하나만 사용하고, 각 연결을 포트 번호로 구분합니다.

168.1.10:12345 ──► 203.0.113.5:40001
168.1.11:54321 ──► 203.0.113.5:40002
168.1.12:11111 ──► 203.0.113.5:40003

모두 같은 공인 IP, 다른 포트

포트 번호는 0~65,535 범위이지만, 일부가 예약되어 있으므로 NAT에 사용 가능한 포트는 약 6만 개입니다. 하나의 공인 IP로 동시에 수만 개의 연결을 지원할 수 있습니다.

NAT와 5-tuple의 관계

PAT가 포트 번호로 연결을 구분할 수 있는 이유는 5-tuple에 있습니다.

소켓과 전송 계층에서 네트워크 연결은 5-tuple로 식별된다고 했습니다.

(프로토콜, 출발지 IP, 출발지 포트, 목적지 IP, 목적지 포트)

NAT는 이 5-tuple을 변환합니다.

원본 패킷 (내부):
(TCP, 192.168.1.10, 12345, 93.184.216.34, 80)

변환 후 (외부):
(TCP, 203.0.113.5, 40001, 93.184.216.34, 80)

만약 두 내부 장비의 패킷이 변환 후 같은 5-tuple을 갖게 되면, 응답이 돌아왔을 때 어느 장비의 패킷인지 구분할 수 없습니다.

내부 장비 A: (TCP, 192.168.1.10, 12345, 93.184.216.34, 80)
내부 장비 B: (TCP, 192.168.1.11, 54321, 93.184.216.34, 80)

만약 둘 다 같은 포트 40001로 변환된다면:
변환 후 A: (TCP, 203.0.113.5, 40001, 93.184.216.34, 80)
변환 후 B: (TCP, 203.0.113.5, 40001, 93.184.216.34, 80)  ← 동일!
→ 응답이 돌아오면 A와 B를 구분할 수 없음

이 때문에 NAT는 변환 후에도 5-tuple이 고유하도록, 같은 포트를 두 연결에 할당하지 않습니다.

이처럼 NAT 테이블은 연결 상태를 추적하는 역할도 하므로, 연결 추적(Connection Tracking) 테이블이라고도 합니다.

이 연결 추적 개념은 Part 2에서 다루는 상태 기반 방화벽의 핵심 원리이기도 합니다.

NAT의 이점

NAT의 본래 목적은 주소 절약이지만, 그 외에 부수적인 이점도 있습니다.

주소 절약 (본래 목적):

하나의 공인 IP로 수천 개의 내부 장비 지원
1990년대에 수년 내 고갈이 예측되었던 IPv4 주소를 2020년대까지 사용 가능하게 함

보안(부수 효과):

내부 네트워크 구조가 외부에 노출되지 않음
외부에서 내부로 직접 연결 불가 (NAT 테이블에 매핑이 없으면 패킷이 전달되지 않음)

유연성:

내부 주소 체계를 자유롭게 설계
ISP를 변경해도 내부 주소 변경 불필요

NAT의 한계

이점이 있는 만큼 대가도 있습니다.

End-to-End 원칙 위반:

인터넷의 원래 설계 원칙은, 네트워크 중간 장비는 패킷을 전달만 하고 통신의 양 끝(호스트)이 직접 상대방과 통신하는 것이었습니다(End-to-End 원칙).

NAT는 중간에서 주소를 변환하므로 이 원칙을 깨뜨립니다. NAT 테이블에 매핑이 없으면 외부에서 먼저 연결을 시작할 수 없기 때문입니다.

내부에서 서버를 운영하려면, 특정 포트로 들어오는 외부 트래픽을 내부 장비로 수동 매핑하는 포트 포워딩(Port Forwarding) 같은 추가 설정이 필요합니다. 포트 포워딩의 구체적인 원리는 Part 3에서 다룹니다.

P2P 애플리케이션도 같은 문제를 겪습니다. P2P는 두 사용자가 서로에게 직접 연결하는 방식인데, 양쪽 모두 NAT 뒤에 있으면 어느 쪽도 상대방에게 먼저 연결을 시작할 수 없습니다.

프로토콜 호환성:

패킷은 크게 헤더(출발지/목적지 주소 등 제어 정보)와 페이로드(실제 데이터 본문)로 나뉩니다. NAT는 헤더의 IP 주소만 변환합니다.

그런데 FTP, SIP, H.323 같은 일부 프로토콜은 페이로드 안에도 IP 주소를 포함합니다.

예를 들어 FTP에서 파일을 전송할 때, 클라이언트가 “내 주소는 192.168.1.10이니 여기로 데이터를 보내줘”라는 메시지를 페이로드에 담아 보냅니다.

NAT가 헤더의 주소는 공인 IP로 변환하지만, 페이로드 안의 192.168.1.10은 그대로 남습니다.

서버가 이 사설 주소로 데이터를 보내려 하면 인터넷에서 라우팅되지 않아 통신이 실패합니다.

이를 해결하기 위해 ALG(Application Layer Gateway)가 페이로드까지 검사하여 주소를 수정합니다.

성능 부담:

NAT는 단순히 패킷을 전달하는 것이 아니라, 모든 패킷의 헤더를 검사하고 주소를 변환한 뒤 테이블을 갱신해야 합니다.

가정용 공유기에서는 문제가 되지 않지만, 수만 명이 동시에 접속하는 대규모 환경에서는 이 처리 과정이 병목이 될 수 있습니다.

마무리

클래스 기반 할당의 낭비 → CIDR로 개선, 그래도 유한한 43억 개
사설 IP + NAT로 하나의 공인 IP를 수천 대가 공유
PAT/NAPT가 포트 번호로 연결을 구분하는 가장 보편적 방식
NAT는 주소를 절약하지만, End-to-End 원칙을 깨뜨림

NAT는 IPv4 주소 고갈에 대한 임시 해결책으로 설계되었습니다. 근본적인 해결책은 128비트 주소를 사용하는 IPv6입니다.

IPv6의 주소 공간은 모든 장비에 고유한 공인 주소를 부여할 수 있을 만큼 넓으므로, NAT 없이도 End-to-End 통신이 가능합니다.

하지만 2020년대에도 전 세계 인터넷 트래픽의 상당 부분이 여전히 IPv4이며, NAT는 계속 사용되고 있습니다.

NAT가 외부에서 내부로의 연결을 차단한다고 했습니다. 이 특성은 보안 측면에서 유용하지만, NAT 자체가 방화벽은 아닙니다.

방화벽은 관리자가 정한 규칙에 따라 어떤 패킷을 허용하고 어떤 패킷을 차단할지 판단하는 장치입니다.

다만 NAT의 연결 추적 테이블은 방화벽에서도 핵심적으로 활용됩니다.

Part 2에서는 방화벽의 원리와 상태 추적을 살펴봅니다. 패킷 필터링, 상태 기반 검사, 그리고 NAT와 방화벽이 어떻게 결합되는지 알아봅니다.

Part 3에서는 NAT 트래버설과 P2P 통신의 어려움을 다룹니다.

관련 글

시리즈

NAT와 방화벽 (1) - NAT의 탄생과 주소 변환의 원리 (현재 글)
NAT와 방화벽 (2) - 방화벽의 원리와 상태 추적
NAT와 방화벽 (3) - NAT 트래버설과 P2P 통신