언어

HTTP/2와 HTTP/3

HTTP/2와 HTTP/3의 작동 방식, QUIC과 멀티플렉싱의 차이, Googlebot 지원 범위, 간접 SEO 이점, CDN 활성화와 Server Push 대안을 설명합니다.

최초 게시: 2026년 7월 3일 · 최근 업데이트: 2026년 8월 22일 · Advanced
언어
AI작성자AI v2

HTTP/2는 TCP 연결 하나에서 멀티플렉싱과 HPACK 압축을 제공하고 HTTP/3는 UDP 기반 QUIC으로 스트림 간 손실 지연을 격리합니다. 둘 다 직접 순위 요소가 아니며 Googlebot은 기본 HTTP/1.1과 자격 충족 시 HTTP/2를 사용하고 현재 문서에는 HTTP/3가 없습니다. HTTP/2 거부는 421 상태로 문서화됐습니다. 이점은 사용자 속도와 Core Web Vitals를 통한 간접 효과입니다. CDN에서 켠 뒤 실제 협상을 확인하고 Server Push 대신 103 Early Hints나 preload를 사용하세요.

요약 — HTTP/2는 TCP 연결 하나에서 멀티플렉싱, HPACK 헤더 압축, RFC 9218 우선순위 힌트를 제공합니다. HTTP/3는 같은 의미 체계를 TCP 대신 QUIC/UDP 위에서 제공해 한 스트림의 손실 패킷이 다른 스트림을 막지 않게 합니다. 스트림은 연결의 혼잡 제어와 QPACK 상태를 공유하므로 파일별 완전 독립은 아닙니다. 둘 다 직접 순위 요소가 아닙니다. Google은 HTTP/2 크롤에 순위 상승이 없다고 하고, 크롤러 문서는 HTTP/3를 지원 프로토콜로 나열하지 않습니다. Googlebot은 기본 HTTP/1.1, 자격이 되면 HTTP/2(HTTPS + h2)를 쓰며 문서화된 거부 상태는 421입니다. 실제 사용자 속도가 Core Web Vitals에 반영되는 간접 이점은 있지만 새 프로토콜 협상 자체가 지표나 검색 성과를 보장하지 않습니다. 웹 대부분은 HTTP/2지만 실제 HTTP/3 요청은 아직 소수이며 CDN이 지원해도 발견·대체 절차 때문에 모든 방문이 사용하지는 않습니다. 순위 상승 추구와 Chrome/Chromium v106부터 기본 비활성화된 Server Push는 건너뛰고 103 Early Hints나 rel=preload를 쓰세요.

Evidence for this claim HTTP/2 adds binary framing and multiplexed streams while preserving HTTP semantics. Scope: Current official or standards documentation. Confidence: high · Verified: RFC 9113: HTTP/2 Evidence for this claim HTTP/3 maps HTTP semantics over QUIC rather than TCP. Scope: Current official or standards documentation. Confidence: high · Verified: RFC 9114: HTTP/3

각 프로토콜이 실제로 바꾸는 것

두 업그레이드를 구분하면 나머지는 자연스럽게 이해됩니다.

**HTTP/2(2015, RFC 7540)**는 HTTP 의미 체계를 유지하면서 바이트 전송 방식을 바꿨습니다.

  • 멀티플렉싱. HTTP/1.1의 연결별 순차 처리 대신 하나의 연결에서 여러 요청·응답을 교차 전송합니다.
  • HPACK 헤더 압축. 매 요청의 반복 헤더를 압축해 오버헤드를 줄입니다.
  • 스트림 우선순위. 원래 RFC 7540 우선순위 트리는 HTTP/2 업데이트 RFC 9113에서 폐기됐습니다. 현재 신호는 HTTP/2와 HTTP/3 모두에 쓰는 RFC 9218 Extensible Priority Scheme의 간단한 urgency·incremental 힌트입니다. 서버가 전부·일부를 따르거나 무시할 수 있는 권고입니다.
  • 처음에는 Server Push도 있었고 HTTP/2·HTTP/3 명세에 기술적으로 남아 있지만 브라우저는 실무 지원을 중단했습니다.
  • 실제로 HTTPS가 필요하며 주요 브라우저는 암호화되지 않은 HTTP/2를 협상하지 않습니다.

