들어가며 — 평평한 네트워크의 유혹
새 사무실에 처음 네트워크를 깔 때, 가장 쉬운 방법은 모든 것을 하나로 잇는 것입니다. 인터넷 회선을 공유기에 꽂고, 스위치를 몇 대 물리고, 직원 PC와 서버와 프린터와 전화기를 전부 같은 망에 연결합니다. 케이블만 꽂으면 서로 통신이 되니 편합니다. 열 명 남짓한 작은 사무실이라면 이것으로 충분하고, 굳이 복잡하게 나눌 이유도 없습니다.
문제는 회사가 자라면서 시작됩니다. 직원이 늘고, 개발 서버가 생기고, 운영 서비스가 올라가고, IP 전화가 들어오고, 관리해야 할 네트워크 장비가 쌓입니다. 그런데 이 모든 것이 여전히 하나의 평평한 네트워크 위에 있다면, 겉으로는 잘 돌아가는 것처럼 보여도 그 안에는 조용히 위험이 쌓입니다.
같은 망에 있다는 것은 서로를 볼 수 있다는 뜻입니다. 직원의 노트북이 운영 데이터베이스 서버에 접근할 수 있고, 손님용 와이파이에 접속한 낯선 기기가 사내 파일 서버와 같은 네트워크에 놓이며, 누군가의 PC가 악성코드에 감염되면 그 코드가 같은 망의 모든 장비로 번질 수 있습니다. 평평한 네트워크에서는 한 곳의 사고가 전체의 사고가 됩니다.
우리는 고객의 사내망을 설계할 때 이 평평함을 거부합니다. 대신 하나의 사무실을 여러 개의 논리적인 세계로 나눕니다. 이 글은 우리가 왜, 그리고 어떻게 사내 네트워크를 나누는가에 대한 이야기입니다. 실제로 우리가 60~70명 규모의 회사 네트워크를 구축하며 사무실 하나를 아홉 개의 망으로 갈랐던 경험을 바탕으로 풀어보겠습니다.
📋 프로젝트 관리의 시선으로
망을 나누는 일은 케이블링이 아니라 “신뢰의 경계를 어디에 그을 것인가”라는 의사결정입니다. 이것은 프로젝트에서 역할과 권한을 나누고, 리스크를 격리하고, 변경을 통제하는 일과 정확히 같은 사고방식입니다. 이 글은 파티션 설계·리눅스 선택 이야기와 같은 믿음 위에 서 있습니다 — 좋은 인프라란 사고를 잘 수습하는 것이 아니라, 사고가 사고로 번지지 않게 경계를 미리 긋는 것.
신뢰의 경계 — 왜 나누는가
네트워크를 나누는 일의 본질은 신뢰의 경계를 긋는 것입니다. 사무실 안의 모든 장비가 서로 같은 수준으로 신뢰받아야 하는 것은 아닙니다. 운영 서버는 엄격하게 보호받아야 하고, 직원 PC는 자유롭게 인터넷을 써야 하며, 손님 기기는 최소한만 허용되어야 합니다. 이들을 같은 망에 두는 것은, 성격이 전혀 다른 공간을 벽 없이 한 방에 몰아넣는 것과 같습니다.
경계를 나눴을 때 얻는 것은 크게 세 가지입니다.
첫째는 보안 격리입니다. 망을 나누면 한 영역의 사고가 다른 영역으로 번지지 않습니다. 직원망의 PC가 감염되어도 그 악성코드는 직원망 안에 갇히고, 운영 서버망으로 넘어가지 못합니다. 이것은 앞서 우리가 서버의 디스크를 나누고 시스템의 역할을 나눌 때 지켰던 것과 똑같은 원칙입니다. 사고가 사고로 번지지 못하게 미리 벽을 세워두는 것, 그것이 좋은 설계의 핵심입니다.
둘째는 트래픽의 정리입니다. 하나의 큰 네트워크에서는 모든 장비가 서로에게 끊임없이 신호를 보냅니다. 특히 브로드캐스트라 불리는, 망 전체에 대고 외치는 신호는 장비가 많아질수록 기하급수적으로 늘어나 네트워크를 느리게 만듭니다. 망을 나누면 이 소음이 각 영역 안에 갇혀, 전체가 조용하고 빨라집니다.
셋째는 정책의 명확함입니다. 망이 나뉘어 있으면 “누가 어디에 접근할 수 있는가”를 경계 단위로 깔끔하게 정의할 수 있습니다. “개발망은 운영 서버에 접근할 수 없다”, “전화기는 서버에 붙을 수 없다” 같은 규칙을, 장비 하나하나가 아니라 망 대 망으로 관리할 수 있게 됩니다.
[ 평평한 네트워크 vs 나뉜 네트워크 ]
평평한 네트워크
┌─────────────────────────────────────┐
│ 직원PC 운영서버 개발 전화 손님기기 │
│ └───────┴──────┴─────┴─────┘ │
│ 모두가 서로에게 접근 가능 │
│ 한 곳 감염 → 전체 확산 │
└─────────────────────────────────────┘
나뉜 네트워크
┌────────┐ ┌────────┐ ┌────────┐ ┌────────┐
│ 직원망 │ │ 운영망 │ │ 개발망 │ │ 전화망 │
└────────┘ └────────┘ └────────┘ └────────┘
│ │ │ │
└──────────┴────┬─────┴──────────┘
경계에서 통제
(허용된 통신만 넘나듦)📋 프로젝트 관리 관점 — 신뢰는 등급으로 관리한다
“모든 장비가 같은 수준으로 신뢰받을 필요는 없다”는 문장은, 프로젝트의 이해관계자·권한 관리와 그대로 겹칩니다. 모두에게 모든 접근을 열어주는 조직은 편하지만, 사고의 원인 추적도 책임 소재도 흐려집니다. 자산의 민감도에 따라 신뢰 등급을 나누고(운영·직원·손님), 경계에서 접근을 통제하는 것 — 그것이 리스크 격리이자 거버넌스입니다. 한 곳의 사고가 각주로 끝나느냐 전면 장애가 되느냐는, 경계를 미리 그었는가에서 갈립니다.
나누는 방법 — VLAN이라는 도구
그렇다면 어떻게 나눌까요? 가장 단순한 방법은 물리적으로 분리하는 것입니다. 망마다 별도의 스위치를 두고, 별도의 케이블을 깔면 됩니다. 하지만 이 방식은 금세 한계에 부딪힙니다. 망이 다섯 개, 아홉 개로 늘어나면 스위치도 그만큼 필요하고, 케이블은 거미줄처럼 얽히며, 방화벽 장비에는 그 많은 망을 받을 물리 포트가 모자랍니다. 배선실은 순식간에 지옥이 됩니다.
그래서 우리는 VLAN(Virtual LAN, 가상 랜)을 씁니다. VLAN은 하나의 물리적인 네트워크 장비를 여러 개의 논리적인 네트워크로 나누는 기술입니다. 물리적으로는 같은 스위치, 같은 케이블을 쓰지만, 각 데이터에 “이건 어느 망 소속”이라는 꼬리표(태그)를 붙여서 논리적으로 완전히 분리합니다.
핵심 개념은 태그(tag)와 트렁크(trunk)입니다. 각 데이터 조각에 VLAN 번호라는 꼬리표를 붙이면, 물리적으로 같은 선을 타고 흐르더라도 스위치와 방화벽은 그 꼬리표를 보고 어느 망 소속인지 구분합니다. 그리고 여러 VLAN의 태그된 트래픽을 한 가닥의 케이블에 몰아서 실어 보내는 통로를 트렁크라고 부릅니다. 트렁크 덕분에 우리는 케이블 한 줄로 아홉 개의 망을 방화벽까지 올려보낼 수 있습니다.
[ VLAN 트렁크의 원리 ]
물리 케이블 한 가닥 (트렁크)
════════════════════════════════════▶ 방화벽(라우터)
│ 꼬리표를 단 데이터들이 함께 흐른다
│
├─ [태그:110] 운영 서버 트래픽
├─ [태그:410] 직원 PC 트래픽
├─ [태그:510] 전화 트래픽
└─ [태그:910] 관리 트래픽
↓
방화벽이 꼬리표를 보고
각각을 다른 망으로 분류·통제이 구조의 우아함은, 물리적 단순함과 논리적 분리를 동시에 얻는다는 데 있습니다. 케이블은 한 가닥이지만 망은 아홉 개입니다. 배선은 깔끔하지만 격리는 철저합니다. 우리가 실제로 이 VLAN을 방화벽 장비 위에서 어떻게 만들고 각 망에 게이트웨이를 부여하는지는, 실전 구축 기록에 화면 단위로 정리되어 있습니다.
📎 실전 구축 편
이 글이 “왜 나누는가(Why)”를 다룬다면, 실제 OPNsense 방화벽에서 물리 포트 하나에 VLAN 여섯 개를 트렁크로 올리고 각 망에 게이트웨이를 부여하는 과정은 화면 단위로 이 편에서 볼 수 있습니다.
→ 중소기업 네트워크 구축 – 02. OPNsense 초기 설정: Interface/VLAN
어떻게 가를 것인가 — 역할로 나누는 설계
VLAN이라는 도구를 손에 쥐었으니, 이제 진짜 중요한 질문이 남습니다. 무엇을 기준으로 나눌 것인가? 여기서 설계자의 판단이 드러납니다. 우리는 망을 역할(role) 기준으로 나눕니다. 부서가 아니라, 그 장비가 하는 일과 요구되는 보안 수준으로 가릅니다. 같은 개발팀 안에도 개발 서버와 직원 PC는 성격이 다르고, 이 둘은 다른 망에 있어야 하기 때문입니다.
실제 구축에서 우리가 하나의 사무실을 가른 아홉 개의 망은 다음과 같은 역할들이었습니다. 운영 서비스가 도는 서버망, 배포 전 검증을 하는 스테이징 서버망, 개발 작업을 하는 개발망, 직원들이 일하는 업무망, IP 전화가 도는 음성망, 그리고 네트워크 장비 자체를 관리하는 관리망. 여기에 데이터센터 쪽 망까지 더해 아홉이 되었습니다.
각 망을 나눈 이유를 몇 가지만 짚어보겠습니다.
- 운영 서버망을 따로 두는 이유. 실제 고객 서비스가 도는 서버는 회사에서 가장 보호받아야 할 자산입니다. 여기에는 직원 PC도, 개발 장비도 함부로 접근해서는 안 됩니다. 그래서 운영 서버망은 가장 엄격한 경계로 둘러싸고, 오직 관리망과 꼭 필요한 통신만 허용합니다.
- 개발망과 운영망을 분리하는 이유. 개발은 본질적으로 불안정합니다. 새 코드를 시험하고, 설정을 바꾸고, 때로는 의도적으로 무언가를 망가뜨려 봅니다. 이런 실험적인 활동이 운영 서버와 같은 망에서 이뤄진다면, 개발 중의 실수 하나가 실제 서비스를 건드릴 수 있습니다. 둘을 나눠두면 개발망에서 무슨 일이 벌어져도 운영은 안전합니다.
- 관리망을 따로 두는 이유. 스위치, 방화벽, 무선 장비 같은 네트워크 인프라 자체를 제어하는 관리망은 가장 민감한 영역입니다. 이 망을 장악하면 네트워크 전체를 장악할 수 있기 때문입니다. 그래서 관리망은 별도로 격리하고, 외부에서의 직접 접근을 철저히 막으며, 오직 인증된 경로로만 들어올 수 있게 합니다.
- 전화망을 따로 두는 이유. IP 전화는 실시간 음성이라 트래픽 성격이 데이터와 전혀 다릅니다. 통화 품질을 지키려면 전화 트래픽을 별도 망에 두고 우선순위를 관리하는 것이 유리합니다. 동시에, 전화기가 서버에 접근할 이유는 전혀 없으니 보안상으로도 분리가 마땅합니다.
이 아홉 개 망의 전체 설계도와 각 망에 부여한 IP 대역, 그리고 회사 규모에 따라 어느 정도의 네트워크가 필요한지에 대한 판단 기준은 실전 기록의 도입부에 상세히 정리해 두었습니다.
📎 실전 구축 편
실제로 하나의 회사를 아홉 개 VLAN으로 나눈 전체 설계도, 번호 체계, IP 대역 배분, 그리고 “우리 회사 규모엔 어떤 네트워크가 맞는가”의 판단 기준은 이 시리즈의 도입부에 정리되어 있습니다.
→ 중소기업 네트워크 구축 – 00. 어떤 규모가 필요한가?
📋 프로젝트 관리 관점 — 조직도가 아니라 ‘하는 일’로 나눠라
“부서가 아니라 역할로 나눈다”는 원칙은 프로젝트의 관심사 분리와 작업 분해의 핵심입니다. 조직도(부서)를 그대로 시스템 경계로 삼으면, 성격이 다른 일이 한 칸에 섞여 리스크가 전이됩니다. 변동성이 큰 일(개발)과 지켜야 할 일(운영)을 같은 경계에 두지 않는 것 — 그리고 가장 민감한 통제권(관리망)을 별도로 격리하는 것은, 곧 프로젝트의 핵심 자산과 권한을 분리해 보호하는 설계입니다.
번호에도 질서를 — 읽히는 설계
망을 아홉 개로 나누면 새로운 문제가 생깁니다. 각 VLAN에는 번호를 붙여야 하는데, 이 번호를 아무렇게나 매기면 나중에 아무도 알아볼 수 없게 됩니다. VLAN 47이 무슨 망인지, VLAN 12가 어디 소속인지 매번 문서를 뒤져야 한다면 관리가 고통스러워집니다.
그래서 우리는 번호 자체에 의미를 담습니다. 실제 구축에서 쓴 규칙은 앞자리는 역할, 뒷자리는 위치였습니다. 앞자리로 그 망이 무슨 일을 하는지(1번대는 운영, 3번대는 개발, 9번대는 관리)를 표현하고, 뒷자리로 그 망이 어디에 있는지(본사는 10, 데이터센터는 20)를 표현했습니다.
[ VLAN 번호 체계 — 번호가 곧 설명 ]
1 1 0
│ │ └── 위치: 10=본사, 20=데이터센터
│ └───── (자리 맞춤)
└──────── 역할: 1=운영, 2=검증, 3=개발,
4=사용자, 5=전화, 9=관리
예시
110 → "운영 + 본사" 910 → "관리 + 본사"
310 → "개발 + 본사" 120 → "운영 + 데이터센터"
920 → "관리 + 데이터센터"이렇게 해두면 번호만 보고도 그 망의 정체를 즉시 읽을 수 있습니다. 110은 운영·본사, 920은 관리·데이터센터. 문서를 뒤질 필요가 없습니다. 이것은 사소해 보이지만, 앞선 글들에서 우리가 강조했던 재현 가능한 표준의 또 다른 모습입니다. 네트워크가 커지고 사이트가 늘어도, 같은 규칙을 그대로 확장하면 됩니다. 세 번째 사이트가 생기면 뒷자리에 30을 부여하면 그만입니다. 질서 있는 번호 체계는 그 자체로 미래의 확장을 준비하는 설계입니다.
📋 프로젝트 관리 관점 — 명명 규칙은 가장 값싼 문서다
“번호만 보고 정체를 읽는다”는 것은, 프로젝트의 표준화된 명명 규칙·산출물 코드 체계와 같습니다. 규칙이 있으면 새 구성원도 문서를 뒤지지 않고 맥락을 즉시 파악하고, 새 사이트가 생겨도 같은 규칙을 확장하기만 하면 됩니다. 이것이 곧 재현 가능성이고, 속인성을 걷어낸 예측 가능성입니다. 좋은 표준은 미래의 확장을 미리 설계에 담아둔다는 점에서, 가장 값싸고 오래가는 문서입니다.
나눈 뒤에 지키는 것 — 경계의 통제
망을 나누는 것만으로 끝이 아닙니다. 여기에 중요한 함정이 하나 있습니다. VLAN으로 망을 갈라놓기만 하면, 기본 상태에서는 오히려 망끼리 통신이 될 수 있다는 점입니다. 방화벽이 각 망의 게이트웨이 역할을 하기 때문에, 아무 규칙도 세우지 않으면 방화벽이 이 망 저 망 사이를 그냥 이어줘 버립니다. 벽을 세웠는데 문을 다 열어둔 셈입니다.
망분리의 진짜 가치는 “개발망이 운영 서버를 못 건드린다”, “전화기가 서버에 못 붙는다” 같은 실제 격리에서 나옵니다. 그리고 그 격리를 만드는 것은 VLAN 자체가 아니라, 경계에 세우는 방화벽 규칙입니다. 나누는 것이 절반이라면, 경계를 통제하는 것이 나머지 절반입니다.
우리가 이 통제를 설계할 때 지키는 원칙이 몇 가지 있습니다.
- 기본은 차단, 예외만 허용. 우리는 “일단 다 막고, 꼭 필요한 통신만 연다”는 원칙으로 규칙을 세웁니다. 그 반대, 즉 “일단 다 열고 위험한 것만 막는” 방식은 반드시 빠뜨리는 구멍이 생깁니다. 무엇을 허용할지는 셀 수 있지만, 무엇을 막아야 할지는 끝이 없기 때문입니다.
- 관리망부터, 조심스럽게. 규칙을 세우는 순서도 중요합니다. 우리는 항상 관리망부터 손을 댑니다. 관리망은 우리가 장비에 접속하는 통로이기도 해서, 여기서 실수하면 스스로를 네트워크에서 잠가버릴 수 있기 때문입니다. 가장 민감한 곳을 가장 먼저, 가장 신중하게 다룹니다.
- 한꺼번에 잠그지 않는다. 운영 중인 네트워크에서 모든 경계를 한 번에 닫으면 반드시 사고가 납니다. 그래서 우리는 한 망씩 격리하고, 통신을 테스트하고, 이상이 없으면 다음으로 넘어가는 점진적 방식을 씁니다. 급하게 완성하는 것보다 안전하게 도달하는 것이 중요합니다.
[ 경계 통제의 최종 그림 (일부) ]
관리망 ──── 허용 ────▶ 모든 서버망 (관리 특권)
관리망 ──── 차단 ────✗ 직원망·전화망 (건드릴 이유 없음)
직원망 ──── 허용 ────▶ 인터넷, 지정된 웹 서비스만
직원망 ──── 차단 ────✗ 운영 서버망
개발망 ◀─── 상호 차단 ──▶ 운영망 (필요한 통신만 예외)
전화망 ──── 허용 ────▶ 인터넷, 전화 시스템만
전화망 ──── 차단 ────✗ 그 외 전부이 경계 규칙들을 실제 방화벽 위에서 어떤 순서로, 어떤 방식으로 세워가는지 — 규칙을 사람이 읽을 수 있게 만드는 방법부터 스스로를 잠그지 않는 작업 순서까지 — 는 실전 기록에서 가장 무겁게 다룬 부분입니다.
📎 실전 구축 편
나뉜 망들 사이에 실제로 방화벽 규칙을 세워 격리를 완성하는 과정 — 규칙을 이름으로 읽히게 만드는 법, 관리망부터 점진적으로 조여가는 순서, 자기 접속을 끊지 않는 안전한 작업법 — 은 여기서 다룹니다.
→ 중소기업 네트워크 구축 – 03. OPNsense 초기 설정: DHCP와 방화벽 룰
📋 프로젝트 관리 관점 — 기본값은 ‘차단’, 변경은 ‘점진적으로’
세 가지 규율이 그대로 프로젝트 원칙입니다. ① 기본은 차단, 예외만 허용 — 화이트리스트 방식은 리스크를 ‘셀 수 있게’ 만듭니다(열어둔 것만 관리하면 되므로). ② 가장 민감한 곳부터 신중히 — 스스로를 잠그지 않도록 통제권(관리망)을 먼저, 조심스럽게 다룬다는 것은 변경의 영향 분석과 롤백 경로 확보입니다. ③ 한꺼번에 잠그지 않는다 — 한 망씩 격리·테스트·전진하는 것은 곧 점진적 배포(단계적 롤아웃)와 변경 관리 그 자체입니다. 급하게 완성하기보다 안전하게 도달하기 — 운영 중 변경의 제1원칙입니다.
물리와 논리가 만나는 곳
지금까지 이야기한 VLAN과 경계는 모두 논리적인 개념입니다. 하지만 이 논리는 결국 물리적인 장비 위에서 구현되어야 합니다. 방화벽이 각 망의 게이트웨이가 되어 트래픽을 통제하고, 그 아래의 스위치가 각 포트에 어느 망을 배정할지 결정하며, 이 둘이 트렁크 케이블 한 가닥으로 맞물립니다.
우리는 이 구조에서 역할을 명확히 나눕니다. 방화벽은 L3, 즉 망과 망 사이의 라우팅과 통제를 맡습니다. 스위치는 L2, 즉 각 물리 포트에 VLAN 꼬리표를 붙이고 실제 케이블 연결을 담당합니다. 방화벽에서 “운영 서버망”이라는 논리적 경계를 정의하면, 스위치에서 그 망에 속할 물리 포트들을 지정해 실제 서버들이 꽂히게 하는 식입니다.
[ L3와 L2의 역할 분담 ]
┌────────────────────────────────────┐
│ 방화벽 (L3) │
│ 각 VLAN의 게이트웨이 · 라우팅 · 통제 │
└──────────────┬─────────────────────┘
│ 트렁크 (전 VLAN 태그)
┌──────────────┴─────────────────────┐
│ 백본 스위치 (L2) │
│ 포트별 VLAN 배정 · 물리 스위칭 │
└──┬────┬────┬────┬────┬────┬─────────┘
│ │ │ │ │ │
운영 운영 개발 직원 전화 관리
서버 서버 PC PC 전화 장비이 물리적 구현 — 스위치에서 어느 포트에 어느 망을 배정하고, 트렁크를 어떻게 설정하며, 재부팅해도 설정이 살아남게 하는 실무적인 세부 — 역시 실전 기록에 담겨 있습니다. 논리적 설계가 실제 장비 위에서 어떻게 살아 움직이는지 궁금하다면 함께 보시길 권합니다.
📎 실전 구축 편
방화벽(L3)이 정의한 VLAN을 백본 스위치(L2)의 물리 포트에 배정하고 트렁크 한 가닥으로 맞물리게 하는 실무는 이 편에 있습니다.
→ 중소기업 네트워크 구축 – 07. Omada 백본 스위치: L2 VLAN과 트렁크
맺으며 — 나눔은 곧 통제이고, 통제는 곧 신뢰다
하나의 사무실을 아홉 개의 세계로 나누는 일은, 겉보기에는 번거롭고 복잡해 보입니다. 케이블 하나면 될 것을 왜 굳이 태그를 붙이고 경계를 세우고 규칙을 만드는가. 하지만 그 번거로움의 반대편에는, 사고가 번지지 않는 안전함과, 누가 어디에 접근하는지 명확히 아는 통제력과, 회사가 커져도 흔들리지 않고 확장되는 질서가 있습니다.
우리가 사내망을 나누는 이유는 결국 앞선 글들에서 이야기한 것과 같은 자리로 돌아옵니다. 서버의 디스크를 나눈 것도, 시스템의 역할을 나눈 것도, 지금 네트워크의 경계를 나누는 것도, 모두 한 곳의 문제가 전체의 문제가 되지 않도록 미리 설계하는 일입니다. 그리고 이것은 인프라만의 이야기가 아닙니다. 리스크를 격리하고, 신뢰를 등급으로 나누고, 변경을 통제하고, 표준으로 확장을 준비하는 이 모든 과정은 — 좋은 프로젝트 관리가 하는 일과 정확히 같습니다.
나눔은 곧 통제이고, 통제는 곧 신뢰입니다. 우리가 고객의 네트워크를 아홉 개로 나누는 것은, 그 위에서 도는 비즈니스가 어떤 사고에도 흔들리지 않기를 바라기 때문입니다.
다음 편에서는 이 경계를 밖으로 확장합니다. 사무실을 넘어, 인터넷에 직접 노출되는 데이터센터의 서비스망을 어떻게 지키는지 — 공격 표면을 어떻게 줄이고 외부의 위협으로부터 어떻게 방어선을 세우는지를 다루겠습니다.
