워크플로 단계와 저장 비용을 비교하는 장면

Cloudflare Workflows 가격: 2026년 8월 step·storage 과금 전 비용 계산하기

작성자HuntLab 운영자

Cloudflare Workflows 가격을 보다가 step 단가만 곱하면 되겠지 싶었는데요. 아니었음. 2026년 8월 4일 공식 문서를 대조해보니 Paid 예상액은 steps, storage, requests, CPU 네 항목과 Workers Paid 월 $5 최소 요금을 함께 봐야 합니다. step·storage 과금은 최신 Pricing 기준 8월 10일 적용 예정이라, 지금 해둘 일은 청구됐다고 단정하는 게 아니라 내 사용량을 같은 단위로 바꾸는 것.

이 글은 실제 Cloudflare 계정이나 invoice를 조회한 후기가 아니라 공식 1차 자료를 비교한 계산 가이드예요. 특히 GraphQL의 stepCount를 월 합계처럼 바로 더하면 중복 집계할 수 있어서, 그 부분까지 따로 짚어보겠습니다.

Cloudflare Workflows의 requests·CPU·storage·steps 초과분과 Paid 월 $5 최소 요금의 계산 구조

8월 10일부터 달라질 예정인 항목은 step과 storage

Cloudflare 공식 Workflows Pricing은 Paid의 step·storage 과금을 2026년 8월 10일부터 적용한다고 안내합니다. 다만 7월 7일 Workflows changelog 표현은 ‘8월 10일보다 이르지 않게’라서 강도가 살짝 달라요.

조사일이 8월 4일, 즉 예정일 전이라 실제 개시나 첫 invoice 반영은 아직 확인할 수 없습니다. 게시 시점이 8월 10일 이후라면 Pricing, changelog, Billing > Billable Usage를 다시 보는 게 맞아요. 날짜 하나 보고 이미 청구 중이라고 쓰면 곤란함.

그리고 requests와 CPU는 이번에 새로 생기는 비용이 아닙니다. 공식 changelog상 initial public beta부터 활성화돼 있었고, 이번 변경 대상이 step과 storage예요. 예전 GA 글에 나온 2025년 storage 과금 일정은 최신 문서와 충돌하므로 현행 계산에는 쓰지 않았습니다.

Free는 일별 제한, Paid는 월 포함량으로 계산한다

같은 Workflows라도 Free와 Paid는 단위부터 다릅니다. Free의 steps는 하루 기준이고 Paid는 billing cycle의 월 기준이라 한 표에 놓고도 상계 방식은 완전히 달라요.

과금 차원 Workers Free Workers Paid 계산할 때 볼 것
Requests / invocation 하루 100,000회 월 10,000,000회 포함, 초과 1,000,000회당 $0.30 Workers requests와 공유
CPU time invocation당 10 ms 월 30,000,000 CPU-ms 포함, 초과 1,000,000 CPU-ms당 $0.02 active compute만 집계
Storage 1 GB 월 1 GB-month 포함, 초과 GB-month당 $0.20 일별 peak storage의 30일 평균
Steps 하루 3,000회 월 500,000회 포함, 초과 100,000회당 $0.80 sleep/wait 포함, retry·rollback handler 제외

표의 수치와 조건은 Workflows Pricing과 Workers Pricing을 기준으로 했습니다.

Free에서 오늘 2,000 steps, 내일 4,000 steps를 썼다고 해서 이틀 합계 6,000회로 퉁칠 수는 없어요. 하루 3,000회 제한이므로 내일 사용량이 걸립니다. 초과 요금을 내고 계속 쓰는 구조도 아니고 제한이 적용되며, storage 1 GB 한도에서 state 저장을 시도하면 오류가 납니다.

Paid는 반대로 월 포함량을 봅니다. 다만 requests와 CPU 포함량은 Workflows만의 독립 주머니가 아니라 같은 계정의 Workers Standard 사용량과 공유해요. Workflows requests가 200만 건이어도 다른 Worker가 900만 건을 썼다면 총 1,100만 건으로 계산해야 하는 식. 여기서 은근 많이 헷갈릴 듯.

참고로 step.sleep이나 외부 이벤트를 기다리는 시간 자체는 CPU를 소비하지 않지만 step에는 포함됩니다. sleep이 곧 CPU 비용은 아니어도 ‘완전 무료 대기’는 아닌 셈이에요. 현재 가격 문서상 retry와 rollback handler는 step count에서 제외됩니다.

Paid 예상 비용은 네 초과분을 한 번에 넣는다

한 billing cycle의 값을 아래처럼 잡으면 계산이 깔끔합니다.

  • S: Workflows billable steps
  • G: Workflows storage GB-month
  • R: 다른 Workers까지 포함한 Workers Standard 총 requests
  • C: 다른 Workers까지 포함한 Workers Standard 총 CPU-ms
step_overage_usd    = max(0, S - 500,000) / 100,000 × 0.80
storage_overage_usd = max(0, G - 1) × 0.20
request_overage_usd = max(0, R - 10,000,000) / 1,000,000 × 0.30
cpu_overage_usd     = max(0, C - 30,000,000) / 1,000,000 × 0.02

