정보관리기술사 학습 노트
← 목록으로
네트워크
#VPN#IPSec#SSLVPN#터널링#ZTNA#133회#126회
최종 업데이트 · 2026-10-01

VPN(Virtual Private Network)

1. 개요

가. 정의

공용 네트워크(인터넷) 위에 암호화된 가상의 전용 통신로(터널) 를 구성해, 물리적으로는 공용망을 지나가지만 논리적으로는 전용망처럼 안전하게 데이터를 송수신하는 기술.

VPN의 본질은 "소유"가 아니라 "구성"이다. 전용선이 물리 회선을 독점 소유해 보안을 얻는다면, VPN은 남들과 공유하는 인터넷 회선 위에 암호·인증·무결성이라는 소프트웨어적 장치를 덧씌워 독점한 것과 동등한 신뢰 수준을 만들어낸다. 즉 같은 광케이블을 수많은 패킷이 함께 지나가더라도, 특정 송·수신자만 열어볼 수 있는 "논리적 벽"을 세워 사실상의 전용망을 흉내 내는 것이 VPN이다.

나. 등장 배경 및 필요성

지사 간 통신이나 재택근무자의 사내 접속을 위해 물리 전용선(Leased Line) 을 까는 방식은 안전하지만 비용이 지역·거리에 비례해 폭증한다. 서울-부산 전용선과 서울-뉴욕 전용선의 월 임대료가 수십 배 차이 나는 이유가 바로 이 거리 종속성이며, 글로벌하게 흩어진 지사·원격근무자를 모두 전용선으로 묶는 것은 대기업에게도 비현실적이다. 인터넷은 이미 전 세계로 깔려 있어 한계비용이 사실상 0에 가깝지만, 누구나 패킷을 엿볼 수 있는 개방망이라 그대로 쓰면 도청·변조·위장 위험이 크다.

VPN은 이 둘의 장점만 취해, 저렴한 인터넷 위에 암호화·인증·무결성을 입힌 터널을 얹음으로써 전용선 수준의 보안을 훨씬 낮은 비용으로 구현한다. 거리와 무관하게 "인터넷에 닿기만 하면" 연결이 성립하므로, 새 지사가 생기거나 직원이 해외 출장을 가도 회선 공사 없이 즉시 안전한 접속이 가능하다는 확장성·민첩성이 전용선 대비 결정적 이점이다.

특히 2020년대 이후 원격근무가 상시화되고 기업 자원이 사내 데이터센터에서 클라우드(SaaS·IaaS)로 분산되면서, "언제·어디서·어떤 기기로든 안전하게 접속"하려는 수요가 폭증했다. 과거에는 사무실이라는 물리적 경계 안에 자원이 모여 있었지만, 이제는 사용자도 자원도 경계 밖에 흩어져 있다. 이 변화가 VPN을 기업 네트워크의 선택 사양에서 기본 인프라로 끌어올렸고, 동시에 뒤에서 다룰 ZTNA 같은 차세대 모델로의 진화 압력을 만들어냈다.

다. 특징

VPN을 다른 보안 기술과 구분 짓는 특징은 세 가지로 요약된다. 첫째는 가상화(Virtualization) 로, 물리 회선을 새로 깔지 않고 소프트웨어 설정만으로 전용 경로를 만들어낸다는 점이다. 둘째는 종단 간 보호(End-to-End Protection) 로, 암호화가 특정 구간이 아니라 양 종단 사이 전 구간에 걸쳐 유지된다. 셋째는 투명성(Transparency) 으로, 일단 터널이 서면 상위 애플리케이션은 자신이 VPN 위에서 동작한다는 사실을 몰라도 그대로 통신할 수 있다. 이 세 특징이 결합해 "저비용·고신뢰·무개조"라는 VPN의 실무적 매력을 만든다.

2. VPN 전체 동작 구조

