# Cloudflare 캐시 트랜스코딩, 텍스트 자산 3분의 1로 줄인 실험

> Cloudflare가 9월 1일 공개한 캐시 트랜스코딩 프로토타입을 정리합니다. Zstandard와 Pingora로 캐시 저장 용량을 얼마나 줄였고 어떤 비용을 치렀는지 공식 블로그 수치로 봅니다.

- 출처 사이트: 머니피셜 (https://aifficial.net/money/posts/cloudflare-cache-transcoding-zstd/)
- 발행: 2026-09-03
- 카테고리: 창업 사례 · 태그: Cloudflare, 인프라 비용, 압축, CDN, 엔지니어링 블로그

## 핵심 답변

Cloudflare는 캐시에 들어오는 압축 가능한 텍스트 자산을 Zstandard로 한 번 인코딩해 저장하는 '캐시 트랜스코딩' 프로토타입에서 평균 압축비 2.834배, 즉 디스크 용량을 원본의 약 3분의 1로 줄였다고 밝혔습니다. 적용 대상은 전체 요청의 67.3%, 바이트 기준 22.3%였고 CPU 부담은 몇 퍼센트 수준이었습니다.

## 요약

- Cloudflare 블로그(9월 1일)는 오리진이 보낸 인코딩 그대로 캐시에 저장하던 방식을 바꿔, 캐시 필 시점에 Zstandard로 한 번 압축해 저장하는 프로토타입을 소개했습니다.
- 적용 가능한 텍스트 자산의 평균 압축비는 2.834배로, 디스크 크기가 원본의 약 3분의 1이 됐습니다. 4 KiB 이상 자산만 대상으로 해도 절감 효과의 대부분을 얻었습니다.
- 인코딩 비용은 바이트당 4.31 ns(약 232 MB/s), 디코딩은 1.56 ns(약 641 MB/s)입니다. 압축은 한 번, 해제는 서브할 때마다 일어나므로 디코딩이 싼 쪽이 유리합니다.
- 캐시 서버 10대에서 100만 건 이상의 요청으로 검증한 프로토타입 단계이며, 더 높은 압축 레벨과 다른 콘텐츠 유형은 후속 과제로 남겼습니다.

## 핵심 사실

| 항목 | 값 |
|---|---|
| 공개일 | 2026-09-01 (Cloudflare 블로그, Aashi Patel) |
| 평균 압축비 | 2.834배 (적용 대상 자산, 디스크 크기 약 1/3) |
| 적용 대상 비중 | 요청 67.3% / 바이트 22.3% (압축 가능한 텍스트) |
| 인코딩 비용 | 4.31 ns/byte (약 232 MB/s) |
| 디코딩 비용 | 1.56 ns/byte (약 641 MB/s) |
| 최소 크기 기준 | 4 KiB (이 이상만 트랜스코딩) |
| 검증 규모 | 요청 100만 건 이상, 서버 10대 (프로토타입) |


## 무슨 일인가요

Cloudflare는 2026년 9월 1일 블로그에 '캐시 트랜스코딩' 프로토타입을 공개했습니다. 지금까지 Cloudflare CDN은 오리진 서버가 보낸 콘텐츠 인코딩(gzip, brotli, zstd, 비압축)을 그대로 캐시에 저장했습니다. 그 결과 같은 콘텐츠의 여러 인코딩이 캐시 계층에 함께 남아 저장 공간을 낭비했고, 분산 저장 시스템의 메모리 비용은 계속 오르고 있었습니다. 



새 방식은 Cloudflare의 Rust 기반 프록시 프레임워크 Pingora 안에서, 압축 가능한 자산을 디스크에 쓰기 전에 Zstandard로 인코딩합니다. 압축은 캐시 필 때 한 번만 하고, 해제는 클라이언트에 서브할 때마다 합니다.  블로그는 "인코딩 비용은 자산이 캐시에 들어올 때 한 번 치르지만, 저장과 대역폭 절감은 그 자산이 재사용될 때마다 이어진다"고 설명했습니다. 



## 숫자로 보는 실험










적용 대상인 압축 가능한 텍스트는 전체 요청의 67.3%를 차지하지만 바이트 기준으로는 22.3%입니다. 이 자산들의 평균 압축비는 2.834배였습니다.  4 KiB 이상 자산만 트랜스코딩해도 측정된 저장 절감 효과의 거의 전부를 얻었고, 테스트 조건에서 CPU 사용량 증가는 몇 퍼센트 수준이었습니다.  검증은 캐시 서버 10대에서 100만 건 이상의 요청으로 이뤄졌습니다. 



같은 회사가 8월 27일에 올린 글에서는 1.1.1.1 DNS 캐시 항목의 메모리 구조를 다섯 차례 바꿔 항목당 953바이트를 420바이트로 56% 줄이고, 전체 서버군에서 약 100테라바이트의 메모리를 확보했다고 밝혔습니다.  두 글을 합쳐 보면 지금 Cloudflare 인프라 팀의 관심은 새 기능보다 저장·메모리 단가에 있다고 읽을 수 있습니다. 

## 왜 Zstandard였나요

블로그가 든 선택 기준은 압축과 해제의 비대칭입니다. 압축은 캐시 필 시점에 한 번이지만 해제는 자산을 서브할 때마다 반복되므로, 디코딩이 싼 알고리즘일수록 재사용이 쌓일수록 유리해집니다. 측정값에서 디코딩은 바이트당 1.56 ns로 인코딩 4.31 ns의 약 2.8배 빠릅니다. 

트랜스코딩 하한을 4 KiB로 둔 것도 같은 계산입니다. 작은 자산은 압축해도 줄어드는 절대량이 적은 반면 인코딩 비용은 그대로 들기 때문에, 이 기준만으로도 측정된 저장 절감 효과의 거의 전부를 확보했습니다.  압축 대상이 요청의 67.3%인데 바이트로는 22.3%라는 분포도 같은 이야기를 합니다. 개수는 많고 크기는 작은 텍스트 자산이 캐시의 대부분을 차지한다는 뜻입니다. 


블로그가 밝힌 대로 프로토타입 단계입니다. 더 높은 압축 레벨과 텍스트 이외 콘텐츠 유형은 후속 과제로 남아 있고, 전체 네트워크 기준 절감량은 '페타바이트 단위'라는 제목 표현 외에 구체 수치가 제시되지 않았습니다.


## 무엇을 보면 되나요

- **프로덕션 적용 여부**: Cloudflare가 후속 글에서 전체 네트워크 절감량과 실제 CPU 비용을 공개하는지가 이 실험의 성패를 가릅니다.
- **압축 레벨 선택**: 현재 결과는 낮은 레벨 기준입니다. 레벨을 올렸을 때 인코딩 비용과 압축비의 교환비가 어떻게 바뀌는지 봐야 합니다.
- **자사 캐시에 적용하려면**: 자산의 인코딩 분포(요청 대비 바이트 비중)부터 재는 것이 순서입니다. 이 글의 67.3% 대 22.3%라는 숫자가 그 출발점입니다.


이 사례가 흥미로운 이유는 기술이 새롭기 때문이 아니라, 저장 단가가 오르자 10년 넘게 미뤄 온 최적화가 갑자기 수지에 맞게 됐다는 점입니다. 인프라 비용 절감은 대개 새 기술보다 '언제 계산이 바뀌는가'의 문제이고, Cloudflare가 인턴 프로젝트 규모로 이를 검증해 공개한 것은 다른 회사가 같은 계산을 해 볼 좋은 계기라고 봅니다. 



수치는 Cloudflare 블로그 두 편(2026-09-01, 2026-08-27)에 실린 값입니다. MB/s는 블로그가 제시한 바이트당 나노초를 환산한 것으로, 블로그가 직접 쓴 단위는 아닙니다.



## 자주 묻는 질문

**Q. 무엇이 문제였나요?**

Cloudflare CDN은 오리진이 보낸 콘텐츠 인코딩(gzip, brotli, zstd, 비압축)을 그대로 저장했습니다. 같은 콘텐츠의 여러 인코딩이 캐시 계층에 공존해 저장 공간을 비효율적으로 썼고, 분산 저장 비용은 계속 오르고 있었습니다.

**Q. 왜 Zstandard인가요?**

블로그는 압축은 캐시 필 때 한 번, 해제는 서브할 때마다 일어나는 구조에서 디코딩이 빠른 Zstandard가 유리하다고 설명합니다. 측정값은 디코딩 641 MB/s로 인코딩 232 MB/s의 약 2.8배 빠릅니다.

**Q. 지금 실제 서비스에 적용됐나요?**

아닙니다. 캐시 서버 10대에서 100만 건 이상 요청으로 검증한 프로토타입이며, 더 높은 압축 레벨과 다른 콘텐츠 유형 평가가 후속 과제로 남아 있습니다.

## 출처

1. [How we could save petabytes of cache storage with Zstandard and Pingora (Cloudflare 블로그, 2026-09-01)](https://blog.cloudflare.com/cache-transcoding/) (official)
2. [How we saved 100 terabytes of memory by optimizing 1.1.1.1's DNS cache (Cloudflare 블로그, 2026-08-27)](https://blog.cloudflare.com/dns-cache-memory-optimization-1111/) (official)

_이 문서는 머니피셜 편집부가 작성했습니다. 인용 시 출처를 표기해 주세요._