요약: Claude Code 6월 25일 릴리스에는 autoMode.classifyAllShell 설정이 추가됐습니다. 기존에는 arbitrary-code-execution 패턴에 가까운 Bash/PowerShell 명령만 auto-mode classifier로 보내는 흐름이었다면, 이 설정은 모든 셸 명령을 classifier에 태우는 선택지입니다. 팀에서 Claude Code를 쓰며 “어떤 명령은 그냥 지나가고 어떤 명령은 막히는지 모르겠다”는 문제가 있었다면 검토할 만한 기능입니다.
AI 코딩 도구가 셸을 실행할 수 있게 되면 생산성은 크게 올라갑니다. 테스트 실행, 패키지 설치, grep, git diff, 빌드, 마이그레이션 확인까지 자동으로 이어지기 때문입니다. 하지만 셸 실행 권한은 항상 위험을 동반합니다. cat package.json과 rm -rf build는 둘 다 셸 명령이지만 위험도는 완전히 다릅니다. curl도 단순 문서 조회일 수 있고, 외부로 데이터를 전송하는 명령일 수도 있습니다.
문제는 사용자가 체감하는 승인 기준입니다. 어떤 명령은 자동으로 실행되고, 어떤 명령은 갑자기 거절되며, 어떤 명령은 승인이 필요한지 설명이 부족하면 팀은 AI 도구를 불안정하다고 느낍니다. 특히 보안팀이나 플랫폼팀은 “왜 이 명령이 허용됐는가”를 설명할 수 있어야 합니다.
autoMode.classifyAllShell은 이 지점을 다룹니다. 모든 Bash/PowerShell 명령을 auto-mode classifier로 보내면 정책 적용 범위가 더 일관됩니다. 비용은 약간의 지연과 보수적 차단 가능성입니다. 이 글은 언제 켜고, 어떤 로그를 봐야 하고, 팀 정책을 어떻게 잡으면 좋은지 정리합니다.
기존 방식에서는 위험해 보이는 명령만 분류기에 들어가는 모델에 가깝습니다. 이 방식은 빠르고 덜 시끄럽지만, edge case가 생깁니다. 예를 들어 단순해 보이는 명령 안에 command substitution, pipe, redirect, network call, env 출력이 섞이면 위험도가 바뀝니다. 반대로 안전한 조회 명령이 패턴상 위험해 보이면 불필요하게 막힐 수 있습니다.
autoMode.classifyAllShell을 켜면 모든 셸 명령이 같은 입구를 통과합니다. 이 장점은 정책 설명이 쉬워진다는 점입니다. “Claude Code가 실행하는 모든 셸은 classifier 판정을 거친다”라고 말할 수 있습니다. 그리고 6월 25일 릴리스에는 auto-mode denial reasons가 transcript, denial toast, /permissions recent denials에 추가됐습니다. 즉 막힌 이유를 나중에 추적할 수 있습니다.
단점도 있습니다. 모든 명령이 분류되면 짧은 조회 명령도 약간 느려질 수 있고, classifier가 보수적으로 판단해 자주 쓰는 명령을 막을 수 있습니다. 따라서 개인 장비에서 무조건 켜기보다 팀 공용 환경, 민감 저장소, 배포 권한이 있는 워크스페이스부터 적용하는 것이 현실적입니다.
켜는 편이 좋은 환경은 세 가지입니다. 첫째, 프로덕션 접근 권한이 있는 개발 환경입니다. AWS, GCP, Kubernetes, database CLI, 사내 배포 도구가 로그인되어 있다면 모든 셸 명령을 심사하는 편이 안전합니다. 둘째, 외주나 다수 협업자가 같은 저장소를 다루는 환경입니다. 사람마다 Claude Code 사용 습관이 다르면 정책 일관성이 중요해집니다. 셋째, audit trail이 필요한 조직입니다. denial reason이 transcript와 permissions 기록에 남으면 보안 리뷰가 쉬워집니다.
굳이 켜지 않아도 되는 환경도 있습니다. 완전히 격리된 로컬 toy project, throwaway container, 네트워크가 막힌 샌드박스라면 모든 명령을 classifier에 태우는 비용이 이득보다 클 수 있습니다. 이 경우에는 destructive command, network egress, credential access만 별도 승인으로 잡는 방식이 더 빠릅니다.
중간 지점도 가능합니다. 기본 개발 환경은 off로 두고, 민감 프로젝트의 .claude/settings.json에서만 on으로 두는 방식입니다. 단, repo 설정이 팀에 영향을 주는 만큼 변경 이유와 기대 효과를 PR 설명에 적어야 합니다.
설정을 켠 뒤 첫날에는 “막힌 명령 목록”을 수집해야 합니다. /permissions recent denials에서 최근 거절을 보고, transcript의 denial reason을 함께 확인합니다. 여기서 목표는 classifier를 우회하는 게 아니라 팀의 정상 워크플로우를 이해하는 것입니다.
예를 들어 npm test, pnpm lint, git status, git diff가 거절된다면 정책이 너무 보수적이거나 실행 경로가 이상한 것입니다. 반대로 cat ~/.aws/credentials, env, curl -d @file, kubectl delete, psql production 같은 명령이 거절된다면 정상입니다. 이 구분을 문서화하면 개발자가 “AI가 또 막았다”가 아니라 “이건 민감 명령이라 승인이 필요하다”고 이해합니다.
denial reason은 짧게 분류하세요. 권장 카테고리는 credential access, destructive file operation, network exfiltration, production mutation, unknown script execution, package install, benign read-only입니다. 마지막 benign read-only가 많이 쌓이면 allow rule이나 workflow 안내를 개선할 수 있습니다.
실무에서는 다음처럼 간단한 기준으로 시작하는 것이 좋습니다.
읽기 전용 명령은 자동 허용 후보입니다. ls, pwd, git status, git diff, rg, cat 중 프로젝트 내부 파일을 대상으로 하는 명령은 낮은 위험입니다. 다만 home directory, credential directory, .env, key file은 예외입니다.
상태를 바꾸는 명령은 승인 후보입니다. npm install, pnpm add, migration 실행, formatter write, codegen write, git commit, git push, docker compose up/down은 프로젝트 파일이나 외부 상태를 바꿉니다. 자동으로 해도 되는 팀도 있지만, 처음에는 승인 기반이 낫습니다.
파괴적 명령과 외부 전송 명령은 항상 수동 확인입니다. rm, trash가 아닌 삭제, database drop, kubectl delete, curl upload, scp, rsync, secret 출력, production endpoint 호출은 AI가 판단해서 넘기면 안 됩니다. classifier가 막은 뒤 사람이 확인하는 게 맞습니다.
이 정책은 복잡한 문서보다 실제 예시 30개가 더 효과적입니다. 팀에서 자주 쓰는 명령을 표로 만들고 “자동”, “승인”, “금지”를 붙이면 신규 개발자 온보딩에도 도움이 됩니다.
첫 단계는 관찰 모드에 가깝게 시작하는 것입니다. 민감하지 않은 저장소 하나에서 autoMode.classifyAllShell을 켜고 하루 동안 denial reason을 봅니다. 정상 명령이 많이 막히면 설정을 바로 전사 적용하지 말고 classifier 결과를 기반으로 워크플로우를 정리합니다.
두 번째 단계는 민감 저장소 적용입니다. 이때는 settings 변경 PR에 보안 기준을 적습니다. “모든 셸 명령은 auto-mode classifier를 거친다”, “거절 이유는 /permissions recent denials에서 확인한다”, “반복 거절되는 정상 명령은 정책 리뷰로 처리한다” 정도면 충분합니다.
세 번째 단계는 교육입니다. 개발자에게 긴 보안 문서를 던지기보다, 실제 거절 화면을 캡처하고 “이 경우에는 왜 막혔는지”, “승인이 필요한 경우 어떤 정보를 확인해야 하는지”를 보여주세요. AI 도구의 보안은 정책보다 습관이 중요합니다.
autoMode.classifyAllShell 적용을 검토합니다./permissions recent denials와 transcript denial reason을 수집합니다..env, credential 파일, cloud config, production DB 관련 명령은 별도 고위험 규칙으로 둡니다.autoMode.classifyAllShell은 속도를 조금 내주고 일관성을 얻는 설정입니다. 개인 생산성 도구라면 선택 사항이지만, 팀 표준 개발 도구라면 검토할 만합니다. 핵심은 “모든 명령을 막자”가 아니라 “왜 허용되고 왜 막혔는지 설명 가능한 상태”를 만드는 것입니다.