[리눅스] systemd timer vs Cron 비교: 작업 스케줄러 성능 및 자원 사용량

리눅스 서버를 오래 굴리다 보면 결국 한 번은 붙잡게 되는 주제가 있습니다. 바로 systemd timer Cron 비교입니다. 백업, 로그 정리, 캐시 삭제, 인증서 갱신 같은 작업 자동화는 작아 보여도 장애를 막는 핵심 축이거든요. 저도 처음엔 Cron(크론, 전통적인 작업 스케줄러)만 익숙해서 그냥 crontab부터 열었었는데, systemd timer(시스템디 타이머, systemd 기반 스케줄링)는 또 다른 장점이 분명하더라고요. 특히 서비스 단위 관리, 로그 추적, 의존성 처리에서 차이가 꽤 크거든요.

이번 글은 단순 기능 소개가 아니라, 리눅스 스케줄러를 실제 운영 관점에서 어떻게 비교해야 하는지, 그리고 성능 벤치마크를 할 때 무엇을 봐야 하는지에 초점을 맞췄습니다. 숫자를 억지로 꾸며 넣는 대신, 제가 홈랩에서 비교할 때 사용한 방식과 해석 포인트를 정리해보겠습니다. 혹시 스케줄러 바꿨다가 로그 찾느라 삽질해보신 적 있으신가요? 그 마음 제가 잘 압니다 ㅎㅎ

systemd timer와 Cron이 각각 어떤 흐름으로 작업을 실행하는지 보여주는 개요 이미지입니다.

1. 왜 systemd timer vs Cron 비교가 중요한가

쉽게 말해 Cron은 시간이 되면 명령어를 실행하는 데 특화되어 있고, systemd timer는 서비스 단위로 작업을 관리하는 데 강하죠. 둘 다 예약 실행은 되지만, 운영에서 중요한 건 그 다음입니다. 실패했을 때 어디서 로그를 볼지, 부팅 직후 누락된 작업을 보정할지, 프로세스 제한을 걸 수 있는지, 다른 서비스가 올라온 뒤에만 실행할지 같은 부분이요.

• Cron: 단순하고 가볍고 쓰기 편하죠.
• systemd timer: 추적성과 제어성이 좋거든요.
• 운영 포인트: 성능 차이보다 관리 편의성 차이가 더 크게 느껴지는 경우가 많습니다.

여기서 중요한 포인트! 많은 분들이 systemd가 무조건 무겁다고 생각하시는데, 실제로는 작업 자체의 비용보다 어떻게 프로세스를 감싸고 기록하느냐의 차이예요. 이 부분을 제대로 이해하면 선택이 훨씬 쉬워집니다.

2. 개념 설명: Cron과 systemd timer를 쉽게 말해보면

Cron은 오래된 표준입니다. <code>* * * * * 같은 표현으로 시간을 적고 명령을 실행하죠. 반면 systemd timer는 .service 파일과 .timer 파일을 분리해서 써요. 처음엔 이게 뭔가 싶었는데, 실제로 써보니까 역할이 나뉘어 있어서 나중에 유지보수할 때 편하더라고요.

systemd timer Cron 비교를 할 때 핵심은 “무엇이 더 빠른가” 하나만 보면 안 된다는 점입니다. 실행 지연(latency, 지연 시간), 프로세스 생성 오버헤드, 로그 추적성, 실패 복구성까지 같이 봐야 제대로 판단할 수 있거든요.

3. 벤치마크 기준: 성능 및 자원 비교는 무엇을 봐야 하나

성능 벤치마크라고 하면 보통 처리량부터 떠올리는데, 스케줄러는 조금 달라요. 작업 자동화에서는 아래 기준이 더 실무적입니다.

1. 실행 정확성: 예약한 시점에 얼마나 정확하게 시작되는가
2. 오버헤드: 짧은 작업을 실행할 때 추가 비용이 얼마나 붙는가
3. 로그 가시성: 실패 원인을 얼마나 빨리 찾을 수 있는가
4. 자원 사용량: 메모리, 프로세스 수, cgroup 제어 가능 여부
5. 운영 편의성: 배포, 수정, 재시작, 권한 관리가 쉬운가

제가 직접 체크할 때는 아주 짧은 작업 하나와, 조금 긴 백업성 작업 하나를 나눠서 봅니다. 왜냐하면 짧은 작업에서는 스케줄러 자체의 오버헤드가 더 눈에 띄고, 긴 작업에서는 스케줄러보다 실제 작업 로직이 훨씬 큰 비중을 차지하거든요.

