서버리스 크론잡 스케줄러 2026 — 서버 없이 정기 작업 돌리기

짧은 결론

• 크론잡은 "정해진 시각에 자동으로 실행되는 작업"이고, 서버리스 크론잡 스케줄러는 이걸 상시 켜둔 서버 없이 클라우드가 대신 트리거해주는 방식입니다.
• 관리 부담과 유휴 비용을 줄이고 싶다면 서버리스 방식이 유리하지만, 실행 시간이 아주 길거나 상태를 계속 유지해야 하는 작업에는 맞지 않습니다.
• 대표 유형은 클라우드 스케줄러(AWS EventBridge, GCP Cloud Scheduler), 플랫폼 자체 크론(Vercel Cron, Render Cron Jobs), 깃허브 액션 schedule 세 가지입니다.
• 실패·재시도·타임존 설정을 빠뜨리면 "분명 돌렸는데 안 돌았다"는 문제가 생기니 반드시 확인해야 합니다.
• 직접 서버를 띄워 무거운 크론을 상시 돌려야 한다면 DigitalOcean 같은 VPS도 대안이 됩니다.

크론잡이 뭔가요

크론잡(cron job)은 리눅스의 cron 데몬에서 유래한 용어로, "매일 새벽 3시에 이 스크립트를 실행해라" 같은 시간 기반 반복 작업을 뜻합니다. DB 백업, 오래된 로그 삭제, 매일 아침 리포트 메일 발송, 캐시 갱신처럼 사람이 매번 손으로 누르기엔 번거롭고 정해진 주기로 반복되는 작업이 대표적인 예입니다. 전통적으로는 리눅스 서버에 crontab -e로 스케줄을 등록해서 사용했는데, 이 방식은 그 서버가 항상 켜져 있어야 한다는 전제가 깔려 있습니다.

서버리스로 하는 이유 — 관리와 비용

서버를 하나 띄워서 크론만 돌리는 구조는 생각보다 손이 많이 갑니다. OS 패치, 크론 데몬 상태 점검, 서버가 죽었을 때 알림 받기, 트래픽이 거의 없는데도 24시간 요금이 나가는 문제까지 신경 쓸 게 많습니다. 하루 한 번, 몇 초짜리 스크립트 하나를 위해 서버를 상시 켜두는 건 비효율적입니다.

서버리스 크론잡 스케줄러는 이 부담을 클라우드 쪽으로 넘깁니다. 스케줄과 실행할 함수·엔드포인트만 등록해두면, 정해진 시각에 클라우드가 알아서 트리거하고 실행이 끝나면 리소스를 회수합니다. 실행한 시간만큼만 과금되는 경우가 많아서, 짧고 가벼운 작업일수록 비용 이점이 커집니다. 다만 인프라를 직접 들여다볼 수 없다 보니 세밀한 제어(예: 특정 CPU 사양 고정, 장시간 실행)가 필요한 작업에는 한계가 있다는 점도 함께 알아둬야 합니다.

방법 유형 세 가지

유형	예시	특징
클라우드 스케줄러	AWS EventBridge Scheduler, GCP Cloud Scheduler, Azure Logic Apps	세밀한 스케줄·재시도 정책 설정 가능, 다른 클라우드 서비스와 연동 편리
플랫폼 자체 크론	Vercel Cron, Render Cron Jobs, Railway Cron	이미 쓰고 있는 배포 플랫폼에서 바로 설정, 별도 인프라 지식 불필요
깃허브 액션 schedule	GitHub Actions on: schedule	저장소에 이미 있는 워크플로 문법 재사용, 무료 티어 범위 내 가벼운 작업에 적합

• 클라우드 스케줄러는 이미 AWS나 GCP를 쓰고 있고, Lambda·Cloud Functions 같은 서버리스 함수와 엮어서 정교하게 운영하고 싶을 때 적합합니다.
• 플랫폼 자체 크론은 Next.js나 Node.js 앱을 이미 Vercel·Render 등에 배포해뒀다면 가장 빠른 선택지입니다. 배포 설정 파일에 스케줄 몇 줄만 추가하면 끝납니다.
• 깃허브 액션 schedule은 코드 저장소가 이미 GitHub에 있고, 하루 몇 번 수준의 가벼운 작업(정적 사이트 리빌드, 간단한 크롤링, 알림 발송 등)이라면 별도 계정 없이 바로 쓸 수 있습니다.

간단한 예시 흐름

GitHub Actions로 매일 새벽 3시(UTC 기준 18시)에 스크립트를 돌리는 워크플로는 대략 이런 흐름입니다.

name: daily-report
on:
  schedule:
    - cron: "0 18 * * *"
