VPN 속도 측정 어떻게 해야 정확할까? 2026 실측 방법과 도구 추천
광고 페이지에 적힌 속도 수치는 그대로 참고할 수 없습니다. 이 글에서는 직접 측정하는 방법을 정리합니다. 어떤 도구를 쓰고, 어느 시간대에 재고, 어떤 지표를 봐야 하는지, 그리고 보기 좋게 다듬어진 측정 스크린샷을 가려내는 방법까지 다룹니다.
광고 페이지의 측정값을 그대로 믿으면 안 되는 이유
VPN 속도 측정을 정확하게 하려면 결론부터 말해야 합니다. 한 번의 측정 결과는 '국내 회선 → 국내 인터넷 백본 → 해외 구간 → 해외 데이터센터 → 측정 서버'로 이어지는 경로에서 가장 느린 구간의 성능입니다. 광고에 적힌 숫자는 보통 특정 날짜, 특정 노선, 특정 측정 서버에서 나온 결과일 뿐이며, 서버만 바꿔도 숫자가 자릿수 단위로 달라질 수 있습니다.
가장 흔한 변수는 측정 서버의 위치입니다. 속도 측정 앱은 기본적으로 지연이 가장 낮은 서버를 고르는데, 같은 도시에 있는 서버가 선택되면 국내 회선 속도만 재는 셈이 되고 해외 구간은 전혀 반영되지 않습니다. 노선을 비교하려면 측정 서버를 목표 지역으로 직접 고정해야 합니다.
두 번째 변수는 단위입니다. 속도 측정 도구는 Mbps(메가비트/초)를 쓰고, 다운로드 도구는 MB/s(메가바이트/초)를 쓰는데 두 값은 8배 차이가 납니다. 100 Mbps는 약 12.5 MB/s입니다. 스크린샷에 100 MB/s가 찍혀 있다면 800 Mbps라는 뜻이니, 먼저 환산한 뒤 내 회선 범위에 들어오는 값인지 따져보세요.
'Mbps'와 'MB/s'는 알파벳 한 글자 차이지만 숫자는 8배 차이입니다. 유난히 좋아 보이는 스크린샷을 봤다면 단위부터 확인하고 나눗셈을 한 번 해보세요.
- 8× 1 MB/s와 Mbps 사이의 환산 배수, 스크린샷 숫자를 부풀릴 때 가장 많이 쓰이는 수법
- 3회 같은 시간대 최소 반복 횟수, 최고값이 아니라 중앙값을 사용
- 3구간 낮 시간, 저녁 피크, 심야까지 최소 세 시간대를 커버
- 20–23 베이징 시간 기준 저녁 피크 시간대, 해외 구간 속도 저하가 가장 몰리는 구간
속도 측정 전에 고정해야 할 다섯 가지 변수
속도 측정은 웹페이지를 열고 버튼 한 번 누르는 일이 아니라, 조건을 통제한 비교 실험입니다. 아래 다섯 변수 중 하나라도 달라지면 앞뒤 측정값을 그대로 비교할 수 없습니다.
- 기기와 접속 방식 —— 같은 기기, 같은 브라우저를 사용하고, 유선 연결이 가능하면 Wi-Fi 대신 랜선을 쓰세요. Wi-Fi를 쓸 때는 신호 세기를 먼저 확인해야 합니다. 그렇지 않으면 기기와 공유기 사이의 거리를 재는 셈이 됩니다.
- 클라이언트와 프로토콜 —— Shadowsocks, VMess, Trojan, VLESS의 일반적인 구성은 TCP로 전송되기 때문에 패킷 손실이 생기면 혼잡 제어의 영향을 받아 속도가 눈에 띄게 떨어집니다. Hysteria2, TUIC는 QUIC/UDP 기반이라 손실이 많은 구간에서도 처리량을 더 잘 유지하지만, 통신사의 UDP 정책에 더 민감합니다. 숫자를 비교할 때는 프로토콜을 반드시 동일하게 맞춰야 합니다.
- 분할 모드 —— 전역 모드와 규칙 모드는 트래픽 경로가 완전히 다를 수 있습니다. 규칙 모드에서는 측정 서버 도메인이 직결 규칙에 걸릴 수 있고, 그러면 실제로는 국내 회선 속도를 재는 셈이 됩니다.
- 측정 서버 —— 같은 도시, 같은 통신사의 서버로 고정하세요. 서버를 바꾸는 것은 자를 바꾸는 것과 같습니다.
- 시간대 —— 최소한 낮 시간, 저녁 피크, 심야 세 구간을 커버하고 며칠 연속으로 기록하세요. 상태가 가장 좋은 순간만 골라서는 안 됩니다.
측정 전에 내 IP 페이지를 열어 접속 IP가 목표 지역인지 확인하세요. 여전히 국내 IP로 표시된다면 트래픽이 직결로 나가고 있다는 뜻이므로, 이후 숫자는 노선과 무관합니다.
어떤 도구로 측정할까: 브라우저, 명령줄, 클라이언트 내장 기능
도구에 절대적인 좋고 나쁨은 없습니다. 중요한 것은 각 도구가 무엇을 측정하는지 아는 것입니다. 대역폭, 지연, 패킷 손실은 서로 다른 세 가지 문제이고, 세 가지를 동시에 정확히 재는 도구는 드뭅니다.
| 도구 | 유형 | 주로 확인하는 항목 | 주의할 점 |
|---|---|---|---|
| Speedtest(Ookla) 웹 버전 / 데스크톱 앱 | 멀티스레드 대역폭 | 다운로드, 업로드, 지연, 지터 | 기본적으로 가장 가까운 서버를 자동 선택하므로 목표 지역을 직접 지정해야 함 |
| fast.com | 멀티스레드 대역폭 | 다운로드 대역폭, 업로드로 전환 가능 | 노드는 Netflix가 지정하며 변경할 수 없음, 영상 시청 시나리오 참고용으로 적합 |
| Cloudflare Speed Test | 지연과 대역폭 | 유휴 시 지연과 부하 시 지연, 지터, 패킷 손실, 업/다운로드 | 대역폭을 꽉 채웠을 때 지연이 어떻게 변하는지 볼 수 있음, 단순한 최고값이 아님 |
| iperf3 | 순수 처리량 | 자체 구축한 서버와 클라이언트 사이의 업/다운로드 | 해외 서버를 직접 준비해야 하며, 결과가 서버 위치에 크게 좌우됨 |
| mtr / WinMTR | 경로 품질 | 홉별 지연과 패킷 손실 | 대역폭은 측정하지 않고 경로만 보며, 어느 홉부터 나빠지는지 찾는 데 사용 |
| curl / 브라우저 다운로드 | 단일 연결 실측 | 단일 HTTPS 연결의 실제 처리량과 첫 바이트 시간 | 웹페이지를 열거나 파일 하나를 받을 때의 체감에 가장 가까움 |
또한 여러 클라이언트에 내장된 '속도 측정' 버튼은 노드에 핸드셰이크 한 번이나 HTTP 요청 한 번만 보내는 경우가 많아, 재는 값이 대역폭이 아니라 지연입니다. 노드를 1차로 걸러내는 용도로는 쓸 수 있지만, 속도 결론으로 삼아서는 안 됩니다.
어떤 지표를 볼까: 지연, 지터, 패킷 손실과 단일 스레드 대역폭
대역폭 숫자는 가장 보기 쉽고, 가장 쉽게 오해를 부릅니다. 체감에 미치는 영향 순으로 정렬하면 패킷 손실, 지터, 지연이고, 대역폭 상한은 그다음입니다.
- 지연(RTT): 데이터가 한 번 왕복하는 데 걸리는 밀리초 단위 시간으로, 클릭 후 반응 속도를 결정합니다. 값이 낮고 변동 폭이 작아야 좋습니다.
- 지터(jitter): 연속 측정한 지연 값의 변동 폭입니다. 지터가 큰 노선은 대역폭이 아무리 높아도 화상 회의와 실시간 대전 게임이 끊깁니다.
- 패킷 손실: 해외 구간에서 체감을 가장 크게 망치는 항목입니다. TCP 계열 프로토콜은 패킷 손실이 생기면 속도를 낮춰 재전송하므로 대역폭 숫자도 함께 떨어지고, UDP 계열 프로토콜은 재전송하지 않는 대신 화면이 깨지고 소리가 끊깁니다.
- 다운로드 대역폭: 다운로드와 영상 재생의 상한을 결정합니다.
- 업로드 대역폭: 보통 다운로드보다 낮으며, 라이브 방송 송출, 클라우드 동기화, 클라우드 저장에 더 크게 좌우됩니다.
- 첫 바이트 시간(TTFB): 요청을 보낸 뒤 첫 바이트를 받을 때까지의 시간으로, 지연과 DNS 조회의 영향을 함께 받습니다.
단일 스레드와 멀티스레드도 구분해야 합니다. 멀티스레드 측정은 여러 연결의 결과를 합산하기 때문에 대역폭 상한까지 나올 수 있지만, 연결 하나가 나빠지는 문제는 가려버립니다. 단일 스레드는 영상 버퍼링이나 파일 하나를 내려받을 때의 체감에 더 가깝습니다. 두 숫자를 모두 기록하고, 차이가 클수록 그 노선이 동시 연결에 더 의존한다는 뜻입니다.
# 단일 연결 실측: 실제 처리량과 첫 바이트 시간 확인(Cloudflare 측정 엔드포인트)
curl -o /dev/null -s -w 'dns %{time_namelookup}s | connect %{time_connect}s | ttfb %{time_starttransfer}s | speed %{speed_download} B/s\n' \
'https://speed.cloudflare.com/__down?bytes=100000000'
# 경로 품질: 프로브 패킷 50개를 연속 전송해 홉별 지연과 패킷 손실 확인
mtr -rwzc 50 1.1.1.1측정할 때마다 여섯 개 열을 기록하세요: 시간, 노선과 지역, 프로토콜, 지연, 지터, 단일 스레드 다운로드. 멀티스레드 결과는 별도 열에 적고, 단일 스레드 숫자와 서로 비교하지 마세요.
시간대별·날짜별 기록: 재현 가능한 측정 절차
아래 절차는 별도 도구가 필요 없습니다. 기기 한 대와 표 한 장이면 끝납니다. 이 절차가 재는 것은 '최고로 얼마까지 나오는가'가 아니라 '이 노선이 어느 시간대에 얼마나 흔들리면서 어느 정도의 대역폭을 제공하는가'입니다.
- 노선을 끊고 먼저 기준선을 측정합니다. 같은 기기, 같은 측정 서버로 국내 회선의 지연과 다운로드를 기록하세요.
- 노선에 연결하고 클라이언트를 전역 모드로 전환하거나, 분할 규칙이 측정 서버 도메인을 포함하는지 확인합니다.
- IP 조회 페이지를 열어 접속 IP가 목표 지역으로 바뀌었는지 확인합니다.
- 같은 측정 서버로 3회 연속 측정하고, 매번 지연, 지터, 다운로드, 업로드를 기록합니다.
- curl이나 브라우저 다운로드로 단일 스레드 테스트를 한 번 하고, 실제 처리량과 첫 바이트 시간을 기록합니다.
- mtr로 프로브 패킷 50개를 보내 어느 홉부터 패킷 손실이 나타나는지 확인합니다.
- 다음 시간대로 옮겨 2~6단계를 반복하고, 최소한 낮 시간, 저녁 피크, 심야 세 구간을 커버합니다.
- 며칠 연속 기록한 뒤에는 가장 잘 나온 한 번이 아니라 시간대별 중앙값과 변동 범위를 비교하세요.
보기 좋게 다듬어진 속도 측정 스크린샷을 가려내는 방법
먼저 노선 유형부터 구분하기
직결, 중계, IEPL 전용선은 경로가 완전히 다르기 때문에 숫자를 나란히 놓고 비교하는 것은 의미가 없습니다.
- 직결: 클라이언트가 해외 데이터센터에 바로 연결되어 전 구간이 공용 인터넷을 지납니다. 비용이 낮은 대신, 저녁 피크에 국제 구간 혼잡의 영향을 가장 크게 받습니다.
- 중계: 먼저 국내 중계 서버에 연결한 뒤 중계 서버에서 해외로 나갑니다. 경로를 통제할 수 있고 홉 수가 적어 보통 직결보다 안정적이지만, 중계 노드 자체가 병목이 될 수 있습니다.
- IEPL 전용선: 종단 간 국제 이더넷 전용선으로, 공용 인터넷 국제 구간을 거치지 않아 지연과 지터가 더 안정적이며 비용도 더 높습니다.
스크린샷 자체 점검 목록
- ✅ 스크린샷에 측정 서버의 도시와 통신사, 그리고 측정 시각이 보인다.
- ✅ 단위가 Mbps인지 MB/s인지 명확히 표기되어 있고 앞뒤가 일치한다.
- ✅ 지연, 지터, 패킷 손실, 대역폭이 함께 제시되어 있고 다운로드 숫자 하나만 있지 않다.
- ✅ 단일 스레드와 멀티스레드 결과가 따로 표시되어 있고 어느 노선을 측정했는지 명시되어 있다.
- ❌ 최고값이 나온 한 번만 잘라내고 서버, 시각, 단위를 표시하지 않는다.
- ❌ 숫자가 Mbps와 MB/s 사이를 오가며 커 보이게 만든다.
- ❌ 같은 도시의 측정 서버나 내부망 iperf3 결과로 해외 구간 속도를 가장한다.
- ❌ 프로토콜과 노선 유형을 밝히지 않고 직결, 중계, IEPL 전용선 결과를 한 장의 이미지에 섞어 비교한다.
흔한 오해와 결론
- 숫자가 클수록 좋다 —— 대역폭은 상한만 결정하고, 지연과 패킷 손실이 하한을 결정합니다.
- 한 번 재면 결론이 난다 —— 해외 구간 상태는 시간대에 따라 변하므로, 한 번의 결과로는 안정성을 알 수 없습니다.
- 같은 클라이언트 안의 모든 노선은 속도가 같다 —— 지역과 노선 유형에 따라 경로가 완전히 다르므로 각각 측정해야 합니다.
- 지연이 낮으면 빠르다 —— 대역폭이 부족하면 지연이 낮아도 텍스트 메시지 정도만 주고받을 수 있고, 영상은 여전히 버퍼링이 걸립니다.
- 속도 측정 앱의 숫자 하나만 본다 —— 웹페이지가 느리게 열리거나 영상이 버퍼링되는 원인은 DNS 조회나 단일 연결 품질인 경우가 많고, 집계 대역폭 측정 결과에는 잘 드러나지 않습니다.
처음 질문으로 돌아가 봅시다. 정확한 속도 측정의 본질은 변수를 고정한 뒤 반복해서 비교하는 것입니다. 기기, 프로토콜, 분할 모드, 측정 서버를 먼저 고정하고, 시간대별로 지연, 지터, 패킷 손실, 단일 스레드 대역폭을 기록한 다음, 가장 잘 나온 한 번이 아니라 중앙값과 변동 범위를 비교하세요. 그렇게 얻은 숫자라야 한 노선을 장기간 쓸 만한지 판단하는 근거가 됩니다.