💡 팁: 성능 벤치마크를 한다면 숫자 하나만 보지 말고 time, journalctl, systemctl status, ps, /usr/bin/time -v를 같이 보는 게 좋아요.

4. 실전 구현: Cron 방식으로 작업 자동화 구성하기

먼저 Cron 예시입니다. 가장 익숙한 방식이죠. 예제 작업은 매 5분마다 타임스탬프를 남기는 간단한 스크립트로 잡아보겠습니다.

mkdir -p ~/scheduler-test
cat > ~/scheduler-test/job.sh <<'EOF'
#!/usr/bin/env bash
set -eu
printf '%s cron job executed\n' "$(date --iso-8601=seconds)" >> /tmp/scheduler-test.log
EOF
chmod +x ~/scheduler-test/job.sh

이제 crontab에 등록합니다.

crontab -e

*/5 * * * * /home/USER/scheduler-test/job.sh

여기서 흔한 삽질이 하나 있어요. Cron은 로그인 셸(login shell)이 아니기 때문에 환경 변수(Environment Variable, 환경 변수)가 생각보다 비어 있습니다. PATH가 달라서 명령을 못 찾는 경우가 진짜 자주 나와요. 저도 처음엔 스크립트는 잘 도는데 Cron에서만 실패해서 한참 봤었네요.

• 명령어는 가능하면 절대 경로를 써요.
• 로그 파일 리다이렉션을 명시합니다.
• 실패 시 메일 설정 또는 별도 알림을 붙여야 해요.

Cron 작업 등록과 기본 실행 흐름을 이해하기 쉽게 보여주는 예시 이미지입니다.

5. 실전 구현: systemd timer 방식으로 구성하기

이번엔 같은 작업을 systemd timer로 옮겨보겠습니다. 파일이 둘로 나뉘니까 복잡해 보이지만, 한 번 패턴 잡히면 오히려 정리가 잘 되거든요.

5-1. service 파일 작성

# /etc/systemd/system/scheduler-test.service
[Unit]
Description=Scheduler test job

[Service]
Type=oneshot
ExecStart=/home/USER/scheduler-test/job.sh
User=USER
Group=USER

5-2. timer 파일 작성

# /etc/systemd/system/scheduler-test.timer
[Unit]
Description=Run scheduler test every 5 minutes

[Timer]
OnCalendar=*:0/5
Persistent=true
Unit=scheduler-test.service

[Install]
WantedBy=timers.target

5-3. 활성화 및 확인

sudo systemctl daemon-reload
sudo systemctl enable --now scheduler-test.timer
systemctl list-timers --all | grep scheduler-test
systemctl status scheduler-test.timer

실제로 써보니까 여기서 편한 건 딱 세 가지였어요. 첫째, 로그 추적이 쉽거든요. 둘째, 서비스 단위 재실행이 쉽고요. 셋째, 리소스 제한을 붙이기 좋아요. 예를 들어 아래처럼 제어할 수 있거든요.

[Service]
Type=oneshot
ExecStart=/home/USER/scheduler-test/job.sh
CPUQuota=20%
MemoryMax=128M
NoNewPrivileges=true

이 부분은 Cron보다 systemd 쪽이 확실히 운영 친화적이에요. 특히 여러 작업이 섞이는 서버에서는 누가 언제 뭘 실행했는지 보기가 훨씬 수월합니다.

6. ⚠️ 주의사항과 트러블슈팅: 제가 자주 겪었던 문제들

여기서부터가 진짜 실전입니다. 문서만 보면 쉬워 보이는데, 현장에서는 자잘한 문제들이 계속 나와요.

6-1. Cron은 환경 변수가 다릅니다

문제: 터미널에서는 되는데 Cron에서 실패합니다.

원인: PATH, HOME, locale(로케일, 지역화 설정)이 다를 수 있어요.

해결: 스크립트 상단에 필요한 환경을 명시하고, 명령어 절대 경로를 사용합니다.

#!/usr/bin/env bash
export PATH=/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin
set -eu

6-2. systemd timer는 service 파일과 짝이 맞아야 합니다

문제: 타이머는 살아 있는데 작업이 실행되지 않아요.

원인: Unit= 이름이 다르거나 ExecStart 경로가 틀린 경우가 많거든요.

