매일 도는 작업을 서버 cron에 둘지 GitHub Actions에 둘지 정한 기준

선택지가 둘이었다

작은 알림 작업을 매일 아침 실행해야 했다. 서버에 이미 접속할 수 있으니 cron으로 끝낼 수도 있었고, 코드 저장소에 붙여 GitHub Actions 스케줄로 돌릴 수도 있었다. 둘 다 가능해서 오히려 기준이 필요했다.

내가 겪은 애매함은 실패 알림이었다. 서버 cron은 조용히 실패하기 쉬웠고, Actions는 로그가 잘 남지만 외부 네트워크나 비밀값 관리가 신경 쓰였다.

cron이 편했던 경우

서버 내부 파일이나 로컬 DB에 가까운 작업은 cron이 단순했다.

crontab -e

예를 들어 매일 로그를 압축하는 작업은 서버 안에서 끝난다.

10 3 * * * /usr/local/bin/rotate-app-log.sh >> /var/log/app-cron.log 2>&1

이 방식은 빠르고 의존성이 적다. 대신 로그 파일 위치, 실행 사용자, 환경 변수 로딩을 직접 챙겨야 한다.

GitHub Actions가 나았던 경우

저장소 코드와 함께 테스트하고 싶은 작업은 Actions가 편했다.

name: daily-check
on:
  schedule:
    - cron: '0 0 * * *'
  workflow_dispatch:

jobs:
  run:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4
      - run: python scripts/daily_check.py

코드 변경과 실행 기록이 같이 남는 점이 좋았다. 특히 학생 팀 프로젝트처럼 서버 접근 권한을 모두에게 주기 애매할 때 도움이 된다.

선택할 때 쓴 질문들

• 작업 대상이 서버 내부에만 있는가?
• 실패했을 때 어디로 알림을 받을 것인가?
• 비밀값이 서버에 있는 편이 안전한가, 저장소 Secret이 나은가?
• 수동 재실행 버튼이 필요한가?
• 실행 시간이 길어져도 괜찮은가?

결정

이번 알림 작업은 외부 API를 호출하고 결과 로그를 팀원이 같이 봐야 해서 GitHub Actions로 뒀다. 반대로 로그 정리와 백업 압축은 서버 cron에 남겼다.

한쪽이 항상 정답은 아니었다. 서버 안에서 끝나고 조용히 자주 도는 일은 cron, 코드 리뷰와 실행 기록이 중요한 일은 Actions. 이렇게 나누니 다음 정기 작업을 추가할 때 고민 시간이 줄었다.