2026년 4월 30일 Cloudflare가 공유 사전 압축(Compression Dictionaries, RFC 9842) 의 통과(passthrough) 베타를 공개했습니다. 아직 널리 알려지지 않았지만 웹 성능 관점에서 오랜만에 등장한 큰 변화입니다.

한마디로 정리하면 이렇습니다. 브라우저가 이미 캐시한 이전 버전을 사전(dictionary)으로 삼아, 새 버전과의 차이만 압축·전송한다. JavaScript 번들·CSS·API 응답처럼 버전이 자주 갱신되는 리소스에서 크기 감소 효과가 극적입니다.

왜 이게 큰 변화인가

기존 압축(gzip, brotli)은 매 요청마다 응답 자체를 통째로 압축합니다. 이전에 사용자가 어떤 버전을 받았는지 모르니, 매번 같은 부트스트랩 코드·같은 라이브러리 코드·같은 헤더를 새로 압축해서 보냅니다.

공유 사전 압축은 반대 방향입니다.

  • 브라우저: “나 지난주에 app-v3.2.js(500KB)를 받아 캐시에 갖고 있어.”
  • 서버: “그러면 새 버전 app-v3.3.js와 v3.2와의 차이만 계산해서 15KB로 압축해서 줄게.”

버전이 자주 갱신되지만 대부분의 코드가 유지되는 SPA·프론트엔드 번들·API 응답에서 크기 감소가 극적입니다. Cloudflare 테스트에서 최대 97% 감소가 관찰됐다고 합니다.

인코딩 방식 — DCB / DCZ

두 가지 인코딩 방식이 표준화됐습니다.

  • DCB (Dictionary Compressed Brotli): Brotli 알고리즘 + 공유 사전.
  • DCZ (Dictionary Compressed Zstandard): Zstd 알고리즘 + 공유 사전.

브라우저가 지원하는 인코딩을 Accept-Encoding 헤더로 알려주고, 서버가 그에 맞는 사전 기반 압축을 반환합니다. 사전이 없으면 일반 brotli/zstd로 자동 폴백.

어떻게 동작하는가 — 조금 더 자세히

  1. 사용자가 /app.js를 처음 방문. 서버는 일반 brotli로 압축해서 전송하되 응답에 사전 등록용 헤더를 붙임: Use-As-Dictionary: match="/app.js".
  2. 브라우저는 이 응답을 캐시에 저장하고 “이건 사전으로 쓸 수 있다”고 표시.
  3. 다음에 같은 /app.js(새 버전)를 요청할 때 브라우저는 Available-Dictionary: <해시> 헤더로 “나 이 사전 갖고 있어” 알림.
  4. 서버가 그 사전을 인식하면 사전과 새 버전의 delta를 DCB/DCZ로 압축해 반환.

간단히 말해 버전 관리형 델타 전송입니다. 예전 rsync의 delta transfer 아이디어를 HTTP 계층에 옮긴 셈입니다.

어디에 도움이 되는가

  • SPA 프레임워크 번들: React·Vue·Svelte 앱의 vendor·main 청크. 한 번의 소규모 코드 수정에 사용자에게 수십·수백 KB를 다시 보내는 낭비가 사라집니다.
  • API 응답: 같은 사용자·같은 필드 세트를 반복 호출하는 API. 서버가 이전 응답을 사전으로 등록해두면 이후 응답이 극적으로 작아집니다.
  • CSS·폰트: 자주 바뀌지 않지만 갱신 시 전체를 다시 받는 리소스.
  • 모바일·저대역 회선: 데이터 요금·배터리·체감 속도 모두에 이득.

반대로 한 번만 다운로드되는 대용량 미디어(비디오·이미지)에는 효과가 미미합니다. 이미 압축된 포맷이라 delta가 별 이득 없음.

브라우저·서버 지원 현황

  • 크롬: 128+ 부터 실험적 지원. 플래그 없이도 정식 지원 확대 중.
  • 엣지·오페라: 크로미움 기반이라 크롬과 유사.
  • 파이어폭스·사파리: 표준화 이후 단계적 지원 예정.
  • 서버: Cloudflare가 통과 모드부터. 자체 서버는 아직 Nginx·Apache 정식 모듈 부재.

넓은 배포까지는 시간이 걸립니다. 다만 크로미움 사용자 비중이 크니 지금 도입해도 상당수 사용자에게 이득이 즉시 갑니다.

자체 서버에서 흉내 낼 수 있는 대안

