Cloudflare Queues: 엣지의 백그라운드 작업

Cloudflare Queues는 모든 서버리스 애플리케이션이 언젠가는 마주치는 문제를 해결합니다. 사용자가 기다릴 이유가 없는 작업을 유발하는 요청이 들어온다는 문제입니다. 확인 메일 발송, 업로드된 이미지 리사이즈, 레코드를 외부 서비스로 동기화하는 처리 같은 것들입니다. 전통적인 서버라면 그 일을 백그라운드 워커 프로세스에 넘기면 됩니다. 그런데 Workers에는 넘길 프로세스 자체가 없습니다.

흔히 쓰이는 우회책들은 보기보다 나쁩니다. 요청 안에서 그대로 처리하면 사용자가 메일 발송 업체의 응답을 기다리게 됩니다. 다른 Worker로 요청만 던지고 기다리지 않는 방식은 호출한 실행이 먼저 끝나는 순간 작업을 잃습니다. 두 방식 모두 외부 제공업체의 장애를 견디지 못합니다.

큐가 실제로 주는 것: 속도가 아니라 내구성과 재시도입니다. 프로듀서는 메시지를 기록한 즉시 반환되고, 별도의 컨슈머 Worker가 그 메시지를 가져갑니다. 컨슈머가 실패하면 메시지는 허공으로 사라지는 대신 큐로 되돌아갑니다. 가치는 그게 전부입니다. 백그라운드 작업이 재실행을 견디지 못하는 성격이라면 큐를 붙여도 구제되지 않습니다.

조각들이 맞물리는 방식

큐에는 양쪽 끝이 있고, 그 양쪽 모두 Workers입니다.

프로듀서는 큐 바인딩을 가진 아무 Worker나 될 수 있습니다. 메시지 본문과 함께 send를 호출하면, 그 호출은 메시지가 영구적으로 저장된 시점에 곧바로 반환됩니다. 사용자의 요청은 실제 작업이 끝나기를 기다리지 않고 종료됩니다.

컨슈머는 큐 핸들러를 가진 Worker입니다. Cloudflare가 메시지 묶음을 넘겨 호출하고, 핸들러는 성공적으로 처리한 메시지를 하나씩 확인 응답합니다. 확인 응답되지 않은 것은 모두 재전달됩니다.

설계할 때 가장 신경 써야 하는 부분이 바로 이 재전달 동작입니다. 메시지는 두 번 이상 도착할 수 있고, 따라서 컨슈머는 멱등해야 합니다. 멱등성 키 없이 큐 컨슈머 안에서 카드를 결제하는 구현은 결국 환불 작업을 만들어 냅니다. 메일이 두 번 가는 것은 성가신 정도지만, 결제가 두 번 되는 것은 곧바로 고객 지원 사고입니다.

데드 레터 큐는 반복해서 실패하는 메시지를 받아 둡니다. 이것이 없으면 영구적으로 깨진 메시지는 시도 횟수를 다 쓸 때까지 재시도되다가 그대로 사라집니다. 있으면 나중에 열어 볼 수 있는 곳에 떨어집니다. 필요해진 다음이 아니라, 필요해지기 전에 설정해 두십시오.

오퍼레이션 한 건의 실제 비용

요금 모델은 사람을 헷갈리게 할 만큼 독특합니다. 과금 단위가 메시지 건수가 아니기 때문입니다.

오퍼레이션은 쓰기, 읽기, 삭제된 데이터 64 KB마다 한 건씩 계산됩니다 . 64 KB 미만의 메시지가 정상적으로 전달되면 쓰기 한 번, 읽기 한 번, 삭제 한 번으로 모두 세 오퍼레이션입니다. 127 KB 메시지라면 동작마다 두 오퍼레이션이 되므로, 같은 한 번의 전달에도 합계 여섯 오퍼레이션이 듭니다.

재시도는 계산을 바꿉니다. 재전달할 때마다 읽기가 한 건 더 생기고, 데드 레터 큐에 쓰는 것도 쓰기 한 건으로 더해집니다. 한 메시지에서 다섯 번 실패한 뒤에야 성공하는 컨슈머는 세 오퍼레이션과는 비교가 안 되는 비용을 씁니다. 재시도 횟수를 올릴 것이 아니라 불안정한 컨슈머 자체를 고쳐야 하는 이유가 여기에 있습니다.

싸다고 단정하기 전에 자기 트래픽으로 직접 계산해 보십시오. 한 달에 100만 건, 건당 세 오퍼레이션이면 300만 오퍼레이션이고, 유료 플랜 포함량을 넘겨 대략 80펜스가 청구됩니다. 그 정도면 확실히 저렴합니다. 그러나 하루에 1000만 건이라면 완전히 다른 이야기가 됩니다.

적합 여부를 가르는 제한

Cloudflare의 Queues 제한 문서 를 2026년 8월에 확인한 값입니다.

이 가운데 둘이 나머지보다 훨씬 중요합니다. 메시지당 128 KB 상한은 파일을 큐에 넣지 않는다는 뜻입니다. 큐에는 포인터만 넣고 파일은 R2에 두는데, 어차피 그쪽이 올바른 형태입니다. 25 GB 백로그는 조용히 진행되는 재난에서 여러분을 지켜 주는 장치입니다. 금요일에 컨슈머가 망가졌는데 아무도 눈치채지 못하면 큐가 가득 차고, 그 다음부터는 새 메시지를 조용히 버리는 대신 스토리지 오류로 거절합니다.

