서브넷은 왜 나누는가
서브넷은 네트워크 안의 더 작은 네트워크다. 서브넷으로 나누면 트래픽이 불필요한 라우터를 거치지 않고 더 짧은 경로로 목적지에 간다. 큰 네트워크 하나에 장치가 수백만 대 있으면 데이터가 올바른 장치를 찾는 데 시간이 걸리기 때문에 주소를 일정한 범위로 좁혀 주는 것이 서브넷의 역할이다.
클라우드에서는 이 개념이 설계로 이어진다. AWS VPC에서 서브넷은 VPC 안의 IP 주소 범위이고 서브넷 하나는 가용 영역(AZ) 하나 안에만 있어야 하며 여러 AZ에 걸칠 수 없다. 그래서 가용 영역별로 서브넷을 따로 만들어 한 AZ가 장애가 나도 다른 AZ의 서비스는 유지되게 한다.
IP 주소에서 네트워크와 호스트를 나누는 법
IPv4 주소는 두 부분으로 이루어진다. 앞부분은 어느 네트워크인지를, 뒷부분은 그 네트워크 안의 어느 장치(호스트)인지를 가리킨다. 문제는 앞부분이 어디까지인지가 주소만으로는 안 보인다는 점이고 그 경계를 알려 주는 것이 서브넷 마스크다. Cloudflare 문서는 192.0.2.15를 예로 들어, 서브넷 마스크 255.255.255.0으로 계산하면 앞의 192.0.2가 네트워크이고 15가 장치 번호라고 보여 준다. 이 네트워크는 192.0.2.0/24로 표기한다.
서브넷 마스크는 패킷에 담겨 인터넷을 건너가지 않는다. 패킷에는 목적지 IP만 있고 네트워크 안의 라우터가 그 IP를 자기 서브넷 마스크와 맞춰 보고 어느 서브넷으로 보낼지 정한다.
서브넷 마스크와 CIDR 표기
마스크는 2진수로 쓰면 앞쪽 1이 쭉 이어지고 뒤쪽이 0이다. 255.255.255.0은 11111111.11111111.11111111.00000000이고 여기서 1의 개수가 24개라서 /24로 줄여 쓴다. 이 표기가 CIDR 표기이고, / 뒤의 숫자가 네트워크 부분의 비트 수다. Cloudflare 문서는 클래스(A/B/C) 개념으로 설명하지만, AWS VPC 문서는 서브넷 주소를 CIDR 표기로 쓴다. 클라우드 실무에서는 CIDR 위주로 읽으면 된다.
| CIDR | 서브넷 마스크 | 호스트 비트 | 전체 주소 수 | AWS에서 사용 가능한 수 |
|---|---|---|---|---|
| /16 | 255.255.0.0 | 16 | 65,536 | 65,531 |
| /20 | 255.255.240.0 | 12 | 4,096 | 4,091 |
| /24 | 255.255.255.0 | 8 | 256 | 251 |
| /25 | 255.255.255.128 | 7 | 128 | 123 |
| /26 | 255.255.255.192 | 6 | 64 | 59 |
| /27 | 255.255.255.224 | 5 | 32 | 27 |
| /28 | 255.255.255.240 | 4 | 16 | 11 |
AWS는 서브넷 크기를 /28에서 /16 사이로 허용하고 각 서브넷에서 앞의 4개와 마지막 1개, 총 5개 주소를 못 쓰게 예약한다. 표의 마지막 열은 전체 주소 수에서 이 5개를 뺀 값이다. 예약되는 5개는 /24 기준으로 이렇게 쓰인다.
| 주소 | 용도 |
|---|---|
| 10.0.0.0 | 네트워크 주소 |
| 10.0.0.1 | VPC 라우터용으로 AWS가 예약 |
| 10.0.0.2 | AWS 예약(DNS 서버 주소 규칙) |
| 10.0.0.3 | 향후 사용을 위해 AWS가 예약 |
| 10.0.0.255 | 브로드캐스트 주소(VPC는 브로드캐스트를 지원하지 않아 예약) |
주소 개수 계산하는 법
계산은 세 줄이면 된다. 호스트 비트는 32 - 프리픽스 길이이고 전체 주소 수는 2의 호스트 비트 제곱이다. 마지막 옥텟에서 끊기는 /25~/30 구간은 256 - 마스크의 마지막 숫자가 블록 크기(주소 간격)가 된다. 예를 들어 /26은 마스크 마지막 숫자가 192라서 256 - 192 = 64이고, 서브넷이 64 간격으로 0/64/128/192에서 시작한다.
범위 해석 연습
연습 1. AWS 문서 예제. VPC가 10.0.0.0/24이면 256개 주소를 지원하고 이를 두 서브넷으로 쪼개면 각각 128개다. 10.0.0.0/25는 10.0.0.0 ~ 10.0.0.127이고, 10.0.0.128/25는 10.0.0.128 ~ 10.0.0.255다. 그러면 10.0.0.200은 어느 서브넷일까. 200은 128 ~ 255 구간에 있으니 10.0.0.128/25다.
연습 2. 직접 계산한 예제. 192.168.10.100/26이 속한 범위를 구해 보자.
| 단계 | 계산 |
|---|---|
| 블록 크기 | 256 - 192 = 64 |
| 네트워크 시작 | 100은 64 ~ 127 구간이므로 192.168.10.64 |
| 범위 | 192.168.10.64 ~ 192.168.10.127 |
| 마지막 주소 | 192.168.10.127(일반 네트워크에서는 브로드캐스트) |
정리하면 서브넷 해석은 블록 크기 구하기 → 내 주소가 들어가는 구간 찾기 → 시작/끝 주소 읽기 순서다.
AWS에서 서브넷은 어떻게 설계하는가
AWS 문서 기준으로 서브넷 CIDR은 VPC CIDR과 같거나 그 안의 일부여야 하고 한 VPC의 서브넷끼리는 범위가 겹치면 안 된다. 서브넷의 종류는 라우팅으로 정해진다. 인터넷 게이트웨이로 가는 직접 경로가 있으면 퍼블릭 서브넷, 없으면 프라이빗 서브넷이고, 프라이빗 서브넷의 리소스가 인터넷에 나가려면 NAT 장치가 필요하다. AWS는 리소스를 보호하기 위해 프라이빗 서브넷을 쓰라고 권장한다.
아래는 이 규칙을 적용해 직접 짜 본 예시 설계다.
| 서브넷 | CIDR | AZ | 용도 |
|---|---|---|---|
| public-a | 10.0.0.0/24 | a | 로드밸런서/NAT |
| public-b | 10.0.1.0/24 | b | 로드밸런서/NAT |
| private-a | 10.0.10.0/24 | a | 웹/앱 서버 |
| private-b | 10.0.11.0/24 | b | 웹/앱 서버 |
VPC는 10.0.0.0/16으로 잡으면 위 네 서브넷이 모두 그 안에 들어가고 서로 겹치지 않는다. 가용 영역별로 퍼블릭/프라이빗을 나눈 구조라고 이해했다. 서브넷 단위 보안은 네트워크 ACL이, 리소스 단위 보안은 보안 그룹이 맡고, 대부분은 보안 그룹으로 충분하다.
핵심 복습
| 키워드 | 한 줄 정리 |
|---|---|
| 서브넷 | 네트워크 안의 더 작은 네트워크, 불필요한 라우터 경유를 줄임 |
| 서브넷 마스크 | 주소의 네트워크/호스트 경계, 라우터가 서브넷을 구분할 때 씀 |
| CIDR | 마스크의 1 개수를 /n으로 표기(/24 = 255.255.255.0) |
| 주소 수 계산 | 2의 (32 - n)제곱, AWS는 그중 5개 예약 |
| 범위 해석 | 블록 크기 구하기 → 구간 찾기 → 시작/끝 읽기 |
| 퍼블릭/프라이빗 | 인터넷 게이트웨이로 가는 직접 경로 유무로 구분 |
| 설계 규칙 | 서브넷 CIDR은 VPC 안에 들어가고 서로 겹치지 않음, 서브넷 1개는 AZ 1개 |
📍 참고 자료
확인일: 2026-10-02
