클로드코드 권한 모드 4개 아니라 사실 6개, Auto와 Plan 차이

클로드코드 권한 모드는 흔히 아는 것보다 하나 더, 둘 더 있습니다. Shift+Tab을 눌러 순환하면 Manual, Accept edits, Plan, 조건이 맞으면 Auto까지 서너 개가 돌아가는데, 공식 문서 기준 실제 권한 모드는 여섯 개입니다. 순환 목록에 아예 등장하지 않는 두 개가 더 있어서, 대부분은 그 존재조차 모르고 지나갑니다.
이 모드가 하는 일은 하나입니다. "클로드가 파일을 고치거나 명령을 실행하기 직전에, 얼마나 자주 멈춰서 물어볼 것인가." 그런데 이 다이얼을 잘못 맞추면 승인 프롬프트를 백 번 눌러 대거나, 반대로 열두 개 파일이 조용히 바뀐 걸 나중에 발견하게 됩니다.
| "Shift+Tab 누르면 나오는 게 전부 아니었어?" "auto 모드는 그냥 위험한 거 아니야?" "plan 모드랑 기본 모드랑 뭐가 다르지?" "dangerously-skip-permissions 그게 auto랑 같은 거였나?" |
저도 한동안 Shift+Tab으로 돌아가는 세 개가 전부인 줄 알았습니다. 그런데 스크린샷 하단에 manual mode on이라고 뜨는 걸 보고 "이거 원래 default 아니었나?" 하고 문서를 뒤져 보니, 이름이 바뀐 것도, 숨은 모드가 있는 것도 그때 알았습니다.
그래서 이 글에서는 여섯 개 모드를 하나씩 정리하고, 마지막에 "언제 무엇을 쓰면 되는지"를 표로 묶어 두겠습니다. 기준은 2026년 7월 현재 공식 문서이며, 클로드코드는 업데이트가 잦아 명칭·조건은 버전에 따라 달라질 수 있습니다.
목차
- Shift+Tab은 사실 권한 다이얼입니다
- Manual 모드 - 이름만 바뀐 예전 기본값
- Accept edits 모드 - 파일 수정만 알아서
- Plan 모드 - 코드 건드리기 전 계획부터
- Auto 모드 - 분류기가 대신 판단
- 순환에 안 나오는 나머지 두 개
- 여섯 모드 한눈 비교와 선택 기준
- 결국 얼마나 손을 뗄 것인가
1. Shift+Tab은 사실 권한 다이얼입니다
클로드코드는 파일을 쓰거나, 셸 명령을 돌리거나, 네트워크 요청을 보낼 때마다 잠깐 멈춰서 승인을 요청합니다. 이 "멈춤"이 얼마나 자주 일어나느냐를 정하는 게 권한 모드입니다. 읽기 작업(파일 읽기, 검색, 디렉터리 나열)은 되돌릴 게 없으니 어느 모드든 묻지 않습니다. 상태를 바꾸는 순간부터 모드마다 반응이 갈립니다.
터미널에서는 Shift+Tab을 누를 때마다 default → acceptEdits → plan 순으로 순환합니다. 여기까지가 대부분의 사람이 보는 전부입니다. 그런데 이 셋 말고도 조건이 맞으면 순환에 슬쩍 끼어드는 Auto가 있고, 순환에는 절대 안 나오고 플래그로만 켜지는 두 개가 더 있습니다. 그래서 실제 모드는 여섯 개인데 체감은 서너 개인 겁니다.
| 💡 순환에 뭐가 뜨느냐는 계정마다 다릅니다 기본 순환은 세 개지만, Auto는 요건을 충족한 계정에서만 순환에 나타나고, bypass는 해당 플래그로 세션을 시작해야 순환에 들어옵니다. dontAsk는 순환에 아예 등장하지 않고 플래그로만 켤 수 있습니다. |
2. Manual 모드 - 이름만 바뀐 예전 기본값

