예전에는 IP 주소의 첫 숫자만 보고 네트워크 크기를 짐작했어요. 지금은 그렇게 읽으면 오히려 길을 잘못 잡기 쉬워요.IP 주소와 라우팅에서는 IPv4 주소를
142.250.196.78처럼 점 4개로 나뉜 숫자로 봤어요.
그리고 공인 IP, 사설 IP, 그리고 NAT에서는 10.0.0.0/8, 172.16.0.0/12, 192.168.0.0/16 같은 사설 주소 범위를 봤죠.
근데요, 네트워크를 조금 찾아보다 보면 이런 말을 만나게 돼요.
10.x.x.x는 A 클래스예요.172.16.x.x는 B 클래스 쪽이에요.192.168.x.x는 C 클래스예요.- C 클래스니까 마스크는
255.255.255.0이죠?
192.168.0.0/16처럼 192.168으로 시작해도 /16으로 쓸 수 있고, 10.10.12.0/24처럼 10으로 시작해도 /24로 쓸 수 있거든요.
오늘은 클래스 주소 체계가 한마디로 무엇이었는지, 왜 처음에는 그런 방식이 자연스러웠는지, 왜 인터넷이 커지면서 CIDR로 넘어갔는지, 그리고 지금 주소를 읽을 때 무엇을 기준으로 삼아야 하는지 같이 볼게요.
초기 IPv4 주소 형식은 RFC 791 3.2절의 주소 설명을 출발점으로 보고, CIDR 전환의 문제의식은 RFC 1519와 그 후속 정리인 RFC 4632를 기준으로 잡을게요.
여기서는 IPv4의 classful addressing에서 CIDR로 넘어간 이유를 큰 흐름으로 볼게요.
BGP 경로 전파, RIR 주소 할당 정책, 실제 인터넷 라우팅 테이블 운영까지 깊게 들어가지는 않아요.
그쪽은 뒤에서 longest prefix match와 경로 선택을 볼 때 더 자연스럽게 이어질 거예요.
왜 아직도 A/B/C 클래스 이야기가 나올까요?
클래스 주소 체계는 오래된 설명 방식인데, 아직도 교재나 네트워크 설정 글에서 자주 보여요. 이유는 간단해요. 처음 배울 때는 숫자 첫 칸으로 대략적인 크기를 나누는 방식이 꽤 직관적으로 보이거든요. 예전 감각은 대충 이랬어요.
여기까지만 보면 꽤 단순하죠.
첫 숫자 범위로 “큰 네트워크인지, 중간인지, 작은지”를 빠르게 나눌 수 있으니까요.
문제는 이 단순함이 너무 거칠었다는 데 있어요.
인터넷이 작을 때는 괜찮아 보였지만, 연결되는 조직과 네트워크가 늘어나면서 낭비와 라우팅 테이블 문제가 같이 커졌어요.
클래스 방식은 한마디로 뭐였을까요?
짧게 잡으면 이래요.클래스 주소 체계는 IPv4 주소의 앞쪽 비트 모양만 보고 네트워크 크기를 미리 정해두는 방식이었어요.
비유로 보면 클래스 방식은 이래요.
이사할 사람에게 집을 줄 때, 선택지가 세 종류밖에 없는 거예요.
- 아주 큰 건물
- 중간 건물
- 작은 건물
예전 클래스 경계는 실제로 어떻게 나뉘었을까요?
IPv4 주소는 32비트예요. 클래스 방식은 이 32비트의 맨 앞 비트를 보고 큰 종류를 나눴어요. 이 그림에서 핵심은 주소 안에 네트워크 크기 힌트가 박혀 있었다는 점이에요. 별도 prefix를 붙이지 않아도, 첫 비트 패턴으로 기본 크기를 짐작하는 식이었죠. 표로 보면 이렇게 잡을 수 있어요.클래스 방식은 왜 처음엔 그럴듯했을까요?
처음부터 이상한 방식이었던 건 아니에요. 초기 인터넷에서는 네트워크 수도 지금보다 훨씬 적었고, 주소를 쓰는 조직도 제한적이었어요. 그때는 몇 가지 크기의 상자로 나눠도 운영이 단순해지는 장점이 있었죠. 이 방식의 장점은 설명과 판단이 쉬웠다는 거예요. 라우터나 운영자가 주소의 앞부분을 보고 “대충 이 정도 크기 네트워크구나” 하고 추정할 수 있었으니까요. 하지만 쉬운 규칙은 대개 유연하지 않아요. 인터넷이 커지자, 바로 그 고정 크기가 문제가 됐어요.어디서 낭비가 생겼을까요?
가장 큰 문제는 필요한 크기와 받을 수 있는 크기가 잘 안 맞았다는 점이에요. 예를 들어 어떤 조직이 호스트 주소 2,000개 정도를 필요로 한다고 해볼게요.- Class C 하나는 256개라 부족해요.
- Class B 하나는 65,536개라 너무 커요.
CIDR은 무엇을 바꿨을까요?
CIDR은 Classless Inter-Domain Routing의 줄임말이에요. 이름 그대로 클래스 없이 prefix 길이로 주소 묶음을 읽는 방식이에요. 예전에는 이런 식으로 생각했어요./20이 범위를 결정해요.
이 그림에서 보듯 CIDR에서는 같은 203으로 시작하는 주소라도 /24일 수도 있고 /20일 수도 있어요.
중요한 건 주소 자체가 아니라 prefix 길이를 함께 읽는 것이에요.
왜 CIDR이 주소를 더 알뜰하게 쓰게 해줬을까요?
CIDR은 필요한 크기에 더 가까운 주소 블록을 줄 수 있게 해줘요. 예를 들어 2,000개 정도 주소가 필요하다면,2^11 = 2048이니까 /21 블록이 꽤 잘 맞아요.
/21은 호스트 비트가 11개니까 전체 주소가 2,048개예요.
Class B의 65,536개보다 훨씬 덜 낭비되죠.
여기서 네트워크 주소와 호스트 범위 글에서 봤던 계산이 그대로 이어져요.
prefix가 짧아질수록 주소 묶음은 커지고, prefix가 길어질수록 주소 묶음은 작아져요.
CIDR은 라우팅 표도 줄여줬어요
CIDR의 또 다른 핵심은 주소를 잘 모으면 라우팅 표 한 줄로 표현할 수 있다는 점이에요. 예를 들어 아래 네 개의/24가 연속해서 붙어 있다고 해볼게요.
사설 IP 범위는 클래스와 헷갈리기 쉬워요
이제 공인 IP, 사설 IP, 그리고 NAT에서 본 사설 주소 범위를 다시 볼게요.
여기서 조심할 점이 있어요.
RFC 1918 사설 주소 범위는 사설로 예약된 큰 범위를 말해요.
내 집이나 회사가 그 안에서 실제로 어떤 크기의 서브넷을 쓰는지는 별개예요.
예를 들어 집 공유기는 흔히 이렇게 써요.
10으로 시작한다고 무조건 거대한 /8 하나로 운영하는 게 아니고,
192.168으로 시작한다고 무조건 /24만 가능한 것도 아니에요.
사설 주소 범위는 큰 땅이고, 실제 서브넷은 그 안에서 다시 잘라 쓰는 구획이라고 보면 돼요.
지금은 어떻게 읽어야 할까요?
현대 네트워크에서 안전한 읽기 순서는 이래요.- IP 주소만 보지 말고 prefix를 같이 봐요.
10.10.12.73/26처럼/26이 붙어야 범위가 결정돼요.
- 사설 주소인지 공인 주소인지 구분해요.
10.0.0.0/8,172.16.0.0/12,192.168.0.0/16안인지 봐요.
- 실제 서브넷 크기는 class 이름이 아니라 prefix로 판단해요.
/24,/20,/27이 진짜 경계선이에요.
- 라우팅에서는 더 구체적인 prefix가 이길 수 있다는 걸 준비해요.
- 이건 다음 IP 주소 글의 핵심 질문이에요.
여기서 자주 헷갈리는 함정들
192.168.x.x라서 무조건 /24는 아니에요
집 공유기에서 /24를 많이 쓰니까 그렇게 느껴질 뿐이에요.
192.168.0.0/23처럼 두 개의 /24를 붙여 더 넓게 쓸 수도 있고, 192.168.10.0/27처럼 더 작게 쓸 수도 있어요.
172.x.x.x가 전부 사설 주소는 아니에요
사설 범위는 172.16.0.0/12, 즉 172.16.0.0부터 172.31.255.255까지예요.
172.15.x.x나 172.32.x.x는 그 사설 범위 밖이에요.
이건 172라는 첫 숫자만 보면 놓치기 쉬운 부분이에요.
“클래스 C 네트워크”라는 말은 문맥을 확인해야 해요
현장에서는 아직도C 클래스 하나라는 말을 “/24 하나”라는 뜻으로 느슨하게 쓰는 경우가 있어요.
하지만 엄밀한 classful 주소 체계와 현대 CIDR 운영은 같은 말이 아니에요.
누군가 “C 클래스”라고 말하면, 실제 설정에서는 정말 /24를 뜻하는지 확인하는 편이 좋아요.
CIDR은 서브넷 표기만이 아니라 라우팅 표기이기도 해요
203.0.112.0/22는 단순히 주소 개수만 말하는 표기가 아니에요.
라우터에게는 이 prefix에 속한 목적지는 이쪽으로 보내라는 경로 표기이기도 해요.
그래서 다음에는 여러 prefix가 겹칠 때 어떤 경로가 선택되는지를 봐야 해요.
자, 정리해볼까요?
- 예전 classful 방식은 IPv4 주소의 앞 비트로 A/B/C 같은 큰 종류와 기본 크기를 나눴어요.
- Class A는
/8, Class B는/16, Class C는/24에 가까운 고정 크기 감각이 있었어요. - 이 방식은 필요한 크기와 실제 할당 크기가 잘 맞지 않아 IPv4 주소 낭비를 키웠어요.
- CIDR은 클래스 대신
/20,/24,/26같은 prefix 길이로 주소 범위를 명시해요. - CIDR은 주소를 더 알뜰하게 나눌 뿐 아니라, 연속된 경로를 하나로 요약해 라우팅 테이블 증가도 줄여줘요.
- 지금은 첫 숫자나 클래스 이름보다 주소 + prefix + 문맥을 함께 읽는 게 훨씬 안전해요.
192.168으로 시작한다고 무조건 /24라고 읽으면 안 되는 이유가 보이죠?
예전 클래스 이름은 역사 표지판이고, 지금 실제 경계선은 CIDR prefix예요.
이어서 보면 좋은 글
- 서브넷 마스크와 CIDR은 실제로 어떻게 계산할까요? —
/24와255.255.255.0이 같은 뜻인 이유를 비트 단위로 다시 잡을 수 있어요. - 네트워크 주소, 브로드캐스트 주소, 호스트 범위는 어떻게 나뉠까요? — prefix가 정해졌을 때 실제 시작 주소와 끝 주소를 계산하는 법을 이어서 볼 수 있어요.
- 공인 IP, 사설 IP, 그리고 NAT는 왜 같이 나올까요? — RFC 1918 사설 주소 범위가 집 안 주소와 NAT 문맥에서 어떻게 쓰이는지 다시 연결해볼 수 있어요.
이어서 볼 질문
CIDR을 이해하면 바로 다음 질문이 생겨요.“라우팅 표에이 질문은 longest prefix match, 그러니까 더 구체적인 경로가 선택되는 규칙으로 이어져요.10.0.0.0/8과10.10.12.0/24가 둘 다 있으면, 라우터는 어느 쪽을 고를까요?”