관성적으로 쓰던 /24, 서브넷팅을 다시 이해해보기

2026. 7. 27. · 네트워크CloudCIDRAI-assisted

클라우드나 홈랩에서 네트워크를 구성할 때 /24를 자주 사용했다. AWS와 NHN Cloud에서 VPC와 서브넷을 만들 때도, 홈랩 서버 네트워크를 설정할 때도 비슷했다.

필요한 IP 주소 수를 계산해서 선택한 값은 아니었다. 규모가 크지 않았고 /24가 익숙했기 때문에 큰 고민 없이 사용했다. 서브넷 계산기가 있으니 필요하면 도구로 확인하면 된다고 생각하기도 했다.

정보처리기사 공부를 하면서 서브넷팅을 다시 접했다. 계산 공식을 외우는 것보다, 내가 계속 사용해온 /24가 어느 정도의 범위인지, prefix가 달라지면 규모가 어떻게 바뀌는지, 애초에 네트워크를 왜 나누는지부터 이해할 필요가 있다고 느꼈다.

이 글의 목표는 모든 서브넷 계산을 잘 암산하려는 게 아니다. prefix를 보고 대략적인 주소 규모를 가늠하고, 서브넷팅이 필요한 이유와 선택한 prefix의 근거를 설명할 수 있을 정도로 정리해보려 한다.

서브넷팅은 왜 필요한가

서브넷팅은 하나의 큰 IP 주소 대역을 필요한 크기의 작은 네트워크로 나누는 방식이다. 어디까지가 네트워크 영역이고 어디부터 호스트 영역인지를 prefix로 구분하고, 필요한 규모에 맞춰 주소 범위를 배정한다.

가장 먼저 떠올릴 수 있는 이유는 주소를 필요한 만큼 나눠 쓰기 위해서다. 서버가 몇 대 없는 구간과 수백 대가 필요한 구간에 같은 크기의 주소 대역을 배정할 필요는 없다. 현재 필요한 주소뿐 아니라 앞으로 늘어날 규모까지 고려해 범위를 잡으면 주소 낭비를 줄이면서 확장 공간도 남길 수 있다. CIDR도 정해진 클래스 단위 대신 실제 필요에 맞는 크기의 주소 블록을 사용할 수 있게 하고, 여러 경로를 하나로 묶어 라우팅 정보를 줄이기 위해 도입됐다. (RFC 4632)

서브넷은 주소만 나누는 것이 아니라 라우팅과 운영의 단위가 되기도 한다. 역할이나 연결 조건이 비슷한 서버를 같은 서브넷으로 묶으면 어떤 경로를 사용할지, 외부와 어떻게 통신할지, 문제가 생겼을 때 어느 범위부터 확인할지를 구분하기 쉬워진다. RFC 1918에서도 연결 요구사항이 비슷한 호스트를 별도의 서브넷으로 묶는 방식을 권고한다.

보안도 서브넷을 나누는 이유로 자주 언급되지만, 네트워크를 나눴다는 사실만으로 통신이 차단되는 것은 아니다. 실제 접근 범위는 라우팅 테이블, 방화벽, ACL, 보안 그룹 같은 정책과 함께 결정된다. 서브넷은 이런 정책을 적용할 경계를 만들고, 정책이 다르게 필요한 자원을 구분하는 기반에 가깝다.

결국 서브넷팅은 주소를 잘게 나누는 계산만을 의미하지 않는다. 필요한 주소 규모를 정하고, 통신 경로와 운영 범위를 구분하며, 이후 적용할 정책의 경계를 설계하는 과정이라고 이해하는 편이 더 정확하다.

같은 서브넷과 다른 서브넷

서버는 목적지 IP가 자신과 같은 서브넷에 있는지 먼저 판단한다. 같은 서브넷이면 목적지와 직접 통신하고, 다른 서브넷이면 패킷을 기본 게이트웨이로 보낸다. 게이트웨이 역할을 하는 라우터가 목적지 네트워크로 전달할 경로를 찾는 방식이다.

10.0.0.0/24를 두 개의 /25로 나누면 10.0.0.0/25와 10.0.0.128/25가 된다. 이때 통신 흐름은 다음처럼 달라진다.

10.0.0.10/25  ── 직접 ──▶ 10.0.0.100/25
   0~127 구간                 0~127 구간

10.0.0.10/25  ── 라우터 ──▶ 10.0.0.129/25
   0~127 구간                 128~255 구간

