infra
Platform

모듈 맵

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

0 / 35 완료

펼치기
0 / 35 완료0%

Networking · 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 주소의 구조

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비트 값입니다.

IP 주소:      192.168.1.25   →  11000000.10101000.00000001.00011001
서브넷 마스크: 255.255.255.0  →  11111111.11111111.11111111.00000000
              (마스크 AND 연산)
네트워크 주소: 192.168.1.0    →  11000000.10101000.00000001.00000000
                                 ←── 네트워크 부분 ───→←── 호스트 ──→

마스크 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 / 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 vs 사설 IP

💡개념

사설(Private) IP 대역 3가지

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

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

사설(Private) IP 대역 3가지

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
🔍실행 후 확인할 것
  • 핵심 출력명령 결과에서 성공/실패를 가르는 값을 먼저 확인합니다
  • 대상 식별IP, 포트, 인터페이스, 프로세스명처럼 다음 조치를 결정하는 필드를 봅니다
  • 다음 분기결과가 기대와 다르면 어느 계층을 이어서 점검할지 정합니다
두 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
├── Public Subnet AZ-a:   10.0.0.0/24   (254개, 10.0.0.1~254)
├── Public Subnet AZ-b:   10.0.1.0/24   (254개, 10.0.1.1~254)
├── Private Subnet AZ-a:  10.0.10.0/24  (254개, 10.0.10.1~254)
├── Private Subnet AZ-b:  10.0.11.0/24  (254개, 10.0.11.1~254)
├── DB Subnet AZ-a:       10.0.20.0/24  (254개, 10.0.20.1~254)
└── DB Subnet AZ-b:       10.0.21.0/24  (254개, 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

💼
실무 맥락
현업 패턴

실무에서 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개 호스트

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

지식 확인

퀴즈 — 5문제

Q1

192.168.10.0/24 네트워크에서 사용 가능한 호스트 IP 수는?

Q2

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

Q3

10.0.0.0/16 네트워크의 브로드캐스트 주소는?

Q4

클라우드 VPC를 설계할 때 10.0.0.0/16을 사용하는 주된 이유는?

Q5

172.20.100.0/22 네트워크의 서브넷 마스크는?

0 / 5 답변

🧪 실습으로 확인하기

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

초급

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

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

이것도 배워보세요

networking입문 · 45
[Network] DNS 동작 과정과 A, CNAME, TXT 레코드 분석
Networking 트랙 계속
docker입문 · 30
[Docker] 백엔드 개발자에게 Docker와 컨테이너 가상화가 필수인 이유
Docker 트랙 시작점