HTTP/2 멀티플렉싱 vs HOL 블로킹: 체감 성능 차이는?

HTTP/2로 바꾸면 항상 빨라질까요? 절반은 맞고 절반은 아닙니다. 멀티플렉싱 덕분에 요청을 한 연결로 동시 전송할 수 있지만, TCP 기반 특성 때문에 HOL(Head-of-Line) 블로킹이 생기면 체감 성능이 오히려 흔들릴 수 있어요. 이 글은 두 개념을 구조적으로 정리하고, 사이트에서 무엇을 점검해야 하는지 실천 팁까지 담았습니다.

1) 멀티플렉싱: 단일 연결에서의 병렬 전송

정의: HTTP/2는 하나의 TCP 연결 위에 여러 스트림을 얹어 CSS, JS, 이미지 등을 병렬로 전송합니다. HTTP/1.1 시절처럼 도메인 샤딩이나 요청 수를 억지로 분산하지 않아도 됩니다.
장점 요약

• 초기 연결·핸드셰이크 수를 줄여 지연 비용 절감
• 중요 리소스를 먼저 보내는 우선순위 제어 가능
• HPACK 헤더 압축으로 중복 헤더 전송량 축소

핵심 목표는 RTT와 연결 수를 동시에 줄여 초기 구동 시간을 당기는 것입니다.

2) HOL 블로킹: 손실 순간 드러나는 TCP의 직렬 병목

현상: 멀티플렉싱은 애플리케이션 계층에서 병렬이지만, 그 아래 TCP는 단일 바이트 스트림입니다. 특정 패킷이 유실되면 해당 패킷 이후 데이터는 재전송이 끝날 때까지 대기합니다.
체감 이유

• 모바일·공공 와이파이처럼 손실 1~3%만 있어도 재전송 지연이 누적
• 한 리소스 손실이 다른 리소스 진행까지 잠시 붙잡아 둠
• TTFB, LCP, INP 같은 핵심 지표가 들쭉날쭉해 “가끔 느린” 인상을 남김

요약하면, HTTP/2는 평균 성능을 높이는 데 유리하지만, 손실이 생기는 순간 전송 계층의 직렬 병목을 피하기 어렵습니다.

3) 언제 빨라지고 언제 느려지나

좋아지는 경우

• 손실이 거의 없는 유선 환경
• 작은 리소스가 많은 초기 렌더 구간
• 캐시 적중률이 높은 사이트(전송량 자체가 적음)

악화될 수 있는 경우

• 모바일/혼잡망(지터·손실 존재)
• 대형 JS 번들과 이미지가 뒤섞인 페이지
• 서버 측 큐 대기 증가(애플리케이션/DB 병목)

4) 바로 적용할 튜닝 체크리스트

1. 리소스 구조 재검토
   HTTP/1.1 습관처럼 과도한 스플릿이나 샤딩은 지양하되, 초기 렌더 핵심(폰트, 크리티컬 CSS, LCP 이미지)은 별도 청크로 유지합니다.
2. 우선순위 힌트 활용
   preload, preconnect, 필요 시 priority 속성으로 핵심 리소스를 일찍 당겨옵니다. 폰트는 지연 로딩 전략과 폰트 표시 정책을 함께 점검하세요.
3. 전송 바이트 절감
   Brotli 압축, 이미지 AVIF/WEBP 변환, 적절한 Cache-Control/ETag/Vary 설정으로 네트워크 전송량과 손실 노출 면적 자체를 줄입니다.
4. 서버/프록시 큐 길이 단속
   NGINX/Envoy/HAProxy에서 워커·버퍼·큐 설정을 점검하고, 백엔드(스레드, DB 커넥션, 캐시) 병목을 먼저 제거하세요.
5. 모바일 실측 분리
   RUM에서 HTTP/2 사용 구간을 통신사·OS·디바이스별로 분리 관측합니다. TTFB, LCP, 오류율, 네트워크 손실 지표를 함께 봐야 원인이 드러납니다.
6. 대용량 전송 분리
   동영상/대형 파일은 멀티플렉싱 연결과 분리하거나 전용 도메인·전용 경로를 사용해 다른 리소스의 지연 전파를 막습니다.

5) HTTP/3(QUIC)과 비교해 본 핵심 포인트

• HTTP/2: 멀티플렉싱이 있어도 TCP 손실이 발생하면 HOL 블로킹 영향권에 듭니다.
• HTTP/3(QUIC): 스트림이 독립적으로 손실 복구되어 한 스트림의 문제를 다른 스트림으로 덜 전파합니다. 모바일/혼잡망에서 체감 개선 폭이 커지는 이유입니다.
• 운영 관점 결론: 손실이 잦은 사용자 비중이 높다면 HTTP/3 병행 도입과 AB 테스트를 고려하는 것이 안전합니다.

6) 자주 나오는 질문 정리

Q1. HTTP/2는 HTTP/1.1보다 항상 빠른가요?
A. 일반적으로 유리하지만, 손실이 있는 환경이나 요청 패턴에 따라 체감 이득이 줄거나 변동성이 커질 수 있습니다.

Q2. 멀티플렉싱인데 왜 느리다고 느끼죠?
A. 패킷 유실 시 재전송 완료까지 모든 스트림이 대기하는 HOL 블로킹 영향 때문입니다.

Q3. 그럼 도메인 샤딩을 다시 써야 할까요?
A. 과도한 샤딩은 커넥션 오버헤드만 키웁니다. 핵심 리소스 우선화, 바이트 절감, 대용량 분리, HTTP/3 병행이 현대적 해법입니다.

7) 실행 로드맵

1. 초기 렌더 핵심 리소스 식별(LCP 요소, 폰트, 크리티컬 CSS)
2. 우선순위·프리로드·프리커넥트 적용 및 검증
3. 이미지/폰트 포맷 전환과 캐시 정책 정리
4. RUM으로 모바일 세그먼트 성능 분리 추적
5. 대용량 전송 분리와 HTTP/3 점진 도입
6. 국가/통신사/디바이스별 AB 테스트로 효과 검증

결론

HTTP/2의 멀티플렉싱은 평균을 끌어올리고, HOL 블로킹은 꼬리 구간을 악화시킬 수 있습니다. 핵심은 전송 바이트를 줄이고, 우선순위를 정확히 주며, 대용량은 분리하고, HTTP/3를 병행 도입해 손실 환경을 견고하게 만드는 것입니다. 이 네 가지만 지켜도 TTFB와 LCP가 안정적으로 내려가고 사용자 체감이 눈에 띄게 개선됩니다.