리눅스에서 작업 스케줄링하기: cron vs systemd timer 비교

리눅스 시스템 관리에서 “언제” 작업이 실행되느냐는 “무엇”을 실행하느냐만큼 중요합니다. 가장 오래된 친구는 cron, 요즘 배포판에서 많이 쓰이는 건 systemd timer입니다. 이 글에서는 두 가지를 비교하면서, 실제로 어떤 상황에서 무엇을 쓰면 좋을지 정리해 보겠습니다.

1. 왜 cron과 systemd timer를 비교해야 할까?

Commandbox 광고

대부분의 리눅스 서버에는 이런 요구가 있습니다.

  • 매일 새벽 3시에 백업 실행
  • 5분마다 헬스 체크 스크립트 실행
  • 매주 일요일에 로그 압축 및 정리
  • 부팅 후 1분 뒤에 한 번만 실행해야 하는 초기화 작업

전통적으로는 전부 cron으로 처리했지만, 요즘은 많은 배포판이 systemd를 기본 init 시스템으로 사용하고 있고, 이에 따라 “타이머 유닛(systemd timer)”도 강력한 대안이 되고 있습니다.

2. cron 기본 개념 정리

2.1 cron이란?

cron은 오래된 유닉스/리눅스 스케줄러입니다. 정해진 시간/주기에 따라 명령을 실행하며, 설정은 주로 crontab 파일로 관리합니다.

2.2 cron 설정 위치

  • 시스템 전체: /etc/crontab, /etc/cron.d/
  • 사용자별: crontab -e로 편집되는 per-user crontab

예를 들어, 매일 새벽 3시에 백업 스크립트 실행:

0 3 * * * /usr/local/bin/backup.sh

필드 의미는 다음과 같습니다.

분  시  일  월  요일  명령
0   3   *   *   *    /usr/local/bin/backup.sh

2.3 cron의 장점

  • 오래되고 검증된 도구
  • 대부분의 리눅스/유닉스 시스템에서 동일한 개념
  • 설정 문법이 간단하며, 예제가 많음
  • systemd 이전 시스템에서도 사용 가능

2.4 cron의 한계

  • 서비스와 분리되어 있어, “어떤 서비스와 연관된 작업인지” 추적이 어려움
  • 상태/로그 확인이 불편 (syslog, 메일 등으로 흩어짐)
  • 의존성 관리(다른 서비스가 먼저 떠 있어야 한다 등)가 약함
  • “부팅 후 5분 뒤에 한 번만 실행” 같은 상대 시간 기반 스케줄링이 애매함

3. systemd timer 기본 개념

Commandbox 광고

3.1 systemd timer란?

systemd timer는 systemd의 “타이머 유닛”입니다. 특정 조건(시간, 부팅 후 경과 시간 등)에 따라 다른 systemd service를 실행하는 역할을 합니다.

즉, 구조는 항상 쌍으로 갑니다.

  • myjob.service → 실제로 실행할 작업 정의
  • myjob.timer → 언제 실행할지 정의

3.2 service + timer 기본 예제

매일 새벽 3시에 백업 실행 예제를 systemd timer로 쓰면 다음과 같습니다.

(1) 서비스 유닛: /etc/systemd/system/backup.service

[Unit]
Description=Daily backup job

[Service]
Type=oneshot
ExecStart=/usr/local/bin/backup.sh

(2) 타이머 유닛: /etc/systemd/system/backup.timer

[Unit]
Description=Run daily backup at 3:00

[Timer]
OnCalendar=*-*-* 03:00:00
Persistent=true

[Install]
WantedBy=timers.target

활성화:

sudo systemctl daemon-reload
sudo systemctl enable --now backup.timer

3.3 systemd timer의 장점

  • 서비스와 명확히 연관됨: 어떤 서비스가 어떤 타이머에 의해 실행되는지 구조가 선명함
  • 로그 관리가 쉬움: journalctl -u backup.service 등으로 로그 조회

  • 유연한 트리거 조건:

  • OnCalendar=: cron 비슷한 시간 기반 표현

  • OnBootSec=: 부팅 후 X초 후
  • OnUnitActiveSec=, OnUnitInactiveSec= 등: 마지막 실행 후 일정 시간 등
  • 의존성 처리: “네트워크가 올라온 다음에만 실행” 같은 조건을 service의 After=network-online.target 등으로 표현 가능
  • systemd eco 시스템과 통합: systemctl list-timers, systemctl status 등으로 상태 확인

3.4 systemd timer의 단점

  • cron에 비해 학습 곡선이 있음 (service + timer 두 파일 필요)
  • systemd 환경에 종속적 (아주 옛날 시스템이나 non-systemd 환경에서는 사용 불가)
  • 간단한 한 줄짜리 작업에는 다소 “과한” 느낌일 수 있음

