대역폭은 속도가 아니다: 지연 시간, 지터, 패킷 손실, 처리량, TTFB 입문

VPS 요금제를 살펴볼 때 가장 눈에 띄는 숫자는 대개 1 Gbps나 10 Gbps입니다. 초보자는 이를 "이 머신은 엄청나게 빠를 것"이라고 직관적으로 해석하기 쉽습니다. 그러나 대역폭은 고속도로의 차선 폭(최대 통행 용량)과 같습니다. 도로가 아무리 넓어도 신호 대기, 우회로, 정체, 사고가 있다면 목적지에 빨리 도착할 수 없습니다.

네트워크 경험은 지연 시간, 지터, 패킷 손실률, 처리량, 애플리케이션 응답 속도로 나누어 종합적으로 평가해야 합니다.

1. 지연 시간(레이턴시): 한 번 왕복하는 데 걸리는 시간

일반적인 ping이 측정하는 값은 RTT(Round-Trip Time, 왕복 시간)입니다. 데이터 패킷이 내 컴퓨터에서 목적지에 도달하고 다시 되돌아오기까지 걸리는 시간을 밀리초(ms) 단위로 나타냅니다.

20 ms:  조작 반응이 즉각적이고 쾌적함
200 ms: 매번 입출력 시 명확한 대기 시간이 체감됨

이는 절대적인 등급이 아니라 이해를 돕기 위한 기준입니다. 웹페이지를 로드할 때 여러 번의 왕복 통신이 필요하며, SSH 터미널 작업 역시 빈번한 상호작용을 수반합니다. 따라서 다운로드 대역폭이 아무리 커도 지연 시간이 높으면 작업이 굼뜨게 느껴집니다.

2. 지터(Jitter): 지연 시간의 안정성

10번의 RTT 측정 결과가 40, 41, 39, 42 ms라면 매우 안정적인 상태입니다. 반면 40, 180, 55, 300 ms처럼 심하게 요동친다면, 수학적 평균값은 그럴듯해 보여도 실제 체감은 극도로 불안정해집니다.

이러한 지연 시간의 편차를 지터(Jitter) 또는 패킷 지연 변이라고 부릅니다. 실시간 음성 통화, 게임, 원격 터미널, 화상 회의는 대용량 파일 다운로드보다 지터에 훨씬 민감합니다. 지속적이고 적시의 패킷 전달이 필수적이기 때문입니다.

RFC 3393은 IP 패킷 지연 변이의 측정 표준을 정의합니다. 복잡한 수식을 계산할 필요는 없으며, 평균 지연 시간뿐만 아니라 표본 간의 안정성 역시 매우 중요하다는 점을 기억하세요.

3. 패킷 손실: 전송된 데이터가 유실되는 현상

패킷 손실은 송신된 데이터 패킷이 정해진 시간 내에 목적지에 도달하지 못하는 현상입니다. TCP 프로토콜은 유실된 데이터를 재전송하지만, 재전송 자체가 시간과 대역폭을 낭비합니다. 몇 퍼센트의 지속적인 손실만으로도 SSH 타이핑이 멈칫거리고, 다운로드 속도가 급락하며, 음성 통화가 끊기게 됩니다.

RFC 2680에 명시되어 있듯, 심한 패킷 손실은 TCP가 높은 처리량을 유지하기 어렵게 만듭니다. 또한 왕복 경로가 비대칭일 경우, 단순한 왕복 테스트는 양방향 손실률을 한데 뒤섞어 버립니다.

주의할 점은 일부 라우터가 ICMP 진단 패킷에 대한 응답 우선순위를 낮춰둔다는 것입니다. ping에서 손실률이 나타난다고 해서 실제 HTTPS나 SSH 서비스에서도 동일하게 패킷이 유실되는 것은 아닙니다. 실제 업무 프로토콜과 유사한 방식으로 측정해야 유의미한 결과를 얻을 수 있습니다.

4. 대역폭과 처리량: 공칭 한도와 실제 측정치

VPS 사양표에 1 Gbps라고 적혀 있어도 이는 포트 한도일 뿐입니다. 실제 처리량은 회선 혼잡, 경유 경로, 패킷 손실, 지연 시간, TCP 윈도우 크기, 디스크 I/O, CPU 성능에 의해 제한됩니다.

따라서 속도 측정 결과가 낮다고 해서 무조건 "회선이 나쁘다"고 단정할 수는 없습니다. 저속 스토리지에서 파일을 읽거나 대상 서버가 다운로드 속도를 제한하고 있다면 네트워크가 좋아도 속도가 나오지 않습니다.

