VPN 속도 측정의 핵심은 속도 측정 사이트를 한 번 열어 돌리는 것이 아니라, 측정 조건을 고정해 오늘의 결과와 다음 주의 결과를 같은 표에 넣어 비교할 수 있게 만드는 데 있습니다. 지연 시간, 지터, 패킷 손실, 대역폭은 각각 다른 질문에 답하는 값이고, 야간 피크 시간대의 성능은 평소와 크게 벌어집니다. 아래에서는 어떤 지표를, 어느 시간대에, 몇 번 측정해 어떤 값으로 정리할지, 결과를 어떻게 읽을지, 그리고 각 서비스의 홍보 페이지에 적힌 숫자가 왜 서로 비교할 수 없는지를 순서대로 설명합니다.

속도 측정에서 확인해야 할 지표

「빠르다」는 두루뭉술한 표현이고, 최소한 지연 시간, 지터, 패킷 손실, 대역폭이라는 네 가지로 나눠 각각 측정할 수 있습니다. 이들 사이에는 환산 관계가 없습니다. 지연이 낮은 회선의 대역폭이 아주 작을 수 있고, 대역폭이 크다고 표기된 회선이 야간 피크에는 심하게 흔들릴 수 있습니다. 네 가지를 따로 기록해야 문제가 물리적 거리에서 온 것인지, 링크 혼잡에서 온 것인지, 아니면 로컬 네트워크 자체의 문제인지 판단할 수 있습니다.

지표단위일반적인 측정법해석 시 유의점
지연 시간(RTT)밀리초클라이언트 내장 지연 테스트, TCP 핸드셰이크 소요 시간물리적 거리가 하한을 결정하므로 대륙 간 회선이 같은 도시 회선과 같을 수는 없음
지터밀리초연속 10개 이상 표본 간의 차이중앙값이 좋아도 지터가 크면 통화가 계속 끊김
패킷 손실퍼센트연속 프로브 또는 TCP 재전송 통계패킷 손실을 먼저 보고 지연 시간을 보는 순서를 지킬 것
다운로드 / 업로드 대역폭Mbps단일 스레드와 다중 스레드로 각각 측정결과가 가정용 회선 요금제 상한을 넘을 수 없음
DNS 조회 소요 시간밀리초새 도메인에 처음 접속할 때의 소요 시간조회가 로컬을 거치는지 터널을 거치는지에 따라 결과 차이가 큼
첫 바이트 시간밀리초브라우저 개발자 도구의 네트워크 패널대상 사이트 자체의 영향도 받으므로 전부 회선 탓으로 돌릴 수 없음

ICMP 프로브는 일부 네트워크에서 속도 제한을 받거나 아예 버려집니다. ping이 통하지 않는다고 해서 회선이 끊긴 것은 아닙니다. 연결 여부를 판단할 때는 TCP 핸드셰이크 소요 시간이나 클라이언트 내장 지연 테스트가 더 신뢰할 만하고, 브라우저가 실제로 연결을 맺는 과정에도 더 가깝습니다.

먼저 측정 조건을 고정하기

같은 노드라도 기기, 무선 주파수 대역, 백그라운드 부하가 다르면 실측 결과가 두 배까지 벌어집니다. 속도 측정의 첫 단계는 시작 버튼을 누르는 것이 아니라 변수를 고정하는 일입니다. 그렇지 않으면 이후의 데이터는 참고용일 뿐 근거로 쓸 수 없습니다.

프로토콜도 고정해야 합니다. VMess는 클라이언트와 서버의 시간이 일치해야 하며, 시스템 시간이 어긋나면 단순히 느려지는 것이 아니라 핸드셰이크 자체가 실패합니다. Hysteria2와 TUIC는 QUIC 기반으로 UDP를 사용하므로 패킷 손실이 큰 링크에서는 TCP 계열 프로토콜보다 대체로 안정적이지만, 로컬 네트워크가 UDP를 제한하면 결과가 반대로 나옵니다. 프로토콜을 바꿨다면 반드시 별도 행으로 기록하고, 이전 측정군과 섞어 평균을 내지 마십시오.

시간대 구성: 야간 피크는 별도 행으로

국제 회선의 대역폭은 공유됩니다. 밤 20:00부터 23:00까지는 로컬 통신사의 출구와 해외 방향이 동시에 몰리기 때문에 같은 회선이라도 이 시간대의 실측값이 오전의 절반에 그칠 수 있습니다. 한가한 시간대에만 측정하면 하루 중 가장 좋은 숫자를 얻게 되고, 정작 회선을 써야 하는 시간과는 맞지 않습니다.

4개 시간대: 오전, 오후, 야간 피크, 심야에 각각 한 차례씩 측정
3회 시간대마다 세 번 반복하고 최고값이 아닌 중앙값을 사용
10개 지연 시간은 최소 열 번 연속 표본을 뽑아야 유효한 표본군
1장 모든 시간대를 같은 표에 모아야 가로 비교가 가능

