infra
Platform

모듈 맵

[Network] 서브넷 마스크 계산과 IP 대역 설계 실무

0 / 35 완료

펼치기
0 / 35 완료0%

네트워크 트러블슈팅 · 02 / 35

[Network] 서브넷 마스크 계산과 IP 대역 설계 실무

공인/사설 IP 대역의 차이를 이해하고, CIDR 표기법으로 서브넷을 계산하여 네트워크를 설계하는 방법을 배웁니다.

🚨INCIDENT ALERT
HIGH

새 서버를 같은 대역에 넣었는데 일부 서버와만 통신이 됩니다. 알고 보니 한쪽은 /24, 다른 쪽은 /25로 설정되어 서로 같은 네트워크라고 판단하는 범위가 달랐습니다.

CIDR 계산을 못 하면 라우팅과 방화벽 규칙이 전부 추측이 됩니다. IP 범위를 숫자로 읽어야 합니다.

IP 주소 체계와 서브네팅 (CIDR)

IP 주소를 모르면 클라우드 VPC 설계도, 방화벽 규칙 작성도, 서버 간 통신 구성도 할 수 없습니다. 인프라 엔지니어가 반드시 체득해야 할 기초 중의 기초입니다.

이번 챕터에서 배울 것
  • 1IPv4 주소의 32비트 구조에서 네트워크/호스트 부분을 구분할 수 있다
  • 2서브넷 마스크와 CIDR(/) 표기법으로 네트워크 범위를 표현할 수 있다
  • 3호스트 수 계산 공식 2^(32-CIDR) - 2로 사용 가능 호스트 수를 계산할 수 있다
  • 4공인 IP와 사설 IP 3대역(10.x, 172.16~31.x, 192.168.x)을 구별할 수 있다
  • 5ip addr / ipcalc 명령어로 서버 IP와 서브넷 정보를 확인할 수 있다
  • 6VPC 서브넷 설계 원칙에 따라 IP 대역을 분할할 수 있다
실습 환경 준비
현재 서버의 IP 주소와 CIDR 확인
ip addr show
ipcalc 설치 (서브넷 계산 도구)
sudo apt-get install -y ipcalc || sudo yum install -y ipcalc
Python3 ipaddress 모듈 사용 가능 여부 확인
python3 -c 'import ipaddress; print(ipaddress.ip_network("10.0.0.0/24"))'
라우팅 테이블 확인 (서브넷 간 통신 경로)
ip route show
💡개념

IP 주소의 구조

AWS에서 VPC를 만들 때 10.0.0.0/16을 입력하거나, 방화벽 규칙에 192.168.1.0/24를 허용 대상으로 추가할 때 — 이 숫자들이 어떤 범위를 의미하는지 직관적으로 이해해야 합니다. 그렇지 않으면 VPC 설계를 잘못 해서 나중에 서브넷을 추가할 수 없거나, 방화벽 규칙이 의도와 다르게 적용되는 상황이 생깁니다.

IP 주소의 구조 — 32비트 IPv4는 네트워크부와 호스트부로 나뉜다. 서브넷 마스크(예: 255.255.255.0 = /24)가 어디까지가 네트워크부인지 경계를 정하고, 같은 네트워크부를 가진 주소끼리 라우터 없이 직접 통신한다. 호스트부가 모두 0이면 네트워크 주소, 모두 1이면 브로드캐스트 주소로 예약되어 실제 호스트 할당에서 빠진다확대

IPv4 주소는 32비트 숫자를 8비트씩 4개로 나누어 표현합니다. 사람이 읽기 편하도록 각 8비트를 10진수로 변환해 점(.)으로 구분합니다.

192    .  168   .   1   .  25
11000000.10101000.00000001.00011001
 8비트     8비트    8비트    8비트
                              = 총 32비트

각 옥텟(8비트)은 0~255 범위의 값을 가집니다.

  • 최솟값: 0.0.0.0
  • 최댓값: 255.255.255.255

IP 주소는 두 부분으로 구성됩니다 — 앞부분은 네트워크를, 뒷부분은 개별 호스트를 식별합니다:

[  네트워크 부분  |  호스트 부분  ]
  192.168.1        .25
  ↑ 같은 네트워크의 모든 장치가 공유    ↑ 해당 네트워크 내 개별 주소

네트워크 부분이 같은 장치들은 **같은 네트워크(서브넷)**에 속합니다. 네트워크 부분이 다르면 라우터를 통해 통신해야 합니다.


서브넷 마스크란?

서브넷 마스크는 IP 주소에서 네트워크 부분과 호스트 부분을 구분하는 32비트 값입니다.

