Cloudflare Workflows 동시 실행 제한: 배포 누락·대기 상태·cron 예외 점검

대기열에서 일부 작업만 처리 구간으로 보내는 동시 실행 제한의 개념을 표현한 AI 생성 편집 이미지다. 실제 Cloudflare 화면이나 내부 구조도가 아니다.

DB 연결이 부족하거나 외부 AI API가 429를 반환할 때, 재시도 횟수만 늘리면 부하가 더 커질 수 있다. 작업을 얼마나 많이 만들었는지와 지금 몇 개를 동시에 실행할지는 따로 관리해야 한다.

Cloudflare는 2026년 11월 10일 Workflow별 동시 실행 제한을 발표했다. 계정 전체의 한도 안에서 개별 Workflow가 동시에 사용할 실행 슬롯을 줄일 수 있다. 한도를 넘긴 인스턴스는 거절하지 않고 대기열에 넣는다. DB·외부 API 보호와 특정 배치 작업의 실행 독점을 줄이는 데 사용할 수 있다. 공식 변경 기록

특히 주의할 점은 설정 없이 다시 배포하면 기존 제한이 제거된다는 것이다. 숫자를 정하는 작업과 배포 경로에서 그 숫자를 유지하는 작업을 함께 검토해야 한다.

1. 기존 Workflow에 제한을 넣는 위치

아래는 기존 Wrangler 설정의 workflows 배열에 들어갈 예시다. 전체 프로젝트 설정이 아니므로 main이나 다른 바인딩을 대체하지 않는다. 이름·클래스는 실제 프로젝트에 맞춘다.

지원되는 Wrangler 버전은 4.127.0 이상이다. 제한은 양의 정수여야 하며 계정 한도를 높이는 용도로 쓸 수 없다. 공식 한도표에서 계정 동시 실행 한도는 Workers Free 100개, Paid 50,000개다. 여기의 8은 설명용 값이며 권장 기본값은 아니다. 공식 변경 기록, Workflows 한도표

다른 Worker의 Workflow를 script_name으로 참조한다면 호출하는 쪽이 아니라 Workflow를 정의한 Worker에 제한을 설정한다. concurrency와 script_name을 같은 정의에 함께 지정할 수 없다. 동시 실행 제한 문서

2. 실행 슬롯은 언제 반환될까

공식 문서에서 확인할 경계는 다음과 같다.

초과 인스턴스의 상태는 queued다. 대기 순서를 따르려고 하지만 엄격한 FIFO 보장은 아니다.

waiting·paused 상태는 슬롯을 차지하지 않는다. 다만 짧은 sleep·재시도 대기 중에는 running으로 남아 슬롯을 유지할 수 있다.

waitingForPause와 롤백 처리 중인 인스턴스는 제한에 포함된다.

대기를 마치거나 재개할 때 자리가 없으면 다시 큐에서 기다린다.

한도를 낮춰도 이미 실행 중인 인스턴스를 즉시 중단하지 않는다.

Workflow별 한도는 용량 예약이 아니다. 해당 Workflow의 여유가 있어도 계정 한도가 차면 실행을 기다린다.

이 동작은 “sleep을 호출했으니 즉시 슬롯 하나가 비었다” 또는 “긴급 작업에 10을 지정했으니 항상 10개가 실행된다”는 해석을 피해야 하는 이유다. 동시 실행 제한 문서

3. cron으로 만든 인스턴스에는 예외가 있다

Workers Paid에서 Workflow 바인딩의 schedules로 생성한 인스턴스는 cron 실행 건마다 최대 1시간의 별도 동시 실행 예산을 사용한다. 그 동안 일반 동시 실행 슬롯을 소비하지 않고, Workflow별 한도에 도달해도 실행될 수 있다. 예산 소진 뒤에는 계정과 Workflow 양쪽의 슬롯이 생길 때까지 큐에서 기다린다. 예약 실행 문서, 동시 실행 제한 문서

따라서 예약 배치를 포함한 DB 전체 연결 수의 절대 상한을 이 설정 하나로 보장한다고 생각하면 안 된다. 모든 유입 경로의 합산 제한이 필요하면 DB 연결 풀, 외부 API 앞의 공유 제한기 등 별도 통제를 검토한다. 이는 해당 기능의 범위를 고려한 운영 설계 제안이다.

4. 동시 실행 수와 API 호출량은 별도로 계산하기

예를 들어 인스턴스 8개가 각각 외부 요청 3개를 병렬로 보낸다면, 단순 계산상 해당 구간의 요청은 최대 24개까지 겹칠 수 있다. 반대로 매우 짧은 작업을 빠르게 교체하면 동시 인스턴스 수가 작아도 초당 요청 수는 커진다.

이 예시는 제품 성능 측정치가 아니다. 설정 대상이 Workflow 인스턴스라는 점에서 도출한 설계상의 구분이다.

연결 수가 문제라면 한 인스턴스의 최대 병렬 연결과 같은 DB를 사용하는 다른 서비스를 합산한다.

초당·분당 요청 한도가 문제라면 별도의 속도 제한과 제공자의 재시도 지침을 적용한다.

월간 비용이 문제라면 총 작업 수·토큰 사용량·재시도 횟수에 대한 예산 통제가 필요하다.

대기열이 계속 늘면 한도를 올리기 전에 작업 유입량과 처리 지연을 함께 확인한다.

5. 배포 전에 확인할 체크리스트

실제 배포 설정 확인: 개발·스테이징·운영에서 어떤 Wrangler 파일과 환경 설정이 사용되는지 확인한다. 제한이 필요한 모든 배포 경로에 concurrency.limit가 남아 있어야 한다.

정의 위치 확인: 다른 Worker를 참조하는 바인딩에만 제한을 넣지 않았는지 확인한다.

작은 원격 검증 준비: 외부 결제·유료 모델 호출 대신 무해한 테스트 작업으로 큐 진입, 실행 완료 후 시작, 대기 후 재개를 살핀다.

낮춤과 제거를 구분: 제한 값을 줄이는 변경과 속성 자체를 빼는 변경을 코드 리뷰에서 따로 본다.

관측 기준 정하기: DB 연결·429뿐 아니라 큐 체류 시간과 전체 완료 시간을 함께 비교한다. 오류가 줄어도 사용자가 기다리는 시간이 지나치게 늘면 조정이 필요하다.

예약 작업 분리 확인: schedules 예외와 다른 Worker·서비스의 동일 의존성 호출을 검토한다.

이 기능은 로컬 개발 환경에서 적용되지 않는다. 로컬 테스트 통과만으로 배포 후 큐 동작을 검증했다고 말할 수 없다. 이 글의 설정은 공식 문서에 근거한 예시이며, 실제 Cloudflare 계정 배포나 부하 테스트를 수행한 결과는 아니다. 동시 실행 제한 문서

정리

이번 변경은 대량 작업의 실행 폭을 Workflow 단위로 조절할 수 있게 한다. 실무에서는 제한값뿐 아니라 배포 때 설정 유지, 대기 상태의 슬롯 반환 시점, cron 예외, 외부 요청의 별도 한도를 같이 확인해야 한다. 먼저 보호하려는 의존성과 허용 대기 시간을 정한 뒤 작은 범위에서 관측하며 적용하는 편이 안전하다.

확인 기준일: November 11, 2026 (한국 시간, 공식 발표일은 11월 10일)