리눅스 작업 스케줄링: cron, at

서버 운영을 하다 보면 반드시 정해진 시점에 실행해야 하는 작업이 생긴다.
예를 들어 백업, 로그 정리, 임시 파일 삭제, 리포트 생성, 배치 실행 같은 작업은
사람이 매번 수동으로 처리하기 어렵다.

그래서 운영에서는 작업을 자동으로 예약하고 실행하는 도구가 필요하다.

이 글에서는 리눅스 작업 스케줄링에 대해 다음 흐름으로 정리한다.

• cron: 주기 작업 스케줄러
• at: 단발성 작업 스케줄러
• systemd 환경의 작업 스케줄링

cron: 주기 작업 스케줄러

1. 개념

cron은 리눅스에서 가장 대표적인 주기적 작업 스케줄러다.
정해진 시간이나 주기에 따라 작업을 반복 실행할 때 사용한다.

예를 들어 다음과 같은 작업이 cron의 대상이 된다.

• 매일 새벽 백업 실행
• 일정 주기 로그 정리
• 캐시 / 임시 파일 삭제
• 주기적 배치 작업 실행

즉 cron은 반복되는 운영 작업을 자동화하는 기본 도구라고 볼 수 있다.

2. 동작 구조

구성 요소

• 작업 정의: crontab
• 실행 주체: crond
• 서비스 관리: systemd

실행 흐름

• 사용자는 crontab에 실행 규칙을 등록한다.
• 실제 실행은 백그라운드 데몬인 crond가 수행한다.
• 데몬은 systemd가 서비스 단위로 관리한다.

3. 운영 시 주의사항

cron은 조용히 실패(silent failure) 할 수 있다.

대표적인 원인은 다음과 같다.

• 환경 변수 미설정 (PATH)
• 권한 문제
• 스크립트 내부 에러
• 표준 출력 / 에러 출력이 별도로 수집되지 않음

예를 들어 터미널에서는 잘 실행되던 스크립트가, cron에서는 실패하는 경우가 자주 있다.
이는 cron이 로그인 셸과 다른 환경에서 실행되기 때문이다.

그래서 운영 환경에서는 단순히 작업을 등록하는 것보다, 실패를 확인할 수 있게 만드는 것이 더 중요하다.

따라서 실무에서는 반드시 다음을 고려해야 한다.

• 로그 파일로 출력 리다이렉션
• 에러 출력 포함 (2>&1)
• 모니터링 연계

4. crontab 기본 명령어

# 현재 등록된 작업 확인
crontab -l

# 작업 편집
crontab -e

5. crontab 포맷

cron은 다음 5개의 시간 필드로 실행 시점을 지정한다.

* * * * * command
│ │ │ │ │
│ │ │ │ └ 요일 (0-7, 일요일=0 또는 7)
│ │ │ └ 월 (1-12)
│ │ └ 일 (1-31)
│ └ 시 (0-23)
└ 분 (0-59)

6. crontab 사용 예시

0 3 * * * /opt/myapp/backup.sh >> /var/log/myapp-backup.log 2>&1

이 설정은 다음 의미를 가진다.

• 매일 새벽 3시 실행
• 표준 출력 + 에러 로그를 파일에 기록

실행뿐 아니라 실패 여부를 나중에 추적할 수 있도록 로그까지 함께 남기는 형태다.

at: 단발성 작업 스케줄러

1. 개념

at은 한 번만 실행되는 작업 을 예약할 때 사용한다.

예를 들어 점검 종료 후 새벽 2시에 스크립트를 한 번 실행하거나,
일정 시각에 일회성 후처리 작업을 예약할 때 사용할 수 있다.

2. at 사용 예시

at 02:00
> /opt/myapp/run-once-job.sh
> Ctrl+D

위 예시는 지정한 시각에 스크립트를 한 번 실행하도록 예약하는 방식이다.

명령 입력을 마친 뒤 Ctrl + D를 누르면 작업이 등록된다.

3. at 주요 명령어

# 예약 목록 확인
atq

# 작업 삭제
atrm <job_id>

4. 동작 구조

구성 요소

• 작업 등록: at
• 실행 주체: atd
• 서비스 관리: systemd

실행 흐름

• 사용자는 at 명령으로 실행 규칙을 등록한다.
• 실제 실행은 백그라운드 데몬인 atd가 수행한다.
• 데몬은 systemd가 서비스 단위로 관리한다.

*구조는 cron과 비슷하지만, 반복 실행이 아니라 1회 실행이라는 점이 다르다.

systemd 환경의 작업 스케줄링

지금까지의 내용을 systemd 관점에서 정리하면,
리눅스 작업 스케줄링 구조는 다음처럼 볼 수 있다.

사용자는 cron, at으로 언제 작업을 실행할지 정의하고,
systemd는 그 규칙을 수행하는 데몬의 실행과 상태를 관리한다.

(참고) 대안: systemd timer

systemd 환경에서는 cron 대신 systemd timer를 사용하는 방식도 존재한다.

보통 .service와 .timer를 조합해서 사용하며,
systemd 체계 안에서 더 일관되게 관리할 수 있다는 장점이 있다.

주요 특징

• .service + .timer 조합
• journal과 연계된 로그 확인
• 의존성 및 실행 순서 관리 가능

하지만 다음의 이유로 실무에서는 여전히 cron이 많이 사용된다.

• 기존 시스템과의 호환성
• 단순 작업에 대한 직관성
• 빠르게 등록하고 확인하기 쉬운 사용성

정리

• cron은 반복 작업 스케줄링 도구
• at은 1회성 작업 스케줄링 도구
• crond, atd는 각각 systemd가 관리하는 서비스
• 운영에서는 작업 등록 자체보다 실패를 확인할 수 있는 로그와 실행 결과 관리가 더 중요하다