내 사이트, HTTP/2 제대로 쓰고 있을까? 3분 자가진단

HTTP/2, 켰다고 다 빨라지는 건 아닙니다

HTTP/2는 2015년 등장해 지금은 표준 사양이 RFC 9113(2022년, 옛 RFC 7540 폐기)으로 정리된, 사실상 웹의 기본 프로토콜입니다. 그런데 "HTTP/2를 지원한다"는 서버 설정과 "내 방문자가 실제로 HTTP/2로 받고 있다"는 건 다른 이야기입니다.

TLS·ALPN 협상이 어긋나거나, 중간 경로의 어느 구간이 HTTP/1.1이면 사이트는 조용히 HTTP/1.1로 떨어집니다. 콘솔에 켜둔 스위치만 믿지 말고, 실제 응답을 한 번 확인하는 게 자가진단의 출발점입니다.

HTTP/2가 뭘 바꿨나 (3가지만)

점검에 앞서 핵심만 짚겠습니다. HTTP/2의 강점은 크게 셋입니다.

• 멀티플렉싱 — 하나의 연결에서 여러 요청·응답을 동시에 주고받습니다. HTTP/1.1처럼 연결을 여러 개 열 필요가 줄어, 애플리케이션 계층의 대기열 막힘(HOL 블로킹)이 완화됩니다.

• 헤더 압축(HPACK) — 매 요청 반복되는 헤더의 중복을 줄여 전송량을 아낍니다.

• 바이너리 프레이밍 — 텍스트가 아닌 바이너리로 주고받아 파싱이 효율적입니다.

한 가지 오해를 짚자면, 한때 HTTP/2의 상징처럼 불리던 서버 푸시(Server Push)는 이제 권장되지 않습니다. 크롬(2022년)과 파이어폭스(2024년) 등 주요 브라우저가 기본 지원을 중단했고, 같은 효과는 리소스 preload나 103 Early Hints로 얻는 편이 안전합니다. 또 HTTP/2가 모든 막힘을 없애는 건 아닙니다. TCP 계층의 막힘은 남고, 그 부분은 뒤에서 볼 HTTP/3가 다룹니다.

내 사이트가 HTTP/2 쓰는지, 3가지로 확인

어렵지 않습니다. 셋 중 편한 걸로 확인하면 됩니다.

1. 브라우저 개발자도구 — 사이트를 연 뒤 F12 → Network 탭 → 페이지 새로고침. 요청 목록의 열 머리글을 우클릭해 Protocol 열을 켜면 값이 보입니다. h2면 HTTP/2, h3면 HTTP/3, http/1.1이면 아직 HTTP/1.1입니다. (Protocol 열은 기본 숨김이라 우클릭으로 켜야 보입니다.)

2. curl 명령 — 터미널에서 curl -I --http2 https://내도메인을 실행합니다. 응답 첫 줄이 HTTP/2 200이면 HTTP/2로 응답한 것이고, HTTP/1.1 200이면 아닙니다. (내 curl이 HTTP/2를 지원하는지는 curl -V 출력의 Features에서 먼저 확인하면 좋습니다.)

3. 온라인 도구 — 설치 없이 확인하려면 KeyCDN HTTP/2 Test 같은 도구에 주소를 넣으면 지원 여부를 알려줍니다.

참고로 브라우저에서 HTTP/2는 HTTPS와 ALPN 협상으로 결정됩니다. 즉 사실상 HTTPS가 전제이고, 평문 HTTP에서는 HTTP/2가 협상되지 않는다고 보면 됩니다. 한 가지 더, 이 점검은 보통 브라우저(또는 curl)와 첫 접점(엣지) 사이를 보는 것이라, 그 뒤 오리진 서버 구간까지 HTTP/2인지는 따로 확인해야 합니다.

HTTP/2 켰는데 효과가 없다면

진단 결과 h2가 떠도 체감 속도가 그대로일 수 있습니다. 켜져 있는데 효과가 안 나는 데는 흔한 원인이 있습니다.

• 도메인 샤딩 잔재 — HTTP/1.1 시절 병렬 다운로드를 늘리려고 자원을 여러 서브도메인에 쪼개 두던 방식입니다. HTTP/2는 단일 연결 멀티플렉싱이 강점이라, 샤딩이 남아 있으면 연결이 분산돼 오히려 효과가 줄어듭니다. 통합을 검토하세요.

• 엣지는 HTTP/2, 오리진은 HTTP/1.1 — CDN·프록시 구간만 HTTP/2이고 그 뒤 오리진 서버가 HTTP/1.1이면, 그 구간 이점은 사라집니다. 종단 간 경로를 함께 점검해야 합니다.

• HTTPS·ALPN 설정 문제 — 브라우저는 ALPN으로 h2를 협상할 때만 HTTP/2를 씁니다. TLS 구성이나 ALPN이 어긋나면 조용히 HTTP/1.1로 폴백합니다.

• 서버 푸시에 의존한 옛 설정 — 앞서 본 대로 푸시는 브라우저가 무시하므로, 푸시 기반 최적화는 preload·103 Early Hints로 바꿔야 합니다.

그럼 HTTP/3로 바로 가야 하나

HTTP/3가 화제이지만, "HTTP/2는 끝났으니 당장 갈아타야 한다"는 건 성급합니다. HTTP/3는 QUIC(UDP) 기반이라 패킷 손실이 잦은 모바일·불안정 네트워크에서 TCP 계층 막힘을 줄이는 강점이 있습니다. 다만 환경·구현·중간 장비(UDP 차단)에 따라 결과가 달라, HTTP/2보다 무조건 빠르다고 단정하기는 어렵습니다.

둘은 한동안 공존합니다. 보통 연결은 HTTP/2로 시작해 조건이 맞으면 HTTP/3로 올라가죠. 그러니 순서는 분명합니다. 지금 HTTP/2가 제대로 동작하는지부터 확인하는 게 먼저입니다.

점검이 막막하다면

위 진단에서 http/1.1이 뜨거나, 종단 간 경로가 복잡해 어디서 HTTP/2가 끊기는지 모르겠다면 인프라 구성을 함께 들여다보는 편이 빠릅니다. 스피디의 S-CDN도 HTTP/2를 지원하며, 엣지부터 오리진까지 프로토콜·TLS 구성이 일관되게 동작하는지 점검을 도울 수 있습니다.

이것만 기억하세요

자주 묻는 질문 (FAQ)