서브넷 마스크 비트 분해 — 192.168.1.25와 255.255.255.0을 AND 연산해 네트워크 주소를 얻는 과정, /24 경계로 네트워크·호스트 부분 구분확대

마스크 1인 비트 = 네트워크 부분 (고정) 마스크 0인 비트 = 호스트 부분 (변경 가능)


💡개념

CIDR 표기법 — 슬래시(/) 표현

AWS 콘솔에서 보안 그룹 규칙을 설정하다가 0.0.0.0/010.0.0.0/8의 차이를 몰라서 전체 허용을 하는 실수가 생깁니다. 방화벽 담당자에게 허용 범위를 전달할 때도 CIDR 표기 없이 "10.0.1 대역 전체요"라고 하면 오해가 생깁니다. /숫자가 어떤 범위를 의미하는지 숫자만 보고 바로 파악할 수 있어야 네트워크 설정이 의도대로 적용됩니다.

CIDR(Classless Inter-Domain Routing)은 서브넷 마스크를 /숫자 형태로 간결하게 표현합니다. 숫자는 네트워크 비트 수(1의 개수)를 의미합니다.

CIDR 표기법 — 슬래시(/)로 서브넷 크기를 표현한다. 192.168.1.0/24에서 /24는 프리픽스 길이(네트워크부 비트 수)다. /8=255.0.0.0(약 1677만 호스트, 대규모 사설망)·/16=255.255.0.0(6.5만, 중규모)·/24=255.255.255.0(254, 소규모 서브넷)·/30=255.255.255.252(2개, P2P 링크)·/32=단일 호스트. 프리픽스 숫자가 클수록 서브넷이 작아지고 사용 가능 호스트 수가 줄어든다확대

전통 표기:  192.168.1.0 / 255.255.255.0
CIDR 표기:  192.168.1.0/24
                        ↑ 앞 24비트가 네트워크 부분

자주 사용하는 CIDR 정리: 실무에서 자주 쓰는 CIDR 표기와 호스트 수 관계입니다.

CIDR서브넷 마스크호스트 수용도
/8255.0.0.016,777,214대형 사설망 (10.0.0.0/8)
/16255.255.0.065,534클라우드 VPC 전체
/24255.255.255.0254일반 서브넷 (가장 흔함)
/25255.255.255.128126서브넷 절반 분할
/26255.255.255.19262소규모 서비스 서브넷
/27255.255.255.22430작은 팀/서비스용
/28255.255.255.24014관리용 소형 서브넷
/30255.255.255.2522포인트-투-포인트 링크
/32255.255.255.2551단일 호스트 지정

호스트 수 계산 공식 — CIDR 숫자로 사용 가능한 호스트 수를 계산합니다:

사용 가능한 호스트 수 = 2^(32 - CIDR 숫자) - 2
예) /24 → 2^8 - 2 = 256 - 2 = 254개
예) /28 → 2^4 - 2 = 16 - 2 = 14개

-2 이유: 네트워크 주소(첫 번째)와 브로드캐스트 주소(마지막)는 호스트에 할당 불가

💡개념

두 IP가 같은 망인지 커널이 판별하는 법 — 마스크 AND부터 경로 결정까지 4단계

앞에서 CIDR와 서브넷 마스크를 배웠는데, 정작 서버가 패킷을 보낼 때 **"이 목적지가 나랑 같은 망인가"**를 어떻게 판단하는지는 아직 뿌옇습니다. 이 판단이 곧 "게이트웨이 없이 직접 보낼까, 라우터로 넘길까"를 가르고, 마스크를 한 자리 잘못 넣으면 "같은 대역인데 ping이 안 되는" 정확히 그 지점입니다. 커널은 IP와 마스크를 AND 연산해 네트워크 주소를 뽑고, 출발지·목적지의 네트워크 주소를 비교하는 4단계로 이걸 결정합니다.

TEXT
출발지 192.168.1.50/24 → 목적지 ?
   │
   ① 내 네트워크 주소 계산 (IP AND 마스크)
   │    192.168.1.50  AND  255.255.255.0(/24)  = 192.168.1.0
   │
   ② 목적지도 같은 마스크로 AND
   │    목적지 192.168.1.200 → 192.168.1.0
   │    목적지 192.168.11.10 → 192.168.11.0
   │
   ③ 두 네트워크 주소 비교
   │    192.168.1.0 == 192.168.1.0   → 같은 망
   │    192.168.1.0 != 192.168.11.0  → 다른 망
   │
   ④ 경로 결정
   │    같은 망 → ARP로 상대 MAC 얻어 L2 직접 전달
   │    다른 망 → 게이트웨이(라우터)로
   ▼