10.0.0.129/25에서 .129는 사라지는 주소가 아니다. 두 번째 서브넷인 10.0.0.128/25에 포함되는 호스트 주소다. 일반적인 IPv4 네트워크를 기준으로 .128은 네트워크 주소, .129부터 .254까지는 호스트 주소, .255는 브로드캐스트 주소가 된다.

같은 서브넷이라고 해서 항상 통신할 수 있는 것은 아니다. VLAN이나 서버 방화벽 같은 다른 설정으로 통신이 차단될 수 있다. 반대로 서로 다른 서브넷이어도 라우팅 경로가 있고 방화벽과 ACL 등의 정책이 허용하면 통신할 수 있다.

prefix 숫자를 어떻게 읽을 것인가

IPv4 주소는 32비트로 구성된다. /24에서 24는 앞의 24비트를 네트워크 영역으로 사용한다는 뜻이고, 나머지 8비트가 호스트 영역이 된다. 따라서 이 대역에 포함되는 전체 주소 수는 2^(32-24), 즉 2^8 = 256개다. (RFC 4632)

계산식을 매번 풀지 않더라도 한 가지 규칙은 기억하기 쉽다. prefix가 1 증가하면 호스트 비트가 1 줄고 주소 범위는 절반이 된다. 반대로 prefix가 1 감소하면 주소 범위는 두 배가 된다.

예를 들어 10.0.0.0/24의 전체 범위는 10.0.0.0부터 10.0.0.255까지다. 이를 /25 두 개로 나누면 10.0.0.0/25와 10.0.0.128/25가 되고, 각각 128개의 주소를 포함한다. /26으로 나누면 시작 주소가 0, 64, 128, 192로 바뀌면서 64개씩 네 구간이 된다.

여기서 계산한 수는 어디까지나 전체 주소 수다. 실제 장비나 인스턴스에 할당할 수 있는 주소 수는 환경에 따라 다르다. 일반적인 IPv4 서브넷에서는 네트워크 주소와 브로드캐스트 주소를 제외하지만 /31처럼 별도 용도가 있는 예외도 있다. AWS VPC는 IPv4 서브넷마다 처음 네 주소와 마지막 주소를 예약하므로 /24의 256개 중 일반적으로 251개를 사용할 수 있다. (AWS VPC 문서)

우선은 prefix 숫자를 봤을 때 정확한 마지막 주소를 바로 계산하는 것보다, /24는 256개 규모이고 /25, /26으로 갈수록 절반씩 줄어든다는 감각을 익히는 것이 중요하다고 생각했다.

자주 접하는 prefix와 사용 맥락

어떤 prefix를 자주 사용하는지는 네트워크의 규모와 목적에 따라 달라진다. 따라서 특정 값을 정답처럼 외우기보다, 주소 범위인지 실제 서브넷인지, 어느 정도의 주소가 필요한 상황인지를 함께 보는 편이 낫다.

사설 주소 블록과 서브넷 크기는 다르다

RFC 1918은 내부 네트워크에서 사용할 수 있도록 다음 세 IPv4 주소 블록을 예약했다.

여기서 /8, /12, /16은 사설 주소로 사용할 수 있는 전체 블록의 크기다. 각 네트워크를 반드시 그 크기로 만들어야 한다는 의미는 아니다. 예를 들어 10.0.0.0/8 안에서 10.10.1.0/24, 10.10.2.0/24처럼 더 작은 서브넷을 여러 개 만들 수 있다.

크기별로 보면

/31은 point-to-point 링크에서 두 주소를 모두 사용할 수 있도록 정의돼 있고, /32는 하나의 호스트를 나타내는 host route로 사용된다. (RFC 3021, RFC 4632)

플랫폼의 제약도 함께 확인해야 한다. AWS VPC의 IPv4 서브넷은 /16부터 /28까지만 만들 수 있으므로 /30, /31, /32를 VPC 서브넷 크기로 선택할 수는 없다. 대신 /32는 라우팅이나 보안 규칙에서 단일 IP를 가리킬 때 접할 수 있다. (AWS VPC 문서)

결국 prefix를 선택할 때는 현재 필요한 IP 수, 서비스가 예약하는 주소, 앞으로 늘어날 자원, 다른 네트워크와의 중복 가능성을 같이 봐야 한다. 표는 규모를 빠르게 가늠하기 위한 기준일 뿐이며, 실제 선택은 환경의 조건에 따라 달라진다.

왜 /24를 자주 선택했을까

