서브넷마스크 계산, 이제 공식 없이 비트로 읽는다 — 네트워크 정리 (AWS VPC 설계 포함)

🌐 네트워크 기초 완전 정복

서브넷마스크, 이제 계산 없이
"눈으로 바로 읽는 법을 알려드립니다"

IP 클래스 · CIDR · 서브네팅 계산법 · AWS/k8s VPC 설계까지 — 실무 백엔드 개발자 관점

🌐 IPv4 기준 ☁️ AWS VPC 설계 포함 ⏱ 읽기 약 15분 🔥 실무 설계 패턴 포함

📋 목차

1. 들어가며 — VPC 설계에서 서브넷을 잘못 잡았던 경험
2. IP 주소와 서브넷마스크 — 이진수로 이해하기
3. CIDR 표기법 — /24가 뭔지 이제 직관적으로 읽기
4. 네트워크 주소 · 브로드캐스트 · 호스트 범위 계산
5. IP 클래스와 사설 IP 대역
6. 서브네팅 — 하나의 네트워크를 쪼개는 법
7. 실무 적용 — AWS VPC / k8s 서브넷 설계
8. 실무 트러블슈팅 BEST 3

📖 Section 01

들어가며 — VPC 설계에서 서브넷을 잘못 잡았던 경험

AWS에서 새 서비스를 구성할 때 VPC CIDR을 /24로 잡았습니다. "256개면 충분하겠지"라고 생각했는데, 나중에 EKS 파드가 IP를 엄청나게 잡아먹는다는 걸 알게 됐고, 서브넷이 모자라서 VPC를 처음부터 다시 만들어야 했습니다.

서브넷마스크를 대충 알면 이런 실수를 합니다. 이 글은 "서브넷마스크를 코딩하듯 정확히 이해하는 법"을 정리한 것입니다. 수학 공식이 아니라 비트 구조로 이해하면 절대 헷갈리지 않습니다.

💡

백엔드 개발자가 서브넷마스크를 알아야 하는 이유:
① AWS VPC, 서브넷, 보안그룹 설계할 때
② k8s 클러스터 네트워크(Pod CIDR, Service CIDR) 설정할 때
③ 방화벽 규칙에서 IP 허용 범위 지정할 때
④ 서버 간 통신이 안 될 때 네트워크 범위 확인할 때

· · ·

🔢 Section 02

IP 주소와 서브넷마스크 — 이진수로 이해하기

IPv4 주소는 32비트 숫자를 8비트(옥텟) 4개로 나눠 표현한 것입니다. 우리가 보는 192.168.1.100은 사람이 읽기 편한 10진수 표현일 뿐이에요.

192.168.1.100 — 이진수 분해

IP (10진수)

192 . 168 . 1 . 100

IP (2진수)

1

1

0

0

0

0

0

0

 

1

0

1

0

1

0

0

0

 

0

0

0

0

0

0

0

1

 

0

1

1

0

0

1

0

0

Mask /24

1

1

1

1

1

1

1

1

 

1

1

1

1

1

1

1

1

 

1

1

1

1

1

1

1

1

 

0

0

0

0

0

0

0

0

🔵 네트워크 부분 (24비트) — 고정    🟢 호스트 부분 (8비트) — 변경 가능

🔑

서브넷마스크의 역할:
IP 주소를 "네트워크 부분"과 "호스트 부분"으로 나누는 경계선입니다.
마스크의 1인 비트 위치 = 네트워크 주소 (모두 같아야 같은 네트워크)
마스크의 0인 비트 위치 = 호스트 주소 (이 부분이 달라도 같은 네트워크)

· · ·

📏 Section 03

CIDR 표기법 — /24가 뭔지 직관적으로 읽기

CIDR(Classless Inter-Domain Routing) 표기법은 IP주소/프리픽스길이 형태로, 슬래시 뒤 숫자는 "앞에서 몇 비트가 네트워크 부분인지"를 나타냅니다.

CIDR	서브넷마스크	호스트 비트	총 IP 수	실제 사용 가능 IP	용도
/32	255.255.255.255	0비트	1	1 (단일 호스트)	특정 IP 지정
/30	255.255.255.252	2비트	4	2	P2P 링크
/28	255.255.255.240	4비트	16	14	소규모 서브넷
/24	255.255.255.0	8비트	256	254	일반 LAN
/22	255.255.252.0	10비트	1,024	1,022	중규모 서브넷
/20	255.255.240.0	12비트	4,096	4,094	AWS VPC 서브넷
/16	255.255.0.0	16비트	65,536	65,534	대규모 VPC

⚡

암기 없이 계산하는 공식:
호스트 비트 수 = 32 - 프리픽스 길이
총 IP 수 = 2^(호스트 비트 수)
사용 가능 IP = 총 IP - 2 (네트워크 주소 + 브로드캐스트 주소 제외)

