2026. 6. 22. 19:54ㆍComputer Science/네트워크
4편에서 게이트웨이가 내부망과 외부망의 경계 역할을 하고, NAT가 공인 IP와 사설 IP를 변환한다는 걸 배웠다.
그런데 내부망 안에 기기가 수백, 수천 대라면 어떨까?
그 많은 기기를 하나의 네트워크에 뒤섞어두면 관리도 어렵고 보안도 취약해진다.
이번 편에서는 내부망을 더 작은 단위로 나누고 통제하는 세 가지 개념을 다룬다.
- 서브넷: 내부망을 구역으로 나누기
- 방화벽: 구역 사이의 통행 규칙 정하기
- DMZ: 외부에 공개할 서버는 따로 두기
서브넷: 내부망을 쪼개서 관리하기
서브넷은 하나의 큰 네트워크를 목적에 맞게 작은 단위로 나누는 것이다.
내부망을 왜 나눠야 할까?
첫째, 관리 효율성이다. 회사에 컴퓨터가 1000대 있다면, 부서별로 네트워크를 나눠두면 문제가 생겼을 때 어느 부서인지 빠르게 파악할 수 있다. "인사팀 인터넷이 안 돼요"라는 문의가 오면, 인사팀 서브넷만 확인하면 된다.
둘째, 보안이다. 외부에 노출되어야 하는 서버(웹서버)와 절대 노출되면 안 되는 서버(DB서버)를 같은 네트워크에 두면 위험하다. 영역을 분리해두면 한 구역이 뚫려도 다른 구역으로 침투하기 어려워진다.
셋째, IP 낭비 방지다. 작은 팀에 거대한 IP 대역을 통째로 줄 필요가 없으므로, 필요한 만큼만 잘라서 나눠 쓸 수 있다.
CIDR: 구역과 번지수를 나누는 표기법
서브넷을 이해하려면 CIDR 표기법을 먼저 알아야 한다.
IP 주소는 "앞쪽 몇 자리가 네트워크(어느 구역인지)를 나타내고, 나머지 뒷자리가 호스트(그 구역 안의 몇 번째 기기인지)를 나타낸다"는 구조다. 그 경계가 어디인지를 정해주는 것이 CIDR(예: /24) 표기다.
10.0.1.5/24
→ 앞 24비트(10.0.1 부분): 네트워크 주소 (어느 구역인지)
→ 나머지 8비트(.5 부분): 호스트 번호 (그 구역 안의 몇 번째 기기인지)
→ 할당 가능한 IP: 254개 (256개 중 첫 번째/마지막 2개 제외)
10.0.1.5/16
→ 앞 16비트(10.0 부분): 네트워크 주소
→ 나머지 16비트(1.5 부분): 호스트 번호
→ 할당 가능한 IP: 65,534개
참고로 할당 가능한 IP 중 첫 번째/마지막 2개는 제외된다.
맨 처음 번호(예: 10.0.1.0)는 네트워크 자체를 가리키는 주소이고,
맨 마지막 번호(예: 10.0.1.255)는 네트워크 안의 모든 기기에게 동시에 신호를 보내는 브로드캐스트 주소라 기기에 직접 할당할 수 없다.
실제로는 이렇게 나눈다
회사 전체에 10.0.0.0/16이라는 큰 대역(약 65,534개의 IP)이 할당되어 있다면,
이걸 그대로 다 같이 쓰는 게 아니라 부서/용도별로 작은 서브넷으로 잘라서 나눠 쓴다.
회사 전체 대역: 10.0.0.0/16
개발팀 서브넷: 10.0.1.0/24 (254개)
인사팀 서브넷: 10.0.2.0/24 (254개)
서버실 서브넷: 10.0.10.0/24 (254개)
게스트 와이파이 서브넷: 10.0.20.0/24 (254개)
이렇게 미리 구역을 나눠두면,
누군가 인사팀 와이파이에 연결하는 순간 그 기기는 자동으로 10.0.2.x 대역의 IP를 받는다.
개발팀 와이파이에 연결하면 10.0.1.x 대역을 받는다.
해당 구역의 와이파이에 연결하는 순간 그 대역의 IP를 자동으로 할당해주는 것이 DHCP다.
방화벽: 구역 사이의 통행 규칙 정하기
서브넷으로 구역만 나눠놓는다고 보안이 저절로 강화되는 건 아니다.
"어느 구역에서 어느 구역으로 통신을 허용할지"를 실제로 정해주는 규칙이 필요한데, 그 역할을 하는 것이 방화벽(Firewall)이다.
예를 들어 다음과 같은 규칙을 만들 수 있다.
1. 서버실 서브넷(10.0.10.0/24)에는 개발팀 서브넷(10.0.1.0/24)에서만 접근 가능
2. 인사팀 서브넷(10.0.2.0/24)에서는 서버실 접근 불가
3. 게스트 와이파이 서브넷(10.0.20.0/24)에서는 내부 어떤 서브넷에도 접근 불가, 오직 인터넷만 허용
서브넷이 "건물을 동 단위로 나누는 것"이라면, 방화벽은 "그 동들 사이에 누가 드나들 수 있는지 정하는 경비 규칙"이다.
참고로 4편에서 배운 게이트웨이(공유기)도 기본적인 방화벽 기능을 함께 가지고 있다.
"내부에서 먼저 요청한 경우에만 응답을 허용한다"는 규칙 자체가 방화벽의 가장 기본적인 형태다.
DMZ: 외부에 공개할 서버는 따로 둔다
회사가 외부에 공개해야 하는 서비스(예: 회사 홈페이지를 호스팅하는 웹서버)를 운영한다면, 고민이 하나 생긴다.
이 웹서버를 내부망 깊숙한 곳에 두자니 외부와 통신하기 위해 내부망까지 일부 열어줘야 하고,
그렇다고 완전히 외부망에 노출시키자니 보안이 너무 취약해진다.
이 문제를 해결하기 위한 설계 패턴이 DMZ(Demilitarized Zone, 비무장지대)다.
외부에 공개해야 하는 서버들만 모아놓은 별도의 서브넷을 만들고,
이 구역은 외부 인터넷과 제한적으로 통신을 허용하면서도 내부 핵심 서브넷(DB서버, 사내 시스템 등)과는 분리해놓는다.
인터넷(외부망)
↓ 제한적 접근만 허용
DMZ 서브넷 (웹서버 등 외부 공개용)
↓ DMZ에서 내부로의 접근은 더 엄격히 제한
내부 핵심 서브넷 (DB서버, 사내 시스템 등)
DMZ는 외부망과 내부 핵심망 사이에 두는 완충지대다.
만약 DMZ에 있는 웹서버가 해킹을 당하더라도, DMZ와 내부 핵심 서브넷 사이에 또 다른 방화벽 규칙이 있기 때문에
공격자가 곧바로 내부 핵심 시스템(DB 등)까지 침투하기는 어렵다.
비유하면, DMZ는 "외부 손님을 맞이하는 회사 로비"와 같다.
손님(인터넷 트래픽)은 로비(DMZ)까지는 들어올 수 있지만, 사무실(내부 핵심망)로 가려면 또 다른 출입 통제(방화벽)를 거쳐야 한다.
서브넷, 방화벽, DMZ는 각각 독립된 개념이 아니라 함께 작동한다.
서브넷으로 내부망을 구역으로 나누고,
방화벽으로 그 구역 사이의 통행 규칙을 정하고,
DMZ로 외부에 공개할 서버를 안전하게 분리한다.
이 세 가지가 함께 작동하면서 내부망은 외부에 최소한으로만 노출되면서도 정상적으로 인터넷과 통신할 수 있게 된다.
그리고 이 작업은 회사가 클라우드(AWS 등)로 인프라를 옮기더라도 본질은 똑같이 반복된다.
물리적인 케이블과 스위치 설정이 VPC/서브넷/보안그룹 설정으로 바뀔 뿐이다.