앞에서는 Reverse Proxy가 외부 요청을 받아 내부 서비스로 전달하는 구조를 살펴봤다.
하지만 Reverse Proxy에 요청이 도착하기 전에는 IP 네트워크에서 패킷이 목적지까지 이동하는 과정이 먼저 일어난다.
Client는 목적지 IP가 같은 네트워크에 있는지 판단하고, 다른 네트워크라면 라우팅 테이블에 따라 다음 홉(Next Hop)으로 패킷을 전달한다. 라우터 역시 자신의 라우팅 테이블을 확인하면서 같은 과정을 반복한다.
WireGuard나 NetBird에서 등장하는 CIDR, Routing Peer, Network Resource 같은 개념도 결국 이 IP Routing 구조 위에서 동작한다.
이번 글에서는 그 기반이 되는 IP 주소, 서브넷, CIDR, 기본 게이트웨이와 라우팅을 알아본다.
목차
- IP 주소는 네트워크와 호스트를 식별한다
- Network Prefix와 Host 영역 - 서브넷 마스크와 CIDR
- Prefix Length와 주소 범위
- /24를 실제로 나누어 보기 - 같은 네트워크와 다른 네트워크는 처리 방식이 다르다
- 같은 Subnet에서의 직접 통신
- 다른 Network와 Default Gateway - 라우팅 테이블은 목적지로 가는 경로를 결정한다
- Destination Prefix
- Next Hop
- Network Interface
- Default Route - 여러 Route가 겹치면 Longest Prefix Match를 사용한다
- 가장 구체적인 Route 선택
- VPN Route도 같은 규칙으로 선택된다 - 사설 IPv4 주소와 NAT
- 사설 IPv4 주소 범위
- SNAT
- DNAT
- NAT와 Reverse Proxy의 차이 - 네트워크 분리와 접근 제어는 다른 문제다
- Network Segmentation
- Routing과 Firewall / ACL - 패킷은 라우팅 테이블을 따라 다음 홉으로 이동한다
- Destination IP 확인
- Longest Prefix Match
- Next Hop 결정
- ARP와 Ethernet Frame 전송
1. IP 주소는 네트워크와 호스트를 식별한다
IPv4 주소는 32비트로 구성된다.
보통 사람이 읽기 쉽도록 8비트씩 나누어 10진수로 표현한다.
192.168.10.34
실제 비트로 표현하면 다음과 같다.
192 168 10 34
11000000 10101000 00001010 00100010
하지만 IPv4 주소만으로는 어느 비트까지가 **네트워크 프리픽스(Network Prefix)**이고, 나머지 어느 부분이 호스트 영역인지 알 수 없다.
예를 들어 다음 주소가 있다고 하자.
192.168.10.34/24

