CIDR의 등장 배경과 역사
CIDR(Classless Inter-Domain Routing, 사이더)은 기존 클래스 기반 IP 주소 할당 방식의 한계를 극복하기 위해 1993년 IETF가 RFC 1517, RFC 1518, RFC 1519를 통해 공식 도입한 방식이다. 이후 1998년 RFC 2050으로 개정되며 인터넷 라우팅 표준으로 자리잡았다.
1980년대 말 인터넷이 급속히 성장하면서 기존 클래스 기반 주소 체계(Classful Addressing)는 두 가지 문제를 드러냈다. Class C 네트워크(254개 호스트)는 너무 작고 Class B 네트워크(65,534개 호스트)는 지나치게 커서 실제 수요와 맞지 않았고, 그 결과 많은 IP 주소가 낭비됐다. 동시에 인터넷 라우팅 테이블이 폭발적으로 증가해 라우터의 메모리와 처리 성능에도 큰 부담이 생겼다.
CIDR은 이런 문제를 해결하기 위해 클래스 개념을 제거하고 가변 길이 서브넷 마스크(VLSM, Variable Length Subnet Mask)를 도입했다. 이를 통해 필요한 규모에 맞춰 네트워크 크기를 조정할 수 있게 되었고, 라우트 집약(Route Aggregation) 또는 슈퍼넷팅(Supernetting)으로 여러 작은 네트워크를 하나의 라우팅 항목으로 묶어 라우팅 테이블 크기도 크게 줄일 수 있었다.
CIDR 표기법과 구조
CIDR은 IP 주소 뒤에 슬래시(/)와 네트워크 비트 수를 붙이는 접두사 표기법(Prefix Notation)을 사용한다. 이 표기법은 네트워크 부분과 호스트 부분을 간결하게 구분하고, 서브넷 마스크도 짧게 표현할 수 있게 해 준다. 예를 들어 192.168.1.0/24는 처음 24비트가 네트워크 부분이고 나머지 8비트(32 - 24 = 8)가 호스트 부분임을 뜻한다. 192.168.1.128/25는 처음 25비트가 네트워크 부분이고 나머지 7비트가 호스트 부분이다.
IP 주소는 32비트로 구성되므로 CIDR 접두사는 /0부터 /32까지 가능하다. /0은 전체 인터넷(0.0.0.0/0)을 의미하며 디폴트 라우트에 사용된다. /32는 단일 호스트를 나타내는 호스트 라우트로, 예를 들어 192.168.1.1/32와 같이 쓴다.
이진수로 보면 구조가 더 분명해진다. 192.168.1.64/26은 이진수로 11000000.10101000.00000001.01000000이며, 처음 26비트(11000000.10101000.00000001.01)가 네트워크 부분이다. 나머지 6비트(000000)는 호스트 부분이다. /26에 대응하는 서브넷 마스크는 11111111.11111111.11111111.11000000, 즉 255.255.255.192다. 이 값에서 네트워크 비트는 모두 1이고 호스트 비트는 모두 0이다.
CIDR과 서브넷 마스크의 관계
CIDR 접두사는 서브넷 마스크와 일대일로 대응된다. 서브넷 마스크는 IP 주소에서 네트워크 부분과 호스트 부분을 구분하는 32비트 값이며, AND 연산으로 네트워크 주소를 추출할 때 사용된다.
자주 쓰이는 대응 관계를 보면 /24는 서브넷 마스크 255.255.255.0(이진수: 11111111.11111111.11111111.00000000)에 해당하며, 256개(2^8) 주소 중 254개 호스트를 할당할 수 있다. /25는 255.255.255.128(이진수: 11111111.11111111.11111111.10000000)로 128개(2^7) 주소 중 126개 호스트를, /26은 255.255.255.192(이진수: 11111111.11111111.11111111.11000000)로 64개(2^6) 주소 중 62개 호스트를, /27은 255.255.255.224(이진수: 11111111.11111111.11111111.11100000)로 32개(2^5) 주소 중 30개 호스트를 할당할 수 있다.
각 네트워크에서 첫 번째 주소는 네트워크 주소(Network Address)로 해당 네트워크 자체를 식별하는 데 쓰인다. 마지막 주소는 브로드캐스트 주소(Broadcast Address)로 네트워크 내 모든 호스트에 메시지를 전송할 때 사용되므로 실제 호스트에 할당할 수 없다. 따라서 전체 주소 개수에서 2를 뺀 값이 일반적으로 사용 가능한 호스트 수가 된다.
네트워크 크기 계산과 이해
CIDR 접두사에 따른 네트워크 크기는 2의 거듭제곱으로 계산된다. 호스트 비트 수가 n일 때 전체 주소 개수는 2^n이고, 사용 가능한 호스트 수는 일반적으로 2^n - 2가 된다. 예를 들어 /24 네트워크는 호스트 비트가 8비트(32 - 24 = 8)이므로 2^8 = 256개의 주소를 가지며 254개의 호스트를 할당할 수 있다. /25는 호스트 비트 7비트로 128개 주소에 126개 호스트를, /26은 64개 주소에 62개 호스트를, /27은 32개 주소에 30개 호스트를, /28은 16개 주소에 14개 호스트를, /29는 8개 주소에 6개 호스트를, /30은 4개 주소에 2개 호스트를 할당할 수 있다.
/30 네트워크는 단 2개의 호스트만 사용할 수 있으므로 주로 라우터 간 Point-to-Point 연결(예: 본사와 지사를 연결하는 전용선, ISP 간 BGP 피어링)에 사용된다. /31 네트워크는 RFC 3021에서 Point-to-Point 링크에 한해 브로드캐스트 주소 없이 2개 주소 모두 호스트로 사용할 수 있도록 예외를 허용한다. /32는 단일 호스트를 나타내므로 호스트 라우트(특정 IP 주소로의 정확한 경로)나 루프백 인터페이스 할당에 사용된다.
서브넷팅(Subnetting) 이해하기
서브넷팅은 하나의 큰 네트워크를 여러 개의 작은 네트워크(서브넷)로 분할하는 과정이다. CIDR 접두사를 늘려 네트워크 부분을 확장하고 호스트 부분을 줄이는 방식으로 구현하며, 이를 통해 네트워크를 논리적으로 분리하고 브로드캐스트 도메인을 축소하며 보안을 강화할 수 있다. 또한 IP 주소를 더 효율적으로 관리할 수 있다.
예를 들어 192.168.1.0/24 네트워크(256개 주소, 254개 호스트)를 /26으로 서브넷팅하면 4개의 서브넷으로 나뉜다.
192.168.1.0/26: 주소 범위192.168.1.0 ~ 192.168.1.63, 네트워크 주소.0, 브로드캐스트.63, 사용 가능 주소.1 ~ .62, 62개 호스트192.168.1.64/26: 주소 범위192.168.1.64 ~ 192.168.1.127, 네트워크 주소.64, 브로드캐스트.127, 사용 가능 주소.65 ~ .126, 62개 호스트192.168.1.128/26: 주소 범위192.168.1.128 ~ 192.168.1.191, 네트워크 주소.128, 브로드캐스트.191, 사용 가능 주소.129 ~ .190, 62개 호스트192.168.1.192/26: 주소 범위192.168.1.192 ~ 192.168.1.255, 네트워크 주소.192, 브로드캐스트.255, 사용 가능 주소.193 ~ .254, 62개 호스트
서브넷팅을 할 때는 서브넷 경계가 2의 거듭제곱 단위로 정렬되어야 한다. /26 서브넷의 크기는 64이므로 시작 주소는 0, 64, 128, 192여야 한다. 임의의 주소(예: 50)에서 시작할 수 없으며, 이를 확인하려면 마지막 옥텟을 이진수로 바꿨을 때 호스트 비트가 모두 0인지 보면 된다.
슈퍼넷팅(Supernetting)과 라우트 집약
슈퍼넷팅은 서브넷팅의 반대 개념으로, 여러 개의 작은 네트워크를 하나의 큰 네트워크로 통합하는 과정이다. CIDR 접두사를 줄여 네트워크 부분을 축소하고 호스트 부분을 확장하는 방식으로 구현하며, 라우팅 테이블 크기를 줄여 라우터의 메모리 사용량과 경로 탐색 시간을 낮추는 데 중요한 역할을 한다.
예를 들어 연속된 4개의 /24 네트워크(192.168.0.0/24, 192.168.1.0/24, 192.168.2.0/24, 192.168.3.0/24)는 하나의 /22 네트워크(192.168.0.0/22)로 집약할 수 있다. 이를 이진수로 보면 192.168.0.0(11000000.10101000.00000000.00000000)부터 192.168.3.255(11000000.10101000.00000011.11111111)까지 처음 22비트(11000000.10101000.000000)가 공통이므로 /22로 표현할 수 있다.
라우트 집약은 ISP나 대규모 조직에서 인터넷 라우팅 테이블의 폭발적 증가를 막는 핵심 기술이다. BGP(Border Gateway Protocol) 라우팅에서도 널리 사용되며, 1990년대 초반 급격히 커지던 라우팅 테이블 문제를 CIDR과 라우트 집약으로 완화했다. 현재도 인터넷 백본 라우터의 라우팅 테이블 크기를 관리 가능한 수준으로 유지하는 데 필수적이다.
CIDR과 VLSM(Variable Length Subnet Mask)
VLSM은 하나의 네트워크 안에서 서로 다른 크기의 서브넷을 동시에 사용할 수 있게 하는 기술이다. CIDR의 핵심 기능 중 하나이며, IP 주소 활용도를 극대화하는 데 유용하다. 클래스 기반 주소 체계나 고정 길이 서브넷 마스크(FLSM)에서는 모든 서브넷이 같은 크기여야 했지만, VLSM을 사용하면 실제 필요한 호스트 수에 맞춰 각 서브넷 크기를 다르게 정할 수 있어 주소 낭비를 줄일 수 있다.
예를 들어 192.168.1.0/24 네트워크는 다음과 같이 VLSM으로 분할할 수 있다.
- 서버팜 네트워크: 100개 호스트가 필요하므로
192.168.1.0/25할당(126개 호스트 가능) - 사무실 네트워크: 50개 호스트가 필요하므로
192.168.1.128/26할당(62개 호스트 가능) - DMZ 네트워크: 10개 호스트가 필요하므로
192.168.1.192/27할당(30개 호스트 가능) - Point-to-Point 라우터 링크 3개: 각각 2개 호스트만 필요하므로
192.168.1.224/30,192.168.1.228/30,192.168.1.232/30할당(각 2개 호스트) - 나머지 주소 공간:
192.168.1.236/30 ~ 192.168.1.252/30, 향후 확장을 위해 예약 가능
VLSM을 적용할 때는 큰 서브넷부터 먼저 할당한 뒤 점차 작은 서브넷을 배치해야 주소 공간 단편화를 줄일 수 있다. 또한 서브넷 간 주소가 겹치지 않도록 주의해야 한다. 라우팅 프로토콜도 VLSM을 지원해야 하는데, RIPv2, OSPF, EIGRP, IS-IS, BGP는 지원하지만 RIPv1과 IGRP는 지원하지 않는다.
CIDR 블록 계산 방법
특정 호스트 수에 필요한 CIDR 블록은 다음 순서로 계산할 수 있다. 먼저 필요한 호스트 수에 2를 더한다. 이 2는 네트워크 주소와 브로드캐스트 주소 예약분이다. 그다음 이 값 이상이 되는 가장 작은 2의 거듭제곱을 찾는다. 예를 들어 필요한 호스트가 50개라면 50 + 2 = 52이고, 이를 수용하는 가장 작은 2의 거듭제곱은 2^6 = 64다. 따라서 호스트 비트 수는 6비트이며, 32 - 6 = /26이므로 필요한 CIDR 접두사는 /26이다.
구체적으로 필요한 호스트가 10개라면 10 + 2 = 12이고, 이를 수용하는 가장 작은 2의 거듭제곱은 2^4 = 16이므로 호스트 비트 4비트가 필요하다. 따라서 CIDR은 /28이며 14개 호스트를 사용할 수 있다. 필요한 호스트가 100개라면 100 + 2 = 102이고, 가장 작은 2의 거듭제곱은 2^7 = 128이므로 CIDR은 /25가 된다. 필요한 호스트가 500개라면 500 + 2 = 502이고, 이를 수용하는 값은 2^9 = 512이므로 CIDR은 /23이 된다. Point-to-Point 링크(라우터 간 연결)는 2개 호스트만 필요하므로 /30(2개 호스트) 또는 /31(RFC 3021, 2개 호스트)을 사용한다.
IP 주소가 특정 CIDR 블록에 속하는지 확인하기
IP 주소가 특정 CIDR 블록에 속하는지 확인하려면 AND 연산을 사용한다. IP 주소와 서브넷 마스크를 이진수로 변환한 뒤 AND 연산을 수행하고, 그 결과로 나온 네트워크 주소가 CIDR 블록의 네트워크 주소와 일치하는지 확인하면 된다.
예를 들어 192.168.1.75가 192.168.1.64/26 블록에 속하는지 보자. 먼저 192.168.1.75를 이진수로 변환하면 11000000.10101000.00000001.01001011이다. /26 서브넷 마스크는 11111111.11111111.11111111.11000000(255.255.255.192)이다. 이 둘을 AND 연산하면 11000000.10101000.00000001.01000000, 즉 192.168.1.64가 나온다. 이는 CIDR 블록의 네트워크 주소와 같으므로 192.168.1.75는 192.168.1.64/26 블록에 속한다.
반대로 192.168.1.200이 192.168.1.64/26 블록에 속하는지 확인하면, 이 주소는 이진수로 11000000.10101000.00000001.11001000이다. /26 마스크와 AND 연산하면 11000000.10101000.00000001.11000000, 즉 192.168.1.192가 나온다. 이는 192.168.1.64와 다르므로 192.168.1.200은 192.168.1.64/26 블록에 속하지 않고, 대신 192.168.1.192/26 블록에 속한다.
실제 활용 사례
기업 네트워크 설계
중규모 기업이 192.168.0.0/16 사설 IP 블록을 할당받았다면, CIDR과 VLSM을 활용해 다음과 같이 효율적으로 네트워크를 설계할 수 있다.
- 본사: 직원 500명,
192.168.0.0/23할당(510개 호스트), 사용 범위192.168.0.1 ~ 192.168.1.254 - 지사 A: 직원 100명,
192.168.2.0/25할당(126개 호스트), 사용 범위192.168.2.1 ~ 192.168.2.126 - 지사 B: 직원 50명,
192.168.2.128/26할당(62개 호스트), 사용 범위192.168.2.129 ~ 192.168.2.190 - 데이터센터 서버: 30대,
192.168.3.0/27할당(30개 호스트), 사용 범위192.168.3.1 ~ 192.168.3.30 - DMZ 웹 서버: 10대,
192.168.3.32/28할당(14개 호스트), 사용 범위192.168.3.33 ~ 192.168.3.46 - 라우터 간 Point-to-Point 링크: 각각
192.168.4.0/30,192.168.4.4/30,192.168.4.8/30할당(각 2개 호스트) - 나머지 주소 공간:
192.168.4.12/30 ~ 192.168.255.252/30, 향후 확장이나 새로운 지사 개설을 위해 예약
클라우드 환경(AWS VPC)
AWS VPC(Virtual Private Cloud)를 생성할 때는 CIDR 블록 설계가 매우 중요하다. 일반적으로 /16 블록(예: 10.0.0.0/16, 65,534개 호스트)을 VPC에 할당한 뒤 이를 여러 서브넷으로 나눈다.
- 퍼블릭 서브넷(인터넷 게이트웨이를 통한 외부 접근 가능): 웹 서버, 로드 밸런서, NAT 게이트웨이를 위해
10.0.1.0/24할당(254개 호스트) - 프라이빗 애플리케이션 서브넷(외부 접근 불가, NAT를 통한 아웃바운드만 가능): 애플리케이션 서버를 위해
10.0.10.0/24할당(254개 호스트) - 프라이빗 데이터베이스 서브넷: 데이터베이스 서버를 위해
10.0.20.0/24할당(254개 호스트)
고가용성을 위해 각 서브넷은 여러 가용 영역(Availability Zone)에 분산 배치한다. 예를 들어 ap-northeast-2a 영역에는 10.0.1.0/25, ap-northeast-2c 영역에는 10.0.1.128/25를 둘 수 있다. 서브넷 간 통신은 라우팅 테이블과 보안 그룹(Security Group)으로 제어한다. 또한 VPC 피어링이나 Transit Gateway로 여러 VPC를 연결할 때는 CIDR 블록이 겹치지 않도록 주의해야 한다.
쿠버네티스 Pod 네트워크
쿠버네티스 클러스터에서는 Pod, Service, Node에 각각 별도의 CIDR 블록을 할당한다. Pod CIDR은 클러스터 내 모든 Pod에 할당되는 IP 범위로, 일반적으로 10.244.0.0/16(65,534개 IP)을 사용하며 CNI(Container Network Interface) 플러그인(Calico, Flannel, Weave 등)이 이를 관리한다. Service CIDR은 ClusterIP 타입 서비스에 할당되는 가상 IP 범위로, 일반적으로 10.96.0.0/12(1,048,574개 IP)를 사용하며 kube-proxy가 iptables 또는 IPVS 규칙으로 트래픽을 라우팅한다. Node CIDR은 물리적 또는 가상 서버의 IP 범위로 기존 인프라의 네트워크 대역(예: 192.168.1.0/24)을 사용한다. 이 세 가지 CIDR 블록은 서로 겹치지 않아야 하며, 기존 회사 네트워크와도 충돌하지 않도록 설계해야 한다.
CIDR의 장점과 한계
장점
CIDR의 가장 큰 장점은 IP 주소 할당의 유연성과 효율성이다. 클래스 기반 주소 체계에서는 Class C(254개 호스트)와 Class B(65,534개 호스트) 사이에 중간 크기가 없었다. 그래서 1,000개 호스트가 필요한 네트워크에 Class B를 할당하면 64,000개 이상의 IP가 낭비됐다. 반면 CIDR을 사용하면 /22(1,022개 호스트)를 할당해 낭비를 크게 줄일 수 있다.
라우팅 테이블 크기를 줄일 수 있다는 점도 중요하다. 라우트 집약을 통해 여러 네트워크를 하나의 항목으로 통합할 수 있어 라우터의 메모리 사용량과 경로 탐색 시간이 감소한다. 1990년대 초반 인터넷 라우팅 테이블이 기하급수적으로 증가하던 문제도 CIDR 도입으로 완화됐으며, 현재도 전 세계 BGP 라우팅 테이블을 관리 가능한 수준(약 100만 개 항목)으로 유지하는 데 기여하고 있다.
VLSM 지원으로 네트워크 설계의 유연성도 크게 높아졌다. 하나의 네트워크 안에서 서로 다른 크기의 서브넷을 동시에 사용할 수 있고, 실제 필요한 호스트 수에 맞춰 서브넷 크기를 조정해 IP 주소 활용도를 극대화할 수 있다. 또한 클래스 개념이 사라지면서 네트워크 경계가 8비트 단위에 묶이지 않아 임의의 비트 위치에서 네트워크를 분할하거나 통합할 수 있게 되었다.
한계
CIDR의 한계는 주로 복잡성 증가에서 나타난다. 클래스 기반 주소 체계는 간단하고 직관적이어서 IP 주소만 보고도 네트워크 크기를 쉽게 짐작할 수 있었다. 예를 들어 192.168.1.x는 무조건 Class C로 이해하면 됐다. 하지만 CIDR은 접두사를 함께 확인해야 하고, 이진수 연산에도 익숙해야 정확한 계산이 가능하므로 네트워크 관리자의 학습 곡선이 더 높다.
라우팅 프로토콜 호환성 문제도 있다. 오래된 라우팅 프로토콜(RIPv1, IGRP)은 CIDR과 VLSM을 지원하지 않으므로 최신 프로토콜(RIPv2, OSPF, EIGRP, BGP)로 업그레이드해야 한다. 이 때문에 레거시 시스템과 통합할 때 호환성 문제가 발생할 수 있다.
또한 CIDR은 IPv4 주소 고갈의 근본적 해결책은 아니다. 주소 활용 효율을 높여 고갈 시점을 늦췄을 뿐, 32비트 주소 공간의 한계 자체를 없애지는 못했다. 궁극적인 해결책은 128비트 주소 공간을 가진 IPv6로의 전환이지만, IPv4와 IPv6가 공존하는 현재에도 CIDR은 IPv4 네트워크 관리의 핵심 기술로 계속 사용되고 있다.
결론
CIDR은 1993년 도입 이후 30년 넘게 인터넷 주소 할당과 라우팅의 핵심 기술로 쓰여 왔다. 클래스 기반 주소 체계의 비효율성과 라우팅 테이블 폭발 문제를 완화하며 인터넷의 지속적인 성장을 뒷받침했다. 가변 길이 서브넷 마스크(VLSM), 라우트 집약(Supernetting), 접두사 표기법 같은 CIDR의 핵심 개념은 오늘날 네트워크 설계의 기본 원칙이 되었다.
CIDR을 이해하면 네트워크 설계에서 IP 주소 낭비를 줄이고, 효율적인 서브넷팅을 수행하며, 라우팅 문제를 더 정확하게 진단할 수 있다. 또한 AWS VPC, Azure VNet, GCP VPC 같은 클라우드 환경과 쿠버네티스, 도커 스웜 같은 컨테이너 플랫폼의 네트워크 구조를 이해하는 데도 도움이 된다. IPv6 전환이 진행 중인 현재에도 IPv4는 여전히 널리 사용되고 있으며, CIDR은 IPv4 네트워크를 효율적으로 관리하는 데 계속 중요한 역할을 할 것이다.