Cloudflare Workers 기본

웹사이트를 Cloudflare Workers에 올리면 일반 웹호스팅처럼 월 정액이 나가는지, 방문자가 늘수록 요청마다 요금이 붙는지가 처음에 가장 헷갈립니다. 답은 요청의 종류에 따라 다릅니다. HTML, CSS, 이미지 같은 정적 파일을 그대로 내려주는 요청은 무료이고 한도가 없습니다(Workers Cache를 켜지 않았을 때입니다). 요금이 계산되는 것은 Worker 코드가 실행되는 요청입니다. 아래는 2026년 10월 20일 기준으로 Workers가 무엇인지, 두 종류의 요청이 어떻게 갈리는지, 무료와 유료의 한도가 얼마인지, 내 사용량을 어디서 보는지를 순서대로 정리한 것입니다. 금액은 모두 USD입니다.

Cloud Run 같은 컨테이너 서비스의 비용은 Cloud Run 비용 최적화에서 다뤘습니다. 두 서비스는 과금 단위가 달라서 서로 같은 표로 비교하지 않았습니다.

Workers는 무엇일까

Workers는 Cloudflare의 전 세계 네트워크에서 앱을 만들고 배포하고 확장하는 서버리스 플랫폼입니다. 서버를 직접 두지 않고(서버리스), 요청이 들어올 때 실행되는 코드(fetch() 함수)를 올려서 응답을 만듭니다. 이 글에서 Worker는 그 코드 하나를, Workers는 이를 돌리는 플랫폼을 뜻합니다.

Wrangler는 Workers의 명령줄 도구입니다. 프로젝트를 만들고, 로컬에서 실행하고, 배포하는 데 씁니다.

# 프로젝트 만들기
npm create cloudflare@latest -- my-first-worker

# 로컬에서 실행
npx wrangler dev

# 배포
npx wrangler deploy

앞의 두 명령은 내 컴퓨터에서 파일을 만들고 실행합니다. 첫 명령은 마지막에 “Do you want to deploy your application?”이라고 묻는데, 처음에는 아니요를 고르는 것이 좋습니다. 마지막 deploy는 Cloudflare에 올려 실제 주소에 반영하므로 변경이 생깁니다.

정적 파일과 코드 실행은 따로 계산됩니다

Workers에는 정적 에셋(Static Assets) 기능이 있습니다. 빌드한 사이트의 파일 폴더를 Worker와 함께 올려 두면, 요청 주소가 그 폴더의 파일과 맞을 때 Worker 코드를 실행하지 않고 파일을 바로 내려줍니다. 과금은 여기서 갈립니다.

주의할 점이 둘 있습니다.

• Worker 코드가 함께 배포되어 있을 때, 요청 주소가 에셋 폴더의 파일과 맞지 않으면 그 요청은 Worker가 처리하고 과금 대상입니다. /api/...처럼 동적으로 처리해야 하는 주소가 그렇습니다. Worker 코드가 없는 사이트는 맞지 않는 주소가 404가 되고 Worker는 실행되지 않습니다.
• 설정의 run_worker_first에 적은 패턴과 맞는 요청은 에셋 파일이 있어도 항상 Worker를 먼저 실행합니다. 그래서 이 설정은 요청을 과금 대상으로 바꿀 수 있습니다. !/로 시작하는 패턴은 Worker를 실행하지 않고 에셋을 내려줍니다.

Free 계정에서 일일 한도를 넘으면 run_worker_first로 잡힌 에셋 요청은 에셋으로 되돌아가지 않고 429 응답이 됩니다. 코드가 있는 Worker는 한도를 넘으면 Error 1027이 나고, 경로 설정에서 한도 초과 시 Worker를 건너뛰게(fail open) 했으면 Worker 없이 응답하고 오류를 내게(fail closed) 했으면 오류 페이지가 나갑니다.

자동 캐싱과 Workers Cache는 다릅니다

이름이 비슷하지만 서로 다른 기능이고 과금도 다릅니다.

