VPN 속도측정 방법: 직접 객관적으로 측정하는 도구와 시간대

VPN 속도 측정을 제대로 하려면 먼저 한 가지 전제를 받아들여야 합니다. 한 번의 측정은 결론이 아니라 표본일 뿐입니다. 같은 회선이라도 오전과 피크 시간대에 전혀 다른 숫자가 나올 수 있고, 도구를 바꾸거나 측정 서버를 바꾸면 결과가 또 달라집니다. 어떤 회선이 자신의 사용 환경에 맞는지 판단하려면 변수를 고정하고 시간대를 나눠 반복 측정해야 하며, 지연 시간·지터·패킷 손실·처리량 네 가지 지표를 함께 봐야 합니다. 아래 절차는 전문 지식 없이도 시스템 기본 명령과 몇 가지 일반적인 도구만으로 실행할 수 있습니다.

먼저 네 가지 지표를 구분합니다: 지연 시간, 지터, 패킷 손실, 처리량

속도 측정 페이지에서 가장 눈에 띄는 숫자는 처리량일 뿐이고, '왜 영상이 끊기는지'는 알려주지 않습니다. 네 가지 지표는 각자 역할이 다르며, 하나라도 빠지면 잘못 판단할 수 있습니다:

• 지연 시간(RTT): 패킷이 기기에서 대상 서버까지 갔다가 돌아오는 데 걸리는 시간이며 단위는 밀리초입니다. 프록시를 연결하면 이 왕복에는 '기기 → 출구 노드 → 대상' 두 구간이 포함되므로 직결보다 큰 값이 나오는 것이 자연스럽습니다. 그래서 같은 대상, 같은 도구끼리만 가로로 비교해야 합니다.
• 지터: 연속된 여러 패킷 지연 시간의 변동 폭입니다. 영상이 끊기는지, 음성이 끊기는지는 평균 지연 시간보다 지터에 더 크게 좌우됩니다. 평균 지연 시간이 높지 않아도 지터가 크면, 안정적으로 조금 높은 지연 시간보다 체감이 더 나쁩니다.
• 패킷 손실: 보낸 패킷 중 도착하지 않은 비율입니다. 손실이 조금만 생겨도 재전송이 발생해 처리량이 떨어집니다. QUIC 기반 프로토콜은 패킷 손실을 다루는 방식이 TCP와 달라서 나타나는 양상도 다릅니다.
• 처리량: 단위 시간에 실제로 전송된 데이터 양입니다. 단일 스레드와 다중 스레드를 구분해야 합니다. 단일 스레드는 파일 하나를 내려받거나 영상 하나를 재생할 때의 경험에 가깝고, 다중 스레드는 속도 측정 사이트의 점수에 가깝습니다.

측정 전에 변수부터 고정합니다: 기기, 프로토콜, 연결 방식

측정 결과에 가장 쉽게 섞여드는 것은 회선 차이가 아니라 자신의 변수입니다. 같은 노드라도 기기를 바꾸고, 프로토콜을 바꾸고, 무선으로 바꾸면 숫자가 크게 달라질 수 있습니다. 측정 전에 아래 항목을 먼저 고정하세요:

• 기기와 네트워크: 같은 기기, 같은 네트워크를 사용하고 유선을 우선하세요. 무선을 쓸 때는 주파수 대역과 위치를 고정하고 중간에 바꾸지 않습니다.
• 백그라운드 트래픽: 시스템 업데이트, 클라우드 동기화, 클라우드 백업을 끄고 다른 기기의 대용량 작업도 잠시 멈춥니다.
• 프로토콜: Shadowsocks, VMess, VLESS, Trojan은 TCP를 사용하고, Hysteria2, TUIC는 QUIC 기반으로 UDP를 사용합니다. 같은 노드에서도 프로토콜에 따라 성능이 다를 수 있고, 국제 구간에 패킷 손실이 생기면 차이가 더 뚜렷해집니다. 노드를 비교할 때는 노드와 프로토콜을 동시에 바꾸지 마세요.
• 멀티플렉싱(mux): 여러 연결을 하나의 TCP 연결로 재사용하는 방식이라 패킷 손실이 생기면 헤드 오브 라인 블로킹의 영향을 받기 쉬워 단일 스레드 처리량이 낮아집니다. 전부 끄거나 전부 켜고 비교하세요. 섞어서 비교하면 안 됩니다.
• 규칙 모드: 분할 모드에서 측정 대상이 직결 규칙에 걸리면 실제로는 직결 속도를 측정하게 됩니다. 측정 전에 대상이 프록시를 통과하는지 확인하세요.

자주 쓰는 도구와 각각에 맞는 측정 항목

도구는 많을 필요가 없고, 각 지표에 맞는 측정법이 있으면 됩니다. 아래 항목들은 지연 시간부터 처리량까지를 아우르며, 두세 개를 골라 조합하면 충분합니다:

시간대 선택: 피크 시간과 한가한 시간대에 각각 몇 번 측정할까

