지금 서비스에서 외국에서 하면 느리거나, 심지어는 안되는 경우도 있다고 해서 확인중이다.
허허... 왜그럴까?
일단 직접 외국을 가서 테스트는 힘드니까 vpn으로 테스트해보니까
느리거나, 안되는 경우가 생겼다.
vpn 말로만 하고 틀기만했지, 동작원리를 좀 알아보자.
실제 물리적 네트워크 흐름
1. 일반적인 5G 연결 (VPN OFF)
- 핸드폰 ➡️ SKT 망(기지국/라우터) ➡️ 목적지 서버(예: 구글)
- SKT는 패킷의 헤더를 보고 "아, 이 트래픽은 구글 IP로 가는구나" 하고 최단 경로로 길을 찾아줌
2. VPN 연결 시 (VPN ON)
- 핸드폰 ➡️ SKT 망 ➡️ VPN 서버 ➡️ 목적지 서버
VPN은 본질적으로 네트워크 단에 구축된 '암호화된 프록시 서버'임.
핸드폰에서 VPN 앱을 켜면 기기의 라우팅 테이블이 변경됩니다.
원래는 목적지 IP(구글)로 바로 날아가야 할 원본 패킷을 통째로 암호화한 뒤, 그 겉을 VPN 서버 IP가 적힌 새로운 헤더로 한 번 더 감싸버립니다(터널링/캡슐화).
- 핸드폰의 역할: 데이터를 암호화하고, 겉포장지의 최종 목적지를 'VPN 서버 IP'로 적어서 SKT 망으로 던집니다.
- SKT(통신사)의 역할: L3 스위치/라우터 인프라인 SKT 망은 패킷의 내용물을 읽을 수 없습니다(암호화되어 있으므로). 겉포장지에 적힌 대로 패킷을 VPN 서버까지만 성실하게 배달해 줍니다. 즉, SKT 입장에서는 사용자가 구글에 가는지 유튜브에 가는지 알 수 없고, 오직 "VPN 서버와 알 수 없는 데이터를 주고받는다"고만 인식합니다.
- VPN 서버의 역할: SKT 망을 타고 도착한 패킷의 암호를 풉니다. 내용물을 확인해 보니 "아, 원래 구글로 가려던 요청이구나!" 하고 파악한 뒤, 핸드폰을 대신하여 VPN 서버 자신의 IP로 구글에 요청을 보냅니다. 구글의 응답을 받으면 다시 암호화해서 SKT 망을 거쳐 핸드폰으로 쏴줍니다.
다시 보는 "왜 5G 속도가 안 나오나?"
- Hop(거쳐가는 노드) 추가로 인한 Latency 증가: 클라이언트와 타겟 서버 사이에 Proxy 서버(VPN)가 물리적으로 한 대 더 끼어든 구조입니다. 만약 일본이나 미국에 있는 VPN 서버를 잡았다면, 한국에 있는 서버를 접속할 때도 패킷이 무조건 바다를 건너갔다 와야 하므로 RTT(Round Trip Time)가 급증합니다.
- 암/복호화 연산 오버헤드: 클라이언트(핸드폰)와 프록시(VPN 서버) 양단에서 실시간으로 모든 패킷을 암호화하고 복호화하는 컴퓨팅 리소스 및 시간 비용이 추가됩니다.
- 병목 현상 (Bottleneck): 핸드폰과 SKT 기지국 사이의 구간이 아무리 5G 대역폭(예: 500Mbps)으로 넓게 뚫려 있더라도, 중간에 낀 VPN 서버의 네트워크 회선 처리량(Throughput)이 50Mbps라면 전체 응답 속도는 결국 50Mbps로 하향 평준화됩니다.
결론적으로, SKT라는 물리적인 5G 도로는 그대로 타되 목적지로 직행하지 않고 'VPN 서버라는 경유지'를 강제로 들르도록 네트워크 경로를 우회하는 기술이기 때문에 원래의 5G 최고 속도를 낼 수는 없음.
안되는 이유? WAF일수도
'TIL' 카테고리의 다른 글
| kubectl apply 내부 동작 원리 (feat. create랑 섞어 쓰면 안 되는 이유) (0) | 2026.05.07 |
|---|---|
| SSL 인증서 파일 정리 (.crt, .pem, .key, fullchain.pem 차이) (0) | 2026.05.06 |
| kubectl namespace에 대해서 알아야 할 것. (0) | 2026.05.04 |
| Kubernetes Service가 없으면 어떻게 될까? (0) | 2026.05.03 |
| Pods 개념 정리 ( CKA 대비) (0) | 2026.04.28 |