VPN 속도 측정 방법: 도구와 시간대, 지표로 직접 확인하기

VPN 속도 측정에서 결론을 좌우하는 것은 속도 측정 사이트의 화면이 아니라, 어느 구간을, 어느 시간대에, 몇 번 반복해 측정했는지입니다. 같은 기기, 같은 구독이라도 측정 노드를 바꾸거나 한 시간만 달라져도 결과는 몇 배씩 차이 납니다. 회선이 거짓말을 하는 것이 아니라, 두 측정이 애초에 같은 질문에 답한 것이 아니기 때문입니다. 아래에서는 측정을 세 계층과 네 가지 지표, 그리고 반복 실행할 수 있는 절차로 나눠 서로 다른 회선을 의미 있게 비교하는 방법을 정리합니다.

먼저 기준을 정합니다: 네 가지 지표의 역할

일상에서 말하는 “인터넷이 느리다”는 적어도 네 가지 서로 다른 값에 해당합니다. 지연 시간, 지터, 패킷 손실은 회선 품질에 속하고 처리량은 전송 결과에 속합니다. 네 지표 중 하나만 나빠져도 체감은 “버벅임”으로 나타날 수 있지만 대응 방법은 전혀 다릅니다. 패킷 손실은 회선을 바꿔야 하고, 지터는 혼잡 시간대를 피해야 하며, 처리량이 안 나오는 것은 단일 스레드 문제일 뿐 회선 품질과 무관할 수 있습니다.

대역폭과 처리량은 같은 말이 아닙니다. 대역폭은 회선이 표기상 보장하는 상한이고, 처리량은 단말에서 실제로 받은 양입니다. 그 사이에는 프로토콜 오버헤드, 서버 측 속도 제한, 단일 연결의 윈도 크기 제한, 같은 회선을 쓰는 다른 사용자의 점유가 있습니다. 따라서 Mbps라는 단위를 볼 때는 그것이 대역폭인지 처리량인지 먼저 확인하고, 비교 근거로 삼을지 결정해야 합니다.

도구: 세 계층으로 나눠 측정하고 웹 점수 하나로 결론 내지 않기

측정을 세 계층으로 나누고 각 계층에 맞는 도구를 쓰면 결론이 단단해집니다. 계층을 섞어 쓰면 숫자끼리 서로 어긋납니다.

웹 속도 측정 사이트는 대부분 멀티스레드 HTTP로 돌아가므로 회선의 상한을 보는 데 적합합니다. 다만 기본값이 가까운 노드를 고르기 때문에 그 숫자는 “가장 가까운 측정 서버까지 얼마나 빠른가”를 뜻할 뿐 “내가 쓰려는 서비스까지 얼마나 빠른가”를 뜻하지는 않습니다. 두 숫자는 동시에 성립할 수 있고, 하나는 높고 하나는 낮아도 어느 쪽도 틀린 말이 아닙니다.

iperf3는 지점 간 검증에 적합합니다. 동시 연결 수와 테스트 시간을 지정할 수 있어 브라우저와 속도 측정 사이트의 간섭을 배제할 수 있지만, 양쪽 모두 통제 가능한 노드가 있어야 합니다. 일상적인 자가 점검에는 멀티스레드 속도 측정 사이트로 상한을, 단일 스레드 다운로드로 하한을 확인하고 두 숫자를 모두 기록하는 편이 더 현실적입니다.

시간대와 횟수: 두 측정을 비교 가능하게 만들기

한 번의 측정은 표본 하나일 뿐입니다. 국제 회선 부하는 뚜렷한 시간대 패턴을 보이며, 저녁 피크와 새벽의 차이는 두 회선 사이의 차이보다 큰 경우가 많습니다. 그래서 시간대를 넘나드는 비교는 추세를 봐야 하고, 같은 시간대 안에서의 가로 비교만이 순위를 매길 수 있습니다.