예: /26 → 호스트 비트 = 32-26 = 6 → 총 IP = 2^6 = 64 → 사용 가능 = 62개

· · ·

🧮 Section 04

네트워크 주소 · 브로드캐스트 · 호스트 범위 계산

192.168.10.130/26 을 예시로 실제 계산 과정을 따라가 봅시다.

192.168.10.130 / 26 — 네트워크/호스트 분리

IP 마지막 옥텟

1

0

0

0

0

0

1

0

Mask 마지막 옥텟

1

1

0

0

0

0

0

0

네트워크 주소

1

0

0

0

0

0

0

0

브로드캐스트

1

0

1

1

1

1

1

1

🔵 /26 = 앞 26비트 고정 (마지막 옥텟에서 앞 2비트까지 네트워크)
네트워크 주소: 192.168.10.128  |  브로드캐스트: 192.168.10.191
사용 가능 IP: 192.168.10.129 ~ 192.168.10.190 (62개)

📐

빠른 계산법 — 블록 크기로 네트워크 주소 찾기

블록 크기 = 2^(호스트 비트 수). /26이면 블록 크기 = 2^6 = 64.
마지막 옥텟(130)을 블록 크기(64)로 나누면: 130 ÷ 64 = 2 (몫).
네트워크 주소 = 64 × 2 = 128 → 192.168.10.128
브로드캐스트 = 128 + 64 - 1 = 191 → 192.168.10.191

💡 이 방법이면 암산으로도 30초 안에 계산 가능합니다!

· · ·

📦 Section 05

IP 클래스와 사설 IP 대역

클래스	범위	기본 마스크	사설 IP 대역	실무 사용
🔴 Class A	1.0.0.0 ~ 126.255.255.255	/8	10.0.0.0/8	AWS VPC 대규모
🟡 Class B	128.0.0.0 ~ 191.255.255.255	/16	172.16.0.0/12	사내 네트워크
🟢 Class C	192.0.0.0 ~ 223.255.255.255	/24	192.168.0.0/16	가정/소규모
🔵 특수	127.0.0.1	—	Loopback	localhost

✅

사설 IP 3대장 — 외워두면 평생 써먹습니다:
🔴 10.0.0.0/8 — 10.x.x.x 전체 (1677만개 IP) → AWS 대규모 VPC 추천
🟡 172.16.0.0/12 — 172.16.x.x ~ 172.31.x.x (104만개 IP)
🟢 192.168.0.0/16 — 192.168.x.x 전체 (6만5천개 IP) → 공유기/로컬 환경

이 대역들은 인터넷에서 라우팅되지 않는 내부 전용 IP입니다.

· · ·

✂️ Section 06

서브네팅 — 하나의 네트워크를 쪼개는 법

서브네팅은 큰 네트워크 1개를 작은 네트워크 여러 개로 나누는 것입니다. 예를 들어 192.168.1.0/24 (256개 IP)를 4개의 서브넷으로 나눠 보겠습니다.

 

 

 

192.168.1.0/24 → /26 서브넷 4개로 분할

계산

# /24 → /26으로 2비트 추가 → 2^2 = 4개 서브넷 생성
# 각 서브넷 크기: 256 / 4 = 64개 IP (사용 가능: 62개)

서브넷 1: 192.168.1.0/26
         네트워크: 192.168.1.0
         게이트웨이: 192.168.1.1
         호스트 범위: 192.168.1.1 ~ 192.168.1.62
         브로드캐스트: 192.168.1.63

서브넷 2: 192.168.1.64/26
         네트워크: 192.168.1.64
         호스트 범위: 192.168.1.65 ~ 192.168.1.126
         브로드캐스트: 192.168.1.127

서브넷 3: 192.168.1.128/26
         네트워크: 192.168.1.128
         호스트 범위: 192.168.1.129 ~ 192.168.1.190
         브로드캐스트: 192.168.1.191

서브넷 4: 192.168.1.192/26
         네트워크: 192.168.1.192
         호스트 범위: 192.168.1.193 ~ 192.168.1.254
         브로드캐스트: 192.168.1.255

· · ·

☁️ Section 07

실무 적용 — AWS VPC / k8s 서브넷 설계

AWS VPC 서브넷 설계 — 실무 추천 패턴 (10.0.0.0/16)

Internet Gateway
Public 진입점

NAT Gateway
Private → Internet

Public Subnet A
10.0.1.0/24 (AZ-a)
ALB, Bastion

Public Subnet B
10.0.2.0/24 (AZ-b)
ALB, Bastion

Public Subnet C
10.0.3.0/24 (AZ-c)
ALB, Bastion

Private Subnet A
10.0.11.0/24 (AZ-a)
App Server, EKS Node

