cron과 systemd timer는 무엇이 다를까? 리눅스 작업 스케줄링 선택 기준 정리
리눅스에서 반복 작업을 예약할 때 여전히 cron을 먼저 떠올리는 경우가 많지만, systemd를 쓰는 배포판에서는 systemd timer도 공식 기능으로 널리 사용된다. 2026년 5월 9일 기준 Ubuntu manpage와 systemd 문서를 보면 두 방식은 단순히 문법만 다른 것이 아니라, 시간 표현 방식, 누락 실행 처리, 로그 확인 방식, 서비스 의존성 관리에서 차이가 있다.
이 글은 Ubuntu manpage와 systemd 문서를 기준으로 cron과 systemd timer의 차이를 객관적인 사실만 정리한 글이다. 어떤 상황에서 무엇을 선택하는 편이 맞는지 빠르게 판단할 수 있도록 핵심 비교와 예시를 함께 묶었다.
cron은 무엇이고 systemd timer는 무엇인가?
crontab(5) 문서는 cron을 특정 시각과 날짜에 명령을 실행하는 방식으로 설명한다. 각 줄은 기본적으로 다섯 개의 시간 필드와 명령으로 구성되며, cron 데몬은 이를 기준으로 주기 작업을 실행한다.
반면 systemd.timer(5)는 timer unit이 다른 unit, 보통 같은 이름의 .service를 시간 조건에 따라 활성화하는 구조라고 설명한다. 즉 systemd timer는 단순 문자열 스케줄러라기보다, systemd의 unit 관리 체계 안에서 동작하는 예약 실행 기능에 가깝다.
가장 큰 차이는 무엇인가?
실무에서 체감이 큰 차이는 네 가지다.
- cron은 다섯 필드 기반의 crontab 문법을 중심으로 작업을 정의한다.
- systemd timer는
OnCalendar=,OnBootSec=,OnUnitActiveSec=같은 unit 옵션으로 스케줄을 정의한다. - systemd timer는
Persistent=로 타이머가 비활성 상태였던 동안 놓친 실행을 다시 처리할 수 있다. - systemd timer는 실행 결과를 journal과 service 단위 상태로 함께 추적할 수 있다.
스케줄 문법은 어떻게 다른가?
Ubuntu의 crontab(5)는 cron 항목이 분, 시, 일, 월, 요일 필드와 명령으로 구성된다고 설명한다. 예를 들어 0 2 * * *는 매일 2시에 실행하는 식이다. 또 월의 일(day of month)과 요일(day of week)을 모두 제한하면 둘 중 하나만 일치해도 실행된다고 문서가 밝힌다.
systemd timer는 같은 주기 작업을 OnCalendar=로 표현할 수 있다. Ubuntu의 systemd.timer(5)는 calendar event 표현식과 monotonic timer를 함께 지원한다고 설명하며, systemd.time(7)는 시간 간격 문법 예시로 2h 30min 같은 형식을 제시한다. 즉 systemd timer는 "매일 02:00" 같은 달력 기반 표현과 "부팅 5분 뒤", "마지막 실행 1시간 뒤" 같은 상대 시간 표현을 한 체계 안에서 다룰 수 있다.
놓친 실행을 복구해야 하면 무엇이 더 유리할까?
이 질문에서는 systemd timer 쪽이 분명한 장점이 있다. Ubuntu의 systemd.timer(5)는 Persistent=가 참이면 마지막 트리거 시점을 디스크에 저장하고, 타이머가 비활성 상태였던 동안 한 번이라도 실행됐어야 했다면 타이머가 다시 활성화될 때 즉시 서비스를 실행한다고 설명한다.
또 같은 문서는 OnCalendar= 기반 calendar timer가 시스템이 suspend 상태일 때 시점을 놓치더라도 재개 후 catch up 처리한다고 설명한다. 다만 연속해서 여러 번 놓쳤더라도 서비스 활성화는 한 번으로 합쳐질 수 있다고 명시한다.
반대로 cron 문서는 기본적으로 현재 시각과 필드 일치 여부에 따라 실행되는 구조를 설명한다. 그래서 "부팅 중이거나 서비스가 멈춘 사이에 놓친 작업을 자동 복구해야 하는가"가 중요하면, cron 단독보다 Persistent=가 있는 systemd timer가 더 직접적인 선택지가 된다.
로그와 실패 확인은 어떻게 다른가?
cron 계열은 전통적으로 작업 출력 메일 전송과 셸 리다이렉션을 많이 사용한다. Ubuntu의 crontab(5)는 MAILTO를 통해 작업 출력을 메일로 보낼 수 있다고 설명한다.
systemd 쪽은 실행 단위가 service이기 때문에 상태 확인과 로그 조회가 더 일관적이다. Ubuntu의 systemd.cron(7)와 systemd-crontab-generator(8) 문서는 관련 로그가 journal에 남고, systemctl list-timers로 타이머 현황을 볼 수 있다고 설명한다. systemd timer를 직접 작성하면 같은 흐름으로 systemctl status와 journalctl -u ...를 사용할 수 있다.
정확한 시각 실행이 중요하면 무엇을 확인해야 할까?
systemd timer는 설정한 시각에 무조건 초 단위로 딱 맞춰 실행된다고 보면 안 된다. Ubuntu의 systemd.timer(5)는 타이머가 AccuracySec=의 영향을 받으며, 기본값은 1분이라고 설명한다. 즉 별도 조정이 없으면 설정 시각 주변 윈도 안에서 동작할 수 있다.
같은 문서는 RandomizedDelaySec=를 함께 써서 부하 분산을 할 수 있다고 설명한다. 따라서 "정확히 매일 00:00:00에 실행"이 정말 중요하면 systemd timer에서도 AccuracySec과 지연 옵션을 의식해서 설정해야 한다.
서비스 의존성과 실행 환경을 같이 관리하려면?
cron은 기본적으로 명령 실행 중심이다. 환경 변수, 셸, 경로를 crontab 안에서 따로 챙겨야 하고, 복잡한 의존성은 스크립트 내부에서 처리하는 경우가 많다.
systemd timer는 timer가 service를 활성화하는 구조라서, 실제 작업 정의를 .service에 분리할 수 있다. 이 방식이면 작업 계정, 작업 디렉터리, 재시작 정책, 선행 조건, 리소스 제한 같은 systemd 속성을 같이 관리하기 쉽다. 배포 자동화나 서버 운영 작업에서 timer가 자주 선택되는 이유가 여기에 있다.
FAQ
Q. 간단한 개인 작업도 systemd timer로 바꿔야 할까?
반드시 그렇지는 않다. 이미 cron 문법에 익숙하고 단순 반복 실행만 필요하다면 cron도 충분히 실용적이다. 다만 로그 추적, service 단위 관리, 놓친 실행 복구가 필요하면 systemd timer 쪽 이점이 커진다.
Q. systemd timer는 달력 기반 예약만 가능한가?
아니다. systemd.timer(5)는 OnCalendar= 외에도 OnBootSec=, OnStartupSec=, OnUnitActiveSec=, OnUnitInactiveSec= 같은 monotonic timer 옵션을 설명한다.
Q. systemd timer를 쓰면 놓친 실행이 모두 개별적으로 재실행되나?
항상 그렇지는 않다. Ubuntu의 systemd.timer(5)는 suspend 중 여러 번 시점을 놓친 calendar timer라도 재개 후 서비스 활성화는 한 번만 일어날 수 있다고 설명한다.
언제 cron을 쓰고 언제 systemd timer를 쓰면 좋을까?
다음 기준으로 나누면 실무 판단이 단순해진다.
- cron: 짧은 명령 하나를 익숙한 다섯 필드 문법으로 돌리면 충분한 경우
- systemd timer: 서비스 단위 관리, journal 로그, 누락 실행 복구, 부팅 기준 상대 시간 실행이 필요한 경우
특히 서버 운영 작업이나 배포 후 정기 점검 작업처럼 "실패 원인 추적"과 "실행 보장"이 중요한 경우에는 systemd timer가 더 설명력이 높다. 반대로 개인 환경에서 간단한 명령을 빠르게 예약하려면 cron이 더 짧고 익숙할 수 있다.
정리
cron과 systemd timer는 둘 다 반복 작업을 예약하지만, 동작 모델은 다르다. cron은 시각 필드와 명령 중심이고, systemd timer는 timer와 service를 분리해 더 넓은 운영 제어를 제공한다.
2026년 5월 9일 기준 Ubuntu와 systemd 문서를 기준으로 보면, 놓친 실행 복구가 중요하거나 journal과 unit 상태까지 함께 관리해야 하는 작업은 systemd timer가 유리하다. 반대로 단순한 예약 명령이라면 cron이 여전히 충분히 실용적이다.
참고 자료
'프로그래밍 > 리눅스 커널' 카테고리의 다른 글
| I2S의 bclk, lrclk 출력 시점 (0) | 2024.12.22 |
|---|---|
| pinctrl-names과 pinctrl (0) | 2024.10.22 |
| s906b sound card probe 살펴보기 (1) | 2022.05.26 |
| s906b alsa sound card 코드 따라가기 (0) | 2022.05.19 |
| 삼성 S906B (S22+) 리눅스 커널 다운 및 vim, cscope, ctags 준비 (0) | 2022.05.19 |