Cloudflare Cache가 Rust 기반 Pingora로 이전 — 무엇이 달라지고 우리는 무엇을 배울 수 있는가

2026년 5월 4일 Cloudflare가 캐시 계층 전체를 자체 개발한 Rust 기반 Pingora 프록시 위로 옮겼다고 발표했습니다. Cloudflare는 하루에 수조 개의 HTTP 요청을 처리하는 세계 최대급 프록시 사업자이고, 지난 십 수년간 Nginx 기반이었습니다. 그 대들보를 Rust로 갈아치웠다는 뜻입니다.

이 소식이 왜 우리(자체 서버로 웹사이트를 운영하는 사람들)에게도 흥미로운지 정리해봅니다.

무엇이 바뀌었나

Cloudflare가 밝힌 변화점.

저지연: 캐시 조회·응답 처리의 오버헤드가 감소. 특히 tail latency(p99·p99.9) 개선.
향상된 RFC 준수: HTTP 캐싱 표준(RFC 9111 등)의 세부 사항에 더 엄격히 대응.
비동기 stale-while-revalidate 지원: 만료된 캐시를 사용자에게 즉시 반환하면서, 백그라운드에서 재검증을 병렬로 진행.

Pingora 자체는 2022년 오픈소스로 공개됐지만, 실제 캐시 워크로드가 Nginx에서 완전히 Pingora로 이전된 건 최근입니다. 발표 시점 기준으로 Cloudflare의 전체 캐시 트래픽이 Pingora를 통해 흐르고 있습니다.

왜 Rust인가, 왜 지금인가

Nginx는 여전히 훌륭한 도구입니다. 하지만 20년 넘게 축적된 코드베이스에서 대규모 사업자가 부딪히는 한계가 있었습니다.

메모리 안전성: C 기반이라 use-after-free·buffer overflow 같은 취약점 회귀 가능성.
비동기 모델 확장 한계: 이벤트 루프 아키텍처가 특정 워크로드에서 CPU를 다 활용 못 함.
커스터마이징 마찰: Cloudflare 규모에서 필요한 세밀한 프로토콜 처리를 Nginx 모듈로 표현하기 어려움.

Rust는 이 세 지점에서 답을 줍니다. 메모리 안전성은 언어 차원에서 보장, tokio/async 기반 확장 모델, 라이브러리 생태계로 프로토콜 처리 자유도 확보.

Cloudflare가 자체 프록시를 만들어 이전한 건 순수 기술적 이유만이 아니라 거대 규모의 운영 편익 때문입니다. 우리가 그 규모까지 갈 일은 없지만, 그 결정이 만든 오픈소스 자산은 우리도 쓸 수 있습니다.

Pingora의 정체 — 프레임워크인가 프록시인가

한 가지 오해하기 쉬운 점. Pingora는 완제품 프록시가 아니라 프록시 프레임워크입니다.

Cloudflare 내부: Pingora 위에 자체 캐시 로직·라우팅·엣지 처리를 얹은 완제품 형태로 사용.
오픈소스로 공개된 것: Pingora 프레임워크. 개발자가 Rust 코드로 자기 프록시를 구축할 때 쓰는 라이브러리 세트.

즉 자체 서버에 “Pingora 설치”를 apt로 하는 방식이 아니라, Rust로 짧은 프로그램을 작성해서 Pingora가 제공하는 요청 처리 파이프라인·연결 풀·업스트림 관리를 활용하는 형태입니다.

자체 서버 운영자 관점 — 지금 갈아탈 필요가 있는가

솔직히 말해 대부분의 웹사이트는 Nginx로 충분합니다. 갈아타야 할 순간은 이런 경우.

초당 수십만 이상의 요청을 처리하고 tail latency가 병목.
프로토콜 처리(HTTP/3, gRPC, WebSocket 등)를 세밀히 커스터마이징해야 함.
메모리 안전성이 규제·감사 관점에서 중요.

이 조건이 아니라면 Nginx·Caddy·Traefik·HAProxy 중 하나가 여전히 실용적입니다. 다만 차세대 프록시 계층이 Rust로 가고 있다는 것 자체는 인식하고 있으면 좋습니다. 몇 년 안에 프로덕션 급 완제품 Rust 프록시가 여러 개 등장할 겁니다.

자체 서버에서 지금 시도해볼 만한 Rust 계열 프록시

프로덕션 사용까지는 조심스럽지만, 검토·실험 가치가 있는 것들.

1) Sozu

sozu-proxy/sozu — 프랑스 Clever Cloud가 개발한 HTTP 프록시. Rust 기반, hot-reload 설정, TLS 종단 지원. 프로덕션 사용 사례 있음.

# Debian/Ubuntu에서 build
git clone https://github.com/sozu-proxy/sozu
cd sozu && cargo build --release

설정은 TOML 기반이고 Nginx보다 깔끔합니다.

2) Ferron

