VPN 전후 데이터 경로와 지연 변화, 보안 관점에서 비교하기
“VPN 전”이랑 “VPN 후”는 길이 어떻게 달라지나요?
VPN은 한마디로 “내 트래픽(데이터)을 택배 상자에 넣어 봉인해서, 지정한 창고(VPN 게이트웨이)까지 먼저 보내는 방식”이거든요. 그래서 VPN을 켜면 데이터가 가는 길(경로)이 보통 한 번 꺾입니다. 이 “꺾이는 지점”이 성능도, 보안도, 장애 포인트도 같이 바꿔놔요.
오늘은 “VPN 전후 데이터 경로”를 눈앞에 그려보듯 비교해볼게요. 기술 용어는 최대한 생활 비유로 풀어서 갈게요.
제가 2023년에 한국에서 해외(미국 서부) 리모트 접속 이슈를 트러블슈팅했을 때도, VPN을 켜는 순간 RTT가 대략 30ms대에서 180ms대로 튀면서 “길이 꺾인 만큼 체감이 바뀌는” 걸 딱 보였거든요.
한눈에 보는 트래픽 흐름(ASCII 지도)
1) VPN 안 쓸 때(기본 경로)
내 기기 → 집/회사 공유기 → ISP(통신사) → 인터넷 → 목적지 서비스(웹/앱 서버)
“가장 짧은 길”로 가는 편입니다.
중간에 “VPN 서버”라는 경유지가 없어서 지연(레이턴시)이 단순해요.
대신 공용 인터넷 구간에서 보안은 “HTTPS 같은 앱 단 보안”에 많이 의존합니다(환경마다 다를 수 있어요).
2) VPN 쓸 때(터널 경로)
내 기기 → 집/회사 공유기 → ISP → 인터넷 → VPN 게이트웨이(회사/사업자) → (터널 종료) → 목적지 서비스
여기서 핵심은 “터널(tunnel)”이에요. 터널은 “봉인된 전용 통로처럼 보이게 만드는 캡슐화(패킷을 다른 패킷으로 포장)”인데요, 이 포장/해제 작업이 추가됩니다. 실무에서 이 개념이 중요한 이유는, “VPN이 느리다/안 된다”의 원인이 암호화 자체가 아니라 MTU·단편화·경유지 같은 경로 변수에서 터지는 경우가 꽤 많기 때문이거든요. 한국멀티미디어학회 논문 자료는 L2TP, PPTP, IPSec, IPSec/L2TP 등 방식별로 트래픽 부하를 측정·분석했다고 정리돼 있는데, 결론적으로 “VPN 방식에 따라 오버헤드(추가 부담)가 달라질 수 있다”는 점을 시사해요(한국멀티미디어학회 자료 1에 따르면).
비교 기준: “경로”, “지연”, “보이는 것(가시성)”, “장애 포인트”
VPN 전후를 판단할 때, 저는 아래 4가지를 기준으로 많이 봅니다.
1) 경로가 얼마나 꺾이느냐(어디를 경유하느냐)
2) 지연/손실이 어디서 생기느냐(집 와이파이 vs VPN 구간 vs 목적지)
3) 운영/관제 입장에서 뭐가 보이느냐(로그/모니터링)
4) 장애가 났을 때 범인이 누구냐(내 PC? 공유기? VPN? 서비스?)
이 기준으로 들어가면, “VPN이 무조건 느리다/무조건 안전하다” 같은 단정에서 벗어나서 훨씬 현실적인 판단이 됩니다.
비교 항목별로 뜯어보기: 어디서 무엇이 달라지나
1) 지연(레이턴시)과 손실(패킷 로스): “길이 늘어나면 변수도 늘어요”
VPN을 켜면 경유지가 추가되니까, 지연이 늘 가능성이 생깁니다. 게다가 “VPN 터널 안에서의 손실”이라는 새로운 변수가 생겨요.
ThousandEyes는 엔드포인트 에이전트 측정으로 “VPN 터널 노드 포함, 모든 구간의 패킷 손실과 지연을 시각적으로 보여주고”, VPN 손실 스파이크가 앱 성공 지표(페이지 성공률) 하락과 상관관계를 보일 수 있다고 설명합니다(자료 4에 따르면). 쉽게 말해 “사이트가 느린데, 서버 탓인지 VPN 탓인지”를 구간별로 나눠 보면 범인이 드러날 때가 많다는 거죠.
VPN 전: 보통 “내 와이파이/통신사/목적지” 3자 구도
VPN 후: “내 와이파이/통신사/VPN 게이트웨이/목적지” 4자 구도(+ 터널 내부 이슈)
2) 트래픽 부하(오버헤드): “포장지 무게도 택배비예요”
VPN은 트래픽을 암호화하고(잠금), 캡슐화하고(포장) 다시 풀어요(언박싱). 이 과정에서 CPU 사용량, 패킷 크기 증가, 처리 지연 같은 오버헤드가 생길 수 있습니다.
앞서 언급한 한국멀티미디어학회 자료는 L2TP, PPTP, IPSec, IPSec/L2TP 조합 등 “기술별 트래픽 부하 측정”을 다루고 있어요(자료 1에 따르면). 여기서 독자가 가져갈 포인트는 하나입니다: “VPN도 종류/구성에 따라 부담이 다르고, 특히 조합형은 구조가 복잡해질 수 있다.” 성능이 애매하면 “VPN을 켰기 때문”이 아니라 “어떤 방식으로, 어떤 경로로, 어떤 장비가 처리하느냐”가 더 큰 원인일 수 있어요.
3) 경로 시각화의 의미: “지도 앱이 있어야 길 막힌 데를 피해가죠”
VPN 문제는 짜증 포인트가 딱 하나예요. 체감은 “그냥 느림”인데, 원인은 여러 구간 중 하나라는 겁니다.
ThousandEyes의 VPN 모니터링 소개는 네트워크 경로를 시각화해서 “서브옵티멀(비효율)한 VPN 게이트웨이나 스플릿 터널 구성 문제”를 진단하는 데 도움이 된다고 말합니다(자료 5에 따르면). 결국 시각화는 “감”이 아니라 “구간별 증거”를 주는 도구예요.
참고로 IETF RFC 4301(IPsec 아키텍처)에서도 보안 통신은 ‘보호되는 경로(보안 연관/정책)’를 어떻게 잡느냐가 핵심으로 다뤄지는데, 여기서 말하는 요지가 결국 “암호화만 보지 말고 경로/정책까지 같이 보라”는 쪽이랑 통하거든요.
VPN 게이트웨이가 멀리 있으면: 경로 자체가 길어져 지연 증가
스플릿 터널이 꼬이면: 어떤 트래픽은 VPN, 어떤 트래픽은 직통으로 나가서 “되는 건 되고 안 되는 건 안 되는” 이상한 현상도 가능(환경마다 다를 수 있어요)
“VPN 전후”를 제대로 비교하는 체크리스트(일반인용)
1) 목적지가 어디냐
회사 내부 시스템이면 VPN 경유가 “필요”한 경우가 많고
일반 웹서비스면 VPN이 “불필요한 경유”가 될 수도 있어요(정책에 따라 다름)
2) 느린 게 “항상”이냐 “특정 시간대”냐
특정 시간대만 느리면 VPN 게이트웨이 과부하/회선 혼잡 같은 가능성도 봐야 합니다.
3) 구간을 나눠서 봤냐
로컬(와이파이) 문제인지
VPN 터널 문제인지
목적지 서비스 문제인지
이걸 나누면 해결 속도가 확 올라가요.
이런 관점은 “VPN 트래픽을 SIEM으로 수집·탐지·시각화하면 보안 관제 환경을 만들기 쉽다”는 이글루코퍼레이션 글의 방향성과도 맞닿아 있습니다(자료 3에 따르면). 보안도 결국 “보이는 만큼 지킨다” 쪽이거든요.
어떤 상황에 VPN이 더 유리하고, 어떤 상황엔 손해일까?
VPN이 유리한 쪽
회사 자원(내부망, 사내 시스템)에 접근해야 하는 경우
공용망에서 통신을 보호해야 하는 정책/요구가 있는 경우
“누가/어디서/어떤 접속을 했는지” 관제까지 묶어서 운영해야 하는 경우
VPN이 손해가 될 수 있는 쪽
목적지가 원래 인터넷에 잘 열려 있고, 굳이 우회할 이유가 없는데도 전부 터널로 태우는 경우(풀 터널)
VPN 게이트웨이가 지리적으로 너무 멀거나, 동시 접속이 많아 병목이 생기는 경우
트래픽이 큰 작업(대용량 업/다운, 실시간 게임 등)에서 오버헤드가 체감되는 경우
참고로 게임용 VPN 같은 서비스도 있는데, 체감은 사용자 환경/라우팅에 따라 갈립니다(나무위키 자료 2에 따르면). 이런 건 “된다/안 된다”가 아니라 “내 경로에서 이득이 있냐” 게임이더라고요.
결론: VPN은 “보안 스위치”가 아니라 “경로 변경 스위치”예요
다만, 이 글에서 말하는 “VPN 전/후 경로 차이”는 일반적인 원리 설명에 가깝고, 실제로는 회사 정책(풀 터널/스플릿 터널), VPN 종류, 게이트웨이 위치, 회선 품질에 따라 결과가 꽤 다를 수 있으니 내 환경 기준으로 보셔야 합니다.
VPN을 켜면 데이터가 안전해지는 면도 있지만, 동시에 “경로가 바뀐다”는 사실이 제일 큽니다. 경로가 바뀌면 지연·손실·장애 포인트·관제 방식이 같이 바뀌고요. 그래서 VPN 전후 비교의 핵심은 “내 트래픽이 어디를 경유하는지”를 시각화해서 구간별로 보는 겁니다.
정리하면,
VPN 전: 단순하고 짧은 길, 문제도 비교적 단순
VPN 후: 경유지 추가로 변수 증가, 대신 정책/보안/관제에 유리
원하시면 “집-PC-회사 VPN-사내 시스템” 같은 실제 시나리오를 하나 정해주시면, 그 케이스 기준으로 트래픽 경로를 더 촘촘하게(풀 터널/스플릿 터널 포함) 그려드릴게요.