해결: systemctl status와 journalctl -u scheduler-test.service를 같이 봐요.

6-3. 부팅 중 누락 작업은 해석이 다릅니다

Cron은 시스템이 꺼져 있던 동안의 스케줄을 기본적으로 보정하지 않아요. 반면 systemd timer의 Persistent=true는 누락된 실행을 어느 정도 메워줍니다. 백업이나 동기화 작업처럼 “한 번은 꼭 돌아야 하는” 작업이면 이 차이가 꽤 크거든요.

• Cron 적합: 단순 정리 작업, 개인 계정 배치
• systemd 적합: 서비스와 연동된 운영 작업, 추적이 중요한 작업

systemd timer 구성 요소와 로그 확인 포인트를 한 번에 보여주는 다이어그램입니다.

7. 검증 및 결과: 무엇을 확인하면 비교가 되는가

이제 결과를 봐야겠죠. 다만 여기서 조심할 점이 있어요. 자원 사용량과 실행 지연은 배포판, systemd 버전, 파일시스템 상태, CPU 절전 정책에 따라 달라집니다. 그래서 저는 특정 숫자를 일반화하기보다, 아래 체크리스트 기준으로 해석하는 편을 권해요.

1. 스케줄 등록 확인: crontab -l, systemctl list-timers
2. 실행 이력 확인: 로그 파일, journalctl -u 서비스명
3. 실행 시간 측정: /usr/bin/time -v로 스크립트 자체 비용 확인
4. 프로세스 추적: ps -ef, systemd-cgls로 실행 구조 확인

journalctl -u scheduler-test.service --since today
systemctl status scheduler-test.service
/usr/bin/time -v /home/USER/scheduler-test/job.sh

제가 실무에서 해석하는 기준은 이렇습니다.

🎉 정리하면, systemd timer Cron 비교에서 절대적인 승자는 없습니다. 대신 운영 규모가 커질수록 systemd timer 쪽의 장점이 더 또렷하게 보여요. 반대로 가벼운 서버나 개인 계정 자동화라면 Cron이 아직도 충분히 실용적입니다.

실행 상태, 로그, 자원 사용량 확인 포인트를 대시보드 형태로 정리한 결과 이미지입니다.

8. 정리 및 FAQ: 어떤 기준으로 선택하면 되나

마지막으로 제가 멘토링할 때 가장 많이 드리는 기준을 남겨보겠습니다. 저도 처음엔 Cron만 썼는데, 서비스 운영 범위가 넓어지면서 systemd timer로 조금씩 옮겼거든요. 드디어 기준이 잡히고 나니까 선택이 쉬워졌어요.

• 단순한 작업 자동화가 필요하면 Cron으로 시작해도 됩니다.
• 로그 추적, 실패 복구, 의존성 관리가 중요하면 systemd timer가 나아요.
• 리눅스 스케줄러를 팀 표준으로 맞춘다면 systemd 방식이 문서화하기 편합니다.
• 성능 벤치마크는 숫자 경쟁보다 운영 관찰 가능성까지 함께 봐야 하고요.

자주 묻는 질문

Q. Cron이 systemd timer보다 항상 가볍나요?
꼭 그렇진 않아요. 짧은 작업에서는 체감 차이가 있을 수 있지만, 대부분은 실제 작업 로직이 더 큰 비중을 차지합니다.

Q. 기존 Cron을 전부 systemd timer로 바꿔야 하나요?
아니에요. 운영상 이점이 큰 작업부터 옮기면 돼요. 예를 들면 백업, 동기화, 서비스 연계 배치처럼요.

Q. 둘을 같이 써도 되나요?
물론이죠. 저도 실제로는 혼용하는 편입니다. 다만 동일한 작업이 중복 실행되지 않게 기준은 분명히 잡아야 해요.

다음 글에서는 systemd service 하드닝(hardening, 보안 강화)이나 백업 배치 표준화 쪽을 따로 다뤄볼 예정입니다. 이전 글에서 다뤘던 로그 관리와 묶어서 보면 더 이해가 잘 될 거예요. 혹시 지금 운영 중인 서버에서 어느 쪽이 맞을지 고민된다면, 먼저 “실패했을 때 얼마나 빨리 원인을 찾을 수 있나”부터 따져보세요. 그 질문 하나가 생각보다 방향을 잘 잡아줍니다.

Cron과 systemd timer 선택 기준을 빠르게 판단할 수 있도록 요약한 인포그래픽입니다.