🖼️ 인포그래픽

🖼️ 4컷 인포그래픽

💡 한 줄 요약

Cloudflare는 잦은 배포와 에이전트 트래픽으로 기존 캐싱이 약해지는 웹에서, 브라우저가 이미 가진 이전 리소스를 사전처럼 활용해 변경분만 전송하는 공유 딕셔너리 압축을 엣지에서 지원하려 한다.

📌 핵심 요약

• 웹 페이지는 지난 10년 동안 매년 6~9%씩 무거워졌고, 동시에 에이전트형 크롤러·브라우저·도구가 반복적으로 페이지와 엔드포인트를 요청하면서 전송량과 요청 빈도가 함께 증가하고 있다.
• AI 보조 개발로 배포와 실험이 더 잦아지면, 작은 코드 변경에도 번들 파일명과 청크가 바뀌어 브라우저가 전체 애플리케이션을 다시 내려받는 문제가 커진다.
• 공유 딕셔너리는 클라이언트가 이미 캐시한 이전 버전의 리소스를 압축 기준으로 삼아, 서버가 새 파일 전체가 아니라 변경분에 가까운 압축 결과만 보내도록 하는 방식이다.
• 과거 Chrome의 SDCH는 성능 개선 가능성을 보였지만 보안 사이드채널, Same-Origin Policy와 CORS 문제, 캐시 API와의 상호작용 부족 등으로 중단되었고, 현대 표준인 RFC 9842가 같은 출처 제한 등으로 이를 보완했다.
• Cloudflare는 우선 공유 딕셔너리에 필요한 헤더와 인코딩을 통과시키고 캐시 키를 확장하는 1단계 패스스루 지원을 준비 중이며, 내부 테스트에서는 272KB 자바스크립트 자산이 DCZ 공유 딕셔너리 압축으로 2.6KB까지 줄었다.

🧩 주요 포인트

1. 웹 페이지는 지난 10년 동안 매년 6~9%씩 무거워졌고, 동시에 에이전트형 크롤러·브라우저·도구가 반복적으로 페이지와 엔드포인트를 요청하면서 전송량과 요청 빈도가 함께 증가하고 있다.
2. AI 보조 개발로 배포와 실험이 더 잦아지면, 작은 코드 변경에도 번들 파일명과 청크가 바뀌어 브라우저가 전체 애플리케이션을 다시 내려받는 문제가 커진다.
3. 공유 딕셔너리는 클라이언트가 이미 캐시한 이전 버전의 리소스를 압축 기준으로 삼아, 서버가 새 파일 전체가 아니라 변경분에 가까운 압축 결과만 보내도록 하는 방식이다.
4. 과거 Chrome의 SDCH는 성능 개선 가능성을 보였지만 보안 사이드채널, Same-Origin Policy와 CORS 문제, 캐시 API와의 상호작용 부족 등으로 중단되었고, 현대 표준인 RFC 9842가 같은 출처 제한 등으로 이를 보완했다.
5. Cloudflare는 우선 공유 딕셔너리에 필요한 헤더와 인코딩을 통과시키고 캐시 키를 확장하는 1단계 패스스루 지원을 준비 중이며, 내부 테스트에서는 272KB 자바스크립트 자산이 DCZ 공유 딕셔너리 압축으로 2.6KB까지 줄었다.

🧠 상세 정리

1. 무거워지는 웹과 에이전트 트래픽

글은 웹 페이지가 지난 10년 동안 매년 6~9%씩 무거워졌다는 문제의식에서 출발한다. 프레임워크 중심 개발, 상호작용성 증가, 미디어가 풍부한 페이지 구성이 이 흐름을 만들었고, 저자는 이 추세가 멈추지 않을 것이라고 본다. 여기에 에이전트형 크롤러와 브라우저, 여러 자동화 도구가 반복적으로 엔드포인트를 호출하면서 같은 페이지를 더 자주 가져오는 변화가 겹친다. 2026년 3월 Cloudflare 네트워크에서 에이전트 행위자는 전체 요청의 10%에 조금 못 미쳤고, 전년 대비 약 60% 증가한 것으로 제시된다. 즉 문제는 단순히 페이지가 커졌다는 데 있지 않고, 더 무거운 페이지가 더 많은 클라이언트에 의해 더 자주 요청된다는 데 있다.

2. 잦은 배포가 기존 캐싱을 약하게 만드는 이유

