Cloudflare Workers 번들 한도 64 MiB 통합: 용량 때문에 Paid로 업그레이드할 이유가 사라졌다

Cloudflare Workers가 번들 크기 때문에 Workers Paid를 선택해야 할 이유를 없앴습니다. 2026년 9월 4일, 기존 Workers Free의 3 MB와 Workers Paid의 10 MB 압축 검사 대신 두 요금제에 동일한 64 MiB 비압축 한도가 적용되기 시작했습니다. 이제 배포 용량은 gzip이 아니라 Wrangler의 Total Upload 값을 기준으로 판단해야 합니다.

Cloudflare Workers 번들 용량 제한, 무엇이 바뀌었나

Worker 번들은 배포할 때 Cloudflare가 받는 코드와 지원 모듈의 묶음입니다. Cloudflare의 명령줄 툴인 Wrangler는 기본적으로 esbuild를 사용해 업로드 파일을 빌드하고, 코드에서 불러온 npm 패키지를 포함한 뒤 그 크기를 보여줍니다.

9월 4일까지 Cloudflare는 이 번들을 압축한 뒤, 압축 결과가 Workers Free의 3 MB 또는 Workers Paid의 10 MB를 넘으면 배포를 거부했습니다. 이 압축 검사는 이제 폐지됐습니다.

현재 플랫폼이 확인하는 항목은 하나뿐입니다. 비압축 번들 크기가 64 MiB 이하여야 하며, Free와 Paid에 같은 한도가 적용됩니다.

마지막 열이 이번 변경의 핵심입니다. Total Upload는 비압축 크기입니다. gzip도 참고용으로 계속 표시되지만, Cloudflare는 더 이상 이 값을 배포 통과 기준으로 사용하지 않습니다.

이를 단순한 배수로 환산해서는 안 됩니다. 이전 수치는 MB 단위의 압축 바이트였고, 새 수치는 MiB 단위의 비압축 바이트입니다. 실제로 더 담을 수 있는 코드의 양은 프로젝트의 JavaScript, 의존성, 바이너리 모듈이 얼마나 잘 압축되는지에 따라 달라집니다.

$5 요금제 판단 기준이 달라졌습니다

사업상 직접적인 영향은 범위가 좁지만 실용적입니다. Workers Paid는 계정당 월 최소 $5 USD가 청구됩니다. 번들이 기존 Free 한도인 3 MB를 넘는다는 이유만으로 업그레이드할 계획이었다면, 이제 Total Upload가 64 MiB 이내인 한 그 이유는 사라졌습니다.

그렇다고 두 요금제가 같아진 것은 아닙니다. Workers Free에는 하루 100,000건의 요청, 호출당 10밀리초의 CPU 시간, 호출당 50개의 하위 요청이 포함됩니다. Workers Paid에는 월 1,000만 건의 요청과 3,000만 CPU 밀리초가 포함되고, 호출당 10,000개의 하위 요청을 허용합니다. 요청당 CPU 시간은 기본 30초이며 최대 5분까지 사용할 수 있습니다.

따라서 비용 판단은 더 간단해졌습니다. 트래픽, CPU, 하위 요청, Paid 전용 기능이 필요할 때 비용을 지불하면 됩니다. 압축이 잘되는 번들이 폐지된 Free 한도를 넘었다는 이유만으로 결제할 필요는 없습니다.

실제 프로덕션 사용량 때문에 이미 Paid를 이용하는 팀은 요금이 바로 줄어들지 않습니다. 번들이 기존 한도보다 훨씬 작았던 팀도 워크플로가 달라지지 않습니다. 이번 변경의 혜택은 배포 크기 때문에 코드를 줄이거나 분할하고, 또는 요금제를 올리려 했던 프로젝트에 집중됩니다.

계정과 런타임 비용 계산 전반은 Cloudflare 종합 리뷰에서 Workers와 Cloudflare의 다른 요금제 및 사용량 과금이 어떻게 맞물리는지 확인할 수 있습니다. 이 글에 있던 이전 번들 한도 수치는 이번 9월 변경으로 대체됩니다.

더 수월해지는 네 가지 빌드