/24는 앞의 24bit가 네트워크 프리픽스라는 의미다.
따라서 192.168.10.34/24가 속한 네트워크는 192.168.10.0/24이고, 192.168.10.34는 그 네트워크 안에서 인터페이스에 할당된 하나의 IPv4 주소다.
두 표현은 의미가 다르다.
| 표현 | 의미 |
| 192.168.10.34 | 하나의 인터페이스에 할당될 수 있는 IPv4 주소 |
| 192.168.10.0/24 | 여러 IPv4 주소를 포함하는 네트워크 프리픽스 |
NetBird나 Cloud Network 설정에서 /24, /16 같은 값이 계속 등장하는 이유도 특정 장비 하나가 아니라 주소 범위 전체를 표현해야 하기 때문이다.
2. 서브넷 마스크와 CIDR
네트워크와 호스트 영역을 구분하는 전통적인 방법 중 하나가 서브넷 마스크(Subnet Mask)다.
다음 IPv4 주소를 보자.
| 항목 | 값 |
| IP Address | 192.168.10.34 |
| Subnet Mask | 255.255.255.0 |
Subnet Mask를 이진수로 표현하면 다음과 같다.
255 255 255 0
11111111 11111111 11111111 00000000
앞에서부터 1인 비트가 24개이므로 255.255.255.0은 Prefix Length로 표현하면 /24다.
CIDR(Classless Inter-Domain Routing) 표기에서는 IPv4 주소 뒤에 /24와 같은 Prefix Length를 붙여 네트워크 프리픽스의 길이를 표현한다.
192.168.10.34/24
여기서 /24가 Prefix Length다.
Prefix Length가 길어질수록 주소 범위는 작아진다
IPv4 주소는 전체가 32비트다.
Prefix Length가 길어질수록 네트워크를 구분하는 비트 수가 늘어나고, 호스트 영역으로 사용할 수 있는 비트 수는 줄어든다.
| CIDR | Prefix Bit | Host Bit |
| /8 | 8 bit | 24 bit |
| /16 | 16 bit | 16 bit |
| /24 | 24 bit | 8 bit |
| /32 | 32 bit | 0 bit |
즉 Prefix Length가 길어질수록 Host 영역은 줄어들고, 해당 Prefix가 포함하는 IPv4 주소의 개수도 감소한다.
대표적인 범위를 보면 다음과 같다.
| Prefix | 포함하는 주소 범위 |
| 10.0.0.0/8 | 10.0.0.0 ~ 10.255.255.255 |
| 10.10.0.0/16 | 10.10.0.0 ~ 10.10.255.255 |
| 10.10.10.0/24 | 10.10.10.0 ~ 10.10.10.255 |
| 10.10.10.18/32 | 10.10.10.18 하나 |
/32는 Prefix Length가 32bit이므로 Host 영역이 없다.
따라서 정확히 하나의 IPv4 주소와 일치하며 Host Route처럼 특정 주소 하나를 나타낼 때 사용할 수 있다.
반대로 0.0.0.0/0은 Prefix Length가 0이므로 모든 IPv4 주소와 일치한다.
Routing Table에서는 이를 Default Route로 사용한다.
/24를 실제로 나누어 보면
다음 네트워크를 보자.
192.168.10.0/24
/24는 Host 영역으로 8bit를 사용하므로 총 256개의 IPv4 주소를 포함한다.
일반적인 IPv4 /24 Subnet은 다음과 같이 구성된다.
| 구분 | 주소 |
| Network Address | 192.168.10.0 |
| 일반적인 Host 할당 범위 | 192.168.10.1 ~ 192.168.10.254 |
| Broadcast Address | 192.168.10.255 |
일반적인 /24 Subnet에서는 Network Address와 Broadcast Address를 Host에 할당하지 않으므로 254개의 주소를 Host에 사용할 수 있다.
다만 모든 Prefix를 같은 방식으로 계산해서 사용할 수 있는 것은 아니다.
예를 들어 /31은 Point-to-Point Link에서 두 주소를 모두 사용할 수 있고, /32는 단일 IPv4 주소를 나타내는 용도로 사용된다.
따라서 실제 네트워크에서는 Prefix Length뿐 아니라 해당 Prefix가 어떤 용도로 사용되는지도 함께 봐야 한다.
3. 같은 네트워크와 다른 네트워크는 처리 방식이 다르다
| 장비 | IP 주소 | 네트워크 |
| PC | 192.168.10.10/24 | 192.168.10.0/24 |
| Server | 192.168.10.20/24 | 192.168.10.0/24 |
두 장비의 네트워크 프리픽스가 모두 192.168.10.0/24이므로 PC는 Server가 같은 네트워크에 있다고 판단한다.
같은 네트워크의 장비와 통신할 때는 라우터를 거칠 필요가 없다.
Ethernet 환경에서는 ARP(Address Resolution Protocol)를 이용해 목적지 IPv4 주소에 대응하는 MAC 주소를 확인한다. MAC 주소를 알아낸 뒤에는 해당 MAC 주소를 목적지로 하는 Ethernet Frame을 전송한다.
다른 Network라면
| 장비 | IP 주소 | 네트워크 |
| PC | 192.168.10.10/24 | 192.168.10.0/24 |
| Server | 10.20.0.50/24 | 10.20.0.0/24 |
두 주소는 서로 다른 네트워크에 속한다. PC는 Server에 Ethernet Frame을 직접 전달할 수 없으므로 패킷을 라우터에 전달해야 한다. 이때 기본적으로 사용하는 라우터가 기본 게이트웨이(Default Gateway)다.
| 계층 | 목적지 |
| IP 패킷 | 최종 서버 10.20.0.50 |
| Ethernet Frame | 다음 홉인 기본 게이트웨이의 MAC 주소 |
여기서 중요한 점은 IP 패킷의 최종 목적지가 바뀌지 않는다는 것이다. 목적지 IP는 계속 10.20.0.50이다. 다만 현재 Ethernet 구간에서 Frame을 전달할 다음 홉이 기본 게이트웨이이므로 Ethernet Destination에는 게이트웨이의 MAC 주소가 사용된다.
즉 기본 게이트웨이는 최종 목적지가 아니라 목적지 네트워크로 가기 위한 다음 홉(Next Hop)이다.

