Cisco는 네트워크 구조를 어떤 기준으로 나누어 설계할까

같은 크기의 사무실도 왜 다른 설계가 필요할까 ↑

공유기에서 기업망으로 확장하는 글에서는 공유기에 모인 기능을 나누면서, 한 장비가 고장 났을 때 어느 업무까지 멈추는지 살펴보았습니다. Cisco의 참조 설계도 업무의 요구와 적용 조건을 함께 읽어야 우리 망에 맞는 구조를 고를 수 있습니다.

교육용으로 두 사무실을 비교해 보겠습니다. 사무실 A는 문서 작업이 중심이고 회선 장애 때 승인된 대체 접속으로 업무를 이어 갈 수 있습니다. 사무실 B는 내부 업무 서버에 계속 접속해야 하며, 서버와 통신이 끊기면 현장의 작업이 함께 멈춥니다. 인원수가 같다는 정보만으로 이 차이를 알 수는 없습니다.

A에서는 예비 장비를 보관하고 설정을 복원하는 시간이 업무의 허용 범위 안에 들어가는지 확인할 수 있습니다. B에서는 장비를 교체하는 동안 업무를 멈추기 어려울 수 있습니다. 이때 대체 경로, 장비 전환, 전원과 관리 접속을 설계 대상으로 추가합니다. 이처럼 업무가 얼마나 오래 중단돼도 되는지 알아야 장비 이중화가 필요한지 판단할 수 있습니다.

“중단 없이 운영해야 한다”는 요구도 구체적으로 확인해야 합니다. 새 연결을 잠시 만들지 못하는 것과 이미 진행 중인 거래가 사라지는 것은 다른 실패입니다. 설계자는 업무 담당자에게 어떤 업무가 얼마나 오래 멈춰도 되는지 묻고, 네트워크가 담당할 부분과 애플리케이션이 담당할 부분을 나눕니다.

사무실의 크기보다 업무에 필요한 기능을 기준으로 사례를 비교해 보겠습니다. 작은 현장에도 이중화가 필요할 수 있고, 넓은 현장에도 단순한 구조가 적합할 수 있습니다. 우리 현장에 필요한 조건을 먼저 정하면 참조 도면 가운데 어떤 구성을 살펴봐야 할지 고르기 쉽습니다.

같은 인원의 두 사무실을 비교해 보겠습니다. 업무가 중단돼도 기다릴 수 있는 시간이 다르면 예비 장비와 상시 대체 경로 중 필요한 구성도 달라집니다.

Cisco의 설계에서 캠퍼스·WAN·데이터센터는 무엇을 나누는 이름일까 ↑

먼저 어느 영역의 네트워크를 설계하는지 구분합니다. 사무실에서 사용자를 연결하는 망, 떨어진 사업장을 잇는 망, 서버와 애플리케이션을 연결하는 망은 서로 이어지지만 같은 문제를 다루지는 않습니다.

여기서 다루는 캠퍼스 LAN은 사무실이나 사옥 안에서 직원의 PC·전화·무선 단말을 업무 서비스에 연결하는 망입니다. 캠퍼스라는 말이 대학이나 넓은 부지만을 뜻하지는 않습니다. 작은 사무실부터 여러 건물로 이루어진 사옥까지 포함하며, 현장의 규모와 업무에 따라 필요한 구성이 달라집니다.

WAN은 서로 떨어진 사업장이나 서비스가 있는 곳을 연결합니다. 지점 사용자가 본사 서버에 접속한다면 지점의 접속망, 사업장 사이의 연결, 본사 서비스 구간을 모두 지나갈 수 있습니다. 이때 인터넷 경계의 라우터와 캠퍼스의 Core는 맡는 일이 다르므로 구분해서 표시합니다.

데이터센터는 애플리케이션과 서버 사이의 연결·정책·가용성을 따로 다룹니다. 데이터센터의 Spine-Leaf와 캠퍼스의 Core는 설계 목적과 연결 방식이 다르므로 같은 구조로 취급하면 안 됩니다. 기업망의 기능 배치 도해는 전체를 이해하는 출발점이며, 실제 구조는 해당 영역의 공식 가이드로 다시 구별해야 합니다.

예를 들어 PC-A에서 App-S로 가는 선 하나를 그린 뒤 접속망과 외부 서비스 구간을 나누어 표시합니다. 요청에 필요한 인증이나 보안은 이 경계를 가로질러 작동할 수 있습니다. 각 구간에서 어떤 기능을 설계하고 어디에서 서로 연결하는지 적으면, 같은 Cisco 문서에 나오는 구성도 용도에 맞게 구별할 수 있습니다.

