Linux cron job 설정 완벽 가이드 — crontab으로 자동 실행 스케줄 등록하는 방법

반복적인 서버 작업을 대신해 주는 Linux cron 백그라운드 자동화

운영 중인 서비스 장비에서 주기적인 DB 백업 파일 추출, 오래된 웹 서버 로그 정리, 일일 회원 통계 쿼리 실행 등 매일 일정 간격으로 반복되는 시스템 유틸리티 작업을 손수 타이핑하는 것은 인력의 큰 낭비입니다. Linux의 cron 서비스는 시스템 내부에서 유령처럼 상주하며, 개발자가 미리 작성해 둔 일정 계획표 명세에 따라 특정 스크립트나 명령 바이너리를 백그라운드 상에서 약속된 시각에 칼같이 자동 실행해 주는 예약 엔진입니다. 무인 서버 운영 체계에서 뼈대를 이룰 만큼 핵심적인 자동화 도구입니다.

현재 계정의 스케줄러를 제어하는 Linux crontab 기본 커맨드

cron 스케줄을 추가하고 관리할 때는 crontab이라는 사용자 전용 설정 유틸리티를 호출합니다. 터미널에 crontab -e 명령어를 입력하면 리눅스 시스템 편집기(nano 또는 vi)가 열리며, 이 텍스트 파일 내에 원하는 스케줄 예약 양식을 기재해 주기만 하면 스케줄 가입이 마감되죠. 현재 어떤 스케줄러들이 예약되어 대기 중인지 조회하고 싶다면 crontab -l을 입력하고, 등록된 스케줄 세트를 몽땅 폐기하여 포맷하고 싶다면 crontab -r 명령어를 입력하면 처리됩니다. 이때 -r 명령어는 실수로 잘못 치기 쉽고 즉시 지워버리므로 백업 없이 실행할 때 대단히 조심하셔야 합니다.

스케줄 시간을 맵핑하는 Linux cron 표현식 필드 분석

crontab 파일의 작성 규격은 공백으로 한 칸씩 격리된 5개의 날짜/시간 필드와 그 뒤에 실행할 쉘 스크립트의 경로를 한 줄로 적는 것으로 완성됩니다. 왼쪽부터 순서대로 분(0-59), 시(0-23), 일(1-31), 월(1-12), 요일(0-7, 0/7은 일요일) 구조를 이룹니다. H 문자나 대소문자를 판별하는 Jenkins와 달리 순수 숫자로만 표기해야 하죠. 예컨대 30 3 * * * /home/ubuntu/backup.sh 라고 작성하면, 매일 새벽 3시 30분에 지정한 경로의 백업 쉘 파일이 스스로 가동되는 스케줄링 흐름이 잡힙니다.

CLI 수동 실행과 다른 Linux cron 환경변수 PATH 삽질 극복 요령

많은 DevOps 입문자들이 겪는 가장 악명 높은 함정은 **'수동으로 쉘 스크립트를 켤 때는 완벽하게 돌던 기능이, 왜 cron에만 가면 쥐도 새도 모르게 죽어버리는가'** 하는 에러입니다. 우리가 SSH 터미널에 로그인해 있을 때는 .bashrc나 .profile 파일에 등록된 풍부한 명령어 경로 정보($PATH)가 로딩되어 있어서 node나 git 명령을 그냥 쳐도 OS가 경로를 알아서 찾아내 실행하지만, cron 데몬은 극단적으로 최소화된 환경 정보(보통 /usr/bin이나 /bin)만 들고 태어나기 때문입니다. 이 삽질을 극복하려면 스크립트 파일 내에서 구동하는 모든 명령어(예: node 대신 /usr/bin/node, tar 대신 /bin/tar)를 **반드시 절대 경로 명칭으로 기재해 주어야** 하며, 스크립트 최상단 라인에 명시적으로 $PATH 환경 변수 문자열을 덮어쓰기해 두는 방어 코드를 심어야 인프라가 뻗는 사고를 완벽히 차단할 수 있습니다.

# [올바른 cron 스크립트 작성 요령 예시 - backup.sh]
#!/bin/bash

# 1. cron 환경에서도 작동할 수 있도록 PATH 환경 변수 명시적 선언
PATH=/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin

# 2. 모든 실행 명령어에 절대 경로 적용
/usr/bin/docker exec db_container /usr/bin/pg_dumpall -U postgres > /home/ubuntu/db_backup_$(/bin/date +%Y%m%d).sql

# 3. 30일이 지난 백업 파일 삭제
/usr/bin/find /home/ubuntu/ -name "db_backup_*.sql" -mtime +30 -exec /bin/rm -f {} \;

syslog 분석을 통해 Linux cron 자동 실행 실패 디버깅하기

cron은 화면이 없는 백그라운드에서 조용히 돌아가기 때문에, 스크립트 내부에서 에러가 터져도 터미널 창에 에러 로그를 보여주지 않아 먹통 유령 상태에 빠지기 십상입니다. 이럴 때는 리눅스의 기본 통합 로깅 파일인 /var/log/syslog 파일을 grep cron 명령으로 필터링해 추적하거나, /var/log/cron 경로를 까보는 것이 해결의 지름길입니다. 로그 안에 CMD 지시어와 함께 우리 스크립트명이 찍혀 있는데도 아무 데이터가 안 쌓였다면, 에러 출력을 일반 텍스트 파일로 리다이렉션(>> /home/ubuntu/cron_error.log 2>&1)되도록 crontab에 살짝 기록을 덧붙여 오류 원인을 손쉽게 분석하여 디버깅을 마칠 수 있습니다.

# [crontab -e 설정 창 기입 예시]
# 매일 새벽 2시 0분에 스크립트를 구동하고 표준 에러(2)와 표준 출력(1)을 한곳에 로깅
0 2 * * * /home/ubuntu/backup.sh >> /home/ubuntu/cron.log 2>&1