TCP-80.NET의 일본 VPS·전용서버로 자체 웹서버를 운영 중이라면, 공유 사전 압축 자체는 아직 Nginx·Apache에 정식 모듈이 없습니다. 다만 비슷한 효과를 내는 세팅은 지금도 가능합니다.

1) Brotli 정적 사전 프리컴프레션

Brotli는 내장된 표준 사전(약 120KB)이 이미 있어서 gzip보다 훨씬 압축률이 좋습니다. 정적 파일을 미리 최고 레벨로 압축해서 서빙.

# 빌드 파이프라인에서
brotli -q 11 -k app.js         # app.js.br 생성

# Nginx에서 정적 br 파일 서빙
# nginx.conf
brotli_static on;
brotli_types text/css application/javascript application/json;

brotli_static on은 ngx_brotli 모듈이 필요합니다. Ubuntu는 libnginx-mod-http-brotli 패키지로 설치.

2) Zstandard 압축 (Cloudflare 자체 사전 없이도)

zstd는 사전 압축을 지원합니다. 특정 도메인의 응답(예: 특정 API의 JSON 응답)을 대상으로 훈련된 사전을 만들어 서버·클라이언트가 공유하면 응답 크기가 30~50% 줄어듭니다.

# 훈련용 샘플 수집
mkdir samples && curl -s -o samples/1.json https://example.com/api/users
# ... 여러 번 반복

# 사전 학습
zstd --train samples/*.json -o api-users.dict

# 사전 기반 압축
zstd -D api-users.dict --long response.json -o response.json.zst

이걸 HTTP 응답에 얹으려면 커스텀 헤더로 사전 버전을 알려주고 클라이언트도 대응 코드가 필요합니다. Cloudflare의 표준 방식과 달리 브라우저 자동 지원은 없어서 SPA에서 자체 fetch·decode 코드로 처리.

3) 청크 분리로 캐시 히트율 극대화

가장 실용적인 대안. 번들을 다음 세 층으로 나눕니다.

  • vendor 청크 — React·Vue 같은 라이브러리. 거의 안 바뀜.
  • route 청크 — 페이지·라우트별 코드. 페이지 하나 수정 시 그 청크만 바뀜.
  • runtime·main — 진짜 자주 바뀌는 소규모 코드.

이렇게 나누면 사용자가 다시 다운로드해야 하는 양이 극적으로 줄어듭니다. 공유 사전 압축의 아이디어를 매우 러프하게 흉내 낸 셈.

4) HTTP/3 QUIC 활성화

압축 자체 이득은 아니지만 전체 페이지 로딩의 병목이 회선 지연인 경우가 많아, HTTP/3로 옮기는 것만으로 체감 속도가 크게 개선됩니다. HTTP/3 도입 가이드에서 자세히 다뤘습니다.

도입 우선순위

지금 당장 프로덕션에 공유 사전 압축을 도입해야 하는가? 대부분의 사이트에는 아직 이른 편입니다. 이유.

  • 브라우저·서버 지원이 아직 통일되지 않음.
  • 세팅 복잡도가 높고 디버깅 도구가 미비.
  • 대부분 사이트의 성능 병목은 압축이 아니라 이미지·서드파티 스크립트·API 지연.

먼저 해야 할 것.

  • brotli 정적 프리컴프레션 (즉시 적용, 무료 이득).
  • 이미지 WebP/AVIF 전환.
  • 서드파티 스크립트 감사.
  • HTTP/3 활성화.

이 위생 작업들이 끝난 다음에 공유 사전 압축을 검토하면 그때는 상대적 이득이 명확해집니다.

마무리

공유 사전 압축은 웹 성능의 다음 층입니다. 지금은 Cloudflare가 먼저 프로덕션에 배포하고 표준을 밀고 있고, 몇 년 안에 CDN·CDN 없는 사이트 모두에 확산될 것 같습니다.

TCP-80.NET의 VPS·전용서버 고객 중 프리컴프레션·HTTP/3·캐시 정책 튜닝을 함께 검토하고 싶으신 분은 @tcp80net 텔레그램으로 문의 주시면 됩니다.

출처 (Source)

이 글은 아래 Cloudflare 공식 changelog를 참고해 tcp-80.net 청중 관점에서 재구성·번역·확장했습니다. 자체 서버 대응 섹션(Nginx brotli, zstd 사전, 청크 분리, HTTP/3)은 원문에 없는 자체 추가 내용입니다.

Cloudflare 제품 옵션명·UI는 시점에 따라 다를 수 있으니 최신 정보는 원문 및 Cloudflare 대시보드에서 확인하시기 바랍니다.