[Cloudflare Workers][운영] subrequests 상한이 달라진 뒤 client disconnect와 waitUntil 취소를 어디서 구분하나

IT 리서치 노트

[Cloudflare Workers][운영] subrequests 상한이 달라진 뒤 client disconnect와 waitUntil 취소를 어디서 구분하나

Cloudflare Workers 운영에서 subrequests 관련 장애를 읽을 때 예전 1000 상한 감각만 붙들고 있으면 해석이 어긋나기 쉽다. 2026년 7월 31일 기준 Cloudflare 공식 문서를 다시 보면 paid plan Workers는 기본 10000 subrequests로 바뀌었고 더 크게 조정할 수 있으며, 응답이 끝나거나 클라이언트가 끊긴 뒤 작업이 취소될 수 있는지 여부는 ctx.waitUntil과 실행 수명 축에서 따로 봐야 한다. 이 글은 subrequests 상한 변경 뒤 client disconnect와 waitUntil 취소를 어디서 구분해야 하는지 정리한 것이다.

목차

1. 개요
2. 어디서 실제로 막히는가
3. 실무에서 적용하는 순서
4. 공식 문서와 예시 화면으로 확인하기
5. 주의사항과 리스크
6. 결론
7. 참고 링크

1. 개요

결론부터 말하면 현재 Cloudflare Workers 운영에서는 subrequests 상한과 후처리 생존 시간을 अलग한 문제로 봐야 한다. paid plan의 기본 subrequests 상한은 예전 1000 고정이 아니라 10000이고, 클라이언트 연결이 끊긴 뒤 남은 작업은 waitUntil로 넘기지 않으면 취소될 수 있다.

따라서 '후처리 로그가 빠졌다'는 증상 하나만으로 subrequests limit 초과라고 결론내리기 어렵다. 먼저 plan과 wrangler limits를 보고, 그다음 disconnect 유형과 waitUntil 사용 여부, wall time과 logs를 차례로 보는 편이 빠르다.

2. 어디서 실제로 막히는가

실무에서 먼저 헷갈리는 상황은 네 가지다. 첫째, 예전 1000 상한 기억 때문에 paid plan에서 subrequests 수치만 봐도 limit 초과를 의심한다. 둘째, 사용자가 응답을 빨리 닫은 뒤 analytics 저장이나 webhook 기록이 빠졌는데 이를 fetch 오류로만 본다. 셋째, waitUntil에 올려 둔 작업이 30초 안에 끝나지 않아 일부 후처리가 누락되는데 일반 timeout과 같은 증상으로 묶는다. 넷째, metrics의 subrequests 차트와 logs의 exception을 따로 봐서 한도와 취소 신호가 섞인다.

Cloudflare limits 문서는 HTTP-triggered Workers에 hard duration limit이 없다고 하면서도, 응답 완료 또는 client disconnect 뒤 outstanding work가 취소될 수 있고 waitUntil이 최대 30초를 연장한다고 적고 있다. changelog는 paid plan 기본 subrequests 상한이 10000으로 바뀌었고 더 높일 수 있다고 설명한다. 두 문서를 같이 읽으면 숫자 한도와 실행 수명은 다른 축이라는 점이 드러난다.

또 Observability 문서는 client disconnect를 Cancelled와 Response Stream Disconnected 같은 유형으로 나눠 보여 주고, Workers Logs에서는 $metadata.error와 $workers.outcome 필터를 쓰라고 안내한다. 즉 운영자는 subrequests 차트, disconnect 차트, wall time, logs를 한 번에 봐야 한다.

• 증상: 응답은 갔는데 후처리 저장이 간헐적으로 빠진다.
• 실패: 여전히 subrequests 1000 고정 상한을 전제로 본다.
• 막힘: waitUntil을 안 쓴 취소와 waitUntil 30초 안에 못 끝난 작업을 구분하지 않는다.
• 누락: Metrics의 subrequests/wall time과 Logs의 error/outcome을 같이 묶지 않는다.

