압축 설정, 텍스트 응답부터 줄입니다
압축 대상 형식과 협상 헤더를 확인해 전송량을 줄이고 중복 압축을 피합니다.

- 압축 대상 형식 목록과 최소 크기를 정했다
- 정적 파일은 사전 압축, 동적 응답은 실시간 압축으로 나눴다
- 현재 어느 계층이 압축하는지 응답 헤더로 확인했다
압축 대상은 텍스트 응답입니다
압축으로 얻는 효과는 응답 종류에 따라 크게 다릅니다. 문서, 스타일, 스크립트, 데이터 응답처럼 텍스트로 된 내용은 크게 줄어듭니다. 반대로 이미지나 영상처럼 이미 압축된 형식은 다시 압축해도 거의 줄지 않고 계산 비용만 늘어납니다. 그래서 설정의 첫 단계는 대상 형식 목록을 정하는 일입니다. 두 번째 단계는 최소 크기를 정하는 일입니다. 아주 작은 응답은 압축해도 이득이 없고 오히려 커질 수 있으므로, 일정 크기 이상만 압축하도록 둡니다. 3단계는 압축 수준을 정하는 일입니다. 높일수록 작아지지만 계산 시간이 늘어나므로, 수준 값을 2개만 두고 정적과 동적에 나눠 씁니다.
미리 압축해 두면 계산 비용이 사라집니다
정적 파일은 요청마다 압축할 필요가 없습니다. 배포 시점에 압축본을 함께 만들어 두고, 요청이 오면 그 파일을 그대로 보내면 계산 비용이 0이 됩니다. 이 방식에서는 압축 수준을 높게 설정해도 부담이 없으므로 용량이 더 줄어듭니다. 동적으로 생성되는 응답은 미리 만들 수 없으므로 요청 시 압축하되 수준을 중간으로 둡니다. 그래서 설정을 두 갈래로 나눕니다. 정적 파일은 사전 압축과 높은 수준, 동적 응답은 실시간 압축과 중간 수준입니다. 이 구분 없이 하나의 수준으로 통일하면 한쪽은 느리고 다른 쪽은 덜 줄어듭니다.
전송량 감소를 계산합니다
학습용 가정으로 계산합니다. 가정값은 텍스트 응답 하나가 압축 전 180킬로바이트, 압축 후 42킬로바이트이고 월 요청이 200,000건이라고 두겠습니다. 건당 절감은 138킬로바이트입니다. 월 절감은 27,600,000킬로바이트이고 기가바이트로는 27.6기가바이트입니다. 이것이 중간 계산값입니다. 최종 효과는 요금과 속도 두 가지로 나타납니다. 전송 요금이 줄고, 느린 회선 사용자의 다운로드 시간이 줄어듭니다. 특히 모바일 회선에서는 전송 시간이 체감의 큰 부분이므로, 압축은 비용이 거의 없는 성능 개선 수단이고, 설정은 1회로 끝납니다.
중간 계층에서 이미 압축하는 경우가 있습니다
결론을 뒤집는 조건은 중복 처리입니다. 전송 서비스가 이미 압축을 수행하고 있으면 원본 서버에서도 압축할 필요가 없고, 두 번 압축하면 계산만 낭비됩니다. 그래서 설정 전에 대표 경로 5개의 응답 헤더를 확인해 어느 계층이 압축하고 있는지 봅니다. 두 번째 조건은 협상 헤더입니다. 중간 캐시가 압축 여부를 구분하지 않고 저장하면, 압축을 지원하지 않는 클라이언트에게 압축된 응답이 갈 수 있습니다. 그래서 응답이 달라지는 조건을 선언해야 합니다. 세 번째는 스트리밍 응답입니다. 조금씩 내려보내는 응답에 압축을 걸면 버퍼링 때문에 첫 바이트가 늦어질 수 있습니다.
성능 최적화 실행 전 점검표
- 압축 대상 형식 목록과 최소 크기를 정했다
- 정적 파일은 사전 압축, 동적 응답은 실시간 압축으로 나눴다
- 현재 어느 계층이 압축하는지 응답 헤더로 확인했다
- 응답이 달라지는 조건을 선언했다
이 가이드의 근거 문서
출처 확인일: 2026-10-19. 공식 문서에 기반한 편집 가이드이며 직접 수행한 벤치마크가 아닙니다. 비용 사례는 명시된 가정에 한합니다.
오류 제보 방법