A/B/C 클래스 주소 체계는 왜 CIDR로 바뀌었을까요?¶

예전에는 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를 기준으로 잡을게요.

왜 아직도 A/B/C 클래스 이야기가 나올까요?¶

클래스 주소 체계는 오래된 설명 방식인데, 아직도 교재나 네트워크 설정 글에서 자주 보여요. 이유는 간단해요. 처음 배울 때는 숫자 첫 칸으로 대략적인 크기를 나누는 방식이 꽤 직관적으로 보이거든요.

예전 감각은 대충 이랬어요.

여기까지만 보면 꽤 단순하죠. 첫 숫자 범위로 “큰 네트워크인지, 중간인지, 작은지”를 빠르게 나눌 수 있으니까요.

문제는 이 단순함이 너무 거칠었다는 데 있어요. 인터넷이 작을 때는 괜찮아 보였지만, 연결되는 조직과 네트워크가 늘어나면서 낭비와 라우팅 테이블 문제가 같이 커졌어요.

클래스 방식은 한마디로 뭐였을까요?¶

짧게 잡으면 이래요.

클래스 주소 체계는 IPv4 주소의 앞쪽 비트 모양만 보고 네트워크 크기를 미리 정해두는 방식이었어요.

비유로 보면 클래스 방식은 이래요. 이사할 사람에게 집을 줄 때, 선택지가 세 종류밖에 없는 거예요.

• 아주 큰 건물
• 중간 건물
• 작은 건물

그런데 필요한 공간이 2,000명분이라면 어떻게 될까요? 작은 건물은 부족하고, 중간 건물은 너무 커요. 결국 중간 건물을 통째로 받지만 대부분을 비워두게 되죠.

CIDR은 이 문제를 줄이려고 필요한 크기에 더 가까운 주소 묶음을 줄 수 있게 만든 방식에 가까워요.

예전 클래스 경계는 실제로 어떻게 나뉘었을까요?¶

IPv4 주소는 32비트예요. 클래스 방식은 이 32비트의 맨 앞 비트를 보고 큰 종류를 나눴어요.

flowchart TD
    A[IPv4 주소<br/><small>32 bits</small>]
    A --> B[0xxx...<br/><small>Class A</small>]
    A --> C[10xx...<br/><small>Class B</small>]
    A --> D[110x...<br/><small>Class C</small>]
    A --> E[1110...<br/><small>Class D / Multicast</small>]
    A --> F[1111...<br/><small>Class E / Reserved</small>]

이 그림에서 핵심은 주소 안에 네트워크 크기 힌트가 박혀 있었다는 점이에요. 별도 prefix를 붙이지 않아도, 첫 비트 패턴으로 기본 크기를 짐작하는 식이었죠.

표로 보면 이렇게 잡을 수 있어요.

클래스 방식은 왜 처음엔 그럴듯했을까요?¶

처음부터 이상한 방식이었던 건 아니에요. 초기 인터넷에서는 네트워크 수도 지금보다 훨씬 적었고, 주소를 쓰는 조직도 제한적이었어요. 그때는 몇 가지 크기의 상자로 나눠도 운영이 단순해지는 장점이 있었죠.

flowchart LR
    A[조직이 주소를 요청해요]
    A --> B{필요한 크기는?}
    B --> C[아주 큼<br/><small>Class A</small>]
    B --> D[중간<br/><small>Class B</small>]
    B --> E[작음<br/><small>Class C</small>]

이 방식의 장점은 설명과 판단이 쉬웠다는 거예요. 라우터나 운영자가 주소의 앞부분을 보고 "대충 이 정도 크기 네트워크구나" 하고 추정할 수 있었으니까요.

하지만 쉬운 규칙은 대개 유연하지 않아요. 인터넷이 커지자, 바로 그 고정 크기가 문제가 됐어요.

어디서 낭비가 생겼을까요?¶

가장 큰 문제는 필요한 크기와 받을 수 있는 크기가 잘 안 맞았다는 점이에요.

예를 들어 어떤 조직이 호스트 주소 2,000개 정도를 필요로 한다고 해볼게요.

• Class C 하나는 256개라 부족해요.
• Class B 하나는 65,536개라 너무 커요.

그럼 예전 방식에서는 Class B를 받는 쪽으로 기울기 쉬웠어요. 하지만 실제로는 2,000개만 써도 되는데 65,536개짜리 큰 묶음을 받는 셈이죠.

flowchart LR
    A[필요한 주소<br/><small>약 2,000개</small>]
    B[Class C<br/><small>256개라 부족</small>]
    C[Class B<br/><small>65,536개라 너무 큼</small>]
    D[남는 주소가 많아져요]

    A --> B
    A --> C
    C --> D

    style C stroke:#ef4444,stroke-width:2px
    style D stroke:#ef4444,stroke-width:2px

이건 개인에게만 손해인 문제가 아니에요. IPv4 주소는 전체 개수가 정해져 있으니, 큰 덩어리를 필요 이상으로 나눠주면 전체 주소 공간이 빨리 줄어들어요.

그리고 또 하나의 문제가 있었어요. 작은 Class C 여러 개를 많이 나눠주면 주소 낭비는 줄어들 수 있지만, 라우터가 기억해야 할 경로가 많아져요. 즉 주소 낭비와 라우팅 테이블 증가가 동시에 압박으로 온 거예요.

CIDR은 무엇을 바꿨을까요?¶

CIDR은 Classless Inter-Domain Routing의 줄임말이에요. 이름 그대로 클래스 없이 prefix 길이로 주소 묶음을 읽는 방식이에요.

예전에는 이런 식으로 생각했어요.

192로 시작하네? Class C니까 /24겠네.

