Cron vs systemd 타이머: 무엇을 써야 할까?

현대 배포판이라면, 내가 소유한 작업은 systemd 타이머로 처리하고 cron은 한 줄짜리 사용자 작업과 내가 세팅하지 않은 서버용으로 남겨두세요. 타이머는 모든 실행을 저널에 기록하고, 머신이 꺼져 있던 동안 놓친 스케줄을 보정 실행할 수 있으며, 시스템의 나머지와 같은 유닛 파일 체계에 묶입니다. Cron의 무기는 간결함 — crontab -e 한 줄이 유닛 파일 두 개를 이깁니다 — 이고, 미니멀 컨테이너와 기이한 Unix 박스에서 존재가 보장된 유일한 스케줄러이기도 합니다. 함정은 이겁니다: cron은 조용히 실패합니다. 작업이 새벽 3시에 에러를 내면 cron은 아무도 안 읽는 로컬 메일함에 편지를 넣지만, 타이머는 전체 출력과 함께 journalctl -u mytimer.service를 줍니다. 아래에서: 실제 차이, 각각의 테스트 법, 타이머가 발화하지 않는 이유, 결정 표를 다룹니다.

cron과 systemd 타이머의 차이는 무엇일까?

Cron은 줄 표를 읽는 데몬입니다 — 시간 필드 다섯 개와 명령 하나 — 그리고 벽시계가 일치할 때 각 명령을 실행합니다. 모델은 그게 전부입니다. 작업을 객체로 다루는 개념이 없습니다: 유닛도, 상태도, 의존성도, 자체 로그 항목도 없습니다.

systemd 타이머는 스케줄이 일치할 때 다른 유닛 파일(foo.service)을 발화하는 유닛 파일(foo.timer)입니다. 작업이 일급 객체라서 다른 서비스처럼 start, status, logs, 실패 추적을 갖춥니다. 스케줄링은 캘린더 기반(cron 같은)이거나 모노토닉(OnBootSec=15min — 벽시계 변화가 혼동시킬 수 없는 방식)입니다.

실용적 귀결:

• 로깅: 타이머는 유닛별로 stdout/stderr를 저널에 기록; cron은 최선의 경우 로컬 사용자에게 메일.
• 놓친 실행: Persistent=true 타이머는 스케줄을 놓쳤다면 부팅 때 한 번 실행; cron은 그냥 건너뜀.
• 의존성: 타이머는 network-online.target이나 마운트 지점을 기다릴 수 있음; cron은 스크립트 안에서 재시도 로직을 손수 굴려야 함.
• 문법: cron은 한 줄; 타이머는 파일 두 개. 전환 비용은 그게 전부입니다.

스케줄 문법은 어느 쪽이 쉬울까 — crontab vs OnCalendar?

Cron의 다섯 필드는 컴팩트한 현직자입니다: */15 * * * *은 15분마다이고, 대부분의 관리자는 잠결에도 읽습니다. systemd의 OnCalendar=는 더 장황하지만 엄격히 더 표현력이 좋고, systemd-analyze calendar는 저장하기 전에 다음 실행을 알려줍니다 — cron에는 이런 dry-run이 없습니다.

# Cron: 매일 03:30
30 3 * * * /usr/local/bin/backup.sh

# systemd: 같은 스케줄, 저장 전에 검증 가능
systemd-analyze calendar "*-*-* 03:30:00"
# -> 다음 실행: Fri 2026-09-11 03:30:00 ...

OnCalendar는 cron이 진짜로 깔끔하게 표현하지 못하는 것을 처리합니다: Mon..Fri *-*-* 09..17:00:00 (평일, 업무 시간), 또는 천 대의 머신이 같은 순간에 서버를 두드리지 않게 하는 *:0/15에 RandomizedDelaySec=10m.

기다리지 않고 systemd 타이머를 테스트하는 방법은?

명령 세 개가 전부를 답합니다. 무엇이 예약됐고 언제 발화하는지 나열하고, 타이머와 정확히 같은 방식으로 작업을 손으로 돌리고, 로그를 읽습니다:

systemctl list-timers --all                 # 모든 타이머, 다음 + 마지막 실행
sudo systemctl start backup.service         # 지금 작업 발화 — 타이머가 쏘는 것과 같은 유닛
journalctl -u backup.service -f             # 출력 실시간 관찰

분리에 주목: systemctl start backup.timer는 스케줄을 활성화하고, 서비스가 작업입니다. list-timers에 타이머가 보이고, systemctl status backup.service가 초록이고, 저널에 출력이 보이면 체인 전체가 동작하는 겁니다.

cron 작업을 수동으로 실행하는 방법은?

Cron 작업은 벗겨낸 환경으로 실행됩니다 — 그래서 “내 셸에선 되는데 cron에선 안 된다”는 버그의 한 장르가 생긴 겁니다. cron을 충실히 재현하려면 cron이 쓸 것과 같은 환경으로 sh를 통해 명령을 돌립니다:

crontab -l                                  # 정확한 라인 확인
env -i SHELL=/bin/sh PATH=/usr/bin:/bin sh -c '/usr/local/bin/backup.sh'
grep CRON /var/log/syslog | tail            # cron이 발화는 했나? (Debian/Ubuntu)
journalctl -u cron -n 20                    # systemd 배포판에서는 동일한 요령으로

그 env -i 줄이 정직한 수동 테스트입니다: cron 기본 PATH를 얹은 벌거벗은 환경. 대부분의 조용한 cron 실패는 텅 빈 PATH나 명령 안의 따옴표 없는 %(cron은 %를 줄바꿈으로 취급)이고, 둘 다 이 방식으로 즉시 드러납니다.

systemd 타이머가 발화하지 않는 이유는?

원인 넷이 거의 모든 경우를 덮습니다, 확인 순서대로:

1. 서비스와 타이머 이름이 안 맞는다. foo.timer는 foo.service를 발화합니다 — 오타난 OnFailure나 이름이 바뀐 유닛은 타이머가 “실행”되지만 아무것도 향하지 않게 만듭니다. systemctl cat foo.timer가 정확히 무엇을 향하는지 보여줍니다.
2. 타이머를 고쳤지만 리로드하지 않았다. 유닛 파일을 바꾼 뒤에는: sudo systemctl daemon-reload && sudo systemctl restart foo.timer. 이게 없으면 새 스케줄은 살아있지 않습니다.
3. 기대한 OnCalendar 의미 없이 Persistent=true만 — 아니면 systemctl status foo.timer(유휴여도 항상 active로 보임) 대신 list-timers를 봐야 하는 경우.
4. 발화하는 서비스가 즉시 죽고 있다. 그래서 타이머가 죽어 보입니다. journalctl -u foo.service --since -1h가 list-timers가 숨기는 크래시를 보여줍니다.

로그를 봤다면, journalctl cheat sheet가 이걸 빠르게 만들어주는 필터(-u, --since, -f)를 다룹니다.

cron vs systemd 타이머: 결정 표

	cron	systemd 타이머
세팅	crontab 한 줄	유닛 파일 두 개
로깅	로컬 메일, 보통 안 읽힘	저널, 유닛별
놓친 실행 (머신 꺼짐)	건너뜀	Persistent=true로 한 번 실행
의존성 / 순서	없음 — 스크립트에서 DIY	완전한 유닛 의존성
무작위 지연	$RANDOM으로 DIY	RandomizedDelaySec=
스케줄 테스트/dry-run	없음	systemd-analyze calendar
어디에나 존재	예 — 컨테이너, BSD, 임베디드	systemd 필요 (PID 1)
루트 없는 사용자 작업	crontab -e	systemd --user 유닛

경험 법칙: 자신의 systemd 머신에 올리는 작업 → 타이머. 빠른 개인 리마인더나 내가 만들지 않은 박스 → cron. 의존성, 재시도, 실제로 돌았는지 아는 것이 필요한 무엇이든 → 항상 타이머. 흔한 패턴은 유지보수 작업을 돌리는 타이머 — 가령 매일 밤의 rsync backup — 이고, Persistent=true는 예약된 시각에 머신이 잠들어 있었어도 백업이 일어난다고 보장합니다. cron은 그저 이걸 제공할 수 없습니다.