새 서버를 같은 대역에 넣었는데 일부 서버와만 통신이 됩니다. 알고 보니 한쪽은 /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 addr showsudo apt-get install -y ipcalc || sudo yum install -y ipcalcpython3 -c 'import ipaddress; print(ipaddress.ip_network("10.0.0.0/24"))'ip route showIP 주소의 구조
AWS에서 VPC를 만들 때 10.0.0.0/16을 입력하거나, 방화벽 규칙에 192.168.1.0/24를 허용 대상으로 추가할 때 — 이 숫자들이 어떤 범위를 의미하는지 직관적으로 이해해야 합니다. 그렇지 않으면 VPC 설계를 잘못 해서 나중에 서브넷을 추가할 수 없거나, 방화벽 규칙이 의도와 다르게 적용되는 상황이 생깁니다.

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/0과 10.0.0.0/8의 차이를 몰라서 전체 허용을 하는 실수가 생깁니다. 방화벽 담당자에게 허용 범위를 전달할 때도 CIDR 표기 없이 "10.0.1 대역 전체요"라고 하면 오해가 생깁니다. /숫자가 어떤 범위를 의미하는지 숫자만 보고 바로 파악할 수 있어야 네트워크 설정이 의도대로 적용됩니다.
CIDR(Classless Inter-Domain Routing)은 서브넷 마스크를 /숫자 형태로 간결하게 표현합니다. 숫자는 네트워크 비트 수(1의 개수)를 의미합니다.

전통 표기: 192.168.1.0 / 255.255.255.0
CIDR 표기: 192.168.1.0/24
↑ 앞 24비트가 네트워크 부분
자주 사용하는 CIDR 정리: 실무에서 자주 쓰는 CIDR 표기와 호스트 수 관계입니다.
| CIDR | 서브넷 마스크 | 호스트 수 | 용도 |
|---|---|---|---|
| /8 | 255.0.0.0 | 16,777,214 | 대형 사설망 (10.0.0.0/8) |
| /16 | 255.255.0.0 | 65,534 | 클라우드 VPC 전체 |
| /24 | 255.255.255.0 | 254 | 일반 서브넷 (가장 흔함) |
| /25 | 255.255.255.128 | 126 | 서브넷 절반 분할 |
| /26 | 255.255.255.192 | 62 | 소규모 서비스 서브넷 |
| /27 | 255.255.255.224 | 30 | 작은 팀/서비스용 |
| /28 | 255.255.255.240 | 14 | 관리용 소형 서브넷 |
| /30 | 255.255.255.252 | 2 | 포인트-투-포인트 링크 |
| /32 | 255.255.255.255 | 1 | 단일 호스트 지정 |
호스트 수 계산 공식 — 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로 변환 후 인터넷에 접속합니다.

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
실제 서버에서 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가 같은 서브넷에 있는지 확인하는 것이 중요합니다.
# 시나리오: 서버 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
"
서브넷 분할 설계
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
- 나중에 추가될 서브넷을 위해 중간 번호 건너뜀 (2
9, 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으로 다시 만들어야 하는 사태 발생
실전 설계 원칙:
- VPC는
/16이상 넉넉하게 - 서브넷은
/24가 기본, 필요 시 더 작게 분할 - 향후 VPN/피어링을 고려해 다른 환경과 IP 대역이 겹치지 않도록
/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개 호스트 |
| /16 | VPC 전체 범위로 자주 사용, 65,534개 호스트 |
다음 챕터에서는 다른 네트워크로 패킷을 전달하는 게이트웨이와 정적 라우팅을 학습합니다.