개인 SaaS 창업자는 프레임워크와 요금제를 따로 선택할 수 있습니다

Workers Free에서 풀스택 애플리케이션을 출시한다고 가정해 보겠습니다. 프레임워크 어댑터, 서버 렌더링 코드, 프로덕션 의존성을 합치면 애플리케이션 트래픽은 여전히 Free 범위에 들어오는데도 번들 압축 크기가 기존 Free 한도를 넘을 수 있습니다.

이제 이 빌드는 64 MiB Total Upload를 기준으로 판단하면 됩니다. 한도 안에 들어오면 번들 크기만으로 $5의 Paid 최소 요금이 강제되지 않습니다. 어떤 규모에서나 프로덕션을 무료로 운영할 수 있다는 뜻은 아닙니다. 아직 필요하지 않은 런타임 사용량에 비용을 내기 전에 수요를 검증할 수 있다는 의미입니다.

에이전시는 잘못된 CI 게이트를 삭제할 수 있습니다

에이전시의 빌드 책임자가 기존 gzip 한도를 모든 고객 저장소에 복사해 두었을 수 있습니다. 이 검사를 그대로 두면 Cloudflare가 더 이상 적용하지 않는 규칙 때문에 빌드가 실패합니다.

이를 비압축 Total Upload 검사로 바꾸고, 여유 공간을 확보할 수 있도록 내부 상한선을 64 MiB 아래로 정해야 합니다. 그러면 고객 프로젝트는 과거 규칙이 아니라 현재 플랫폼 제약에 맞춰 실패 여부가 결정됩니다.

Rust 또는 WebAssembly 팀은 더 넓은 공간을 얻지만, 새 런타임을 얻는 것은 아닙니다

일반적으로 Wasm으로 줄여 부르는 WebAssembly를 사용하면 Worker에서 Rust, Go, C 같은 언어로 컴파일한 바이너리 코드를 실행할 수 있습니다. Cloudflare에 따르면 Wasm Worker는 바이너리에 런타임 의존성이 추가로 포함되는 경우가 많아 동등한 JavaScript Worker보다 대체로 큽니다.

배포 허용량이 커지면서 Wasm 모듈과 그 주변 코드를 담을 공간도 늘어났습니다. Wrangler는 .wasm과 .wasm?module 업로드를 직접 지원합니다. 여전히 크기 최적화는 중요하며, Cloudflare는 바이너리 크기를 줄이는 데 wasm-opt 사용을 권장합니다.

플랫폼 팀은 우회용 아키텍처를 정리할 수 있습니다

Workers Paid를 사용하는 플랫폼 엔지니어라면 10 MB 압축 한도에 맞추기 위해 하나의 온전한 서비스를 나누거나, 유용한 의존성을 제거하거나, 외부 모듈을 위한 별도 경로를 구축했을 수 있습니다. 이제 그 결정을 다시 검토할 때입니다.

서비스를 나눈 덕분에 소유권이나 장애 경계가 명확해졌다면 분할을 유지할 이유가 있습니다. 하지만 폐지된 업로드 검사만을 위해 나눴다면, 현재 플랫폼 요구사항으로는 뒷받침되지 않는 복잡성만 남은 셈입니다.

다음 배포 전에 실제 번들 크기를 확인하는 방법

node_modules나 소스 디렉터리의 크기, 별도 프레임워크 빌드가 만든 아카이브를 보고 추측할 필요는 없습니다. Worker 프로젝트에서 Wrangler의 드라이 배포를 실행하면 Cloudflare가 실제로 받을 결과물을 그대로 빌드할 수 있습니다.

1. 1

   배포하지 않고 빌드하기

   Cloudflare가 문서에서 안내하는 드라이런 명령을 실행합니다.

   wrangler deploy --outdir bundled/ --dry-run

   Wrangler가 Worker를 빌드하고, 배포하지 않은 채 결과물을 로컬에 저장합니다.

2. 2

   Total Upload 확인하기

   명령 출력에서 Total Upload를 찾습니다. Cloudflare가 현재 64 MiB 한도와 비교하는 비압축 번들 크기입니다. 진단에 도움이 된다면 gzip도 참고하되, 플랫폼의 배포 통과 여부를 정하는 수치로 사용해서는 안 됩니다.