VPN 연결은 "터널을 세우고(제어 평면) → 세운 터널로 데이터를 흘려보내는(데이터 평면)" 두 단계로 이해하면 명확하다. 아래 구조도는 원격 사용자와 본사 게이트웨이 사이에 터널이 형성되고, 그 안으로 평문 트래픽이 암호화되어 오가는 전체 흐름을 보여준다.

flowchart LR
  subgraph Client["사용자 단말"]
    APP["업무 앱(평문)"] --> VC["VPN 클라이언트(암호화)"]
  end
  VC -->|"암호화 터널"| NET["공용 인터넷"]
  NET -->|"암호화 터널"| GW["VPN 게이트웨이(복호화)"]
  subgraph HQ["본사 내부망"]
    GW --> SRV["업무 서버·DB"]
  end

단말에서 생성된 평문 트래픽은 VPN 클라이언트를 거치며 캡슐화·암호화되어 공용 인터넷으로 나간다. 중간 경로의 ISP·공유기·중계 라우터는 암호문과 바깥쪽 헤더만 볼 수 있을 뿐, 그 안의 목적지나 내용은 알 수 없다. 반대편 게이트웨이는 터널의 반대쪽 끝에서 패킷을 복호화해 원래 평문으로 되돌린 뒤 내부망으로 전달한다. 따라서 보안의 경계가 "물리 회선"이 아니라 단말의 VPN 클라이언트와 본사 게이트웨이라는 두 종단으로 옮겨지며, 이 두 종단 사이 구간 전체가 하나의 가상 전용 구간이 된다.

이 구조에서 핵심은 종단에서의 암·복호화 위치다. 암호화가 단말에서 시작돼 게이트웨이에서 풀리므로 중간 어디서 패킷이 탈취돼도 평문이 노출되지 않는다. 다만 게이트웨이 "안쪽"은 복호화된 평문이 흐르므로, 게이트웨이 자체가 공격당하면 내부가 그대로 노출된다는 구조적 약점도 동시에 내포한다. 이 약점이 뒤에서 다룰 경계 기반 신뢰 모델의 한계로 이어진다.

3. IPSec VPN vs SSL VPN

flowchart LR
  subgraph IPSec["IPSec VPN · L3"]
    A["본사"] --- B["지사"]
  end
  subgraph SSL["SSL VPN · L4~7"]
    U["원격 사용자"] --- W["웹/앱"]
  end

두 방식의 차이는 터널을 네트워크 스택의 어느 계층에 뚫느냐에서 비롯되고, 그 선택이 용도를 가른다. IPSec VPN은 네트워크 계층(L3)에서 IP 패킷 자체를 암호화하므로, 일단 터널이 서면 그 위의 모든 애플리케이션 트래픽이 투명하게 보호된다. 사용자가 의식하지 않아도 네트워크 전체가 연결되므로 지사-본사 상시 연결(Site-to-Site) 에 적합하지만, 전용 클라이언트 설치와 설정이 필요하다.

반면 SSL VPN은 전송응용 계층(L47)에서 TLS로 보호하며 웹 브라우저만으로 접속할 수 있어 무설치·편의성이 크다. 대신 특정 애플리케이션 단위로 접근을 여는 방식이라 세밀한 접근제어가 쉬워, 불특정 장소에서 접속하는 원격 사용자(Remote Access) 에 적합하다. 요컨대 "네트워크 전체를 붙일 것인가(IPSec), 필요한 앱만 열 것인가(SSL)"가 선택 기준이다.

계층 차이는 보안 관리의 세밀도(Granularity) 로도 직결된다. IPSec은 터널에 들어온 사용자에게 네트워크 전체를 열어주므로 관리가 단순하지만, 한 번 뚫리면 노출 범위가 넓다. SSL VPN은 "이 사용자는 그룹웨어와 회계 웹앱만"처럼 앱 단위로 권한을 좁힐 수 있어, 협력업체·외부 인력처럼 최소한만 열어줘야 하는 대상에 유리하다. 실무에서는 "지사 간 백본은 IPSec, 개별 재택·협력사 접속은 SSL VPN"으로 병행 운영하는 사례가 일반적이다.