**HTTP/3(2022, RFC 9114)**는 HTTP/2 의미 체계를 유지하고 전송 계층을 바꿉니다.

  • TCP가 아니라 UDP 기반 전송인 QUIC 위에서 작동합니다.
  • HTTP/2의 전송 계층 head-of-line blocking을 줄이지만 모든 형태를 없애지는 않습니다. HTTP/2의 멀티플렉싱 스트림은 TCP 연결 하나를 공유해 패킷 하나가 손실되면 재전송까지 모든 스트림이 멈춥니다. QUIC은 요청별 스트림을 제공해 한 스트림 손실이 다른 스트림을 막지 않습니다. 다만 같은 QUIC 연결의 스트림은 혼잡·흐름 제어를 공유하고, 한 스트림 안의 바이트는 순서대로 도착하며, QPACK 헤더 디코딩은 다른 스트림이 의존할 수 있는 공유 제어 스트림을 사용합니다. “파일마다 완전히 독립”이 아니라 “손실이 스트림 사이로 번지지 않는다”가 정확합니다.
  • QUIC은 의무 암호화인 TLS 1.3을 통합하고 세션 재개로 연결 설정을 빠르게 하며 재방문에 선택적 0-RTT를 지원합니다. 0-RTT의 초기 데이터는 공격자가 재생할 수 있어 안전한 요청만 허용되며 서버는 거부하고 일반 핸드셰이크로 돌아갈 수 있습니다(425 Too Early).
  • QUIC은 새 네트워크 경로를 검증해 WiFi → 셀룰러 변경에도 연결을 옮기는 연결 마이그레이션을 지원합니다. QUIC v1에서는 클라이언트만 시작할 수 있고, 경로 검증·주소 변경·혼잡 상태 재설정 때문에 연속성이 조건부이지 보장되지는 않습니다.

HTTP/3의 가장 큰 이점은 느리거나 손실이 많은 연결에 집중됩니다. 빠르고 안정적인 네트워크에서는 차이가 작습니다. Will Nye가 Search Engine Journal에서 잘 설명한 대로 트래픽의 가장 느린 구간이 이점을 가장 많이 얻습니다. 모든 사용자가 광통신을 쓰는 사이트에 과장해서 판매하지 마세요.

순위에 영향을 주나요? (아니요 — 정확한 표현)

SEO 실무자가 가장 궁금해하는 질문입니다. Google 크롤러 개요는 크롤러가 HTTP/1.1과 HTTP/2를 지원하고 크롤 성능에 더 좋은 쪽을 선택한다고 설명하며 다음과 같이 밝힙니다.

“The default protocol version used by Google’s crawlers is HTTP/1.1; crawling over HTTP/2 may save computing resources (for example, CPU, RAM) for your site and Googlebot, but otherwise there’s no Google-product specific benefit to the site (for example, no ranking boost in Google Search).” (번역) Google 크롤러의 기본 프로토콜은 HTTP/1.1이며 HTTP/2 크롤은 사이트와 Googlebot의 CPU·RAM 같은 컴퓨팅 자원을 절약할 수 있지만 Google 검색 순위 상승 같은 Google 제품의 별도 이점은 없습니다.

매우 명확합니다. HTTP/2는 연결 양쪽의 전송 효율을 높여 서버와 Googlebot 작업을 줄일 수 있지만 순위 신호가 아닙니다.

SEO 이점은 간접적입니다. 실제 사용자의 빠른 로드는 Google 페이지 경험 신호인 **Core Web Vitals**에 반영됩니다. HTTP/2·HTTP/3는 순위를 올리는 스위치가 아니라 Google이 측정하는 지표에 나타날 수 있는 사용자 경험 투자입니다.

오늘날 Googlebot의 실제 동작

경쟁 글이 자주 생략하지만 이 페이지에서 가장 유용한 부분이며 Google 크롤러 문서는 구체적입니다.

  • 기본은 HTTP/1.1. 이전 크롤 통계에 따라 세션 사이에 HTTP/2로 전환할 수 있습니다.

  • HTTP/2 크롤은 요청형이 아니라 자격 기반입니다. Googlebot은 2020년 11월 중순부터 일부 사이트를 HTTP/2로 크롤하기 시작했습니다(Googlebot will soon speak HTTP/2). 사이트가 HTTPS와 HTTP/2 지원을 제공하고 업그레이드가 유리할 만큼 충분히 크롤되면 자격을 얻으며 강제할 수 없습니다.

  • 421로 거부할 수 있습니다. Google은 크롤러 개요에 거부 방법을 문서화했습니다.

    “To opt out from crawling over HTTP/2, instruct the server that’s hosting your site to respond with a 421 HTTP status code when Google attempts to access your site over HTTP/2.” (번역) HTTP/2 크롤을 거부하려면 Google이 HTTP/2로 접근할 때 서버가 421 HTTP 상태 코드를 반환하게 합니다.

  • Google 크롤러 문서에 HTTP/3는 없습니다. 현재 개요는 HTTP/1.1과 HTTP/2만 지원 버전으로 나열하고 HTTP/3를 언급하지 않습니다. 이는 Google이 공개한 내용에 관한 판단이지 어떤 요청도 HTTP/3를 쓰지 않는다는 보장은 아닙니다. Barry Schwartz도 Search Engine Roundtable에서 같은 부재를 보도했고 Will Nye의 SEJ 가이드는 Googlebot이 현재 HTTP/3를 지원하지 않는다고 설명합니다.

