무슨 일인가요
Cloudflare는 2026년 9월 1일 블로그에 '캐시 트랜스코딩' 프로토타입을 공개했습니다. 지금까지 Cloudflare CDN은 오리진 서버가 보낸 콘텐츠 인코딩(gzip, brotli, zstd, 비압축)을 그대로 캐시에 저장했습니다. 그 결과 같은 콘텐츠의 여러 인코딩이 캐시 계층에 함께 남아 저장 공간을 낭비했고, 분산 저장 시스템의 메모리 비용은 계속 오르고 있었습니다. 공식
새 방식은 Cloudflare의 Rust 기반 프록시 프레임워크 Pingora 안에서, 압축 가능한 자산을 디스크에 쓰기 전에 Zstandard로 인코딩합니다. 압축은 캐시 필 때 한 번만 하고, 해제는 클라이언트에 서브할 때마다 합니다. 공식 블로그는 "인코딩 비용은 자산이 캐시에 들어올 때 한 번 치르지만, 저장과 대역폭 절감은 그 자산이 재사용될 때마다 이어진다"고 설명했습니다. 공식
오리진 응답
gzip·brotli·zstd·비압축 혼재
캐시 필
Zstandard로 1회 인코딩
디스크 저장
원본의 약 1/3 크기
서브
요청마다 디코딩 (641 MB/s)
숫자로 보는 실험
2.834배
평균 압축비
적용 대상 자산의 디스크 크기가 원본의 약 3분의 1로
67.3% / 22.3%
적용 대상 비중 (요청 / 바이트)
압축 가능한 텍스트 자산 기준
232 → 641 MB/s
인코딩 → 디코딩 처리량
바이트당 4.31 ns → 1.56 ns
4 KiB
트랜스코딩 최소 크기
이 기준으로도 측정된 절감 효과의 대부분을 확보
| 항목 | 처리량 |
|---|---|
| 인코딩 (캐시 필 시 1회) | 232 |
| 디코딩 (서브 시 매번) | 641 |
출처: Cloudflare 블로그 (2026-09-01), 바이트당 4.31 ns / 1.56 ns 환산값
적용 대상인 압축 가능한 텍스트는 전체 요청의 67.3%를 차지하지만 바이트 기준으로는 22.3%입니다. 이 자산들의 평균 압축비는 2.834배였습니다. 공식 4 KiB 이상 자산만 트랜스코딩해도 측정된 저장 절감 효과의 거의 전부를 얻었고, 테스트 조건에서 CPU 사용량 증가는 몇 퍼센트 수준이었습니다. 공식 검증은 캐시 서버 10대에서 100만 건 이상의 요청으로 이뤄졌습니다. 공식
같은 회사가 8월 27일에 올린 글에서는 1.1.1.1 DNS 캐시 항목의 메모리 구조를 다섯 차례 바꿔 항목당 953바이트를 420바이트로 56% 줄이고, 전체 서버군에서 약 100테라바이트의 메모리를 확보했다고 밝혔습니다. 공식 두 글을 합쳐 보면 지금 Cloudflare 인프라 팀의 관심은 새 기능보다 저장·메모리 단가에 있다고 읽을 수 있습니다. 추정
왜 이제야 하나요
해커뉴스 스레드(138점, 댓글 62개)에서는 Zstandard의 빠른 디코딩, 음수 압축 레벨, 소형 객체용 사전 지원을 장점으로 꼽는 의견이 많았습니다. 한 이용자는 "zstd 3에서 5 레벨은 디스크나 네트워크 병목을 거의 만들지 않는다"고 적었습니다. 보도 반면 HTTP 범위 요청을 압축 캐시에서 어떻게 처리할지는 논쟁거리였고, zstd의 프레임 단위 구조나 seekable 포맷으로 풀 수 있다는 제안이 나왔습니다. 보도
"왜 진작 하지 않았느냐"는 반응도 있었습니다. 저장과 대역폭이 충분히 쌌을 때는 엔지니어링 비용이 더 컸지만, 최근 공급망 제약으로 하드웨어 단가가 오르면서 계산이 바뀌었다는 해석입니다. 보도
무엇을 보면 되나요
- 프로덕션 적용 여부: Cloudflare가 후속 글에서 전체 네트워크 절감량과 실제 CPU 비용을 공개하는지가 이 실험의 성패를 가릅니다.
- 압축 레벨 선택: 현재 결과는 낮은 레벨 기준입니다. 레벨을 올렸을 때 인코딩 비용과 압축비의 교환비가 어떻게 바뀌는지 봐야 합니다.
- 자사 캐시에 적용하려면: 자산의 인코딩 분포(요청 대비 바이트 비중)부터 재는 것이 순서입니다. 이 글의 67.3% 대 22.3%라는 숫자가 그 출발점입니다.
