HTTP 압축은 응답 본문을 더 작게 만들어 전송량을 줄이는 기술입니다. HTML·CSS·JS·JSON 같은 텍스트는 반복이 많아 보통 70~90%까지 줄어들어, 페이지 로딩 속도와 대역폭 비용에 큰 영향을 줍니다. 압축은 클라이언트와 서버가 지원 방식을 협상한 뒤, 서버가 본문을 압축해 어떤 방식을 썼는지 알려주고 클라이언트가 풀어서 사용하는 식으로 동작합니다.
협상: Accept-Encoding과 Content-Encoding
클라이언트는 요청에 Accept-Encoding 헤더로 자신이 풀 수 있는 압축 방식을 나열하고, 서버는 그중 하나를 골라 본문을 압축한 뒤 Content-Encoding 응답 헤더로 실제 사용한 방식을 밝힙니다. 이 협상 결과는 캐시가 압축본과 원본을 구분하도록 반드시 Vary: Accept-Encoding으로 표시해야 합니다.
GET /app.js HTTP/1.1
Host: example.com
Accept-Encoding: br, gzip, deflate
HTTP/1.1 200 OK
Content-Type: application/javascript
Content-Encoding: br
Vary: Accept-Encoding
Content-Length: 24518알고리즘 비교
대표적인 압축 알고리즘은 압축률과 속도에서 서로 다른 균형점을 가집니다.
- gzip: 가장 널리 지원되는 사실상의 표준(DEFLATE 기반). 압축률·속도의 균형이 좋고 호환성이 완벽해, 확실한 폴백으로 항상 지원해야 합니다.
- Brotli (
br): 구글이 만든 알고리즘으로, 정적 자산에서 gzip보다 대략 15~25% 더 작게 압축합니다. 최고 레벨은 압축이 느리므로, 미리 압축해 두는 정적 파일에 특히 유리합니다. 현대 브라우저 대부분이 HTTPS에서 지원합니다. - deflate: gzip과 같은 DEFLATE 알고리즘이지만 헤더 래핑이 달라 일부 구현이 어긋납니다. 실무에서는 gzip을 쓰고 deflate는 잘 쓰지 않습니다.
- zstd (Zstandard): 페이스북이 만든 최신 알고리즘. Brotli급 압축률에 훨씬 빠른 속도를 내 동적 콘텐츠 압축에 매력적이며, 최신 브라우저·CDN이 지원을 넓혀가고 있습니다.
무엇을, 언제 압축할까
압축은 만능이 아닙니다. 이미 압축된 바이너리는 다시 압축하지 마세요. JPEG·PNG·WebP·MP4·zip·gz 같은 파일은 내부적으로 이미 압축돼 있어, 다시 압축하면 크기가 거의 안 줄거나 오히려 커지고 CPU만 낭비합니다. 압축이 효과적인 대상은 텍스트 계열(HTML·CSS·JS·JSON·XML·SVG·폰트 일부)입니다. 또한 아주 작은 응답(수백 바이트)은 압축 헤더 오버헤드가 이득을 상쇄하므로, 보통 1KB 안팎의 최소 크기 임계값을 두고 그보다 큰 텍스트만 압축합니다.
보안 위험: CRIME과 BREACH
압축은 미묘한 보안 위험을 안고 있습니다. 압축은 '반복되는 데이터일수록 더 작아지는' 성질이 있는데, 공격자가 요청을 조금씩 바꿔가며 응답(또는 요청) 크기 변화를 관찰하면 그 안에 든 비밀 값(세션 토큰·CSRF 토큰)을 한 글자씩 추측할 수 있습니다. CRIME은 요청 헤더 압축(TLS/SPDY 수준)을 노렸고, BREACH는 HTTP 응답 본문 압축을 노립니다. 방어책은 (1) 민감한 비밀을 압축되는 응답 본문에 사용자 입력과 함께 반사(reflect)하지 않기, (2) CSRF 토큰을 요청마다 무작위화(마스킹)하기, (3) 길이 은닉(랜덤 패딩) 등입니다. gzip 자체를 끄기보다 이런 애플리케이션 수준 대응이 현실적입니다.
Content-Encoding vs Transfer-Encoding
혼동하기 쉬운 두 헤더를 구분해야 합니다. Content-Encoding은 리소스 자체의 표현이 압축됐다는 뜻으로, 종단 간(end-to-end) 속성입니다. 캐시에 저장되는 것도 압축된 본문이고, ETag도 압축된 표현 기준입니다. 반면 Transfer-Encoding: chunked(또는 gzip)는 이번 연결 구간의 전송 방식만을 가리키는 홉 간(hop-by-hop) 속성으로, 본문 길이를 미리 모를 때 조각으로 나눠 보내는 용도입니다. 실무 웹 성능 최적화에서 압축은 거의 항상 Content-Encoding으로 하며, Transfer-Encoding은 스트리밍 전송 메커니즘으로 이해하면 됩니다.