배포 스크립트 실행 권한 불일치가 새벽 배포를 막는다

배포 스크립트 파일 권한 하나를 맞추는 작업을 했다.

작은 변경이다. chmod +x publish.sh 한 줄로 끝나는 일이고, diff도 코드 한 줄 안 바뀐다. 그런데 이게 왜 생겼냐를 짚어보면 꽤 익숙한 패턴이 나온다.

왜 이런 게 생기나

로컬에서 스크립트 파일을 새로 만들거나 복사해서 커밋할 때, 실행 권한이 빠진 채로 올라가는 경우가 있다. 특히 macOS나 Windows 로컬 환경에서 파일을 다루다가 git에 올리면 100644 (일반 파일) 로 올라가는 경우가 잦다. 서버 쪽은 원래 100755 (실행 가능)로 기대하고 있는데, git이 이 불일치를 추적하지 않으면 CI/CD 파이프라인이나 직접 실행 시 Permission denied를 뱉는다.

# 서버 기대값
-rwxr-xr-x  publish.sh  (100755)

# 로컬 커밋 상태
-rw-r--r--  publish.sh  (100644)

이 차이를 git 레벨에서 바로잡는 방법은:

git update-index --chmod=+x publish.sh

또는 로컬에서 실제로 권한을 바꾼 뒤 커밋하는 방식이다. chmod +x publish.sh 후 git add 하면 git이 파일 모드 변경을 감지해 같이 반영한다.

파일 권한과 배포 신뢰도

배포 스크립트 권한 불일치는 작아 보이지만, 실제로는 꽤 찝찝한 사고의 씨앗이다. 특히 자동화 파이프라인에서 publish.sh를 직접 호출하는 구성이면, 권한 없이 실행 시도하는 순간 배포가 멈춘다. CI 로그 뒤져보면 bash: ./publish.sh: Permission denied 한 줄이 전부라 원인 파악도 잠깐 헷갈린다.

팀원한테 "이 스크립트 실행해봐" 했을 때 돌아오는 게 Permission denied면 — 내가 설명을 못 한 건지, 환경 문제인지, 스크립트 자체 버그인지 먼저 삽질하게 된다. 이런 사소한 불일치가 신뢰 비용을 만든다.

작은 수정이라도 맥락을 남기는 이유

커밋 메시지에 matches server 100755 를 명시한 건 의도적이다. 단순히 "실행 권한 추가"라고만 쓰면, 나중에 이 커밋을 보는 사람은 "왜 이게 빠져있었지?", "서버 상태랑 맞춰야 하는 건 어디서 나온 얘기야?" 라는 의문이 생긴다. 기준이 어디 있는지를 커밋 메시지에 박아두면 질문 자체가 줄어든다.

코드 리뷰에서도 이런 식의 컨텍스트를 PR description에 넣도록 팀 내에서 권장한다. 변경 자체보다 왜 이 값이 정답인지를 적는 것. 변경 stat이 거의 없는 커밋일수록 이유 설명이 더 중요하다. 코드가 없으니 설명이 전부다.

• 실행 권한 관련 실수는 새 스크립트 추가 시 자주 발생
• git config core.fileMode true 설정 확인도 환경 점검 시 챙길 포인트
• 팀 레포라면 onboarding 문서에 "스크립트 추가 시 권한 확인" 한 줄 넣는 게 낫다

별거 아닌 것 같지만, 배포 스크립트 권한 하나 안 맞아서 새벽 배포가 막히는 경험 한 번 하면 이런 커밋이 왜 필요한지 바로 이해가 된다. 끝.

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

• 외장SSD 쿠팡에서 보기 →
• USB허브 쿠팡에서 보기 →
• 노이즈캔슬링헤드폰 쿠팡에서 보기 →

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