같은 망이면 스위치만 거쳐, 다른 망이면 라우터를 거쳐 도달

각 단계에서 무슨 일이 일어나고, 틀어지면 어떤 증상인가:

단계하는 일여기서 틀어지면
① 내 네트워크 계산내 IP와 마스크를 AND해 내가 속한 네트워크 주소를 구한다마스크를 /24 대신 /25로 넣으면 내 네트워크 범위 자체가 반쪽(.0~.127)이 됨
② 목적지 마스킹목적지 IP를 같은 마스크로 AND해 목적지 네트워크 주소를 구한다마스크가 틀리면 목적지 판정 기준도 함께 틀어짐
③ 비교두 네트워크 주소가 같은지 본다양쪽 서버 마스크가 서로 다르면(/24 vs /25) 서로 상대를 다른 망으로 오판
④ 경로 결정같으면 L2 직접(ARP)·다르면 게이트웨이로오판하면 ARP가 엉뚱한 범위로만 나가 "같은 대역인데 응답 없음"

여기서 두 주소가 예약된다는 것도 함께 기억해야 합니다 — 호스트 비트가 전부 0이면 네트워크 주소, 전부 1이면 브로드캐스트 주소라 실제 호스트에 못 붙입니다(그래서 2^(32-CIDR) - 2). 그래서 "같은 망인데 못 붙는" 장애의 대부분은 ①의 마스크 오설정입니다. 한쪽만 /25로 잡히면 그 서버는 상대를 다른 망으로 보고 ARP 대신 게이트웨이를 찾는데, 게이트웨이가 그 트래픽을 되돌려주지 않아 조용히 막힙니다. ip route get <목적지IP>로 직접(dev)인지 경유(via)인지 확인하고, ip addr의 prefix가 설계값과 같은지부터 대조하는 이유가 이것입니다.


공인 IP vs 사설 IP

💡개념

사설(Private) IP 대역 3가지

클라우드 인스턴스에 10.0.1.45가 붙어있는데 왜 인터넷에서 직접 접속이 안 되는지 처음에는 이해하기 어렵습니다. 반대로 172.20.5.100이 사설 IP인지 공인 IP인지 헷갈려서 보안 그룹 규칙을 잘못 설정하는 일도 생깁니다. 세 가지 사설 대역 범위를 외워두면 IP 주소를 보는 순간 내부망인지 외부망인지 즉시 판단할 수 있습니다.

인터넷에서 직접 라우팅되지 않는 사설 IP 대역이 있습니다. NAT(Network Address Translation)를 통해 공인 IP로 변환 후 인터넷에 접속합니다.

사설 IP 대역 3가지 — 인터넷에서 라우팅되지 않는 사설 대역: 10.0.0.0/8(대규모)·172.16.0.0/12(중규모)·192.168.0.0/16(소규모·가정). 외부 통신은 NAT로 공인 IP로 변환. VPC·사내망은 이 대역에서 골라 쓰며, 대역이 겹치면 VPN·피어링 시 충돌확대

RFC 1918에서 정의한 사설 IP 대역: 인터넷에서 라우팅되지 않는 내부 전용 대역입니다.

클래스 A: 10.0.0.0   ~ 10.255.255.255   (10.0.0.0/8)
          → 약 1,677만 개 주소
          → 대기업, 클라우드 VPC, 데이터센터에 사용

클래스 B: 172.16.0.0 ~ 172.31.255.255   (172.16.0.0/12)
          → 약 104만 개 주소
          → 중규모 기업망에 사용

클래스 C: 192.168.0.0 ~ 192.168.255.255 (192.168.0.0/16)
          → 약 65,536개 주소
          → 가정용 공유기, 소규모 오피스

외우는 방법:

  • 10.x.x.x → 앞이 10으로 시작하면 사설
  • 172.16~31.x.x → 172인데 두 번째가 16~31이면 사설
  • 192.168.x.x → 192.168로 시작하면 사설

공인 IP (Public IP): 사설 IP 대역을 제외한 나머지가 공인 IP입니다. 인터넷에서 직접 라우팅 가능합니다.

특수 목적 주소:

  • 127.0.0.0/8 → 루프백(loopback), 자기 자신 (127.0.0.1)
  • 169.254.0.0/16 → 링크-로컬(APIPA), DHCP 실패 시 자동 할당
  • 0.0.0.0/0 → 모든 IP (방화벽 규칙에서 사용)
  • 255.255.255.255 → 제한된 브로드캐스트

서브넷 계산 실습

네트워크/브로드캐스트 주소 계산하기