권장 시간대는 오전 10:00을 기준선, 오후 15:00을 두 번째 기준선, 밤 21:00을 야간 피크 표본, 심야 00:30을 대조군으로 삼는 것입니다. 시간대마다 3회씩 측정하고 회차 사이는 2~3분씩 띄운 뒤 중앙값을 사용합니다. 평균은 이상 표본 하나에 쉽게 끌려가고, 최고값은 웹페이지를 열 때의 평소 상태를 대표하지 못합니다. 중앙값은 개별 이상치에 둔감해 일상적인 체감에 더 가깝습니다.

지연 시간, 지터, 패킷 손실 읽는 법

빛이 광섬유 안에서 나아가는 속도는 초속 약 20만 킬로미터이므로 왕복 거리가 지연 시간의 하한을 그대로 결정합니다. 이웃 국가 노드는 왕복 1000~2000킬로미터 수준이라 이론적 하한이 수십 밀리초에 불과합니다. 반면 태평양을 건너는 왕복 거리는 2만 킬로미터를 넘어 하한 자체가 이미 100밀리초를 웃돕니다. 그래서 같은 스크린샷에 「도쿄 30밀리초」와 「로스앤젤레스 30밀리초」가 함께 나온다면, 후자는 대개 실제 출구 노드가 아니라 로컬 진입 지점을 측정한 값입니다.

위 수치는 경험에 기반한 참고 범위일 뿐 보장값이 아니며, 실제 결과는 로컬 통신사, 회선 유형, 대상 사이트의 위치에 따라 달라집니다. 지터는 인접 표본 간의 차이를 봅니다. 연속 10개 표본의 최대와 최소가 50밀리초 차이 난다면 중앙값이 60밀리초에 불과해도 음성 통화는 끊깁니다. 실시간 음성·영상에서는 지터가 지연 시간보다 더 치명적입니다. 패킷 손실률은 1% 미만이면 거의 느껴지지 않고, 3%를 넘으면 영상에 화면 깨짐이 생기고 웹페이지가 간헐적으로 로드에 실패하며, 10%를 넘으면 사실상 사용이 어렵습니다. 패킷 손실이 나타나면 먼저 회선 유형을 바꾸고, 그다음에 프로토콜 교체를 검토하십시오.

해석 1: 지연 시간이 높고 지터가 작으며 패킷 손실이 0이라면 문제는 물리적 거리에 있습니다. 프로토콜을 바꿔도 개선되지 않으며, 더 가까운 노드로 바꾸거나 경로가 더 짧은 회선 유형으로 옮겨야 합니다.

한 번 측정하고 결론을 내리는 것이 가장 흔한 실수입니다. 한 번의 결과에는 회선 상태, 순간적 혼잡, 로컬 네트워크 변동이 뒤섞여 있으므로 최소 3회, 회차마다 10개 표본은 있어야 숫자를 비교할 수 있습니다.

대역폭: 단일 스레드, 다중 스레드, 단위 환산

단일 스레드 대역폭은 연결 하나의 처리량을 결정하며, 고비트레이트 영상 시청이나 대용량 파일 하나를 내려받을 때 이 값이 중요합니다. 다중 스레드 대역폭은 총량을 결정하고 여러 작업을 동시에 할 때 비로소 쓰입니다. 브라우저에서 쓰는 속도 측정 사이트는 보통 여러 연결을 동시에 열기 때문에 숫자가 좋게 나오고, 클라이언트 내장 측정은 대개 단일 스레드이거나 연결 수를 지정할 수 있어 개별 앱의 실제 체감에 더 가깝습니다. 둘 다 측정해야 하지만 섞어서 비교해서는 안 됩니다.

단위부터 맞춰야 합니다. Mbps는 초당 메가비트, MB/s는 초당 메가바이트로 둘은 8배 차이가 납니다. 100 Mbps는 약 12.5 MB/s입니다. 다운로드 프로그램이 표시한 12 MB/s를 12 Mbps로 착각하면 회선이 표기값의 10분의 1밖에 안 나온다고 오해하게 됩니다.

대역폭 상한은 세 가지 제약을 받습니다. 가정용 회선 요금제, 노드 측의 대역폭 할당, 프로토콜 캡슐화 오버헤드입니다. 실측 다운로드는 가정용 요금제를 넘을 수 없고 보통 그보다 한 단계 낮습니다. 업로드는 대개 다운로드보다 훨씬 작으므로 화상 회의가 끊길 때는 다운로드를 계속 재기보다 업로드를 먼저 확인해야 합니다.

홍보 수치를 서로 비교할 수 없는 이유

두 속도 수치를 함께 놓고 비교하려면 먼저 네 가지가 일치하는지 확인해야 합니다. 측정 대상의 위치, 연결 스레드 수, 측정 시간대, 측정 방식(ICMP, TCP, 애플리케이션 계층)입니다. 이 중 하나만 달라도 결론이 뒤집힐 수 있습니다.