HTTP/2 발표(2015)와 Googlebot 지원(2020) 사이에는 약 다섯 해가 있었습니다. HTTP/3는 2022년에 확정됐으므로 같은 패턴이라면 크롤러 지원까지 시간이 더 걸릴 수 있습니다. HTTP/3 크롤을 기다리지도, 그 때문에 사이트 개선을 미루지도 마세요. 채택 이유는 Googlebot이 아니라 사용자입니다.

두 가지를 덧붙입니다. 첫째, 2021년 Google I/O 무렵 John Mueller는 Google이 이미 URL 절반 이상을 HTTP/2로 크롤하고 멀티플렉싱·헤더 압축으로 연결 수와 대역폭이 크게 줄었다고 했습니다. Google과 서버 인프라 모두의 이점입니다. 둘째, Bing에는 비교 가능한 HTTP/2·HTTP/3 크롤 정책 발표를 찾지 못했습니다. IndexNow, Crawl Control, 사이트맵 처리처럼 일반 크롤 효율 자료는 있지만 Google 수준의 프로토콜 선언은 없으므로 추론하지 않습니다. Bing 답이 필요하면 Bing Webmaster Blog를 직접 확인하세요.

Chrome 도구가 보여 주는 것과 보여 주지 않는 것

Chrome Lighthouse의 Modern HTTP 인사이트는 오래된 HTTP 버전으로 제공되는 사이트를 표시해 파일이 HTTP/2·HTTP/3인지 확인합니다. 다만 대부분 SEO 담당자가 보는 공개 PageSpeed Insights가 아니라 Chrome DevTools 성능 추적에 나타납니다. 예전 uses-http2 감사는 모든 요청에서 h1·h2·h3를 안정적으로 감지하기 어려워 비활성화됐습니다. 일반 PSI에서 실시간 “uses HTTP/2” 통과를 찾지 마세요. 브라우저 Network 패널의 Protocol 열이나 WebPageTest로 확인합니다.

2026년 실제 채택 현황

가장 좋은 공개 데이터는 Akamai의 Robin Marx가 작성한 2024 Web Almanac HTTP 장입니다.

  • 홈페이지: 데스크톱 HTTP/1.1 약 22% · HTTP/2 약 71% · HTTP/3 약 7%. 모바일은 약 21% / 70% / 9%로 비슷합니다.
  • 전체 요청: 약 **85%**가 HTTP/2 이상이고 HTTP/1.1은 약 15%입니다.
  • HTTP/3를 실제 사용하는 사이트보다 준비된 사이트가 많습니다. 홈페이지 약 26–28%가 alt-svc 헤더로 HTTP/3 지원을 알리지만 실제 제공 요청은 훨씬 적습니다.
  • CDN이 대부분을 담당합니다. CDN 제공 요청의 약 **96%**가 HTTP/2 이상인 반면 비CDN 요청은 약 **29%**가 여전히 HTTP/1.1입니다. CDN 사용 주장을 한 통계로 보여 줍니다.

다른 곳의 “상위 10 million 사이트 중 25%가 HTTP/3 지원”이라는 오래된 수치는 Almanac의 “실제 요청 7–9%가 HTTP/3”와 다른 것을 측정합니다. 대형 도메인의 사이트 수준 지원과 실제 요청 점유율은 동시에 참일 수 있으므로 모순으로 취급하지 마세요.

실제 활성화 방법

