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)를 의미한다. CIDR 표기법을 이진수로 표현하면 더 명확하게 이해할 수 있는데, 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 연산을 통해 네트워크 주소를 추출하는 데 사용된다. 일반적으로 많이 사용되는 CIDR 접두사와 서브넷 마스크의 대응 관계는 다음과 같으며, /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비트로 2^7 = 128개 주소에 126개 호스트를, /26은 호스트 비트 6비트로 2^6 = 64개 주소에 62개 호스트를, /27은 호스트 비트 5비트로 2^5 = 32개 주소에 30개 호스트를, /28은 호스트 비트 4비트로 2^4 = 16개 주소에 14개 호스트를, /29는 호스트 비트 3비트로 2^3 = 8개 주소에 6개 호스트를, /30은 호스트 비트 2비트로 2^2 = 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을 사용하면 실제 필요한 호스트 수에 맞춰 각 서브넷의 크기를 다르게 설정할 수 있어 IP 주소 낭비를 최소화할 수 있다. 예를 들어 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의 거듭제곱을 찾고(예: 필요한 호스트 50개 → 50 + 2 = 52 → 2^6 = 64), 그 거듭제곱의 지수가 호스트 비트 수가 되며(6비트), 마지막으로 32에서 호스트 비트 수를 빼면 CIDR 접두사가 된다(32 - 6 = /26). 구체적인 예시로 필요한 호스트가 10개라면 10 + 2 = 12이고 이상의 가장 작은 2의 거듭제곱은 2^4 = 16이므로 호스트 비트 4비트가 필요하며 CIDR은 /28(14개 호스트 사용 가능)이 되고, 필요한 호스트가 100개라면 100 + 2 = 102이고 이상의 가장 작은 2의 거듭제곱은 2^7 = 128이므로 호스트 비트 7비트가 필요하며 CIDR은 /25(126개 호스트 사용 가능)가 되며, 필요한 호스트가 500개라면 500 + 2 = 502이고 이상의 가장 작은 2의 거듭제곱은 2^9 = 512이므로 호스트 비트 9비트가 필요하며 CIDR은 /23(510개 호스트 사용 가능)이 되고, 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.64)와 일치하므로 192.168.1.75는 192.168.1.64/26 블록에 속한다. 반대로 192.168.1.200이 192.168.1.64/26 블록에 속하는지 확인하면 192.168.1.200은 이진수로 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)로 업그레이드해야 하며, 레거시 시스템과의 통합 시 호환성 문제가 발생할 수 있다. IPv4 주소 고갈 문제의 근본적 해결책은 아니며, CIDR은 IP 주소 활용 효율을 높여 고갈 시점을 늦췄을 뿐 32비트 주소 공간의 한계는 여전히 존재하고, 궁극적인 해결책은 128비트 주소 공간을 가진 IPv6로의 전환이지만 IPv4와 IPv6가 공존하는 현재 상황에서는 CIDR이 IPv4 네트워크 관리의 핵심 기술로 계속 사용되고 있다.
결론
CIDR은 1993년 도입 이후 30년 이상 인터넷 주소 할당과 라우팅의 핵심 기술로 자리잡았으며, 클래스 기반 주소 체계의 비효율성과 라우팅 테이블 폭발 문제를 해결하여 인터넷의 지속 가능한 성장을 가능하게 만들었다. CIDR의 핵심 개념인 가변 길이 서브넷 마스크(VLSM), 라우트 집약(Supernetting), 접두사 표기법은 현대 네트워크 설계의 기본 원칙이 되었으며, 기업 네트워크부터 클라우드 인프라, 컨테이너 오케스트레이션까지 모든 영역에서 광범위하게 활용되고 있다. CIDR을 깊이 이해하면 네트워크 설계 시 IP 주소 낭비를 최소화하고 효율적인 서브넷팅을 수행할 수 있으며, 라우팅 문제를 진단하고 해결하는 능력이 향상되고, 클라우드 환경(AWS VPC, Azure VNet, GCP VPC)에서 네트워크를 올바르게 구성할 수 있으며, 쿠버네티스나 도커 스웜 같은 컨테이너 플랫폼의 네트워크 구조를 이해하고 트러블슈팅할 수 있고, BGP 라우팅과 인터넷 백본 구조를 파악하는 데 도움이 된다. IPv6 전환이 진행 중인 현재에도 IPv4는 여전히 광범위하게 사용되고 있으며, CIDR은 IPv4 네트워크를 효율적으로 관리하는 데 필수불가결한 기술로 계속 중요한 역할을 수행할 것이다.