흔한 표기실제 의미재현에 필요한 조건
표기 최고 대역폭최적 시간대, 최적 노드에서의 다중 스레드 최고치같은 시간대, 같은 노드, 같은 스레드 수
표기 최저 지연 시간가장 가까운 진입 지점 또는 가장 가까운 노드까지의 측정값진입 지점을 잰 것인지 출구를 잰 것인지, 어떤 방식으로 측정했는지 명시
속도 제한 없음인위적인 속도 상한이 없음여전히 가정용 회선과 회선 용량의 제약을 받음
야간 피크에도 안정적해당 시간대의 하락 폭이 낮 시간대에 비해 작음비교 시간대와 표본 수를 제시

한 서비스가 홍보 페이지에 아주 높은 최고치를 적어 두었고, 집에서 단일 스레드로 재면 그 일부만 나온다 해도 둘은 모순이 아닙니다. 조건이 다르기 때문입니다. 판단을 하려면 조건을 맞춘 뒤 비교해야 합니다. 같은 시간대, 같은 노드, 같은 프로토콜, 같은 스레드 수로 재고 나서 어느 쪽의 야간 피크 하락 폭이 더 작은지 보십시오.

그대로 옮겨 쓸 수 있는 기록표

아래는 기록표의 머리글입니다. 한 행이 특정 시간대의 완전한 측정 한 번을 나타냅니다. 스프레드시트든 순수 텍스트든 상관없지만, 열 구성은 고정하고 중간에 열을 추가하지 않는 것이 핵심입니다.

date,slot,node,protocol,rtt_med_ms,jitter_ms,loss_pct,down_mbps,up_mbps,note

입력 순서는 다음 여섯 단계로 고정하는 것을 권합니다.

  1. 연결하지 않은 상태에서 한 차례 측정해 로컬 네트워크 기준선으로 삼습니다.
  2. 대상 노드에 연결하고 10초 정도 기다려 연결이 안정된 뒤 시작합니다.
  3. 지연 테스트를 3회 연속 진행하고, 회차마다 10개 표본을 뽑아 중앙값과 지터를 기록합니다.
  4. 단일 스레드와 다중 스레드로 대역폭을 각각 한 번씩 측정하고 다운로드와 업로드를 따로 적습니다.
  5. 시간대를 바꿔 1~4단계를 반복하고 결과는 같은 표에 이어서 추가합니다.
  6. 일주일 뒤 「야간 피크 다운로드 ÷ 오전 다운로드」로 하락 비율을 계산합니다.

하락 비율이 20% 이내라면 정상적인 변동 범위이므로 따로 조치할 필요가 없습니다. 20%에서 50%는 체감되는 속도 저하이므로 다른 회선을 비교해 볼 시점입니다. 50%를 넘으면 해당 시간대에 그 회선이 심하게 몰린 상태이므로 프로토콜을 바꿔 가며 운을 시험하기보다 회선 유형을 바꿔야 합니다.

결과 해석과 흔한 오해

해석 2: 야간 피크 다운로드가 오전의 30% 수준으로 떨어지고 지연이 두 배가 되었는데 패킷 손실은 0에 가깝다면 전형적인 공유 대역폭 혼잡입니다. 같은 유형의 회선에서 노드만 바꾸는 것보다 직결에서 중계나 전용선으로 회선 유형을 바꾸는 편이 효과적입니다.
해석 3: 지연이 정상이고 패킷 손실이 0인데 단일 스레드가 다중 스레드의 10분의 1에 그친다면 병목은 단일 연결 속도 제한이나 프로토콜 캡슐화 오버헤드에 있으며 노드의 원근과는 관계가 없습니다.

회선은 직결, 중계, 전용선 세 가지로 나뉩니다. 직결은 로컬 통신사에서 곧바로 해외로 나가므로 경로가 가장 짧지만 피크 시간대 변동이 큽니다. 중계는 먼저 현지 진입 지점을 거쳐 해외로 나가므로 홉이 하나 늘지만 대체로 안정성이 좋습니다. 전용선은 점대점 링크를 사용해 지연과 대역폭이 더 평탄한 대신 비용이 높습니다. 측정할 때는 도시별로 묶기보다 회선 유형별로 묶어 집계해야 규칙성이 더 잘 보입니다. 회선 목록에는 각 회선의 유형이 표시되어 있으므로 그대로 대조해 기록표를 채울 수 있습니다.

속도 측정의 목적은 가장 보기 좋은 숫자를 찾는 것이 아니라 「실제로 써야 하는 시간대에 가장 안정적인 회선」을 찾는 것입니다. 같은 시간대, 같은 노드, 같은 프로토콜로 연속 세 회차의 중앙값이라야 결정의 근거로 삼을 수 있습니다.