구분 IPSec VPN SSL VPN
동작 계층 네트워크(L3) 전송응용(L47)
접속 방식 전용 클라이언트 필요 웹 브라우저(무설치)
주 용도 지사간 상시 연결(Site-to-Site) 원격 사용자 접속(Remote Access)
접근 범위 네트워크 전체 특정 애플리케이션 단위
보안 프로토콜 ESP/AH, IKE TLS/SSL
장점 광범위·투명한 연결 세밀한 접근제어·편의성

4. VPN 핵심 기술 요소와 IPSec 상세

flowchart LR
  T["터널링"] --> E["암호화"]
  E --> A["인증"]
  A --> I["무결성"]
  I --> K["키관리"]

VPN의 안전성은 다섯 요소가 사슬처럼 맞물릴 때 성립한다. 어느 하나라도 빠지면 전체가 무너지는 구조이므로, 각 요소를 "왜 필요한가"의 관점에서 짚어야 한다.

터널링(Tunneling) 은 원래의 패킷을 새 헤더로 감싸(캡슐화) 공용망을 통과시키는 뼈대로, L2TP·PPTP나 IPSec의 ESP/AH, SSL/TLS가 쓰인다. 캡슐화는 "주소 체계가 다른 사설망 패킷을 공용망에 실어 나르는" 역할을 하며, 그 자체로는 내용을 숨기지 못한다. 그래서 암호화(Confidentiality) 가 데이터 기밀성을 담당해 AES 같은 대칭키로 페이로드를 가린다. 대칭키를 쓰는 이유는 대량 트래픽을 빠르게 처리해야 하기 때문으로, 비대칭키는 느려서 키 교환에만 제한적으로 쓴다.

그러나 상대가 위장한 공격자면 암호화도 무의미하므로 인증(Authentication) 이 IKE·전자서명·인증서로 통신 양단을 검증한다. "내가 지금 암호화해 보내는 상대가 정말 본사 게이트웨이가 맞는가"를 확인하지 않으면, 공격자가 중간에서 게이트웨이인 척 가로채는 중간자 공격(MITM)에 그대로 노출된다. 전송 중 비트가 조작됐는지는 무결성(Integrity) 이 HMAC·해시로 탐지해, 공격자가 암호문을 임의로 뒤섞어 오작동을 유발하는 것을 막는다.

마지막으로 대칭키를 안전하게 나눠 갖고 주기적으로 바꾸는 키 관리(Key Management) 가 없으면 앞의 모든 것이 무너진다. 같은 키를 오래 쓰면 트래픽이 쌓여 암호 분석에 취약해지므로, IKE(Internet Key Exchange)가 디피-헬만(DH) 교환으로 세션키를 안전하게 합의하고 주기적으로 재협상(Rekeying)한다.

요소 설명 대표 기술
터널링(Tunneling) 원 패킷 캡슐화 L2TP·PPTP·IPSec(ESP/AH)·SSL/TLS
암호화(Confidentiality) 데이터 기밀성 대칭키(AES 등)
인증(Authentication) 양단 신원 검증 IKE·전자서명·인증서
무결성(Integrity) 위·변조 탐지 HMAC·해시
키 관리 세션키 교환·갱신 IKE

IPSec에는 두 가지 캡슐화 모드가 있다. 전송(Transport) 모드는 페이로드만 암호화하고 원래 IP 헤더는 유지해 종단 간(호스트-호스트) 통신에 쓰이고, 터널(Tunnel) 모드는 원래 IP 헤더까지 포함한 전체 패킷을 암호화해 새 헤더로 감싸므로 게이트웨이 간 Site-to-Site 연결에 쓰인다. 터널 모드가 원 IP 헤더까지 숨기는 이유는, 게이트웨이 뒤에 어떤 내부 호스트가 통신하는지(내부 토폴로지)를 외부에 노출하지 않기 위함이다.

