네트워크 인프라 이해하기 · 제1부 · 내 PC는 통신할 준비를 어떻게 할까

필요한 IP 주소 개수에 맞는 서브넷은 어떻게 계산할까

필요 주소 수를 Prefix와 블록 경계로 바꾸고 겹침·요약 가능성까지 확인하는 계산

필요한 주소 수만 보고 아무 Prefix나 고르면 주소가 부족하거나 넓은 범위를 낭비할 수 있습니다. Prefix Length에 따라 주소 블록의 크기가 정해지고, 그 경계에서 Network Address와 Broadcast Address, 사용할 수 있는 호스트 범위가 함께 결정됩니다. 이 글에서는 /26 계산부터 VLSM 배치, /31·/32의 쓰임과 Route Summary까지 실제 주소로 차근차근 확인합니다.

지금 필요한 주소만 계산하면 왜 Subnet이 금방 부족해질까↑

현재 단말 수만 세면 Subnet은 금방 부족해집니다. 게이트웨이, 네트워크 장비, 예약 주소와 단기 증설을 포함한 필요량을 정해야 합니다. DHCP Pool에 넣지 않을 주소도 같은 블록을 사용합니다.

예를 들어 현재 단말이 50대라면 /27의 32개 주소로는 부족합니다. /26은 총 64개 주소를 가지며 전통적인 다중 접근 Subnet에서는 네트워크와 브로드캐스트 주소를 제외한 범위를 호스트에 사용합니다.

주소 요구량은 “오늘 전원이 켜진 단말 수”보다 큽니다. 50명 사무실이라도 개인 단말, IP Phone, Printer, AP, Gateway와 장애 교체용 주소가 같은 Subnet을 사용할 수 있습니다. DHCP Lease가 즉시 회수되지 않는 시간과 향후 증원도 포함해야 합니다. 반대로 막연한 성장 가능성만으로 모든 부서에 /22를 주면 Broadcast 도메인과 주소 추적 범위가 불필요하게 커집니다.

설계 문서에는 현재 사용량, 향후 1~3년의 증가 예상, 기반 장비와 예약 주소, 동적 할당 범위, 미리 확보할 여유 공간을 따로 적습니다. 이 수량을 모두 담을 수 있는 가장 작은 주소 블록을 구한 뒤 운영 정책과 장애 범위를 검토합니다. 주소를 적게 쓰는 것만이 목적은 아닙니다. 증설할 여유를 남기면서도 하나의 L2 도메인이 지나치게 커지지 않도록 균형을 잡아야 합니다.

필요한 수량을 겨우 담는 작은 주소 블록은 빈 주소를 아낄 수 있지만, 증설할 여유도 적습니다. 반대로 너무 넓게 잡으면 브로드캐스트와 장애의 영향 범위가 커질 수 있습니다. 필요한 주소 수에 확장 여유를 더하고, 장애 범위·보안 정책·경로 요약을 함께 고려해 블록 크기를 정합니다.

이 절의 근거 IETF RFC 4632

Prefix가 한 비트 길어질 때 주소 블록은 얼마나 작아질까↑

IPv4는 32비트이므로 Prefix가 /p일 때 전체 주소 수는 2^(32-p)입니다. /26은 호스트 부분이 6비트이므로 2^6 = 64개 주소를 가집니다.

Prefix가 한 비트 길어질 때마다 주소 블록은 절반이 됩니다. /24의 256개 주소를 /25 두 개로 나누면 각각 128개, 다시 /26으로 나누면 각각 64개입니다. 이 관계를 알면 표를 외우지 않아도 인접 Prefix를 계산할 수 있습니다. 예를 들어 /23은 호스트 Bit가 9개이므로 2^9 = 512개 주소이며 세 번째 옥텟이 2씩 증가하는 경계를 가집니다.

전통적인 Broadcast LAN에서는 전체 주소 수에서 Network Address와 Directed Broadcast Address를 제외해 호스트 수를 계산합니다. 하지만 /31 Point-to-Point처럼 별도 표준이 정의한 예외가 있으므로 공식 하나를 모든 링크에 적용하면 안 됩니다. 또한 일반 동적 할당에 쓸 수 있는 DHCP 주소 수는 설정한 임대 범위에서 Gateway·Static 주소, Reservation, 제외 범위 등 일반 동적 할당에서 빠지는 주소를 중복 없이 제외해 계산합니다. Prefix의 전체 주소 수와 일반 동적 Lease용 주소 수, 예약 클라이언트용 주소 수를 구분해서 기록해야 합니다.

Prefix가 한 비트 길어질 때마다 블록은 절반으로 줄어듭니다. 필요한 수를 만족하는 Prefix를 찾은 뒤에도 시작 주소가 그 블록의 배수에 맞는지 확인해야 유효한 네트워크 경계가 됩니다.

이 절의 근거 IETF RFC 4632

