서브넷 마스크는 IPv4 주소 32비트 중 어디까지가 네트워크이고 어디부터가 호스트(개별 장비)인지를 표시하는 값입니다. 왼쪽에는 1이, 오른쪽에는 0이 이어집니다. 1인 자리가 네트워크 부분, 0인 자리가 호스트 부분입니다. 공유기 설정 화면에서 자주 보는 255.255.255.0도 2진수로 바꾸면 “1이 24개, 0이 8개”라는 뜻일 뿐입니다.
이 글은 서브넷 마스크를 2진수로 읽는 방법에서 시작해 CIDR 표기와의 변환, 네트워크 주소와 브로드캐스트 주소 구하기, 서브넷팅과 VLSM, /31·/32 예외, 클라우드에서 실제로 쓸 수 있는 주소 수까지 차례로 다룹니다. 본문의 계산 결과는 모두 IP 서브넷 계산기로 구한 값이며, 사이트 테스트가 계산기 코드로 다시 계산해 확인합니다. 예시 주소는 RFC 1918 사설 주소와 RFC 5737 문서용 주소입니다.
서브넷 마스크란: 네트워크 부분과 호스트 부분의 경계
같은 네트워크에 있는 장비끼리는 라우터를 거치지 않고 직접 통신하고, 다른 네트워크로 가는 패킷은 기본 게이트웨이로 보냅니다. 장비는 이 판단을 서브넷 마스크로 합니다. 내 IP 주소와 상대 IP 주소를 각각 서브넷 마스크와 AND 연산해서 나온 네트워크 주소가 같으면 같은 네트워크입니다.
서브넷 마스크는 1985년 RFC 950(Internet Standard Subnetting Procedure)에서 정의되었습니다. RFC 950은 서브넷 비트가 연속하지 않아도 된다고 하면서도 연속시키라고 권장했습니다. 현재 CIDR 규칙을 정한 RFC 4632는 “마스크는 왼쪽부터 연속해야 한다”(the mask must be left contiguous)고 못박았습니다. 1이 항상 왼쪽부터 이어지므로 마스크는 1의 개수만으로 표현할 수 있고, 그것이 /24 같은 CIDR 프리픽스 길이입니다.
2진수로 보는 서브넷 마스크
IP 주소 192.168.0.25, 서브넷 마스크 255.255.255.0을 2진수로 나란히 놓아 보겠습니다.
IP 주소 11000000.10101000.00000000|00011001 192.168.0.25
서브넷 마스크 11111111.11111111.11111111|00000000 255.255.255.0
네트워크 11000000.10101000.00000000|00000000 192.168.0.0
브로드캐스트 11000000.10101000.00000000|11111111 192.168.0.255세로선 왼쪽 24비트가 네트워크 부분입니다. 호스트 부분 8비트를 모두 0으로 만든 것이 네트워크 주소 192.168.0.0, 모두 1로 만든 것이 브로드캐스트 주소 192.168.0.255입니다. 이 둘은 장비에 줄 수 없으므로 실제로 쓸 수 있는 주소는 192.168.0.1부터 192.168.0.254까지 254개입니다.
서브넷 마스크와 CIDR 프리픽스 변환표
한 옥텟(8비트) 안에서 마스크가 가질 수 있는 값은 아래 9가지뿐입니다. 이 표만 알면 모든 변환을 암산할 수 있습니다.
| 1의 개수 | 2진수 | 10진수 | 해당 옥텟의 블록 크기 |
|---|---|---|---|
| 0 | 00000000 | 0 | 256 |
| 1 | 10000000 | 128 | 128 |
| 2 | 11000000 | 192 | 64 |
| 3 | 11100000 | 224 | 32 |
| 4 | 11110000 | 240 | 16 |
| 5 | 11111000 | 248 | 8 |
| 6 | 11111100 | 252 | 4 |
| 7 | 11111110 | 254 | 2 |
| 8 | 11111111 | 255 | 1 |
프리픽스를 마스크로 바꿀 때는 8비트마다 255를 쓰고, 나머지는 표에서 찾고, 남은 자리는 0으로 채웁니다. /21은 8 + 8 + 5이므로 255.255.248.0입니다. 반대로 255.255.255.224는 8 + 8 + 8 + 3이므로 /27입니다. 255.255.255.200(11001000)처럼 1 사이에 0이 끼어 있는 값은 마스크가 아닙니다.
ACL이나 OSPF 설정에서 쓰는 와일드카드 마스크는 서브넷 마스크의 비트를 뒤집은 값입니다. 각 옥텟을 255에서 빼면 되므로 /21은 0.0.7.255입니다.
네트워크 주소와 브로드캐스트 주소 구하기
2진수 AND가 원칙이지만, 표의 블록 크기를 쓰면 10진수로 바로 풀 수 있습니다. 172.20.15.77/22를 예로 들겠습니다.
/22는 8 + 8 + 6이므로 마스크는255.255.252.0이고, 마스크가 바뀌는 곳은 세 번째 옥텟입니다.- 블록 크기는 256 − 252 = 4입니다. 세 번째 옥텟은 0, 4, 8, 12, 16…으로 나뉩니다.
- 주소의 세 번째 옥텟 15는 12와 16 사이에 있으므로 네트워크 주소는
172.20.12.0입니다. - 브로드캐스트 주소는 다음 네트워크(
172.20.16.0) 바로 앞인172.20.15.255입니다. - 호스트 비트는 32 − 22 = 10비트이므로 2¹⁰ − 2 = 1,022개를 쓸 수 있습니다.
계산기에 172.20.15.77/22를 넣으면 네트워크 주소 172.20.12.0, 브로드캐스트 주소 172.20.15.255, 와일드카드 마스크 0.0.3.255, 사용 가능한 호스트 1,022개가 나옵니다. 계산기는 슬래시 뒤에 /22 같은 프리픽스만 받습니다. 255.255.252.0 형태로 받았다면 위 표로 먼저 바꿔서 입력하세요.
서브넷팅 계산: 서브넷 개수와 호스트 수
서브넷팅은 호스트 부분에서 비트를 빌려 네트워크를 더 잘게 나누는 작업입니다. 호스트 비트를 n개 빌리면 서브넷은 2ⁿ개가 되고, 서브넷마다 남은 호스트 비트 h개로 2ʰ − 2개의 호스트를 쓸 수 있습니다.
예제: 192.168.10.0/24를 6개 이상의 서브넷으로 나누고, 각 서브넷에 가능한 한 많은 호스트를 두려면?
- 2ⁿ ≥ 6을 만족하는 가장 작은 n은 3입니다(2³ = 8).
- 프리픽스는 24 + 3 =
/27, 마스크는255.255.255.224입니다. - 남은 호스트 비트는 5개이므로 서브넷마다 2⁵ − 2 = 30개의 호스트를 쓸 수 있습니다.
- 블록 크기 32로 나누면
192.168.10.0,.32,.64, ….224의 8개 서브넷이 나옵니다.
| 서브넷 | 네트워크 주소 | 사용 가능 범위 | 브로드캐스트 주소 |
|---|---|---|---|
| 1번째 | 192.168.10.0/27 | 192.168.10.1 ~ 192.168.10.30 | 192.168.10.31 |
| 2번째 | 192.168.10.32/27 | 192.168.10.33 ~ 192.168.10.62 | 192.168.10.63 |
| … | … | … | … |
| 8번째 | 192.168.10.224/27 | 192.168.10.225 ~ 192.168.10.254 | 192.168.10.255 |
오래된 교재에는 서브넷 개수에서도 2를 빼는(2ⁿ − 2) 설명이 남아 있습니다. RFC 950이 서브넷 필드가 전부 0이거나 전부 1인 값은 실제 서브넷에 할당하지 말라고 했기 때문입니다. 1995년 RFC 1878은 이 관행에 대해 “This practice is obsolete!”라고 적고, 현재 소프트웨어는 정의 가능한 모든 서브넷을 쓸 수 있다고 밝혔습니다. 위 예제처럼 3비트를 빌리면 서브넷은 8개입니다. 반면 호스트 수에서 2를 빼는 규칙은 지금도 유효합니다. 시험 문제를 풀 때는 문제가 어느 전제를 따르는지 확인하세요.
VLSM: 부서별로 크기가 다른 서브넷 나누기
부서마다 필요한 호스트 수가 다르면 서브넷마다 프리픽스 길이를 달리합니다(VLSM, 가변 길이 서브넷 마스크). 10.10.0.0/24 하나로 개발팀 100대, 영업팀 50대, 회의실 무선 20대, 라우터 간 링크 2개를 만든다고 하겠습니다.
- 호스트 수 + 2가 들어가는 가장 작은 블록을 고릅니다. 100대는
/25(126개), 50대는/26(62개), 20대는/27(30개), 링크는/31입니다(장비가 지원하지 않으면/30). - 큰 블록부터 앞에서부터 차례로 배치합니다. 2ⁿ개짜리 블록은 2ⁿ의 배수에서 시작해야 하므로, 큰 블록을 먼저 놓아야 빈틈이 생기지 않습니다.
- 배치한 범위를 계산기로 하나씩 확인합니다.
| 용도 | 필요 대수 | 할당 | 범위 | 사용 가능 |
|---|---|---|---|---|
| 개발팀 | 100 | 10.10.0.0/25 | 10.10.0.0 ~ 10.10.0.127 | 126 |
| 영업팀 | 50 | 10.10.0.128/26 | 10.10.0.128 ~ 10.10.0.191 | 62 |
| 회의실 무선 | 20 | 10.10.0.192/27 | 10.10.0.192 ~ 10.10.0.223 | 30 |
| 링크 1 | 2 | 10.10.0.224/31 | 10.10.0.224 ~ 10.10.0.225 | 2 |
| 링크 2 | 2 | 10.10.0.226/31 | 10.10.0.226 ~ 10.10.0.227 | 2 |
10.10.0.228부터 10.10.0.255까지 28개가 남습니다.
/31과 /32: 브로드캐스트 주소가 없는 블록
라우터 두 대를 일대일로 잇는 링크에는 상대가 하나뿐이라 브로드캐스트가 필요 없습니다. /30을 쓰면 주소 4개 중 2개가 네트워크와 브로드캐스트로 사라집니다. RFC 3021(2000년)은 이런 점대점 링크에 31비트 마스크를 허용하고, 두 주소를 “호스트 주소로 해석해야 한다”(MUST be interpreted as host addresses)고 정했습니다.
계산기도 RFC 3021을 따라 203.0.113.9/31의 사용 가능한 호스트를 2개(203.0.113.8, 203.0.113.9)로 표시합니다. /31과 /32에서는 브로드캐스트 주소 칸에 「없음」과 이유를 표시합니다. /32는 주소 하나만 가리키며 호스트 라우트나 방화벽 허용 목록에 씁니다. 198.51.100.7만 입력하고 드롭다운에서 /32를 고르면 네트워크 주소, 첫 번째·마지막 호스트가 모두 198.51.100.7이고 사용 가능한 호스트는 1개입니다.
클라우드 서브넷의 예약 주소: AWS·Azure·Google Cloud·네이버 클라우드
클라우드 VPC는 서브넷마다 라우터와 DNS 등에 쓸 주소를 추가로 예약합니다. 계산기의 사용 가능한 호스트 수에서 아래만큼 더 빼야 합니다.
| 서비스 | 서브넷당 사용할 수 없는 주소 | /24에서 사용 가능 | /26에서 사용 가능 |
|---|---|---|---|
| 일반 LAN(계산기 표시) | 2: 네트워크, 브로드캐스트 | 254 | 62 |
| AWS VPC | 5: 처음 4개와 마지막 1개 | 251 | 59 |
| Azure Virtual Network | 5: 네트워크, 기본 게이트웨이, Azure DNS용 2개, 브로드캐스트 | 251 | 59 |
| Google Cloud VPC | 기본 범위에서 4: 네트워크, 게이트웨이, 끝에서 두 번째, 브로드캐스트 | 252 | 60 |
| 네이버 클라우드 플랫폼 VPC | 7: 네트워크, 브로드캐스트, 내부 관리용 최초 5개 | 249 | 57 |
네이버 클라우드 플랫폼의 Subnet 생성 가이드는 “Network IP, Broadcast IP, 내부 관리를 위한 최초 5개의 IP는 가용 수량에서 제외되어, /24인 경우 249개, /25인 경우 121개, /26인 경우 57개의 IP 사용 가능”이라고 적고 있습니다. 같은 /26이라도 계산기의 62개, AWS의 59개, 네이버 클라우드의 57개로 차이가 납니다. 서버 대수가 서브넷 크기에 빠듯하다면 사용할 클라우드의 예약 개수를 먼저 확인하세요. AWS 서브넷은 /28/16, Azure는 최소 /29, Google Cloud는 /29/4 범위에서 만들 수 있습니다.
자주 하는 실수
- 슬래시 뒤에 점으로 된 마스크를 쓰기. 계산기는
/27같은 프리픽스 길이를 받으며/255.255.255.224는 오류로 처리합니다. - 앞에 0 붙이기.
192.168.010.001은 계산기와 Pythonipaddress모두 잘못된 주소로 거부합니다. 오래된 구현 중에는010을 8진수 8로 읽는 것이 있어 같은 문자열이 다른 장비를 가리킬 수 있습니다. - 서브넷 마스크와 와일드카드 마스크 혼동. ACL에
0.0.0.255를 써야 할 자리에255.255.255.0을 쓰면 전혀 다른 주소 범위와 일치합니다. - 겹치는 대역 연결. 두 VPC가 모두
10.0.0.0/16을 쓰면 피어링이나 VPN이 성립하지 않습니다. AWS 문서도 CIDR 블록이 일치하거나 겹치는 VPC 사이에는 피어링 연결을 만들 수 없다고 밝힙니다. 라우터에서는 CIDR의 최장 일치 규칙(RFC 4632 5.1절) 때문에 더 구체적인 경로가 조용히 우선하므로, 겹침은 오류 없이 일부 대역만 통신이 끊기는 형태로 나타납니다.
계산기는 IPv4 서브넷을 한 번에 하나씩 계산합니다. 대역을 자동으로 나누거나 두 범위가 겹치는지 판정하지는 않으므로, VLSM 표는 위 순서대로 만들고 각 행을 계산기로 확인하는 방식으로 쓰면 됩니다.