들어가며
웹 애플리케이션의 규모가 커지고 처리해야 할 리소스가 폭발적으로 증가하면서 기존 HTTP/1.1 프로토콜의 구조적 한계가 드러나기 시작했다. 이를 극복하고 통신 지연을 최소화하여 웹의 전반적인 성능을 끌어올리기 위해 2015년에 등장한 것이 HTTP/2다.
HTTP/2는 기존 HTTP/1.1의 기본적인 구성 요소(메서드, 상태 코드, URI 등)는 유지하면서, 병목을 완화하기 위해 데이터 전송 구조를 근본적으로 재설계했다.
HTTP/1.1의 구조적 한계와 병목 현상
HTTP/1.1은 한 TCP 연결 안에서는 응답 순서 제약이 강했고, 파이프라이닝(Pipelining)도 널리 정착하지 못해 브라우저가 여러 연결을 여는 방식으로 병렬성을 보완해야만 했다. 이러한 설계는 웹의 초창기에는 문제가 없었으나, 현대의 복잡한 웹 환경에서는 심각한 성능 저하를 유발했다.
HOL(Head-Of-Line) Blocking
순차적 처리 방식 탓에, 먼저 보낸 요청의 처리가 지연되거나 응답 파일의 크기가 너무 크면 뒤이어 대기 중인 다른 요청들은 앞선 작업이 끝날 때까지 기다려야만 했다.
무거운 헤더의 반복 전송
HTTP/1.1은 매 요청과 응답마다 평문(Plain Text) 형태의 무거운 헤더를 전송한다. 특히 수십 개의 리소스를 주고받을 때 쿠키(Cookie)나 User-Agent처럼 내용이 완전히 동일한 헤더가 매번 중복해서 전송되어 불필요한 네트워크 대역폭을 크게 낭비했다.
클라이언트의 우회 기법 한계
브라우저들은 이러한 제약을 우회하기 위해 이미지 스프라이트(Image Sprite), CSS/JS 파일 병합, 도메인 샤딩이나 다중 연결처럼 병렬 연결 수를 늘리는 방식, 그리고 HTTP 파이프라이닝 같은 기법을 사용했다. 하지만 이는 근본적인 해결책이 아니었으며, 오히려 리소스 관리의 복잡도를 높이고 서버에 불필요한 커넥션 부하를 주기도 했다.
HTTP/2의 핵심 기술과 변화
HTTP/2는 기존의 순차적, 텍스트 기반 전송 방식을 버리고 성능 극대화에 초점을 맞춘 새로운 메커니즘을 도입했다.
바이너리 프레이밍 계층 (Binary Framing Layer)
HTTP/2는 HTTP 애플리케이션 계층과 TCP 전송 계층 사이에 바이너리 프레이밍 계층을 새롭게 추가했다.
HTTP/1.1이 줄바꿈으로 구분된 평문 텍스트로 메시지를 전송했다면, HTTP/2는 모든 메시지를 더 작은 단위인 프레임(Frame)으로 잘게 나누고 이를 바이너리로 인코딩한다. 이 계층 덕분에 메시지 경계를 일관되게 해석할 수 있고, 요청과 응답을 프레임 단위로 나누어 다루는 멀티플렉싱도 가능해진다.
멀티플렉싱 (Multiplexing)
잘게 쪼개진 바이너리 프레임들은 스트림(Stream)이라는 가상의 채널을 통해 전송된다. 멀티플렉싱은 이 스트림들을 활용해 단 하나의 TCP 커넥션 위에서 여러 개의 요청과 응답을 순서에 상관없이 병렬로 교환할 수 있게 해주는 핵심 기술이다.
프레임 단위로 조각난 데이터가 섞여서 전송되더라도, 각 프레임에 부여된 스트림 식별자를 통해 목적지에서 원래의 메시지로 재조립된다. 이 덕분에 HTTP/1.1에서 문제였던 요청 단위 직렬화는 크게 완화되었고, 하나의 응답이 늦어져도 다른 스트림을 함께 흘려보낼 수 있게 되었다. 다만 TCP 위에서 동작하는 한 패킷 손실이 발생하면 같은 연결의 다른 스트림도 영향을 받으므로, 전송 계층의 HOL Blocking까지 사라지는 것은 아니다.
HPACK 알고리즘을 통한 헤더 압축
HTTP/2는 HPACK 알고리즘을 도입하여 헤더의 크기를 획기적으로 줄였다.
클라이언트와 서버는 서로 주고받은 헤더 필드의 상태를 각각 인덱스 테이블(정적 테이블과 동적 테이블)로 유지하고 관리한다. 이전 요청과 중복되는 헤더 필드는 문자열 전체를 보내는 대신 인덱스 값만 전송하고, 새롭게 추가되거나 변경된 값만 허프만 인코딩(Huffman Coding)으로 압축하여 전송한다. 결과적으로 전송해야 할 헤더 데이터의 양이 극적으로 감소하게 된다.
스트림 우선순위 (Stream Prioritization)
멀티플렉싱으로 수많은 리소스가 병렬로 전송될 때, 브라우저가 화면을 렌더링하는 데 더 중요한 파일(예: 메인 CSS나 핵심 JS)이 존재하기 마련이다. HTTP/2는 각 스트림에 가중치와 의존성을 부여하여 우선순위를 설정할 수 있는 기능을 제공했다. 하지만 명세상 우선순위 기능이 있었음에도 서버와 브라우저의 구현 편차가 크고 널리 성공적이지 못했으며, 최신 HTTP/2 표준(RFC 9113)에서는 기존 우선순위 방식이 사실상 퇴조했다.
프론트엔드 최적화 방식의 변화
HTTP/2의 도입은 단순히 속도가 빨라진 것을 넘어 프론트엔드 최적화 방식에 큰 변화를 가져왔다.
멀티플렉싱 덕분에 리소스를 더 잘게 나누어 전송하더라도 과거 HTTP/1.1 환경만큼 불리하지는 않다. 그래서 파일 수를 줄이기 위해 강제로 CSS나 JS를 하나의 거대한 파일로 묶거나(Concatenation) 이미지를 합치는(Image Sprite) 최적화의 우선순위도 예전보다 낮아졌다. 또한 브라우저가 여러 개의 도메인(Domain Sharding)으로 분산시켜 TCP 커넥션 제한을 우회하던 기법도 더 이상 권장되지 않는다.
서버 푸시(Server Push)에 대하여
HTTP/2 초기에는 클라이언트가 요청하지 않은 리소스를 서버가 알아서 미리 밀어 넣어주는 ‘서버 푸시’ 기능이 주목받았다. 하지만 실무에서는 브라우저의 캐시 상태를 서버가 정확히 파악하기 어려워 불필요한 대역폭 낭비를 초래하는 안티 패턴으로 작용했다. 결국 모던 브라우저를 중심으로 이 기능에 대한 지원을 중단하는 추세이며, 현재는
103 Early Hints를 활용해 클라이언트가 능동적으로 리소스를 준비하도록 돕는 방식이 더 자주 언급된다.
서버 설정 관점에서의 적용
자바 생태계의 스프링 부트(Spring Boot)를 사용한다면 애플리케이션 코드 수정 없이 설정 파일에 아래와 같이 속성을 추가해 HTTP/2를 활성화할 수 있다.
server:
http2:
enabled: true
다만, 대부분의 모던 브라우저는 암호화되지 않은 평문 통신(h2c)을 지원하지 않고 보안 연결 위에서 동작하는 HTTP/2(h2)만을 허용한다. 따라서 브라우저와 직접 통신하는 웹 서버나 외부 공개용 리버스 프록시(Nginx, HAProxy 등) 단에서는 SSL/TLS 인증서 설정이 필요하다. (물론 프록시 뒤의 내부 구간이나 서비스 간 통신 같은 비브라우저 클라이언트 환경에서는 평문인 h2c를 사용할 수도 있다.)
운영 환경에서 함께 확인할 것들
설정을 켰다고 해서 바로 HTTP/2의 효과가 드러나는 것은 아니다. 애플리케이션 앞단에 리버스 프록시나 CDN이 있다면, 실제 협상은 그 계층에서 끝나고 백엔드까지는 HTTP/1.1로 전달될 수도 있다. 이 경우 브라우저에서는 HTTP/2로 보이더라도 원서버 관점에서는 커넥션 수나 헤더 처리 방식이 기대와 다를 수 있다.
가장 먼저 확인할 것은 클라이언트와 엣지 구간에서 HTTP/2 협상이 실제로 이루어졌는지다.
브라우저 개발자 도구의 네트워크 탭에서 프로토콜 열을 보거나, curl -I --http2 https://example.com처럼 응답 헤더만 확인해도 빠르게 감을 잡을 수 있다.
로컬이나 스테이징에서 테스트할 때는 TLS가 빠져 있어 브라우저가 암호화된 HTTP/2인 h2를 쓰지 않는 경우도 많으므로, 설정만 보고 HTTP/2가 적용되었다고 판단하면 어긋나기 쉽다.
리버스 프록시를 두는 환경이라면 프록시가 HTTP/2를 어디까지 처리하는지도 따로 보는 편이 좋다. 클라이언트와 프록시 사이만 HTTP/2로 열고 프록시와 애플리케이션 사이는 HTTP/1.1로 두는 구성이 흔하기 때문이다. 이때는 멀티플렉싱과 헤더 압축 같은 HTTP/2의 이점이 어느 구간에서 작용하는지 정확히 구분해서 해석해야 한다.
정리하며
HTTP/2는 데이터를 일반 텍스트에서 바이너리로 바꾸고, 하나의 통로로 쪼개진 프레임을 병렬로 전송하는 방식으로 기존의 통신 구조를 개선했다. 이러한 설계는 HTTP/1.1에서 두드러졌던 요청 직렬화와 무거운 헤더 전송 문제를 크게 줄였고, 복잡한 우회 기법에 덜 의존하도록 만들었다. 다만 성능 개선의 폭은 TLS 구성, 프록시 배치, 실제 협상 구간에 따라 달라지므로, 프로토콜 이름만 바뀌었다고 단정하기보다 어느 구간에서 병목이 줄었는지 함께 확인하는 편이 도움이 된다.