Workers의 새 지출 한도를 켜기 전에는 같은 계정에서 멈출 서비스와 한도에 포함되지 않는 비용부터 확인하세요. Cloudflare는 2026년 11월 13일 Workers와 Durable Objects의 제품별 지출 한도를 발표했습니다. 알림만 받을 수도 있고 사용 중단을 선택할 수도 있어요. 다만 이 금액이 최종 청구액의 정확한 상한을 보장하지는 않습니다.
이 글은 여러 Worker와 Durable Object를 운영하는 개발·운영 담당자를 위한 설정 전 안내입니다. 11월 14일 공식 발표와 현재 청구·제품 문서를 확인했어요. 실제 계정의 한도를 변경하거나 청구서를 측정한 사례는 아니며, 아래 서비스 구성은 적용 범위를 설명하기 위한 가상 예시입니다.
알림을 받을지, 사용을 멈출지 먼저 고르세요
이번 기능에는 서로 다른 선택이 있습니다. 이메일 알림은 지정한 기준에 도달했다는 사실을 알려 주면서 제품 사용을 계속하게 합니다. 지출 한도는 효력이 적용되면 해당 제품이 지원하는 작업을 막아요. 비용을 관찰하고 싶은 상황과 사용량을 중단해야 하는 상황을 같은 설정으로 취급하지 않는 것이 출발점입니다.
Cloudflare는 올해 앞서 제공한 계정 전체 예산 알림과 이번 제품별 제어도 구분합니다. 기존 예산 알림이 새 한도로 자동 바뀌었다고 생각하지 마세요. 어떤 제품의 지출 기준인지, 수신자는 누구인지, 실제로 사용을 막는 정책인지 확인해야 같은 화면을 보고도 다른 기대를 갖는 일을 줄일 수 있습니다.
Workers와 Durable Objects에는 각각 별도의 한도가 있습니다. 앱이 두 제품을 함께 쓰더라도 Workers 한도 하나가 Durable Objects와 Workers AI, KV, R2의 비용까지 모두 관리하지는 않아요. AI Gateway를 통해 라우팅되는 AI 요청의 예산 제어 역시 적용 요청과 범위가 별도입니다.
따라서 팀에서 먼저 합의할 문장은 “얼마까지만 쓰자”보다 구체적이면 좋겠습니다. 예를 들어 “이 계정의 Workers 사용은 관찰하되 중단하지 않고 알림부터 받는다”처럼 제품과 행동을 함께 적을 수 있어요. 이는 금액 추천이나 운영 성공 사례가 아니라 설정 의도를 명확히 하는 기록 예시입니다.
개별 앱이 아니라 계정의 제품 전체가 대상이에요
현재 문서에서 Workers 한도는 계정의 모든 Workers를 합친 사용에 적용됩니다. 특정 Worker나 테스트 환경만 고르는 방식이 아니에요. Durable Objects도 개별 객체나 네임스페이스만 대상으로 한도를 지정할 수 없습니다. 같은 제품을 공유하는 서비스 목록을 먼저 보는 이유입니다.
가상의 계정에 운영 API와 실험용 Worker가 함께 있다고 생각해 보세요. 실험 작업의 사용량이 제품 전체 한도에 영향을 주면 운영 Worker도 중단 대상이 될 수 있습니다. 실험의 목적과 운영의 중요도가 다르다는 사실만으로 제품별 한도가 둘을 자동으로 분리해 주지는 않아요.
청구 항목도 구분해야 합니다. Workers는 포함 사용량을 공제한 뒤 요청과 CPU 시간에 대한 사용 요금을 계산하며, 월 구독료와 다른 제품 요금은 한도에서 제외합니다. Durable Objects는 요청·실행 시간, SQLite 행 읽기·쓰기, 키값 저장소의 읽기·쓰기·삭제 사용 요금이 대상입니다.
Durable Objects에 저장된 데이터의 요금과 공통 Workers Paid 구독료는 별도입니다. 사용이 일시중지돼도 저장 데이터 요금은 계속 발생할 수 있어요. 한도에 도달하면 데이터가 삭제되거나 구독이 취소된다는 뜻도 아닙니다. 비용을 설명할 때 사용 처리와 데이터 보관을 나눠 적어 주세요.
담당자가 검토할 간단한 메모에는 계정, 제품, 같은 제품을 사용하는 앱, 포함 항목, 별도 요금 항목을 한 줄씩 남길 수 있습니다. 현재 화면의 금액만 비교하기보다 그 금액이 합산한 범위와 남아 있는 항목을 함께 읽는 방식입니다. 실제 금액은 해당 계정의 현재 청구 기준으로 확인해야 해요.
한도에 닿으면 어떤 요청이 막히나요?
Workers 문서는 새 HTTP 요청뿐 아니라 Cron Triggers, Queue 소비자, Email Worker, 다른 Worker나 Durable Object에서 오는 호출도 중단 대상이라고 설명합니다. 웹페이지 한 곳의 접속만 확인해서 계정의 모든 작업 상태를 판단하기는 어렵겠죠. 정기 작업과 뒤에서 이어지는 호출 경로도 확인 대상으로 남겨 두세요.
HTTP 방문자에게는 1103 오류가 나타날 수 있습니다. 다만 이 오류에는 다른 원인도 있으므로 번호 하나만으로 지출 한도 때문이라고 확정하지 마세요. Billing의 Spend Management에서 실제 한도와 상태를 함께 확인해야 합니다. 한도로 거절된 요청은 Worker 실행으로 청구되지 않는다고 문서는 안내합니다.
Worker 코드를 실행하지 않고 제공되는 정적 자산은 계속 이용할 수 있습니다. 반면 run_worker_first처럼 코드 실행이 필요한 경로는 실패할 수 있어요. 같은 사이트에서 이미지가 보인다는 관찰과 API나 인증 경로가 동작한다는 관찰은 분리하는 편이 좋겠습니다.
Durable Objects는 새 stub 요청과 SQL 읽기·쓰기, SQLite 저장 공간 증가, 새 알람 설정 등에서 차단 동작이 있습니다. 하지만 이미 실행 중인 요청의 실행 시간, 이미 열린 WebSocket의 메시지, 레거시 키값 저장 객체의 일부 저장소 작업까지 모두 멈추는 것은 아니라고 현재 문서가 밝힙니다.
이 차이는 앱의 의존 관계를 보는 데 도움이 됩니다. 객체 자체의 한도를 풀었어도 그 객체를 호출하는 Worker가 막혀 있다면 사용자는 여전히 실패를 볼 수 있어요. “한도 해제” 한 항목과 “사용자 요청 경로 정상”을 각각 확인할 수 있도록 담당 서비스와 관찰 지점을 적어 두세요.
한도 금액과 최종 청구액은 같지 않을 수 있어요
한도는 현재 구독 청구 기간의 추정 사용 요금을 기준으로 평가됩니다. 사용량 집계와 차단 적용에는 시간이 걸리고, 이미 진행 중인 작업이나 적용 실패 등으로 금액을 넘길 수 있다고 문서는 설명해요. 화면에 입력한 숫자를 정확한 최대 청구액이나 무조건적인 비용 보증으로 안내하면 안 됩니다.
표시된 상태도 읽는 기준이 다릅니다. On은 정책이 켜져 있다는 뜻이지 서비스가 정상 실행 중이라는 확인은 아닙니다. Limit reached도 기록된 임계값 이벤트를 나타내며 모든 차단이 전파됐다는 증거는 아니에요. 설정 저장, 기준 도달 기록, 실제 요청 동작을 순서대로 나눠 보세요.
문서에 따르면 수신 주소가 있는 정책은 기준의 80%와 100%에서 알림을 보냅니다. 평가 사이에 두 기준을 한꺼번에 넘으면 100% 알림만 받을 수 있어요. 또 대시보드에서 만든 지출 한도에 이메일 수신자가 자동으로 붙지는 않는다고 안내합니다. 알림을 기대한다면 실제 수신 주소 설정까지 확인해야 합니다.
현재 지출도 새 한도에 포함됩니다. 공식 안내의 예시처럼 이미 60달러가 쌓인 제품에 50달러 한도를 저장하면 평가 시 바로 중단으로 이어질 수 있어요. 이 숫자는 원문 동작을 설명하는 예시이며 추천 예산이 아닙니다. 새로 설정한 순간부터 사용액이 0으로 시작한다고 생각하지 않는 것이 중요해요.
저장 직전에는 권한과 기존 상태를 함께 확인하세요
현재 대시보드 안내는 계정의 Billing에서 Spend Management를 열고 제품의 한도를 편집하도록 설명합니다. 청구 설정을 바꿀 권한이 필요하며 금액은 USD 기준으로 입력해요. 이 글은 실제 버튼을 대신 누르거나 계정 권한을 바꾸지 않았으니, 도입 담당자는 현재 UI와 자신의 권한 범위를 다시 확인해 주세요.
새 한도를 저장하면 켜지지만 기존 한도를 편집할 때는 원래 켜짐·꺼짐 상태가 유지된다는 조건도 있습니다. 금액을 수정한 뒤 값만 읽고 끝내지 말고 정책 상태를 함께 보세요. 변경 전 금액과 상태, 수신 주소, 변경 이유를 남겨 두면 이후 가용성 문제를 조사할 때 어느 변경이 있었는지 구분하기 쉽습니다.
공유 계정이라면 비용 담당자와 서비스 담당자가 같은 의미로 승인했는지도 확인해 보세요. 메일을 받을 담당자, 중단됐을 때 판단할 담당자, 재개 후 확인할 업무가 서로 다를 수 있습니다. 기능이 제공된다는 사실만으로 팀의 대응 절차까지 준비됐다고 보기는 어려워요.
작은 검토표에는 새 설정값과 함께 실제로 확인한 범위를 쓰면 좋습니다. 운영 경로를 시험하지 않았다면 “설정 확인, 요청 동작 미검증”처럼 남길 수 있죠. 대시보드 상태를 읽은 일을 전체 서비스의 중단·복구 시험으로 표현하지 않는 방식입니다.
재개할 때는 밀린 작업과 구독 주기도 봐야 해요
기간이 끝나기 전에 사용을 재개하는 방법으로 문서는 현재 사용액보다 한도를 높이거나, 끄거나, 제거하는 선택을 안내합니다. 변경 적용에는 몇 분이 걸릴 수 있고 다시 사용하면 요금이 발생할 수 있어요. 한도를 껐다 켜는 동작으로 이번 기간의 사용액이 초기화되지는 않습니다.
차단은 다음 구독 청구 기간이 시작될 때도 풀리며 켜 둔 한도는 새 기간에 남습니다. 이 기준을 무조건 매월 1일로 쓰지 마세요. 공식 예시처럼 갱신일이 15일인 구독은 그 주기에 맞춰 읽어야 합니다. 이 기능으로 인한 차단을 푸는 일이 다른 계정 제한까지 없애 주는 것도 아닙니다.
Durable Objects의 대기 중인 알람은 차단 동안 보류됩니다. 현재 문서는 예약한 지 7일을 넘긴 알람은 보류 중 삭제되며, 여전히 필요한 업무라면 서비스 복원 후 앱이 다시 예약해야 한다고 설명해요. 보류를 무기한 보존으로 생각하지 말고 지연 업무와 이미 처리된 업무를 구분할 계획을 세워 보세요.
자주 묻는 질문을 정리해 볼게요. 한도를 켜면 다른 제품 비용도 멈추나요? 제품별 범위를 확인해야 합니다. 알림 메일이 오면 모든 요청이 막혔나요? 알림과 차단 적용은 다른 관찰입니다. 한도를 풀면 복구가 끝났나요? 관련 Worker·객체·지연 작업과 실제 요청까지 확인한 범위만 완료로 남겨 주세요.
자료 확인일은 2026년 11월 14일입니다. 아래 공식 안내를 기준으로 정리했으며 실제 계정 설정 변경·명령 실행·성능 시험은 하지 않았어요. 적용 시점의 계정·버전·환경 조건은 담당자가 다시 확인해 주세요.
함께 읽어 볼 글: Google Cloud spend caps의 API 차단 범위와 예산 알림 비교. 배경과 다른 선택 조건을 비교할 때 참고해 보세요.
'소프트웨어개발' 카테고리의 다른 글
| 웹 회의 소음 제거가 추가됐어요: RealtimeKit에서 음소거와 구분할 것 (0) | 2026.11.14 |
|---|---|
| Copilot CLI의 C++ 설정 자동화: MSBuild가 맡는 일과 개발자가 확인할 일 (0) | 2026.11.14 |
| Cloudflare Tunnel 경로 정규화 확대: 2027년 기본값 변경 전에 볼 세 가지 (0) | 2026.11.14 |