초당 5,000 메시지라는 처리량은 넉넉하지만 어디까지나 큐 하나 기준입니다. 한 큐에 부하가 몰리면 그 지점이 병목이 되는데, 여러 큐로 샤딩하는 설계로 미리 피할 수 있습니다.

Cloudflare Queues가 오답인 경우

작업이 정말로 동기적일 때. 사용자가 화면에서 결과를 봐야 한다면, 큐에 넣는 순간 왕복이 하나 늘고 폴링 문제가 따라붙을 뿐입니다. 그 자리에서 처리하고, 빠르게 만드십시오.

순서가 보장된 정확히 한 번 처리가 필요할 때. Queues가 제공하는 것은 최소 한 번 전달입니다. 엄격한 순서나 정확히 한 번 의미론을 요구하는 일에는 큐가 제공하지 않는 조정이 필요하고, Cloudflare에서는 보통 Durable Object가 그 역할을 맡습니다.

트리거로 시작되는 작업이 아니라 예약 작업일 때. 야간 정리 작업에는 큐가 필요 없습니다. Worker를 직접 호출하는 cron 트리거가 더 단순하고 움직이는 부품도 적습니다.

작업이 15분을 넘길 때. 실행 시간 한도를 넘긴 컨슈머는 작업 도중에 강제로 종료됩니다. 여러 단계에 걸친 긴 처리에 필요한 것은 단계를 넘나드는 지속 실행을 위해 만들어진 Cloudflare Workflows이지, 15분 내내 상태를 붙들고 있으려는 큐 컨슈머가 아닙니다.

Cloudflare Workers로 서버리스 API 만들기 가이드는 이런 작업을 만들어 내는 요청 경로 자체를 다루고, Cloudflare Workers와 AWS Lambda 비교 는 대부분의 팀이 전제로 들고 오는 SQS 더하기 Lambda 패턴과 실행 모델이 어떻게 다른지 설명합니다.

어디서 시작할까

요청 핸들러 안에서 사용자가 기다릴 필요가 없는 작업 하나만 골라, 그것만 밖으로 옮기십시오. 첫날부터 데드 레터 큐를 붙이고, 컨슈머를 멱등하게 만들고, 백로그 지표는 비어 있으리라 짐작하지 말고 실제로 지켜보십시오.

Mecanik은 소프트웨어 개발 팀을 통해 엣지 아키텍처를 설계하고 검토합니다. 여기에는 그 작업에 정말 큐가 필요한지 누군가 되묻는 과정도 포함됩니다. 대부분의 시스템에 필요한 큐는 하나나 둘이지, 기능마다 하나가 아닙니다.

함께 읽기: Cloudflare Hyperdrive: 엣지에서 Postgres 연결하기 , 2026년 웹 앱 개발 방법: 영국 개발자 가이드 , Cloudflare D1: 엣지에서 서버리스 SQL 데이터베이스 구축하기 , Cloudflare Workers AI: 2026년 엣지에서 AI 모델 실행하기 .

자주 묻는 질문

Cloudflare Queues 요금은 얼마인가요? Workers Free 플랜에는 하루 10,000 오퍼레이션이, 유료 플랜에는 한 달 100만 오퍼레이션이 포함되며, 초과분은 100만 오퍼레이션당 0.40달러이고 아웃바운드 전송 요금은 없습니다. 오퍼레이션은 쓰기, 읽기, 삭제된 64 KB마다 한 건으로 계산되므로 64 KB 미만의 일반 메시지는 쓰기 한 번, 읽기 한 번, 삭제 한 번으로 모두 세 오퍼레이션이 듭니다.

Cloudflare Queues에서 오퍼레이션으로 계산되는 것은 무엇인가요? 쓰기, 읽기, 삭제된 데이터 64 KB마다 한 건입니다. 64 KB보다 작은 메시지는 동작마다 한 오퍼레이션이지만, 127 KB 메시지는 동작마다 두 오퍼레이션입니다. 재시도할 때마다 읽기가 한 건씩 더해지고 데드 레터 큐에 쓰면 쓰기가 한 건 더해지므로, 불안정한 컨슈머는 메시지당 기본 세 오퍼레이션보다 훨씬 큰 비용을 냅니다.

Cloudflare Queues의 최대 메시지 크기는 얼마인가요? 메시지당 128 KB이며, 배치 전송은 100건 또는 합계 256 KB로 제한됩니다. 이 상한 때문에 실제 데이터는 R2 같은 오브젝트 스토리지에 두고 큐에는 포인터만 넣게 되는데, 제한과 무관하게 그편이 더 나은 설계입니다.

Cloudflare Queues는 정확히 한 번 전달을 보장하나요? 아니요. 전달은 최소 한 번이므로 메시지가 두 번 이상 도착할 수 있고 컨슈머는 멱등해야 합니다. 멱등성 키 없이 컨슈머 안에서 결제를 청구하거나 크레딧을 발급하면 언젠가는 중복이 생깁니다. 엄격한 순서나 정확히 한 번 의미론이 필요하다면 대신 Durable Object를 쓰십시오.

Cloudflare Queues를 쓰지 말아야 할 때는 언제인가요? 사용자가 결과를 기다리고 있을 때, 엄격한 순서나 정확히 한 번 처리가 필요할 때, 작업이 트리거가 아니라 예약 실행이고 cron 트리거로 충분할 때, 또는 작업이 컨슈머의 15분 실행 시간 한도를 넘길 때입니다. 마지막 경우를 위해 존재하는 것이 바로 Cloudflare Workflows입니다.