들어가며 — 떨어져 있지만 하나여야 하는
앞의 두 글에서 우리는 두 개의 세계를 지었습니다. 직원들이 일하는 닫힌 사내망과, 고객이 접속하는 열린 서비스망. 그런데 현실의 회사는 이 두 세계가 한 건물 안에 있지 않습니다. 사무실은 본사에 있고, 실제 서비스가 도는 서버들은 멀리 떨어진 데이터센터(IDC)에 있습니다. 물리적으로 수십 킬로미터, 때로는 그 이상 떨어진 두 장소입니다.
그런데 일은 이 둘이 하나인 것처럼 이뤄져야 합니다. 본사의 엔지니어가 데이터센터의 서버에 접속해 관리하고, 본사의 모니터링 시스템이 데이터센터 서버의 상태를 실시간으로 지켜보며, 배포 시스템이 본사에서 데이터센터로 새 버전을 밀어 넣습니다. 백업 데이터가 두 곳 사이를 오가고, 로그가 한곳으로 모입니다. 두 사무실은 떨어져 있지만, 네트워크상으로는 하나의 인트라넷처럼 동작해야 합니다.
어떻게 물리적으로 떨어진 두 장소를 하나의 내부망처럼 이을 수 있을까요? 이 글은 그 질문에 대한 우리의 답입니다. 전용선을 까는 대신, 이미 깔려 있는 인터넷 위에 우리만의 암호화된 전용 통로를 그리는 방법 — IPsec 터널 — 에 대한 이야기입니다.
📋 프로젝트 관리의 시선으로
1·2편이 “경계를 긋는 이야기”였다면, 3편부터는 “그 경계를 안전하게 넘나드는 이야기”입니다. 여기서 다루는 판단들 — 직접 만들 것인가 빌릴 것인가(전용선 vs 터널), 무엇을 통합하고 무엇은 격리할 것인가, 연결을 어디까지 완성으로 볼 것인가 — 은 곧 프로젝트의 Build vs Buy 의사결정, 통합 범위 관리, 완료 정의(DoD)와 같습니다. 이 글은 파티션·리눅스·사내망 분리·서비스망 방어와 같은 원칙 위에 서 있습니다.
두 갈래 길 — 전용선과 터널
두 지점을 잇는 데는 크게 두 갈래의 방법이 있습니다.
첫 번째는 전용선(leased line)입니다. 통신사에서 두 지점만을 위한 물리적인 회선을 임대하는 것입니다. 오직 우리만 쓰는 독립된 선이니 안전하고 성능도 일정합니다. 하지만 대가가 큽니다. 매달 상당한 비용이 나가고, 설치에 시간이 걸리며, 한번 깔면 경로를 바꾸기 어렵습니다. 대기업이라면 감당하겠지만, 중소 규모의 회사가 두 사이트를 잇자고 전용선을 까는 것은 과한 투자인 경우가 많습니다.
두 번째는 인터넷 위의 암호화 터널입니다. 두 지점 모두 어차피 인터넷에 연결되어 있으니, 그 인터넷을 통로로 삼되 그 위에 암호화된 전용 통로를 논리적으로 그리는 방식입니다. 물리적으로는 공용 인터넷을 타고 흐르지만, 그 안의 데이터는 완벽하게 암호화되어 있어 중간에서 누가 엿봐도 알아볼 수 없습니다. 마치 공공 도로 위에 우리만 볼 수 있는 투명한 파이프를 놓고, 그 안으로만 우리 데이터를 흘려보내는 것과 같습니다.
우리는 대부분의 중소 규모 환경에서 두 번째 방법, 즉 IPsec 터널을 선택합니다. 판단의 근거는 명확합니다.
[ 전용선 vs IPsec 터널 ]
전용선 (Leased Line)
통신사 ──물리 전용 회선──▶ 대기업급 비용
· 성능 일정, 완전 독립
· 매달 고정 비용 큼, 설치 오래, 경로 고정
· 중소 규모엔 과투자인 경우 많음
IPsec 터널 (Site-to-Site VPN)
본사 ══암호화 터널══[ 공용 인터넷 ]══암호화 터널══ IDC
· 기존 인터넷 회선 재사용 → 추가 회선비 없음
· 빠른 구축, 유연한 변경
· 데이터는 암호화되어 공용망에서도 안전물론 IPsec 터널이 만능은 아닙니다. 공용 인터넷을 타기 때문에 인터넷 상황에 따라 성능이 흔들릴 수 있고, 전용선처럼 성능이 계약으로 보장되지는 않습니다. 그래서 우리는 이 점을 솔직하게 고려합니다. 관리·모니터링·배포처럼 안정성이 중요하되 대역폭이 극단적으로 크지 않은 트래픽에는 IPsec이 훌륭한 선택입니다. 반면 사이트 간에 어마어마한 대용량 데이터를 실시간으로 주고받아야 하는 특수한 경우라면 전용선을 검토합니다. 도구는 상황에 맞게 고르는 것이지, 하나가 항상 옳은 것은 아니기 때문입니다.
📋 프로젝트 관리 관점 — Build vs Buy는 총소유비용으로 판단한다
전용선(전용 자원 구매) 대 터널(기존 자원 재사용)은 전형적인 Build/Buy·자원 조달 의사결정입니다. 답은 규모와 요구에 따라 갈립니다 — 초기·고정 비용, 구축 속도, 변경 유연성, 보장 수준을 저울에 올려 총소유비용(TCO)과 리스크로 판단합니다. 그리고 “IPsec이 만능은 아니다”라고 한계를 명시하는 것이 핵심입니다. 트레이드오프를 숨긴 확신보다, 언제 다른 선택이 나은지를 아는 결정이 언제나 더 견고합니다.
IPsec은 어떻게 통로를 만드는가
IPsec이 어떻게 공용 인터넷 위에 안전한 통로를 만드는지, 그 원리를 조금 들여다보겠습니다. 깊은 기술적 세부까지 갈 필요는 없고, 핵심 발상만 짚으면 충분합니다.
IPsec 터널은 두 단계로 세워집니다. 먼저 양쪽 끝의 방화벽이 서로 “너 진짜 내가 아는 그 상대가 맞느냐”를 확인하고 암호화에 쓸 비밀 열쇠를 안전하게 교환합니다. 이 과정에서 미리 약속한 인증 정보로 서로의 신원을 검증하기 때문에, 엉뚱한 제3자가 끼어들 수 없습니다. 신원 확인과 열쇠 교환이 끝나면, 두 번째 단계로 실제 데이터가 그 열쇠로 암호화되어 터널을 통해 오갑니다.
[ IPsec 터널이 서는 과정 ]
1단계 — 신원 확인 & 열쇠 교환
본사 방화벽 ◀──"너 맞아?"──▶ IDC 방화벽
서로의 신원 검증 (사전 약속된 인증)
암호화 열쇠를 안전하게 교환
2단계 — 암호화된 데이터 전송
본사 ══[ 암호화된 데이터 ]══▶ IDC
공용 인터넷을 타지만
내용은 열쇠 없이 해독 불가이 구조의 핵심은, 터널 밖에서 보면 아무것도 알 수 없다는 점입니다. 공용 인터넷의 어느 지점에서 이 트래픽을 가로챈다 해도, 보이는 것은 암호화된 의미 없는 데이터뿐입니다. 그 안에 무엇이 오가는지, 어떤 서버가 어떤 명령을 주고받는지는 열쇠를 가진 양쪽 끝만 알 수 있습니다. 물리적으로는 공용망을 타면서도 논리적으로는 우리만의 사설망이 되는 것, 그것이 IPsec이 주는 것입니다.
설계의 진짜 어려움 — 무엇을 잇고 무엇을 막을까
여기까지는 IPsec의 원리입니다. 하지만 우리가 실무에서 마주하는 진짜 어려움은 터널을 세우는 기술 자체가 아닙니다. 터널을 세운 다음, 그 터널로 무엇을 통과시키고 무엇을 막을 것인가를 결정하는 설계입니다.
순진하게 생각하면, 두 사이트를 이었으니 이제 본사의 모든 것이 데이터센터의 모든 것과 통신할 수 있게 하면 될 것 같습니다. 하지만 이것은 위험한 발상입니다. 우리가 1·2편에서 그토록 공들여 망을 나누고 경계를 세웠는데, 두 사이트를 잇는다고 그 경계를 통째로 허물어버린다면 지금까지의 모든 노력이 무의미해집니다. 터널은 두 사이트를 잇는 다리이지, 모든 벽을 없애는 폭탄이 되어서는 안 됩니다.
그래서 우리는 터널을 세울 때 이런 원칙을 지킵니다. 필요한 망만, 필요한 만큼만 잇는다.
우리가 실제 구축에서 내린 판단이 좋은 예입니다. 본사와 데이터센터를 이을 때, 우리는 관리망끼리만 터널로 연결했습니다. 즉 본사의 관리망과 데이터센터의 관리망이 서로 통하게 하되, 운영 서버망끼리는 터널로 직접 잇지 않았습니다. 이유가 있습니다. 사이트 간에 실제로 필요한 통신은 대부분 관리 트래픽입니다. 엔지니어가 원격지 서버를 관리하고, 모니터링 시스템이 상태를 수집하고, 배포와 백업이 오가는 것들입니다. 이 관리 트래픽은 관리망을 통하면 됩니다. 반면 양쪽의 운영 서비스 서버끼리 내부망으로 직접 연결할 이유는 거의 없고, 오히려 그렇게 이으면 한쪽 서비스망의 사고가 터널을 타고 다른 쪽으로 번질 위험만 커집니다.
[ 터널로 무엇을 잇는가 — 선택적 연결 ]
본사 (HQ) 데이터센터 (IDC)
┌──────────────┐ ┌──────────────┐
│ 관리망 ●──────┼══ IPsec 터널 ══┼──────● 관리망 │ ← 연결 O
│ │ │ │ (관리·모니터링·
│ 운영 서버망 ✕ │ │ 운영 서비스망 ✕│ 배포·백업)
│ 개발망 ✕ │ │ │
│ 직원망 ✕ │ │ │ ← 직접 연결 X
└──────────────┘ └──────────────┘
불필요한 연결은 열지 않는다
→ 한쪽 사고가 터널 타고 번지는 것을 차단이것이 설계의 핵심입니다. 터널을 세우는 것은 기술이지만, 그 터널로 무엇을 잇고 무엇을 막을지 결정하는 것은 판단입니다. 그리고 그 판단의 기준은 언제나 같습니다. 꼭 필요한 것만 연결하고, 나머지는 격리를 유지한다. 두 사이트를 하나처럼 쓰되, 하나가 되었다고 해서 격리의 원칙까지 버리지는 않는 것입니다.
📋 프로젝트 관리 관점 — 통합은 경계를 허무는 일이 아니다
“이었으니 다 통하게 하자”는 유혹은, 프로젝트에서 시스템·팀·프로세스를 통합할 때 그대로 나타납니다. 하지만 통합(integration)이 곧 경계의 제거를 뜻하지는 않습니다. 필요한 인터페이스만 정의해 연결하고 나머지는 격리를 유지해야, 한쪽의 장애·변경·사고가 연결을 타고 전체로 번지는 것을 막습니다. 좋은 통합은 최소한의 명확한 접점(관리망끼리만)으로 잇는 것 — 느슨한 결합(loose coupling)이 곧 회복탄력성입니다.
자주 걸려 넘어지는 곳 — 라우팅
IPsec 구축에서 실무자들이 가장 흔히 걸려 넘어지는 지점이 있습니다. 터널 자체는 잘 세워졌는데 통신이 안 되는 상황입니다. 원인은 대개 라우팅입니다.
조금 풀어 설명하면 이렇습니다. 터널을 세운다는 것은 두 지점 사이에 통로를 만드는 것이지만, 데이터가 그 통로로 알아서 흘러 들어가지는 않습니다. 각 사이트의 방화벽에게 “저쪽 사이트의 이 주소 대역으로 가는 데이터는 인터넷이 아니라 이 터널로 보내라”고 명확히 길을 알려줘야 합니다. 이 길 안내가 빠지면, 저쪽 사이트로 가야 할 데이터가 엉뚱하게 일반 인터넷 경로로 빠져나가 버려서, 터널은 멀쩡히 서 있는데도 통신이 되지 않습니다.
[ IPsec에서 라우팅을 빠뜨리면 ]
라우팅 설정 O (정상)
IDC 대역행 데이터 ──▶ [ 터널로 진입 ] ──▶ IDC 도달 ✓
라우팅 설정 X (흔한 실수)
IDC 대역행 데이터 ──▶ [ 일반 인터넷으로 ] ──▶ 길 잃음 ✗
터널은 서 있지만 안 쓰임그래서 우리는 IPsec을 구성할 때 터널을 세우는 것과 라우팅을 정의하는 것을 언제나 한 세트로 다룹니다. 어느 대역이 터널을 통과해야 하는지를 양쪽 방화벽에 정확히 명시하고, 그것이 방화벽 규칙과도 맞물리게 합니다. 터널을 세웠다고 끝이 아니라, 그 터널로 갈 데이터의 길까지 놓아야 비로소 두 사이트가 통합니다.
이 IPsec 터널을 실제 방화벽 위에서 어떻게 세우고, 관리망끼리 연결하며, 라우팅의 함정을 어떻게 피하는지는 실전 기록에 구체적으로 담겨 있습니다.
📎 실전 구축 편
본사와 데이터센터를 IPsec Site-to-Site로 묶어 관리망끼리 연결하고, 운영망 간 통신은 격리하며, 터널 라우팅(트래픽 셀렉터)의 함정을 피하는 실제 구성은 이 편에 있습니다.
→ 중소기업 네트워크 구축 – 06. 보안 설정 ②: 절체 후 방어선과 접근 (IPsec)
📋 프로젝트 관리 관점 — ‘연결’과 ‘동작’은 다르다: 완료의 정의
“터널은 섰는데 통신이 안 된다”는 상황은, 프로젝트에서 “개발은 끝났는데 실제로는 안 되는” 상태와 똑같습니다. 산출물이 존재하는 것과 실제로 연동·동작하는 것은 다릅니다. 그래서 우리는 터널과 라우팅을 한 세트로 다룹니다 — 완료의 정의(DoD)에 ‘엔드투엔드 동작 검증’까지 포함시키는 것입니다. 부분의 완성을 전체의 완성으로 착각하지 않는 것이, 통합 프로젝트의 제1원칙입니다.
하나의 설계, 두 개의 사이트
두 사이트를 IPsec으로 잇는 일에는, 앞선 글들에서 강조해온 원칙 하나가 조용히 뒷받침되고 있습니다. 두 사이트를 같은 설계 원칙으로 표준화하는 것입니다.
만약 본사와 데이터센터가 서로 다른 방식으로, 다른 주소 체계로, 다른 규칙으로 구성되어 있다면, 이 둘을 잇는 일은 악몽이 됩니다. 주소가 겹쳐서 충돌하고, 규칙이 달라서 예외가 넘쳐나고, 한쪽을 이해한 사람이 다른 쪽은 알아보지 못합니다. 하지만 두 사이트를 처음부터 같은 원칙으로 설계했다면, 잇는 일은 자연스럽습니다.
우리가 1편에서 이야기한 VLAN 번호 체계가 여기서 빛을 발합니다. 앞자리는 역할, 뒷자리는 위치라는 규칙 덕분에, 본사의 관리망(910)과 데이터센터의 관리망(920)은 번호만 봐도 “같은 역할, 다른 위치”임이 즉시 읽힙니다. 두 사이트가 같은 언어로 지어졌기에, 터널로 잇는 순간 마치 원래 하나였던 것처럼 맞물립니다.
[ 같은 설계 원칙으로 지어진 두 사이트 ]
본사 (HQ) 데이터센터 (IDC)
├─ 운영 110 ├─ 운영 120
├─ 개발 310 │
├─ 관리 910 ●═══ IPsec ═══● 관리 920
└─ ... └─ ...
뒷자리만 다른 동일 체계
→ 번호가 곧 "같은 역할, 다른 위치"를 설명
→ 터널로 이으면 하나처럼 맞물림이것은 앞선 모든 글을 관통하는 재현 가능한 표준의 또 다른 증명입니다. 서버를 같은 원칙으로 나누고, 사이트를 같은 원칙으로 설계했기에, 사이트가 하나에서 둘로, 둘에서 셋으로 늘어도 같은 방식으로 확장할 수 있습니다. 세 번째 사이트가 생기면 같은 설계에 위치 번호만 부여해 또 하나의 터널로 잇습니다. 표준화된 설계는 그 자체로 확장의 청사진입니다.
우리가 이 두 사이트의 전체 그림 — 어떤 망들이 어디에 있고, 어떻게 하나의 표준으로 묶였는지 — 을 어떻게 잡았는지는 실전 기록의 도입부에서 전체 설계도와 함께 볼 수 있습니다.
📎 실전 구축 편
본사와 데이터센터 두 사이트를 하나의 설계 원칙으로 표준화하고 IPsec으로 묶은 전체 그림 — 망 구성, 번호 체계, 장비 배치 — 은 이 시리즈의 도입부에 정리되어 있습니다.
→ 중소기업 네트워크 구축 – 00. 어떤 규모가 필요한가?
📋 프로젝트 관리 관점 — 표준화가 통합의 비용을 결정한다
두 사이트를 잇는 비용은 터널 기술이 아니라 “두 곳이 얼마나 같은 원칙으로 지어졌는가”에서 갈립니다. 서로 다른 규칙·체계로 만든 결과물을 나중에 통합하려면 예외와 충돌이 폭발합니다(전형적인 통합 부채). 반대로 공통 표준(명명·구조·정책) 위에 지어두면, 확장은 “같은 규칙에 번호만 추가”가 됩니다. 표준화는 처음엔 번거롭지만, 미래의 통합·확장 비용을 미리 갚아두는 투자입니다.
맺으며 — 거리를 지우는 설계
물리적인 거리는 지울 수 없습니다. 본사와 데이터센터는 여전히 수십 킬로미터 떨어져 있고, 그 사이에는 공용 인터넷이 놓여 있습니다. 하지만 좋은 설계는 그 거리를 네트워크상에서 지워냅니다. 엔지니어는 바로 옆방의 서버를 만지듯 원격지 서버를 관리하고, 시스템들은 같은 건물에 있는 것처럼 서로 통신하며, 두 사이트는 하나의 인트라넷으로 동작합니다. 그러면서도 그 통신은 공용 인터넷 위에서 완벽하게 암호화되어 안전합니다.
IPsec 터널이 하는 일의 본질이 이것입니다. 거리를 지우되 안전은 지키는 것. 그리고 두 사이트를 잇되 경계는 유지하는 것. 우리는 터널로 두 세계를 하나처럼 만들면서도, 꼭 필요한 통로만 열어 격리의 원칙을 끝까지 지킵니다. 잇는 것과 나누는 것은 모순이 아닙니다. 필요한 곳은 잇고 불필요한 곳은 나누는 것, 그 균형이 바로 설계입니다. 그리고 그것은 좋은 프로젝트 관리가 늘 하는 일이기도 합니다 — 연결할 것과 격리할 것을 가려, 통합의 이득은 취하되 그 대가는 치르지 않는 것.
지금까지 우리는 망과 망을 이었습니다. 사무실의 여러 망을 경계로 나누고, 두 사이트를 터널로 이었습니다. 하지만 아직 남은 연결이 하나 있습니다. 사람과 망입니다. 사무실 밖에 있는 직원이, 출장지나 집에서, 회사의 내부망에 안전하게 접속하려면 어떻게 해야 할까요. 다음 편에서는 사람을 안전하게 잇는 마지막 연결 — 원격 접속 VPN — 을 다루며 이 시리즈를 마무리하겠습니다.