IPSec 연결은 IKE 두 단계로 수립된다. 아래 시퀀스는 1단계에서 관리용 보안채널(IKE SA)을 세우고, 2단계에서 실제 데이터용 터널(IPSec SA)을 합의하는 흐름을 나타낸다.

sequenceDiagram
  participant A as 개시자(지사 GW)
  participant B as 응답자(본사 GW)
  A->>B: "IKE 1단계: DH 교환·상호 인증"
  B-->>A: "IKE SA 수립(관리 채널)"
  A->>B: "IKE 2단계: ESP 파라미터 협상"
  B-->>A: "IPSec SA 수립(데이터 터널)"
  A->>B: "암호화 데이터 전송(ESP)"

1단계에서 양측은 DH 교환으로 비밀을 공유하고 인증서·사전공유키(PSK)로 서로를 인증해 IKE SA라는 안전한 관리 채널을 만든다. 2단계에서는 그 채널 위에서 실제 데이터 보호용 암호 스위트와 키를 협상해 IPSec SA를 맺는다. 이렇게 "협상용 채널과 데이터용 채널을 분리"하는 설계 덕분에, 데이터 키는 자주 갱신하면서도 매번 무거운 인증을 다시 하지 않아 성능과 보안을 동시에 챙긴다.

5. 비교·사례

구체적인 적용 양상을 보면 두 방식의 선택 논리가 분명해진다. 어느 글로벌 제조사가 전 세계 30여 개 지사를 묶을 때는, 각 지사 라우터에 IPSec 터널 모드를 상시 설정해 서로를 하나의 사내망처럼 쓴다. 직원은 VPN을 의식하지 않고 사내 ERP에 접속하며, 연결이 끊겨도 자동 재협상된다. 반면 같은 회사가 재택·외주 인력에게는 SSL VPN 포털을 제공해, 브라우저 로그인만으로 허가된 몇 개 웹 시스템에만 접근하게 한다. 노트북에 전용 소프트웨어를 깔 수 없는 외주 환경에서 무설치 접속은 큰 장점이다.

성능 측면의 수치 감각도 중요하다. 암·복호화 연산은 CPU를 소모하므로, 전용 암호 가속 하드웨어 없이 소프트웨어로만 처리하면 고대역폭 구간에서 수백 Mbps~수 Gbps 수준에서 병목이 생길 수 있다. 그래서 본사 게이트웨이급 장비는 대개 AES-NI 같은 하드웨어 가속을 내장한다. 또한 공격 사례로, 과거 PPTP는 MS-CHAPv2 인증의 취약점으로 사실상 수 시간 내 크랙이 가능함이 알려져 현재는 사용이 권장되지 않으며, 신규 구축은 IPSec(IKEv2)나 최신 WireGuard 계열로 수렴하고 있다.

6. 심화: ZTNA·SASE로의 진화

전통 VPN의 가장 근본적 한계는 경계 기반 신뢰(Perimeter-based Trust) 모델에 있다. "터널에 들어오면 곧 내부자"로 간주하므로, 한 직원의 계정·단말이 탈취되면 공격자는 그 터널을 타고 내부망 전체를 횡적으로 이동(Lateral Movement)할 수 있다. 실제로 다수의 대형 침해 사고가 "탈취한 VPN 계정으로 초기 침투 → 내부 확산" 경로를 밟았고, 이는 "한 번 믿으면 끝까지 믿는" 모델의 구조적 결함을 드러냈다.