• 피크 시간대와 한가한 시간대에 각각 한 라운드씩 측정하고, 두 시간대의 중앙값을 따로 기록합니다.
• 같은 회선을 세 번 연속 측정해 최댓값이 아니라 중앙값을 씁니다.
• 매번 기록: 날짜, 회선 이름, 프로토콜, 클라이언트 버전, 단일 스레드인지 멀티스레드인지.
• 회선을 바꿀 때는 변수를 하나만 바꾸고, 기기·클라이언트·측정 노드는 그대로 유지합니다.
• 측정 전에 구독을 먼저 갱신하고 노드 목록이 바뀌지 않았는지 확인합니다.

지표 읽는 법: 숫자에서 결론까지

숫자 묶음을 얻었다면 정해진 순서로 읽는 편이 감으로 판단하는 것보다 훨씬 믿을 만합니다.

1. 먼저 패킷 손실을 봅니다. 손실이 계속 0이 아니라면 회선을 바꾸는 것이 우선이며, 클라이언트 설정을 만지작거려도 해결되지 않습니다. MTU를 조정해도 되살릴 수 없습니다.
2. 다음은 지터입니다. 지터가 지연 시간 자체에 가까울 정도라면 링크에 대기가 쌓이고 있다는 뜻으로, 보통 중계 구간 혼잡이나 공유 대역폭 포화가 원인입니다.
3. 그다음 처리량입니다. 지연도 정상이고 지터도 작은데 처리량이 안 나온다면 대개 단일 스레드 제한, 서버 측 속도 제한, 프로토콜 오버헤드 때문입니다.
4. 마지막은 체감입니다. 첫 바이트 시간, 영상 재생 시작, 게임 내 조작 반응은 앞의 세 항목이 합쳐진 결과이며, 장기적으로 추적할 가치가 있는 유일한 지표입니다.

지연이 큰 회선에는 놓치기 쉬운 메커니즘이 하나 더 있습니다. 단일 TCP 연결의 처리량은 대역폭-지연 곱의 제약을 받습니다. 지연이 높을수록 단일 연결로 높은 대역폭을 채우기 어렵고, 여러 개의 동시 연결이 있어야 포화됩니다. 따라서 “멀티스레드는 꽉 차는데 단일 스레드는 안 나온다”는 정상적인 현상이며, 회선 문제라고 단정할 수 없습니다.

프로토콜과 회선 유형이 결과를 바꿉니다

프로토콜 차이는 주로 두 곳에서 나옵니다

첫째는 전송 계층 선택입니다. Shadowsocks, VMess, VLESS, Trojan은 본체가 TCP를 타면서 UDP도 포워딩할 수 있고, Hysteria2와 TUIC는 QUIC 기반으로 UDP를 씁니다. 손실이 뚜렷한 회선에서는 QUIC 계열의 혼잡 제어가 더 공격적이어서 회복이 빠르지만, 네트워크가 UDP를 속도 제한하거나 차단하면 반대로 성능이 나빠집니다. 이 지점은 자가 점검에서 “프로토콜이 별로다”라고 오판하기 쉽습니다.

둘째는 핸드셰이크와 오버헤드입니다. VMess는 타임스탬프 검증이 있어 기기 시간이 크게 어긋나면 핸드셰이크가 그대로 실패합니다. VLESS는 자체적으로 상태가 없고 XTLS와 결합하면 TLS 암복호화를 한 번 줄여 고대역폭에서 CPU 사용이 낮습니다. Trojan은 표준 TLS에 의존해 트래픽 형태가 일반 HTTPS에 가깝습니다. 이런 차이는 저대역폭에서는 거의 측정되지 않고, 대역폭-지연 곱이 큰 구간에서만 드러납니다.

회선 유형: 직결, 중계, IEPL 전용선

• 직결. 단말이 곧바로 출구에 연결되며, 지연은 국제 출구의 혼잡도에 따라 달라지고 저녁 피크에 변동이 가장 큽니다.
• 중계. 중계 노드에 먼저 접속한 뒤 출구로 포워딩하며, 중계 구간의 대역폭을 단독으로 쓰는지가 피크 시간대 성능을 좌우합니다.
• IEPL 전용선. 지점 간 전용 링크로 공용 인터넷 국제 출구를 거치지 않아 지연과 패킷 손실이 가장 안정적이며, 비용도 가장 높습니다.

