서브넷 계산기

192.168.1.128/26사설(RFC 1918)
네트워크 주소
192.168.1.128
브로드캐스트 주소
192.168.1.191
사용 가능 범위
192.168.1.129 – 192.168.1.190
사용 가능 주소 수
62
전체 주소 수
64
서브넷 마스크
255.255.255.192
와일드카드 마스크
0.0.0.63
프리픽스
/26 · 6 호스트 비트
이진수11000000.10101000.00000001.10000010

브라우저에서 계산되며 어디에도 전송되지 않고 조회도 하지 않습니다. RFC 3021에 따라 /31은 두 주소 모두 사용할 수 있고, /32는 사용 가능한 호스트가 하나이며, IPv6는 네트워크 주소도 브로드캐스트 주소도 예약하지 않습니다.

입력한 내용은 저장, 기록, 공유되지 않습니다.

CIDR 표기로 주소를 입력하면 네트워크 주소와 브로드캐스트 주소, 사용 가능한 호스트 범위, 서브넷 마스크, 와일드카드 마스크, 주소 개수를 보여 줍니다. IPv4와 IPv6 모두 지원하며, 모든 계산은 브라우저에서 이루어지고 어떤 조회도 하지 않습니다.

사용 방법

  1. 192.168.1.130/26처럼 주소와 프리픽스를 입력합니다.
  2. 네트워크, 브로드캐스트, 사용 가능 범위, 호스트 수를 확인합니다.
  3. 필요하면 네트워크를 더 작은 균등 서브넷으로 나눕니다.

프리픽스란 무엇인가

IPv4 주소는 32비트입니다. 슬래시 뒤의 프리픽스 길이는 그중 몇 비트가 네트워크를 나타내는지를 뜻하며, 나머지 비트가 네트워크 안의 호스트를 나타냅니다. /24는 앞 24비트를 고정하고 호스트용으로 8비트, 즉 256개 주소를 남깁니다. 프리픽스가 하나 줄 때마다 블록은 두 배가 되므로 /23은 512개, /16은 65,536개 주소입니다.

넷마스크는 같은 정보를 주소 형태로 쓴 것입니다. 1이 24개, 0이 8개 이어지면 255.255.255.0입니다. 마스크는 반드시 1이 끊김 없이 이어져야 합니다. 그래야 경계가 흩어진 비트가 아니라 한 줄로 그어지기 때문입니다. 그래서 255.255.0.255는 마스크가 아니며, 이를 가장 가까운 올바른 마스크로 조용히 바꿔 주는 계산기는 정작 찾고 있던 설정 오류를 감춰 버립니다.

와일드카드 마스크는 넷마스크를 뒤집은 것입니다. Cisco 액세스 리스트와 OSPF가 고정된 비트가 아니라 바뀔 수 있는 비트를 기준으로 작성되기 때문에 존재합니다. /24의 와일드카드는 0.0.0.255입니다. 무엇이 필요한지는 전적으로 설정하는 대상에 달려 있으므로 여기서는 둘 다 보여 줍니다.

2진수 행은 한 번쯤 읽어 볼 만합니다. 서브넷팅은 32비트 위에 경계선 하나를 긋는 일이고, 그 선을 직접 보는 편이 점으로 구분된 10진수로 따지는 것보다 대개 빠릅니다.

알아봐야 할 주소 범위

RFC 1918은 인터넷에서 라우팅되지 않는 사설용 IPv4 블록 세 개를 지정합니다. 10.0.0.0/8, 172.16.0.0/12(172 전체가 아니라 172.16부터 172.31까지라는 점에 주의), 그리고 192.168.0.0/16입니다. 접하게 되는 내부 네트워크는 거의 모두 이 중 하나에서 잘라 낸 것입니다.

자주 등장해서 보자마자 알아봐야 할 범위도 몇 가지 있습니다. 100.64.0.0/10은 캐리어급 NAT로, ISP 고객과 ISP 자체 라우터 사이에서 쓰이며 가정용 네트워크에서도 생각보다 자주 보입니다. 169.254.0.0/16은 링크 로컬로, DHCP가 실패했을 때 스스로 할당되므로 이 범위의 주소는 설정이라기보다 문제의 증상인 경우가 대부분입니다. 127.0.0.0/8은 루프백이며 127.0.0.1만이 아니라 /8 전체가 해당합니다. 224.0.0.0/4는 멀티캐스트, 255.255.255.255는 제한 브로드캐스트 주소입니다.

문서와 예제용으로는 RFC 5737이 192.0.2.0/24, 198.51.100.0/24, 203.0.113.0/24 세 블록을 예약해 두었습니다. 다이어그램이나 블로그 글에서는 누군가의 실제 주소를 아무렇게나 고르지 말고 이 주소를 쓰세요.