가장 보수적인 기본 모드입니다. 읽기는 자유롭게 하지만, 파일을 고치거나 대부분의 Bash 명령, 네트워크 요청처럼 뭔가를 바꾸는 행동은 전부 하나씩 물어봅니다. 처음 만지는 코드베이스거나, 운영에 가까운 민감한 작업일 때 적합합니다.
여기서 헷갈리기 쉬운 지점이 이름입니다. 이 모드의 설정값은 지금도 default인데, CLI와 확장·데스크톱 앱에서 표시되는 라벨은 Manual로 바뀌었습니다. 스크린샷에서 본 manual mode on이 바로 이겁니다. 설정 파일이나 SDK에서는 여전히 default를 쓰고, CLI에서는 manual을 별칭으로 받아 줍니다. Manual 라벨과 manual 별칭은 CLI v2.1.200부터 적용됐습니다.
| 📌 default = Manual, 같은 모드입니다 문서·블로그마다 "default", "ask", "approval", "Manual"로 제각각 부르는데 전부 이 하나를 가리킵니다. 설정값 default, 표시 라벨 Manual, CLI 별칭 manual로 기억하면 됩니다. |
3. Accept edits 모드 - 파일 수정만 알아서

설정값은 acceptEdits입니다. Manual이 하던 걸 그대로 하면서, 작업 디렉터리 안에서의 파일 생성·수정은 묻지 않고 승인합니다. 여기에 자주 쓰는 파일 계열 Bash 명령(mkdir, touch, mv, cp, rm, sed 등)도 작업 디렉터리 안이라면 자동으로 통과됩니다. 상태 표시줄에는 accept edits on이 뜹니다.
대신 작업 디렉터리 밖 경로, 보호 경로(.git이나 셸 설정 파일 등), 그리고 위 목록에 없는 다른 Bash 명령은 여전히 물어봅니다. 인라인으로 하나씩 승인하기보다, 일단 클로드가 고치게 두고 git diff나 에디터로 나중에 몰아서 리뷰하고 싶을 때 쓰기 좋습니다.
4. Plan 모드 - 코드 건드리기 전 계획부터

설정값은 plan입니다. 클로드가 파일을 읽고 셸로 탐색은 하되, 소스는 절대 고치지 않습니다. 대신 "이렇게 바꾸겠습니다"라는 계획을 글로 정리해 내놓습니다. 큰 프로젝트나 낯선 코드베이스를 먼저 파악하고 방향을 맞춘 뒤 실제 수정에 들어가고 싶을 때 씁니다.
진입은 Shift+Tab으로 순환하거나, 프롬프트 앞에 /plan을 붙이면 됩니다. 계획이 준비되면 클로드가 어떻게 진행할지 선택지를 줍니다. 그대로 승인하고 Auto로 시작할지, 하나씩 수동 승인하며 갈지, 계획을 더 다듬을지 고를 수 있습니다. 계획을 승인하면 plan 모드에서 빠져나와 선택한 권한 모드로 전환되면서 실제 편집이 시작됩니다.
한 가지 알아 둘 점은, Auto 모드를 쓸 수 있는 계정이라면 계획 단계에서도 분류기가 붙어 읽기·검색 같은 안전한 명령을 자동으로 통과시킵니다. 다만 파일을 실제로 바꾸는 명령은 계획 단계 내내 막혀 있습니다.
5. Auto 모드 - 분류기가 대신 판단

