본문으로 건너뛰기
Network suite

IP / CIDR 서브넷 계산기

IPv4 주소를 CIDR 표기법(예: 192.168.1.10/24)으로 입력하면 네트워크 주소, 브로드캐스트 주소, 사용 가능한 호스트 범위, 호스트 수, 서브넷 마스크, 와일드카드 마스크를 즉시 계산합니다.

모든 처리는 브라우저 내에서 수행되며 서버로 전송되지 않습니다.

가이드: 사용 방법 및 특징

  • 「IP주소/프리픽스 길이」 형식(예: 10.0.0.0/8)으로 입력합니다. 프리픽스를 생략하면 /32로 처리됩니다.
  • 입력과 동시에 네트워크·브로드캐스트·호스트 범위 등이 자동으로 계산되어 표시됩니다.
  • 각 항목 오른쪽의 복사 버튼으로 값을 개별적으로 클립보드에 복사할 수 있습니다.
  • /31(RFC 3021 포인트 투 포인트)이나 /32(단일 호스트) 같은 특수한 프리픽스도 올바르게 처리합니다.

FAQ: 자주 묻는 질문

  • 「전체 주소 수」와 「사용 가능한 호스트 수」가 다른 이유는 무엇인가요?

    일반적인 서브넷에서는 맨 앞의 네트워크 주소와 맨 뒤의 브로드캐스트 주소를 호스트에 할당할 수 없으므로, 사용 가능한 호스트 수는 전체 주소 수에서 2를 뺀 값이 됩니다. 예를 들어 /24는 전체 256개, 사용 가능 254개입니다.
  • /31이나 /32에서 호스트 수 처리가 달라지는 이유는 무엇인가요?

    /32는 단일 호스트를 의미하므로 1개 주소를 그대로 사용합니다. /31은 RFC 3021에 정의된 포인트 투 포인트 링크용으로 네트워크·브로드캐스트를 예약하지 않아 두 주소 모두 사용할 수 있습니다. 이 도구는 이러한 특례를 지원합니다.
  • 와일드카드 마스크란 무엇인가요?

    서브넷 마스크의 비트를 반전한 것으로, 주로 Cisco 계열 장비의 ACL(액세스 제어 목록)에서 범위 지정에 사용됩니다. 예를 들어 마스크 255.255.255.0의 와일드카드는 0.0.0.255입니다.
  • 입력한 IP 주소가 외부로 전송되나요?

    아니요. 모든 계산은 브라우저 내 JavaScript로 처리되며 입력한 값이 서버로 전송되지 않으므로, 사내 네트워크를 설계할 때도 안심하고 사용할 수 있습니다.

활용: 주요 활용 사례

  • 서브넷 설계 검증

    /24, /26 등으로 분할할 때 각 서브넷에서 사용 가능한 호스트 수와 범위가 요구 사항에 맞는지 빠르게 검증할 수 있습니다.

  • 방화벽·ACL 범위 지정

    네트워크 주소와 와일드카드 마스크를 확인하여 규칙의 허용·차단 범위를 정확하게 기술할 수 있습니다.

  • 클라우드 VPC/서브넷 설정

    AWS, GCP 등에서 VPC·서브넷 CIDR을 정할 때 호스트 수 상한과 주소 범위를 미리 파악할 수 있습니다.

주의: 이용 시 주의

  • IPv4 전용

    이 도구는 IPv4 CIDR를 대상으로 합니다. IPv6 주소(예: 2001:db8::/32)는 지원하지 않습니다.

  • 사용 가능한 호스트 수 계산 방식

    /30 이하의 일반 서브넷은 네트워크와 브로드캐스트 주소를 제외하고 계산합니다. /31·/32는 특례로 모든 주소를 사용 가능으로 셉니다.

  • 사설 판정의 범위

    「주소 유형」은 RFC 1918 사설 범위, 루프백, 링크 로컬을 판정합니다. 그 외에는 공인으로 표시하지만 실제 도달 가능성을 보장하지는 않습니다.

계산 결과

네트워크 CIDR
서브넷 마스크
와일드카드 마스크
네트워크 주소
브로드캐스트 주소
사용 가능한 호스트 범위
전체 주소 수
사용 가능한 호스트 수
주소 유형

위에 CIDR을 입력하면 상세 내역이 표시됩니다.

이 도구의 관련 기사

Recent Articles

활용 사례
2026-08-07

curl 옵션 정리|-X -H -d 가 실제로 하는 일과 함정

실무에서 만나는 curl 옵션을 표로 정리했습니다. -d 만으로 이미 POST가 되는 이유, -d 와 --data-raw 의 차이, 앞의 @ 가 조용히 파일을 읽는 함정, 작은따옴표와 큰따옴표의 구분, -k 와 -L 을 쉽게 붙이면 안 되는 이유까지 예제로 설명합니다.

도구 소개
2026-08-06

JSON Schema와 Zod를 상호 변환하는 원리|required와 .optional()의 대응

JSON Schema에서 Zod 스키마를 만들고 Zod 코드에서 다시 JSON Schema를 뽑아내는 양방향 변환기의 구현을 해설합니다. required와 .optional()의 기본값이 반대인 문제, 제약 조건 대응표, 코드를 실행하지 않고 해석하는 방법까지 정리합니다.

활용 사례
2026-08-06

SQL 절 실행 순서 레퍼런스|WHERE에서 SELECT 별칭을 못 쓰는 이유

SQL은 작성한 순서대로 실행되지 않습니다. 논리적 실행 순서(FROM → WHERE → GROUP BY → HAVING → SELECT → ORDER BY → LIMIT)를 축으로, 별칭이 WHERE에서 안 되는 이유, WHERE와 HAVING의 구분, ONLY_FULL_GROUP_BY, COUNT(*)와 COUNT(컬럼)의 차이, LEFT JOIN + WHERE 함정을 예제로 정리합니다.

활용 사례
2026-08-06

unified diff 형식 읽는 법|git diff의 @@ 헤더 완전 해설

git이 출력하는 unified diff 형식을 읽는 법을 정리했습니다. @@ -12,7 +12,9 @@ 의 네 숫자가 뜻하는 것, 한 글자만 고쳐도 줄 전체가 바뀐 것처럼 보이는 이유, 공백과 줄바꿈 문자의 함정, \ No newline at end of file, 머지 커밋의 @@@, similarity index를 통한 이름 변경 감지까지 예제로 설명합니다.

활용 사례
2026-08-06

UTC⇄JST/KST 변환 레퍼런스|9시간 시차 대조표와 타임존 사고 예방법

UTC와 일본 시간(JST)·한국 시간(KST)의 변환을 대조표로 정리했습니다. ISO 8601의 Z와 +09:00의 의미, JavaScript 날짜 파싱이 9시간 어긋나는 조건, MySQL/PostgreSQL의 타임존 동작, GitHub Actions cron이 UTC로 도는 함정까지 예제와 함께 해설합니다.

활용 사례
2026-08-04

CREATE TABLE 레퍼런스|MySQL·PostgreSQL·SQLite의 타입과 제약 조건 차이

CREATE TABLE(DDL) 작성법을 3개 데이터베이스 비교표로 정리했습니다. 타입 대응표, 자동 증가(AUTO_INCREMENT / IDENTITY / rowid)의 방언 차이, 외래 키의 ON DELETE 동작, MySQL이 조용히 무시하는 CHECK 제약까지 예제와 함께 해설합니다.

광고

광고