네트워크 나누기

블록을 나눈다는 것은 경계를 오른쪽으로 옮기는 것입니다. /24를 넷으로 나누면 각각 64개 주소인 /26 네 개가 되고, 둘로 나누면 각각 128개 주소인 /25 두 개가 됩니다. 프리픽스는 항상 2의 거듭제곱이므로 계산은 늘 같고, 그것이 곧 제약이기도 합니다. 주소 100개짜리 서브넷은 만들 수 없고 64개나 128개만 가능합니다.

가변 길이 서브넷 마스크(VLSM)는 모든 서브넷을 똑같이 자르지 않고 담을 대상에 맞춰 크기를 정하는 방식입니다. 두 라우터 사이의 점대점 링크에는 주소 두 개면 되므로 /31이나 /30, 장비 60대가 있는 사용자 VLAN에는 /26, 증가가 예상되는 서버 구간에는 /24를 줍니다. 잘하는 비결은 대부분 여유를 남기는 데 있습니다. 프리픽스를 넘어설 만큼 커진 서브넷의 번호를 다시 매기려면 모든 장비, 모든 방화벽 규칙, 그 서브넷을 참조하는 모든 정적 설정을 손대야 하기 때문입니다.

요약하기 좋은 경계에 맞춰 할당하는 것도 도움이 됩니다. 한 사이트의 모든 것이 하나의 /20 안에 있으면 나머지 네트워크는 16개가 아니라 1개의 경로로 그곳에 닿을 수 있고, 규모가 큰 환경일수록 그 차이가 누적됩니다.

IPv6는 자릿수만 늘어난 IPv4가 아니다

계산법은 같지만 설계의 전제가 다르기 때문에, IPv4 습관을 그대로 가져오면 어색한 IPv6 네트워크가 되기 쉽습니다.

표준 서브넷 크기는 호스트 수와 상관없이 항상 /64입니다. 상태 비저장 주소 자동 설정(SLAAC)은 64비트 호스트 부분을 전제로 하므로 /64보다 잘게 나누면 동작하지 않습니다. 무엇을 포기하는지 알고 점대점 링크에 쓰는 경우가 아니라면 피하는 것이 좋습니다. 사이트에는 보통 /48이나 /56이 할당되며, 각각 65,536개와 256개의 서브넷입니다. 주소 절약을 다시는 고민하지 않고 VLAN마다 세지 않고 /64를 할당하라는 것이 그 의도입니다.

브로드캐스트 주소는 없으며 그 역할은 멀티캐스트가 맡습니다. 프리픽스 안에 예약된 주소도 없으므로 /64에는 정말로 18,446,744,073,709,551,616개의 사용 가능한 주소가 있고, 두 개를 빼는 습관은 적용되지 않습니다. 그리고 NAT는 이 모델에 포함되지 않습니다. 호스트는 전역으로 라우팅 가능한 주소를 가지며, 접근 가능 여부는 방화벽에서 결정합니다. 이는 계산이 아니라 사고방식의 변화입니다.

소규모 사무실을 위해 /24 나누기

192.168.10.0/24 하나를 받았고, 수용해야 할 것이 네 가지라고 해보겠습니다. 직원 단말 약 50대, 서버 열몇 대, 프린터와 카메라 몇 대, 그리고 지사 라우터로 가는 지점 간 링크 두 개입니다. 본능적으로는 이 블록을 똑같은 /26 네 개로 쪼개게 되는데, 그러면 대부분을 낭비하면서 정작 여유가 필요한 곳에는 여유가 남지 않습니다.

가변 길이 서브네팅이 훨씬 낫습니다. 직원 VLAN에는 192.168.10.0/26을 줍니다. 사용 가능한 주소가 62개입니다. 서버에는 192.168.10.64/27을 주면 사용 가능 30개로, 대수가 두 배로 늘어도 감당됩니다. 프린터와 카메라는 192.168.10.96/27에 둡니다. 사용자 네트워크와 분리해 두면 방화벽 규칙이 단순해지기 때문입니다. 그러고 나면 192.168.10.128/25가 통째로 비어 있게 되고, 링크 두 개는 그 위쪽 끝에서 /30을 가져가 192.168.10.252/30과 192.168.10.248/30을 쓰면 가운데는 비워 둘 수 있습니다.

빈틈없이 채우지 않고 여백을 남기는 이유는, 나중에 주소를 다시 매기려면 모든 장비, 모든 DHCP 스코프, 모든 방화벽 규칙, 모든 정적 항목을 손봐야 하기 때문입니다. 사설 대역 안의 주소 공간은 공짜지만, 재번호 작업으로 날아가는 주말은 공짜가 아닙니다.