주어진 IP와 CIDR에서 네트워크 주소, 브로드캐스트 주소, 사용 가능한 IP 범위를 계산합니다.

예제: 192.168.10.50/24 — 가장 일반적인 홈/사무실 네트워크 대역을 분석합니다.

CIDR: /24 → 서브넷 마스크 255.255.255.0

IP 주소:         192.168.10.50
서브넷 마스크:   255.255.255.0
AND 연산:        -----------------
네트워크 주소:   192.168.10.0   ← 첫 번째 주소 (장치에 할당 불가)

브로드캐스트:    192.168.10.255 ← 마지막 주소 (장치에 할당 불가)
사용 가능 범위:  192.168.10.1 ~ 192.168.10.254 (254개)

예제: 10.0.2.100/26 — /26 마스크를 실제 주소에 적용해 네트워크 범위를 분석합니다:

CIDR: /26 → 서브넷 마스크 255.255.255.192

IP 주소(이진):  10.0.2.01100100
마스크(이진):   /26 = 앞 26비트가 1

세 번째 옥텟까지: 10.0.2 (고정)
네 번째 옥텟 분석:
  100 = 01100100
  /26이므로 상위 2비트(01)가 네트워크, 하위 6비트(100100)가 호스트

  네트워크 부분: 01000000 = 64

네트워크 주소: 10.0.2.64
브로드캐스트:  10.0.2.127  (64+63=127)
사용 범위:     10.0.2.65 ~ 10.0.2.126 (62개)

빠른 계산 팁 — 블록 크기를 외우면 서브넷 범위를 암산으로 빠르게 구할 수 있습니다:

/26의 블록 크기: 256 - 192 = 64
블록: 0, 64, 128, 192, ...

100이 들어가는 블록: 64~127
→ 네트워크: 10.0.2.64, 브로드캐스트: 10.0.2.127
Linux에서 IP 주소와 서브넷 확인하기

실제 서버에서 IP 구성을 확인하는 명령어들입니다.

로컬 터미널
# 실습 디렉토리 준비
mkdir -p /tmp/networking/part1/exam_2 && cd /tmp/networking/part1/exam_2

# 방법 1: ip addr (현대적 방법, 권장)
ip addr show
# 또는 줄여서
ip a

# 출력 예시:
# 1: lo: <LOOPBACK,UP,LOWER_UP> mtu 65536
#     link/loopback 00:00:00:00:00:00
#     inet 127.0.0.1/8 scope host lo
#
# 2: eth0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500
#     link/ether aa:bb:cc:dd:ee:ff brd ff:ff:ff:ff:ff:ff
#     inet 10.0.1.25/24 brd 10.0.1.255 scope global eth0
#              ↑ IP주소/CIDR    ↑ 브로드캐스트 주소

# 특정 인터페이스만 확인
ip addr show eth0

# 방법 2: ifconfig (구버전, 일부 배포판에서만)
ifconfig eth0

# 서브넷 계산 도구 사용
# ipcalc 설치 후 사용
ipcalc 192.168.10.50/24

# 출력:
# Address:   192.168.10.50        11000000.10101000.00001010. 00110010
# Netmask:   255.255.255.0 = 24   11111111.11111111.11111111. 00000000
# Network:   192.168.10.0/24      11000000.10101000.00001010. 00000000
# HostMin:   192.168.10.1         11000000.10101000.00001010. 00000001
# HostMax:   192.168.10.254       11000000.10101000.00001010. 11111110
# Broadcast: 192.168.10.255       11000000.10101000.00001010. 11111111
# Hosts/Net: 254                   Class C, Private Internet
🔍실행 후 확인할 것
  • Network/Broadcast 먼저 확인ipcalc 출력에서 Network와 Broadcast 줄을 먼저 봅니다 — 두 서버의 Network 값이 같아야 직접 통신 가능
  • 서브넷 마스크 해석/24=255.255.255.0(254개 호스트), /25=127개, /30=2개 — 프리픽스 길이가 길수록 대역이 좁아짐
  • 다른 서브넷일 때Network 값이 다르면 같은 스위치에 있어도 라우터(게이트웨이)를 반드시 거쳐야 하므로 ip route 확인으로 이어짐
두 IP가 같은 서브넷인지 확인하기

서버 간 통신 문제를 디버깅할 때 두 IP가 같은 서브넷에 있는지 확인하는 것이 중요합니다.

로컬 터미널
# 시나리오: 서버 A(10.0.1.10/24)에서 서버 B(10.0.1.200)로 통신 가능한가?

