네트워크 인프라 이해하기 · 제4부 · 배운 원리로 실제 망을 어떻게 설계할까

공유기 한 대가 하는 일을 대규모 기업망에서는 어떻게 나눠 설계할까

기능 목록이 아니라 장애·변경·상태의 경계로 장비 역할을 나누는 설계

BY 주식회사 아이엠비즈니스플랫폼 PUB 2026-07-24 UPD 2026-10-26 READ 약 11분 VERIFY 표준·공식 자료 대조 $ subnet

가정용 공유기 한 대는 스위칭, DHCP, 라우팅, NAT와 방화벽을 함께 처리합니다. 기업망은 기능이 실패하거나 변경될 때의 영향 범위에 따라 이 역할을 여러 장비와 운영 책임으로 나눕니다. 이 글에서는 패킷이 지나는 순서와 각 기능이 남기는 상태를 기준으로 어떤 경계를 분리하고 어떤 이중화 조건을 확인해야 하는지 설명합니다.

공유기 한 대 안에서도 한 번의 통신을 위해 여러 기능이 차례로 일한다↑

가정용 장비는 무선 Access Point, Ethernet 스위치, DHCP 서버, Default Gateway, NAT와 Stateful 방화벽 역할을 한 제품에서 제공합니다. 사용자는 한 화면에서 설정할 수 있고 작은 환경에서는 운영이 단순합니다.

한 기능의 이름과 제품 이름을 혼동하면 기업망을 이해하기 어렵습니다. 공유기라는 상자 안에서도 패킷은 L2 스위칭, L3 라우팅, 주소 변환과 보안 정책이라는 서로 다른 판단을 차례로 거칩니다.

노트북이 인터넷 서버로 패킷을 보낼 때 이 한 상자 안에서도 역할은 순서대로 달라집니다. 무선 AP가 프레임을 받고 내장 스위치가 VLAN 안에서 전달한 뒤, Gateway 기능이 Destination IP로 Route를 조회합니다. DHCP 서버는 그보다 앞서 클라이언트 설정을 제공했고, 인터넷 방향에서는 방화벽 정책과 NAT/PAT가 허용 여부와 주소 매핑을 처리합니다. 외형은 한 장비지만 패킷 처리 관점에서는 여러 경계가 연속되어 있습니다.

장애 때도 어느 기능이 작동하지 않는지 나누어 보면 원인을 찾기 쉽습니다. Wi-Fi 단말만 끊겼다면 무선 구간을, 유선·무선 단말 모두 주소를 못 받는다면 DHCP를 먼저 살펴봅니다. 내부 서버에는 접속되는데 인터넷만 안 된다면 기본 경로·NAT·WAN을 확인합니다. 기업망에서도 이 원리는 같습니다. 기능을 별도 장비로 옮겨도 그 기능이 맡은 일과 앞뒤의 통신 경로를 구별할 수 있어야 합니다.

여러 기능이 한 장비 안에 있어도 각각의 동작 조건은 다릅니다. DHCP로 주소를 받아도 외부 경로가 없을 수 있고, 경로가 있어도 방화벽 정책이나 NAT 설정 때문에 통신이 안 될 수 있습니다. 장비 그림과 함께 패킷이 들어오는 포트, 조회하는 경로와 정책, 바뀌는 주소와 상태, 나가는 포트를 적어 보면 작은 망과 기업망에서 같은 기능이 어디에 배치되어 있는지 비교할 수 있습니다.

이 절의 근거 IETF RFC 1122 · IETF RFC 1812

도해에서 확인할 내용 아래 도해는 앞에서 설명한 흐름을 바탕으로 SOHO 공유기 안의 L2/L3 처리와 PAT 헤더 재작성, ISP Access·IXP·서버까지 이어지는 실제 전달 구간까지 한 화면에 정리했습니다. 화살표와 번호를 따라가며 단말의 헤더 값이 공유기에서 어떻게 바뀌고 어느 구간을 거쳐 서버에 도달하는지 확인할 수 있습니다.

↔ 도해는 좌우로 움직여 볼 수 있습니다.

기업망이 장비 역할을 나누는 기준은 사용자 수보다 장애와 변경의 영향이다↑

기업망에서 역할을 나누는 이유는 단순히 트래픽이 많기 때문만은 아닙니다. 사용자 Access 정책은 자주 바뀌고, Core Route는 안정성이 중요하며, 인터넷 방화벽은 보안 변경과 감사가 필요합니다. 서로 다른 변경 주기를 한 장비에 묶으면 영향 범위가 커집니다.