설정값은 auto입니다. 여기서부터 성격이 확 달라집니다. 클로드가 승인 프롬프트 없이 계속 실행하되, 별도의 분류기(classifier) 모델이 각 행동을 실행 직전에 검사합니다. 요청 범위를 넘어서는 행동, 모르는 인프라를 건드리는 행동, 클로드가 읽은 적대적 콘텐츠에 휘둘린 듯한 행동을 걸러 냅니다. 상태 표시줄에는 auto mode on이 표시됩니다.
분류기가 기본적으로 막는 것들은 꽤 구체적입니다. curl | bash로 코드를 받아 실행하거나, 민감한 데이터를 외부로 보내거나, 운영 배포·마이그레이션을 돌리거나, force push를 하거나, terraform destroy 같은 파괴적 명령을 실행하는 식의 행동입니다. 반대로 작업 디렉터리 안의 파일 작업이나 락 파일에 선언된 의존성 설치, 읽기 전용 HTTP 요청 등은 기본 허용됩니다.
| 📌 Auto 모드는 편의지, 안전 보장이 아닙니다 공식 문서도 명시합니다. 분류기는 프롬프트를 줄여 줄 뿐, 민감한 작업의 리뷰를 대체하지 못합니다. 방향은 믿되 손은 완전히 놓지 말라는 뜻입니다. 참고로 분류기가 연속 3회 또는 누적 20회 차단하면 Auto가 멈추고 다시 하나씩 묻는 방식으로 돌아갑니다. |
Auto는 요건을 충족해야 쓸 수 있습니다. 요금제는 전 플랜에서 가능하지만 팀·엔터프라이즈는 관리자(Owner)가 먼저 켜 줘야 하고, 모델도 일정 버전 이상이어야 합니다. 이 조건은 버전마다 바뀌므로, 안 보인다면 일시적 장애가 아니라 요건 중 하나가 안 맞는 경우가 대부분입니다.
6. 순환에 안 나오는 나머지 두 개
여기까지가 대부분이 아는 범위입니다. 남은 둘은 성격이 정반대인데, 공통점은 Shift+Tab 순환에서는 볼 수 없다는 점입니다.
dontAsk - 미리 허용한 것만, 나머지는 전부 거절
설정값은 dontAsk입니다. 원래라면 물어봤을 도구 호출을 전부 자동으로 거절합니다. 미리 등록한 permissions.allow 규칙에 맞는 행동, 읽기 전용 Bash 명령, 훅이 승인한 호출만 실행하고 나머지는 그냥 막습니다. 사람에게 묻지 않으니 세션이 입력을 기다리며 멈추는 일이 없습니다. "무엇을 할 수 있는지 미리 못 박아 두고, 그 밖으로는 한 발도 못 나가게" 하는 CI 파이프라인이나 제한된 환경에 맞습니다. 켜려면 claude --permission-mode dontAsk처럼 플래그로 지정합니다.
bypassPermissions - 검사 자체를 끄는 마지막 카드
설정값은 bypassPermissions이고, --dangerously-skip-permissions 플래그와 같은 뜻입니다. 이름 그대로 승인 프롬프트와 안전 검사를 모두 꺼서, 보호 경로 쓰기까지 즉시 실행됩니다. 그래서 아까 Auto와 헷갈리기 쉬운데, 둘은 전혀 다릅니다. Auto는 분류기가 뒤에서 계속 걸러 주고, bypass는 거를 사람도 장치도 없습니다.
| 📌 bypass는 격리된 환경에서만 공식 경고가 붙어 있습니다. 컨테이너, VM, 인터넷 없는 개발 컨테이너처럼 클로드가 호스트를 망가뜨릴 수 없는 환경에서만 쓰라는 겁니다. 프롬프트 인젝션이나 의도치 않은 행동에 대해 아무 방어막이 없습니다. 그나마 rm -rf /나 rm -rf ~ 같은 명령은 이 모드에서도 회로 차단기처럼 한 번 물어봅니다. |
안전장치도 있습니다. 이 모드로 시작하지 않은 세션에서는 도중에 bypass로 들어갈 수 없고, 리눅스·맥에서는 root나 sudo로 돌리면 실행 자체를 거부합니다.
7. 여섯 모드 한눈 비교와 선택 기준
정리하면 이렇습니다. 왼쪽에서 오른쪽으로 갈수록 "묻지 않고 실행하는 범위"가 넓어지고, 그만큼 사람의 감시는 줄어듭니다.
| 모드 (설정값) | 묻지 않고 실행하는 것 | 적합한 상황 |
|---|---|---|
| Manual (default) | 읽기 전용 | 처음 쓸 때, 민감한 작업 |
| Accept edits | 읽기 + 파일 수정 + 기본 파일 명령 | 리뷰하면서 코드 다듬기 |
| Plan | 읽기 전용 (계획만 작성) | 코드 건드리기 전 탐색 |
| Auto | 거의 전부, 분류기가 뒤에서 검사 | 긴 작업, 프롬프트 피로 줄이기 |
| dontAsk | 미리 허용한 도구만 | 잠긴 CI·스크립트 |
| bypassPermissions | 전부, 검사 없음 | 격리된 컨테이너·VM 전용 |
실무에서 고를 때 저는 이렇게 나눕니다. 낯선 저장소를 처음 열었으면 Plan으로 지형부터 읽고, 방향이 맞으면 Accept edits로 넘어가 diff를 몰아 봅니다. 프롬프트를 계속 누르기 지겨운 긴 작업이면 Auto를 켜되 배포·삭제 구간에서는 다시 눈으로 확인합니다. dontAsk와 bypass는 사람이 붙어 있는 일반 작업용이 아니라, 각각 자동화 파이프라인과 완전 격리 환경이라는 특수 상황용이라고 선을 그어 두면 헷갈리지 않습니다.
| 💡 모드는 기준선, 규칙은 그 위에 얹는 것 여섯 모드는 출발점일 뿐이고, 그 위에 allow·ask·deny 규칙을 얹어 특정 도구만 콕 집어 미리 허용하거나 막을 수 있습니다. 또 bypassPermissions를 뺀 모든 모드에서 보호 경로(.git, 셸 설정 파일 등)로의 쓰기는 자동 승인되지 않습니다. |
8. 결국 얼마나 손을 뗄 것인가
여섯 모드를 한 줄로 꿰면 "클로드가 하려는 것"과 "클로드가 해 버린 것" 사이에 사람을 얼마나 세워 둘 것인가의 문제입니다. Manual은 매번 세우고, Accept edits는 파일 수정만 통과시키고, Plan은 계획 단계에서 한 번 세우고, Auto는 분류기로 대신 세우고, dontAsk는 규칙으로만 통과시키고, bypass는 아무도 안 세웁니다.
정답이 정해져 있진 않습니다. 얼마나 개입하고 싶은지, 그 작업이 되돌릴 수 있는 종류인지에 달려 있죠. 다만 "순환에 보이는 게 전부"라고 믿고 있었다면, 숨은 두 개까지 알고 나서 고르는 것과 모르고 default에 머무는 것은 작업 흐름이 꽤 달라집니다. 앞서 말했듯 명칭과 요건은 버전에 따라 바뀌니, 실제 적용 전에는 각자 환경에서 claude --help로 한 번 확인해 보는 편이 안전합니다.
자주 묻는 질문
Auto 모드와 bypassPermissions는 뭐가 다른가요?
둘 다 승인 프롬프트를 크게 줄이지만 방향이 반대입니다. Auto는 분류기 모델이 실행 직전에 위험한 행동을 걸러 내고, bypassPermissions는 그 검사 자체를 꺼서 아무것도 거르지 않습니다. 프롬프트는 줄이되 안전망을 원하면 Auto, 완전히 격리된 환경에서 속도만 필요하면 bypass입니다.
manual 모드와 default 모드는 다른 건가요?
같은 모드입니다. 설정값은 여전히 default이고, CLI·확장·데스크톱 앱에 표시되는 라벨만 Manual로 바뀌었습니다. CLI v2.1.200부터 manual을 별칭으로 입력할 수도 있습니다. 훅이나 SDK 설정에서는 default를 그대로 씁니다.
Shift+Tab을 눌러도 Auto가 안 보여요.
Auto는 요건을 충족한 계정에서만 순환에 나타납니다. 요금제 조건, 모델 버전, 팀·엔터프라이즈의 경우 관리자 활성화 여부 중 하나라도 안 맞으면 나오지 않습니다. 이건 일시적 오류가 아니라 요건 문제일 가능성이 큽니다.
dontAsk는 왜 순환에 안 나오나요?
dontAsk는 사람이 옆에서 승인하는 일반 작업이 아니라, CI나 스크립트처럼 무인 실행을 전제로 한 모드이기 때문입니다. 그래서 Shift+Tab 순환에는 아예 등장하지 않고 --permission-mode dontAsk 플래그로만 켤 수 있습니다.
🎲 추천 글 모음
AI가 너무 똑똑해서 미국 정부가 꺼버렸다 - 앤트로픽 미토스·페이블 5 중단 사태 총정리
"AI가 너무 위험해서 정부가 끄라고 했다는데, 그게 가능한 일인가요?""어제까지 잘 쓰던 인공지능이 갑자기 안 된다는데 무슨 일이죠?""앞으로 AI도 핵무기처럼 나라가 관리하게 되는 건가요?" 202
lsy7651.tistory.com
Claude 챗·코워크·코드 차이 - 같은 모델인데 왜 일하는 성격이 다를까 (2026)
"챗은 답이 정확한데 좀 느린 느낌이고…""코워크는 처음엔 답답한데 쓰다 보면 손발이 맞아.""코드는 일단 만들어 놓고 보는 스타일 아니야?""같은 Claude인데 왜 셋이 성격이 달라?" 요즘 동료들
devwar.tistory.com
Claude Fable 5 출시 정리 - Mythos급 모델, 가격, 6월 22일 무료 기간 (2026)
"Fable? Mythos? 이름이 왜 두 개야?""Opus보다 위 등급이 생겼다는 게 무슨 말이지?""제일 강한 모델인데 일부러 기능을 막아놨다고?""Pro 요금제로도 쓸 수 있는 거 맞아?" 2026년 6월 9일, Anthropic이 새 모
devwar.tistory.com
AI 개발 언어 1위는 왜 파이썬일까 - 느린데도 이긴 언어의 역설
AI 개발 언어 1위는 몇 년째 파이썬(Python)입니다. 그런데 정작 파이썬은 실행 속도가 느린 언어로 유명합니다. 인공지능과 머신러닝은 어마어마한 연산을 요구하는 분야인데, 하필 느린 파이썬이
devwar.tistory.com
AI 코딩 컨벤션 시대, 컨벤션 문서의 독자가 바뀌었다
AI 코딩 컨벤션이라는 말이 낯설게 들릴 수 있습니다. 코드 컨벤션은 원래 사람 팀원끼리 지키던 약속이었는데, 요즘은 그 규칙 문서를 읽는 쪽이 AI로 바뀌었습니다. CLAUDE.md, AGENTS.md 같은 파일이
devwar.tistory.com
'AI시대' 카테고리의 다른 글
| Supabase 특징 및 AI 백엔드 구축 시 생기는 변화 (0) | 2026.08.07 |
|---|---|
| AI 코딩 에이전트 goal·ultracode 명령어 정리 (0) | 2026.07.21 |
| AI 코딩 컨벤션 시대, 컨벤션 문서의 독자가 바뀌었다 (0) | 2026.07.13 |
| MAS(멀티 에이전트 시스템)란 무엇인가 - 모놀리식부터 AI 에이전트까지, 분산 아키텍처의 역사 (0) | 2026.07.07 |
| AI 개발 언어 1위는 왜 파이썬일까 - 느린데도 이긴 언어의 역설 (0) | 2026.07.06 |