Vercel에서 백그라운드 작업도 함께 돌립니다, Daemons 공개 베타

Vercel이 2026년 10월 15일, 작업을 계속 가져와 처리하는 백그라운드 프로세스를 위한 Daemons를 공개 베타로 선보였습니다. 웹앱과 워커를 같은 프로젝트에서 배포할 수 있습니다. 도입을 검토한다면 실행 방식뿐 아니라 재시도 설계, 베타 제한, 요금제별 할당량도 함께 확인해야 합니다.

무엇이 달라졌나요?

Vercel Daemons는 큐, 데이터베이스, 외부 시스템에서 일감을 가져오는 장시간 실행 프로세스를 지원합니다. 공식 발표가 든 사례는 Celery·BullMQ 같은 큐 소비자, Temporal·Cadence 워커, 작업을 기다리는 자체 호스팅 CI 러너입니다. 요청을 받기 위한 HTTP 서버를 따로 만들 필요가 없습니다. 컨테이너는 Fluid compute에서 실행되며, 개발자가 지역별 인스턴스 수를 정하면 Vercel이 그 수를 유지합니다. 종료되거나 충돌한 인스턴스도 다시 시작합니다. 공식 발표

초보자에게는 ‘사용자 화면 뒤에서 일감을 기다리는 작업자’라고 생각하면 쉽습니다. 사용자가 버튼을 누르는 순간 모든 처리를 끝내는 대신, 할 일을 기록해 두고 작업자가 가져가는 구조입니다. 뉴스의 핵심은 웹사이트와 이런 작업자의 배포를 한 프로젝트 안에서 다룰 수 있게 됐다는 점입니다. 다만 이 구조를 택한다고 서비스 전체의 운영 책임이 사라지는 것은 아닙니다.

어떤 작업에 어울리나요?

Vercel의 별도 소개 글은 영상 처리 앱을 예로 듭니다. Python과 ffmpeg를 함께 담은 컨테이너가 Vercel Queues에서 작업을 가져와 동영상과 썸네일을 처리하는 구성입니다. 이 사례처럼 실행에 필요한 도구를 컨테이너에 묶고, 다음 일감을 기다리는 반복 루프가 있는 워커가 주요 대상입니다. 백엔드 확장 소개

설명용 구성도입니다. Daemon 워커가 큐에서 작업을 가져오며, 중단·재시도와 중복 처리는 별도로 설계해야 합니다.

출처: VECTORLOG 설명용 구성도 · Vercel 공식 문서 기반

운영 관점에서는 다음 기준으로 검토해볼 수 있습니다. 이미 큐를 읽는 워커가 있고 웹앱과 함께 버전을 관리하고 싶다면 검토할 만합니다. 반대로 화면 요청에 응답하는 API가 필요하다면, 먼저 요청을 받는 실행 환경을 선택해야 합니다. Daemons의 역할을 정하지 않고 기존 백엔드를 통째로 옮기는 계획부터 세우면 네트워크 방식이나 저장소에서 예상치 못한 차이를 만날 수 있습니다.

배포는 어떻게 연결되나요?

공식 설정 문서는 프로젝트 최상위의 daemons 항목에 워커 이름과 설정을 작성하도록 안내합니다. 필수 값은 소스 위치인 root, Dockerfile 또는 Containerfile 위치인 entrypoint, 지역별 개수인 replicas입니다. 필요하면 실행 명령과 메모리도 지정합니다. 기본 메모리는 2 GiB이며, 이미지 대상 아키텍처는 Linux amd64입니다. 설정 레퍼런스

프로덕션 배포가 바뀌면 Daemons도 그 배포의 설정에 맞춰 교체됩니다. 이때 구버전과 신버전이 잠시 함께 실행될 수 있습니다. 따라서 메시지 형식과 데이터베이스 변경은 두 버전이 동시에 처리해도 안전해야 합니다. 대시보드에서 지정한 인스턴스 수 재정의는 다음 배포에도 유지되므로, 설정 파일만 고쳤는데 개수가 그대로라면 이 항목도 확인할 필요가 있습니다. 관리 문서

재시작과 작업 복구는 각각 설계해야 합니다

공식 개요는 인스턴스가 언제든 멈출 수 있다고 설명합니다. 종료 신호인 SIGTERM을 받으면 새 작업 수신을 멈추고 진행 중인 일을 정리해야 합니다. 기본 종료 유예 시간은 10초입니다. 작업은 여러 번 실행돼도 결과가 망가지지 않도록 만들고, 큐 메시지의 완료 확인은 실제 처리가 끝난 뒤 보내라고 권고합니다. Daemons 개요

예를 들어 결과를 저장했지만 완료 확인을 보내기 직전에 프로세스가 종료될 수 있습니다. 다음 작업자가 같은 일을 다시 받았을 때 결과가 중복 생성되지 않도록 작업 ID와 처리 상태를 확인하는 식의 대비가 필요합니다. 이는 운영 설계를 설명하기 위한 예시입니다. ‘프로세스를 다시 띄운다’는 기능을 ‘모든 업무가 정확히 한 번 완료된다’는 보장으로 읽어서는 안 됩니다.

