네트워크 인프라 이해하기 · 제4부 · 배운 원리로 실제 망을 어떻게 설계할까
Access·Distribution·Core는 각각 어떤 일을 맡을까
스위치가 여러 대 있다고 해서 각 장비를 Access·Distribution·Core에 하나씩 대응시킬 수는 없습니다. 계층은 단말을 연결하고, 여러 접속 구간을 모으고, 집계 블록 사이로 데이터를 전달하는 역할을 구분한 이름입니다. 같은 VLAN 안의 통신부터 다른 블록으로 가는 통신까지 따라가며 각 역할이 어느 경로에서 등장하는지 확인합니다.
목차로 돌아가기Access는 단말이 어떤 조건으로 망에 들어올지 정한다 ↑
Access는 PC·전화·AP 같은 단말과 접속 장비를 망에 연결합니다. 이 역할을 이해하려면 위쪽으로 향하는 선보다 단말이 연결된 포트에서 어떤 조건을 적용하는지 먼저 보아야 합니다.
PC-A가 A1의 업무 포트에 연결되면 해당 포트의 속도와 VLAN, 필요한 접속 정책이 통신의 출발 조건이 됩니다. 무선 단말은 AP를 통해 연결되므로 AP의 유선 연결과 전원도 같은 접속 설계에 들어갑니다. 단말의 위치와 사용 방식이 달라지면 Access가 준비해야 할 자원도 달라집니다.
이 사례에서 PC-A와 PC-C는 A1의 같은 VLAN10에 있습니다. 두 단말 사이의 프레임을 A1이 내부에서 전달할 수 있다면 통신은 그 스위치에서 끝납니다. 위쪽 장비가 있다는 이유로 모든 프레임을 먼저 Distribution이나 Core로 보냈다가 되돌려 받는 것은 아닙니다.
Access에서 라우팅까지 수행하는 설계도 가능합니다. 따라서 Access를 L2 장비라는 뜻으로 고정하면 이후 Routed Access를 설명할 수 없습니다. 계층의 이름은 단말 접속을 맡는 위치를 말하고, L2 또는 L3는 그 위치에서 어떤 전달 방식을 쓰는지를 말합니다.
접속 정책의 범위도 단말과 함께 확인합니다. 업무 PC와 방문자 단말이 같은 물리 스위치에 있어도 같은 통신 권한을 가질 필요는 없습니다. 어느 단말이 어떤 망과 서비스에 접속할 수 있는지 정한 뒤, 해당 포트와 무선망에 적용할 정책을 설정합니다.
장애를 확인할 때도 단말이 접속한 곳부터 살펴봅니다. 특정 PC만 실패한다면 그 PC의 링크·주소·VLAN·접속 정책을 정상 단말과 비교합니다. AP 아래 여러 사용자가 함께 실패한다면 AP 전원이나 유선 연결이라는 공유 지점을 살펴봅니다. 망 전체를 보기 전에 어느 접속 묶음에서 결과가 달라졌는지 확인할 수 있어야 합니다.
Distribution은 여러 접속 구간과 공통 서비스를 연결한다 ↑
Distribution은 여러 Access 구간을 집계해 다른 구간과 서비스에 연결합니다. 트래픽의 양보다는 어떤 Access들을 모으고 어느 구간으로 연결하는지를 보면 Distribution의 역할을 이해하기 쉽습니다.
한 건물의 접속 스위치 A1·A2·A3를 D1·D2에 연결해 보겠습니다. D1·D2는 각 스위치에서 올라온 트래픽을 모아 서버나 다른 블록으로 전달합니다. 이 집계 구간에서는 여러 접속 스위치에 필요한 상향 용량과 주소 계획, 정비 범위를 함께 살펴야 합니다.
전통적인 L2 Access 사례에서는 업무 VLAN의 게이트웨이를 Distribution에 둘 수 있습니다. PC-A가 다른 서브넷의 App-S로 보낸 패킷은 그 게이트웨이에서 라우팅됩니다. 이 사례에서는 게이트웨이를 Distribution에 두었지만, 다른 설계에서는 Access에 둘 수도 있습니다.
게이트웨이를 Access로 옮기면 Distribution은 상향 라우팅을 집계하는 다른 역할을 맡습니다. 동일한 역할 이름을 쓰더라도 프레임을 벗기고 라우팅하는 위치와 정책 적용 위치는 달라질 수 있습니다. 도면에는 계층명 옆에 게이트웨이, VLAN 경계, 라우팅 연결을 따로 표시해야 합니다.
집계 장비에서 모든 정책을 처리해야 한다고 고정할 필요도 없습니다. 사용자 접속 조건은 Access에, 서비스별 보호는 별도 서비스 경계에 둘 수 있습니다. 같은 패킷에 정책이 여러 번 적용된다면 각 위치의 목적과 허용 조건을 기록해 의도하지 않은 중복 차단을 구별해야 합니다.
여러 Access가 같은 Distribution에 의존하므로 그 장비 고장과 설정 변경이 미치는 범위를 함께 계산합니다. D1을 정비할 때 D2에 얼마의 수요가 모이는지, 특정 VLAN이 어느 접속 구간까지 이어지는지 확인합니다. 여러 Access를 한곳에 모으면 배선은 정리되지만, 트래픽도 그곳에 모이고 장비 고장의 영향도 여러 Access로 넓어집니다.
Core는 여러 집계 블록 사이의 전달을 맡는다 ↑
Core는 여러 Distribution 블록 사이의 연결을 맡습니다. 모든 현장에 반드시 별도 장비로 존재하는 단계가 아니라, 블록 사이의 전달을 독립해서 다룰 필요가 있을 때 분리하는 역할입니다.
블록 A는 D1·D2와 그 아래 Access들로, 블록 B는 D3·D4와 다른 Access들로 구성했다고 하겠습니다. A의 PC-A가 B의 App-B로 통신할 때 두 블록을 잇는 경로가 필요합니다. C1·C2를 그 사이의 공통 전달 계층으로 두면 각 블록은 다른 모든 블록과 개별 연결을 만드는 대신 Core에 연결할 수 있습니다.
이 구조에서는 블록 안의 단말 접속과 블록 사이의 전송을 구별해서 정비할 수 있습니다. 다만 새로 둔 Core에서도 장애가 날 수 있습니다. Core 장비·링크·전원에 여러 블록이 함께 의존하므로, Core 장비나 링크, 전원 중 무엇이 고장 나도 통신을 유지할지 정해야 합니다.
Core는 여러 집계 블록 사이에서 데이터를 전달하는 데 집중하도록 구성합니다. 검사나 서비스 기능을 추가하려면 처리 자원을 얼마나 쓰는지, 그 기능의 고장이나 설정 변경이 전체 전달에 영향을 주는지 따져 보아야 합니다. 블록마다 처리할 수 있는 기능을 Core에 모두 모으면 공통 장애의 영향도 커질 수 있습니다.
두 개의 작은 블록을 직접 연결하는 방식이 요구를 충족할 수도 있습니다. 건물이 여러 개라는 사실만으로 Core를 의무화하지 말고, 연결 수·광 경로·용량·정비 범위와 운영 복잡성을 비교합니다. 별도 Core를 선택했다면 어떤 기능을 분리했고 여러 블록이 새로 공유하게 된 장비와 경로는 무엇인지 도면에 남깁니다.
Access·Distribution·Core가 맡는 일과 실제 장비를 나란히 놓아 보겠습니다. 장비 대수와 논리적인 역할의 수가 다른 이유를 확인할 수 있습니다.
↔ 도해는 좌우로 움직여 볼 수 있습니다.
같은 VLAN·다른 VLAN·다른 블록의 경로를 나란히 따라간다 ↑
통신이 지나는 계층은 출발지와 목적지의 위치, 그리고 선택한 경계에 따라 달라집니다. 다음 세 경로를 비교하면 모든 패킷이 Access·Distribution·Core를 차례로 거치는 것은 아니라는 점을 알 수 있습니다.
첫째는 PC-A에서 PC-C로 가는 통신입니다. 두 단말이 A1의 같은 VLAN10에 있고 프레임을 직접 전달할 수 있으면 Access 안에서 왕복합니다. 목적지가 다른 접속 스위치에 있다면 같은 VLAN이라도 그 VLAN이 이어진 상향 경로를 사용할 수 있으므로, 같은 VLAN이라는 조건만으로 경로 길이까지 정해지지는 않습니다.
둘째는 PC-A에서 App-S 10.60.20.10으로 가는 통신입니다. 이 사례에서는 VLAN10·20의 게이트웨이를 D1에 두었으므로 A1에서 D1을 거쳐 서버 구간으로 갑니다. D1은 목적지 IP에 맞는 전달 정보를 사용하고, 다음 홉의 MAC 주소를 목적지 주소로 넣어 Ethernet 헤더를 구성합니다. Core까지 올라갈 필요는 없습니다.
셋째는 다른 블록의 App-B 10.70.20.10으로 가는 통신입니다. A1에서 D1을 지나 Core와 블록 B의 Distribution으로 이어집니다. 응답 방향에서도 App-B의 게이트웨이와 PC-A의 서브넷으로 향하는 경로가 필요합니다. 요청이 서버에 도착해도 응답이 돌아올 경로가 없으면 통신은 성립하지 않습니다.
같은 서브넷에 속하더라도 통신이 같은 스위치 안에서 끝나는 것은 아닙니다. 실제 VLAN이 어느 스위치까지 연결되는지와 프레임의 목적지 위치를 함께 보아야 합니다. 주소상의 관계와 물리적으로 지나가는 장비를 구분해야 도면의 선을 실제 전달 경로로 읽을 수 있습니다.
도해에는 어떤 경로가 L2 전달이고 어디에서 IP 라우팅을 하는지 구분해 표시합니다. 스위치가 ACL이나 QoS를 위해 IP 필드를 읽는 것과 목적지 IP로 다음 네트워크를 선택하는 동작은 다릅니다. 따라서 어떤 헤더 필드를 읽고 무엇을 결정하는지까지 적어야 스위칭과 라우팅을 구별할 수 있습니다.
세 목적지를 같은 배치도에 놓으면 통신이 어디에서 끝나는지 보입니다. PC-C로 가는 길은 A1 안에서, App-S로 가는 길은 D1을 거쳐 같은 블록 안에서 끝나고, App-B로 가는 길만 Core를 지납니다.
↔ 도해는 좌우로 움직여 볼 수 있습니다.
PC-A가 같은 VLAN의 PC-C, 같은 블록의 App-S, 다른 블록의 App-B로 보내는 세 경로를 비교합니다. 목적지에 따라 어느 계층까지 지나는지 따라가 보세요.
↔ 도해는 좌우로 움직여 볼 수 있습니다.
논리 역할과 장비 수가 다른 도면을 읽는다 ↑
한 장비가 여러 역할을 맡을 수 있고, 한 역할을 여러 장비가 나눌 수도 있습니다. 설계도에서는 이 두 방향을 모두 설명해야 계층 수와 장비 수를 혼동하지 않습니다.
작은 현장에서 전용 Distribution 없이 접속 장비만으로 현장의 LAN을 구성할 수 있으면 단일 계층을 선택할 수 있습니다. 여러 Access를 집계하면서 별도 Core를 두지 않는 2계층 구성에서는 Distribution과 중심 전달 기능을 함께 배치합니다. 이런 결합을 흔히 Collapsed Core라고 부릅니다.
반대로 별도 Core 역할을 두더라도 C1·C2를 함께 배치해 대체 경로를 제공할 수 있습니다. 두 장비가 있다는 이유로 Core 계층이 두 개가 되는 것은 아닙니다. 두 장비의 제어 관계와 전원·배선의 독립성은 계층 수와 별도로 확인할 이중화 조건입니다.
논리 도면에는 접속·집계·블록 간 전달 역할을, 물리 도면에는 장비·포트·광 경로·전원을 표시합니다. 두 도면에서 같은 장비 식별자를 사용하면 역할을 나누어 그렸더라도 실제로는 한 장비나 전원 회로에 몰려 있는 부분을 찾을 수 있습니다.
같은 장비 이름이 여러 역할에 등장한다면 한 장비가 그 기능들을 함께 맡고 있다는 뜻일 수 있습니다. 도면이 잘못된 것은 아니지만, 그 장비가 고장 나면 어떤 기능이 함께 멈추는지는 표시해야 합니다.
다음 작은 사무실의 통합 구성에서는 이 역할들이 한 장비 안에 모였을 때 무엇을 확인할지 봅니다. 이어 스위치와 AP를 분리한 사례에서 같은 이름을 다시 사용합니다. 역할을 먼저 구별해 두면 장비가 늘거나 줄어도 어느 기능을 다른 장비로 옮겼고 무엇을 그대로 두었는지 설명할 수 있습니다.
더 궁금한 점 ↑
L3 기능을 지원하는 스위치라면 Distribution 장비인가요?
아닙니다. L3 지원은 장비가 수행할 수 있는 기능이고 Distribution은 설계에서 맡긴 집계 역할입니다. L3 스위치를 단말의 게이트웨이를 맡는 Access에 사용할 수도 있으므로 연결 대상과 역할을 확인해야 합니다.
이 글의 용어 사전 ↑
이 글의 뜻과 영어 참고 표기는 전체 용어 사전에서 함께 볼 수 있습니다.
- Collapsed Corecollapsed core
- 집계 블록distribution block
- L2 AccessLayer 2 access
- Routed Accessrouted access
- Single-Tiersingle-tier design
- Two-Tiertwo-tier design
- PCPC
- 서버server
- EthernetEthernet
- MAC 주소MAC address
- VLANVLAN
- Network Accessnetwork access
- Core Networkcore network
- Distributiondistribution layer
- 단말endpoint
- 게이트웨이gateway
- IPIP
- LANLAN
- 패킷packet
- QoSquality of service
- L2Layer 2
- L3Layer 3
- 라우팅routing
- ACLACL
- 스위치switch
- 장비 포트device port
- APwireless access point
작성 범위와 참고 문서
기술 원리는 아래 공식 문서를 참고했습니다. 본문의 장비 배치와 주소는 설명을 위한 예시입니다. 실제 현장에서 측정한 결과나 제품의 보장 성능과는 구분해 주세요.
- Campus LAN and Wireless LAN Solution Design Guide — 캠퍼스 계층 역할과 설계 형태의 기본 근거. 계층을 나누는 원리를 참고했습니다. 현재 제품의 성능과 지원 조합은 해당 제품 문서에서 확인해야 합니다.
- Cloud Campus LAN Design Guide — 캠퍼스 역할과 배치 비교의 보조 근거. 본문의 사례에 특정 관리 제품이 반드시 필요한 것은 아닙니다.
- High Availability Campus Network Design — Routed Access Layer — 게이트웨이를 Access에 두는 L3 경계와 전통적 L2 Access의 구분. 장비 성능 수치는 인용하지 않았습니다.
- Campus Network for High Availability Design Guide — 캠퍼스의 장애 경로·복구·설계 검증을 설명할 때 참고했습니다.
- RFC 1812 — Requirements for IP Version 4 Routers — IPv4 라우터의 목적지 경로 선택·TTL 처리·다음 홉 전달 원리.
실제 망에 적용할 때는 사용하는 장비·소프트웨어의 지원 조건을 확인하고, 현장에서 필요한 동작을 시험해 보세요.