CIDR 서브넷 마스크 (설계철학, IP절약, VLSM)

서브넷 마스크 계산법 네트워크 참고 이미지

서브넷 마스크 계산을 잘 한다고 네트워크 설계를 잘 하는 걸까요? 저는 오랫동안 그렇다고 믿었습니다. 그런데 실무에서 직접 부딪혀보니, 계산 능력과 설계 능력은 전혀 다른 이야기였습니다. CIDR(Classless Inter-Domain Routing)과 서브넷 마스크의 핵심은 공식 암기가 아니라, 왜 이렇게 나눠야 하는지를 아는 것이었습니다. 그 차이를 뼈저리게 느끼게 해준 경험들이 있습니다.

설계철학 없이 CIDR을 쓰면 생기는 일

일반적으로 서브넷 설계는 "현재 필요한 호스트 수에 맞게 자르면 된다"고 알려져 있습니다. 저도 처음엔 그렇게 배웠고, 그렇게 했습니다. 실무 초기에 서버 20대를 운영하는 환경에서 /27 서브넷을 할당했습니다. /27이란 프리픽스(prefix) 비트가 27개라는 의미로, 호스트에 사용할 수 있는 비트가 5개 남아 30개의 IP를 사용할 수 있는 구성입니다. 딱 맞는 선택처럼 보였습니다.

그런데 6개월 후 서버가 추가되면서 서브넷이 꽉 차버렸고, 결국 전체 IP 계획을 다시 설계해야 하는 사태가 벌어졌습니다. 솔직히 이건 예상 밖이었습니다. 단순히 귀찮은 수준이 아니라, 운영 중인 서비스에 영향을 줄 수 있는 작업이었으니까요. 지금 생각해보면 그 설계의 근본적인 문제는 "지금 몇 대냐"를 기준으로 잡은 것이었습니다. 네트워크 설계는 현재가 아니라 12개월에서 18개월 뒤를 기준으로 해야 한다는 것을 그때 처음으로 제대로 배웠습니다.

이 경험이 더 치명적으로 반복될 수 있는 환경이 바로 VPC(Virtual Private Cloud)입니다. VPC란 AWS나 GCP 같은 클라우드 환경에서 사용자가 논리적으로 격리된 네트워크 공간을 직접 구성하는 개념입니다. 문제는 클라우드에서 서브넷을 한 번 생성하면 CIDR 범위를 변경할 수 없다는 점입니다. 처음 설계가 틀리면 삭제하고 다시 만드는 것 외에 방법이 없습니다. 운영 중인 환경에서 이걸 다시 해야 한다면, 그 파장은 단순히 IP 재설계에서 끝나지 않습니다. 서비스 중단, 연결 재구성, 관련 보안 그룹 수정까지 따라옵니다.

이 제약 때문에 현장에서는 초기 설계 시 최소 2배 여유를 두는 것이 사실상 불문율로 통합니다. 저도 그 이후로는 예상 호스트 수의 두 배 이상을 수용할 수 있는 서브넷을 기본으로 잡고 있습니다. 낭비처럼 보일 수 있지만, 나중에 재설계하는 비용과 비교하면 낭비가 아닙니다. 오히려 이 여유가 진짜 절약입니다.

또 하나 간과하기 쉬운 부분이 있습니다. 서브넷은 단순히 IP를 나누는 도구가 아니라 보안 경계이자 브로드캐스트 도메인(broadcast domain)을 결정하는 기준입니다. 브로드캐스트 도메인이란 하나의 브로드캐스트 패킷이 전달되는 범위를 의미하며, 이 범위가 넓을수록 불필요한 트래픽이 늘어납니다. /24 하나로 254개 호스트를 한 덩어리로 묶는 것보다, /26 네 개로 쪼개서 영역별로 격리하는 방식이 보안과 성능 모두에서 유리한 경우가 많습니다. 계산기가 알려줄 수 없는 판단이 바로 이 지점입니다.

CIDR 설계에서 제가 개인적으로 중요하게 생각하는 원칙을 정리하면 다음과 같습니다. 첫째, 현재 호스트 수가 아닌 12~18개월 후 예상 수를 기준으로 설계한다. 둘째, VPC 환경에서는 서브넷 CIDR 변경이 불가하므로 반드시 여유분을 확보한다. 셋째, 서브넷은 IP 분리 도구가 아니라 보안 경계와 라우팅 효율을 결정하는 설계 단위로 본다. 넷째, 브로드캐스트 도메인 크기를 의식하며 서브넷 크기를 결정한다. CIDR이 1993년 RFC 1519에서 도입된 이후 클래스 기반 주소 체계를 대체해온 이유도 바로 이 유연성에 있습니다. 고정된 Class A/B/C 분류는 낭비가 너무 심했고, 프리픽스 비트 수를 자유롭게 지정할 수 있는 CIDR이 그 자리를 채웠습니다.

IP절약과 VLSM, 이론보다 몸으로 배운 것들