# 수동 계산:
# 서버 A 네트워크: 10.0.1.0/24 (범위: 10.0.1.1~10.0.1.254)
# 서버 B(10.0.1.200)는 10.0.1.0/24 범위 내 → 같은 서브넷 → 직접 통신 가능

# 시나리오 2: 서버 A(10.0.1.10/24)에서 서버 C(10.0.2.50)는?
# 서버 C(10.0.2.50)는 10.0.1.0/24 범위 밖 → 다른 서브넷 → 라우터 필요

# ip route get으로 실제 라우팅 경로 확인
ip route get 10.0.1.200
# 10.0.1.200 dev eth0 src 10.0.1.10
# ↑ 직접 통신 (dev eth0 — 라우터 거치지 않음)

ip route get 10.0.2.50
# 10.0.2.50 via 10.0.1.1 dev eth0 src 10.0.1.10
# ↑ via 10.0.1.1 — 게이트웨이(라우터)를 통해 전달

# 파이썬으로 서브넷 계산 (스크립트에서 활용)
python3 -c "
import ipaddress
net = ipaddress.ip_network('10.0.1.0/24')
ip_b = ipaddress.ip_address('10.0.1.200')
ip_c = ipaddress.ip_address('10.0.2.50')
print(f'10.0.1.200 in 10.0.1.0/24: {ip_b in net}')  # True
print(f'10.0.2.50  in 10.0.1.0/24: {ip_c in net}')  # False
"

서브넷 분할 설계

VPC 서브넷 설계 — 실전 시나리오

AWS/GCP/Azure에서 VPC를 설계할 때 서브넷을 어떻게 나누는지 실습합니다.

요구사항:

  • VPC 전체: 10.0.0.0/16 (65,534개 IP)
  • Public 서브넷 2개 (로드밸런서, NAT 게이트웨이용)
  • Private 서브넷 2개 (애플리케이션 서버용)
  • DB 서브넷 2개 (데이터베이스용)
  • 각 서브넷은 AZ(가용영역)별로 분리

설계 결과 — 위 원칙을 적용한 실제 서브넷 배치 예시입니다: VPC 10.0.0.0/16 안에 6개 서브넷을 배치한 예시입니다.

서브넷CIDR사용 가능 IP
Public Subnet AZ-a10.0.0.0/24254개 (10.0.0.1~254)
Public Subnet AZ-b10.0.1.0/24254개 (10.0.1.1~254)
Private Subnet AZ-a10.0.10.0/24254개 (10.0.10.1~254)
Private Subnet AZ-b10.0.11.0/24254개 (10.0.11.1~254)
DB Subnet AZ-a10.0.20.0/24254개 (10.0.20.1~254)
DB Subnet AZ-b10.0.21.0/24254개 (10.0.21.1~254)

설계 원칙:

  • /24를 기준으로 역할별로 번호 대역을 나눔 (0.x=public, 10.x=private, 20.x=db)
  • 짝수 번호(0, 10, 20)는 AZ-a, 홀수(1, 11, 21)는 AZ-b
  • 나중에 추가될 서브넷을 위해 중간 번호 건너뜀 (29, 1219는 비어있음)
로컬 터미널
# 설계를 검증하는 파이썬 스크립트
python3 << 'EOF'
import ipaddress

vpc = ipaddress.ip_network('10.0.0.0/16')
subnets = [
    ('Public AZ-a',  '10.0.0.0/24'),
    ('Public AZ-b',  '10.0.1.0/24'),
    ('Private AZ-a', '10.0.10.0/24'),
    ('Private AZ-b', '10.0.11.0/24'),
    ('DB AZ-a',      '10.0.20.0/24'),
    ('DB AZ-b',      '10.0.21.0/24'),
]

for name, cidr in subnets:
    net = ipaddress.ip_network(cidr)
    print(f"{name:15} {cidr:18} 호스트수: {net.num_addresses-2}")
    # VPC 안에 포함되는지 확인
    assert net.subnet_of(vpc), f"{cidr}가 VPC 범위를 벗어남!"

print("\n모든 서브넷이 VPC 범위 내에 있습니다.")
EOF

자주 하는 실수와 트러블슈팅

신규 서버를 추가했는데 기존 서버와 통신이 안 됩니다.

로컬 터미널
# 기존 서버: 10.0.1.10/24
# 신규 서버: 10.0.1.50/25 (실수로 /25로 설정)

# 신규 서버에서 기존 서버로 ping 시도
ping -c 3 10.0.1.10

# Request timeout × 3

# 원인 분석:
# 신규 서버(/25 설정):
#   10.0.1.50/25 → 네트워크: 10.0.1.0/25 (범위: 10.0.1.1~10.0.1.126)
#   10.0.1.10은 이 범위 내 → 직접 통신 시도

