VLAN 설계 (브로드캐스트, Trunk 포트, VXLAN)

VLAN 설계의 목적

네트워크가 느리다는 민원을 받았을 때, 가장 먼저 의심해야 할 것은 서버도, 인터넷 회선도 아닐 수 있습니다. 저도 처음엔 그걸 몰랐습니다. 약 200명 규모의 회사 네트워크를 재설계하는 프로젝트에 투입됐을 때, 문제의 근원이 단 하나의 VLAN에 전 직원이 묶여 있다는 사실이었습니다. 회선 속도는 충분했고 서버도 정상이었습니다. 그런데 네트워크는 왜 이렇게 버벅거렸을까요? 그때부터 VLAN은 저에게 단순한 네트워크 기술이 아니라 실제 장애를 해결하는 도구가 되었습니다.

모두가 한 방에 있을 때 생기는 일, 브로드캐스트 도메인

당시 회사는 서버, 개발팀, 일반 직원이 구분 없이 하나의 네트워크에 연결되어 있었습니다. 처음 패킷 캡처를 떠봤을 때 솔직히 이건 예상 밖이었습니다. 화면 가득 ARP 브로드캐스트 패킷이 쏟아지고 있었으니까요. 업무 트래픽보다 브로드캐스트가 더 많은 수준이었습니다.

브로드캐스트 도메인이란, 브로드캐스트 패킷이 전달되는 범위를 의미합니다. 쉽게 말해 누군가 "이 IP 주소 가진 사람 손 들어!"라고 외치면 그 소리가 들리는 공간이 브로드캐스트 도메인입니다. 이 공간이 넓을수록 쓸데없는 외침이 많아지고, 모든 단말이 그 외침에 귀를 기울여야 하니 네트워크 전체 효율이 떨어집니다.

특히 개발팀이 대용량 빌드 작업을 돌리거나 특정 부서에서 트래픽이 몰리면, 그 영향이 서버팜까지 그대로 전파되는 구조였습니다. 한 명이 대용량 파일을 전송하면 옆 자리 사람의 화상 회의가 끊기는 식이었습니다. 이 문제를 해결하기 위해 고안된 기술이 VLAN(Virtual Local Area Network)입니다. 하나의 물리적 스위치를 여러 개의 논리적 네트워크로 쪼개는 방식으로, IEEE 802.1Q 표준에 따라 이더넷 프레임에 4바이트 태그를 붙여 각 VLAN을 구별하며 VLAN ID는 1부터 4094까지 사용할 수 있습니다.

VLAN 설계, 실제로 어떻게 나눴나

재설계 작업에서 저희가 나눈 VLAN 구조는 서버팜(VLAN 10), 개발팀(VLAN 20), 일반 직원(VLAN 30), 게스트 Wi-Fi(VLAN 40), 관리 네트워크(VLAN 99)였습니다. 번호 체계도 처음엔 아무렇게나 하려다가, 나중에 관리가 불편해질 것을 우려해 기능 단위로 묶어 정리했습니다.

이 구조에서 Access Port와 Trunk Port의 역할 구분이 핵심이었습니다. Access Port란 단말 하나가 연결되는 포트로, 태그 없이 단일 VLAN 트래픽만 처리합니다. 직원 PC나 서버가 꽂히는 포트가 여기에 해당합니다. 반면 Trunk Port는 여러 VLAN의 태그가 붙은 프레임을 동시에 주고받는 포트로, 스위치 간 또는 스위치와 라우터 사이를 연결할 때 씁니다.

분리 작업이 끝나고 나서 가장 눈에 띈 변화는 브로드캐스트 트래픽이 현저히 줄었다는 점이었습니다. 그리고 생각지도 못했던 보안 효과도 있었습니다. 일반 직원 PC에서 개발팀 서버로 직접 접근이 가능했던 구조가 VLAN 분리만으로 차단되었습니다. 논리적 경계 하나가 물리적 장벽 없이 보안 격리를 만들어 낸 셈입니다. 멀티테넌트 환경, 즉 한 인프라를 여러 조직이 나눠 쓰는 구조에서도 VLAN이 기본 격리 수단으로 쓰이는 이유가 바로 여기 있습니다. 장비를 새로 사지 않고 설정만으로 이런 효과가 났다는 게 당시엔 꽤 놀라웠습니다.

Trunk 포트 설정, 저도 한 번 크게 틀렸습니다

제가 직접 겪어보니 VLAN 설계에서 가장 사고가 잘 나는 지점은 Trunk 포트 설정이었습니다. 스위치와 라우터 사이 Trunk를 구성하면서 allowed VLAN 목록을 제대로 명시하지 않았더니, 특정 VLAN 트래픽이 조용히 사라지는 현상이 발생했습니다. 당시엔 원인을 찾느라 한참을 헤맸습니다. 트래픽이 완전히 차단된 게 아니라 일부만 안 되는 상황이라 더 찾기 어려웠습니다.