4. 라우팅 테이블은 목적지로 가는 경로를 결정한다
Router뿐 아니라 일반적인 PC나 Server도 Routing Table을 가지고 있다.
Linux에서는 다음 명령으로 확인할 수 있다.
ip route
예를 들어 다음과 같은 결과가 있다고 하자.
default via 192.168.10.1 dev eth0
192.168.10.0/24 dev eth0
10.20.0.0/16 via 192.168.10.254 dev eth0
각 Route는 다음과 같이 읽을 수 있다.
| Route | 의미 |
| default via 192.168.10.1 dev eth0 | 다른 더 구체적인 Route와 일치하지 않으면 192.168.10.1을 다음 홉으로 사용 |
| 192.168.10.0/24 dev eth0 | 192.168.10.0/24는 eth0에 직접 연결된 네트워크 |
| 10.20.0.0/16 via 192.168.10.254 dev eth0 | 10.20.0.0/16으로 가는 패킷은 192.168.10.254를 다음 홉으로 사용 |
default는 IPv4에서 0.0.0.0/0에 해당한다. 다른 더 구체적인 Route와 일치하지 않는 목적지에 사용하는 기본 경로다.
따라서 라우팅 테이블은 대략 다음 정보를 가진다.
| 항목 | 의미 |
| Destination Prefix | 어떤 목적지 IP 범위에 적용되는 Route인지 |
| Next Hop | 패킷을 다음으로 전달할 라우터 |
| Network Interface | 패킷을 내보낼 인터페이스 |
| Metric | Route의 비용 또는 우선순위 판단에 사용하는 값 |
패킷을 전송할 때 운영체제는 Destination IP와 라우팅 테이블을 비교해 사용할 Route를 선택한다.
5. 여러 Route가 겹치면 Longest Prefix Match를 사용한다
Routing Table에는 서로 겹치는 Network Prefix가 존재할 수 있다.
예를 들어 다음 Route가 있다고 하자.
| Destination Prefix | Next Hop |
| 0.0.0.0/0 | Gateway A |
| 10.0.0.0/8 | Gateway B |
| 10.20.0.0/16 | Gateway C |
| 10.20.30.0/24 | Gateway D |
목적지가 다음과 같다고 하자.
10.20.30.50
목적지 10.20.30.50은 네 Route에 모두 포함된다. 이때 라우터는 임의의 Route를 선택하지 않고, 일치하는 Route 중 Prefix Length가 가장 긴 Route를 선택한다.
따라서:
/0, /8, /16, /24 가운데 가장 긴 Prefix는 /24이므로 10.20.30.0/24 → Gateway D가 선택된다.
가 선택된다.

