크론 환경에서 인증 체크 스크립트 타임아웃 버그 수정
목차
auth-check 스크립트가 cron 환경에서 자꾸 실패한다는 보고가 들어왔다. 직접 실행하면 멀쩡하게 돌아가는데 cron job으로 올라가면 FAIL이 떨어지는 현상. 원인은 stdin 대기였다.
Cron과 Interactive Shell은 다르다
처음엔 직관적이지 않을 수 있다. 같은 셸 스크립트인데 왜 다를까?
Interactive shell은 사용자가 터미널에 앉아서 실행하는 환경이다. 키보드 입력을 받을 준비가 되어 있다. stdin이 연결되어 있고, 스크립트가 입력을 기다리면 사용자가 줄 수 있다.
Cron은 백그라운드 스케줄러가 정해진 시간에 명령을 실행하는 환경이다. 사용자 입력이 없다. stdin은 /dev/null이거나 끊겨있다. 그런데 스크립트가 stdin을 기다리면? 타임아웃이 발생하거나 hang 상태로 빠진다.
여기가 핵심인데, auth-check 스크립트 내 exec나 print 핑 부분이 stdin을 소비하려고 했던 거다. cron에서 가동되면서 stdin이 없으니 대기 상태에 빠지고, 결국 timeout으로 FAIL 판정이 나버렸다.
문제의 실체: stdin 대기
shell에서 stdin을 기다리는 흔한 패턴들:
# 1. read 명령어
read -p "뭔가 입력하세요: " input
# 2. cat (입력 없이 실행되면 대기)
cat
# 3. exec < /dev/stdin (명시적으로 stdin 리다이렉트)
exec < /dev/stdin
# 4. 파이프나 리다이렉트 체인에서 실수로 stdin 소비
echo "test" | some_command < /dev/stdin
코드리뷰할 때 이런 패턴들을 놓치기 쉽다. 특히 cron에서만 실패하는 버그는 로컬에선 잡아내기 힘들다. 개발자가 손으로 테스트할 때는 항상 interactive 환경이니까.
해결: </dev/null로 stdin 명시하기
fix는 간단했다. exec와 print 명령어 실행 시 stdin을 /dev/null로 명시적으로 리다이렉트하는 것.
# Before: stdin을 기다릴 수 있는 상태
exec some_command
# After: stdin을 닫아버리기
exec some_command </dev/null
이렇게 하면:
- interactive shell에서 실행해도 문제없다 (stdin이 필요 없으면 그냥 진행)
- cron에서 실행할 때도 stdin 대기로 인한 hang이 없다
- 의도도 명확하다 ("이 명령어는 stdin을 필요로 하지 않음")
두 개 스크립트(claude-auth-check.sh, codex-auth-check.sh)를 모두 고쳤다. auth 체크는 periodic하게 도는 중요한 작업이라 cron 안정성이 중요했다.
배운 점: cron 환경을 명시적으로 고려하기
이 경험에서 얻은 교훈이 몇 가지 있다.
첫째, 스크립트 작성할 때부터 cron 친화적으로 생각해야 한다. 특히 automation 영역에서 작성하는 스크립트는 사람이 손으로 실행하는 경우보다 cron/scheduler에서 도는 경우가 대부분이다. 로컬에서만 테스트하고 merge했다면 위험하다.
둘째, input/output 명시성. stdin, stdout, stderr를 어디서 받고 어디로 보낼지 명확히 해야 한다. 특히 비대화형 환경에서:
- stdin은 대부분 필요 없으니 </dev/null
- stdout/stderr는 로그 수집이 필요하면 파일로 리다이렉트
- exit code는 모니터링 시스템이 해석하므로 정확히
셋째, 팀 코드리뷰에서 cron 체크포인트 추가하기. auth나 health check 같은 중요한 스크립트는 "이게 cron에서도 잘 도나?" 를 checklist 항목으로 넣는 게 좋다. 실제로 cron 환경 시뮬레이션도 가능하다:
# stdin을 닫고 실행해보기
/path/to/script </dev/null
# 또는 at 명령어로 백그라운드 스케줄 테스트
echo "/path/to/script" | at now + 1 minute
이번 건 사소한 버그처럼 보이지만, 모니터링 시스템이 false positive를 계속 받으면 alert fatigue가 생기고 결국 누군가 중요한 경고를 놓치게 된다. 그래서 automation 파이프라인의 안정성은 단순한 "코드가 맞는가"를 넘어서 "프로덕션 환경에서 믿을 수 있는가"까지 가야 한다.
🛒 이 글과 어울리는 추천 상품
*위 링크는 쿠팡파트너스 활동의 일환이며, 일정액의 수수료를 제공받을 수 있습니다.
댓글 0
첫 댓글 달아줘.