Trunk 포트는 기본적으로 모든 VLAN을 허용하는 방식으로 동작하기도 하지만, 장비나 설정에 따라 명시적으로 VLAN을 허용 목록에 넣어야 하는 경우가 있습니다. 이걸 놓치면 특정 VLAN 패킷이 Trunk를 통과하지 못하고 유실됩니다. 그 이후로 저는 Trunk 포트를 설정할 때 반드시 허용 VLAN을 명시적으로 선언하는 습관을 들였습니다. 기본값을 믿지 않는다는 원칙이 생긴 셈입니다.

더 주의해야 할 부분은 Native VLAN입니다. Native VLAN이란 Trunk 포트에서 태그 없이 전달되는 VLAN을 의미합니다. 이 값이 양쪽 장비에서 일치하지 않으면 VLAN Hopping 공격에 그대로 노출됩니다. VLAN Hopping이란 공격자가 태그를 조작해 원래 접근할 수 없는 VLAN으로 트래픽을 침투시키는 기법입니다. 실무에서 Native VLAN을 기본값인 VLAN 1로 방치하는 경우를 종종 보는데, 이건 보안 관점에서 꽤 위험한 설정입니다. VLAN 1은 많은 장비에서 기본 관리 트래픽이 흐르는 구간이기도 해서 더욱 그렇습니다. Cisco의 VLAN 보안 가이드에서도 Native VLAN을 사용하지 않는 전용 VLAN ID로 변경할 것을 권고하고 있습니다. 저는 이걸 설계 체크리스트의 첫 번째 항목으로 넣어두고 있습니다.

VLAN의 한계, 그리고 VXLAN이 등장한 이유

VLAN이 강력한 건 분명하지만, 설계가 복잡해질수록 관리 포인트도 기하급수적으로 늘어납니다. Inter-VLAN Routing이 그 대표적인 예입니다. Inter-VLAN Routing이란 서로 다른 VLAN에 속한 단말끼리 통신하기 위해 L3 스위치나 라우터를 거치도록 하는 방식입니다. 이 구성 자체는 어렵지 않지만, 라우팅 정책을 잘못 설정하면 VLAN 간 격리 효과가 무너지는 일이 생깁니다. 분리를 했는데 사실상 분리가 안 된 상황이 되는 거죠. 저도 이 실수를 한 번 했는데, ACL을 빠뜨리는 바람에 개발팀 VLAN에서 서버 VLAN으로 무제한 접근이 가능한 상태가 며칠간 유지됐습니다.

더 근본적인 한계도 있습니다. VLAN ID는 12비트 필드로 구성되어 있어 최대 4094개의 논리 네트워크만 지원합니다. 일반 기업 환경에서는 충분하지만, 수십만 개의 테넌트를 다루는 클라우드 데이터센터에서는 이 숫자가 금방 부족해집니다. 이 한계를 극복하기 위해 등장한 것이 VXLAN(Virtual Extensible LAN)입니다. VXLAN은 기존 이더넷 프레임을 UDP 패킷으로 캡슐화하는 오버레이 네트워크 기술로, 최대 약 1,600만 개의 논리 네트워크를 지원합니다. RFC 7348 표준으로 정의된 이 기술은 현재 대부분의 클라우드 인프라에서 네트워크 가상화의 기반으로 쓰이고 있습니다.

전통적인 VLAN 개념을 잘 이해하고 있어야 VXLAN 같은 오버레이 기술도 제대로 파악할 수 있습니다. 결국 확장된 개념이니까요. 클라우드 환경에서 일한다면 VLAN을 배우는 데 그치지 말고, 오버레이 네트워크 방향으로 시야를 넓혀 두는 것이 좋다고 생각합니다. 저도 온프레미스 환경만 다루다가 클라우드 환경을 접했을 때, VLAN의 기본 개념이 VXLAN을 이해하는 데 그대로 연결됐습니다.

VLAN은 제대로 설계하면 효율과 보안을 동시에 잡을 수 있는 기술입니다. 하지만 잘못된 Trunk 설정이나 Native VLAN 방치처럼 사소해 보이는 실수가 전체 설계를 흔들 수 있습니다. 처음 설계할 때 허용 VLAN 목록을 명시적으로 관리하고, Native VLAN을 전용 ID로 분리하는 것만 지켜도 나중에 겪을 수 있는 문제를 상당 부분 예방할 수 있습니다. 지금 네트워크 문제로 고민 중이라면 먼저 브로드캐스트 도메인이 어떻게 구성되어 있는지부터 확인해 보시길 권합니다.

---

출처 및 참고 경로

• Cisco 기술 백서: "Understanding and Configuring VLANs" - cisco.com
• IEEE 표준 위원회: "802.1Q - Bridges and Bridged Networks" - ieee.org
• NIST Special Publication 800-123: "Guide to General Server Security" - nist.gov