일기 slecs

트래픽 모니터링 스크립트 실행 권한 누락으로 배포 멈춘 경험

목차

한 줄짜리 커밋이었다. traffic-watcher.py 파일에 실행 권한을 추가한 것. chmod +x 같은 작은 변경이 얼마나 크리티컬할 수 있는지 다시 한번 깨달은 순간이었다.

왜 이런 일이 발생하나

처음엔 단순하다. 스크립트를 로컬에서 작성하고 테스트한다. 그리고 git에 커밋한다. 보통은 여기까지는 문제가 없다. 왜냐하면 개발 머신에선 이미 python scripts/traffic-watcher.py로 실행하거나, 혹은 대충 복사한 파일들이 있었을 테니까. 하지만 배포 파이프라인이 작동하는 순간이 문제다.

CI/CD 서버에서 스크립트를 직접 실행하려는 순간—예를 들어 ./scripts/traffic-watcher.py 형태로 shebang을 이용해 실행하려는 순간—Permission denied가 튀어나온다. 파일 자체는 존재하고, 내용도 완벽하지만, 실행할 권한이 없다는 에러다.

이건 막상 겪으면 꽤 창피한 버그다. 코드 자체엔 문제가 없는데, 인프라 레벨의 작은 실수로 배포가 멈춘다. 특히 traffic-watcher 같은 모니터링/관리 스크립트라면, 이게 배포 후 자동 시작되어야 하는 종류라면, 이 한 줄의 누락이 시스템 전체의 가시성을 먹어버린다.

작은 것들이 쌓일 때

내가 이 커밋을 하면서 생각한 건, "이게 첫 번째 스크립트인가?"라는 질문이었다. 아니었다. 보통 프로젝트엔 몇 개의 운영 스크립트가 존재한다:
- 데이터 마이그레이션 스크립트
- 배치 작업용 진입점
- 헬스 체크 유틸
- 로그 분석 스크립트

이 모든 것들이 git에는 커밋되어 있지만, 실행 권한을 갖지 못했을 가능성이 높다. 한 파일만 고치는 게 아니라, "이런 일이 다시 생기면 어떻게 방지할까"를 생각해야 했다.

접근법 장점 단점
개별 chmod 커밋 각 파일이 필요할 때 명시적으로 처리 누락 가능성, 관리 분산
배포 스크립트에서 일괄 처리 중앙화된 통제, 한 곳만 수정 배포 스크립트가 복잡해짐
pre-commit hook 커밋 시점에 자동 감지 다른 사람의 로컬 설정에 의존
디렉토리 구조 정규화 스크립트 디렉토리의 규칙화 초기 정책 수립 필요

팀 리딩 관점에서의 회고

내가 팀장으로서 느낀 건, 이런 "작은" 실수들이 얼마나 팀의 신뢰를 깎을 수 있다는 것이다. 자동화가 작동하다가 갑자기 멈춘다. 원인을 추적하면 "아, 파일 권한 때문이구나"라는 결론에 도달한다. 그 순간 팀은 생각한다: "왜 이런 게 커밋되었지? 리뷰는 뭐 했고?"

물론 chmod +x를 체크리스트에 넣을 순 없다. 하지만 할 수 있는 게 있다:

  • 배포 자동화 테스트: CI 단계에서 실제로 스크립트를 실행해본다. 단순히 문법 체크만 하는 게 아니라, 권한 문제가 있는지까지.
  • 코드 리뷰 가이드라인: scripts/ 디렉토리에 새 파일이 추가되면, "이 파일이 직접 실행되어야 하는가?"를 체크박스 항목으로 넣는다.
  • 스크립트 템플릿: 새 스크립트를 만들 때 shebang과 함께, "chmod +x가 필요하니?"를 명시적으로 언급하는 문서화.
# scripts/traffic-watcher.py 같은 파일은
#!/usr/bin/env python3
# 이 첫 줄이 있으면, 반드시 chmod +x 필요

배운 점

단순한 chmod +x 한 줄이지만, 이걸 통해 다시 깨달은 게 있다. 운영과 배포의 세계에서는 코드만 완벽해선 부족하다. 파일 권한, 경로, 환경 변수, 스크립트 진입점—이런 "인프라 세부사항"들이 모두 맞아떨어져야 자동화가 작동한다.

그리고 팀이 커질수록, 이런 작은 실수가 누적될 가능성이 높아진다. 따라서 처음부터 규칙을 세우고, 자동화된 체크로 방어선을 만드는 게 정말 중요하다. 커밋 메시지가 "chore"인 이유도 여기 있다—큰 기능은 아니지만, 시스템이 제대로 작동하기 위한 필수 관리 작업이니까.

다음부턴 이런 파일들이 리뷰될 때 한 번 더 생각해야겠다.


🛒 이 글과 어울리는 추천 상품

*위 링크는 쿠팡파트너스 활동의 일환이며, 일정액의 수수료를 제공받을 수 있습니다.

댓글 0

첫 댓글 달아줘.