분리는 물리 장비만 뜻하지 않습니다. VRF와 가상 방화벽처럼 하나의 시스템 안에서도 라우팅 영역과 보안 정책을 논리적으로 나눌 수 있습니다. 다만 Control Plane·Data Plane의 독립성은 구현에 따라 다릅니다. Virtual 섀시와 Stack은 여러 장비를 하나의 논리 장비로 묶으므로, 장애 영역과 관리 책임이 서로 독립적이라고 간주해서는 안 됩니다.

사용자 100명이라도 24시간 생산 설비와 사무망이 함께 있다면 장애 도메인을 나눌 이유가 충분합니다. 반대로 500명 교육장처럼 동일 정책과 짧은 운영 시간의 환경은 단순한 구조가 더 나을 수 있습니다. 장비 수는 인원 비례식으로 정하지 않고, 한 변경이나 장애가 중단시키는 업무, 허용 중단 시간, 담당 팀과 승인 절차를 기준으로 정합니다.

자주 바뀌는 Access 정책과 안정적으로 유지해야 하는 Core 라우팅을 같은 구성 단위에 두면 작은 사용자 변경이 넓은 라우팅 영향으로 이어질 수 있습니다. 물리 분리 외에도 VRF, Virtual Context, 독립된 구성 Pipeline으로 변경 범위를 나눌 수 있습니다. 다만 같은 섀시·Power·Control Plane을 공유하면 공통 장애가 남습니다. 논리 분리와 물리 독립성을 각각 표시해야 이중화 수준을 과대평가하지 않습니다.

처리량, 포트 밀도, 암호화 성능, 상태 수, 정책 복잡도와 팀 책임도 분리 기준이 됩니다. 반대로 규모가 작고 같은 팀이 동일한 변경 창에 운영한다면 통합 장비가 더 단순할 수 있습니다. “기업은 반드시 N계층” 같은 고정 답보다 기능별 용량, 장애 영향, 변경 빈도와 복구 시간을 표로 만들어 분리의 이익과 추가 의존성을 비교합니다.

이 절의 근거 IETF RFC 1812 · Cisco Design Zone

서비스가 끊겨도 장비에 접속하려면 사용자 패킷 경로와 관리 경로를 나눠야 한다↑

사용자 패킷은 Access에서 들어와 VLAN과 Gateway를 거쳐 내부 서비스 또는 인터넷 Edge로 나갑니다. 이 Data Plane 경로와 별도로 운영자는 장비의 관리 인터페이스, 인증, 로그와 시간 동기화에 접근해야 합니다.

업무 통신과 관리 접속이 같은 경로를 사용하면 장애가 났을 때 장비 상태를 확인하거나 설정을 되돌리지 못할 수 있습니다. 별도 관리망이 필요한지는 현장의 복구 요구에 따라 판단하되, 주 경로가 끊겨도 사용할 관리 수단이 있는지는 설계 때 확인해야 합니다.

관리 경로에는 SSH·HTTPS 접속뿐만 아니라 AAA, DNS, NTP, Syslog, Telemetry와 Software 배포가 포함됩니다. 장비가 살아 있어도 TACACS 서버나 DNS에 도달하지 못하면 운영자가 Login하지 못할 수 있고, NTP가 틀리면 여러 Log의 장애 시각을 연결하기 어렵습니다. 관리 VRF나 전용 인터페이스를 쓴다면 이 종속 서비스가 어느 Route와 방화벽 정책을 사용하는지까지 설계해야 합니다.

Out-of-Band 네트워크는 Production Data Plane과 다른 스위치·회선을 사용해야 장애 격리 효과가 있습니다. 같은 Core와 Power를 공유하면서 VLAN만 다르면 일부 장애에는 여전히 함께 끊깁니다. Console 서버, Cellular 백업과 현장 접근 절차를 포함해 “주 경로가 완전히 사라졌을 때 어떻게 확인하고 원복할 것인가”를 시험합니다. 관리망 자체가 새로운 단일 장애 지점이 되지 않도록 인증과 접근 Log도 별도로 보호해야 합니다.