jobs:
  run-report:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4
      - run: node scripts/send-daily-report.js

Vercel Cron이라면 vercel.json에 경로와 스케줄만 등록하면 되고, AWS EventBridge Scheduler라면 콘솔이나 IaC로 대상 Lambda ARN과 cron 표현식을 지정하는 방식입니다. 공통점은 "직접 24시간 서버를 붙잡고 있지 않아도 된다"는 점입니다.

실패·재시도·타임존 주의사항

서버리스 크론잡은 편하지만 몇 가지는 반드시 챙겨야 합니다.

• 재시도 정책 — 네트워크 문제나 일시적 오류로 실행이 실패했을 때 자동 재시도할지, 몇 번까지 시도할지 서비스마다 기본값이 다릅니다. 기본값을 그대로 두면 중요한 작업이 한 번 실패하고 그냥 넘어갈 수 있으니 재시도 횟수와 알림 설정을 직접 확인해야 합니다.
• 중복 실행 방지 — 재시도나 스케줄 겹침으로 같은 작업이 두 번 실행될 수 있습니다. 결제·메일 발송처럼 중복되면 곤란한 작업은 멱등성(idempotency)을 갖도록 설계해야 합니다.
• 타임존 — 크론 표현식은 기본적으로 UTC 기준인 서비스가 많습니다. "한국 시간 새벽 3시"를 의도했는데 UTC로 등록해버리면 실제로는 낮 12시에 돌아갑니다. 서비스별로 타임존 설정이 가능한지, 아니면 UTC로 직접 환산해야 하는지 반드시 확인하세요.
• 실행 시간 제한 — 서버리스 함수는 대부분 최대 실행 시간이 정해져 있습니다(예: 몇 분 단위). 이 시간을 넘기는 무거운 배치 작업이라면 서버리스보다 직접 서버를 운영하는 편이 안전할 수 있습니다.
• 모니터링 — 크론잡은 사람이 직접 지켜보지 않는 작업이라, 실행 여부와 성공·실패를 로그나 알림으로 남겨두지 않으면 문제가 한참 지나서야 발견되는 경우가 많습니다.

서버리스가 안 맞는 경우

모든 크론잡을 서버리스로 옮길 필요는 없습니다. 실행 시간이 길고 무거운 배치(대용량 데이터 처리, 오래 걸리는 영상 인코딩 등)나, 여러 크론잡이 상태를 공유하며 복잡하게 얽혀 있는 경우에는 오히려 직접 서버를 두고 관리하는 편이 더 예측 가능합니다. 이런 상황이라면 DigitalOcean 같은 VPS에 크론 데몬을 그대로 올리고, 필요한 만큼 리소스를 고정 배정해서 운영하는 방법도 여전히 유효한 대안입니다.

마무리

크론잡 자체는 오래된 개념이지만, 이를 서버 없이 클라우드가 트리거해주는 서버리스 방식은 관리 부담과 비용을 크게 줄여줍니다. 이미 쓰는 배포 플랫폼이 있다면 플랫폼 자체 크론부터 시작하고, 더 세밀한 제어가 필요해지면 클라우드 스케줄러로, 저장소 기반 자동화라면 깃허브 액션 schedule로 넘어가는 순서가 무난합니다. 다만 재시도·타임존·실행 시간 제한은 서비스마다 기본값이 다르니 등록 후 꼭 한 번은 실제로 실행 로그를 확인해보길 권합니다.

자주 묻는 질문

서버리스 크론잡은 완전히 무료인가요?

서비스마다 다릅니다. GitHub Actions나 일부 플랫폼 크론은 일정 사용량까지 무료 티어를 제공하지만, 실행 빈도가 잦거나 실행 시간이 길어지면 유료 구간으로 넘어갈 수 있습니다. 등록 전에 해당 서비스의 무료 티어 한도를 확인하는 게 좋습니다.

크론 표현식은 어떻게 읽나요?

일반적인 크론 표현식은 "분 시 일 월 요일" 다섯 자리로 구성됩니다. 예를 들어 0 18 * * *는 "매일 18시 0분"을 뜻합니다. 서비스마다 초 단위가 추가되는 등 세부 문법 차이가 있을 수 있으니 사용하는 서비스의 문서에서 표현식 형식을 확인하는 것이 안전합니다.

실행이 실패했는지 어떻게 알 수 있나요?

대부분의 서버리스 크론 서비스는 콘솔에서 실행 이력과 성공·실패 로그를 제공합니다. 여기에 더해 실패 시 이메일이나 슬랙 알림을 받도록 별도로 연동해두면, 콘솔을 매번 확인하지 않아도 문제를 바로 파악할 수 있습니다.