홈시리즈멘토링

© 2026 정기창. All rights reserved.

본 블로그의 콘텐츠는 CC BY-NC-SA 4.0 라이선스를 따릅니다.

☕후원하기소개JSON Formatter러닝 대기질개인정보처리방침이용약관

© 2026 정기창. All rights reserved.

콘텐츠: CC BY-NC-SA 4.0

☕후원하기
소개|JSON Formatter|러닝 대기질|개인정보처리방침|이용약관

Github Actions 크론이 정시에 오지 않아서 — Cloudflare Workers로 옮긴 이야기

정기창·2026년 4월 26일

전편에서 우리는 "다음 글에서는 'Github Actions'을 설정할 때 추가로 고려해야할 부분이 무엇인지에 대해서 다룬다"고 약속했습니다. 그런데 막상 Github Actions로 크론을 설정해서 돌려보니 한 가지 큰 의문이 생겼습니다. 약속한 시간에 메시지가 오지 않는다는 점이었습니다.

Github Actions의 크론은 정시에 오지 않습니다

매일 오전 7시에 메시지를 받기로 설정했는데, 실제로는 7시 5분에 오기도 하고 7시 20분에 오기도 합니다. 어떤 날은 7시 30분에 오는 경우도 있고, 가끔은 아예 그 시간대를 건너뛰기도 합니다. 처음에는 제가 설정을 잘못한 줄 알았습니다. 그러나 알고 보니 이건 Github Actions가 처음부터 그렇게 설계된 영역이었습니다.

이유는 간단합니다. Github Actions는 무료로 제공되는 서비스이기 때문에, 전 세계의 수많은 사용자가 동시에 같은 시간대(예: 정각)에 작업을 돌리려고 합니다. 모두가 한꺼번에 몰리면 Github가 그 작업들을 하나씩 처리하면서 일부는 자연스럽게 뒤로 밀려납니다. 결과적으로 5분에서 30분, 심한 경우 1시간 이상의 오차가 일상적으로 발생합니다.

"하루에 한 번 받기만 하면 되니까 5분 정도 늦어도 괜찮지 않나요?"라고 생각할 수도 있습니다. 그러나 보고서가 정확히 출근 시간에 와야 한다거나, 5분 단위로 무언가를 체크해야 한다거나 하는 경우에는 이 오차가 꽤 거슬리는 문제로 다가옵니다.

그래서 다른 무료 대안을 찾아봤습니다

오전 7시 정각을 가리키는 시계와 주황색 구름, 구름을 통과해 받은편지함에 정확히 도착하는 편지로 Cloudflare Workers의 정시 크론을 표현한 일러스트

외부의 무료 크론 서비스는 의외로 많습니다. cron-job.org 같은 단순한 서비스부터, 큰 클라우드 회사가 제공하는 본격적인 서비스까지 종류가 다양합니다. 그중에서 제가 고른 것은 Cloudflare Workers라는 서비스입니다. 이유는 세 가지였습니다.

  • 약속한 시간에 정확하게 작동합니다 (Github Actions 같은 큰 지연이 없습니다).

  • 우리가 작성한 코드 안에서 바로 동작합니다 — 따로 서버를 직접 만들지 않아도 됩니다.

  • 그러면서도 비밀번호 같은 민감한 정보를 안전하게 보관해주는 기능이 갖춰져 있습니다.

Cloudflare는 원래 인터넷의 보안과 속도를 책임지는 큰 회사입니다. 그 회사의 인프라를 빌려서 우리가 짧게 작성한 코드를 무료로 실행할 수 있도록 해주는 것이 Cloudflare Workers입니다. 우리가 만든 코드를 우리 컴퓨터가 아니라 Cloudflare의 서버에서 5분마다 자동으로 실행시켜주는 셈입니다.

비밀번호 같은 정보는 어떻게 다룰까

예를 들어 슬랙(메신저)에 메시지를 보내려면 슬랙이 발급해주는 '웹훅 URL'이라는 긴 주소가 필요합니다. 이 주소가 외부에 노출되면 누구나 우리 슬랙 채널에 마음대로 메시지를 보낼 수 있게 됩니다. 그래서 이런 정보는 코드 안에 그대로 적어두면 안 됩니다.

Cloudflare Workers에는 이런 민감한 정보를 별도로 등록하는 화면이 있습니다. 이름과 값을 입력하고 '암호화'(Encrypt) 버튼을 누르면, 그때부터는 화면에서도 그 값을 다시 볼 수 없게 됩니다. 우리 코드 안에서는 "그 값을 가져와줘"라고만 말하면, Cloudflare가 알아서 안전한 보관함에서 꺼내 사용해줍니다. Github Actions에도 비슷한 기능이 있어서, 보관 방식 자체는 두 서비스 모두 어느 정도 비슷한 수준이라고 보면 됩니다.