# 기존 서버(/24 설정):
#   10.0.1.10/24 → 네트워크: 10.0.1.0/24 (범위: 10.0.1.1~10.0.1.254)
#   10.0.1.50은 이 범위 내 → 직접 통신 시도

# 문제: 양쪽 다 직접 통신을 시도하지만
# 신규 서버의 ARP 요청이 다른 서브넷으로 전달되지 않아 통신 실패
# (ARP는 같은 서브넷 내에서만 동작)

# 해결: 신규 서버의 CIDR을 /24로 수정
ip addr del 10.0.1.50/25 dev eth0
ip addr add 10.0.1.50/24 dev eth0

# 재확인
ping -c 3 10.0.1.10
# 64 bytes from 10.0.1.10: icmp_seq=1 ttl=64 time=0.3 ms ← 성공

서버에 10.0.1.25 IP를 설정했는데 인터넷 접속이 안 됩니다.

로컬 터미널
# 서버에서 인터넷 테스트
ping -c 3 8.8.8.8
# Request timeout

curl http://example.com
# curl: (6) Could not resolve host: example.com

# 1단계: 게이트웨이 확인
ip route show
# default via 10.0.1.1 dev eth0
# 10.0.1.0/24 dev eth0 proto kernel

# 2단계: 게이트웨이 ping
ping -c 3 10.0.1.1
# 64 bytes from 10.0.1.1: icmp_seq=1 ← 게이트웨이는 정상

# 3단계: 게이트웨이(라우터)에서 NAT 설정 확인
# 사설 IP → 공인 IP 변환(NAT)이 라우터에서 설정되어 있어야 함
# AWS라면: VPC의 인터넷 게이트웨이(IGW), NAT 게이트웨이 연결 확인
# 온프레미스라면: 방화벽/라우터의 NAT(MASQUERADE) 규칙 확인

# 라우터에서 iptables NAT 확인 예시 (리눅스 라우터):
iptables -t nat -L POSTROUTING
# MASQUERADE  all  --  10.0.1.0/24  0.0.0.0/0
#   ↑ 이 규칙이 없으면 인터넷 접속 불가

# 규칙 추가 (공인 IP 인터페이스가 eth1인 경우):
iptables -t nat -A POSTROUTING -s 10.0.1.0/24 -o eth1 -j MASQUERADE

심화 — 호스트 수 공식이 깨지는 곳: /31·/32와 클라우드 예약 IP

💡개념

심화: 2^(32-CIDR)-2 공식의 예외 — /31 P2P 링크와 클라우드가 더 떼어가는 IP

앞에서 사용 가능 호스트 수 = 2^(32-CIDR) - 2 공식을 배웠습니다. 이 -2(네트워크·브로드캐스트)는 '브로드캐스트가 필요한 일반 이더넷 서브넷'을 전제한 규칙입니다. 그런데 실무에는 이 공식이 그대로 안 맞는 두 자리가 있습니다 — 라우터끼리 잇는 P2P 링크, 그리고 클라우드 서브넷입니다. 이걸 모르면 IP를 낭비하거나, 반대로 서브넷을 너무 빡빡하게 잡아 확장 때 막힙니다.

  • /31 — P2P 링크의 예외(RFC 3021): 공식대로면 /31은 2^1-2=0개라 못 쓸 것 같지만, 라우터 간 포인트-투-포인트 링크는 상대가 하나뿐이라 브로드캐스트가 무의미합니다. RFC 3021은 /31에서 네트워크·브로드캐스트 예약을 생략하고 두 주소를 모두 호스트로 쓰게 합니다. 그래서 링크마다 /30(4개 중 2개만 사용) 대신 /31로 IP 2개씩을 아낍니다.
  • /32 — 딱 한 호스트: /32는 호스트 하나를 정확히 가리킵니다. 라우팅 테이블의 특정 호스트 경로, 방화벽·보안그룹에서 '이 IP 하나만' 허용할 때 씁니다. source: 1.2.3.4/32 같은 규칙이 그것입니다.
  • 클라우드는 -2가 아니라 더 뗍니다: AWS는 각 서브넷에서 앞 4개(네트워크, VPC 라우터=.1, DNS=.2, 향후 예약=.3)와 마지막 1개(브로드캐스트)까지 총 5개를 예약합니다. 그래서 /24는 254가 아니라 251부터 시작합니다. GCP·Azure도 개수는 달라도 비슷하게 몇 개씩 예약합니다.
  • 예약 말고도 IP를 먹는 것들: 로드밸런서 노드, NAT, 각 인스턴스의 보조 ENI, 파드마다 IP를 쓰는 쿠버네티스 CNI 등이 같은 서브넷에서 IP를 소비합니다. '이론상 254개'만 믿고 서브넷을 빡빡하게 잡으면 오토스케일링이 한계에 부딪힙니다.

