티스토리 뷰

같은 스크립트도 실행 조건이 다릅니다

터미널에서는 성공하는 점검 스크립트가 cron에서 실패하면 실행 시간만 바꿔 재시도하기 쉽습니다. 하지만 작업 디렉터리, PATH, 실행 계정과 환경 변수 차이가 원인 후보입니다. 실패한 명령을 반복하기 전에 수동 실행과 예약 실행의 조건을 나란히 기록해야 합니다.

이 글은 Linux의 사용자 crontab을 설명합니다. 배포판과 cron 구현에 따라 기본 환경과 시간대 동작이 달라집니다. 시스템 crontab과 사용자 crontab은 필드 구성이 다를 수 있으므로 예시를 운영 설정에 그대로 붙이지 않습니다. 이번 글에서는 예약을 실제 등록하지 않았습니다.

명령의 위치와 입력 파일을 확인합니다

command -v bash
command -v python3
pwd
crontab -l

조회 결과에서 실제 명령 경로와 등록된 작업을 확인합니다. 스크립트 안에 상대 경로가 있으면 어떤 디렉터리를 기준으로 해석하는지 따져 봅니다. 터미널의 별칭이나 로그인 시 읽는 설정 파일에 의존한다면 cron에서 같은 조건이 보장되는지도 확인해야 합니다.

전체 환경 변수를 외부 로그에 출력하면 토큰과 비밀값이 노출될 수 있습니다. 필요한 PATH, 작업 디렉터리, 실행 계정 같은 항목만 내부에서 확인하고 민감값은 가립니다. 오류를 고치기 위해 모든 환경 변수를 복사하거나 관리자 계정으로 바꾸는 방법은 사용하지 않습니다.

예약 문장을 검토하는 교육용 예시

# 사용자 crontab 설명용 예시: 실제 등록하지 않음
10 8 * * * /usr/bin/bash /absolute/demo/check.sh >> /absolute/demo/check.log 2>&1

분·시·일·월·요일 필드 다음에 명령이 옵니다. 위 예시는 08:10 작업을 설명하지만 서버 시간대가 KST인지 확인하기 전에는 한국 시간 08:10이라고 단정할 수 없습니다. /usr/bin/bash와 /absolute/demo 경로도 실제 존재 여부를 확인해야 하는 자리표시자입니다.

로그 리디렉션 대상 디렉터리가 없거나 쓰기 권한이 없으면 실행 증거를 얻지 못할 수 있습니다. 로그가 계속 커질 수 있으므로 보관과 순환 정책도 필요합니다. cron 안의 퍼센트 문자와 따옴표는 구현 문서를 보고 해석해야 하며, 긴 복잡한 명령은 검토 가능한 스크립트로 나누는 편이 좋습니다.

예약 기록이 없을 때의 점검

가상 상황에서 스크립트 로그 파일이 비어 있다면 스크립트 내부 실패인지 예약 자체가 실행되지 않았는지 구분합니다. 등록된 crontab, 서버 시간대와 예약 시각, 명령 경로, 로그 대상의 존재 여부를 순서대로 확인합니다. 로그가 없다는 사실만으로 스크립트를 정상 종료했다고 쓰지 않습니다.

수동 실행할 때도 예약 계정과 같은 권한·작업 경로·필요 환경을 맞출 수 있는지 테스트 담당자가 확인합니다. 차이를 하나씩 정리하고 수정한 설정 한 항목과 재시험 결과를 대응시킵니다. 로그에는 실제 인증값이나 전체 환경 변수를 넣지 말고 필요한 조건의 존재 여부를 기록합니다.

조건을 하나씩 맞추어 재검증합니다

비교 항목 | 수동 실행 | 예약 실행
실행 계정 | 실제값 | 실제값
작업 디렉터리 | 실제값 | 실제값
실행 파일 경로 | 실제값 | 실제값
필요 변수 | 값 비공개, 존재 여부 | 존재 여부
출력 위치 | 경로·권한 | 경로·권한
종료 코드 | 실제값 | 실제값

재시험은 담당자가 허용한 테스트 환경에서 수행하고, 바꾼 조건과 실행 시각을 남깁니다. 여러 조건을 동시에 바꾸면 무엇이 영향을 줬는지 알기 어렵습니다. 한 번 성공한 결과와 다음 예약 시각에도 성공한 결과를 구분합니다.

오늘은 기존 스크립트에서 상대 경로와 로그인 환경 의존성을 찾아 목록으로 만들고, 예약 실행 기록에 종료 코드를 추가해 보세요. 수동 성공 여부만 적던 점검표보다 예약 실패를 다시 확인하기 쉬워집니다.

공식 자료와 확인 범위

기술 자료 확인일: 2026년 10월 12일. 교육용 자료는 실제 기관·고객의 기록이 아닙니다.

Debian cron: crontab 환경과 필드