여러 건물을 연결할 때 Core는 언제 따로 둘까

건물이 몇 동인지보다 집계 블록을 어떻게 연결할지 살펴본다 ↑

집계 블록은 여러 Access와 그 위의 Distribution을 하나의 설계 단위로 묶어 보는 범위입니다. 건물 하나와 일치할 수도 있지만 항상 같지는 않습니다. 실제 서비스 경로와 정비 책임에 따라 한 건물 안에 여러 블록이 있거나 여러 작은 건물이 한 블록에 들어갈 수 있습니다.

앞선 Two-Tier 사례가 하나의 집계 블록이라면, 이번에는 블록 A와 블록 B가 각각 자체 Access·Distribution을 가진다고 가정합니다. 블록 A의 PC-A는 블록 B의 App-B에 접속해야 합니다. 같은 블록 내부에서 끝나는 통신과 블록 사이로 나가는 통신을 나누어 봅니다.

블록이 적고 연결 관계가 단순하면 Distribution 사이를 직접 연결하는 구성도 검토할 수 있습니다. 별도 Core가 없다는 사실만으로 설계가 잘못된 것은 아닙니다. 필요한 용량과 장애 대응, 정책, 확장 조건을 현재 연결로 만족하는지 확인하면 됩니다.

블록이 늘어나면서 연결과 변경의 조합이 복잡해지면, 블록 간 전달을 Core라는 별도 역할에 맡길 이유가 생깁니다. 각 Distribution은 계속 자신의 Access들을 모으고, Core는 Distribution 블록 사이로 패킷을 전달합니다. 이렇게 나누었을 때 연결이 얼마나 단순해지고 변경 범위가 줄어드는지 비교합니다.

블록마다 담당자가 다르다면 공통 전달을 누가 변경할 수 있는지도 정합니다. 장비의 계층만 나누고 변경 권한과 연락 체계를 나누지 않으면 공통 Core에서 작업이 충돌할 수 있습니다. 연결 구조를 나누는 일과 누가 어느 설정을 바꿀지 정하는 일은 함께 진행해야 합니다.

따라서 Core 도입의 근거는 건물 세 동이라는 식의 숫자가 아니라 연결 관계와 운영 요구입니다. 새 블록을 추가할 때 기존 블록을 얼마나 변경하는지, 공통 전달 경로를 독립적으로 정비할 필요가 있는지 기록합니다. 이 요구가 분명해야 Core를 추가해 해결할 문제와 여러 블록이 Core를 함께 사용하면서 생길 위험을 비교할 수 있습니다.

이번에는 앞선 접속·집계 구성을 블록 A와 블록 B에 각각 두고, 두 블록 사이의 전달을 Core에 맡기겠습니다. 점선 구역은 건물의 외벽이 아니라 설계와 정비를 함께 검토할 집계 블록입니다.

PC-A에서 다른 건물의 서버까지 역할을 따라간다 ↑

블록 A와 B 사이에 C1·C2라는 Core를 두고, 각 블록의 Distribution이 두 Core에 L3 경로를 갖도록 구성한다고 하겠습니다. 이 그림의 핵심은 장비를 세 층으로 쌓는 모양이 아니라, 블록 내부 전달과 블록 간 전달을 구별하는 데 있습니다.

PC-A의 주소는 10.60.10.21이고 목적지 App-B는 10.70.20.10입니다. 단말은 자신의 게이트웨이에 프레임을 보내고, 블록 A의 라우팅 경로를 따라 Distribution에 도달합니다. 그 Distribution은 블록 B의 목적지로 가는 경로를 선택해 Core 방향으로 전달합니다.

Core는 목적지에 맞는 블록 B 방향 경로로 패킷을 전달합니다. 블록 B의 Distribution과 접속 구간을 거쳐 App-B에 도착하면, 응답은 PC-A의 주소로 돌아갈 경로를 따라갑니다. 요청과 응답이 서로 다른 Core를 지날 수도 있으므로, 양방향 경로와 정책이 실제로 어떻게 설정돼 있는지 확인합니다.

