백업 스크립트를 등록해 놨는데 다음 날 확인해 보면 실행된 흔적이 없고, 로그도 남지 않는 상황을 한 번쯤 겪게 됩니다. 이때 가장 많이 헷갈리는 부분은 “문법은 맞는데 왜 실행이 안 되는지”입니다. 이 글에서는 FreeBSD cron 설정에서 실제로 막히는 지점을 기준으로, 등록부터 오류 원인까지 한 번에 정리합니다.
1. cron이 동작하는 구조부터 이해해야 하는 이유
cron을 등록했는데 아무 반응이 없을 때, 가장 먼저 확인해야 할 건 문법이 아니라 구조입니다. FreeBSD에서는 cron 데몬이 백그라운드에서 실행되면서 crontab 파일을 주기적으로 읽고 작업을 수행합니다.
각 사용자마다 별도의 crontab이 존재하고, 시스템 전체 설정은 별도로 관리됩니다. 즉, “어디에 등록했는지”에 따라 실행 여부가 달라질 수 있습니다.
실제로는 root에 넣어야 하는 작업을 일반 사용자에 등록해 놓고 실행이 안 되는 경우가 자주 보입니다. 이건 권한 문제라기보다 실행 환경 자체가 다르기 때문입니다.
겉보기에는 단순한 예약 실행이지만, 사용자 단위로 분리되어 있다는 점이 처음에 많이 헷갈리는 부분입니다. 여기서 갈리는 핵심은 ‘어떤 사용자 기준으로 실행되느냐’입니다.
2. crontab 시간 문법, 헷갈리는 지점만 정리
cron 설정에서 가장 많이 막히는 부분은 시간 표현입니다. 특히 분, 시, 일, 월, 요일 순서를 헷갈리는 경우가 많습니다.
기본 구조는 다음과 같습니다.
분 시 일 월요일 명령어
예를 들어 매일 새벽 3시에 실행하려면 “0 3 * * *” 형태가 됩니다. 여기서 *는 모든 값을 의미합니다.
문제는 요일과 날짜를 동시에 지정했을 때입니다. 둘 중 하나만 맞아도 실행되는 방식이라 의도와 다르게 동작할 수 있습니다.
처음 설정할 때는 “조건을 줄이는 방향”보다 “명확하게 하나만 지정하는 방식”이 오류를 줄입니다. 놓치기 쉬운 포인트는 요일과 날짜가 AND가 아니라 OR 조건처럼 작동한다는 점입니다.
3. 실제로 많이 쓰는 작업 예시와 적용 방식
로그 정리나 백업 작업을 cron으로 돌리려다가 경로 문제에서 막히는 경우가 많습니다.
예를 들어 매일 자정 로그 삭제:
0 0 * * * /usr/bin/find /var/log -type f -mtime +7 -delete
여기서 중요한 건 명령어 자체보다 “절대 경로”입니다. cron은 일반 쉘과 다르게 PATH 환경 변수가 제한적이기 때문에 상대 경로가 거의 동작하지 않습니다.
또 하나 자주 보이는 상황은 스크립트는 잘 되는데 cron에서는 실패하는 경우입니다. 이건 실행 권한 또는 쉘 환경 차이 때문인 경우가 많습니다.
실제로는 명령어보다 “어디에서 실행되는지”를 먼저 확인하는 것이 더 중요합니다. 헷갈리기 쉬운 부분은 터미널에서 되면 cron에서도 된다고 착각하는 점입니다.
4. 실행 안 되는 가장 흔한 원인 4가지
cron이 동작하지 않을 때는 대부분 비슷한 원인에서 막힙니다.
첫 번째는 경로 문제입니다. 두 번째는 실행 권한 누락입니다. 세 번째는 환경 변수 부족입니다. 네 번째는 로그 확인을 안 한 상태입니다.
특히 로그를 확인하지 않고 계속 설정만 수정하는 경우가 많은데, 이 단계에서 시간이 가장 많이 낭비됩니다.
/var/log/cron 또는 메일 로그를 보면 실패 원인을 바로 확인할 수 있습니다.
처음부터 모든 걸 완벽하게 설정하려 하기보다, “단순한 echo 테스트”부터 시작하는 것이 훨씬 빠릅니다. 여기서 갈리는 핵심은 ‘문법 확인보다 실행 결과 확인을 먼저 하는 습관’입니다.
5. 운영 환경에서 안정적으로 돌리는 방법
cron 작업을 운영 환경에 적용하면, 단순 실행보다 안정성이 더 중요해집니다.
예를 들어 백업 작업은 실패했을 때 알림이 없으면 문제가 커질 수 있습니다. 그래서 출력 결과를 로그 파일로 남기는 방식이 기본적으로 권장됩니다.
또한 동시에 실행될 수 있는 작업이라면 lock 파일이나 조건 체크를 넣어 중복 실행을 방지해야 합니다.
실제 운영에서는 “잘 돌아가는 것”보다 “문제 발생 시 추적 가능한 상태”가 더 중요합니다.
초기에는 자동화보다 확인 가능성을 우선으로 설계하는 것이 시행착오를 줄입니다. 놓치기 쉬운 포인트는 성공 케이스보다 실패 케이스 대비가 더 중요하다는 점입니다.
6. FAQ
Q1. crontab 수정 후 바로 적용되나요?
대부분 저장 즉시 반영되지만, 데몬 상태에 따라 지연될 수 있습니다. 재시작이 필요한 경우도 있어 확인이 필요합니다.
Q2. 특정 스크립트만 실행이 안 되는 이유는?
경로 또는 실행 권한 문제일 가능성이 큽니다. 특히 쉘 환경 차이를 먼저 확인하는 것이 좋습니다.
Q3. 로그는 어디서 확인하나요?
/var/log/cron 또는 시스템 메일 로그에서 확인할 수 있습니다. 로그를 먼저 보는 습관이 중요합니다.
Q4. cron에서 환경 변수 설정 가능한가요?
가능합니다. crontab 상단에 PATH나 SHELL을 직접 지정할 수 있습니다.
Q5. 테스트는 어떻게 하는 게 좋나요?
처음에는 1분 단위로 실행되도록 설정하고 echo 출력으로 정상 동작 여부를 확인하는 방식이 가장 빠릅니다.
마무리
cron 설정은 문법 자체보다 “실행 환경 이해”에서 성패가 갈립니다. 특히 처음에는 복잡한 작업을 넣기보다, 단순한 테스트부터 점검하는 흐름이 훨씬 안정적입니다.
지금 설정한 cron이 있다면, 바로 로그 확인부터 해보는 것을 권합니다. 문제가 있다면 대부분은 생각보다 단순한 부분에서 막혀 있을 가능성이 높습니다.