Vercel Queues 역시 최소 한 번 전달하는 방식을 설명합니다. 처리 결과가 성공했더라도 확인이 늦거나 장애가 발생하면 메시지가 다시 전달될 수 있습니다. 재전달과 중복 처리는 큐를 사용하는 코드에서 고려해야 합니다. Queues 개념

Queues와 Workflows는 어떻게 구분하나요?

Queues의 poll 모드에서는 애플리케이션이 준비된 시점에 직접 메시지를 가져옵니다. 외부 서비스의 처리 속도 제한에 맞추거나 계속 실행되는 소비자를 둘 때 활용할 수 있습니다. Daemons는 이 소비자를 실행할 장소가 됩니다. 같은 큐에서도 소비자 그룹별로 push와 poll 방식을 선택할 수 있습니다. Poll 모드

Workflows는 여러 단계의 상태를 보존하며 중단·재개하는 업무 흐름을 위한 기능입니다. 실패한 단계의 재시도, 외부 이벤트 기다리기, 충돌과 배포를 거친 재개를 지원합니다. 공식 문서는 Functions가 코드를 실행하고 Queues와 관리형 저장소가 실행을 뒷받침한다고 설명합니다. Workflows 개요

따라서 선택할 때는 ‘오래 걸리는가’만 묻기보다, ‘계속 일감을 가져오는 프로세스가 필요한가’, ‘메시지를 전달하고 싶은가’, ‘여러 단계의 진행 상태를 보존하고 싶은가’를 나눠 보는 편이 좋습니다. 세 기능은 함께 쓸 수도 있습니다.

무료 체험과 상시 운영의 조건

베타는 Hobby를 포함한 모든 요금제에서 제공되지만 할당량이 다릅니다. Hobby의 팀당 월 한도는 10 vCPU-hours입니다. 1 vCPU 인스턴스 하나가 계속 실행되면 약 10시간에 소진되며, 한도에 도달하면 팀의 Daemons가 멈춥니다. Pro의 기본 동시 실행 한도는 16 vCPU와 메모리 32 GiB입니다. 이 수치는 가격이나 무료 제공량을 뜻하지 않습니다. 베타 제한

현재 베타는 프로덕션 환경에서만 실행되며 프리뷰 배포, 자동 확장, 영구 로컬 저장소를 지원하지 않습니다. 프로젝트 루트가 하위 폴더로 지정된 구성도 제한 대상입니다. 로컬 테스트는 Docker로 진행합니다. 실제 도입 전에는 최신 사용량·과금 안내도 확인해 주세요. 베타 제한

도입 전 체크리스트

다음은 위 문서를 바탕으로 정리한 실무 검토 순서입니다.

• 워커가 외부 요청을 받는 서버인지, 스스로 일감을 가져오는 프로세스인지 구분합니다.
• 처리 중 종료되는 상황을 재현하고, 같은 작업을 두 번 실행해 결과를 확인합니다.
• 결과 저장과 완료 확인 사이에서 실패했을 때의 동작을 점검합니다.
• 구버전·신버전 워커가 같은 메시지를 처리할 수 있는지 살펴봅니다.
• 인스턴스 수, 큐 적체량, 외부 API 제한을 함께 기록합니다.
• 체험용 할당량과 장기 운영 예산을 구분하고, 배포 전 중지 방법도 정합니다.

처음에는 중복 실행과 실패를 쉽게 확인할 수 있는 작은 작업으로 검증하는 편이 낫습니다. 컨테이너가 실행됐다는 사실과 실제 업무가 끝났다는 사실을 각각 기록하면 문제를 찾기도 쉽습니다.

자주 묻는 질문

웹사이트도 Daemons에 올리면 되나요?

Daemons는 인바운드 HTTP·TCP 트래픽을 받지 않습니다. 요청에 응답하는 워크로드에는 Functions나 Services를 검토합니다. 제한 문서

충돌하면 작업이 이어서 실행되나요?

Vercel은 인스턴스를 다시 시작합니다. 작업의 진행 상태와 안전한 재시도는 별도 설계가 필요합니다. 단계별 상태 보존이 필요하다면 Workflows의 실행 모델도 함께 살펴볼 만합니다. Daemons, Workflows

기존 프로젝트에 바로 적용해도 될까요?

먼저 메시지 호환성, 종료 처리, 할당량을 확인하는 것이 좋습니다. 이 글은 공식 발표와 문서의 해설이며, 실제 도입 테스트나 성능 검증을 수행한 사용기는 아닙니다.

자료 확인: 2026년 10월 16일 KST. 공식 발표일은 2026년 10월 15일입니다.

Vercel, Vercel 디자인, Next.js 및 관련 상표·디자인·로고는 미국과 기타 국가에서 Vercel, Inc. 또는 그 계열사의 상표 또는 등록상표입니다.