정리하면 공식은 출발점일 뿐입니다. P2P 링크는 /31로 아끼고, 클라우드 서브넷은 예약·부가 소비·성장 여유를 감안해 넉넉히 잡아야 합니다.

상황: 오토스케일링 그룹의 최대 대수를 늘렸는데 인스턴스가 계속 뜨다가, 어느 순간 InsufficientFreeAddressesInSubnet(콘솔에는 'IP 주소 부족')로 신규 기동이 실패합니다. 이론상 /24는 254개인데 아직 그만큼 안 띄웠다며 당황합니다.

원인: 두 가지가 겹칩니다. (1) AWS는 서브넷마다 5개를 예약합니다(네트워크·.1 라우터·.2 DNS·.3 향후 예약·마지막 브로드캐스트). 그래서 /24의 실사용은 254가 아니라 251입니다. (2) 같은 서브넷에 로드밸런서 노드·NAT·다른 서비스의 보조 ENI가 이미 IP를 쓰고 있었습니다. 남은 IP가 오토스케일링 목표 대수에 못 미쳐 고갈된 것입니다.

진단: 서브넷의 남은 가용 IP와, 무엇이 IP를 먹고 있는지 봅니다.

로컬 터미널
# 서브넷의 남은 가용 IP 개수
aws ec2 describe-subnets --subnet-ids subnet-xxxx \
  --query "Subnets[0].AvailableIpAddressCount"

# 그 서브넷에서 IP를 쓰는 ENI 목록(무엇이 IP를 소비하는지)
aws ec2 describe-network-interfaces \
  --filters Name=subnet-id,Values=subnet-xxxx \
  --query "NetworkInterfaces[].{IP:PrivateIpAddress,Desc:Description}" --output table

AvailableIpAddressCount가 남은 목표 대수보다 작으면 확정입니다.

해결: 서브넷을 처음부터 넉넉히(예: /23, /22) 잡고, 오토스케일링을 여러 AZ의 여러 서브넷에 걸쳐 배치해 한 서브넷에 몰리지 않게 합니다. 이미 좁게 만든 서브넷은 CIDR을 바꿀 수 없으므로, 더 큰 새 서브넷을 추가해 그쪽으로 확장합니다. 설계 단계에서 '2^n-2'가 아니라 '예약 5개 + 부가 소비 + 성장 여유'로 용량을 잡는 것이 핵심입니다(VPC와 서브넷).


💼
실무 맥락
현업 패턴

실무에서 CIDR을 잘못 설계하면 나중에 수정하기 매우 어렵습니다. 실제로 겪는 문제들입니다.

문제 1: VPC CIDR 공간 부족 — 초기 설계 시 대역을 너무 좁게 잡으면 확장이 불가능합니다:

초기 설계: VPC 10.0.0.0/24 (254개 IP)
→ 서비스가 성장해 서버가 300대 필요
→ /24로는 부족하지만 VPC CIDR 변경은 기존 서비스 중단 필요
→ 처음부터 /16이나 /20으로 넉넉하게 설계해야 했음

문제 2: 온프레미스와 클라우드 IP 충돌 — 동일 대역을 양쪽에 쓰면 VPN/피어링 연결이 불가능합니다:

온프레미스 네트워크: 10.0.0.0/8
AWS VPC: 10.0.1.0/24
→ VPN/Direct Connect 연결 시 IP 대역 겹침으로 라우팅 불가
→ VPC를 172.16.0.0/16으로 다시 만들어야 하는 사태 발생

실전 설계 원칙:

  1. VPC는 /16 이상 넉넉하게
  2. 서브넷은 /24가 기본, 필요 시 더 작게 분할
  3. 향후 VPN/피어링을 고려해 다른 환경과 IP 대역이 겹치지 않도록
  4. /28 이하로 너무 작게 만들지 말 것 (클라우드 내부 예약 IP 제외 후 실사용 가능 개수 확인)

면접/실무 단골 질문:

  • "10.0.0.0/24와 10.0.0.0/16의 차이를 설명하세요."
  • "VPC 서브넷을 public과 private으로 나누는 이유는?"
  • "172.16.5.10은 사설 IP인가요?" (Yes — 172.16~31 범위)

요약