• 정적 에셋의 자동 캐싱: 정적 에셋은 요청되면 Cloudflare 네트워크에서 자동으로 캐시되어 가까운 위치에서 내려갑니다. 따로 켜는 설정이 없고, 이 캐싱이 과금에 영향을 준다는 점은 확인되지 않았습니다. 그래서 위 표의 “무료이고 무제한”이 그대로 적용됩니다.
• Workers Cache: Worker가 돌려주는 HTTP 응답을 Cloudflare가 Worker 코드를 실행하지 않고 대신 돌려주게 하는 별도 기능입니다. Wrangler 설정에서 cache.enabled를 true로 켜야 하고("cache": { "enabled": true }), 이 설정 항목은 Wrangler 4.69.0에서 추가되어 4.69.0 이상 버전이 필요합니다. 무엇을 캐시할지는 Worker가 반환하는 Cache-Control 헤더로 정합니다. 이 기능은 Worker가 하는 일을 줄여 지연 시간과 CPU 사용량을 낮추려는 것입니다.
• Cache API: Worker 코드 안에서 직접 캐시를 다루는 별도의 API입니다. 같은 URL로 요청이 몰리면 요청마다 Worker가 실행될 수 있고, Workers Cache는 이를 한 번의 실행으로 묶는다는 차이가 있습니다.

Workers Cache를 켜면 과금 예외가 생깁니다. 캐시에서 응답한 요청도 Worker를 실행한 요청과 같은 요청당 요율로 계산되고, 평소 무료인 정적 에셋 요청과 Worker 사이 호출도 여기에 들어갑니다. 대신 CPU 시간은 캐시 미스나 우회로 Worker가 실제로 실행될 때만 계산됩니다. Worker가 Cloudflare 캐시보다 앞에서 실행되기 때문에 캐시로 응답하는 요청도 비용이 생깁니다. 그래서 정적 파일 요청이 많은 사이트가 Workers Cache를 켜면 무료이던 요청이 요청 수에 더해질 수 있습니다. 이 기능이 정식 출시인지 베타인지는 확인하지 못했습니다.

run_worker_first와 Workers Cache는 서로 다른 조건입니다.

Free와 Paid의 한도와 요금

현재 요금 모델은 Standard 방식입니다. 이전 방식인 Bundled와 Unbound는 옛 모델로 분류되어 있어서 다루지 않습니다.

다른 한도도 같이 봅니다. 서브리퀘스트는 Worker가 코드 안에서 다른 주소로 보내는 요청입니다.

Paid의 월 $5는 최소 청구액이라, 포함량 안에서 쓰면 $5가 전부입니다. 요청 하나당 CPU 시간은 Paid에서 기본 30초이고 최대 5분까지 올릴 수 있어서, 더 길게 쓰려면 설정을 바꿔야 합니다.

Worker가 부르는 D1(데이터베이스)과 R2(파일 저장소)는 요금이 따로 붙습니다. D1을 읽는 Worker 코드의 실행 비용은 D1 사용 요금 위에 더해집니다. 예를 들어 D1은 Free에서 하루 읽은 행 500만, 쓴 행 10만, 저장 5GB까지이고 Paid에서는 읽은 행 월 250억, 쓴 행 월 5,000만, 저장 5GB를 포함한 뒤 초과분이 따로 붙으며, R2 Standard는 월 저장 10GB와 Class A 요청 100만 회, Class B 요청 1,000만 회까지가 무료이며 R2에서 직접 나가는 전송에는 요금이 없습니다. Workers Paid를 구독해도 D1이나 R2 사용량이 무제한이 되지는 않으므로 각각 따로 확인합니다.

얼마나 나올지 계산하기

Paid에서 월 방문이 늘어 Worker 요청이 월 2,000만 회가 되고 호출당 평균 CPU 시간이 5ms라고 가정해 보겠습니다. 이 숫자는 설명을 위한 가정값입니다.

• 요청: (2,000만 − 1,000만) ÷ 100만 × $0.30 = $3.00
• CPU 시간: 2,000만 × 5ms = 1억 ms이므로 (1억 − 3,000만) ÷ 100만 × $0.02 = $1.40
• 합계: $5(최소) + $3.00 + $1.40 = 약 $9.40

가격표로 만든 계산이고 실제 청구액이 아닙니다. 위 가정과 달리 사이트가 전부 정적 에셋이면 Worker 요청이 거의 없으므로 계산할 항목이 없습니다. 다만 같은 사이트에서 Workers Cache를 켜면 정적 파일 요청도 요청 수에 들어갑니다. 예를 들어 정적 파일 요청이 월 5,000만 회라면 (5,000만 − 1,000만) ÷ 100만 × $0.30 = $12가 요청 요금으로 더해집니다(Paid, 가정값, CPU 시간 제외). 또 Worker 로그나 Cron, 빌드 분량 같은 부가 기능의 요금과 한국에서의 결제 방식, 원화 표시는 이번에 확인하지 못했습니다.

내 사용량은 어디서 볼까

비용을 줄이거나 Paid가 필요한지 정하기 전에 실제 사용량부터 봅니다. 읽기만 하는 확인입니다.

