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

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

- 출처 사이트: 비즈피셜 (https://aifficial.net/biz/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 인프라 팀의 관심은 새 기능보다 저장·메모리 단가에 있다고 읽을 수 있습니다. 

## 왜 이제야 하나요

해커뉴스 스레드(138점, 댓글 62개)에서는 Zstandard의 빠른 디코딩, 음수 압축 레벨, 소형 객체용 사전 지원을 장점으로 꼽는 의견이 많았습니다. 한 이용자는 "zstd 3에서 5 레벨은 디스크나 네트워크 병목을 거의 만들지 않는다"고 적었습니다.  반면 HTTP 범위 요청을 압축 캐시에서 어떻게 처리할지는 논쟁거리였고, zstd의 프레임 단위 구조나 seekable 포맷으로 풀 수 있다는 제안이 나왔습니다. 

"왜 진작 하지 않았느냐"는 반응도 있었습니다. 저장과 대역폭이 충분히 쌌을 때는 엔지니어링 비용이 더 컸지만, 최근 공급망 제약으로 하드웨어 단가가 오르면서 계산이 바뀌었다는 해석입니다. 


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


## 무엇을 보면 되나요

- **프로덕션 적용 여부**: 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)
3. [Hacker News 스레드: We could save petabytes of cache storage with Zstandard and Pingora](https://news.ycombinator.com/item?id=49521909) (other)

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