저자는 에이전트가 웹을 소비하는 데 그치지 않고 웹을 만드는 과정에도 관여한다고 설명한다. AI 보조 개발은 팀이 더 빠르게 수정하고, 실험하고, 배포하도록 만들지만, 이 변화는 캐싱 관점에서는 불리하게 작동한다. 한 줄짜리 수정만 있어도 번들러가 청크를 다시 나누고 파일명이 바뀌면 브라우저는 새 URL을 보고 기존 캐시와의 관계를 알지 못한다. 결과적으로 실제로는 대부분 같은 코드인데도 사용자는 전체 애플리케이션을 다시 내려받게 된다. 전통적 압축은 각 다운로드의 크기를 줄일 수는 있지만, 클라이언트가 이미 파일의 95%를 갖고 있다는 사실을 활용하지 못해 중복 전송을 막지 못한다.

3. 공유 딕셔너리의 핵심 원리

공유 딕셔너리는 서버와 클라이언트가 함께 참조하는 압축용 기준 자료를 사용하는 방식이다. 서버는 응답을 처음부터 압축하는 대신, 클라이언트가 이미 캐시한 부분을 알고 있다고 가정하고 새로 필요한 내용만 더 효율적으로 전달한다. 클라이언트는 같은 참조 자료를 갖고 있기 때문에, 전달받은 압축 결과를 풀어 전체 응답을 재구성할 수 있다. 글은 이를 일종의 치트시트처럼 설명하며, 딕셔너리가 파일 안의 더 많은 내용을 참조할수록 실제 네트워크를 통해 전송되는 압축 결과는 더 작아진다고 말한다. 이 접근은 웹에서 반복되는 패턴을 미리 이용하는 Brotli나 사용자 지정 딕셔너리를 중시하는 Zstandard의 원리를 한 단계 더 확장한 것이다.

4. 이전 리소스를 딕셔너리로 삼는 델타 압축

공유 딕셔너리의 중요한 확장은 별도의 딕셔너리 파일이 아니라 브라우저가 이미 캐시한 이전 버전의 리소스를 딕셔너리로 삼는다는 점이다. 서버가 처음 리소스를 제공할 때 Use-As-Dictionary 응답 헤더를 붙이면, 브라우저는 그 파일이 나중에 유용할 수 있음을 알고 보관한다. 이후 같은 계열의 새 리소스를 요청할 때 브라우저는 Available-Dictionary 헤더로 자신이 가진 딕셔너리를 서버에 알린다. 서버는 새 버전을 이전 버전에 대해 압축해 전체 파일이 아니라 차이에 가까운 결과만 전송한다. 글은 app.bundle.v1.js에서 app.bundle.v2.js로 이어지는 배포 예시를 통해, 버전 3은 버전 2를, 버전 47은 버전 46을 기준으로 압축할 수 있어 절감 효과가 릴리스 이력 전체에 이어진다고 설명한다.

5. 과거 SDCH의 실패와 보안 문제

글은 공유 딕셔너리 압축이 처음 등장한 아이디어가 아니며, 2008년 Chrome에 실렸던 SDCH 사례를 되짚는다. SDCH는 일부 초기 도입 사례에서 페이지 로드 시간을 두 자릿수 비율로 개선하는 등 성능 잠재력을 보였지만, 공개 웹의 복잡성을 견디지 못했다. 대표적 문제로는 CRIME, BREACH 같은 압축 사이드채널 공격이 언급된다. 공격자가 민감한 값과 함께 압축되는 내용을 조작할 수 있으면, 압축 결과의 크기 변화를 관찰해 세션 쿠키나 토큰 같은 비밀을 바이트 단위로 추측할 수 있었다. 다만 저자는 보안만이 유일한 문제는 아니었고, 실제 채택 실패에는 구조적 문제가 함께 있었다고 설명한다.

6. 현대 표준 RFC 9842가 보완한 지점

SDCH는 Same-Origin Policy를 침해하는 방식의 교차 출처 딕셔너리 모델을 가졌고, 이것이 성능에는 도움이 되었지만 CORS와 조화되기 어려웠다. 또한 Cache API 같은 요소와 어떻게 상호작용해야 하는지에 대한 명세도 부족했다. 결국 Chrome은 당시 유일한 지원 브라우저였던 SDCH를 2017년에 제거했다. 이후 웹 커뮤니티가 다시 이 문제를 표준으로 다루기까지는 긴 시간이 걸렸지만, 글은 현대 표준인 RFC 9842, Compression Dictionary Transport가 핵심 설계 공백을 닫았다고 평가한다. 예를 들어 광고된 딕셔너리를 같은 출처의 응답에만 사용할 수 있도록 강제해, 과거 사이드채널 공격 조건 상당수를 줄인다.

7. 구현 복잡성을 엣지에서 처리해야 하는 이유