PC-A에서 App-S로 가는 경로를 따라 캠퍼스·WAN·데이터센터가 맡는 구간을 나누어 보겠습니다. 인증과 정책은 이 구간들을 가로질러 적용할 수 있습니다.

한 계층·두 계층·세 계층은 장비 수가 아니라 역할의 배치를 말한다 ↑

캠퍼스 설계의 계층 수는 접속·집계·블록 간 전달 역할을 어떻게 배치했는지 설명합니다. 스위치와 AP, 방화벽의 개수를 더한 값도 아니고 OSI의 L2·L3를 세는 값도 아닙니다.

Single-Tier는 전용 집계 계층 없이 하나의 접속 계층으로 현장의 LAN을 구성하는 방식입니다. 스위치 스택처럼 물리 장비가 여러 대여도 논리적 접속 역할은 하나의 계층일 수 있습니다. 반면 SOHO는 소규모 사무실이라는 이용 환경을 가리킵니다. 공유기 한 대를 쓰는 사례를 설명할 수는 있지만, Cisco의 공식적인 0계층 설계를 뜻하는 말은 아닙니다.

여러 Access 묶음을 Distribution이 집계하고 별도 Core를 두지 않으면 Two-Tier로 설명할 수 있습니다. 상위에서 집계와 중심 전달 역할을 함께 맡는 구성을 Collapsed Core라고 부릅니다. 그 상위 역할을 두 장비가 함께 맡아도 계층이 하나 추가되는 것은 아닙니다.

여러 집계 블록 사이의 전달을 Core로 분리하면 Three-Tier가 됩니다. 그러나 건물 수가 늘 때마다 자동으로 거치는 단계는 아닙니다. 트래픽이 어디로 모이는지, 장비 고장이나 정비 때 어느 구역까지 멈춰도 되는지 비교합니다. 여기에 분리한 장비를 관리할 여건까지 고려해 Core가 필요한지 판단합니다.

L2 Access와 Routed Access는 이 구조 안에서 VLAN을 어디까지 잇고 어디에서 라우팅할지 정하는 별도의 설계 기준입니다. Two-Tier에서도 L2 상향 또는 L3 상향을 선택할 수 있습니다. 따라서 계층도 옆에는 게이트웨이·VLAN 경계·라우팅 링크를 따로 표시합니다. 세 개의 상자만으로는 패킷이 누구의 MAC 주소로 전달되는지 알 수 없습니다.

위쪽에서는 접속·집계·블록 간 전달을 몇 계층으로 나누는지 비교합니다. 아래쪽에서는 그 계층 안에서 VLAN을 어디까지 잇고 라우팅을 어디에서 시작하는지 따로 봅니다.

업무에 필요한 통신과 허용할 중단 시간을 구체적으로 적는다 ↑

요구사항은 누가 무엇과 통신해야 하는지, 어떤 실패를 허용하는지로 적어야 설계에 사용할 수 있습니다. “빠르고 안정적인 망”이라는 표현만으로는 포트나 경로를 고를 수 없습니다.

업무 단말 PC-A에서 업무 서버 App-S의 HTTPS 서비스를 사용하는 상황을 예로 들어 보겠습니다. 요청 방향만 그리지 않고 이름 해석, 인증, 응답 방향까지 확인합니다. 사용자가 버튼 하나를 눌렀을 때 여러 서비스가 차례로 동작한다면, 어느 서비스가 먼저 정상이어야 하는지도 요구사항에 적어 둡니다.

필요한 용량은 회선에 적힌 속도만 보고 정하지 않습니다. 어떤 시간대에 얼마나 많은 단말이 동시에 데이터를 보내는지, 파일 전송과 짧은 거래 요청이 어떻게 겹치는지 조사합니다. 관측하지 못한 값은 측정값처럼 쓰지 않고 가정으로 표시합니다. 설계안에는 그 가정을 확인할 방법과 담당자를 남깁니다.

장애 조건은 “장비 하나가 고장 난다”보다 구체적이어야 합니다. 업링크 한 가닥이 끊기거나 스위치 한 대, 전원 회로 하나가 멈췄을 때 영향을 받는 단말과 남는 용량을 적습니다. 같은 두 장비라도 한 전원 회로에 붙어 있다면 회로 장애로 두 장비가 함께 멈추는 경우도 검토해야 합니다.

