Claude Code 차단 훅, exit code 2만으로는 부족한 이유 | DAKER 커뮤니티
팀이 위험 명령을 막기 위해 Claude Code hook을 만들어 두었다면, 이제 중요한 것은 규칙의 존재가 아니라 실제로 멈추는지 확인하는 일입니다. 보안 정책은 잘 작성하는 것만으로 끝나지 않고, 실행 경로에서 기대한 방식으로 작동하는지 재현해 봐야 의미가 생깁니다.
특히 Claude Code hooks에서는 exit code 2 차단 결과와 stdout JSON 형식이 함께 맞아야 의도한 흐름이 완성됩니다. 2026년 7월 20일 KST 기준 최신 공식 changelog도 hook 차단 결과와 권한 판정 보강을 함께 다루고 있어, 팀 보안 훅은 작성보다 검증이 더 중요하다는 점을 다시 보여줍니다.
차단 훅을 만들었는데 정말 멈추는지 어떻게 확인할까
위험 명령을 막기 위한 hook을 만들어 두었더라도, 실제 실행 경로에서 멈추지 않으면 정책은 문서에만 남게 됩니다. 표준 출력 JSON 형식, 종료 코드, 권한 프롬프트가 함께 얽히는 구조에서는 차단 의도와 실제 차단 결과가 달라질 수 있습니다.
Claude Code hook 검증의 핵심은 exit code 2와 stdout JSON 형식을 함께 확인하는 데 있습니다.
exit code 2와 stdout JSON을 같이 봐야 하는 이유
한 줄로 정리하면, hook은 종료 코드만 맞춘다고 끝나지 않습니다. Claude Code가 읽는 출력 형식까지 맞아야 차단, 질문, 허용의 흐름이 의도대로 이어집니다.
최신 changelog에는 stdout JSON 스키마 검증에 실패한 경우 exit code 2가 문서대로 차단되지 않던 문제를 고친 내용이 포함됩니다. 그래서 팀이 hook 규칙을 설계할 때는 성공 경로뿐 아니라 실패 형식까지 함께 테스트하는 것이 좋습니다.
차단 훅 검증은 어떤 순서로 진행하면 좋을까
검증은 실제 위험 명령을 실행하는 방식보다, 같은 패턴을 안전하게 재현하는 방식으로 접근하는 편이 좋습니다. 테스트 과정에서는 차단 의도와 실제 반응을 분리해 기록해야 나중에 운영 기준으로 남기기 쉽습니다.
- 막아야 할 위험 명령을 실제 명령 대신 안전한 더미 명령으로 재현합니다.
- hook이 exit code 2를 반환하는 경우와 정상 JSON을 반환하는 경우를 따로 기록합니다.
- stdout JSON이 스키마에 맞지 않을 때 Claude Code가 어떻게 반응하는지 확인합니다.
- 권한 프롬프트가 필요한 명령과 즉시 차단해야 하는 명령을 분리합니다.
- 검증 결과를 팀 문서에 명령 예시, 기대 결과, 실제 결과로 저장합니다.
위험 명령 차단을 안전하게 재현하는 방법
실제 파일 삭제 명령을 실행하기보다, 같은 패턴을 가진 무해한 문자열이나 테스트용 임시 경로로 hook 반응을 살펴보면 됩니다. 이렇게 하면 운영 환경을 건드리지 않으면서도 차단 로직이 기대대로 작동하는지 확인할 수 있습니다.
기본 hook 설계는 위험 명령 차단 hooks 글을 기준으로 잡고, 권한 프롬프트 기준은 권한 하드닝 글과 함께 맞춰 보면 좋습니다.
배포 전에 확인해 둘 점
- exit code 2가 기대한 차단 메시지로 이어지는지 확인합니다.
- stdout JSON 필드 이름과 값 형식이 문서 기준에 맞는지 봅니다.
- Bash, PowerShell, 원격 컨테이너 명령처럼 해석기가 다른 경로를 분리합니다.
- 차단, 질문, 허용 세 가지 결과를 각각 테스트합니다.
- 실패 로그에는 토큰, 내부 경로, 고객 데이터를 남기지 않습니다.
차단 훅은 만들어 두는 것보다, 실제로 멈추는지 재현해 보는 과정이 더 중요합니다.
공식 출처 기준으로 조심할 점
작성 기준일은 2026년 7월 20일 KST입니다. 기능 사실은 공식 changelog를 기준으로 확인했으며, 공개 링크는 본문에 포함한 DAKER 커뮤니티 글만 남겼습니다. 이 글은 보안 감사를 대체하지 않으며, 팀의 실제 hook 스키마와 권한 모드는 저장소별로 다시 확인할 필요가 있습니다.
자주 묻는 질문
exit code 2만 반환하면 무조건 안전한가요?
아닙니다. 출력 형식과 Claude Code의 hook 처리 결과까지 함께 확인해야 실제 차단이라고 볼 수 있습니다.
위험 명령을 실제로 실행해 봐야 하나요?
아닙니다. 테스트용 임시 경로나 무해한 더미 명령으로 같은 패턴을 재현하는 방식이 더 안전합니다.
PowerShell 팀도 같은 기준을 쓰면 되나요?
큰 원칙은 같지만 명령 해석과 출력 인코딩이 다를 수 있습니다. Windows 경로는 별도 케이스로 남겨 두는 편이 좋습니다.
오늘 바로 점검할 항목은 무엇인가요?
팀이 신뢰하고 있는 차단 훅 하나를 골라, 차단 결과와 stdout JSON 형식을 함께 재현해 보면 됩니다.
참고 자료
https://daker.ai/community/claude-code-hooks-block-dangerous-commands
https://daker.ai/community/post-mrqt8da2-753e5881
여러분 팀에서는 차단 훅을 검증할 때 exit code와 출력 형식 중 어느 부분에서 가장 자주 문제가 생기나요?