Private Subnet B
10.0.12.0/24 (AZ-b)
App Server, EKS Node

Private Subnet C
10.0.13.0/24 (AZ-c)
App Server, EKS Node

DB Subnet A
10.0.21.0/24 (AZ-a)
RDS, ElastiCache

DB Subnet B
10.0.22.0/24 (AZ-b)
RDS, ElastiCache

DB Subnet C
10.0.23.0/24 (AZ-c)
RDS, ElastiCache

VPC: 10.0.0.0/16 (65,534 IP) | 3 AZ × 3 티어 = 9개 서브넷

🎯

EKS(k8s) 사용 시 서브넷 주의사항:
EKS에서 파드는 노드 IP와 별도로 각각 IP를 1개씩 점유합니다 (AWS VPC CNI 기준).
노드 1대(t3.medium)에서 최대 파드 17개 → IP 17개 소모.
노드 10대 × 17개 = 170개 IP → /24(254개)면 금방 찹니다!
EKS 클러스터가 있다면 서브넷은 /22 이상을 강력 권장합니다.

 

 

 

Terraform — VPC + 서브넷 설계 예시

HCL

# VPC: 10.0.0.0/16
resource "aws_vpc" "main" {
  cidr_block           = "10.0.0.0/16"
  enable_dns_hostnames = true
}

# Public 서브넷 — ALB, Bastion
resource "aws_subnet" "public" {
  count             = 3
  vpc_id            = aws_vpc.main.id
  cidr_block        = "10.0.${count.index + 1}.0/24"
  availability_zone = data.aws_availability_zones.available.names[count.index]
  map_public_ip_on_launch = true
}

# Private 서브넷 — App / EKS Node (/22로 여유 확보)
resource "aws_subnet" "private_app" {
  count             = 3
  vpc_id            = aws_vpc.main.id
  # /22 = 1024 IP → EKS 파드 IP 여유 충분
  cidr_block        = "10.0.${(count.index * 4) + 10}.0/22"
  availability_zone = data.aws_availability_zones.available.names[count.index]
}

· · ·

🚨 Section 08

실무 트러블슈팅 BEST 3

🔴

Case 1 — 같은 VPC인데 서버 간 통신이 안 됨

🚨 현상: 같은 VPC 내 서버 A(10.0.1.5)에서 서버 B(10.0.2.5)로 통신이 안 됨. ping도 안 되고 telnet도 안 됨.

✅ 체크 순서:
1) 보안 그룹(Security Group) 인바운드 규칙 확인 — 출발지 IP 또는 CIDR 허용 여부
2) NACL(Network ACL) 인바운드/아웃바운드 규칙 확인 (Stateless이므로 양방향 모두 확인)
3) 라우팅 테이블에 대상 서브넷으로의 경로 존재 여부 확인

🔴

Case 2 — EKS 파드에 IP 할당 실패

🚨 현상: 새 파드 배포 시 Pending 상태 지속. 이벤트에 "Failed to allocate IP" 또는 "No ENI available" 에러.

✅ 원인: 서브넷 IP가 고갈됨. /24 서브넷(254개)에 노드+파드 IP가 꽉 참.
즉시 대응: 새 서브넷(/22) 생성 후 node group을 새 서브넷으로 마이그레이션
근본 해결: VPC 설계 단계에서 EKS용 서브넷은 /22 이상으로 충분히 확보

🔴

Case 3 — VPC Peering 후 라우팅 안 됨

🚨 현상: VPC A(10.0.0.0/16)와 VPC B(10.1.0.0/16) Peering 연결 후에도 통신 불가.

✅ VPC Peering은 연결만 한다고 끝이 아닙니다.
1) VPC A 라우팅 테이블: 10.1.0.0/16 → Peering Connection 추가
2) VPC B 라우팅 테이블: 10.0.0.0/16 → Peering Connection 추가
3) 양쪽 보안 그룹에서 상대방 CIDR 허용 추가
⚠️ 두 VPC의 CIDR이 겹치면(Overlapping) Peering 자체가 불가합니다. 설계 단계에서 반드시 CIDR을 분리하세요!

🌐 "서브넷마스크 = IP를 네트워크와 호스트로 나누는 경계선"

이 한 문장만 기억하면 됩니다.
CIDR의 /숫자 = 네트워크 비트 수, 나머지 = 호스트 비트 수.
2^(호스트 비트) = 총 IP 수, 여기서 2를 빼면 사용 가능한 IP 수.
AWS/k8s 설계 전에 이 계산 한 번만 해보는 습관이 나중에 큰 장애를 막습니다 💪

#서브넷마스크 #CIDR #서브네팅 #네트워크기초 #AWSVPC #EKS네트워크 #백엔드개발 #IPv4 #개발블로그 #네트워크설계 #데브옵스 #클라우드