같은 Access 스위치의 같은 VLAN에 있는 두 단말의 통신까지 Core로 올리지는 않습니다. Core가 필요한 경로와 필요하지 않은 경로를 구별하면 공통 전달 장비에 어떤 수요를 계산해야 하는지도 명확해집니다. 모든 단말 포트 속도의 합계를 그대로 Core의 실제 수요로 취급할 수 없는 이유입니다.

상태를 추적하는 보안 장비를 지난다면 양방향 흐름을 그 장비가 처리할 수 있는 조건도 도면에 표시합니다. 물리 경로가 달라도 상태 공유나 지원 방식에 따라 결과가 달라집니다. 비대칭 경로에서 통신이 되는지는 해당 보안 장비가 양방향 연결 상태를 처리하는 방식에 따라 확인해야 합니다.

Core를 단순한 전달 역할로 유지하려면 어느 위치에서 사용자 정책과 서비스 경계를 적용할지 정해야 합니다. 단순화는 필요한 보안 정책을 없애는 뜻이 아닙니다. 사용자 정책과 서비스 보호를 적용할 위치를 분명히 정하고, Core에서는 안정적인 블록 간 전달에 집중하도록 설계한다는 뜻입니다.

블록 A의 PC-A에서 블록 B의 App-B까지 요청을 따라갑니다. 선택한 경로와 대체 경로를 구분하고, 응답이 돌아올 경로는 따로 확인합니다.

주소 요약은 간결해지지만 실제 도달성을 숨길 수 있다 ↑

주소를 블록별로 계획하면 상위에 전달할 경로를 요약할 수 있습니다. 이 사례에서는 블록 A에 10.60.0.0/16, 블록 B에 10.70.0.0/16을 배정한 것으로 가정합니다. 이 범위는 계획상의 묶음이며, 그 안의 모든 서브넷이 실제로 존재한다는 뜻은 아닙니다.

블록 A가 Core에 10.60.0.0/16을 알리면 Core는 그 범위의 목적지를 블록 A로 보낼 수 있습니다. 하지만 블록 A 안에서 실제 목적지 서브넷으로 가는 경로가 사라졌다면 요약 경로만으로 전달을 완성할 수 없습니다. 상위 경로의 존재와 하위 서비스의 도달성은 다른 확인 항목입니다.

예를 들어 10.60.10.0/24 경로가 끊겨도 다른 서브넷 때문에 /16 요약이 계속 남을 수 있습니다. Core에서 요약이 정상으로 보이는 동안 PC-A 쪽 통신은 실패할 수 있습니다. 장애 분석에서는 목적지의 더 구체적인 경로와 실제 전달 위치까지 내려가 보아야 합니다.

요약한 범위에 실제 경로가 없는 주소가 들어왔을 때의 처리도 정합니다. 설계에 따라 요약 지점의 폐기 경로 등으로 순환 전달을 막을 수 있지만, 적용 방식과 우선순위는 사용한 라우팅 기능에서 검증해야 합니다. 폐기 경로는 잘못 들어온 패킷의 처리를 정할 뿐 사라진 하위 서비스를 복구하지 않습니다.

블록 간 주소가 겹치거나 일부 주소를 다른 블록으로 옮기면 요약의 전제가 달라집니다. 새 주소를 할당할 때는 남은 범위만 보지 말고 그 주소로 향하는 패킷을 어느 블록에서 받아 전달할지 확인합니다. 주소를 배정한 블록과 라우팅 경로가 일치해야 요약 경로만 보고도 패킷을 어디로 보낼지 쉽게 알 수 있습니다.

Core에 요약 경로가 남아 있어도 블록 안의 특정 서브넷 경로는 사라질 수 있습니다. 상위의 요약과 하위의 실제 경로를 함께 확인해야 하는 사례입니다.

Core 한 대와 집계 블록 하나의 고장을 구별한다 ↑

C1이 고장 나면 C2를 통해 블록 간 통신을 이어가도록 구성합니다. 이때 양쪽 블록에서 서로의 목적지로 향하는 경로가 C2를 거쳐야 하며, C2와 연결된 링크에도 트래픽을 처리할 용량이 남아 있어야 합니다. 케이블이 연결돼 있는지만 확인해서는 부족합니다.