대부분 사이트에는 서버 마이그레이션이 아니지만, HTTP/3는 발견돼야 하고 조용히 대체될 수 있으므로 단순히 켜는 것으로 끝나지 않습니다.

  • CDN을 사용합니다. Cloudflare, Fastly, Google Cloud CDN 같은 CDN에서 HTTP/2·HTTP/3는 대개 체크박스로 켭니다. 그 뒤 브라우저 Network 패널이나 curl --http3로 실제 협상을 확인하세요. TLS/ALPN, 원본-엣지, 엣지-클라이언트 지원이 모두 맞아야 합니다.
  • HTTPS로 제공합니다. 주요 브라우저는 암호화되지 않은 HTTP/2·HTTP/3를 협상하지 않으므로 실제 전제 조건입니다.
  • HTTP/3 발견과 대체 방식을 압니다. 첫 연결은 보통 TCP의 HTTP/2 또는 HTTP/1.1로 협상합니다. 서버·CDN이 Alt-Svc 헤더나 DNS HTTPS/SVCB 레코드로 HTTP/3를 알리면 브라우저가 캐시해 다음 연결에서 QUIC을 시도합니다. UDP가 차단되거나 QUIC 핸드셰이크가 실패하면 HTTP/2·HTTP/1.1로 자동 대체합니다. 설계대로의 동작이지만 “원본 지원”이 첫 방문을 포함한 모든 방문의 사용을 보장하지는 않습니다. 100%라고 가정하지 말고 실제 비율을 측정하세요.
  • 직접 호스팅하면 서버 지원을 확인합니다. HTTP/3 서버 지원은 역사적으로 뒤처졌고 빠르게 바뀌므로 현재 스택 상태를 확인하세요. CDN이 현실적인 기본값인 이유입니다.

하지 말아야 할 것: Server Push

누군가 HTTP/2 Server Push를 제안하면 거절하세요. HTTP/2·HTTP/3 명세에는 남아 있지만 중요한 브라우저에서는 끝난 기능입니다. Chrome 팀 Barry Pollard의 Removing HTTP/2 Server Push가 제거를 설명합니다.

“support of HTTP/2 Server Push will be disabled by default in Chrome 106 and other Chromium-based browsers.” (번역) HTTP/2 Server Push 지원은 Chrome 106과 다른 Chromium 기반 브라우저에서 기본 비활성화됩니다.

채택률도 이미 무너졌습니다. Pollard는 HTTP/2 사이트 사용률이 “dropped to 0,7%” (번역) 0,7%까지 떨어졌다고 했고, 성능도 “without a clear net performance gain and in many cases performance regressions.” (번역) 명확한 순성능 이득 없이 많은 경우 성능 퇴보를 보였다고 설명합니다. Chrome/Chromium에 대해 문서화된 제거이며, 다른 엔진도 실무상 같은 방향이지만 “모든 엔진에서 소스 코드까지 제거됐다”는 주장으로 확장하지 않습니다.

문서화된 대안은 다음과 같습니다.

“103 Early Hints is a much less error-prone alternative with many of the same upsides as Push, and a lot less of the downsides” (번역) 103 Early Hints는 Push의 장점 대부분을 가지면서 단점과 오류 가능성이 훨씬 적은 대안입니다.

필요한 리소스에는 표준 <link rel=preload>도 사용합니다. 리소스 힌트 글에서도 설명합니다. 결론은 2026년에 Server Push를 중심으로 설계하지 말라는 것입니다.

보안 주의점

HTTP/2의 장점은 잠시 약점이기도 했습니다. 2023년 멀티플렉싱은 기록적 DDoS 기법 HTTP/2 Rapid Reset(CVE-2023-44487)의 기반이 됐습니다. Cloudflare 엔지니어들은 기술 분석에서 많은 스트림을 빠르게 열고 취소하는 기능이 “an obvious vector for denial-of-service,” (번역) 명백한 서비스 거부 공격 벡터였다고 설명했고 주요 공급자는 초당 수억 요청 공격을 완화해야 했습니다. 패치된 현대 서버·CDN을 쓰므로 HTTP/2를 피할 이유는 아니지만, 직접 호스팅하면 서버 소프트웨어를 최신으로 유지하세요.

웹 성능에서의 위치

HTTP/2·HTTP/3는 전송 계층 수단이며 웹 성능의 다른 요소와 같은 지표에 영향을 줍니다. 빠른 전송은 TTFB와 LCP를 개선해 **Core Web Vitals**과 연결됩니다. **CDN**은 프로토콜을 켜는 일반적 방법이자 실제 채택의 가장 큰 동력입니다. **캐싱**과 Server Push를 대체한 Early Hints·preload를 포함한 **리소스 힌트**가 리소스 도착 속도를 완성합니다. 사용자에게 맞게 설정할 전송 계층의 한 부분이지 순위 버튼은 아닙니다.

Add an expert note

Pin an expert quote

New person? Create their unclaimed profile at /admin/experts/ → Pin a quote first.