RFC가 보안 문제를 줄였더라도 딕셔너리 전송을 실제 서비스에 구현하는 일은 여전히 복잡하다. 오리진은 딕셔너리를 생성하고 올바른 헤더로 제공해야 하며, 모든 요청에서 Available-Dictionary와 일치하는지 확인하고, 새 응답을 즉석에서 델타 압축하며, 딕셔너리가 없는 클라이언트에는 자연스럽게 폴백해야 한다. 캐싱도 단순하지 않다. 응답은 인코딩뿐 아니라 딕셔너리 해시에도 따라 달라지기 때문에 딕셔너리 버전마다 별도 캐시 변형이 생긴다. 배포 중에는 오래된 딕셔너리를 가진 클라이언트, 새 딕셔너리를 가진 클라이언트, 딕셔너리가 없는 클라이언트가 동시에 존재해 캐시 적중률과 저장 공간 문제가 커진다. 저자는 이런 조정 문제가 모든 요청 앞에 위치하고 압축과 캐시 변형을 이미 관리하는 CDN 엣지에 적합하다고 본다.

8. Cloudflare의 단계적 지원과 초기 실험 결과

Cloudflare는 공유 딕셔너리 압축이 브라우저와 오리진 사이의 여러 계층에 걸친 기능이라고 보고, 이를 플랫폼 전반에 단계적으로 도입하려 한다. 1단계는 패스스루 지원으로, Use-As-Dictionary, Available-Dictionary, dcb, dcz 같은 공유 딕셔너리 관련 헤더와 콘텐츠 인코딩을 제거하거나 재압축하지 않고 전달하는 것이다. 또한 캐시 키가 Available-Dictionary와 Accept-Encoding에 따라 달라지도록 확장해 딕셔너리 압축 응답이 올바르게 캐시되게 한다. 이 단계의 오픈 베타는 2026년 4월 30일로 계획되어 있으며, 사용하려면 기능이 켜진 Cloudflare 존, 올바른 헤더와 dcb 또는 dcz 인코딩을 제공하는 오리진, 그리고 Chrome 130 이상이나 Edge 130 이상 같은 지원 브라우저가 필요하다. 내부 통제 테스트에서는 272KB 자바스크립트 자산이 gzip으로 92.2KB가 되었고, 이전 버전을 딕셔너리로 사용한 DCZ 압축에서는 2.6KB까지 줄어 uncompressed 대비 99%, gzip 대비 97% 작은 결과가 나왔다.

🧾 핵심 주장 / 시사점

• 이 글의 핵심은 압축률 자체보다 캐시가 잦은 배포를 따라가지 못하는 구조적 문제에 있다. 에이전트 트래픽과 AI 보조 개발이 동시에 늘면, 웹은 더 많이 요청되고 더 자주 바뀌며 기존 URL 기반 캐싱은 점점 비효율적이 된다.
• 공유 딕셔너리는 새 리소스를 독립된 파일로 보지 않고, 이전 버전과의 관계 속에서 전송한다는 점에서 배포 중심 웹에 잘 맞는다. 특히 자바스크립트 번들처럼 릴리스마다 대부분은 같고 일부만 바뀌는 자산에서 효과가 크다.
• 기술의 성공 여부는 알고리즘보다 운영 복잡성을 누가 감당하느냐에 달려 있다. 글이 CDN 엣지를 강조하는 이유는 딕셔너리 선택, 캐시 변형, 폴백, 헤더 전달 같은 조정 비용이 개별 오리진보다 네트워크 계층에서 처리되기 쉽기 때문이다.

✅ 액션 아이템

• 웹이 연 6~9%씩 커지고 에이전트형 반복 요청이 증가하는 구간에서 공유 딕셔너리 적용 대상을 우선순위로 정한다.
• SDCH 중단 원인인 보안 사이드채널·동일 출처 정책·캐시 API 이슈를 RFC 9842 보완 항목과 대조해 적용 제약을 재정의한다.
• Cloudflare 1단계 패스스루에서 헤더·인코딩 통과와 캐시 키 확장 동작이 배포 빈발 상황의 번들 재요청을 얼마나 낮추는지 점검한다.

❓ 열린 질문

• 동일 출처 제한이 실제 배포 환경에서 CORS 의존 흐름에 어떤 경로로 제한을 주는가?
• 272KB 자바스크립트 번들에서 2.6KB까지 내려간 압축 효과가 다른 번들 크기와 형식에도 동일하게 재현되는가?
• 에이전트형 요청이 잦고 변경분이 자주 생기는 경우 공유 딕셔너리가 전체 애플리케이션 재다운로드를 실제로 충분히 줄일 수 있는가?