라우터가 이 프리픽스들로 하는 일

라우팅 테이블은 프리픽스와 넥스트홉의 목록이고, 그중에서 무엇을 고를지 정하는 규칙이 최장 프리픽스 매치입니다. 목적지를 포함하는 경로 가운데 가장 구체적인 것이 이깁니다. 테이블에 10.0.0.0/8과 10.1.0.0/16이 있는 상태에서 10.1.2.3으로 가는 패킷은 경로를 추가한 순서와 무관하게 /16을 탑니다.

기본 경로 0.0.0.0/0은 가능한 프리픽스 중 가장 덜 구체적인 것일 뿐이며, 그래서 다른 어떤 것도 맞지 않을 때만 쓰입니다. 이 하나의 메커니즘이, 더 구체적인 경로를 추가하면 넓은 경로가 조용히 덮어써지는 것을 포함해 사람들이 의아해하는 라우팅 동작의 대부분을 설명합니다.

경로 축약은 같은 원리를 의도적으로 쓰는 것입니다. 한 사이트의 모든 서브넷이 하나의 /20 안에 들어 있다면, 네트워크의 나머지 부분은 항목 열여섯 개 대신 하나만 있으면 됩니다. 테이블이 작게 유지되고, 사이트 안에서 링크가 플래핑해도 그 흔들림이 바깥으로 전파되지 않습니다. 축약을 고려하지 않은 할당은 누군가 VLAN을 하나 만들 때마다 라우팅 테이블이 선형으로 늘어나게 만듭니다.

서브넷을 쓸 만하게 만들어 주는 서비스들

서브넷 자체만으로는 할 수 있는 일이 별로 없습니다. DHCP가 그 안의 풀에서 주소를 나눠 주는데, 이 풀은 대역 전체가 아니라 일부여야 하고, 고정 주소가 필요한 서버와 프린터, 네트워크 장비를 위한 공간을 남겨 두어야 합니다. MAC 주소 기반 예약을 쓰면 장비 쪽에 아무것도 설정하지 않고도 안정적인 주소를 줄 수 있는데, 대개 이쪽이 더 나은 선택입니다.

게이트웨이는 관례적으로 사용 가능한 첫 번째나 마지막 주소에 둡니다. 둘 중 무엇을 고르느냐보다 사이트마다 일관되게 유지하는 쪽이 더 중요합니다. 게이트웨이가 언제나 .1이라는 걸 아는 엔지니어가 문제를 더 빨리 풀어냅니다.

사설 대역이 인터넷에 닿을 수 있는 것은 NAT 덕분이고, 동시에 그것이 10.0.0.0/8이나 192.168.0.0/16의 주소가 네트워크 바깥의 누구에게도 아무 의미가 없는 이유이기도 합니다. 로그의 출발지에 사설 주소가 찍혀 있다면 NAT의 안쪽을 보고 있는 것이고, 실제 호스트를 특정하려면 변환 테이블이 필요합니다. 100.64.0.0/10의 캐리어급 NAT는 ISP 규모에서 같은 일을 하는 것이며, 가입자를 식별하는 데 주소뿐 아니라 포트 번호까지 점점 더 필요해지는 이유입니다.

클라우드 네트워크의 서브네팅

AWS, Azure, Google Cloud에서 쓰는 용어는 같지만 제약은 다릅니다. 각 사업자는 모든 서브넷에서 주소 몇 개를 예약합니다. AWS는 다섯 개를 가져갑니다. 네트워크 주소, 게이트웨이, DNS와 향후 용도를 위한 두 개, 그리고 브로드캐스트 주소입니다. 그래서 /28의 사용 가능한 주소는 열네 개가 아니라 열한 개입니다.

VPC CIDR은 보통 한 번 정하면 바꾸기가 고통스럽기 때문에, 피어링을 염두에 두고 고르는 것이 좋습니다. 대역이 겹치는 두 네트워크는 변환 없이는 연결할 수 없고, 가장 흔한 원인은 모두가 기본값인 10.0.0.0/16을 그대로 쓰는 것입니다. 환경별, 리전별로 서로 다른 대역을 확보해 두면 마땅한 선택지가 없는 종류의 마이그레이션을 피할 수 있습니다.

서브넷은 보통 가용 영역마다 두고, 각 영역의 대역을 퍼블릭과 프라이빗 계층으로 나누는 것이 표준 패턴입니다. 계층 사이에 세 번째 계층, 즉 데이터 계층이나 미래의 가용 영역을 위한 여유를 남겨 두는 것은 설계 시점에는 아무 비용도 들지 않으면서, 그렇게 하지 않으면 1년 반쯤 뒤에 나타나는 불연속적이고 어색한 할당을 피하게 해 줍니다.

