AIREITERAnthropic이 10월 22일 발표한 내용에 따르면, 다음 주부터 Pro, Max, Team 요금제의 대부분 Claude 앱에서 새 세션이 Claude auto mode로 시작합니다. Enterprise 관리자는 조직에 적용되기 전에 이메일로 안내받으며, API와 클라우드 플랫폼은 당분간 사용자가 직접 켜야 합니다.
10월 22일에 달라진 점과 그대로인 점
이번 10월 22일 업데이트는 Claude Code에 먼저 적용된 변화를 대부분의 Claude 앱으로 확장합니다. 2026년 8월 14일부터 Pro, Max, Team 요금제의 새 Claude Code 세션은 auto mode로 시작했고, 다른 기본 모드를 고정해 둔 사용자에게는 한 번만 전환 여부를 묻는 메시지가 표시됐습니다. 같은 Anthropic 발표의 10월 22일 공지는 다음 주부터 Pro, Max, Team 요금제의 대부분 Claude 앱에서 새 세션의 기본값도 auto mode가 된다고 설명합니다. Enterprise 관리자는 조직 설정이 바뀌기 전에 이메일을 받습니다.
다만 세 가지 경계는 그대로입니다. Team 관리자가 관리형 설정에서 기본 모드를 고정해 두었다면 사용자에게는 변화가 없습니다. Enterprise, Claude API, AWS의 Claude Platform, Amazon Bedrock, Google Cloud's Agent Platform, Microsoft Foundry는 계속 opt-in 방식으로 운영되며, 이 영역에서도 다음 달 중 auto mode를 기본값으로 전환할 계획입니다. 사용자가 개인적으로 고정한 기본 모드 역시 일회성 전환 안내를 수락하지 않는 한 유지됩니다.
사용 중인 버전도 중요합니다. 릴리스 노트 추적 자료에 따르면 Claude Code v2.1.283 이상에서는 권한 모드를 따로 지정하지 않은 대화형 터미널 및 VS Code 세션이 auto를 기본 시작 모드로 표시합니다. 다만 기능 플래그가 아직 전달되지 않은 상태라면 새로 설치한 앱이 첫 실행에서 manual mode로 시작할 수 있습니다.
Claude auto mode는 어떻게 판단하나
Anthropic의 설명에 따르면 Claude auto mode는 각 단계마다 승인을 묻는 대신, 도구 호출을 별도의 분류기로 보냅니다. 분류기는 일반적인 작업은 허용하고, 되돌릴 수 없거나 파괴적이거나 작업 환경 밖을 향한 작업은 차단합니다. 이후 Claude는 더 안전한 경로를 찾거나 사용자에게 직접 묻습니다. 한 세션에서 세 번 연속 차단되거나 총 스무 번 차단되면 수동 승인 방식으로 돌아갑니다.
명시적으로 설정한 권한 규칙은 Claude auto mode에서도 분류기보다 먼저 적용됩니다. permissions.deny에 등록한 항목은 즉시 차단되며 분류기의 판단으로 재정의할 수 없습니다. permissions.ask 항목은 언제나 승인을 요청합니다. Bash(python:*)처럼 임의의 코드 실행을 허용하는 광범위한 allow 규칙은 auto mode가 켜져 있는 동안 잠시 제외됩니다. 명령이 분류기를 완전히 건너뛰지 못하게 하기 위해서입니다.
분류기는 고정된 allowlist보다 더 많은 맥락을 살핍니다. Anthropic은 git push나 pull request의 대상이 비공개인지, 신뢰할 수 있는 곳인지, 공개 대상인지 확인한 뒤 작업을 실행한다고 설명합니다. git reset --hard 같은 파괴적 명령을 실행할 때는 현재 git 상태도 함께 확인합니다.
웹 페이지, 파일 내용, 도구 출력에서 들어온 외부 콘텐츠는 프롬프트 인젝션 탐지 절차를 거칩니다. 인젝션 시도로 보이는 내용이 있으면 Claude의 컨텍스트에 경고가 추가됩니다. 데이터 유출은 자동 승인되지 않는 강제 차단 항목입니다. 이런 작업을 실행하려면 모드를 바꾸거나 명령을 직접 실행해야 합니다.
Anthropic이 클릭식 승인을 auto mode보다 불리하다고 보는 이유
Anthropic은 이번 변경을 측정 결과에 근거한 사용성 개선으로 설명합니다. 사용자는 Claude Code의 권한 요청 중 97%를 승인하지만, 제시된 계획은 39%만 거부합니다. Anthropic은 이 차이가 각 요청을 검토하기보다 습관적으로 버튼을 누르는 행동을 보여준다고 해석합니다. 2026년 6월 기준으로 활성 CLI 사용자의 49.5%는 직접 Bash allow 규칙을 작성했고, 62%는 bypassPermissions 또는 "don't ask again"을 사용했으며, 대화형 세션의 25%는 bypass mode로 시작했습니다.
통제된 실험에서는 이런 습관을 수치로 확인했습니다. Anthropic은 연구 업체를 통해 유료 테스터 1,053명을 모집하고, 세션마다 권한 요청 하나를 명백히 위험한 명령으로 바꾼 뒤 반응을 기록했습니다. 위험한 명령의 내용은 실제로 실행되지 않았습니다. 사람은 1,053명 중 143명, 즉 13.6%만 해당 명령을 찾아냈지만, auto mode는 같은 명령 1,053개 중 937개를 차단해 89%의 탐지율을 보였습니다.
직접 비교하면 auto mode는 사람이 승인한 명령 중 800개를 차단했습니다. 반대로 사람은 auto mode가 허용한 명령 중 6개만 차단했습니다. 사람의 탐지율은 초반 약 17%에서 이전에 50개 이상의 요청을 처리한 뒤 약 5%까지 떨어졌지만, auto mode의 성능은 거의 변하지 않았습니다.
Anthropic의 발표에 인용된 실제 운영 데이터와 제3자 실험도 같은 방향을 가리킵니다. 2026년 5월부터 6월까지 위험 신호가 감지된 세션을 보면, 수동 승인 세션의 6.3%에는 사용자가 명시적으로 요청하지 않은 운영 수준의 피해가 포함됐습니다. auto mode 세션에서는 그 비율이 2.4%였습니다. Trajectory Labs는 프롬프트 인젝션 시나리오 72개를 각각 10번씩 실행했습니다. 그 결과 Claude Fable 5, Opus 5, Sonnet 5의 auto mode에서는 720번의 시도 중 성공한 사례가 한 번도 없었고, Codex Auto-review mode의 GPT-5.6 Sol에서는 성공률이 5.83%였습니다.
Apollo Research의 레드팀 테스트에서는 저장소 공개 여부, git 상태, 데이터 처리 규칙을 반영해 분류기를 강화한 뒤 오판율을 12%에서 7%로 낮췄습니다. Anthropic은 세 가지 내부 차단 사례도 소개했습니다. 오프네트워크 업로드가 공개 paste 사이트로 우회되는 상황, GPU 학습 작업을 위협할 수 있는 약 2,000개 pod의 대량 프로세스 종료, 지나치게 넓은 결제 역할 권한 상승이 그것입니다. Adobe, Nuro, Gusto, Garner Health를 포함한 Teams 및 Enterprise 도입 기업에서는 pull request가 약 25% 증가했다고도 밝혔습니다.
전환 후 사용자가 실제로 겪는 문제
발표문이 자세히 다루지 않은 불편은 실제 사용자 게시물에서 더 분명하게 드러납니다. commit, worktree 정리, SSH와 서버 작업, 배포 명령처럼 일상적인 작업이 auto mode에서 차단되거나 다시 승인을 요구한다는 불만이 많습니다.
"auto classifier가 아주 기본적인 작업에도 계속 권한을 요청하고, 명시적으로 허용해도 여전히 실행하지 않습니다." — r/ClaudeCode의 u/dfritter4
가장 날카로운 문제는 승인해도 거부를 뒤집을 수 없다는 점입니다. 여러 사용자는 작업을 승인했는데도 하네스가 실행을 거부하는 상황을 겪었다고 말합니다. 결국 manual mode로 전환하거나 터미널에서 직접 명령을 실행해야 합니다.
"manual로 다시 바꾸고, 에이전트에게 계속 진행하라고 말한 뒤, 직접 승인하고, 다시 auto로 돌아가야 했던 상황이 있었습니다." — r/ClaudeCode의 u/phoenixmatrix
분류기 장애는 안전성 판단에 따른 차단과는 별개의 문제입니다. 한 여러 프로젝트에 걸친 장애 사례에서 사용자들은 프로젝트 전반에 "The server-side auto mode classifier gave no verdict"라는 메시지를 봤습니다. 상태 페이지에는 장애가 표시되지 않았고, 서비스가 복구될 때까지 manual mode로 전환하는 것이 유일한 우회 방법이었습니다.
기본값 전환 논의에서는 품질에 대한 우려도 나왔습니다. 일부 사용자는 파괴적 명령보다 Claude가 자율적으로 실행되는 동안 과도하게 복잡한 설계를 선택하거나, 범위를 벗어나거나, 아키텍처를 부실하게 구성하는 점을 더 걱정합니다. 이런 불편이 반복되면서 일부 사용자는 git, 컨테이너, merge 전 검토만으로 보호되는 --dangerously-skip-permissions로 돌아가기도 합니다.
Claude auto mode를 유지하면서 중간 확인 지점 만들기
많은 개발자를 가장 놀라게 하는 기본 동작은 Claude auto mode에서 push와 pull request 생성이 허용된다는 점입니다. 작업 중인 브랜치뿐 아니라 기본 브랜치로의 push도 포함됩니다. 강제 push, commit에 포함된 비밀 정보, 히스토리 재작성은 계속 소프트 차단되며 명시적인 의도가 필요합니다. "저장소를 정리해줘"라는 말만으로는 force push가 허용되지 않지만, 정확한 작업을 지정하면 허용될 수 있습니다. production, release, gh-pages처럼 배포 대상을 나타내는 브랜치 이름은 각각 운영 배포로 판단됩니다.
push와 PR만 별도의 확인 대상으로 두고 나머지는 auto mode로 사용하려면, 분류기보다 먼저 평가되는 콘텐츠 범위 지정 ask 규칙을 추가합니다.
{ "permissions": { "ask": ["Bash(git push *)", "Bash(gh pr create *)"] } }절대 넘지 않아야 할 경계라면 대화 지시가 아니라 permissions.deny를 사용하세요. "검토할 때까지 push하지 마"라는 말은 컨텍스트가 압축될 때 사라질 수 있지만 ask 또는 deny 규칙은 유지됩니다. 특정 대상에 대한 거부가 반복된다면 분류기가 해당 인프라를 인식하지 못하는 것일 수 있습니다. 사용자 설정이나 관리형 설정의 autoMode.environment에 해당 대상을 등록하면 도움이 됩니다.
/permissions의 Recently denied 탭에서 거부된 작업을 확인하고 r을 눌러 하나를 다시 시도할 수 있습니다. 설정은 claude auto-mode config, claude auto-mode defaults, claude auto-mode critique로 점검하세요. 주의할 점도 두 가지 있습니다. Bash(npm test)처럼 범위가 좁은 allow 규칙은 분류기보다 먼저 처리되므로, 내부의 파괴적인 인자를 보지 못한 채 실행할 수 있습니다. v2.1.193 이상에서는 약간의 지연을 감수하고 autoMode.classifyAllShell을 true로 설정하면 모든 셸 명령을 분류할 수 있습니다. 또한 사용자 정의 allow, soft_deny, hard_deny, environment 목록은 "$defaults" 항목을 그대로 남겨두지 않는 한 기본 내장 목록 전체를 대체합니다.
필요할 때는 바로 끄기
Claude auto mode는 세션마다 한 번의 조작으로 전환할 수 있습니다. CLI에서는 Shift+Tab을 눌러 모드를 순환하고, 데스크톱 앱에서는 모드 드롭다운을 사용하세요. 세션을 시작할 때 claude --permission-mode manual을 지정하는 방법도 있습니다. 이 변경은 현재 세션에만 적용됩니다.
manual mode를 영구적인 기본값으로 고정하려면 사용자 설정의 ~/.claude/settings.json에 다음 내용을 저장합니다.
{ "permissions": { "defaultMode": "manual" } }v2.1.200 이상에서 manual은 default의 별칭입니다. 저장소 수준의 .claude/settings.json에서는 auto mode를 허용하거나 고정할 수 없습니다. 여기에 설정한 defaultMode: auto와 bypassPermissions는 무시되므로, opt-in 또는 opt-out 설정은 사용자 설정이나 관리형 설정에서 해야 합니다. 조직 관리자는 관리형 설정의 defaultMode로 조직 기본값을 고정할 수 있습니다. 또는 permissions.disableAutoMode를 "disable"로 설정해 auto mode 자체를 제거할 수 있으며, 이 설정은 v2.1.251부터 이미 실행 중인 세션에도 적용됩니다. useAutoModeDuringPlan이 켜져 있으면 plan mode 중에도 셸 명령을 auto-mode 분류기가 검토합니다. auto mode를 사용할 수 있는 환경에서는 이것이 기본값입니다.
그대로 둘까, manual mode로 고정할까?
열정이 아니라 작업이 초래할 수 있는 영향 범위에 따라 모드를 정하세요. 혼자 하는 실험, 격리된 로컬 리팩터링, 의존성 업데이트, 테스트 생성, diff와 테스트 스위트를 통과 조건으로 삼는 문서 정리는 auto mode와 잘 맞습니다. 공유 팀 저장소에서는 전제 조건이 하나 더 필요합니다. 보호 경로와 비밀 정보 및 배포 매니페스트에 대한 hard deny를 설정하고, 도입 전에 샌드박스나 폐기 가능한 브랜치를 합의해야 합니다.
| 작업 흐름 | 권장 모드 | 먼저 설정할 보호 장치 |
|---|---|---|
| 개인 탐색, 되돌릴 수 있는 수정 | Auto mode | Recently denied 검토 + r 재시도 습관 |
| 팀 저장소의 일반 기능 작업 | push 확인 지점을 둔 Auto mode | git push *와 gh pr create *에 ask 적용 |
| 운영 배포, IAM, 비밀 정보, 장애 대응 | 수동 또는 plan mode + 사람의 diff 검토 | 절대 넘지 않을 경계에 deny 규칙 적용 |
| 규제 대상 또는 HIPAA 적격 세션 | Manual (auto는 전환 가능한 상태로 유지) | 관리형 defaultMode + 변경 권한 감사 |
CLI와 에디터 통합 도구를 같은 릴리스 계열로 맞추고, 관리형 기본값을 하나 정한 뒤 보호 경로와 hard deny를 정의하세요. 첫 실행은 가짜 데이터를 사용하는 devcontainer나 격리된 VM에서 진행하고, merge 전에는 git diff, 테스트 실행, 실제 리뷰를 계속 관문으로 유지하는 편이 좋습니다. Anthropic에 따르면 5월 중순 이후 세션의 약 10%에서 분류기 거부가 발생했습니다.
FAQ
Claude auto mode를 사용하면 토큰 비용이 더 드나요?
Anthropic 기준으로 2026년 8월 7일부터 Pro, Max, Team 요금제에는 추가 요금이 없습니다. Enterprise, API, 클라우드 플랫폼 세션에서는 클라이언트 측 분류기 호출이 여전히 토큰 사용량에 포함됩니다.
auto mode가 정상적인 작업을 차단하면 어떻게 해야 하나요?
/permissions를 열고 Recently denied 탭을 확인한 다음 r을 눌러 거부된 작업을 다시 시도하세요. 같은 대상이 계속 거부된다면 신뢰할 수 있는 인프라를 autoMode.environment에 등록합니다.
main 브랜치로 push했는데 왜 승인 없이 실행됐나요?
auto mode에서는 작업 중인 저장소의 모든 브랜치, 기본 브랜치까지 push가 기본적으로 허용됩니다. 확인 지점을 강제로 만들려면 permissions.ask에 Bash(git push *)를 추가하고, 절대 허용하지 않을 경계라면 permissions.deny에 추가하세요.
auto mode를 운영 환경 작업에 사용해도 안전한가요?
Anthropic은 습관적인 클릭 승인보다 auto mode가 안전하다고 설명하지만, 위험도가 높은 운영 인프라 변경에는 여전히 사람의 검토를 권장합니다. 되돌릴 수 있는 작업에는 auto mode를 사용하고, 배포·비밀 정보·IAM에는 manual 또는 plan mode를 유지하세요.
안전성에 따른 거부와 분류기 장애를 어떻게 구분하나요?
안전성 거부는 차단 이유를 설명하며 Claude가 대체 경로를 제안하는 경우가 많습니다. 반면 "no verdict" 장애는 여러 프로젝트에서 쓰기 작업과 Bash 작업을 한꺼번에 막습니다. /status에서 auto-mode 서버 행을 확인하고, 장애가 의심되면 manual mode로 전환하세요.
Claude Code와 Claude 앱에서 auto mode는 똑같이 작동하나요?
분류기 메커니즘은 공유하지만 적용 시점은 다릅니다. Claude Code가 8월 14일 먼저 변경됐고, Claude 앱은 다음 주에 이어서 적용됩니다. Enterprise와 API 영역은 관리자가 안내받을 때까지 계속 opt-in 방식으로 운영됩니다.