CIDR에서는 이렇게 읽어요.

192.168.0.0/20
앞 20비트가 네트워크 prefix예요.

즉 주소의 첫 숫자가 아니라, 뒤에 붙은 /20이 범위를 결정해요.

flowchart LR
    A[Classful<br/><small>주소 앞부분이 기본 크기 암시</small>]
    B[CIDR<br/><small>prefix 길이를 명시</small>]
    C[203.0.113.0/24]
    D[203.0.112.0/20]

    A --> C
    B --> C
    B --> D

이 그림에서 보듯 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가 연속해서 붙어 있다고 해볼게요.

203.0.112.0/24
203.0.113.0/24
203.0.114.0/24
203.0.115.0/24

이 네 묶음은 하나로 합쳐서 이렇게 광고할 수 있어요.

203.0.112.0/22

flowchart LR
    A[203.0.112.0/24]
    B[203.0.113.0/24]
    C[203.0.114.0/24]
    D[203.0.115.0/24]
    E[203.0.112.0/22<br/><small>하나로 요약</small>]

    A --> E
    B --> E
    C --> E
    D --> E

이걸 보통 route aggregation, route summarization 같은 말로 불러요. 처음에는 이름보다 감각이 중요해요. 연속된 주소 묶음을 더 큰 prefix 하나로 묶어서, 라우터가 기억해야 할 줄 수를 줄이는 것이에요.

RFC 1519와 RFC 4632가 강조한 문제도 바로 이쪽이에요. IPv4 주소를 아끼는 것뿐 아니라, 전 세계 라우터들이 들고 다녀야 하는 경로 정보가 폭발적으로 늘어나는 것도 막아야 했거든요.

사설 IP 범위는 클래스와 헷갈리기 쉬워요¶

이제 공인 IP, 사설 IP, 그리고 NAT에서 본 사설 주소 범위를 다시 볼게요.

여기서 조심할 점이 있어요. RFC 1918 사설 주소 범위는 사설로 예약된 큰 범위를 말해요. 내 집이나 회사가 그 안에서 실제로 어떤 크기의 서브넷을 쓰는지는 별개예요.

예를 들어 집 공유기는 흔히 이렇게 써요.

LAN network: 192.168.0.0/24

하지만 회사나 실험 환경에서는 이렇게 잡을 수도 있어요.

LAN network: 192.168.0.0/23
VPN network: 10.40.16.0/20
Server subnet: 10.40.18.0/24

10으로 시작한다고 무조건 거대한 /8 하나로 운영하는 게 아니고, 192.168으로 시작한다고 무조건 /24만 가능한 것도 아니에요. 사설 주소 범위는 큰 땅이고, 실제 서브넷은 그 안에서 다시 잘라 쓰는 구획이라고 보면 돼요.

지금은 어떻게 읽어야 할까요?¶

현대 네트워크에서 안전한 읽기 순서는 이래요.

1. IP 주소만 보지 말고 prefix를 같이 봐요.
2. 10.10.12.73/26처럼 /26이 붙어야 범위가 결정돼요.
3. 사설 주소인지 공인 주소인지 구분해요.
4. 10.0.0.0/8, 172.16.0.0/12, 192.168.0.0/16 안인지 봐요.
5. 실제 서브넷 크기는 class 이름이 아니라 prefix로 판단해요.
6. /24, /20, /27이 진짜 경계선이에요.
7. 라우팅에서는 더 구체적인 prefix가 이길 수 있다는 걸 준비해요.
8. 이건 다음 IP 주소 글의 핵심 질문이에요.

flowchart TD
    A[IP를 봤어요] --> B{prefix가 같이 있나요?}
    B -->|예| C[/24, /20, /26 같은<br/>CIDR 기준으로 범위 판단]
    B -->|아니오| D[문맥을 더 찾아요<br/><small>설정, 라우팅 표, DHCP 정보</small>]
    C --> E{사설 범위인가요?}
    E -->|예| F[내부망 / NAT / VPN 문맥도 같이 확인]
    E -->|아니오| G[공인 라우팅 문맥 확인]

이 그림은 단순하지만 중요해요. 주소만 외워서 맞히는 방식이 아니라, 주소 + prefix + 문맥을 함께 읽는 쪽으로 넘어와야 해요.

여기서 자주 헷갈리는 함정들¶

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가 겹칠 때 어떤 경로가 선택되는지를 봐야 해요.

자, 정리해볼까요?¶

이제 192.168으로 시작한다고 무조건 /24라고 읽으면 안 되는 이유가 보이죠? 예전 클래스 이름은 역사 표지판이고, 지금 실제 경계선은 CIDR prefix예요.

이어서 보면 좋은 글¶

• 서브넷 마스크와 CIDR은 실제로 어떻게 계산할까요? — /24와 255.255.255.0이 같은 뜻인 이유를 비트 단위로 다시 잡을 수 있어요.
• 네트워크 주소, 브로드캐스트 주소, 호스트 범위는 어떻게 나뉠까요? — prefix가 정해졌을 때 실제 시작 주소와 끝 주소를 계산하는 법을 이어서 볼 수 있어요.
• 공인 IP, 사설 IP, 그리고 NAT는 왜 같이 나올까요? — RFC 1918 사설 주소 범위가 집 안 주소와 NAT 문맥에서 어떻게 쓰이는지 다시 연결해볼 수 있어요.

이어서 볼 질문¶

CIDR을 이해하면 바로 다음 질문이 생겨요.

"라우팅 표에 10.0.0.0/8과 10.10.12.0/24가 둘 다 있으면, 라우터는 어느 쪽을 고를까요?"

이 질문은 longest prefix match, 그러니까 더 구체적인 경로가 선택되는 규칙으로 이어져요.