PC-A에서 App-B로 향하는 경로를 C2만 남긴 도면에서 다시 따라갑니다. 블록 A의 Distribution이 C2로 전달할 수 있는지, C2가 블록 B로 전달할 수 있는지 확인합니다. 이어 App-B에서 PC-A로 돌아오는 경로를 별도로 따라가며 방향별 정책과 상태 추적 장비의 조건을 확인합니다.

C1에서 처리하던 수요가 C2로 이동하면 연결별 부하도 달라집니다. 정상 상태의 평균 사용률이 낮더라도 특정 블록의 연결에 수요가 집중될 수 있습니다. Core 장비 전체 처리량과 개별 포트·대기열의 한계를 같은 것으로 취급하지 않아야 합니다.

반면 블록 A의 두 Distribution이 함께 접근 불가능해지면 C1·C2가 모두 정상이어도 그 블록의 외부 통신은 사라질 수 있습니다. 공통 전원이나 회선 경로로 두 Distribution이 함께 멈추는 경우가 대표적입니다. Core 이중화가 하위 블록의 모든 고장까지 보호하는 것은 아닙니다.

이 차이는 장애 보고에도 반영합니다. 전체 Core의 문제인지 특정 블록의 문제인지, 블록 내부 통신은 가능한지 외부 통신만 실패하는지 구분합니다. 설계 때 블록별 역할과 장애 범위를 나누어 두었다면, 장애 보고에서도 같은 블록 이름을 사용해 어디까지 영향을 받았는지 전달합니다.

계층을 나눈 이익은 변경과 정비에서도 확인한다 ↑

Core를 분리하면 평소 패킷을 전달하는 구조뿐 아니라 장비별 변경·정비 범위도 정리할 수 있습니다. 새 Access를 추가하는 작업, 한 집계 블록을 정비하는 작업, 공통 전달 장비를 교체하는 작업의 범위가 어떻게 달라지는지 설명할 수 있어야 합니다.

블록 A에 새 업무 서브넷을 추가할 때 블록 B의 접속 설정까지 바꾸어야 하는지 살펴봅니다. 주소 계획과 요약이 적절하면 일부 변경을 블록 안에 가둘 수 있습니다. 다만 보안 정책이나 공통 서비스의 허용 목록은 별도 변경이 필요할 수 있으므로 모든 변경이 해당 블록 안에서 끝나는 것은 아닙니다.

C1을 정비하는 동안 C2만으로 요구 서비스를 감당할 수 있는지는 사전에 확인합니다. C2만으로도 단말의 통신 경로와 필요한 상향 용량을 확보할 수 있어야 합니다. 관리 접속과 정책도 정상적으로 동작해야 합니다. 단순히 라우팅 이웃이 연결되었다는 사실보다 실제 업무 요청과 응답이 기준이 되어야 합니다.

새 블록을 추가하면 Core의 포트와 회선 수뿐 아니라 경로 수, 정책 영향, 장애 시험 항목도 늘어납니다. 따라서 빈 포트가 있다는 이유만으로 증설이 가능하다고 판단하지 않습니다. 어떤 추가 조건에서 현재 설계를 재검토할지 문서에 남겨야 성장 과정에서도 같은 기준으로 판단할 수 있습니다.

정비 중 사용할 관리 접속이 정비 대상 Core를 지나가는지도 확인합니다. 업무 우회는 준비했는데 관리 경로가 함께 끊어지면 원복이 늦어질 수 있습니다. 작업자의 접속 위치에서 대상 장비까지 별도로 경로를 따라가며 신뢰할 수 있는 대체 접근 수단을 검증해야 합니다.

도면에 대체 경로가 있다면 실제 장애 때 그 경로로 업무를 이어 갈 수 있는지도 시험해야 합니다. 설계 검증에서는 시험할 장애와 서비스, 중단 허용 시간과 되돌릴 조건을 정리합니다. 사내망의 구성을 살펴본 데 이어, 다음 부에서는 이 망을 지사·클라우드·인터넷과 연결할 때 필요한 회선·주소·경로 정책을 다룹니다.