관리 주소만 별도 VLAN에 두었다고 독립성이 완성되지는 않습니다. 같은 Core, 같은 전원, 같은 DNS·AAA 서버와 같은 WAN 회선을 공유하면 해당 장애가 관리 경로도 함께 끊을 수 있습니다. 설계도에는 관리 단말에서 장비까지의 Route, 인증·이름 해석·시간 동기화 의존성과 비상 Local 접근 절차를 그려 실제 공통 실패 지점을 찾습니다.

이 절의 근거 IETF RFC 6192

장비를 두 대 놓는 것만으로는 왜 끊김 없는 이중화가 완성되지 않을까↑

장비를 두 대 배치해도 Gateway 상태, 라우팅, NAT와 방화벽 세션이 어떻게 전환되는지 정하지 않으면 기대한 복구가 일어나지 않습니다. Active/Standby와 Active/Active의 이름보다 장애 감지, 상태 동기화, 전환 중 손실과 되돌림을 확인합니다.

모든 구간을 이중화하면 복잡성도 늘어납니다. 단일 장애 지점의 영향, 허용 가능한 복구 시간과 운영 능력을 비교해 필요한 곳부터 적용합니다.

Default Gateway 이중화에서는 클라이언트가 사용하는 Virtual IP·MAC이 어느 장비로 이동하는지, 상·하단 Route가 새 Active 장비를 향하는지 확인합니다. 방화벽 Cluster라면 세션과 NAT Mapping, VPN Security Association의 동기화 범위가 추가됩니다. 두 장비 모두 Active라고 믿는 Split-Brain이 생기면 같은 Virtual IP를 서로 광고하거나 비대칭 경로를 만들 수 있으므로 Heartbeat와 장애 Detection 경계도 설계 대상입니다.

장애 전환 뒤에는 새 ping의 성공 여부뿐 아니라 기존 TCP 연결, 새 연결, 장시간 이어지는 UDP 흐름과 외부에서 들어오는 DNAT 접속을 각각 시험합니다. 패킷 손실과 복구 시간을 측정하고, 주 장비로 복귀할 때도 경로와 연결 상태가 안정적인지 확인합니다. 장비 전체 고장에 더해 업링크 단절, 상위 경로 상실, 상태 동기화 링크 단절도 따로 시험해야 실제 장애 범위와 연결 유지 조건을 알 수 있습니다.

두 경로가 같은 전원·광관로·통신사 PoP·설정 배포에 의존하면 독립적인 경로가 아닙니다. 정상 상태의 그림과 함께 장비, 링크, 전원, 회선, Control Plane과 상태 동기화가 각각 실패했을 때 Active Path와 수렴 시간을 기록합니다. Stateful 장비는 신규 세션과 기존 세션의 결과를 따로 시험하고, 복귀 시 Preemption이나 비대칭 경로가 만드는 두 번째 장애도 확인합니다.

이 절의 근거 IETF RFC 1812 · Cisco Design Zone

NAT가 주소를 바꾸는 지점과 방화벽이 통신을 검사하는 지점은 다를 수 있다↑

가정용 장비에서는 NAT와 방화벽이 같은 화면에 있어 하나의 기능처럼 보입니다. 기업망에서는 Internal Segmentation 방화벽, 인터넷 Edge NAT, 클라우드 Security Group처럼 정책 경계가 여러 곳에 있을 수 있습니다.

어느 장비가 주소를 바꾸는지, 어느 장비가 원래 주소를 기준으로 정책과 로그를 남기는지 문서화해야 합니다. 변환 전후 주소를 연결하지 못하면 사고 분석과 서비스 장애 진단이 끊깁니다.

방화벽이 NAT 전에 원래 Source 10.20.30.25로 정책을 평가하는지, NAT 뒤 공인 Source로 평가하는지는 제품의 패킷 Processing 순서와 정책 위치에 따라 다릅니다. 인터넷 Edge Log에는 바깥 Tuple만, 내부 Segmentation 방화벽에는 원래 Tuple만 보일 수 있습니다. 사고 조사와 애플리케이션 Allowlist를 위해 두 Log를 동기화된 시각과 주소 변환 장비가 기록한 변환 전후의 주소·포트 대응 관계로 연결할 수 있어야 합니다. Translation ID는 장비가 제공하는 경우 보조 식별자로 사용하며, 서로 다른 장비에서 같은 값이라고 가정하지 않습니다.