업무 담당자는 원하는 결과를 정하고, 설계자는 그 결과에 필요한 통신 조건을 확인합니다. 예를 들어 서버가 요청을 처리하지 못한 문제를 회선 증속만으로 해결할 수는 없습니다. 업무 목표를 정한 뒤에는 네트워크에서 해결할 부분과 서버·애플리케이션에서 해결할 부분을 나누어 설계서에 적습니다.

보안과 관리 요구도 통신 조건입니다. 방문자 단말이 업무 서버에 도달하지 못해야 한다면 차단 지점과 확인 방법을 정합니다. 업무망 장애 중에도 관리자가 장비에 접속해야 한다면 별도 관리 경로가 필요한지 판단합니다. 요구사항마다 무엇을 시험할지 정해 두면 설계의 빠진 부분을 찾기 쉬워집니다.

업무 요구를 아래처럼 연결 그림으로 옮겨 보겠습니다. PC-A와 App-S 사이의 왕복 경로에 이름 해석·인증과 관리 접속을 함께 표시하면, 장비 배치만 그렸을 때 빠지기 쉬운 의존성을 찾을 수 있습니다.

Cisco의 검증된 설계에서도 적용 조건을 먼저 읽는다 ↑

Cisco Validated 문서를 참고할 때는 어떤 용도와 구성에서 검증했는지 먼저 읽습니다. 우리 망에도 적용하려면 장비·소프트웨어·업무 조건이 그 구성과 맞는지 확인해야 합니다.

문서를 열면 대상 업무, 토폴로지, 하드웨어와 소프트웨어 조합, 검증한 기능의 범위를 구분해 읽습니다. 기능이 지원된다는 설명과 특정 조합에서 시험한 결과도 같은 근거가 아닙니다. 우리 장비나 소프트웨어가 다르면 어떤 가정이 더는 성립하지 않는지 따로 남깁니다.

캠퍼스 LAN의 역할 구분은 오래된 문서에서도 배울 수 있습니다. 다만 이 글에서 참조하는 2020년 Campus LAN 가이드의 제품 목록과 성능 수치를 현재 구매 기준으로 복사하지는 않습니다. 계층을 나누는 이유와 당시 구현을 분리해서 읽고, 실제 장비 선정 때는 해당 제품의 현재 문서로 다시 확인합니다.

참조 구성이 우리 요구보다 크면 모든 장비를 따라 둘 이유가 없고, 작으면 필요한 기능을 빼서는 안 됩니다. 예를 들어 접속 구간만으로 충분한 현장에 별도 Core를 두려면 전달 용량이나 변경 범위처럼 추가 역할이 있어야 합니다. 반대로 그 역할이 필요하다면 사용자 수가 적어도 분리를 검토합니다.

참조 문서의 발행 시점도 설계 기록에 남깁니다. 오래된 문서에서 역할을 나누는 원리는 참고할 수 있어도 당시의 장비 한계와 소프트웨어 지원을 현재 조건으로 옮길 수는 없습니다. 원리의 근거와 실제 제품 조합의 지원 확인을 서로 다른 작업으로 구별합니다.

공식 문서에서 확인한 내용과 이 글에서 설명을 위해 만든 사례는 구분해서 표시합니다. Cisco가 권하는 역할 구분을 참고했다는 사실이 저자의 사례를 Cisco가 검증했다는 뜻은 아닙니다. 적용한 권고, 달라진 조건, 자체 시험할 항목을 함께 기록하면 나중에도 그 구성을 선택한 이유를 확인할 수 있습니다.

요구사항 한 줄을 설계도와 시험 항목까지 연결한다 ↑

설계 결정은 요구사항에서 도면으로, 도면에서 확인 방법으로 이어져야 합니다. 이 연결이 있으면 장비를 바꾸더라도 무엇을 지켜야 하는지 다시 판단할 수 있습니다.

요구사항 R-01을 “업링크 하나가 끊겨도 PC-A가 App-S의 시험 거래를 허용 시간 안에 마친다”로 정해 보겠습니다. 전체 구성을 설명하는 HLD에는 두 경로와 장애의 영향 범위를 그립니다. 포트 번호를 아직 정하지 않았더라도, 어느 링크가 끊겼을 때 어떤 경로로 통신을 이어 갈지는 보여야 합니다.