이 규칙을 Longest Prefix Match라고 한다.
여러 Route와 일치
↓
가장 긴 Prefix 선택
↓
가장 구체적인 Route 사용
다른 목적지도 확인해보자.
앞서 Routing Table에 다음 Route가 있다고 가정했다.
| Destination Prefix | Next Hop |
| 0.0.0.0/0 | Gateway A |
| 10.0.0.0/8 | Gateway B |
| 10.20.0.0/16 | Gateway C |
| 10.20.30.0/24 | Gateway D |
목적지에 따라 선택되는 Route는 다음과 같다.
| Destination | 일치하는 가장 긴 Prefix | 선택되는 Route |
| 10.20.30.50 | /24 | 10.20.30.0/24 → Gateway D |
| 10.20.50.10 | /16 | 10.20.0.0/16 → Gateway C |
| 8.8.8.8 | /0 | 0.0.0.0/0 → Gateway A |
- 10.20.50.10은 0.0.0.0/0, 10.0.0.0/8, 10.20.0.0/16에 모두 포함된다.
- 하지만 10.20.30.0/24에는 포함되지 않는다.
따라서 일치하는 Route 가운데 Prefix Length가 가장 긴 /16 Route가 선택된다. - 반면 8.8.8.8은 10.0.0.0/8을 비롯한 더 구체적인 Route와 일치하지 않는다.
하지만 0.0.0.0/0은 모든 IPv4 주소와 일치하므로 Default Route인 Gateway A가 선택된다.
이 규칙은 VPN이나 Cloud Network에서 특정 경로가 선택되는 이유를 이해할 때도 중요하다.
예를 들어 다음 두 Route가 동시에 존재한다고 하자.
| Destination Prefix | Next Hop |
| 10.0.0.0/8 | 일반 Gateway |
| 10.10.10.0/24 | VPN |
목적지가 10.10.10.50이라면 두 Route에 모두 일치한다.
하지만 /24가 /8보다 더 구체적인 Prefix이므로 다음 Route가 선택된다.
10.10.10.0/24 → VPN
즉 VPN을 사용한다고 해서 모든 패킷이 VPN으로 전달되는 것은 아니다. Routing Table에 등록된 Prefix와 최장 프리픽스 일치 규칙에 따라 어떤 트래픽이 VPN으로 들어갈지가 결정된다.
6. 사설 IPv4 주소와 NAT
내부 네트워크에서는 다음과 같은 IPv4 주소를 자주 볼 수 있다.
| 사설 IPv4 주소 범위 | CIDR |
| 10.0.0.0 ~ 10.255.255.255 | 10.0.0.0/8 |
| 172.16.0.0 ~ 172.31.255.255 | 172.16.0.0/12 |
| 192.168.0.0 ~ 192.168.255.255 | 192.168.0.0/16 |
RFC 1918은 이 세 주소 범위를 사설 네트워크에서 사용할 수 있도록 예약한다.
이 주소들은 인터넷 전체에서 고유하지 않다.
예를 들어 서로 관계없는 두 조직이 모두 192.168.0.0/24를 내부 네트워크로 사용할 수 있다.
따라서 내부 장비가 인터넷에 접근할 때는 사설 주소와 외부에서 사용할 수 있는 주소 사이를 변환하는 과정이 필요할 수 있다.
이때 사용하는 것이 NAT(Network Address Translation)다.
SNAT는 Source Address를 변경한다
내부 Client가 인터넷의 Server에 요청한다고 하자.
NAT가 적용되기 전과 후의 패킷을 비교하면 다음과 같다.
| 상태 | Source | Destination |
| NAT 적용 전 | 192.168.10.10 | External Server |
| SNAT 적용 후 | Public IP | External Server |
Source Address가 변경되었기 때문에 이를 SNAT(Source NAT)라고 한다.
즉 내부에서는 192.168.10.10이 보이지만, 외부 Server에서는 NAT 장비가 사용하는 Public IP에서 요청이 온 것처럼 보일 수 있다.

DNAT는 Destination Address를 변경한다
반대로 외부에서 특정 Public IP와 Port로 들어온 Traffic을 내부 Server로 전달하면서 Destination Address를 변경할 수도 있다.
예를 들어 외부 요청이 다음 주소로 들어온다고 하자.
Public IP:443
이를 내부의 192.168.10.20:443으로 전달할 수 있다.
| 구분 | 변경하는 주소 | 대표적인 용도 |
| SNAT | Source Address | 내부 Client가 외부 Network에 접근 |
| DNAT | Destination Address | 외부 Traffic을 내부 Server로 전달 |

