Systemd 타이머 가이드: 안정적인 스케줄링을 위한 Cron 작업 대체

수십 년 동안 cron은 Linux 및 Unix 계열 시스템에서 작업을 스케줄링하는 사실상의 표준이었습니다. 그 단순성과 보편성 덕분에 관리자와 개발자 모두에게 필수적인 도구가 되었습니다. 그러나 Linux 시스템이 발전하고 특히 systemd가 시스템 및 서비스 관리자로 등장하면서 더욱 강력하고 통합된 스케줄링 메커니즘이 등장했습니다. systemd 타이머 유닛(.timer 파일)은 전통적인 cron 작업에 비해 현대적이고 강력하며 종종 더 우수한 대안을 제공합니다.

이 가이드에서는 systemd 타이머의 장점을 살펴보고, systemd 생태계의 나머지 부분과 어떻게 원활하게 통합되는지 자세히 설명합니다. 타이머(.timer) 및 서비스(.service) 파일을 모두 구성하는 방법에 대한 포괄적인 설명을 제공하여 견고하고 재현 가능하며 쉽게 관리할 수 있는 예약 작업을 생성할 수 있도록 지원합니다. 이 글을 마치면 현대 Linux 환경에서 systemd 타이머가 안정적인 작업 스케줄링을 위해 선호되는 이유를 이해하게 될 것입니다.

Systemd 타이머 이해하기

systemd 타이머는 다른 systemd 유닛, 일반적으로 service 유닛이 언제 활성화될지 제어하는 systemd 유닛 파일입니다. 독립형 데몬인 cron과 달리, systemd 타이머는 systemd 초기화 시스템의 필수적인 부분입니다. 이러한 깊은 통합은 특히 안정성, 로깅 및 리소스 관리 측면에서 여러 가지 중요한 이점을 제공합니다.

systemd 타이머는 항상 다른 유닛, 가장 일반적으로 service 유닛과 함께 작동합니다. .timer 파일은 이벤트가 언제 발생해야 하는지 정의하고, 해당 .service 파일은 이벤트가 트리거될 때 어떤 작업이 수행되어야 하는지 정의합니다. 이러한 명확한 책임 분리는 systemd 타이머를 매우 모듈화되고 유연하게 만듭니다.

Cron에 비해 Systemd 타이머의 주요 장점

cron은 기능적이지만, systemd 타이머는 cron의 많은 한계를 해결하며, 더 견고하고 기능이 풍부한 스케줄링 솔루션을 제공합니다.

신뢰성 및 영구성: systemd 타이머가 Persistent=true로 구성되어 있고 예약된 실행 중에 시스템 전원이 꺼지면, 시스템이 다시 부팅된 직후 관련 서비스가 실행됩니다. 반면 cron 작업은 시스템이 다운되면 예약된 실행을 놓치게 됩니다.
systemd와의 통합: 타이머는 systemd의 강력한 로깅(journalctl을 통해), 의존성 관리 및 리소스 제어(cgroups)의 이점을 얻습니다. 이는 더 나은 모니터링, 더 명확한 오류 보고, 그리고 예약 작업에 대한 복잡한 시작 순서나 리소스 제한을 정의할 수 있는 기능을 의미합니다.
재현성 및 버전 제어: systemd 유닛 파일은 버전 제어 시스템에 쉽게 저장할 수 있는 일반 텍스트 파일입니다. 이를 통해 재현 가능한 배포와 여러 시스템에 걸쳐 예약 작업 변경 사항을 더 쉽게 추적할 수 있습니다.
이벤트 기반 스케줄링: 단순한 시간 기반 스케줄링 외에도 systemd 타이머는 시스템 부팅(OnBootSec)을 기준으로 또는 유닛의 마지막 활성화(OnUnitActiveSec) 이후에 트리거될 수 있어 더 동적인 스케줄링 옵션을 제공합니다.
유연한 시간 표현: systemd는 cron의 구문보다 더 읽기 쉽고 다재다능한 풍부한 캘린더 이벤트 표현식을 제공하며, 여기에는 시간별, 일별, 주별 및 특정 날짜/시간이 포함됩니다.
리소스 관리 및 의존성: 타이머에 의해 시작된 systemd 서비스는 cgroup 설정을 포함한 systemd 환경을 상속하며, 다른 systemd 유닛에 대한 의존성을 선언할 수 있습니다(예: 네트워크 또는 데이터베이스가 사용 가능해질 때까지 기다린 후 실행).
표준 출력/오류 처리: systemd는 타이머에 의해 시작된 서비스의 stdout 및 stderr를 자동으로 캡처하여 시스템 저널로 전달하므로, cron의 이메일 기반 출력이나 수동 리디렉션보다 디버깅 및 감사 작업이 훨씬 간단해집니다.

Systemd 타이머 구성하기

systemd 타이머를 구성하려면 두 개의 유닛 파일(서비스 유닛(.service)과 타이머 유닛(.timer))을 생성해야 합니다. 이 파일들은 일반적으로 시스템 전체 타이머의 경우 /etc/systemd/system/에, 사용자별 타이머의 경우 ~/.config/systemd/user/에 배치됩니다.

1. 서비스 유닛 (`.service` 파일)

서비스 유닛은 실제로 실행될 명령 또는 스크립트를 정의합니다. 이는 표준 systemd 서비스 파일이지만, 종종 비대화식으로 실행되고 특정 작업을 수행하도록 설계됩니다.

예시: /etc/systemd/system/mytask.service

[Unit]
Description=My Scheduled Task Service

[Service]
Type=oneshot
ExecStart=/usr/local/bin/mytask.sh
User=myuser
Group=mygroup
# Optional: Limit resources
# CPUShares=512
# MemoryLimit=1G

[Install]
WantedBy=multi-user.target

설명:

[Unit]: 유닛에 대한 일반적인 정보를 포함합니다.
- Description: 사람이 읽을 수 있는 설명입니다.
[Service]: 서비스별 구성을 정의합니다.
- Type=oneshot: 서비스가 단일 명령을 실행한 다음 종료됨을 나타냅니다. 이는 예약 작업에 일반적으로 사용됩니다.
- ExecStart: 실행할 명령 또는 스크립트입니다. 전체 경로를 제공해야 합니다.
- User, Group: 명령이 실행될 사용자 및 그룹을 정의합니다. 항상 최소한의 권한으로 작업을 실행해야 합니다.
- CPUShares, MemoryLimit: (선택 사항) systemd는 cgroup을 활용하여 서비스에 대한 리소스 제한을 설정할 수 있도록 합니다.
[Install]: 유닛이 어떻게 활성화되어야 하는지 정의합니다.
- WantedBy=multi-user.target: 이 섹션이 존재하더라도, 타이머 유닛 자체가 활성화를 결정하는 타이머 트리거 서비스에는 덜 중요합니다. 하지만 서비스를 수동으로 활성화하거나 다른 systemd 타겟에 통합하려는 경우 유용할 수 있습니다.

2. 타이머 유닛 (`.timer` 파일)

타이머 유닛은 해당 서비스 유닛이 언제 활성화되어야 하는지 정의합니다. 서비스 유닛과 동일한 이름(mytask.service에 대한 mytask.timer와 같이)을 가져야 합니다.

예시: /etc/systemd/system/mytask.timer

[Unit]
Description=Runs mytask.service daily

[Timer]
OnCalendar=daily
Persistent=true
RandomizedDelaySec=600
AccuracySec=1min

[Install]
WantedBy=timers.target