국제 회선 부하는 시간대에 따라 뚜렷한 특징을 보입니다. 평일 20:00–23:00은 보통 피크 시간대로 국제 구간이 가장 혼잡해 지연 시간이 올라가고 패킷 손실이 나타나기 쉽습니다. 오전 9:00–11:00과 오후 14:00–16:00은 상대적으로 한가해 회선 자체의 상한에 더 가까운 숫자가 나옵니다. 각 시간대마다 최소 3회, 몇 분 간격으로 측정해 중앙값을 구하고, 최소 이틀에 걸쳐 평일과 주말을 각각 한 번씩 측정하세요. 한 번 측정해서 나온 좋은 숫자는 아무것도 설명해 주지 않습니다.

그대로 재사용할 수 있는 속도 측정 절차

측정 전 점검 목록을 먼저 확인한 뒤 순서대로 실행하세요. 전체 측정은 15분 이내로 끝내는 것이 좋습니다. 시간대 경계까지 끌면 안 됩니다:

• ✅ 유선을 사용하거나 5GHz 대역에 고정하고, 측정 내내 위치를 바꾸거나 네트워크를 전환하지 않습니다.
• ✅ 시스템 업데이트, 클라우드 동기화, 클라우드 백업과 진행 중인 다운로드를 모두 끕니다.
• ✅ 전체 측정에서 같은 노드, 같은 프로토콜, 같은 mux 설정만 사용합니다.
• ✅ 규칙 모드와 측정 대상을 확인해 '직결'이 프록시 결과에 섞이지 않게 합니다.
• ❌ 공용 Wi-Fi나 모바일 핫스팟에서 비교하지 마세요. 이런 회선 자체에 추가 제약이 있습니다.
• ❌ 한 번 측정한 최고값을 회선 성능으로 받아들이지 마세요.

1. 기준 측정: 프록시를 연결하지 않고 같은 측정 서버로 한 번 측정해 지연 시간과 처리량을 기록합니다.
2. 노드에 연결한 뒤 100개 패킷을 연속으로 ping하고 지연 시간 범위와 패킷 손실을 기록합니다.
3. mtr(또는 tracert)을 한 번 실행해 국제 구간에서 손실이 지속되는지 확인합니다.
4. 같은 측정 서버로 다중 스레드 처리량을 측정하고, 이어서 단일 스레드 다운로드를 한 번 측정해 두 숫자를 모두 기록합니다.
5. 실제 상황으로 돌아가기: 자주 쓰는 영상이나 클라우드 저장소를 열어 1–2분간 실제로 전송하며 화질이 낮아지는지 확인합니다.
6. 피크 시간대에 2–5단계를 반복하고 두 결과를 나란히 비교합니다.
7. 3일 연속 기록하고 최고값이 아니라 중앙값을 해당 노드의 대표값으로 삼습니다.

# Windows: 패킷 100개 연속 전송
ping -n 100 1.1.1.1

# macOS / Linux: 동일한 패킷 수
ping -c 100 1.1.1.1

# 단일 요청의 소요 시간과 다운로드 속도, 여러 번 반복해 중앙값 사용
curl -o /dev/null -s -w "%{time_total} %{speed_download}\n" https://example.com/file

결과 읽는 법: 단일 최고값에 속지 마세요

숫자가 부풀려지는 흔한 원인 몇 가지입니다. 이런 경우에는 그대로 믿지 말고 기록에 메모해 두세요:

• TCP 슬로 스타트와 버스트: 연결이 막建立된 직후에는 속도가 아직 올라가는 중이라, 측정 시간이 너무 짧으면 상승 구간이나 짧은 버스트 구간만 잡힐 수 있습니다.
• 캐시 적중: 같은 주소를 반복 측정하면 CDN 캐시에 걸릴 수 있습니다. 숫자는 좋아 보이지만 출구 대역폭을 뜻하지는 않습니다.
• 측정 서버 위치: 측정 지점과 노드가 같은 도시, 같은 데이터센터면 데이터센터 내부 속도에 가까운 값이 나옵니다. 실제로 대상 사이트에 접속할 때의 속도가 아닙니다.
• 단일 스레드와 다중 스레드의 차이: 다중 스레드는 잘 나오는데 단일 스레드가 안 나온다면 병목이 단일 연결 스케줄링에 있다는 뜻이며, 대용량 파일을 내려받을 때 가장 쉽게 체감됩니다.

흔한 오해와 노드 교체 판단

자주 간과되는 점이 하나 더 있습니다. 속도 측정 숫자는 정상인데 웹페이지를 열 때 첫 단계가 유난히 느리다면 DNS를 먼저 확인하세요. 일부 클라이언트는 '원격 해석 / 로컬 해석' 옵션을 제공하는데, 로컬 해석을 쓰면 도메인 조회가 로컬 네트워크를 거치면서 첫 접속이 느려질 수 있고, 조회 요청이 터널을 통과하지 않을 수도 있습니다(흔히 말하는 DNS 누출). 이런 문제는 처리량 숫자에 나타나지 않으므로 따로 확인해야 합니다.

아래 상황이 나타나면 한 번의 측정만으로 결론을 내리지 말고 노드 교체를 고려하세요:

• 피크 시간대에 여러 날 연속 패킷 손실이 나타나고 ping과 mtr 모두에서 재현될 때;
• 단일 스레드 처리량이 목표 사용 환경에 필요한 수준보다 오래 낮고, 다중 스레드 처리량은 정상일 때;
• 지터가 뚜렷해 영상 화질이 자주 낮아지고 음성이 끊길 때.