3. 3

   CI 용량 기준 바꾸기

   Free 3 MB 또는 Paid 10 MB 압축 크기 규칙을 Total Upload 규칙으로 교체합니다. 한 번의 의존성 업데이트가 남은 여유 공간을 모두 소진하지 않도록 팀 내부 상한선을 플랫폼 최대치보다 낮게 설정합니다.

4. 4

   실제 배포의 시작 시간 확인하기

   다음 일반 배포 또는 버전 업로드에서 Wrangler가 출력하는 startup_time_ms를 기록합니다. 번들이 업로드 한도 안에 들어와도 Cloudflare의 별도 시작 검사에서 실패할 수 있습니다.

흔히 하는 실수는 더 작아 보이는 gzip 값을 계속 확인하는 것입니다. 과거에는 이 값이 배포 여부를 결정했지만 지금은 아닙니다. 이제 용량 기준으로 삼아야 할 항목은 Total Upload입니다.

업로드 한도가 64 MiB여도 런타임 한도는 그대로입니다

번들이 커지면 파싱과 초기화에 더 오래 걸릴 수 있습니다. 요청 핸들러 밖인 전역 범위에서 비용이 큰 작업을 수행하는 코드는 여전히 Script startup exceeded CPU time limit 메시지와 오류 코드 10021로 검증에 실패할 수 있습니다. 64 MiB보다 작은 배포는 크기 게이트를 통과할 수 있을 뿐, 정상적인 시작까지 보장받는 것은 아닙니다.

무거운 프레임워크와 Wasm에서 특히 중요한 문제입니다. 이전 한도에서는 업로드 단계가 먼저 막히는 경우가 많았습니다. 이제 더 많은 코드가 다음 제약까지 도달하면서 메모리와 초기화 동작의 문제가 드러날 수 있습니다.

Worker가 여전히 너무 크다면 현재 문서가 제시하는 실용적인 방법은 세 가지입니다.

• 배포 경로에서 사용하지 않는 패키지와 의존성을 제거합니다.
• 설정, 정적 에셋, 바이너리 데이터는 Worker 번들 대신 Workers Static Assets, KV, R2 또는 D1에 보관합니다.
• Service Bindings를 이용해 기능을 여러 Worker로 분리합니다.

Service Binding 호출에는 두 번째 요청 요금이 붙지 않습니다. Cloudflare는 최초 Worker 호출과 관련 Worker 전체에서 사용한 CPU 시간의 합계를 과금합니다. 따라서 분할은 크기를 관리하는 현실적인 방법이지만, 서비스 경계가 하나 더 생긴다는 점을 감안하고 선택해야 합니다.

월요일에 해야 할 일

최근 Worker가 기존 용량 검사에 걸렸거나, 팀에서 한도를 맞추기 위해 프레임워크 의존성을 줄였거나, 번들 크기만을 이유로 Paid 업그레이드를 검토했다면 이번 주에 바로 확인해야 합니다. 드라이 배포를 실행하고 Total Upload를 기록한 뒤 기존 결정을 다시 검토합니다.

Worker가 이미 기존 한도보다 훨씬 작고 배포 파이프라인에도 하드코딩된 gzip 게이트가 없다면 기다려도 됩니다. 애플리케이션 런타임은 달라진 것이 없습니다.

요청 수, CPU 시간, 하위 요청 또는 다른 Paid 기능 때문에 비용을 지불할 이유가 있다면 Paid를 유지해야 합니다. Free의 업로드 한도가 커졌다는 이유만으로 운영 할당량이 맞지 않는 요금제로 프로덕션 워크로드를 옮겨서는 안 됩니다.

월요일에 할 일은 간단합니다. 빌드 검사를 gzip에서 Total Upload로 바꾸고, 번들 크기가 아니라 사용량을 기준으로 요금제를 결정하면 됩니다.

다음으로 적용할 만한 플랫폼 변경 사항은 뉴스레터에서 받아볼 수 있습니다.