NAT와 Reverse Proxy는 역할이 다르다
NAT와 Reverse Proxy는 모두 Traffic의 중간에 위치할 수 있지만 처리하는 대상이 다르다.
| 구분 | NAT | Reverse Proxy |
| 주요 대상 | IP 주소와 Port | HTTP 요청 |
| 대표 동작 | SNAT, DNAT | Host/Path 기반 요청 전달 |
| Source IP | 주소 자체가 변경될 수 있음 | 자신이 받은 Client 정보를 Header로 전달 가능 |
| 대표 정보 | IP, Port | HTTP Header, Host, Path |
이 차이는 Client IP를 추적할 때 중요하다.
Reverse Proxy는 자신에게 도착한 Client IP를 X-Forwarded-For 같은 Header에 기록해서 Backend로 전달할 수 있다.
하지만 Reverse Proxy에 도착하기 전에 SNAT가 발생했다면 상황이 다르다.
SNAT → Reverse Proxy
이 경우 Reverse Proxy가 받은 Source IP 자체가 이미 변경되어 있다.
따라서 X-Forwarded-For를 사용하더라도 NAT 이전의 원래 Source IP를 복원할 수 없다.
이 차이가 다음 글에서 다룰 NetBird의 Masquerade와 연결된다.
7. 네트워크 분리와 접근 제어는 다른 문제다
실제 인프라에서는 시스템의 역할이나 환경에 따라 네트워크를 여러 주소 대역으로 나누기도 한다.
예를 들어 다음과 같이 구성할 수 있다.
| 네트워크 | 역할 예시 |
| 10.10.0.0/16 | 개발 환경 |
| 10.20.0.0/16 | 운영 환경 |
| 192.168.10.0/24 | 사용자 네트워크 |
| 192.168.20.0/24 | 관리 네트워크 |
이렇게 주소 공간을 나누면 네트워크의 역할을 구분하기 쉬워지고 각각 다른 Routing 정책을 적용할 수도 있다.
하지만 CIDR을 서로 다르게 나눴다는 사실만으로 통신이 차단되는 것은 아니다.
예를 들어 10.10.0.0/16과 10.20.0.0/16이 서로 다른 네트워크라고 하자.
두 네트워크 사이에 라우터가 있고 적절한 Route가 존재하면 패킷은 서로 이동할 수 있다.
그리고 Firewall이나 ACL이 해당 Traffic을 허용한다면 실제 통신도 가능하다.
따라서 다음 두 개념을 구분해야 한다.
| 개념 | 역할 |
| Network Segmentation | 주소 공간과 라우팅 영역을 분리 |
| Access Control | 어떤 Traffic의 통과를 허용하거나 차단할지 결정 |
예를 들어 네트워크를 나눈 뒤 다음과 같은 정책을 추가할 수 있다.
| Source | Destination | 정책 |
| 개발 네트워크 | 운영 DB | 차단 |
| 관리 네트워크 | 운영 Server | 허용 |
| 사용자 네트워크 | 관리 네트워크 | 차단 |
이때 실제 보안 경계를 만드는 것은 단순한 CIDR 구분이 아니라 Routing과 Access Control의 조합이다.
네트워크 분리 + Routing 정책 + Firewall/ACL/Security Group = 실제 통신 경계
즉 10.10.0.0/16과 10.20.0.0/16처럼 주소 대역이 다르다는 사실 자체가 보안 경계인 것은 아니다.
패킷이 이동할 수 있는 Route가 존재하는지, 그리고 그 Traffic을 허용하는 정책이 있는지를 함께 확인해야 한다.
8. 패킷은 라우팅 테이블을 따라 다음 홉으로 이동한다
지금까지 살펴본 내용을 하나의 패킷 흐름으로 연결해보자.
다음 환경이 있다고 하자.
| 구성 | 주소 |
| Client | 192.168.10.20/24 |
| Default Gateway | 192.168.10.1 |
| Destination Server | 10.20.30.50 |
Client의 네트워크는 192.168.10.0/24다.
목적지 10.20.30.50은 이 범위에 포함되지 않으므로 Client는 목적지가 다른 네트워크에 있다고 판단한다.
Client의 Routing Table에 다음 Route가 있다고 하자.
10.20.0.0/16 via 192.168.10.254
0.0.0.0/0 via 192.168.10.1
목적지 10.20.30.50은 두 Route와 모두 일치한다.
- 10.20.0.0/16
- 0.0.0.0/0
최장 프리픽스 일치 규칙에 따라 더 구체적인 /16 Route가 선택된다.
따라서 다음 홉은 192.168.10.254가 된다.
Client는 패킷의 최종 Destination IP를 바꾸지 않는다.
| 항목 | 값 |
| IP Destination | 10.20.30.50 |
| Next Hop | 192.168.10.254 |
| Ethernet Destination | 192.168.10.254의 MAC 주소 |
Client는 ARP를 이용해 다음 홉인 192.168.10.254의 MAC 주소를 확인한 뒤 Frame을 전송한다.
라우터가 패킷을 받으면 다시 자신의 Routing Table을 확인한다.
그리고 같은 과정을 반복해 다음 홉을 결정한다.
이 과정은 목적지 네트워크에 도달할 때까지 계속된다.