Rust로 처음부터 다시 짠 웹서버·프록시. Nginx 대체를 겨냥. 아직 초기 단계지만 벤치마크에서 흥미로운 수치.

3) River

Cloudflare가 Pingora 프레임워크 위에 만든 참조 구현. Pingora를 “설치형 프록시”에 가깝게 쓰고 싶은 개발자를 위한 시작점.

4) Nginx-quic 그대로 두기

가장 실용적인 선택. HTTP/3 필요하면 nginx-quic 브랜치 또는 Nginx 1.25+ 정식 모듈. 이미 익숙한 도구에 새 기능만 얹기.

그럼에도 알아둘 아이디어 — Async Stale-While-Revalidate

Pingora 이전의 핵심 개선점 중 하나가 비동기 stale-while-revalidate입니다. 이건 이름은 어렵지만 개념이 실용적이라 우리 자체 서버에도 적용할 수 있습니다.

전통적 캐시 흐름.

캐시 만료 → 사용자 요청 → 오리진 확인(느림) → 응답

Stale-while-revalidate 흐름.

캐시 만료 → 사용자 요청 → 만료된 캐시 즉시 반환(빠름)
                       → 백그라운드에서 오리진 확인 후 캐시 갱신

사용자는 항상 빠른 응답을 받고, 캐시는 백그라운드에서 갱신됩니다. Cloudflare가 이걸 정교하게 만든 것이 이번 발표의 핵심.

Nginx에서 흉내 내기

Nginx도 proxy_cache_use_stale 지시자로 유사한 동작이 가능합니다.

location / {
    proxy_pass http://backend;
    proxy_cache mycache;
    proxy_cache_valid 200 302 10m;

    # 만료된 캐시라도 오리진 오류 시 사용
    proxy_cache_use_stale error timeout updating http_500 http_502 http_503 http_504;

    # 오리진 확인 중에도 만료 캐시 사용
    proxy_cache_background_update on;

    # 동일 URL 동시 요청 시 오리진 한 번만
    proxy_cache_lock on;
}

proxy_cache_background_update on이 핵심입니다. 이 지시자 하나로 stale-while-revalidate가 켜집니다. 대부분의 Nginx 설정이 이걸 안 켜고 있어서 만료 후 첫 사용자가 오리진 지연을 그대로 겪습니다.

Varnish에서

VCL로 매우 세밀한 SWR 정책 구현 가능. beresp.grace·beresp.keep으로 만료 후에도 얼마나 오래 stale 응답을 허용할지 지정.

Cloudflare 없이 캐시 최적화하는 순서

TCP-80.NET의 일본 VPS·전용서버로 자체 웹서버를 운영한다면 다음 순서로 캐시 위생을 갖추면 좋습니다.

정적 자산 캐시 헤더 정리. Cache-Control: public, max-age=31536000, immutable 을 버전 파일명에 걸기.
Nginx proxy_cache 도입. 오리진 부하 감소.
stale-while-revalidate 활성화. proxy_cache_background_update on.
cache_lock. 동시 다중 요청이 오리진에 몰리는 것 방지.
cache key 최적화. 쿼리스트링·쿠키 중 캐시 무효화 요인 아닌 것 제거.
주기적 캐시 히트율 모니터링. $upstream_cache_status 로그.

이 여섯 단계만 제대로 밟아도 Cloudflare 없이 상당 부분의 성능 이득을 얻을 수 있습니다.

마무리

Pingora 이전은 Cloudflare 내부 이야기지만, 그 이면의 아이디어(비동기 SWR, RFC 엄격 준수, Rust 도입)는 우리 자체 서버 운영에도 시사점이 큽니다. 지금 당장 Rust 프록시로 갈아탈 필요는 없지만, Nginx의 SWR·cache_lock 같은 기능은 오늘 켤 수 있고 즉시 효과가 나옵니다.

TCP-80.NET에서 Nginx·Varnish 캐시 튜닝을 함께 검토하고 싶으신 분은 @tcp80net 텔레그램으로 문의 주시면 됩니다.

출처 (Source)

이 글은 아래 Cloudflare 공식 changelog를 참고해 tcp-80.net 청중 관점에서 재구성·번역·확장했습니다. 자체 서버 대응 섹션(Sozu·Ferron·River 소개, Nginx stale-while-revalidate 설정, 캐시 최적화 순서)은 원문에 없는 자체 추가 내용입니다.

원문 제목: Pingora powers cache
원문 발행일: 2026-05-04
원문 URL: https://developers.cloudflare.com/changelog/post/2026-05-04-pingora-powers-cache/
원문 저작자: Cloudflare, Inc.
본문 재구성·번역: TCP-80.NET (2026-05-04)

Pingora 프레임워크는 Cloudflare가 GitHub에 오픈소스로 공개했습니다: github.com/cloudflare/pingora. Cloudflare 제품 옵션명·UI는 시점에 따라 다를 수 있으니 최신 정보는 원문 및 Cloudflare 공식 문서에서 확인하시기 바랍니다.