4. cron vs systemd timer: 기능 비교

4.1 큰 그림 비교표

항목 cron systemd timer
설정 위치 /etc/crontab, crontab -e /etc/systemd/system/*.service/*.timer
실행 대상 임의의 명령/스크립트 systemd service
시간 표현 방식 cron 표현식(5 필드) OnCalendar, OnBootSec 등 다양한 옵션
부팅 후 X초/분/시간 제한적, 별도 스크립트 트릭 필요 OnBootSec, OnStartupSec로 직접 지원
실패/재시도 관리 별도 구현 필요 service unit의 설정으로 일부 가능
로그 확인 syslog, 메일 등 journalctl -u <service>
의존성(네트워크/파일시스템) 기본 지원 없음 Unit 옵션(After=, Requires= 등)으로 표현
시스템과의 통합 낮음 매우 높음 (systemd 전체와 연계)
이식성(다른 OS로 이동) 비교적 높음 systemd에 의존

5. 예제로 보는 차이점

5.1 매일 새벽 3시 백업: cron vs timer

cron 버전

0 3 * * * /usr/local/bin/backup.sh

systemd timer 버전

# backup.service
[Unit]
Description=Daily backup job

[Service]
Type=oneshot
ExecStart=/usr/local/bin/backup.sh

# backup.timer
[Unit]
Description=Run daily backup at 3:00

[Timer]
OnCalendar=*-*-* 03:00:00
Persistent=true

[Install]
WantedBy=timers.target

5.2 부팅 후 5분 뒤에 한 번만 실행

이건 cron에서는 약간 꼼수(부팅 시 @reboot + sleep, rc.local 등)를 써야 하는 경우가 많습니다.

systemd timer로 구현

# init-job.service
[Unit]
Description=Run custom init job after boot

[Service]
Type=oneshot
ExecStart=/usr/local/bin/init-job.sh

# init-job.timer
[Unit]
Description=Run init job 5 minutes after boot

[Timer]
OnBootSec=5min
AccuracySec=1min

[Install]
WantedBy=timers.target

이렇게 하면, 부팅 이후 5분이 지나면 init-job.service가 한 번 실행됩니다.

6. 어떤 것을 선택해야 할까?

6.1 cron을 계속 써도 좋은 경우

  • 이미 잘 돌아가는 cron 작업이 많고, systemd 통합이 굳이 필요 없을 때
  • 아주 간단한 정기 작업 몇 개만 있는 소규모 서버
  • systemd가 아닌 환경(일부 컨테이너, BSD, 매우 오래된 OS 등)도 함께 고려해야 할 때

6.2 systemd timer를 쓰는 것이 좋은 경우

  • 이미 서비스들이 대부분 systemd로 관리되고 있을 때
  • 작업 실패 시 로그/상태를 한 군데서 관리하고 싶을 때
  • “부팅 후 X시간 뒤”, “마지막 실행 후 Y시간 뒤” 같은 상대 시간 기반 스케줄링이 필요할 때
  • 특정 서비스(예: DB, 네트워크)가 올라온 뒤에만 실행해야 하는 작업이 있을 때
  • CI/CD 파이프라인, 프로덕션 환경 등에서 일관된 관리/관찰성(observability)이 필요할 때

7. 기존 cron 작업을 systemd timer로 옮길 때 팁

실제 마이그레이션은 다음 흐름으로 생각하면 편합니다.

  1. 현재 cron 작업 목록 정리
  • crontab -l
  • /etc/crontab, /etc/cron.d/* 확인
  1. 각 작업을 “서비스 + 타이머”로 분해
  • “무엇을 실행할 것인가?” → .service
  • “언제 실행할 것인가?” → .timer
  1. 시간 표현 변환
  • 0 3 * * * → OnCalendar=*-*-* 03:00:00
  • */5 * * * * → OnCalendar=*:0/5 (5분마다 등, 여러 표현 방식 가능)
  1. 테스트
  • systemctl start myjob.service 로 수동 실행 먼저 확인
  • systemctl start myjob.timer → systemctl list-timers로 스케줄 확인
  1. 기존 cron 비활성화
  • 새 타이머가 안정되면, 해당 cron 항목은 주석 처리하거나 삭제

8. 마무리: 공존도 가능하다

정리하자면:

  • cron은 여전히 단순하고 이식성이 높은 스케줄러
  • systemd timer는 현대 리눅스 환경에서 서비스 중심 관리, 관찰성, 유연한 트리거를 제공하는 강력한 도구

둘 중 하나만 “정답”은 아닙니다. 이미 돌아가는 cron 작업을 굳이 다 옮길 필요는 없지만, 새로 작성하는 스케줄 작업이나 서비스와 강하게 결합된 작업이라면 systemd timer를 우선 고려해 보는 것이 좋습니다.

image