상황	먼저 볼 곳	판단 기준
paid plan에서 subrequests가 많다	limits 설정	기본 10000인지 custom limit인지 본다
응답 뒤 작업이 사라진다	waitUntil 사용 여부	outstanding work 취소인지 본다
에러가 났는지 애매하다	Workers Logs outcome / exception	exception인지 disconnect인지 분리한다

3. 실무에서 적용하는 순서

실무 순서는 다섯 단계가 효율적이다. 먼저 현재 플랜과 wrangler limits.subrequests 값을 확인한다. 다음으로 요청 처리 안에서 응답에 반드시 필요한 fetch와 응답 뒤에도 남겨야 할 후처리를 나눈다. 세 번째로 후처리는 ctx.waitUntil로 옮기고, 30초 안에 끝나지 않을 작업은 Queue나 Workflow 같은 별도 수단을 검토한다. 네 번째로 Metrics에서 subrequests total/cached/uncached와 wall time per execution을 같이 본다. 마지막으로 Logs 또는 wrangler tail에서 outcome과 exception 필드를 닫는다.

1. plan과 wrangler limits부터 확인한다.
2. 응답 필수 fetch와 후처리 fetch를 코드에서 분리한다.
3. 후처리는 waitUntil로 옮기고 30초를 넘으면 더 durable한 수단으로 뺀다.
4. Metrics의 subrequests와 wall time을 같이 본다.
5. Logs에서 disconnect와 exception을 최종 확인한다.

이 순서를 고정하면 '숫자가 많다'와 '작업이 살아남지 못했다'를 별도로 설명할 수 있다. 예를 들어 subrequests total은 높지만 wall time과 logs가 안정적이면 단순히 호출이 많은 구조일 수 있고, subrequests는 적어도 Cancelled가 많다면 waitUntil로 넘기지 않은 후처리가 끊긴 것일 수 있다.

운영 메모 예시

plan=workers-paid
limits.subrequests=10000
subrequests.total=184
subrequests.cached=130
subrequests.uncached=54
wall_time_ms=1240
wait_until_used=true
disconnect_type=Cancelled
workers_outcome=ok

Workers가 열려 있는 동안의 fetch와 응답 이후의 후처리를 코드와 관측에서 같이 분리하면, 오래된 상한 감각 때문에 잘못된 remediation으로 가는 일을 줄일 수 있다.

4. 공식 문서와 예시 화면으로 확인하기

첫 공식 화면은 2026년 2월 changelog다. 여기서 가장 먼저 확인해야 할 사실은 paid Workers의 subrequests 상한이 예전 1000 고정이 아니라 기본 10000, 필요시 최대 1000만까지 조정 가능하게 바뀌었다는 점이다.

Cloudflare changelog는 paid plan Workers의 subrequests 기본 상한이 10000으로 바뀌고 구성으로 더 올릴 수 있다고 설명한다.

즉 예전처럼 'subrequests 1000을 넘어서 에러가 났다'로 바로 결론내리면 안 된다. 이제는 어떤 플랜인지, limits 구성을 바꿨는지, 그리고 실제로는 끊긴 클라이언트 때문에 취소된 것인지부터 다시 분리해 봐야 한다.

두 번째 자료는 현재 limits 문서의 핵심 문장이다. HTTP-triggered Worker는 클라이언트가 연결된 동안 계속 처리할 수 있지만, 응답이 끝나거나 클라이언트가 끊기면 연관 작업이 취소될 수 있고 ctx.waitUntil만 최대 30초를 더 벌어 준다.

Cloudflare limits 문서는 client disconnect 뒤 outstanding work가 취소될 수 있고 waitUntil이 최대 30초를 더 준다고 설명한다.

이 문장을 보면 subrequests 숫자와 후처리 생존 시간을 같은 문제로 보면 안 된다는 점이 선명해진다. 상한과 수명은 다른 축이다.

세 번째 공식 화면은 Observability 문서의 client disconnected by type 구간이다. 여기서는 Cancelled와 Response Stream Disconnected를 분리해 보여 준다.

Cloudflare는 client disconnect를 Cancelled와 Response Stream Disconnected 같은 유형으로 나눠 보여 준다.

