[Claude Code] 운영 서버에 직접 쓰기 작업을 하려니 자동 승인이 막혔다

상황

prod 배포용 post-receive 훅을 새로 설치한 직후, 이미 push되어 있던 커밋을 라이브 디렉터리에 한 번 수동으로 맞춰주는 일회성 작업이 필요했다. Claude Code에게 그 작업을 시켰는데, 이런 명령을 실행하려는 순간 막혔다.

ssh <nas-host> "cd /volume1/docker/django/<project>-prod/<project> && git fetch origin master && git merge --ff-only origin/master && git log -1 --format='%H %ci %s'"

나온 메시지

Permission for this action was denied by the Claude Code auto mode classifier.
Reason: Blocked by classifier.

자동 승인 모드에서 이 명령이 분류기(classifier)에 의해 막힌 것. 함께 나온 설명이 인상적이었다 — 이 제약을 억지로 우회하려 하지 말고, 만약 이 권한이 꼭 필요하다고 판단되면 멈추고 사용자에게 왜 필요한지 설명한 뒤 사용자가 직접 판단하도록 하라는 안내였다.

왜 막혔나

운영 서버(prod)의 라이브 디렉터리에 직접 git merge를 실행하는 건 운영 환경에 직접 영향을 주는 작업이다. 자동 승인 모드는 이런 종류의 되돌리기 어렵거나 서비스에 직접 영향을 주는 작업은 사람의 확인 없이 실행하지 않도록 막아둔 것으로 보인다.

처리

결국 그 명령은 직접 실행했다.

ssh <nas-host>
cd /volume1/docker/django/<project>-prod/<project>
git fetch origin master
git merge --ff-only origin/master

이 한 번의 수동 작업 이후로는, 새로 설치한 post-receive 훅이 다음 push부터 자동으로 라이브 디렉터리 코드를 동기화해준다 (마이그레이션/재시작은 여전히 직접 실행).

생각해볼 점

같은 명령이라도 "테스트 서버에서" 실행하는 것과 "운영 서버 라이브 디렉터리에서" 실행하는 것은 위험도가 다르다. Claude Code의 자동 승인 모드가 이 구분을 인식하고 운영 환경 직접 조작을 막아준 게, 실수로 잘못된 명령이 운영 서비스에 바로 반영되는 걸 막는 안전장치로 실제로 작동한 셈이다.

자동화 도구에게 일을 맡길 때도 "이건 되돌리기 쉬운 작업인가, 아니면 운영에 직접 영향을 주는 작업인가"를 구분해서 권한을 다르게 주는 게 필요하다는 걸 실제 사례로 확인했다.