상세 설계인 LLD에서는 두 경로를 실제 포트, 주소, VLAN, 라우팅과 정책에 대응시킵니다. 경로가 두 줄이라는 그림만으로는 VLAN이 어디까지 이어지는지, 게이트웨이가 어디인지 알 수 없습니다. 정상 상태와 장애 상태에 적용될 값까지 적어야 구축 담당자가 같은 의도를 구현할 수 있습니다.

시험 T-01은 R-01을 다시 읽어 만듭니다. 어떤 링크를 어떤 조건에서 중단할지, 어디에서 패킷을 확인하고 어떤 업무로 복구 여부를 판단할지, 허용 시간을 넘으면 어떻게 되돌릴지를 적습니다. 이 시간은 제품의 광고 수치를 그대로 가져오지 않고 업무 요구와 시험 방식으로 합의한 값이어야 합니다.

검토한 대안을 버린 이유도 짧게 남깁니다. 상시 이중화 대신 예비 장비 교체를 택했다면 비용뿐 아니라 허용 중단 시간과 실제 복원 가능성을 근거로 적습니다. 이후 업무가 바뀌면 어느 전제가 깨졌는지 찾아 같은 결정을 다시 검토할 수 있습니다.

요구사항·도면·설정·시험에 같은 식별자를 붙이면 시험하지 못한 부분도 찾기 쉽습니다. 업링크를 끊어 본 것만으로 전원 장애나 방화벽의 세션 전환까지 확인한 것은 아닙니다. 시험한 장애와 아직 시험하지 못한 장애를 나누어 적어 두어야 운영자가 복구 가능한 범위를 판단할 수 있습니다.

요구사항 R-01이 도면과 설정을 거쳐 시험 T-01로 이어지는 과정을 정리했습니다. 운영 중 조건이 달라지면 같은 요구사항으로 돌아가 설계와 시험을 함께 다시 검토합니다.

설계 때 정한 조건을 운영에서도 다시 확인한다 ↑

구축을 마친 뒤에도 설계 문서를 운영의 기준으로 사용합니다. 운영 중 관찰한 값이 처음의 가정과 달라졌다면 장비부터 증설하기 전에 어떤 요구가 바뀌었는지 확인합니다.

PC-A의 업무가 단순 조회에서 대용량 업로드로 바뀌면 같은 단말 수라도 업링크 수요가 달라집니다. 사용률의 평균만 기록했다면 짧은 혼잡을 놓칠 수도 있습니다. 설계 때 가정한 동시 사용과 실제 시간대별 관찰을 비교하면 용량 문제인지 다른 원인인지 조사할 출발점이 생깁니다.

새 방문자 무선망이나 원격 접속도 기존 도면에 반영합니다. 새 연결이 업무망의 보안 경계를 우회하지 않는지, 관리 접속이 공통 장애 원인에 다시 묶이지 않는지 봅니다. 연결을 추가한 뒤에도 도면과 담당자 목록을 고치지 않으면, 장애 때 운영자가 이미 바뀐 경로와 정책을 잘못 파악할 수 있습니다.

앞으로 다룰 사례도 작은 장비를 큰 장비로 바꾸는 순서로 읽기보다는, 우리 현장에서 필요한 부분을 골라 적용하면 됩니다. 뒤의 사례를 읽고 작은 현장에 대체 경로만 추가할 수도 있고, 복잡한 현장에서 불필요한 VLAN 확장을 줄일 수도 있습니다. 어떤 기능을 분리하려는지, 용량은 충분한지, 고장 때 어디까지 멈추는지를 기준으로 도면을 검토합니다.

운영 중에 확인한 문제는 처음 정한 요구사항과 비교해 설계에 반영합니다. 예상보다 복원에 오래 걸렸다면 장비 선택뿐 아니라 예비품 위치와 관리 접근도 재검토합니다. 어떤 고장이었고 어느 단계가 오래 걸렸는지 구분해야 다음 설계 변경이 실제 문제를 줄일 수 있습니다.

이제 Access·Distribution·Core의 역할을 실제 통신 경로에서 살펴봅니다. 작은 사무실의 구성부터 주소 계획·용량·장애 범위·L2/L3 경계를 차례로 검토하고, 여러 통신실과 건물을 연결하는 계층과 이중화로 이어집니다. 사내 설계를 살핀 뒤에는 지사·클라우드·인터넷 연결을, 마지막 부에서는 보안·검증·장애 복구를 다룹니다.