들어가며 — 벽에 문을 내는 일
지금까지 세 편에 걸쳐 우리는 경계를 세우고, 그 경계를 안전하게 넘나드는 법을 이야기했습니다. 사무실의 여러 망을 나누어 신뢰의 경계를 긋고, 인터넷을 마주 보는 서비스망을 겹겹으로 지키고, 두 사이트를 암호화된 터널로 이었습니다. 이 모든 노력의 방향은 하나였습니다. 외부로부터 내부를 지키는 것. 벽을 높이 쌓고, 문을 최소화하고, 낯선 이의 접근을 막는 일이었습니다.
그런데 이제 정반대의 요구가 등장합니다. 우리 편인 사람을, 그 잘 쌓아 올린 벽 너머로 들여보내야 하는 상황입니다. 집에서 일하는 직원이 회사 내부 시스템에 접속해야 하고, 출장 중인 엔지니어가 데이터센터 서버를 긴급히 손봐야 하며, 재택근무자가 사내 그룹웨어를 써야 합니다. 이들은 물리적으로 사무실 밖에, 인터넷 어딘가에 있습니다. 그리고 그들이 접속하려는 곳은, 우리가 그토록 철저히 외부로부터 격리한 바로 그 내부망입니다.
여기에 이 시리즈 전체에서 가장 미묘한 긴장이 있습니다. 우리가 지금까지 막아온 바로 그 방향으로, 우리 편만 통과시켜야 한다. 외부에서 내부로의 접근을 열되, 오직 인증된 사람에게만, 오직 필요한 만큼만 열어야 합니다. 문을 내되, 그 문이 침입의 통로가 되어서는 안 됩니다. 이 글은 그 균형을 어떻게 설계하는가 — 사람을 안전하게 내부망에 잇는 원격 접속 VPN에 대한 이야기입니다.
📋 프로젝트 관리의 시선으로
3편이 “장소와 장소”였다면, 4편은 “사람과 망”이고, 여기서 보안 서사가 완결됩니다. 이 편에서 다루는 것들 — 누구를 신뢰할지(인증), 어디까지 허용할지(최소 권한), 무엇을 언제 열지(순서) — 은 곧 프로젝트의 거버넌스·권한 관리·의존성 있는 릴리스 순서와 같습니다. 이 글은 파티션·리눅스·사내망 분리·서비스망 방어·사이트 연결과 같은 원칙 위에서 시리즈를 닫습니다.
원격 접속 VPN이란 무엇인가
앞선 3편에서 우리는 두 사무실을 잇는 IPsec 터널을 이야기했습니다. 그것은 장소와 장소를 잇는 VPN이었습니다. 본사와 데이터센터라는 고정된 두 지점 사이에 상시 통로를 놓는 방식이었습니다.
원격 접속 VPN은 성격이 다릅니다. 이것은 사람과 망을 잇습니다. 고정된 장소가 아니라, 인터넷 어딘가에 있는 개인의 기기를 회사 내부망으로 끌어들이는 방식입니다. 직원이 자신의 노트북에서 VPN에 접속하면, 그 순간 그 노트북은 마치 사무실 안의 책상에 앉아 있는 것처럼 내부망의 일부가 됩니다. 물리적으로는 카페에 있든 집에 있든 해외에 있든, 네트워크상으로는 사내에 들어와 있는 것입니다.
[ 두 종류의 VPN ]
사이트 간 VPN (3편 — 장소와 장소)
본사 ══상시 터널══ 데이터센터
고정된 두 지점, 항상 연결
원격 접속 VPN (4편 — 사람과 망)
집 노트북 ──┐
출장 폰 ──┼══ 각자 접속 ══▶ 회사 내부망
카페 PC ──┘
유동적인 개인, 필요할 때 접속이 원격 접속을 안전하게 만드는 두 개의 축이 암호화와 인증입니다. 암호화는 그 연결이 공용 인터넷을 타면서도 아무도 엿볼 수 없게 만드는 것이고, 인증은 그 문을 통과하려는 사람이 정말 우리 편이 맞는지를 확인하는 것입니다. 이 둘 중 특히 인증이, 원격 접속 보안의 핵심입니다. 암호화된 통로라도 아무나 들어올 수 있다면 소용이 없기 때문입니다. 그래서 원격 접속 VPN의 진짜 설계는 “어떻게 암호화하느냐”보다 “누구를, 어디까지 들여보내느냐”에 있습니다.
신원의 확인 — 누구를 들여보낼 것인가
문을 여는 첫 단계는 신원 확인입니다. 접속을 시도하는 사람이 진짜 그 사람이 맞는지를 검증하는 것입니다.
가장 기본적인 방법은 아이디와 비밀번호이지만, 우리는 이것만으로는 결코 충분하다고 보지 않습니다. 비밀번호는 유출되고, 추측되고, 재사용됩니다. 원격 접속처럼 외부에 노출된 입구를 비밀번호 하나로 지키는 것은 위험합니다. 그래서 우리는 여러 겹의 인증을 겹칩니다.
우리가 실제 구축에서 택한 방식은 중앙 인증 시스템과의 연동이었습니다. VPN이 자체적으로 계정을 관리하는 대신, 회사의 중앙 계정 시스템에 물어보게 하는 것입니다. 이렇게 하면 여러 이점이 생깁니다. 직원이 입사하거나 퇴사할 때 계정을 한 곳에서만 관리하면 되고, 어느 한 사람의 접근 권한을 즉시 회수할 수 있으며, VPN마다 따로 계정을 만드는 번거로움이 사라집니다. 퇴사한 직원이 VPN 계정으로 여전히 내부망에 들어올 수 있다면 그것은 심각한 구멍인데, 중앙 인증은 이 구멍을 원천 차단합니다.
여기에 더해, 가능하다면 2단계 인증을 겹칩니다. 비밀번호를 아는 것에 더해, 그 사람이 가진 기기(예: 휴대폰의 인증 앱)로 생성되는 일회용 코드를 함께 요구하는 것입니다. 이렇게 하면 비밀번호가 유출되더라도 공격자가 그 사람의 휴대폰까지 갖고 있지 않는 한 통과할 수 없습니다.
[ 겹겹의 신원 확인 ]
접속 시도
│
▼ ① 무엇을 아는가 — 아이디 + 비밀번호
▼ ② 중앙 인증 확인 — 유효한 직원인가? 권한이 살아있나?
▼ ③ 무엇을 가졌는가 — 휴대폰 일회용 코드 (2단계)
│
▼
검증 통과 → 내부망 진입 허용
(한 겹이 뚫려도 다음 겹이 막는다)다만 우리는 여기서도 솔직합니다. 2단계 인증은 분명히 권장되지만, 잠금(lockout) 위험과 운영 편의 사이에서 조직이 판단할 영역이기도 합니다. 인증을 지나치게 복잡하게 만들면 정작 정당한 직원이 급할 때 못 들어오는 일이 생깁니다. 그래서 우리는 접근하려는 대상의 민감도에 따라 인증 강도를 조절합니다. 운영 서버가 있는 관리망처럼 민감한 곳에 닿는 접속에는 2단계 인증을 사실상 필수로 두되, 백업 관리자 계정과 복구 수단을 먼저 확보해 스스로를 잠그는 사고를 막습니다. 보안은 강할수록 좋은 것이 아니라, 지킬 것의 무게에 맞아야 좋은 것입니다.
📋 프로젝트 관리 관점 — 신원은 한 곳에서, 통제는 여러 겹으로
“중앙 인증으로 계정을 한 곳에서 관리하고 즉시 회수한다”는 것은, 프로젝트의 단일 진실원천(single source of truth)과 권한 회수 절차(offboarding)입니다. 권한이 여기저기 흩어지면 퇴사자의 접근이 남는 구멍이 생깁니다. 그리고 비밀번호+2단계를 겹치는 것은 다중 통제이지만, “강할수록 좋다”가 아니라 지킬 것의 무게에 맞춘다는 균형이 핵심입니다 — 복구 수단 없이 잠금만 강화하면, 통제가 곧 자기 발등을 찍습니다.
접근의 통제 — 어디까지 들여보낼 것인가
신원을 확인해 문을 통과시켰다고 끝이 아닙니다. 오히려 여기서부터가 진짜 설계입니다. 들여보낸 사람이 내부망의 어디까지 갈 수 있는가를 정해야 합니다.
흔한 실수는, 일단 VPN에 접속만 하면 내부망 전체를 자유롭게 돌아다니게 두는 것입니다. 이것은 위험합니다. 재택근무하는 일반 직원과, 서버를 관리하는 엔지니어와, 개발자는 각기 접근해야 할 곳이 다릅니다. 일반 직원이 운영 서버의 관리 화면에 닿을 이유가 없고, 개발자가 전 사원의 인사 데이터에 접근할 이유가 없습니다. 그런데 “VPN에 들어오면 다 통과”라는 식으로 두면, 어느 한 사람의 계정이 탈취당했을 때 공격자가 내부망 전체를 휘젓게 됩니다.
그래서 우리는 접속하는 사람의 역할에 따라 접근 범위를 나눕니다. 이것은 1편에서 사내망을 역할별로 나눴던 것과 똑같은 발상입니다. 이번에는 그 원칙을 원격 접속자에게 적용하는 것입니다.
우리가 실제 구축에서 쓴 방식은, VPN 접속자에게 줄 주소 대역 자체를 역할별로 미리 쪼개두는 것이었습니다. 관리자용 대역, 개발자용 대역, 일반 사용자용 대역을 나누고, 각 대역이 내부망의 어디까지 닿을 수 있는지를 방화벽에서 명확히 규정했습니다.
[ 역할에 따른 원격 접속 범위 분리 ]
VPN 접속자
│
├─ 관리자 대역 ──▶ 관리망까지 접근 (넓은 권한)
│
├─ 개발자 대역 ──▶ 개발망만 접근
│
└─ 일반 사용자 대역 ──▶ 지정된 업무 시스템만
(운영·관리망 차단)
같은 VPN이라도 누구냐에 따라 닿는 범위가 다르다이렇게 나누면, 설령 일반 사용자 계정 하나가 탈취되더라도 그 피해는 일반 사용자가 닿을 수 있는 제한된 범위에 갇힙니다. 공격자가 그 계정으로 관리망이나 운영 서버에 접근하려 해도 방화벽이 막습니다. 문을 열어주되, 그 사람이 갈 수 있는 방을 미리 정해두는 것입니다. 이것이 최소 권한의 원칙입니다. 각자에게 꼭 필요한 만큼의 접근만 주고, 그 이상은 주지 않습니다.
특히 우리는 외부에서 운영 시스템으로의 접근을 다룰 때 한 겹을 더 둡니다. 외부의 원격 접속자가 운영 서버에 곧바로 닿게 하지 않고, 반드시 관리망을 거치도록 경로를 설계합니다. 가장 민감한 자산일수록 여러 관문을 통과하게 만드는 것입니다.
📋 프로젝트 관리 관점 — 최소 권한은 사고의 폭발 반경을 줄인다
“VPN에 들어오면 다 통과”는, 프로젝트로 치면 모두에게 전권을 주는 조직입니다. 편하지만, 계정 하나·실수 하나가 곧 전체 사고가 됩니다. 역할에 따라 접근을 나누는 최소 권한(least privilege)은, 사고가 나더라도 피해 범위(blast radius)를 그 역할 안에 가둡니다. 가장 민감한 자산일수록 관문을 더 두는 것 — 이것이 1편의 “역할로 나눈다”가 사람에게 되돌아온 모습이며, 리스크를 국소화하는 거버넌스의 핵심입니다.
왜 가장 마지막에 여는가
원격 접속 VPN을 구축할 때 우리가 지키는 중요한 순서 원칙이 있습니다. VPN은 맨 마지막에 연다.
이유는 분명합니다. VPN은 외부에서 내부로 직접 들어오는 입구입니다. 우리가 이 시리즈 내내 지켜온 모든 방어선 — 망분리, 방화벽, 지역 차단, 침입 탐지 — 을 관통해 내부로 이어지는 통로입니다. 그렇기 때문에 이 입구는, 다른 모든 방어선이 자리를 잡고 안정된 뒤에 마지막으로 여는 것이 안전합니다.
만약 다른 방어선이 채 갖춰지지 않은 상태에서 VPN부터 열어버리면, 가장 위험한 입구를 가장 먼저 노출하는 셈이 됩니다. 문제가 생겼을 때 원인을 격리하기도 어렵습니다. 반대로 다른 방어선을 다 세운 뒤 마지막에 VPN을 열면, 이 입구에서 무언가 이상이 생겨도 나머지 방어선들이 받쳐주고, 원인을 이 새로 연 입구로 좁혀 파악하기 쉽습니다.
[ 방어선 구축 순서 — VPN은 맨 마지막 ]
① 망분리 (경계 확립)
② 방화벽 (문 최소화)
③ 지역 차단 · 인증서 (입구 필터)
④ 침입 탐지 (행동 감시)
⑤ ────────────────────────────
VPN (외부→내부 직접 통로) ← 맨 마지막
다른 방어선이 안정된 뒤 노출이것은 이 시리즈를 관통하는 또 하나의 원칙과 맞닿아 있습니다. 위험이 적은 것부터, 위험이 큰 것은 뒤로. 통신을 끊거나 새로운 노출을 만드는 위험한 작업일수록 신중하게, 다른 것이 안정된 뒤에 다룹니다. 급하게 문을 여는 것이 아니라, 안전하게 문을 여는 것입니다.
이 원격 접속 VPN을 실제로 어떻게 구성하는지 — 인증 방식의 선택, 역할별 대역 분리, 그리고 왜 맨 마지막에 여는지 — 는 실전 기록에 구체적으로 담겨 있습니다.
📎 실전 구축 편
원격 접속 VPN(OpenVPN)의 실제 구성 — 중앙 인증 연동, 접속자 역할별 VPN 대역 분리(관리자·개발자·일반 사용자), 그리고 다른 방어선을 세운 뒤 맨 마지막에 여는 순서 원칙 — 은 이 편에 있습니다.
→ 중소기업 네트워크 구축 – 06. 보안 설정 ②: 절체 후 방어선과 접근 (OpenVPN)
📋 프로젝트 관리 관점 — 위험한 일은 의존성이 안정된 뒤에
“VPN을 맨 마지막에 연다”는 것은, 프로젝트의 작업 순서와 의존성 관리입니다. 가장 리스크가 크고 되돌리기 어려운 작업(외부→내부 직통로 개방)은 선행 통제가 자리 잡은 뒤에 배치해야, 문제가 나도 나머지가 받쳐주고 원인을 새 변경으로 좁힐 수 있습니다. “위험이 적은 것부터, 큰 것은 뒤로”는 곧 리스크 기반 일정 수립 — 순서 자체가 하나의 통제입니다.
편의와 보안, 두 마리 토끼
원격 접속을 설계할 때 늘 마주하는 근본적인 줄다리기가 있습니다. 편의와 보안입니다. 이 둘은 흔히 반대 방향으로 당깁니다. 보안을 강화할수록 직원은 접속하기 번거로워지고, 편의를 높일수록 보안 구멍이 늘어납니다.
인증을 여러 겹으로 걸면 안전하지만 매번 로그인이 성가시고, 접근 범위를 잘게 나누면 안전하지만 정작 필요한 곳에 못 닿아 업무가 막힐 수 있습니다. 반대로 한 번 접속하면 뭐든 되게 열어두면 편하지만, 계정 하나만 뚫려도 회사 전체가 위험해집니다. 어느 한쪽으로 치우치면 반드시 대가를 치릅니다.
좋은 원격 접속 설계는 이 둘을 동시에 잡습니다. 그 비결은 앞서 이야기한 것들 안에 이미 있습니다. 역할별로 접근을 나눠두면, 일반 직원은 자신이 쓰는 시스템에 간편하게 닿으면서도 민감한 영역과는 격리됩니다. 중앙 인증을 쓰면, 직원은 늘 쓰던 하나의 계정으로 편하게 접속하면서도 관리자는 권한을 일괄 통제합니다. 민감도에 따라 인증 강도를 조절하면, 일상적인 접속은 가볍게 하되 중요한 접근만 엄격하게 검증합니다.
[ 편의와 보안의 균형 ]
한쪽으로 치우치면
보안만 ▶ 너무 번거로워 업무 마비
편의만 ▶ 계정 하나 뚫려 전체 위험
균형점 (역할 기반 설계)
일반 직원 → 간편한 접속 + 제한된 범위 ← 편의 ↑ 위험 ↓
관리자 → 엄격한 인증 + 넓은 권한 ← 권한엔 그만한 검증
민감도에 인증 강도를 맞춘다이 균형은 그냥 얻어지지 않습니다. “누가 무엇에 접근해야 하는가”를 정확히 이해하고, 그에 맞춰 접근을 설계할 때만 가능합니다. 무작정 다 열지도, 무작정 다 막지도 않고, 각자에게 꼭 맞는 문을 내주는 것. 그것이 편의와 보안을 함께 잡는 유일한 길입니다.
📋 프로젝트 관리 관점 — 통제와 생산성은 제로섬이 아니다
“보안 vs 편의”는 프로젝트의 통제(거버넌스) vs 속도(생산성) 그대로입니다. 순진하게는 상충하지만, 좋은 설계는 둘을 함께 잡습니다 — 리스크에 비례한 통제(민감한 곳만 엄격히), 마찰 없는 기본 경로(일상은 가볍게), 역할 기반 권한(각자에게 꼭 맞게). 통제를 획일적으로 강화하면 사람들은 우회하고, 통제는 무력화됩니다. 지킬 것의 무게에 맞춘 통제만이 실제로 작동합니다.
맺으며 — 경계를 긋고, 다리를 놓다
이 시리즈에서 우리는 네트워크를 두고 두 가지 일을 했습니다. 앞의 두 편에서는 경계를 그었고, 뒤의 두 편에서는 그 경계를 넘는 다리를 놓았습니다.
사무실의 여러 망을 나누어 신뢰의 경계를 세우고, 인터넷을 마주 보는 서비스망을 겹겹으로 지킨 것이 경계를 긋는 일이었습니다. 그리고 두 사이트를 암호화된 터널로 잇고, 사무실 밖의 사람을 내부망으로 안전하게 들인 것이 다리를 놓는 일이었습니다. 언뜻 이 둘은 모순처럼 보입니다. 벽을 세우면서 동시에 문을 내는 것이니까요. 하지만 좋은 네트워크 설계란 바로 이 둘을 함께 해내는 것입니다.
경계를 어떻게 긋고, 그 경계를 어떻게 넘나들게 할 것인가. 이 시리즈를 관통한 질문이 이것이었습니다. 답은 언제나 같은 원칙 위에 있었습니다. 필요한 것만 잇고 나머지는 나눈다. 열되 지킨다. 각자에게 꼭 필요한 만큼만 허용한다. 위험이 적은 것부터, 큰 것은 뒤로. 그리고 무엇보다, 한 곳의 사고가 전체의 사고가 되지 않도록 미리 설계한다.
이것은 이 네트워크 시리즈만의 원칙이 아닙니다. 우리가 서버의 디스크를 나눌 때도, 시스템의 역할을 나눌 때도, 그리고 회사가 딛고 설 인프라 전체를 설계할 때도 한결같이 지켜온 태도입니다. 눈에 보이지 않는 이 경계와 다리들이, 고객의 비즈니스가 어떤 상황에서도 흔들림 없이 돌아가도록 조용히 떠받칩니다.
📋 프로젝트 관리 관점 — 좋은 관리도 결국 ‘벽과 문’의 균형이다
이 시리즈를 관통한 “경계를 긋고, 다리를 놓는다”는 곧 리스크 관리의 두 얼굴입니다. 리스크를 격리하는 벽(범위·권한·경계)과, 기회를 실현하는 문(통합·연결·협업)을 제자리에 함께 두는 것. 벽만 있는 요새는 아무 가치를 못 만들고, 문만 있는 벌판은 아무것도 지키지 못합니다. 파티션부터 VPN까지 여섯 편을 관통한 하나의 문장은 이것입니다 — 좋은 설계(그리고 좋은 관리)란, 열 곳과 막을 곳을 가려 그 균형을 미리 설계하는 것이다.
벽만 있는 요새는 아무것도 할 수 없고, 문만 있는 벌판은 아무것도 지킬 수 없습니다. 벽과 문을 함께, 제자리에 두는 것. 그 균형을 설계하는 일이 우리가 고객에게 드리는 신뢰의 실체입니다.