전체 과정을 정리하면 다음과 같다.
- Destination IP를 확인한다.
- 목적지가 같은 Subnet인지 확인한다.
- 다른 Network라면 Routing Table을 검색한다.
- 일치하는 Route 중 가장 긴 Prefix를 선택한다.
- Next Hop과 Network Interface를 결정한다.
- Ethernet 환경에서는 ARP로 다음 홉의 MAC 주소를 확인한다.
- Frame을 전송한다.
- Router는 다시 자신의 Routing Table을 확인한다.
네트워크 설정도 같은 방식으로 읽을 수 있다.
| 표현 | 의미 |
| 10.20.30.15/24 | Host 10.20.30.15가 10.20.30.0/24 네트워크에 속함 |
| 10.20.30.0/24 via 10.0.0.1 | 10.20.30.0/24로 향하는 패킷을 10.0.0.1에 전달 |
| default via 192.168.1.1 | 더 구체적인 Route가 없으면 192.168.1.1에 전달 |
결국 IP Routing은 다음 세 가지를 반복해서 판단하는 과정이다.
목적지는 어디인가 → 어떤 Route가 가장 구체적으로 일치하는가 → 다음 홉은 어디인가
이 구조를 이해하면 다음 글에서 다룰 NetBird Routing Peer도 같은 방식으로 읽을 수 있다.
예를 들어 10.20.0.0/24를 특정 Routing Peer가 담당한다면, 해당 Prefix로 향하는 패킷은 그 Peer를 통해 사설 네트워크로 전달된다.
NetBird가 별도의 새로운 IP Routing 원리를 사용하는 것은 아니다.
기존 IP Routing 위에 WireGuard 기반 Overlay Network를 구성하고, 특정 네트워크 Prefix로 향하는 패킷을 Routing Peer를 통해 전달한다.
다음 글에서는 이 구조를 기반으로 VPN, WireGuard, Overlay Network, NetBird Routing Peer와 Masquerade를 살펴본다.
'네트워크' 카테고리의 다른 글
| VPN과 Overlay Network — WireGuard와 NetBird (0) | 2026.09.25 |
|---|---|
| Reverse Proxy — 구조와 운영 시 주의할 점 (0) | 2026.09.25 |
| 대용량 파일 멀티파트 업로드, 정말 빠를까? (2) | 2026.04.17 |
| 신뢰성을 위한 Timeout 처리와 멱등성 설계 전략 (1) | 2025.12.02 |