네트워크 인프라 이해하기 · 제4부 · 배운 원리로 실제 망을 어떻게 설계할까
기업의 사설 IP는 어떻게 겹치지 않게 설계할까
연결 전 중복을 막고 요약·성장·책임을 함께 관리하는 주소 계획
본사와 지사, 클라우드가 나중에 연결될 수 있다면 지금 비어 보이는 사설 대역도 함부로 배정할 수 없습니다. 기업은 주소를 지역·사이트·기능별로 나누고 승인한 계획과 실제 사용 상태를 IPAM에서 함께 관리해야 합니다. 이 글에서는 중복을 막는 설계, Route Summary가 가능한 계층 배치, DHCP 범위, 다른 조직망을 인수한 뒤의 통합과 클라우드 연결까지 차례로 살펴봅니다.
본사·지사·클라우드가 나중에 연결될 것까지 생각하면 어떤 주소를 먼저 기록해야 할까↑
본사와 지사 LAN만 보고 사설 주소를 정하면 클라우드 VPC, 원격 접속 Pool, 협력사 VPN과 인수 조직의 주소가 나중에 충돌합니다. 지금 직접 관리하지 않는 연결 대상도 후보 Prefix와 책임자를 기록해야 합니다.
RFC 1918의 세 블록 중 무엇을 선택하든 전부 쓰겠다고 예약하지 않습니다. 필요한 성장 범위와 외부 연결 가능성을 기준으로 상위 블록을 정하고, 사용하지 않는 공간도 왜 비워 두었는지 기록합니다.
주소 지도에는 현재 Route가 교환되는 네트워크뿐 아니라 연결 후보도 넣습니다. Remote Access VPN Pool, Kubernetes Pod·서비스 CIDR, 클라우드 Peering, 백업 네트워크와 장비 관리 대역이 빠지기 쉽습니다. 같은 Prefix가 서로 다른 VRF에 격리되어 있으면 당장은 공존할 수 있지만, 두 VRF 사이 서비스를 연결하는 순간 Translation이나 Readdressing 문제가 나타납니다. 격리 조건까지 주소 자산의 속성으로 기록해야 합니다.
상위 블록을 고를 때는 “RFC 1918에서 비어 보인다”만 보지 않습니다. 이미 연결된 협력사에서 자주 쓰는 범위, 클라우드 Provider의 예약 범위, 향후 Region 수와 Site당 필요한 Summary를 함께 검토합니다. 예비 공간에는 소유 팀과 사용 조건을 붙입니다. 이유 없는 빈 공간은 다음 프로젝트가 먼저 가져가지만, 목적이 기록된 여유 공간은 주소 계획의 성장 방향을 유지합니다.
각 Prefix에는 위치, 기능, VRF/라우팅 문맥, 상위 블록, 상태, 소유 팀, 변경 티켓과 마지막 관측 시각을 붙입니다. 10.0.0.0/8처럼 큰 사설 범위를 “사용 중”이라고만 기록하면 어디가 비어 있는지 판단할 수 없습니다. 반대로 Ping이 안 된다는 이유만으로 빈 주소라 표시하면 방화벽 뒤 장비나 일시 중단된 자산을 재할당할 수 있으므로, 선언된 사용과 실제 관측을 별도 필드로 유지합니다.
이 절의 근거 IETF RFC 1918 · IETF RFC 4632 · IETF RFC 4193
주소 블록을 지역과 기능에 맞춰 나누면 Route와 장애 범위를 함께 정리할 수 있다↑
상위 블록을 지역이나 큰 네트워크 영역에 먼저 나누면 WAN 경계에서 하나의 Summary Route로 광고하기 쉽습니다. 그 안을 사용자, 서버, 관리, 음성처럼 운영·보안 정책이 다른 용도로 나눌 수 있습니다.
옥텟 하나에 지점 번호를 넣는 방식은 사람이 읽기 쉬울 수 있지만 Prefix 경계와 맞지 않으면 Summary가 깨집니다. 숫자 모양보다 Binary Prefix의 연속성과 조직의 실제 경계를 우선합니다.
예를 들어 조직이 10.64.0.0/10을 내부용으로 정하고 Region A에 10.64.0.0/14, Region B에 10.68.0.0/14를 맡길 수 있습니다. 각 Region은 그 안에서 사용자·서버·관리 Prefix를 나누고 WAN에는 /14 Summary를 광고합니다. 새 Site가 생겨도 Region 블록 안에서 배치하면 상위 라우터의 Route 수와 변경 범위를 일정하게 유지할 수 있습니다.
Summary가 너무 넓으면 실제로 존재하지 않는 Child Prefix 트래픽까지 해당 Region으로 끌어들일 수 있습니다. Region 경계의 Discard Route, 이중화 Site의 더 구체적인 광고와 Partial 장애 동작을 함께 설계해야 합니다. 보안 Zone과 장애 복구 단위가 주소 경계와 어긋나면 정책과 Route가 복잡해집니다. 읽기 쉬운 주소 모양보다 Route·장애 도메인·운영 책임이 같은 Prefix 경계에 정렬되는지가 더 중요합니다.
요약 경로를 광고하면 그 안에 포함된 주소로 향하는 트래픽을 받아들이게 됩니다. 하위 경로가 사라졌는데 요약 경로만 남아 있으면 트래픽이 집약 지점까지 왔다가 폐기될 수 있습니다. 따라서 주소 블록을 나눌 때는 집약 위치와 이중화 경로, 일부 대역에 장애가 난 경우의 동작도 함께 검토합니다. 예외 경로를 추가할 때에도 기존 요약 범위와 충돌하지 않는지 확인해야 합니다.
이 절의 근거 IETF RFC 4632
같은 Subnet에서도 장비·고정 클라이언트·일반 클라이언트의 주소 관리 방식은 다르다↑
Gateway, 네트워크 장비, 서버, DHCP 클라이언트가 같은 Subnet을 사용해도 할당 방식은 다를 수 있습니다. Dynamic Pool과 수동 Static 주소가 겹치지 않게 범위를 나누고, DHCP Reservation도 IPAM에서 사용 상태로 기록합니다.
| 상태 | 대표 대상 | 필요 기록 |
|---|---|---|
| Infrastructure | Gateway·스위치·AP | 장비·인터페이스·관리 책임 |
| Reservation | Printer·특정 클라이언트 | 식별자·예약 근거 |
| Dynamic Pool | 일반 클라이언트 | Scope·Lease·제외 범위 |
| Held | 증설·이관 예정 | 소유자·해제 조건 |
DHCP Scope, 예약 주소, 동적 할당 범위와 제외 범위는 IPAM에 기록한 주소 계획과 맞아야 합니다. 이 범위들이 모두 같은 숫자 구간이어야 한다는 뜻은 아닙니다. 각 범위의 역할을 구분하고, 수동으로 설정한 주소를 다른 단말에 동적으로 내주지 않도록 구성합니다.
주소 상태에는 단순한 “사용 중”보다 소유자, 인터페이스, 할당 방식, 생성·만료 근거가 필요합니다. Reservation은 서버 설정과 클라이언트 Identifier를, Static 주소는 장비 설정과 변경 요청을, Dynamic 주소는 Scope와 Lease를 연결합니다. Printer를 철거했는데 Reservation과 DNS Record만 남으면 주소가 영구 점유된 것처럼 보일 수 있습니다. 자산 폐기 절차에 DNS·DHCP·IPAM 회수를 함께 넣어야 실제 가용 주소를 알 수 있습니다.
수동 고정 주소와 동적 할당 주소가 겹치지 않도록 Pool 경계를 명시하고, DNS Update·자산 등록·Lease 보존 기간도 함께 정합니다. 주소만 보고 사용자를 장기간 식별해야 하는 보안 요구가 있다면 NAT Log와 인증 기록의 시각 동기화도 필요합니다. IPAM 한 필드가 모든 실제 사용자를 실시간으로 증명한다고 가정해서는 안 됩니다.
이 절의 근거 IETF RFC 1918 · IETF RFC 2131 · Microsoft IP Address Management
도해에서 확인할 내용 왼쪽 /24의 예에서는 게이트웨이 주소, 고정 인프라 주소, DHCP 임대 풀, 예비 블록의 역할을 구분합니다. 가운데 장비에서 오른쪽으로 이어지는 연결은 서비스망을 함께 쓰는 인밴드 관리와 별도 OOB 관리망을 비교합니다. 주소 배정과 관리 접속 경로는 서로 다른 설계 항목입니다.
↔ 도해는 좌우로 움직여 볼 수 있습니다.
클라우드나 인수 회사와 연결한 뒤 주소 중복을 발견하면 왜 해결하기 어려울까↑
두 네트워크가 같은 Prefix를 사용하면 라우터는 목적지만 보고 어느 쪽으로 보낼지 구분할 수 없습니다. NAT로 일부 통신을 우회할 수 있지만 DNS, 로그, 양방향 접속과 운영 복잡성이 커집니다.
새 VPC·지사·인수 조직을 연결하기 전에 Prefix 목록을 자동 비교하고, 변경 가능한 쪽의 Readdressing 계획을 정합니다. 임시 NAT를 쓴다면 종료 조건과 원래 주소·변환 주소의 기록을 함께 남깁니다.
본사가 10.10.0.0/16, 인수 회사도 같은 Prefix를 쓰면 두 Route를 한 VRF에 동시에 설치해 목적지만으로 구분할 수 없습니다. 일부 애플리케이션만 빠르게 연결해야 한다면 NAT 도메인을 만들 수 있지만, 양쪽 DNS가 원래 주소와 변환 주소를 어떻게 돌려주는지, 어느 쪽에서 접속을 시작하는지까지 설계해야 합니다. Log와 Access 정책에도 두 주소를 연결할 기준이 필요합니다.
장기 통합에서는 보통 변경 가능한 쪽의 Readdressing이 더 단순한 목표 구조를 만듭니다. 다만 서버 의존성, License Binding, ACL과 Static Route를 조사하지 않고 주소만 바꾸면 숨은 장애가 생깁니다. 연결 전 Prefix Overlap 검사는 정확히 같은 CIDR뿐 아니라 한 Prefix가 다른 Prefix를 포함하는 경우까지 찾아야 합니다. 임시 NAT에는 대상 서비스, 종료 날짜, 책임자와 Readdressing 단계가 함께 있어야 임시 구조가 영구화되지 않습니다.
연결 전에는 양쪽 Prefix를 정확한 Prefix Length와 VRF 단위로 대조하고, 충돌 시 주소를 바꿀 쪽을 수명·장비 수·외부 의존성으로 평가합니다. 임시 NAT를 택하면 변환 전후 주소의 책임자, 허용 서비스, Log 보존과 종료 조건을 문서화합니다. 장기적으로 연결할 환경에는 중앙 예약 블록을 미리 배정하고 클라우드 자동 생성 기본 CIDR을 그대로 승인하지 않는 절차가 유리합니다.
이 절의 근거 IETF RFC 1918 · IETF RFC 4193
IPAM이 빈 주소만 표시한다면 왜 운영의 Source of Truth가 될 수 없을까↑
IPAM은 Prefix, VLAN, VRF, 사이트, DHCP Scope와 실제 주소 상태를 연결해야 합니다. 주소가 사용 중인지뿐 아니라 누가 왜 Reservation을 만들었고 어느 변경으로 할당되었는지 이력이 있어야 회수와 장애 대응이 가능합니다.
장비 설정, DHCP/DNS와 클라우드 API에서 관찰한 값이 IPAM과 다르면 어느 쪽이 정본인지 결정해야 합니다. 자동 수집은 차이를 찾는 도구이고, 승인되지 않은 값을 자동으로 정답으로 덮어쓰는 기능이 아닙니다.
새 VLAN을 만들 때 IPAM에서 프리픽스와 게이트웨이를 먼저 예약하고, 승인한 값을 DHCP·DNS와 네트워크 설정에 반영하면 주소 변경의 기준이 일관됩니다. 장비에서 주소를 먼저 만든 뒤 IPAM에 기록하면 중복을 뒤늦게 발견할 수 있습니다. Source of Truth는 화면에 보이는 값이 늘 옳다는 뜻이 아니라, 승인된 주소 계획과 변경 내역을 확인할 기준으로 삼는다는 뜻입니다.
실제 상태를 수집하는 Discovery는 승인된 계획과 현장의 차이를 찾는 데 사용합니다. Ping 응답만으로 주소 사용자를 단정하지 않고 ARP·MAC, DHCP Lease, DNS와 클라우드 API 결과를 대조합니다. 차이를 자동으로 고치기 전에는 항목별로 어느 기록을 기준으로 삼을지 정해야 합니다. 동적 임대는 DHCP Lease를, 장기적인 주소 대역의 담당 부서는 IPAM을 기준으로 확인하는 식입니다.
자동 발견 결과도 신뢰 범위와 시각이 있습니다. ARP에 없다고 장비가 없는 것은 아니고, 오래된 DNS Record가 실제 사용을 뜻하지도 않습니다. 동기화 Job은 출처·수집 시각·충돌 규칙을 남기고, 자동으로 삭제하기보다 검토 대기 상태를 만드는 편이 안전합니다. Prefix 생성·할당·회수에는 승인자와 변경 번호를 요구해 누가 어떤 근거로 상태를 바꿨는지 추적합니다.
이 절의 근거 IETF RFC 4632 · Microsoft IP Address Management
도해에서 확인할 내용 왼쪽은 IPAM에 승인해 둔 주소 계획이고, 가운데는 DHCP·DNS·ARP·MAC 테이블과 클라우드·CMDB에서 수집한 실제 상태입니다. 오른쪽에서는 둘을 대조해 주소 중복, 남은 등록 정보, 계획과 다른 변경을 찾습니다. 아래 순서는 변경 요청부터 승인·적용·관측·감사까지 이어지는 관리 절차입니다.
↔ 도해는 좌우로 움직여 볼 수 있습니다.
새 대역을 확정하기 전에 겹침·Route Summary·성장 공간을 한꺼번에 검토한다↑
상황: 새 클라우드 환경에 10.0.0.0/16을 제안했지만 기존 지사 VPN 일부가 같은 범위를 사용합니다.
- 사내·지사·원격 접속·협력사·클라우드의 전체 Prefix를 수집합니다.
- 정확히 겹치는 Prefix와 한쪽이 다른 쪽을 포함하는 경우를 구분합니다.
- 변경 비용, 미래 요약과 성장 공간을 비교해 새 클라우드 Prefix를 다시 배치합니다.
- VPC·Subnet·Route·보안 정책·DNS 설계를 같은 변경 단위로 검토합니다.
- 할당 근거와 책임자를 IPAM에 기록하고 연결 전 양방향 Route를 시험합니다.
후보 Prefix마다 세 가지 시험을 수행합니다. 전사 Prefix Set과 Overlap이 없는지, Site·Region Summary 안에 정렬되는지, 예상 Subnet과 성장 공간을 연속해서 수용하는지 확인합니다. 여기에 클라우드의 최소·최대 Prefix 제한, 예약 주소와 연결 방식도 반영합니다. 주소 수만 충분한 후보가 Route와 운영 경계에서는 나쁜 선택일 수 있으므로 세 조건을 같은 표에서 비교합니다.
배포 후에는 IPAM의 계획값과 클라우드 Route 테이블, On-Premises 라우터, DHCP·DNS의 관찰값을 자동 비교합니다. 새 연결을 열기 전 양방향 Route 조회와 대표 서비스 통신 흐름을 시험하고, NAT가 개입하면 변환 전후 주소를 기록합니다. 사용하지 않는 예약 블록도 정기적으로 근거를 검토해 반환하거나 유지 이유를 갱신합니다. 주소 계획은 한 번 만든 도면이 아니라 연결과 조직 변화에 맞춰 계속 검증하는 운영 데이터입니다.
결과물은 주소표 하나가 아니라 Prefix 결정의 근거와 의존 시스템 목록입니다. 이 기록이 있으면 증설 때 빈칸을 다시 추측하지 않고, 장애 때 잘못된 Route·DHCP Pool·방화벽 Object 중 어디가 설계 의도와 어긋났는지 빠르게 비교할 수 있습니다.
이 절의 근거 IETF RFC 4632 · IETF RFC 3021 · Microsoft IP Address Management
FAQ↑
사설 주소는 10.0.0.0/8 하나만 쓰는 것이 좋은가요?
NAT를 쓰면 주소 중복을 그대로 둘 수 있나요?
IPAM에 자동 발견된 주소는 바로 사용 중으로 확정해도 되나요?
용어사전↑
출처와 검증
- IETF RFC 1918 — IPv4 사설 주소 공간과 설계 고려
- IETF RFC 4632 — Classless Prefix와 Route Aggregation
- IETF RFC 4193 — IPv6 Unique Local Address
- IETF RFC 3021 — IPv4 Point-to-Point /31 사용
- IETF RFC 2131 — DHCP의 Dynamic Allocation과 Manual Allocation
- Microsoft IP Address Management — 주소 공간의 계획·배포·관리·감사 기능을 갖춘 IPAM 구현 예시
주소 계층과 예비 주소 블록 비율은 조직 규모·연결·운영 도구에 따라 달라집니다. 특정 옥텟 규칙이나 고정 비율을 보편 표준으로 제시하지 않았습니다.