5. TTFB: 서버가 응답을 시작하기까지 걸리는 시간

TTFB는 Time to First Byte의 약자로, HTTP 요청을 보낸 시점부터 첫 번째 응답 바이트를 수신하기까지 걸리는 시간입니다. DNS 조회, TCP 핸드셰이크, TLS 협상, 네트워크 왕복, 백엔드 서버 처리 시간이 모두 합산됩니다.

TTFB가 길다면 네트워크 지연일 수도 있지만, 애플리케이션의 무거운 연산, 데이터베이스 쿼리, 콜드 스타트가 원인일 수 있습니다. 단순한 ping보다 웹사이트 반응성을 훨씬 잘 대변하지만, 전체 페이지 렌더링 완료 시간과는 다릅니다.

ping 은 네트워크 왕복 시간을 측정함;
TTFB 는 앱이 응답을 시작하기까지의 시간을 측정함;
전체 페이지 로딩에는 HTML, 이미지, CSS, JS, 폰트 다운로드 시간이 추가됨.

6. 한 번의 속도 측정으로 결론지을 수 없는 이유

한 번의 측정은 특정 출발지, 목적지, 프로토콜, 부하 상황에서의 단편적인 스냅샷일 뿐입니다. 의미 있는 비교를 위해 다음 조건을 기록하세요:

• 측정 일자와 시각;
• 로컬 인터넷 통신사 및 연결 방식;
• VPS 지역 및 테스트 대상 엔드포인트;
• 사용 프로토콜 (TCP, UDP, ICMP);
• 측정 지속 시간, 동시 스레드 수, 전송 데이터 크기;
• 서버의 CPU, 디스크 부하 상태;
• 야간 피크 혼잡 시간대 여부.

테스트 조건이 통제되지 않으면 측정치의 차이는 VPS 자체의 성능 차이가 아니라 테스트 방법의 차이에서 비롯됩니다.

7. 초보자를 위한 4단계 네트워크 테스트법

기초 점검에서 실제 업무 환경 검증으로 단계적으로 나아갑니다:

1. 도달성 (Reachability): 도메인이 정상 해석되고 TCP 연결이 성립되는가; 2. 회선 품질 (Quality): 다회차 RTT 측정을 통해 지연 시간, 지터, 패킷 손실률을 확인; 3. 전송 성능 (Throughput): iperf3 등 신뢰할 수 있는 도구로 실제 처리량을 측정; 4. 실제 워크로드 (Application): 웹사이트 로딩, SSH 조작, API 호출, 실제 파일 전송.

출처를 알 수 없는 '원클릭 벤치마크 스크립트'를 root 권한으로 무분별하게 실행하지 마세요. 내용을 검증하지 않고 암호화되지 않은 HTTP에서 스크립트를 파이프 실행하면 서버 제어권을 공격자에게 넘겨줄 위험이 있습니다.

8. 요약

네트워크가 '빠른지' 여부는 단 하나의 숫자로 대답할 수 없습니다.

대화형 반응성은 지연 시간과 지터;
안정성은 패킷 손실률;
대용량 파일 전송은 실제 처리량;
웹사이트는 TTFB와 전체 렌더링 시간;
최종 판단은 실제 서비스의 체감 품질.

대역폭은 중요하지만 속도와 동의어가 아닙니다. VPS에서는 일시적인 피크 속도보다 안정적이고 재현 가능한 실측 성능이 훨씬 중요합니다.

자주 묻는 질문 (FAQ)

ping은 매우 낮은데 SSH가 버벅거리는 이유는 무엇인가요?

순간적인 지터, TCP 패킷 손실, 서버 고부하, 터미널 렌더링 병목, 수신 경로(회정) 지연이 원인일 수 있습니다. SSH 디버그 로그와 서버 리소스를 확인하세요.

중간 홉에서 80% 손실률이 나타나면 회선 장애인가요?

후속 홉과 최종 목적지에서 손실이 없다면, 중간 라우터가 진단 패킷 응답을 속도 제한하고 있을 뿐입니다.

속도 측정을 하면 월간 트래픽이 차감되나요?

네. 처리량 테스트는 실제로 대량의 데이터를 송수신하므로 트래픽을 소비합니다. 테스트 전에 예상 사용량을 확인하세요.

참고 자료

• RFC 2680: A One-way Packet Loss Metric for IPPM
• RFC 2681: A Round-trip Delay Metric for IPPM
• RFC 3393: IP Packet Delay Variation Metric for IPPM
• RFC 6349: Framework for TCP Throughput Testing
• iperf3 공식 문서
• MeowVPS: VPS 성능 측정 방법 소개