그래서 같은 “지역”의 노드라도 회선 유형이 다르면 측정 곡선이 완전히 달라질 수 있습니다. 비교할 때 회선 유형을 기록에 남기지 않으면 데이터를 재사용할 수 없고, 다음 주에 처음부터 다시 측정해야 합니다.

지역별로 회선을 바꿔 볼 때 참고할 수 있는 사실: 100+ 개국, 250+ 회선 커버리지, 구독은 동시 접속 기기 수 제한 없음, 기기를 바꿔 재측정할 때 재설정이 필요 없음, 30일 무조건 환불이라 측정 후 맞지 않으면 그대로 환불받을 수 있습니다.

오판 배제: 자주 나오는 간섭 요인

측정 결과가 어긋나는 이유는 대개 회선이 아니라 아래 몇 가지를 깔끔하게 처리하지 못했기 때문입니다.

• ✅ 측정 전에 구독을 갱신하고 같은 회선을 재는지 확인합니다. 노드 이름이 바뀌거나 IP가 교체되면 이전 결론은 바로 무효가 됩니다.
• ❌ 분할 라우팅 규칙을 켠 채로 측정합니다. 일부 트래픽이 직결로 빠져 결과에 두 경로의 성능이 섞이고, 어느 쪽이 좋은지 구분할 수 없습니다.
• ✅ 도메인 조회 경로를 확인합니다. 조회가 현지 통신사 DNS를 거치면 가까운 CDN 노드를 받아 숫자는 좋아 보여도 출구 품질을 대표하지 못합니다.
• ❌ 영상 한 번 재생으로 처리량을 판단합니다. 캐시에 걸린 뒤에는 재생이 매끄러운 것과 회선 성능이 무관합니다.
• ✅ 같은 클라이언트 안에서 가로 비교합니다. 클라이언트마다 기본 MTU, UDP 포워딩 스위치, 분할 정책이 달라 클라이언트를 넘나드는 숫자 비교는 의미가 없습니다.
• ❌ “가속 배율”, “몇 % 개선”을 지표로 삼습니다. 환산된 숫자는 기준선이 없고 재현도 불가능합니다.

재현 가능한 자가 점검 절차

아래 절차는 순서대로 실행하면 결과를 가로 비교할 수 있고, 일주일 간격으로 다시 측정해 안정성을 확인할 수도 있습니다.

1. 변수 고정. 같은 기기, 같은 클라이언트, 같은 측정 노드를 먼저 정하고 시작합니다.
2. 구독 갱신. 회선 이름과 프로토콜을 적어 두고, 이후 모든 기록은 이 행을 기준으로 삼습니다.
3. 링크 계층 측정. 패킷 20개를 연속으로 보내 지연과 손실을 보고, 홉별 경로로 문제 구간을 찾습니다.
4. 처리량 계층 측정. 멀티스레드 속도 측정 한 번, 단일 스레드 다운로드 한 번, 두 숫자를 따로 기록합니다.
5. 애플리케이션 계층 측정. 실제로 쓰는 서비스를 열어 첫 바이트 시간과 버퍼링 여부를 기록합니다.
6. 다음 회선으로 바꿔 3~5단계를 반복하고, 변수는 그대로 둡니다.
7. 한 줄 기록으로 정리한 뒤 어떤 회선을 남기고 어느 시간대에 무엇을 쓸지 결정합니다.

명령줄은 두 줄이면 충분합니다. Windows에서는 ping을 ping -n 20으로, mtr을 pathping으로 바꾸면 됩니다. 여기서는 공용 조회 서비스를 기준점으로 썼는데, 그쪽 노드는 대개 가까워 지연이 낮습니다. 실제 대상의 링크를 판단하려면 주소를 실제로 접속하는 도메인으로 바꾸되, 같은 비교 묶음 안에서는 대상이 반드시 같아야 합니다.

# 지연과 패킷 손실: 패킷 20개를 연속 전송해 평균 지연과 손실률 확인
ping -c 20 1.1.1.1

# 홉별 경로: 홉마다 패킷 50개로 손실이 어느 구간에서 생기는지 확인
mtr -rwc 50 1.1.1.1

자주 묻는 질문