cron 대신 systemd 타이머를 볼 만한 이유

cron 대신 systemd 타이머를 볼 만한 이유

IT & AI 뉴스 썸네일

서버에서 정해진 시간에 작업을 돌릴 때 가장 먼저 떠오르는 도구는 여전히 `cron`이에요. 그런데 리눅스 서버가 systemd를 쓰고 있다면, 같은 일을 `.timer`와 `.service` 조합으로 더 추적하기 쉽게 만들 수 있어요.

핵심 요약

구분	핵심	왜 볼 만한가요
서버 운영	systemd 타이머는 일정에 맞춰 서비스 유닛을 실행해요	실행 이력과 출력이 journal에 남아 장애 추적이 쉬워져요
스케줄 표현	`OnCalendar`, `OnBootSec`, `OnUnitActiveSec`로 시간을 표현해요	“매일 0시”뿐 아니라 “부팅 1시간 뒤부터 매시간” 같은 흐름을 쓰기 좋아요
운영 안정성	`Persistent`, `WakeSystem`, 랜덤 지연 옵션을 제공해요	놓친 실행을 보완하거나 동시에 몰리는 실행을 줄일 수 있어요

1. cron 대신 systemd 타이머를 볼 만한 이유

`cron`은 단순하고 오래 검증된 도구예요. 문제는 작업이 실패했을 때부터 시작돼요. `$PATH`가 예상과 다르게 잡히고, 출력이 메일이나 사라진 로그로 흘러가고, 마지막 실행 결과를 찾기 어려운 경우가 많아요. 원문 글은 이 지점을 systemd 타이머가 줄여줄 수 있다고 설명해요. 1

systemd 타이머는 실행할 작업을 `.service` 유닛으로 두고, 언제 실행할지를 `.timer` 유닛에 적어요. 예를 들어 `backup.service`가 실제 백업 명령을 담고, `backup.timer`가 그 서비스를 언제 깨울지 정하는 식이에요. 이렇게 나누면 “무엇을 실행하나요”와 “언제 실행하나요”가 분리돼요. 2

systemd 타이머도 `daily`나 특정 시각 같은 벽시계 기준 일정을 쓸 수 있어요. `systemd-analyze calendar`로 시간 표현이 실제로 언제 실행되는지 확인할 수도 있어요. `cron` 표현식을 외워서 읽는 대신, 명령어로 다음 실행 시각을 확인하는 쪽에 가까워요. 2

더 흥미로운 부분은 이벤트 기준 실행이에요. `OnBootSec=1h`는 부팅 뒤 1시간 후 실행을 뜻하고, `OnUnitActiveSec=1h`는 서비스가 마지막으로 실행된 뒤 1시간 후 다시 실행을 뜻해요. 임시 파일 정리처럼 “매일 같은 시각”보다 “시스템이 켜진 뒤 일정 시간이 지나면”이 더 자연스러운 작업에 잘 맞아요.

운영자가 체감하는 차이는 로그예요. systemd 서비스로 실행하면 표준 출력과 오류가 journal에 남아요. `systemctl status`로 최근 상태를 보고, `systemctl list-timers`로 다음 실행 시각과 마지막 실행 시각을 한 번에 볼 수 있어요. 작업이 돌았는지, 실패했는지, 다음 일정이 언제인지 확인하는 과정이 짧아져요.

물론 모든 상황에서 systemd 타이머가 `cron`보다 낫다는 뜻은 아니에요. `crontab -e` 한 줄로 끝나는 단순 작업도 많아요. 사용자 단위 타이머는 설정 파일이 늘어나는 부담도 있어요. 그래도 이미 systemd 위에서 서버를 운영하고 있다면, 주기 작업을 서비스 유닛으로 다루는 방식은 충분히 검토할 만해요.

왜 중요한가요

정기 작업은 작을 때는 별문제가 없어 보여요. 하지만 배포, 백업, 정리 작업, 상태 체크처럼 반복되는 일이 늘면 “실패했을 때 어디서 보나요”가 중요해져요. systemd 타이머는 스케줄러를 따로 쓰는 대신, 이미 운영 중인 서비스 관리 체계 안에서 정기 작업을 다룰 수 있게 해요.

노트북이나 개발 서버처럼 항상 켜져 있지 않은 장비에서는 정해진 시각을 놓치는 일이 생겨요. `Persistent=true`를 쓰면 타이머가 비활성 상태였던 동안 놓친 실행을 다시 온라인이 된 뒤 보완할 수 있어요. 꼭 절전 상태에서 깨워야 하는 작업이라면 `WakeSystem`도 선택지가 돼요. 1

여러 서버가 같은 시각에 업데이트 확인을 시작하는 문제도 있어요. 원문은 `RandomizedOffsetSec`와 `FixedRandomDelay` 같은 옵션을 소개해요. 모든 장비가 자정 정각에 같은 API를 치지 않도록 실행 시각을 안정적으로 흩뿌리는 방식이에요. 작은 옵션처럼 보여도, 운영 규모가 커지면 꽤 실용적인 차이가 나요.

개발자가 바로 가져갈 만한 포인트도 분명해요. 첫째, “정기 실행”을 단순한 명령 한 줄이 아니라 서비스로 다룰 수 있어요. 실패 처리, 재시작, 조건부 실행, 로그 확인을 systemd 안에서 이어 붙일 수 있어요. 둘째, `systemd-analyze calendar`로 시간 표현을 실행 전에 확인할 수 있어요. 셋째, `systemctl list-timers`로 지금 머신에서 어떤 예약 작업이 살아 있는지 한눈에 볼 수 있어요.

참고 자료

1. 당신은 systemd 타이머를 충분히 좋아하지 않는군요 — GeekNews
2. You Don't Love systemd Timers Enough — Tyblog