개념핵심 내용
IPv4 구조32비트를 8비트씩 4개 옥텟으로 표현, 0~255
서브넷 마스크네트워크 부분과 호스트 부분을 구분하는 32비트 값
CIDR/숫자 형태로 네트워크 비트 수 표현, /24 = 255.255.255.0
호스트 수 공식2^(32-CIDR) - 2 (네트워크+브로드캐스트 제외)
네트워크 주소호스트 비트 모두 0, 첫 번째 주소 (장치 할당 불가)
브로드캐스트 주소호스트 비트 모두 1, 마지막 주소 (장치 할당 불가)
사설 IP 3대역10.x.x.x / 172.16~31.x.x / 192.168.x.x
/24가장 흔한 서브넷, 254개 호스트
/16VPC 전체 범위로 자주 사용, 65,534개 호스트

명령어·단축키 빠른 참조

이 모듈에서 실제로 쓰는 CIDR 계산·확인 명령만 짧게 모았습니다.

명령어용도자주 쓰는 예
ip addr showNIC의 IP·CIDR(prefix) 확인ip a, ip addr show eth0 (inet 10.0.1.25/24 형태)
ipcalc <IP/CIDR>네트워크·브로드캐스트·호스트 범위 계산ipcalc 192.168.10.50/24 (Network/Broadcast/HostMin~Max)
ip route show라우팅 테이블·기본 게이트웨이 확인ip rdefault via가 게이트웨이
ip route get <IP>직접 통신인지 게이트웨이 경유인지 판별ip route get 10.0.2.50via 있으면 라우터 경유
python3 -c "import ipaddress…"두 IP가 같은 서브넷인지 프로그램 판정ipaddress.ip_address('10.0.1.200') in ip_network('10.0.1.0/24')
ip addr add/del잘못 설정한 IP/CIDR 교정ip addr del 10.0.1.50/25 dev eth0 && ip addr add 10.0.1.50/24 dev eth0

다음 챕터에서는 다른 네트워크로 패킷을 전달하는 게이트웨이와 정적 라우팅을 학습합니다.

여기서 익힌 CIDR(예: /16, /24)은 클라우드에서 VPC와 서브넷의 IP 범위를 정할 때 그대로 쓰입니다. VPC·서브넷 설계는 VPC와 서브넷(Cloud Engineering 트랙)에서 다룹니다.

지식 확인

퀴즈 — 8문제

Q1

서버 A(192.168.10.50/24)에서 서버 B(192.168.10.200/24)에 ping이 성공하는데, 서버 C(192.168.11.10/24)에는 ping이 실패합니다. 서버 A의 라우팅 테이블에 게이트웨이가 없을 때 이 현상의 원인은?

Q2

AWS EC2 인스턴스의 프라이빗 IP가 10.0.1.45입니다. 인터넷에서 이 인스턴스에 직접 접속이 안 되는 근본 이유는?

Q3

팀에서 신규 서버 IP를 10.0.1.100으로 배정하려 합니다. 기존 서브넷이 10.0.0.0/16입니다. 이 IP를 같은 서브넷에 추가해도 됩니까?

Q4

VPC를 새로 설계할 때 10.0.0.0/16을 사용하는 실무적 이유는?

Q5

방화벽 규칙에 `source: 192.168.1.0/24`를 추가했습니다. 여기서 허용되지 않는 IP는?

Q6

192.168.1.50/24에서 '/24'와 서브넷 마스크(255.255.255.0)가 의미하는 것은?

Q7

[심화] 라우터끼리 잇는 포인트-투-포인트 링크에 IP를 아끼려 /31을 쓸 수 있다. 공식대로면 /31은 2^(32-31)-2=0개라 못 쓸 것 같은데, 실제로는 호스트 2개를 쓰는 이유는?

Q8

[심화] AWS에서 /24 서브넷(이론상 254개)에 오토스케일링으로 서버를 늘리는데, 250대도 안 됐는데 InsufficientFreeAddressesInSubnet 에러로 더 못 뜬다. 가장 먼저 이해해야 할 원리는?

0 / 8 답변

🧪 실습으로 확인하기

포트는 열렸다는데 왜 안 되지? — ss/netstat/telnet으로 TCP 진단

초급

"포트 8080 열었는데요?"와 "왜 안 돼요?" 사이의 간극을 메우는 실습. ss로 바인딩 상태를 확인하고, telnet/nc으로 원격 연결을 테스트하고, iptables 방화벽을 진단하고, 바인딩 주소(0.0.0.0 vs 127.0.0.1)까지 수정하는 4단계 TCP 포트 진단 플로우를 완성한다.

35📋 4단계💻 직접 환경
실습 시작하기 →

이것도 배워보세요