estimated_total_usd = 5.00 + 위 네 초과 비용

마지막의 $5는 Workers Paid 계정 최소 요금입니다. 이미 다른 Workers 때문에 Paid 최소 요금을 내고 있다면 Workflows의 증분 비용을 볼 때 $5를 또 더하면 안 돼요. 전체 청구 예상액과 Workflows 추가분을 분리하면 마음 편-안.

단, 공식 문서에는 fractional unit의 invoice 반올림이나 최소 청구 increment가 명시돼 있지 않습니다. 그래서 위 식은 단가를 비례 적용한 추정식이고 최종 권위는 invoice에 있어요. 세금, 환율, 다른 usage-based product, billing-cycle 부분 기간도 별도입니다.

가상 사용량 230만 steps를 넣어보면

실제 HuntLab 계정 수치가 아닌 가상 예제입니다.

  • steps S = 2,300,000
  • requests R = 2,300,000 — 다른 Workers까지 합쳐도 포함량 이내라고 가정
  • CPU C = 50,000,000 ms
  • 첫 10일 daily peak storage 6 GB, 다음 20일 2 GB

먼저 storage는 마지막 날의 용량이 아니라 30일간 일별 peak의 평균으로 바꿉니다.

G = (6 GB × 10일 + 2 GB × 20일) / 30일
  = 3.333... GB-month

step    = (2,300,000 - 500,000) / 100,000 × $0.80 = $14.40
storage = (3.333... - 1) × $0.20                   ≈ $0.47
request = $0.00
CPU     = (50,000,000 - 30,000,000) / 1,000,000 × $0.02 = $0.40

Workers Paid를 이번에 새로 쓰는 계정이라면 최소 요금을 더해 약 $20.27, 이미 최소 요금을 내는 계정이라면 Workflows 관련 추정 증분은 약 $15.27입니다. step만 계산했을 때보다 CPU와 storage가 $0.87 더 붙었어요. 이 예시에선 작아 보여도 사용 패턴이 바뀌면 비중도 달라지겠지.

가상 사용량의 steps·storage·requests·CPU 포함량을 차감해 약 $20.27을 계산한 표

GraphQL의 stepCount는 모든 행을 더하면 안 된다

비용 식보다 더 까다로운 건 S, 그러니까 월 billable steps를 어떻게 가져오느냐입니다. 공식 Metrics and analytics 문서는 최근 31일 보존되는 workflowsAdaptiveGroups와 raw workflowsAdaptive 데이터셋을 설명해요. raw 데이터에서는 특정 instance의 datetime, eventType, workflowName, instanceId, stepCount, wallTime을 시간순으로 볼 수 있습니다.

근데 공식 집계 예제의 이름이 조금 함정입니다.

stepCount: workflowsAdaptiveGroups(
  filter: {
    workflowName: $workflowName
    eventType: "WORKFLOW_START"
    # 시간 필터 생략
  }
) {
  count
  dimensions { date: datetimeHour }
}

여기서 stepCount는 쿼리 alias이고 실제 선택 필드는 count입니다. 즉 WORKFLOW_START 이벤트 수를 실행 step 총계라고 단정할 근거가 없어요. raw 데이터도 한 instance에서 이벤트가 여러 번 나오므로 각 행의 누적 stepCount를 몽땅 더하면 중복 집계 위험이 있습니다. 이름만 보고 냅다 합산하면 큰일 날 수 있음.

안전하게 확인하려면 이 순서가 낫습니다.

  1. 최근 31일 안에서 workflowName과 조회 기간을 고정합니다.
  2. raw workflowsAdaptive로 표본 instance 몇 개를 시간순 조회합니다.
  3. stepCount가 증가하는 방식과 종료 상태의 값을 확인합니다.
  4. instance별 최신 또는 terminal event 값을 쓸 수 있는지 실제 응답으로 검증하고, 실행 중 instance 처리 규칙도 정합니다.
  5. 월 추정 합계를 Workflows analytics와 Billing > Billable Usage에 대조합니다.

3~4번은 공식 billing 집계 공식이 아니라 검증해야 할 운영 가설입니다. 이번 조사에서는 실제 계정 응답을 보지 못했으므로 확정 GraphQL 쿼리를 만들지 않았어요. 값이 다르면 GraphQL 추정보다 Billable Usage와 invoice를 우선해야 합니다.

Storage는 완료된 instance와 retention까지 본다

Storage 비용은 순간 파일 크기만 재는 방식이 아닙니다. running, errored, sleeping, completed 상태의 instance가 모두 persisted state 계산에 들어가고, 30일간 일별 peak storage의 평균으로 GB-month가 정해져요.

Paid의 기본 state retention은 30일, Free는 3일입니다. 완료된 instance가 많이 쌓이면 실행이 끝났어도 청구 기간의 peak가 유지될 수 있다는 얘기. 불필요한 state 반환을 줄이고, 감사 기간이 짧아도 되는 workflow라면 instance 생성 시 더 짧은 retention을 지정하거나 API·Wrangler·REST·dashboard에서 삭제하는 방안을 검토할 수 있습니다. 삭제 후 storage limit 반영에는 몇 분이 걸릴 수 있어요.