제가 실무에서 가장 극적인 변화를 체감한 건 /30 서브넷을 제대로 쓰기 시작하면서였습니다. /30이란 호스트 비트가 2개로, 실제 사용 가능한 IP가 딱 2개인 서브넷입니다. 이 구성은 라우터와 라우터 사이의 P2P 링크, 즉 두 장비만 연결되는 지점 간 회선에 최적화된 크기입니다.

제가 맡았던 레거시 네트워크에서는 이런 라우터 간 링크에 /24가 할당되어 있었습니다. 254개의 IP를 쓸 수 있는 서브넷에서 실제로 사용하는 건 IP 2개뿐이었던 겁니다. 이 구조를 전부 /30으로 교체했을 때, 수백 개의 IP가 해방됐고 이를 실제 서버에 재할당할 수 있었습니다. 처음에 이 결과를 보고 솔직히 어처구니가 없었습니다. 아무도 이 비효율을 문제로 인식하지 않은 채로 수년을 운영해온 것이었으니까요. 그리고 그 원인은 단순했습니다. 처음 설계한 사람이 /30이 존재한다는 걸 몰랐거나, 알면서도 귀찮아서 /24를 일괄 할당한 겁니다.

VLSM(Variable Length Subnet Masking)을 처음 도입했을 때는 또 다른 혼란이 찾아왔습니다. VLSM이란 동일한 상위 네트워크 안에서 서로 다른 크기의 서브넷을 혼용하는 방식입니다. 예를 들어 192.168.10.0/24라는 하나의 네트워크 안에 /26, /28, /30이 동시에 존재하는 식입니다. 이론상 효율적이지만, 각 서브넷의 주소 범위가 서로 겹치지 않는지 수작업으로 검증하는 과정이 생각보다 복잡했습니다.

결국 저는 엑셀로 서브넷 계산 도구를 직접 만들었습니다. 프리픽스를 입력하면 네트워크 주소, 브로드캐스트 주소, 사용 가능한 호스트 범위가 자동으로 나오는 구조였는데, 이걸 만들면서 오히려 서브넷 구조 자체를 완전히 내재화하게 됐습니다. 툴을 쓰면 편하지만, 한 번쯤 직접 만들어보는 경험이 이해도를 비약적으로 끌어올린다고 생각합니다. 계산기에 숫자를 넣는 것과 계산기를 직접 만드는 것의 차이는 단순히 숙련도의 차이가 아닙니다. 구조를 이해했는지 아닌지의 차이입니다.

서브넷 마스크 계산의 핵심 원리를 간단히 짚으면, 네트워크 주소는 IP 주소와 서브넷 마스크를 AND 연산한 값이고, 브로드캐스트 주소는 네트워크 주소에 호스트 비트를 전부 1로 채운 값입니다. 192.168.10.0/26을 예로 들면, 호스트 비트 6개로 62개의 IP를 쓸 수 있고, 범위는 192.168.10.1부터 192.168.10.62까지입니다. 이 계산 자체는 어렵지 않습니다. 문제는 이 계산 결과를 놓고 "이게 지금 상황에 맞는 선택인가"를 판단하는 설계 감각인데, 이건 경험 없이는 쌓이지 않습니다.

RFC 4632에서 정의된 CIDR의 주소 집약(aggregation) 개념도 라우팅 효율과 직결됩니다. 여러 연속된 서브넷을 하나의 상위 프리픽스로 요약해 라우팅 테이블을 단순화할 수 있다는 원리인데, 이를 실제 네트워크 설계에 적용하면 라우터의 부하도 줄이고 장애 범위도 좁힐 수 있습니다.

서브넷 설계를 단순한 계산 문제로 보는 시각이 아직도 많습니다. 하지만 저는 실무를 거치면서 이게 결국 네트워크의 보안 구조와 성장 가능성을 결정하는 설계 철학의 문제라는 생각을 굳혔습니다. 계산 공식은 검색하면 나오지만, 왜 지금 이 크기로 잘라야 하는지는 직접 실수하고 고쳐본 사람만 압니다. 아직 서브넷 설계가 낯설다면, 한 번쯤 작은 네트워크라도 직접 설계해보시길 권합니다. 계산기를 쓰더라도, 그 숫자가 의미하는 바를 이해하면서 쓰는 것과 모르고 쓰는 것은 결과에서 확연히 드러납니다.

---

 

📚 출처 및 참고 자료

• RFC 1519 - CIDR: an Address Assignment and Aggregation Strategy: https://datatracker.ietf.org/doc/html/rfc1519
• Cisco - Subnetting a Network: https://www.cisco.com/c/en/us/support/docs/ip/routing-information-protocol-rip/13788-3.html
• Wikipedia - Classless Inter-Domain Routing: https://en.wikipedia.org/wiki/Classless_Inter-Domain_Routing
• Subnet Calculator: https://www.subnet-calculator.com/
• IANA - IP Address Services: https://www.iana.org/assignments/ipv4-address-space/