이에 대한 대안이 ZTNA(Zero Trust Network Access) 다. ZTNA는 "네트워크에 붙었다"는 사실을 신뢰의 근거로 삼지 않고, 자원에 접근하는 매 순간 사용자·기기·상황(위치·시간·단말 보안상태)을 재평가한다. 접근 단위도 네트워크 전체가 아니라 특정 애플리케이션으로 좁혀, 설령 한 계정이 뚫려도 그 하나의 앱 외에는 횡적 이동이 불가능하다. 또한 접속 전에는 자원의 존재 자체를 숨기는(Dark Cloud) 방식으로 공격 표면을 줄인다.

flowchart TB
  subgraph Legacy["전통 VPN: 경계 신뢰"]
    L1["터널 진입"] --> L2["내부망 전체 신뢰"]
  end
  subgraph ZT["ZTNA: 지속 검증"]
    Z1["접근 요청"] --> Z2["매 접근 재평가"]
    Z2 --> Z3["특정 앱만 허용"]
  end

더 나아가 SASE(Secure Access Service Edge) 는 ZTNA·SWG·CASB·FWaaS 등 보안 기능과 SD-WAN의 네트워킹을 클라우드 엣지에서 통합 제공하는 모델로, 사용자가 어디에 있든 가장 가까운 PoP(접속점)에서 보안 검사와 최적 경로 라우팅을 함께 받게 한다. VPN이 "본사로 일단 끌어온 뒤 나가는" 백홀 구조라면, SASE는 "엣지에서 검사하고 바로 클라우드로" 보내 지연을 줄인다. 다만 VPN이 당장 사라지는 것은 아니며, 상당수 기업은 Site-to-Site 백본은 IPSec으로 유지하면서 사용자 원격접속만 단계적으로 ZTNA로 전환하는 하이브리드 전략을 취하고 있다.

7. 고려사항 및 시사점

  • 성능과 보안의 균형(스플릿 터널링): 암·복호화는 CPU·대역 오버헤드를 유발하므로, 모든 트래픽을 터널로 보내는 대신 사내 목적지만 터널링하고 일반 인터넷은 직접 나가게 하는 스플릿 터널링으로 성능을 절충할 수 있다. 다만 분리 구간은 보안 검사를 우회하므로, 민감 업무는 풀 터널로 강제하는 등 정책적 선 긋기가 필요하다.
  • 경계 기반 신뢰의 한계와 제로트러스트 결합: VPN을 유지하더라도 "접속=신뢰"의 등식을 깨야 한다. 사용자·기기·상황을 매 접근마다 평가하는 제로트러스트 원칙과 결합하고, 접근 단위를 네트워크에서 애플리케이션으로 좁혀 횡적 이동을 차단하는 방향으로 운영해야 한다.
  • 인증 강화와 계정 탈취 대비: VPN 계정 탈취가 침해의 주된 초기 경로이므로, 비밀번호 단독 인증에서 벗어나 MFA(다중요소 인증) 와 단말 신뢰성 검증(기기 인증서·EDR 연동)을 필수화해야 한다.
  • 암호 스위트·프로토콜 최신화: PPTP 등 취약 프로토콜을 제거하고 IKEv2·TLS 1.3 등 현행 표준과 충분한 키 길이(AES-256 등)를 유지하며, 양자내성암호(PQC) 전환 로드맵도 선제적으로 검토해야 한다.
  • 가용성·확장성 설계: 원격근무 상시화로 VPN이 필수 인프라가 된 만큼, 게이트웨이 이중화·부하분산과 동시접속 세션 용량 산정을 통해 특정 시점 접속 폭주에도 서비스가 끊기지 않도록 설계해야 한다.

참고자료

한 줄 요약: VPN은 공용망 위에 암호화 터널로 가상 전용망을 구성 하는 저비용 보안 기술로, 네트워크 계층의 IPSec(지사간)과 응용 계층의 SSL(원격접속)로 나뉘며 터널링·암호화·인증·무결성·키관리를 핵심 요소로 하고, 경계 신뢰의 한계를 넘어 매 접근을 검증하는 ZTNA·SASE로 진화하고 있다.