"주기적으로 스크립트를 돌리는 건 그냥 crontab 아닌가?"에서 출발하지만, 서버를 운영하다 보면 "어젯밤 백업이 돌긴 한 건가?"에서 막힙니다. cron과 systemd timer의 차이는 로그와 의존성을 시스템이 관리해 주느냐에서 갈립니다.
핵심 차이: 통합 관리냐 단순 실행이냐
cron은 단순합니다. "몇 시에 이 명령을 실행하라"를 한 줄로 적으면 끝입니다. 대신 실행 결과·로그·실패 추적은 직접 챙겨야 합니다. systemd timer는 작업을 .service 유닛으로 정의하고 .timer가 그걸 깨우는 구조라, 실행 기록이 journald에 남고 다른 유닛과의 의존성도 걸 수 있습니다.
| 구분 | cron | systemd timer |
|---|---|---|
| 정의 방식 | crontab 한 줄 | .timer + .service 유닛 |
| 로그 | 직접 리다이렉트 필요 | journalctl에 자동 기록 |
| 의존성 | 없음 | After=·Requires= 가능 |
| 누락 작업 | 꺼져 있으면 건너뜀 | Persistent=true로 따라잡기 |
| 정밀도·랜덤화 | 분 단위 | 초 단위·RandomizedDelaySec |
언제 무엇을 쓰나
- 간단하고 빠른 한 줄 작업 → cron: 5분마다 헬스 체크 핑, 임시 정리 스크립트처럼 가볍고 추적이 덜 중요한 경우.
- 운영 작업·추적이 중요 → systemd timer: 야간 백업, DB 덤프, 의존 서비스가 켜진 뒤 실행돼야 하는 작업. 실패를
journalctl로 바로 들여다봐야 하는 경우.
특히 노트북·VM처럼 꺼져 있던 시간이 있는 환경에서 timer의 Persistent=true는 강력합니다. 새벽 3시 백업을 놓쳤어도 부팅 직후 따라잡아 실행합니다. cron은 그 시각에 꺼져 있었으면 그냥 건너뜁니다.
직접 확인하기
지금 시스템에 등록된 타이머와 다음 실행 시각은 한 줄로 볼 수 있습니다.
서버 터미널
systemctl list-timers --all
OUTPUT
NEXT LEFT UNIT ACTIVATES
Mon 2028-09-25 03:00:00 KST 8h left backup.timer backup.service
Mon 2028-09-25 06:00:00 KST 11h left logrotate.timer logrotate.service
NEXT(다음 실행)·LEFT(남은 시간)·ACTIVATES(실행할 서비스)가 한눈에 보입니다. 특정 작업이 잘 돌았는지는 서비스 로그로 확인합니다.
서버 터미널
journalctl -u backup.service --since today
systemctl status backup.timer
cron 쪽은 등록 내용을 crontab -l로 보고, 실행 기록은 배포판에 따라 /var/log/cron이나 journalctl -u cron에서 찾습니다.
요점 정리
- 차이의 본질은 시스템 통합 관리 — 로그·의존성·누락 따라잡기가 여기서 갈립니다.
- cron = 단순·빠른 등록, 추적은 직접. systemd timer = 유닛 기반·
journalctl자동 로그·Persistent따라잡기. - 운영·재현성이 중요하면 timer, 한 줄로 끝나는 가벼운 작업이면 cron.
systemctl list-timers로 다음 실행을,journalctl -u로 실행 결과를 확인하세요.
systemd 유닛과 타이머를 직접 만들고 journalctl로 추적하는 실습은 리눅스 트랙에서 회원가입 없이 무료로 익힐 수 있습니다.