/24는 서브넷 마스크로 표현하면 255.255.255.0이다. 네트워크 영역과 호스트 영역이 점으로 구분된 마지막 octet을 기준으로 나뉘기 때문에 범위를 알아보기 쉽다. 예를 들어 192.168.10.0/24라고 하면 마지막 숫자인 0부터 255까지가 하나의 범위라는 것을 바로 떠올릴 수 있다.

전체 주소 수가 256개라는 점도 홈랩이나 작은 클라우드 환경에서는 무난하게 느껴졌다. 서버가 몇 대 없는 상황에서는 당장 주소가 부족하지 않고, 네트워크마다 세 번째 octet을 다르게 두면 192.168.10.0/24, 192.168.20.0/24처럼 구분하기도 쉽다. 주소 효율보다 설정과 관리의 단순함이 더 중요하다면 /24를 선택하는 것 자체가 잘못은 아니다.

다만 익숙하다는 이유만으로 /24를 기본값처럼 사용하면 필요한 규모를 따져보지 않게 된다. 주소가 몇 개만 필요한 구간에는 지나치게 클 수 있고, 반대로 인스턴스나 네트워크 인터페이스가 계속 늘어나는 환경에서는 256개도 부족할 수 있다. 클라우드에서는 플랫폼이 예약하는 주소까지 제외해야 하므로 전체 주소 수만 보고 판단해서도 안 된다.

돌이켜보면 /24를 사용한 사실보다 왜 그 크기를 선택했는지 설명할 근거가 없었던 점이 더 큰 문제였다. 앞으로는 계산기를 사용하더라도 필요한 주소 수와 증가 가능성을 먼저 확인하고, 그 결과로 /24가 적절한지 판단하는 편이 맞다고 생각한다.

앞으로 서브넷을 만들 때 확인할 것

다음에 서브넷을 만들게 된다면 먼저 /24를 입력하기보다 아래 항목부터 확인하려고 한다.

1. 필요한 IP 수: 서버뿐 아니라 로드 밸런서, 네트워크 인터페이스처럼 주소를 사용하는 자원을 함께 센다.
2. 예약 주소와 플랫폼 제약: 전체 주소 수에서 실제 할당할 수 없는 주소가 몇 개인지, 만들 수 있는 최소·최대 prefix가 무엇인지 확인한다.
3. 증가 가능성: 현재 수량에 딱 맞추지 않고 앞으로 추가될 자원과 운영 여유를 고려한다.
4. 네트워크를 나눌 기준: 역할, 연결 경로, 접근 정책이 다른 자원을 같은 서브넷에 둘 필요가 있는지 판단한다.
5. 다른 대역과의 중복: 사내망, 홈랩, 다른 VPC, VPN으로 연결할 네트워크와 주소가 겹치지 않는지 확인한다.
6. 라우팅과 보안 정책: 서브넷을 나눈 뒤 필요한 통신 경로와 방화벽·ACL 정책을 함께 설계한다.

학습용 예시

AWS VPC에서 앞으로 사용할 IP가 30개 필요하다고 가정해봤다. /27은 전체 주소가 32개지만 AWS가 5개를 예약하므로 일반적으로 27개만 할당할 수 있다. 이 경우 /27은 부족하고, /26으로 넓히면 전체 64개 중 59개를 할당할 수 있어 필요한 수량과 증가 여유를 확보할 수 있다.

실제 환경에서는 서브넷 계산기로 범위와 주소 수를 확인하면 된다. 다만 계산 결과를 그대로 입력하기 전에 플랫폼의 예약 주소와 기존 네트워크 중복 여부를 확인하고, 선택한 prefix의 이유를 짧게라도 기록해두는 것이 필요하다.

정리

prefix 숫자가 커질수록 하나의 서브넷에 포함되는 주소 범위는 작아진다. 정확한 범위는 계산기로 확인하더라도 /24에서 /25, /26으로 갈수록 규모가 절반씩 줄어든다는 감각은 익혀둘 필요가 있다.

서브넷팅은 주소를 아끼기 위한 계산에 그치지 않는다. 네트워크를 필요한 크기와 역할에 따라 나누고, 각 구간의 라우팅과 접근 정책을 설계하기 위한 과정이다.

결국 /24를 사용하는 것 자체가 문제는 아니다. 필요한 주소 수, 증가 가능성, 플랫폼의 예약 주소, 다른 네트워크와의 중복 여부를 확인한 결과로 /24를 선택했다면 그 선택에는 근거가 있다. 앞으로는 익숙한 값을 먼저 정하기보다 필요한 조건을 확인한 뒤 prefix를 선택하려고 한다.