[Cloudflare Workers][비용]CPU time과 subrequests 제한을 배포 전에 확인하는 법

IT 실무 리서치

[Cloudflare Workers][비용]CPU time과 subrequests 제한을 배포 전에 확인하는 법

Cloudflare Workers는 요청 수만 계산하면 실제 비용과 제한을 놓치기 쉽다. 요청 하나가 내부에서 만드는 fetch, KV/D1/R2 접근, CPU time, subrequests를 표로 적고 배포 후 로그에서 느린 요청을 확인해야 한다.

목차

1. 개요
2. 요청 하나가 만드는 내부 호출
3. CPU time과 subrequests 같이 보기
4. wrangler tail로 확인
5. 나눠야 하는 작업
6. 결론
7. 참고 링크

1. 개요

Workers 비용을 요청 수로만 보면 위험하다. 사용자는 한 번 호출했지만 Worker 내부에서는 인증 확인, 외부 API 호출, DB 조회, 로그 저장이 연달아 일어난다. 이 내부 호출이 subrequests와 CPU time을 키운다.

배포 전에는 가격표를 보는 것에서 끝내지 말고 요청 하나가 만드는 작업을 표로 적는다. 배포 후에는 `wrangler tail`이나 Workers Logs에서 느린 요청과 제한 오류를 확인한다.

2. 요청 하나가 만드는 내부 호출

공식 문서에서 봐야 할 곳은 요청 수가 아니라 CPU time과 subrequests 항목이다. 이 두 항목이 실제 구조와 맞는지 아래 표로 옮긴다.

Cloudflare Workers limits 문서에서 CPU time과 subrequests 제한 항목을 확인한다.

문서 캡처만으로는 비용을 계산할 수 없다. 요청 하나가 내부에서 무엇을 호출하는지 직접 표로 적어야 한다.

아래 표는 실제 설계 검토에서 먼저 만드는 자료다. 메뉴 화면보다 요청 하나가 내부에서 몇 번 외부 호출을 만드는지 보이는 표가 더 도움이 된다.

박스가 있는 리포트 생성 단계처럼 fan-out이 큰 작업은 subrequests를 빠르게 늘린다.

이 표에서 누적 호출 수가 커지는 구간을 찾으면 구조 변경 후보가 보인다. 캐시, Queue, 별도 백엔드 분리를 검토할 지점이다.

3. CPU time과 subrequests 같이 보기

느린 요청 로그 남기기

export default {
  async fetch(request, env) {
    const startedAt = Date.now();
    const user = await fetch("https://api.example.com/user");
    const plan = await fetch("https://api.example.com/plan");

    console.log(JSON.stringify({
      path: new URL(request.url).pathname,
      elapsedMs: Date.now() - startedAt,
      subrequests: 2
    }));

    return Response.json({ ok: user.ok && plan.ok });
  }
};

외부 API 주소와 인증 값은 샘플이다. 실제 토큰은 Cloudflare secret이나 별도 secret store에서 읽고 로그에 남기지 않는다.

제한 확인은 문서 읽기와 코드 구조를 같이 봐야 한다. 아래 흐름처럼 요청별 내부 호출을 먼저 세고, 그다음 limits와 pricing에 대입한다.

화살표 순서대로 보면 가격표와 실제 코드 구조를 연결할 수 있다.

preview 환경에서 빠르게 보였다고 production에서도 안전하다고 보장할 수 없다. 배포 후 실제 트래픽에서 느린 요청과 오류 코드를 확인한다.

4. wrangler tail로 확인

로그 화면에서는 상태 코드보다 경로와 elapsedMs를 같이 본다. 박스가 있는 줄처럼 특정 API에서만 CPU time 오류가 나면 그 경로의 내부 호출을 다시 세어야 한다.

Exceeded CPU Time이 보이면 요청 수보다 실행 구조를 먼저 본다. 외부 호출이 많은 작업은 분리 후보가 된다.

조치를 비용 요금제 변경으로만 끝내면 같은 구조가 더 큰 비용으로 이어질 수 있다. 리포트 생성, AI 호출, 대량 외부 API 호출은 Queue나 백엔드 job으로 분리한다.

5. 나눠야 하는 작업

어떤 작업을 Workers에 남길지 정할 때는 실행 시간이 짧고 외부 호출이 적은지 본다. 아래 표의 박스가 있는 행처럼 오래 걸리는 작업은 분리 후보다.

대량 리포트 생성처럼 긴 작업은 Workers 안에서 끝내려 하지 말고 Queue나 별도 백엔드 후보로 본다.

Workers는 짧고 빠른 edge 작업에 강하다. 구조를 나누면 비용도 예측하기 쉬워지고 제한 오류도 줄어든다.

6. 결론

Cloudflare Workers 비용과 제한은 요청 수 하나로 판단하지 않는다.

요청 하나가 만드는 내부 호출, CPU time, subrequests, production 로그를 같이 봐야 한다. 외부 호출이 많은 작업은 Workers 안에 억지로 넣기보다 Queue나 별도 백엔드로 나누는 편이 안전하다.

최근에는 subrequests 상한 숫자 자체도 바뀌었기 때문에 예전 기억만 믿고 배포 판단을 하면 어긋나기 쉽다. paid 기본 상한이 커진 뒤에는 숫자보다 client disconnect 이후 취소와 ctx.waitUntil() 연장 범위를 같이 봐야 하니, 이 분기점이 필요하면 [Cloudflare Workers][운영] subrequests 상한이 달라진 뒤 client disconnect와 waitUntil 취소를 어디서 구분하나를 이어서 보면 된다.

7. 참고 링크

1. https://developers.cloudflare.com/workers/platform/limits/
2. https://developers.cloudflare.com/workers/platform/pricing/
3. https://developers.cloudflare.com/changelog/post/2026-02-11-subrequests-limit/