Claude Code를 좀 써본 사람이면 공감할 텐데, 승인 팝업이 많음. 파일 수정할 때 한 번, 셸 명령 실행할 때 한 번, MCP 도구 쓸 때 한 번. 복잡한 작업이면 수십 번 “OK” 누르게 됨. 자율적으로 일하라고 시켰는데 매번 허락을 구하는 셈.
그래서 많은 사람이 --dangerously-skip-permissions 플래그를 씀. 이름 그대로 “위험하게 모든 권한을 건너뛴다”. 편하긴 한데, AI가 실수로 파일을 날리거나 이상한 명령을 실행해도 막을 방법이 없음. 이름에 “dangerously”가 붙어있는 이유가 있음.
3월 24일, Anthropic이 이 사이의 간극을 메우는 기능을 냈음. Auto Mode. 승인 팝업 없이 자율 실행하되, 뒤에서 별도의 분류기(classifier)가 위험한 행동을 감시하고 차단하는 구조.
Auto Mode가 작동하는 방식
Auto Mode는 단순히 “전부 허용”하는 게 아님. 2중 방어 구조로 돌아감.
입력 레이어: 도구 출력물(파일 내용, 웹 페이지 등)이 Claude의 컨텍스트에 들어가기 전에 서버 측 프롬프트 인젝션 탐지기가 스캔함. 적대적 내용이 발견되면 경고를 추가함.
출력 레이어: Claude가 행동(파일 수정, 명령 실행 등)을 하려고 할 때마다 별도의 분류기 모델(Sonnet 4.6)이 해당 행동을 평가함. 분류기는 Claude의 추론 과정을 볼 수 없음. 의도적으로 그렇게 설계됨. Claude가 분류기를 설득해서 위험한 행동을 승인받는 걸 원천 차단하기 위해서.
행동은 3단계로 평가됨.
1단계 — 안전 도구 허용목록: 파일 읽기, 코드 검색, 계획 수립 같은 읽기 전용 행동은 즉시 실행됨. 분류기를 거치지 않음.
2단계 — 프로젝트 내 파일 수정: 작업 디렉토리 안의 코드 수정은 분류기를 건너뜀. 어차피 git으로 리뷰할 수 있기 때문.
3단계 — 나머지 전부: 셸 명령, 외부 도구 호출, 프로젝트 밖 파일 접근, 자격 증명 사용 → 분류기가 판단.
분류기 자체도 2단계로 나뉨.
- Stage 1 (빠른 필터): yes/no 한 토큰만 출력. “차단 쪽으로 편향”되게 튜닝됨. 오탐률(false positive) 8.5%.
- Stage 2 (정밀 분석): Stage 1이 위험하다고 판단한 경우에만 작동. Chain-of-thought 추론으로 정밀 분석. 오탐률을 0.4%까지 낮춤.
Stage 2는 Stage 1의 컨텍스트를 재활용(prompt caching)해서 비용을 줄임. 결국 대부분의 안전한 행동은 Stage 1에서 바로 통과하고, 의심스러운 것만 Stage 2에서 정밀 분석하는 구조.
뭘 막고 뭘 허용하나
기본 차단 목록:
curl | bash같은 외부 코드 다운로드 후 실행- 외부 엔드포인트로 민감 데이터 전송
- 프로덕션 배포 및 마이그레이션
- 클라우드 스토리지 대량 삭제
- IAM/레포 권한 변경
- 공유 인프라 수정
- 세션 이전에 존재하던 파일의 비가역적 삭제
git push --force,main브랜치 직접 푸시
기본 허용 목록:
- 작업 디렉토리 내 로컬 파일 조작
- lock 파일에 선언된 의존성 설치
.env읽기 + 해당 API로 자격 증명 전송- 읽기 전용 HTTP 요청
- 현재 브랜치 또는 Claude가 생성한 브랜치에 푸시
이 목록이 왜 중요하냐면, 커스텀 가능하기 때문. claude auto-mode defaults 명령으로 현재 기본값을 확인하고, 환경 신뢰 경계(어떤 도메인/버킷/서비스를 내부로 볼 것인지), 차단 규칙, 허용 예외를 설정할 수 있음. 예를 들어 회사 레포에 푸시하는 게 계속 차단되면, 해당 레포를 신뢰 인프라로 등록하면 됨.
실전에서 어떻게 다른지
기존 권한 모드를 정리하면 이런 그림.
| default | acceptEdits | auto | bypassPermissions | |
| 승인 팝업 | 파일 수정 + 명령 실행마다 | 명령 실행만 | 없음 (폴백 시 복귀) | 없음 |
| 안전 장치 | 사람이 직접 리뷰 | 사람이 명령만 리뷰 | 분류기가 자동 리뷰 | 없음 |
| 토큰 사용 | 기본 | 기본 | 높음 (분류기 비용) | 기본 |
| 적합한 상황 | 민감한 작업 | 코드 반복 수정 | 장시간 자율 작업 | 격리된 컨테이너만 |
Auto Mode를 키려면 Shift+Tab으로 모드를 순환하면 됨. default → acceptEdits → plan → auto 순서. CLI에서 시작할 때 직접 지정도 가능함.
claude --permission-mode auto --enable-auto-modeVS Code에서는 프롬프트 박스 하단의 모드 표시를 클릭해서 전환. Desktop 앱에서는 보내기 버튼 옆 모드 셀렉터.
분류기가 차단하면 어떻게 되나?
Claude가 멈추는 게 아님. 차단 사유를 받아서 다른 방법으로 시도함. 예를 들어 git push --force가 차단되면 일반 git push로 대안을 찾음. 0.4% 오탐률이 쌓여도 작업이 중단되지 않는 이유.
연속 3회 또는 세션 내 총 20회 차단되면 Auto Mode가 일시 중지되고 수동 승인 모드로 돌아감. 승인 한 번 해주면 카운터가 리셋되어 다시 Auto Mode로 진행. -p 플래그(비대화식)에서는 사람이 없으니까 바로 세션 종료.
서브에이전트도 적용됨. Claude가 서브에이전트를 띄울 때 분류기가 위임 작업을 먼저 평가하고, 서브에이전트 내부에서도 같은 분류기가 돌아감. 서브에이전트가 끝나면 행동 이력을 다시 검토해서, 도중에 뭔가에 오염됐는지도 체크함.
한계와 현실적 판단
Auto Mode가 만능은 아님. 몇 가지 명확한 한계가 있음.
미탐률 17%. 실제 위험한 행동 중 17%를 놓침. bypassPermissions보다는 훨씬 안전하지만, 사람이 직접 리뷰하는 것보다는 못함. Anthropic도 “고위험 인프라 작업에는 적합하지 않다”고 명시함.
추가 토큰 비용. 분류기 호출이 토큰을 소비함. 읽기 전용 행동과 프로젝트 내 파일 수정은 분류기를 거치지 않으니 비용이 안 들지만, 셸 명령이 많은 작업은 비용이 눈에 띄게 올라갈 수 있음.
지연 시간. 분류기 체크마다 라운드트립이 추가됨. 체감상 각 명령 실행 전에 살짝 멈추는 느낌.
제한된 가용성. 현재 Team 플랜 리서치 프리뷰. Enterprise와 API는 곧 출시. Sonnet 4.6 또는 Opus 4.6 필수. Haiku, claude-3, 서드파티(Bedrock/Vertex/Foundry)에서는 사용 불가.
그래도 실전에서의 가치는 명확함. 장시간 리팩토링이나 대규모 코드 생성 같은 작업에서 승인 팝업을 수십 번 누르는 건 진짜 피로함. Auto Mode는 이 피로를 없애면서도 “AI가 멋대로 rm -rf 날린다”는 최악의 시나리오는 막아줌.
--dangerously-skip-permissions를 습관적으로 쓰고 있었다면, Auto Mode로 바꾸는 게 합리적. 편의성은 거의 같으면서 안전장치가 생김. 완벽하지는 않지만, “위험을 감수하고 전부 건너뛰기” 와 “매번 일일이 승인” 사이의 현실적인 중간 지점.
Claude Code 기본 사용법이 궁금하면 Claude Code 사용법 가이드, 권한 모드 외에 Channels/Dispatch/Computer Use 같은 최신 기능이 궁금하면 Claude Computer Use + Dispatch 정리 참고.