본 콘텐츠는 사용자의 편의를 고려해 자동 기계 번역 서비스를 사용하였습니다. 영어 원문과 다른 오류, 누락 또는 해석상의 미묘한 차이가 포함될 수 있습니다. 필요하시다면 영어 원문을 참조하시기를 바랍니다.
웹 페이지는 지난 10년 동안 매년 6~9% 무거워졌습니다. 이는 웹이 더욱 프레임워크 기반이고, 대화형이며, 미디어가 풍부해짐에 따라 가속화되었습니다. 그 궤도에는 변화가 없습니다. 변화하는 것은 해당 페이지를 얼마나 자주 다시 빌드하고 요청하는 클라이언트의 수라는 점입니다. 둘 다 에이전트 덕분에 급증하고 있습니다.
공유 사전을 사용하면 서버에서 브라우저로의 자산 전송 시간이 축소되므로 페이지가 더 빠르게 로드되고 회선에 불필요한 데이터 전송이 줄어들어, 특히 연결이 느린 재사용자나 방문자에게 유용합니다. 매번 배포 후 전체 JavaScript 번들을 다시 다운로드하는 대신 브라우저는 이미 캐시된 내용을 서버에 알리고 서버는 diffs 파일만 전송합니다.
오늘은 공유 압축 사전에 대한 지원을 살짝 알아보고, 초기 테스트에서 확인한 사항을 보여 드리며, 베타를 직접 사용해 볼 수 있는 시기를 알려드리게 되어 기쁩니다(힌트: 2026년 4월 30일!).
에이전트형 크롤러, 브라우저 등 도구는 반복적으로 엔드포인트에 접속하여 전체 페이지를 가져오며, 정보 조각을 추출하는 경우가 많습니다. 2026년 3월 한 달 동안 Cloudflare 네트워크에서 에이전틱 액터는 전년 대비 최대 60% 증가했습니다.
작년보다 발송되는 모든 페이지가 무거워졌으며, 그 어느 때보다 기계로 더 자주 읽습니다. 에이전트는 단순히 웹을 소비하는 것이 아니라 웹을 구축하는 데 도움을 줍니다. AI 지원 개발로 팀이 더 빠르게 서비스를 제공합니다. 배포, 실험, 반복 빈도를 늘리면 제품 속도에는 좋지만 캐싱에는 좋지 않습니다.
에이전트가 한 줄로 된 수정을 푸시하면 번들러가 다시 청크를 다시하고 파일 이름이 변경되며 전 세계의 모든 사용자가 전체 애플리케이션을 다시 다운로드할 수 있습니다. 코드가 유의미하게 바뀌어서가 아니라 브라우저/클라이언트가 무엇이 변경되었는지 구체적으로 알 방법이 없기 때문입니다. 이는 새로운 URL을 보고 0에서 시작합니다. 기존의 압축은 각 다운로드의 크기에 도움이 되지만, 중복성에는 도움이 되지 않습니다. 클라이언트가 이미 파일의 95%를 캐시했는지 알지 못합니다. 따라서 모든 배포와 모든 사용자, 모든 봇이 반복 바이트를 중복 전송합니다. 하루에 10개의 작은 변경 사항을 전송하면, 사실상 캐싱을 옵트아웃한 것입니다. 하드웨어에 빠르게 병목 현상이 발생하는 웹에서 대역폭과 CPU가 낭비됩니다.
더 자주 재배포되는 더 무거운 페이지에 타격을 주는 요청이 많아질수록 확장하기 위해서는 압축이 더 스마트해져야 합니다.
압축 사전은 치트 시트처럼 작동하는 서버와 클라이언트 간의 공유 참조입니다. 처음부터 응답을 압축하는 대신, 서버에서는 "이전에 캐싱한 적이 있기 때문에 파일의 이 부분을 이미 알고 있습니다"라고 말하고 새로운 내용만 보냅니다. 클라이언트는 동일한 참조를 보유하고 이를 사용하여 압축을 해제하는 동안 전체 응답을 재구성합니다. 사전이 파일의 콘텐츠를 더 많이 참조할 수 있을수록 클라이언트로 전송되는 압축 출력의 크기는 작아집니다.
이미 알려진 것에 기반하여 압축하는 이러한 원칙은 최신 압축 알고리즘이 이전 압축 알고리즘을 능가하는 방법입니다. Brotli에는 HTML 속성 및 문구와 같은 일반적인 웹 패턴의 사전이 내장되어 있습니다. Zstandard는 맞춤형 사전을 위해 특별히 설계되었습니다. 대표적인 콘텐츠 샘플을 제공하면 제공하는 콘텐츠 유형에 최적화된 사전이 생성됩니다. Gzip에는 둘 다 없습니다. 압축하는 동안 실시간으로 패턴을 찾아 사전을 구축해야 합니다. 이러한 “기존 압축” 알고리즘은 현재 Cloudflare에서 사용할 수 있습니다.
공유 사전은 이 원칙을 한 단계 더 발전시켜 이전에 캐시된 버전의 리소스 가 사전이 됩니다. 한 팀이 한 줄로 된 수정 프로그램을 배송하고 나면 모든 사용자가 전체 번들을 다시 다운로드해야 하는 배포 문제를 기억하시나요? 공유 사전을 사용하면 브라우저에는 이미 이전 버전이 캐시되어 있습니다. 서버는 이 요소에 대해 압축하여 diff만 전송합니다. 한 줄 변경 사항이 포함된 500KB 번들을 전송하는 데 불과 몇 KB에 불과합니다. 매일 10만 명의 사용자와 10건의 배포 상황에서, 이는 500GB 전송과 수백 메가바이트의 차이에 해당합니다.
Delta 압축은 브라우저가 이미 가지고 있는 버전을 사전으로 바꿉니다. 이 프로토콜은 서버가 처음 리소스를 제공할 때 Use-As-Dictionary 응답 헤더를 첨부하여 나중에 유용할 것이므로 기본적으로 파일을 유지하도록 브라우저에 지시합니다. 다음 번에 해당 리소스를 요청하면 브라우저에서는 Available-Dictionary 헤더를 다시 보내 서버에 "제가 가진 것입니다."라고 알려줍니다. 그런 다음 서버는 새 버전을 이전 버전으로 압축하고 diff만 전송합니다. 별도의 사전 파일이 필요하지 않습니다.
여기에서 실제 애플리케이션의 성과가 결정됩니다. 버전이 지정된 JS 번들, CSS 파일, 프레임워크 업데이트, 그리고 릴리스마다 점진적으로 변경되는 모든 것이 포함됩니다. 브라우저에 이미 app.bundle.v1.js가 캐시되어 있으며, 개발자가 업데이트하고 app.bundle.v2.js를 배포합니다. Delta 압축은 이러한 버전 간의 diff만 보냅니다. 그 이후의 모든 버전도 차이점입니다. 버전 3은 버전 2에 대해 압축합니다. 버전 47은 버전 46에 대해 압축합니다. 절감된 금액은 초기화되는 것이 아니라 전체 릴리스 내역에 유지됩니다.
커뮤니티에서도 사용자 지정 사전과 동적 사전에 대해 활발하게 논의하고 있습니다 비정적 콘텐츠용 . 이는 향후 과제이지만, 그 의미는 큽니다. 다른 게시물을 위해 저장해 보겠습니다.
공유 사전이 그렇게 강력하다면 왜 모두가 이미 사용하지 않을까요?
마지막으로 이를 시도했을 때 개방형 웹과의 접촉에서 살아남을 수 없었기 때문입니다.
Google에서 출시 2008년에 SDCH(HTTP용 공유 사전 압축)를 Chrome에 일부 얼리어답터에서는 잘 작동하여 페이지 로드 시간이 두 자릿수 개선되었습니다. 하지만 SDCH에 문제가 쌓인 것은 그 누구보다 빠르게 고칠 수 있었습니다.
가장 기억에 남는 것은 압축 부채널 공격(CRIME, BREACH)이었습니다. 연구자들은 공격자가 압축되는 중요한 것(세션 쿠키, 토큰 등)과 함께 콘텐츠를 삽입할 수 있는 경우, 압축된 출력 크기 때문에 비밀 정보가 유출될 수 있음을 보여주었습니다. 공격자는 한 번에 바이트씩 추측하면서 자산 크기가 줄어드는 것을 지켜보면서 모든 비밀을 추출할 때까지 이 과정을 반복할 수 있었습니다.
하지만 보안이 유일한 문제이거나 채택되지 않은 주된 이유는 아니었습니다. SDCH는 동일 출처 정책 위반과 같은 몇 가지 아키텍처 문제를 발견했습니다(아이러니하게도 이것이 부분적으로 우수한 성능을 발휘한 이유이기도 함). 교차 출처 사전 모델은 CORS와 일치할 수 없었으며, 캐시 API와 같은 것들과의 상호 작용에 관한 일부 사양이 부족했습니다. 얼마 지나지 않아 아직 채택이 준비가 되지 않았다는 것이 분명해졌으며, 2017년 Chrome(당시에 지원하는 유일한 브라우저)은 이를 출시 중단했습니다.
웹 커뮤니티가 주도권을 쥐는 데 10년이 걸렸지만, 그만한 가치가 있었습니다.
최신 표준인 RFC 9842: Compression Dictionary Transport는 SDCH를 지지할 수 없었던 주요 설계 격차를 해소합니다. 예를 들어, 광고된 사전은 동일 출처의 응답에 대해서만 사용할 수 있도록 적용하여 부채널 압축 공격을 가능하게 한 많은 조건을 방지합니다.
Chrome 및 Edge는 Firefox와 함께 지원을 제공하여 후속 조치를 취합니다. 현재 이 표준은 광범위하게 채택되고 있지만, 완전한 브라우저 간 지원은 아직 따라잡고 있습니다.
RFC는 보안 문제를 완화하지만 사전 전송은 항상 구현하기가 복잡했습니다. 원본은 사전을 생성하고, 올바른 헤더로 이를 제공하며, 모든 요청을 검사하여 Available-Dictionary 일치를 확인하고, 응답을 즉시 Delta-압축하고, 클라이언트가 사전을 갖고 있지 않을 때 정상적으로 폴백해야 할 수 있습니다. 캐싱도 복잡해집니다. 인코딩과 사전 해시에 따라 응답이 다르므로 사전 버전마다 별도의 캐시 변형이 생성됩니다. 배포 도중에 기존 사전이 있는 클라이언트, 새 사전이 있는 클라이언트, 없는 클라이언트가 있습니다. 캐시가 각각 별도의 사본을 저장합니다. 적중률 감소, 스토리지 증가, 사전 자체는 일반적인 HTTP 캐싱 규칙에 따라 최신 상태를 유지해야 합니다.
이러한 복잡성은 조정의 문제입니다. 그리고 바로 에지에 속하는 그러한 종류의 것입니다. CDN은 이미 모든 요청의 앞에 위치하고, 압축을 관리하며, 캐시 변형을 처리합니다(이 스페이스에서 곧 발표할 블로그를 확인하세요).
Cloudflare에서 공유 사전 지원을 구축하는 방법
공유 사전 압축은 브라우저와 원본 사이 스택의 모든 계층에 적용됩니다. 고객의 관심이 매우 높아서 이미 RFC 작성자인 Patrick Meenan의 dictionary-worker와 같은 자체 구현을 구축한 사람들도 있었습니다. 이는 WASM으로 컴파일된 Zstandard를 사용하여 Cloudflare Worker 내에서 전체 사전 수명 주기를 실행합니다(예를 들어). 우리는 누구나 이를 이용할 수 있고 최대한 쉽게 구현할 수 있기를 바랍니다. 그래서 우리는 배관을 시작하여 세 단계에 걸쳐 플랫폼 전체에 롤아웃할 예정입니다.
Phase 1: 통과 지원은 현재 개발 중입니다. Cloudflare는 Use-As-Dictionary, Available-Dictionary, 그리고 dcb 및 dcz 콘텐츠 인코딩과 같이 공유 사전에 필요한 헤더 및 인코딩을 제거, 수정 또는 재압축하지 않고 전달합니다. 캐시 키는 Available-Dictionary 및 Accept-Encoding 에 따라 달라지도록 확장되어 사전 압축된 응답이 올바르게 캐시됩니다. 이 단계에서는 원본에서 자신의 사전을 관리하는 고객에게 서비스를 제공합니다.
저희는 2026년 4월 30일까지 1단계의 오픈 베타를 준비할 계획입니다. 이를 사용하려면 이 기능이 활성화된 Cloudflare 영역에 있어야 하며, 올바른 헤더(Use-As-Dictionary, Content-Encoding: dcb 또는 dcz)가 포함된 사전 압축 응답을 제공하는 원본이 있어야 하며, 방문자는 Accept-Encoding 에서 dcb/dcz 를 광고하고 Available-Dictionary 를 보내는 브라우저를 사용해야 합니다. 현재 Chrome 130+ 및 Edge 130+ 버전이 제공되며 현재 Firefox 지원은 진행 중입니다.
언제 사용할 수 있는지 변경 로그와 사용 방법에 대한 더 많은 문서를 주시하세요.
Cloudflare는 이미 내부적으로 통과 테스트를 시작했습니다. 제어 테스트에서 우리는 두 개의 js 번들을 차례로 배포했습니다. 동일한 웹 애플리케이션이 연속적으로 배포되는 버전 간의 국지적 변경 사항이 몇 가지 있다는 점을 제외하고는 거의 동일했습니다. 비압축 자산의 크기는 272KB입니다. Gzip은 이 비용을 92.1KB로 줄였으며, 66%라는 탄탄한 수치입니다. 이전 버전을 사전으로 사용하여 DCZ를 통한 공유 사전 압축을 통해 동일한 자산은 2.6KB로 감소했습니다. 이는 이미 압축된 자산에 비해 97% 감소한 수치입니다.
같은 랩 테스트에서 우리는 클라이언트로부터 첫 번째 바이트 시간(TTFB)과 전체 다운로드 완료라는 두 가지 타이밍 이정표를 측정했습니다. 첫 번째 바이트 시간 결과는 보여주지 않는 것을 보여준다는 점이 흥미롭습니다. 캐시 누락 시(DCZ가 원본의 사전에 대해 압축해야 하는 경우) TTFB는 gzip보다 약 20ms 느릴 뿐입니다. 전송할 때의 오버헤드는 거의 무시할 수 있습니다.
다운로드 시간에서 차이가 발생합니다. 캐시 누락 시 DCZ는 gzip의 경우 166ms(81% 개선)에 비해 31ms 만에 완료되었습니다. 캐시 적중 16ms 대 143ms(89% 개선). 응답 규모가 너무 작아 시작할 때 약간의 페널티를 적용해도 훨씬 앞서 마무리할 수 있습니다.
최소한의 JS 번들 차이를 시뮬레이션하는 초기 랩 결과로, 사전과 자산 간의 실제 차이에 따라 결과는 달라질 수 있습니다.
2단계: 이 단계부터 Cloudflare가 작업을 시작합니다. 원본에서 사전 헤더, 압축, 폴백 로직을 처리하는 대신, 이 단계에서 사용자는 Cloudflare에 규칙을 통해 사전으로 사용해야 하는 자산을 알리면 나머지는 Cloudflare가 대신 관리합니다. 우리는 Use-as-Dictionary 헤더를 삽입하고, 딕셔너리 바이트를 저장하며, 새 버전을 이전 버전에 대해 Delta 압축하고, 각 클라이언트에 올바른 변형을 제공합니다. 원본은 정상적인 응답을 제공합니다. 모든 사전적 복잡성이 귀사의 인프라에서 우리 인프라로 옮겨갑니다.
이를 보여주기 위해 실제로 어떻게 보이는지 보여주는 라이브 데모를 구축했습니다. 여기에서 사용해 보세요: 압축(사전 포함)을 할 수 있나요?
데모에서는 일반적인 프로덕션 단일 페이지 애플리케이션 번들을 모방하여 약 94KB의 새로운 JavaScript 번들을 매분 배포합니다. 코드의 대부분은 배포 간에 정적입니다. 매번 작은 구성 블록만 변경하면 됩니다. 이는 번들의 대부분이 변경되지 않은 프레임워크와 라이브러리 코드인 실제 배포 환경에서도 그대로 반영됩니다. 첫 번째 버전이 로드되면 Cloudflare의 에지가 이를 사전으로 저장합니다. 다음 배포가 도착하면 브라우저는 이미 보유하고 있는 버전의 해시를 전송하고, 에지는 이에 대해 새 번들을 Delta-압축합니다. 결과: 94KB는 약 159바이트 로 압축됩니다. 이는 gzip에 비해 99.5% 감소한 수치입니다. 전송되는 유일한 것이 실제 차이점뿐이기 때문입니다.
데모 사이트에는 curl이나 브라우저를 통해 압축 비율을 직접 확인할 수 있는 설명이 포함되어 있습니다.
3단계: 웹 사이트를 대신하여 사전이 자동으로 생성됩니다. 고객이 사전으로 사용할 자산을 지정하는 대신 Cloudflare는 이러한 자산을 자동으로 식별합니다. Cloudflare의 네트워크는 수백만 개의 사이트, 수십억 건의 요청, 모든 신규 배포 등 네트워크에 흐르는 모든 리소스의 모든 버전을 이미 파악하고 있습니다. 연속적인 응답이 대부분의 콘텐츠를 공유하지만, 해시가 다른 URL 패턴을 네트워크에서 관찰하면, 리소스에 버전이 지정되어 Delta 압축 대상이라는 강력한 신호를 보내는 것입니다. 이전 버전을 사전으로 저장하고 이후 버전을 압축합니다. 고객 구성이 필요 없습니다. 유지 보수가 필요 없습니다.
이것은 간단한 아이디어이지만, 실제로는 어렵습니다. 개인 데이터를 공개하지 않는 사전을 안전하게 생성하고 어떤 사전이 가장 큰 이점을 제공할 트래픽을 식별하는 것은 실제 엔지니어링 문제입니다. 하지만 Cloudflare는 적절한 부분을 갖고 있습니다. 우리는 전체 네트워크에서 트래픽 패턴을 보고, 사전이 있어야 하는 캐시 계층을 이미 관리하고 있습니다. 그리고 클라이언트에 대한 RUM 비콘 은 사전이 실제로 압축 성능을 개선하는지 확인하기 위한 유효성 검사 루프를 제공하여, 이를 제공하기 전에 확정하는 데 도움이 될 수 있습니다. 트래픽 가시성, 에지 스토리지, 가상 테스트의 조합 덕분에 자동 생성이 가능해지지만, 아직 이해해야 할 부분이 많습니다.
3단계에서 얻을 수 있는 성능 및 대역폭 이점이 바로 동기를 부여하는 핵심입니다. 이것이 바로 Cloudflare를 사용하는 모든 사람이 공유 사전에 액세스할 수 있는 이유입니다. 여기에는 엔지니어링 시간으로 사용자 지정 사전을 수동으로 구현할 수 없는 수백만 개의 영역이 포함됩니다.
웹 역사의 대부분에서 압축은 상태 비저장 방식이었습니다. 클라이언트가 이전에 아무 것도 본 적이 없는 것처럼 모든 응답을 압축했습니다. 공유 사전은 압축에 메모리를 제공하는 방식으로 변화합니다.
이것은 5년 전보다 지금이 더 중요합니다. 에이전틱 코딩 도구는 배포 간격을 단축하는 동시에 이러한 코딩 도구를 사용하는 트래픽의 비중을 늘리고 있습니다. 오늘날 AI 도구는 큰 차이를 생성할 수 있지만, 에이전트는 코드를 변경할 때 더 많은 컨텍스트를 확보하고 신중을 기하고 있습니다. 더 빈번한 릴리스와 더 많은 자동화 클라이언트와 결합하여 모든 요청에서 더 많은 중복 바이트를 필요로 합니다. Delta 압축은 전송당 바이트 수와 발생해야 하는 전송 수를 줄임으로써 그 방정식의 양쪽에 도움이 됩니다.
공유 사전을 표준화하는 데는 수십 년이 걸렸습니다. Cloudflare는 사용자의 사이트에 접촉하는 모든 클라이언트가 작동하는 인프라를 구축하는 것을 지원합니다. 1단계 베타는 4월 30일에 시작되며, 여러분도 꼭 체험해보시기 바랍니다.
_____
1봇 = 전체 HTTP 요청의 ~31.3% AI = 전체 봇 트래픽의 ~29-30% (2026년 3월).