문제를 추적할 때 계산 결과 읽는 법

현장에서 가장 자주 나오는 질문은 두 주소가 같은 서브넷에 있느냐입니다. 같지 않다면 호스트는 패킷을 직접 보내지 않고 게이트웨이로 넘기며, 그 순간 방화벽이나 라우팅 문제가 끼어들기 때문입니다. 각각의 네트워크 주소를 비교하면 바로 답이 나옵니다. 같은 마스크에 네트워크 주소가 같으면 같은 서브넷입니다.

마스크가 서로 어긋난 것은 전형적인 설정 실수이고, 한쪽에서는 상대에게 닿는데 반대 방향은 안 되는 비대칭 증상을 만듭니다. 목적지가 로컬인지 아닌지에 대해 양쪽 판단이 엇갈리기 때문입니다. 두 네트워크를 나란히 놓고 보면, 설정 파일 두 개를 읽어서는 좀처럼 드러나지 않는 것이 한눈에 보입니다.

또 하나 빠른 답을 주는 것이 대역 종류 표시입니다. 169.254.0.0/16의 주소는 DHCP가 실패했다는 뜻이고, 127.0.0.0/8의 주소는 무언가가 인터페이스가 아니라 루프백에 바인딩돼 있다는 뜻이며, 공인 주소가 있을 거라고 생각한 자리에 100.64.0.0/10의 주소가 뜻밖에 나타났다면 대개 ISP 라우터가 캐리어급 NAT를 하고 있다는 의미입니다.

자주 묻는 질문

어떤 계산기는 왜 /31의 사용 가능 호스트를 0이라고 하나요?
네트워크 주소와 브로드캐스트 주소를 조건 없이 빼기 때문입니다. RFC 3021은 포인트 투 포인트 링크에 대해 이를 바꿨습니다. /31은 정확히 두 개의 주소를 가지며 둘 다 할당할 수 있고, 그래서 /30을 낭비하는 대신 라우터 간 링크를 이렇게 구성하는 것이 일반적입니다. /32도 마찬가지로 단일 호스트이며 사용 가능하지, 마이너스 1이 아닙니다. 이 계산기는 둘 다 제대로 처리합니다.
/24의 사용 가능 호스트는 왜 256이 아니라 254인가요?
블록의 첫 주소는 네트워크 자체를 가리키고 마지막 주소는 브로드캐스트 주소여서 어느 쪽도 호스트에 할당할 수 없기 때문입니다. 흔히 말하는 "둘을 뺀다"가 여기서 나옵니다. 이는 IPv4의 /30 이상 블록에 해당하며, 그보다 작은 경우는 앞의 답을 보세요.
IPv6도 서브넷마다 두 주소를 잃나요?
아닙니다. IPv6에는 브로드캐스트 주소 자체가 없고(그 역할은 멀티캐스트가 대신합니다), IPv4처럼 프리픽스의 모두 0인 주소를 예약하지도 않습니다. IPv6 프리픽스의 모든 주소를 할당할 수 있으며, 그래서 /64는 18,446,744,073,709,551,616을 그대로 보여 줍니다.
이진수 줄은 무엇을 보여 주나요?
주소를 이진수로 표시하고 프리픽스 경계에서 정확히 나눈 것입니다. 왼쪽의 색이 있는 부분이 마스크가 덮는 네트워크 부분이고 나머지가 호스트 부분입니다. 그 경계가 바로 서브네팅 자체이며, 점 십진 마스크로 따지는 것보다 대개 더 빠르게 파악됩니다.
제 서브넷 마스크는 왜 거부되었나요?
서브넷 마스크는 1이 이어진 뒤 0이 이어지는 형태여야 합니다. 255.255.255.192는 유효하고 255.255.0.255는 아닙니다. 일부 도구는 연속되지 않은 마스크를 가장 가까운 유효 값으로 조용히 반올림하는데, 그러면 정작 찾고 싶은 설정 오류가 가려집니다. 이 도구는 거부하고 이유를 알려 줍니다.
서버로 전송되는 것이 있나요?
없습니다. 이것은 산술이며 브라우저에서 수행됩니다. DNS 확인도, WHOIS 조회도, 어떤 종류의 조회도 하지 않습니다. 입력한 주소는 대개 공개하고 싶지 않은 내부 대역인데, 그것이 어디로도 전송되지 않습니다.

마지막 업데이트:

문제 신고

진행 단계, 예상 결과, 실제 결과를 적어 주세요. 비밀 정보와 개인 정보는 삭제해 주세요.

관련 도구