1. Cloudflare 대시보드에서 Workers & Pages > Overview를 열고 Worker를 선택한 뒤 Metrics를 봅니다. 요청 수(전체, 성공, 오류), 서브리퀘스트, 호출당 CPU 시간, 호출 상태를 볼 수 있습니다.
2. 요약 그래프에서 Errors를 선택하면 호출 상태별로 나뉩니다. Internal Error 상태의 요청은 과금에 포함되지 않습니다.
3. 돈이 얼마 나가는지는 Manage Account > Billing > Billable Usage에서 제품별 일별 사용 요금과 무료 한도를 넘은 부분(과금 사용량)을 봅니다. 고정 요금인 월 $5는 이 화면에 나오지 않고 무료 포함량을 넘은 사용량 기반 초과분만 표시되며, 종량제(Pay-as-you-go) 계정에만 보이고 Workers Paid 계정이 여기에 해당하는지는 확인하지 못했으며 Billing 읽기 권한이 필요합니다. Free 계정에서 이 화면이 보이는지는 확인하지 못했습니다.
4. 예산 알림은 Billable Usage > Create budget alert에서 만듭니다. 알림은 이메일로 알려 줄 뿐 사용을 멈추거나 상한을 두지 않습니다.

관찰 가능성(Observability)의 사용량 화면에서는 Workers Observability가 수집한 이벤트 양을 일별로 볼 수 있고 기록은 최대 60일입니다. 이 값이 Workers 요청 수와 같은지는 확인하지 못했으므로 요금은 Billable Usage로 계산합니다.

Worker 지표는 최대 3개월 전까지, 한 번에 1주일 단위로 조회됩니다. 방화벽(WAF) 같은 보안 기능이 막은 요청은 Worker 요청 합계에 들어가지 않습니다.

다음 순서로 판단합니다.

• 월 요청과 CPU 시간이 무료 한도의 한참 아래이면 Free로 충분하고, 요금을 줄이는 것보다 기능과 안정성을 먼저 봅니다.
• 하루 한도에 가까워지거나 Metrics의 호출 상태에서 Exceeded resources가 늘면 Paid를 검토합니다. Paid는 포함량이 넉넉해서 Worker 요청이 늘어도 $5를 넘기는 시점이 늦습니다.
• 요청이 많은데 대부분이 파일이라면, 그 요청이 Worker를 거치는지 먼저 확인합니다. run_worker_first 설정이 파일 경로까지 잡고 있다면 !/로 시작하는 패턴으로 그 경로를 빼서 Worker 실행 없이 에셋만 내려주게 할 수 있습니다. 이때 그 경로에는 Worker의 로직이 적용되지 않으므로 /api 같은 동적 경로를 건드리지 않았는지 확인합니다.

변경한 뒤 확인할 것

run_worker_first나 에셋 설정을 바꾸고 배포했다면 며칠 뒤 Metrics에서 요청 수와 CPU 시간, 오류율이 어떻게 달라졌는지 보고, 정적 에셋(HTML, 이미지)이 정상으로 열리는지 확인합니다. 다음 청구 주기에 Billable Usage의 Workers 항목도 비교합니다.

정적 에셋과 동적 API 경로를 구분하지 못했거나 사이트 응답이 바뀔 수 있는 변경이라면 설정을 바꾸지 않습니다.

마무리 정리

• 정적 파일만 내려주는 요청은 Workers Cache를 켜지 않는 한 무료이고, 요금은 Worker 코드가 실행되는 요청에서 생깁니다.
• 요청이 많은데 대부분이 파일이라면 run_worker_first 패턴이 파일 경로까지 잡고 있지 않은지 먼저 봅니다.
• Workers Cache를 켜기 전에 정적 파일 요청 수가 요청 요금에 더해지는 양을 계산합니다. 설정에는 Wrangler 4.69.0 이상이 필요합니다.
• 비용은 Billable Usage에서 보고, 예산 알림으로 이메일을 받아 둡니다. 알림은 사용을 멈추지 않습니다.
• 설정을 바꾼 뒤에는 Metrics와 다음 청구 주기의 Workers 항목을 비교합니다.

WEFTWARE의 공개 사이트(weftware.com)는 코드 없이 정적 에셋만 제공하고, 같은 계정에 운영용 Worker와 D1 데이터베이스가 따로 있습니다. 아래는 그 계정에서 캡처한 사용량 화면이며 Worker 이름과 데이터베이스 이름은 가렸습니다. Billable Usage 표(위)에서 Workers 표준 요청은 34.28k, Workers CPU는 1.23M ms, Worker 빌드는 121분이고 모든 행의 사용 비용이 $0.00입니다.