따라서 후처리가 비정상 종료됐을 때도 무조건 subrequests 상한이나 일반 exception으로 몰지 말고, 먼저 disconnect 유형과 waitUntil 사용 여부를 대조해야 한다.

네 번째 자료는 코드 예시다. 응답 후에도 남겨야 하는 분석 로그, webhook 기록, 캐시 무효화처럼 클라이언트 연결과 분리해야 하는 작업은 waitUntil에 올려 두는 편이 맞다.

응답 뒤 후처리를 ctx.waitUntil로 분리한 Worker 예시다.

반대로 사용자가 기다리는 핵심 fetch까지 waitUntil로 밀어 두면 응답은 빨라 보여도 실제 비즈니스 동작이 유실될 수 있다. 무엇을 남길지 구분이 먼저다.

다섯 번째 자료는 triage 표다. 지금은 subrequests 상한 초과, client disconnect 취소, waitUntil 30초 초과, uncaught exception을 같은 실패로 보면 해석이 늦어진다.

Workers 실패 원인을 subrequests, disconnect, waitUntil, exception으로 나눈 triage 표다.

이미 CPU time과 subrequests 제한 글이 기본 비용 축을 다뤘다면, 이번 표는 2026년 기준 변경된 한도와 취소 신호를 다시 읽는 운영판이다.

마지막 자료는 metrics 읽는 순서다. Cloudflare는 subrequests total/cached/uncached와 wall time을 따로 보여 주므로, 숫자와 수명 문제를 한 장에 같이 두면 후처리 유실 원인이 빨리 드러난다.

subrequests, wall time, disconnect, logs를 함께 보는 운영 체크리스트다.

또 Vercel timeout 뒤 Runtime Logs를 보는 글과 같이 보면 서버리스 후처리 문제에서 '한도'와 '실행 수명'을 나눠 읽는 감각이 비슷하다는 점도 보인다.

5. 주의사항과 리스크

첫 번째 리스크는 free plan과 paid plan, 그리고 custom limits 차이를 구분하지 않는 것이다. 두 번째 리스크는 waitUntil이 있으니 후처리가 무조건 안전하다고 생각하는 것이다. 문서는 최대 30초를 말할 뿐 영구 보장을 약속하지 않는다. 세 번째 리스크는 Metrics만 보고 exception logs를 생략하거나, 반대로 logs만 보고 subrequests와 wall time을 보지 않는 것이다.

운영 전에 확인할 때는 subrequests 차트, wall time, disconnect 유형, workers outcome 네 신호를 같은 대시보드나 incident 템플릿에 넣는 편이 좋다. 그래야 limit, cancellation, exception을 각각 다른 remediation으로 보낼 수 있다.

• subrequests 숫자와 실행 수명 문제를 분리한다.
• waitUntil은 최대 30초 보조 수단이지 영구 작업 큐가 아니다.
• Metrics와 Logs를 같은 incident 메모에 묶는다.

6. 결론

Cloudflare Workers에서 후처리 누락을 읽을 때는 더 이상 예전 1000 subrequests 상한만 붙잡아서는 안 된다. plan과 limits를 먼저 확인하고, client disconnect, waitUntil, wall time, logs를 같이 보면 숫자 한도 문제와 취소 문제를 훨씬 짧게 자를 수 있다.

이 경계를 이해한 뒤에는 어떤 후처리를 waitUntil에 남기고 어떤 작업을 Queue와 Tail Worker로 분리할지 결정해야 한다. 30초를 넘는 후처리와 durable handoff를 구조적으로 나누는 후속 정리는 waitUntil과 Queue·Tail Worker 분기 글에서 이어진다.

• paid plan subrequests 기본 상한은 현재 10000이다.
• client disconnect 뒤 후처리는 waitUntil로 분리해야 살아남을 수 있다.
• subrequests, wall time, disconnect, outcome을 함께 본다.

7. 참고 링크

1. https://developers.cloudflare.com/workers/platform/limits/
2. https://developers.cloudflare.com/changelog/post/2026-02-11-subrequests-limit/
3. https://developers.cloudflare.com/workers/observability/errors/
4. https://developers.cloudflare.com/workers/observability/metrics-and-analytics/