192.0.2.64/26
    Network       192.0.2.64
    호스트 범위     192.0.2.65 – 192.0.2.126
    Broadcast     192.0.2.127
    다음 블록     192.0.2.128/26

크기가 다른 Subnet은 왜 가장 큰 블록부터 배치해야 할까↑

VLSM은 한 상위 블록 안에서 서로 다른 Prefix 길이를 사용하는 설계입니다. 100명, 50명, 20명 부서가 있다면 가장 큰 /25부터 배치하고, 다음 경계에 /26과 /27을 놓습니다.

작은 블록을 먼저 여기저기 배치하면 큰 블록에 필요한 연속 공간이 남지 않을 수 있습니다. 주소가 비어 있어도 요약 가능한 연속 Prefix를 만들지 못하는 파편화가 생깁니다.

10.50.0.0/24에 100대, 50대, 20대를 넣는다면 먼저 100대용 10.50.0.0/25를 배치합니다. 이어서 50대용 10.50.0.128/26, 20대용 10.50.0.192/27을 놓으면 10.50.0.224/27이 연속된 여유 공간으로 남습니다. 작은 /27을 중간 경계에 먼저 놓았다면 /25가 들어갈 정렬된 공간을 잃을 수 있습니다.

큰 블록부터 배치한다는 규칙만으로 좋은 설계가 완성되지는 않습니다. 지역·보안 영역·Route Summary 경계가 다른 Subnet을 단순히 빈칸에 끼워 넣으면 주소는 맞아도 운영 경계가 흐려집니다. VLSM 배치표에는 용도, VLAN, Gateway, DHCP 범위, 상위 Summary와 성장 방향을 함께 적습니다. 계산의 목표는 빈 주소를 최소화하는 것보다 다음 변경에서도 연속성과 책임을 유지하는 데 있습니다.

예를 들어 10.20.0.0/22를 지점에 배정했다면 각 층이나 기능의 Subnet을 그 안에서 연속되게 배치해 상위 장비가 10.20.0.0/22 하나로 Summary할 수 있게 합니다. 현재 주소만 빈틈없이 채우는 설계보다, 소유 경계와 Route 집약을 보존하는 설계가 변경과 장애 격리에 유리합니다. 남은 조각도 다음 증설이 요구할 블록 경계로 사용할 수 있는지 확인합니다.

이 절의 근거 IETF RFC 4632

주소가 두 개뿐인 /31과 하나뿐인 /32는 어디에 쓰일까↑

/31은 주소가 두 개뿐이지만 RFC 3021은 Point-to-Point 링크에서 두 주소를 양 끝 인터페이스에 사용할 수 있도록 정의합니다. 브로드캐스트가 필요한 일반 사용자 LAN에 그대로 적용하는 규칙은 아닙니다.

/32는 호스트 하나를 정확히 가리키는 Prefix입니다. Loopback 주소, 정적 호스트 Route와 보안 정책에서 자주 사용합니다. Prefix 길이만 보고 “사용 가능한 호스트가 없다”고 판단하지 말고 링크 유형과 용도를 확인해야 합니다.

/31 Point-to-Point에서는 두 주소를 각각 링크 양 끝에 사용하며 네트워크와 Broadcast 역할을 따로 예약하지 않습니다. 양쪽 장비가 RFC 3021 동작을 지원하고 링크가 실제로 두 Endpoint만 갖는지 확인해야 합니다. 오래된 장비나 관리 도구가 /31을 잘못 해석할 수 있으므로 배치 전 상호 운용성도 검증합니다. 여러 호스트가 Broadcast를 필요로 하는 Ethernet 세그먼트에 주소 절약만 보고 적용하는 방식은 맞지 않습니다.

/32는 주소 범위가 아니라 정확히 한 호스트를 가리키는 Route로 자주 쓰입니다. 라우터 Loopback을 /32로 광고하면 물리 인터페이스 하나가 Down 상태가 되어도 다른 경로로 같은 라우터 ID와 관리 주소에 도달할 수 있습니다. 방화벽의 단일 호스트 Match나 Blackhole Route에도 쓰입니다. /31과 /32는 “호스트 Bit가 없으니 쓸 수 없다”는 계산 예외가 아니라, 링크와 Route의 명확한 사용 목적을 표준이 따로 정의한 사례입니다.

/32는 주소 하나를 정확히 가리키며 Loopback, 호스트 Route, 정책 객체 등에 사용됩니다. 인터페이스에 /32를 설정해도 L2 연결만으로 인접 장비와 IP 통신이 보장되지는 않습니다. Peer Route, Unnumbered 방식 또는 별도 Neighbor 처리처럼 도달 조건을 함께 설계해야 합니다. 양 끝의 지원 여부와 실제 FIB 결과로 예외 동작을 확인합니다.

이 절의 근거 IETF RFC 3021

용어사전↑