로그를 켜는 방법, 그리고 '코드가 진실'이라는 원칙

크론이 매번 잘 작동했는지, 혹시 중간에 오류가 났는지를 확인하려면 '로그'라는 기록이 필요합니다. Cloudflare Workers에서는 이 기능이 기본적으로 꺼져있어서, 우리가 직접 켜주어야 합니다.

처음에는 Cloudflare 화면에 들어가서 토글 버튼만 누르면 끝일 줄 알았습니다. 그런데 이번 셋업의 한 가지 특징은 Github에 올린 코드를 Cloudflare가 자동으로 가져가서 실행하는 방식이라는 점이었습니다. 이런 환경에서 화면에서 토글만 누르고 끝내면, 다음에 코드를 한 번 고쳐서 Github에 올리는 순간 그 토글이 다시 풀려버릴 수 있습니다. 코드 안에 적힌 설정이 화면 설정을 덮어쓰기 때문입니다.

그래서 정석은 설정을 화면에 적는 게 아니라 코드 파일에 적고, 그 파일을 Github에 함께 올리는 것입니다. 이번에는 'wrangler.toml'이라는 작은 설정 파일에 "로그를 켜둘 것"이라는 한 줄을 추가하고, 그 변경 사항을 Github에 올렸습니다. 이렇게 해두면 매번 같은 설정이 자동으로 적용되어, 우리가 신경 쓸 일이 한 가지 줄어듭니다. 코드가 진실의 출처가 되는 셈입니다.

Github Actions를 쓰지 않은 이유, 정리

둘 다 무료라는 점에서는 비슷합니다. 그러나 비슷한 무료 서비스 중에서 굳이 Cloudflare Workers를 고른 이유는 다음 세 가지로 요약할 수 있었습니다.

  • 정시성 — 약속한 시간에 거의 정확히 작동합니다.

  • 외부 노출 차단 — 크론 전용으로만 만들어두면, 외부에서 호출할 수 있는 주소 자체가 만들어지지 않아 누군가 임의로 우리 코드를 실행시킬 가능성이 차단됩니다.

  • 설정과 코드의 일치 — Github에 올린 파일이 곧 동작하는 설정이라서, 화면에서 누른 토글이 다음 배포에 사라지는 혼란이 없습니다.

물론 Github Actions가 더 잘 어울리는 작업도 있습니다. 정확한 시간이 중요하지 않은 일일 백업이나, Github와 깊이 연결된 작업(코드 리뷰, 자동 테스트 실행 등)에는 Github Actions가 그대로 좋은 선택입니다. 다만 "매일 정해진 시간에 알림을 받기"처럼 시간 약속이 분명한 작업에는 Cloudflare Workers 같은 다른 도구가 더 잘 맞는다는 것이 이번에 알게 된 결론이었습니다.

다음 글에서는 이렇게 만든 자동화의 개수가 늘어났을 때, 그 상태를 한 자리에 모아 보는 방법에 대해서 이야기해보려 합니다.

바이브 코딩Cloudflare WorkersCronGithub Actions스케줄링자동화비개발자멘토링

관련 글

바이브 코딩을 한 내용이 주기적으로 실행되게 하려면 어떻게 해야할까

바이브 코딩으로 만든 소스코드가 매일 정해진 시간에 알아서 실행되려면 무엇이 필요할까요. 크론이라는 스케줄링 개념부터, 24시간 서버의 비용 문제, Github Actions라는 무료 대안까지 비개발자의 관점에서 차근차근 정리했습니다.

관련도 91%

NestJS 크론 작업을 Worker 프로세스로 분리하기 — Redis 없이 순수 프로세스 분리

NestJS에서 API 서버와 크론 작업을 별도 프로세스로 분리한 실전 기록입니다. Redis나 BullMQ 없이, SharedInfraModule과 createApplicationContext만으로 Worker를 분리하고 Dockerfile CMD 하나로 배포까지 완료했습니다.

관련도 89%

NestJS Cron으로 Grafana Cloud 서버 메트릭을 Slack에 자동 보고하기

NestJS 스케줄러와 Grafana Cloud Prometheus API를 연결해 매일 아침 서버 상태를 Slack으로 자동 보고하는 시스템을 구축한 과정을 정리했습니다. 이미 갖춰진 인프라를 활용해 최소한의 코드로 일일 리포트를 만드는 방법입니다.

관련도 88%