다만 비용만 보고 retention을 일괄 단축하는 건 쏘쏘. 장애 분석과 감사 추적 기록도 같이 사라질 수 있으니 workflow별 필요 보존일과 줄어드는 일별 peak GB를 함께 비교해야 합니다. step result 크기 같은 실행 제한은 비용과 별개라 Workflows Limits도 같이 확인하는 편이 안전해요.

Budget alert는 비용 차단기가 아니라 늦게 오는 알림이다

Budget alert는 Manage Account > Billing > Billable Usage > Create budget alert에서 설정합니다. Budget alerts 기준으로 Pay-as-you-go 계정의 현재 billing period에서 계정 전체 usage-based spend가 USD 임계값을 넘으면 수신자에게 이메일을 한 번 보내요. 다음 billing period에는 reset됩니다.

중요한 한계가 제법 많습니다.

  • Workflows 전용 비용이 아니라 모든 usage-based product 합계입니다.
  • Enterprise contract 계정은 지원 대상이 아닙니다.
  • Workers Paid 월 $5 같은 recurring subscription fee는 임계값 계산에서 빠집니다.
  • 사용량 처리가 하루 한 번이라 임계값을 넘긴 다음 날 알림이 올 수 있습니다.
  • 이메일만 보낼 뿐 Workflow를 멈추거나 비용을 cap하지 않습니다.

2026년 7월 20일 Billing changelog는 조건에 맞는 Pay-as-you-go 계정 중 기존 alert가 없는 계정에 $10 기본 alert를 cohort별로 활성화한다고 안내합니다. 다음 billing cycle부터 켜지고 이미 발생한 사용량에는 발동하지 않아요. 기본 alert가 있겠지 하고 믿기보다 계정 화면에서 직접 상태를 확인해야 함.

예상 usage overage 예산이 $20이라면 $10, $15처럼 조기 경보를 여러 단계로 두는 건 가능합니다. 그래도 자동 중단이 필요하면 애플리케이션의 invocation·queue admission control, CPU limit, 배포별 feature flag 같은 별도 제어가 필요해요. CPU limit도 account spend cap은 아닙니다.

계정 전체 usage 비용의 임계값 초과부터 이메일 발송까지와 Workflow 실행 지속을 보여주는 타임라인

8월 10일 전에는 이 세 가지만 확인

첫째, steps만 보지 말고 같은 billing cycle의 requests·CPU와 일별 peak storage를 모읍니다. 둘째, GraphQL stepCount는 instance별 의미를 실제 응답으로 검증한 뒤 Billable Usage와 맞춰봐야 해요. 셋째, budget alert와 자동 중단 장치는 별개로 준비합니다.

이번 계산은 2026년 8월 4일 공식 문서 기준이라 실제 과금 개시, 부분 billing-cycle 처리, invoice 반올림은 확인하지 못했습니다. 그래서 8월 10일 전에는 31일치 analytics와 Billable Usage를 대조하고 account-level budget alert를 설정하되, 별도의 중단 기준도 운영 코드에 마련해두는 정도가 딱 좋겠습니다. 과금 시작 뒤 첫 invoice까지 확인하면 그때 계산식도 한 번 더 손보는 걸로.

FAQ

Paid에서 월 500,000 steps를 넘지 않으면 Workflows는 완전히 무료인가요?

아닙니다. step 초과 비용은 없지만 Workers Paid의 월 $5 최소 요금과 계정에서 공유하는 requests·CPU 사용량, storage 초과분은 별도로 봐야 합니다. 이미 Paid 최소 요금을 내고 있다면 Workflows 증분 비용에 $5를 중복해서 더하지 않습니다.

수면 중이거나 완료된 Workflow도 storage 비용에 포함되나요?

포함됩니다. running, errored, sleeping, completed instance가 모두 persisted state 계산 대상이고, Paid storage는 30일간 일별 peak의 평균인 GB-month로 계산합니다.

step.sleep과 retry도 유료 step으로 세나요?

step.sleep과 외부 이벤트 대기 step은 step count에 포함되지만 대기 자체는 CPU 시간을 쓰지 않습니다. 현재 공식 가격 문서에서는 retry와 rollback handler를 step count에서 제외합니다.

Free의 하루 3,000 steps를 월 90,000 steps처럼 쓸 수 있나요?

아니요. Free는 일별 제한이라 사용하지 않은 날의 여유분을 다른 날로 넘기는 월간 pool처럼 계산하면 안 됩니다. Paid의 월 500,000 steps 포함량과 기준 단위가 다릅니다.

Budget alert가 임계값에 도달하면 Workflow를 자동으로 중지하나요?

중지하지 않습니다. Pay-as-you-go 계정 전체의 usage-based spend에 대해 이메일을 보내는 정보성 알림이며, 처리도 하루 한 번입니다. 실시간 중단이나 비용 cap이 필요하면 운영 코드에 별도 제어를 마련해야 합니다.

비슷한 글

답글 남기기

이메일 주소는 공개되지 않습니다. 필수 필드는 *로 표시됩니다