클라우드에서는 Route 테이블, Security Group, 네트워크 방화벽과 NAT Gateway가 서로 다른 서비스로 배치될 수 있습니다. 패킷이 어느 경계에서 Source·Destination을 바꾸고 어느 경계가 Stateful 판단을 하는지 도식화해야 합니다. 보안 Zone을 NAT 위치와 자동으로 같게 놓으면 내부 East-West 트래픽이나 IPv6처럼 NAT를 거치지 않는 통신 흐름의 정책이 빠질 수 있습니다. 정책 경계는 신뢰 수준과 관찰 필요성으로, 주소 변환은 라우팅과 주소 영역의 요구로 각각 정합니다.

보안 장비가 실제 출발지 주소를 보아야 하는지, 변환 전후 어느 주소로 정책을 적용하는지, 응답은 어디를 거치는지에 따라 기능을 배치합니다. DNAT로 공개하는 서비스라면 외부 접속 주소, 변환 후 내부 서버 주소와 허용 포트를 표시합니다. 서버의 응답이 나갈 때 출발지 주소·포트가 외부에 공개한 값으로 되돌아가는 과정도 확인합니다. 여러 방화벽이나 부하 분산 장비를 거친다면 각 지점의 주소·포트, 연결 상태를 관리하는 장비와 비대칭 경로의 허용 조건을 함께 기록합니다.

이 절의 근거 IETF RFC 3022 · NIST SP 800-41 Rev. 1

도해에서 확인할 내용 기업 내부의 접속·집계·코어와 외부 망 연결 구간에 기능을 나누어 배치한 예입니다. 인증, 접근 제어, 방화벽 등은 통신 경로와 보호 대상에 맞춰 조합합니다. 장비를 나열하거나 보안 기능을 여러 겹 배치했다고 Zero Trust가 완성되는 것은 아닙니다. 사용자·기기와 접근 대상의 조건을 확인해 권한을 판단하는 정책이 필요합니다. 그림의 장비 유형, 회선 속도와 세션 수는 구성 예시이지 기업망의 필수 사양이나 성능 보장값이 아닙니다.

↔ 도해는 좌우로 움직여 볼 수 있습니다.

장비를 고르기 전에 각 기능의 장애 영향과 담당자를 한 표에 먼저 정리한다↑

상황: 80명 사무실을 500명 규모로 확장하면서 기존 공유기를 교체합니다.

현재 장비가 제공하는 Wi-Fi, DHCP, 스위칭, 라우팅, NAT, VPN과 방화벽 역할을 적습니다.
각 역할의 장애가 영향을 주는 사용자·서비스와 허용 복구 시간을 정합니다.
내부 Gateway, 인터넷 Edge와 관리 경계를 어디에서 나눌지 설계합니다.
상태 동기화와 전환 시 끊기는 통신 흐름, 운영 담당자와 로그 위치를 기록합니다.
최대 사양보다 정상·장애·유지보수 경로를 시험해 설계를 검증합니다.

표의 행에는 Wi-Fi Access, L2 스위칭, DHCP, Default Gateway, Internal 라우팅, 인터넷 라우팅, NAT, 방화벽, VPN과 관리를 둡니다. 열에는 현재 구현, 목표 구현, 설정 담당자, Monitoring, 정상 의존성, 장애 영향, HA 방식과 되돌림 절차를 둡니다. 한 제품이 여러 행에 반복되어도 괜찮습니다. 오히려 그 반복이 현재 한 상자에 묶인 역할과 공통 장애를 드러냅니다.

구성을 정했다면 대표적인 통신을 도면에서 따라가 봅니다. 단말의 주소 할당, 내부 VLAN 사이의 통신, 인터넷 접속, 외부에서 들어오는 공개 서비스 접속, 관리 접속을 각각 그립니다. 정상·장애·정비 상태에서 다음 홉과 적용 정책, 연결 상태를 관리하는 장비를 표시합니다. 이 경로를 장애 시험 결과와 대조하면 빠진 설정이나 설계 조건을 찾을 수 있고, 운영자의 장애 대응 자료로도 활용할 수 있습니다.

시험 환경에서 링크 단절, 장비 재부팅, 상태 동기화 단절과 정책 변경의 영향을 각각 확인합니다. 측정한 복구 시간과 기존 연결의 유지 여부가 업무 요구에 맞는지 보고, 부족한 부분은 장비 배치나 운영 절차를 다시 조정합니다.

이 절의 근거 IETF RFC 6192 · Cisco Design Zone