작업을 길게 돌릴 때, 저는 그냥 auto 모드로 둡니다. 일일이 안 물어보니 편하거든요.

그런데 어느 순간 깨달았습니다. 이 auto가 정확히 뭘 하는지 모르고 켜고 있었다는 걸요.

모드를 바꾸는 방법은 간단합니다. 입력칸에서 Shift+Tab을 누르면 화면 아래 표시가 바뀝니다. 어려운 건 언제 어느 걸 켜느냐죠. 이 글은 그 이야기입니다 — 각 모드가 뭘 하고, 어떤 상황에 맞는지요.

모드 = 얼마나 맡길지 정하는 손잡이

Claude가 파일을 고치거나 명령을 실행하려 할 때, 멈춰 서서 "해도 됩니까?" 하고 묻습니다. 모드는 그 묻는 빈도를 정합니다.

공식 문서도 같은 틀로 설명합니다.

Each mode makes a different tradeoff between convenience and oversight.

(모드는 저마다 편의와 감독 사이에서 다른 절충을 합니다.)

한쪽 끝은 건건이 내가 확인하는 쪽(감독), 다른 쪽은 거의 다 맡기는 쪽(편의)입니다. 작업이 민감하면 감독 쪽으로, 방향을 믿으면 편의 쪽으로 손잡이를 돌립니다.

평소 화면 순환에 도는 모드는 넷입니다 (특수 상황용으로 둘이 더 있는데, 뒤에서 짚습니다).

Shift+Tab을 누를 때마다 이 사이를 돕니다. (auto는 조건을 갖춰야 이 순환에 끼고, 못 갖추면 셋만 돕니다 — 조건은 맨 아래. 또 순환 순서는 맡김 세기 순이 아닌데, 이건 뒤에서 다시 짚겠습니다.)

브레인스토밍·탐색이면 — plan (⏸)

처음 보는 코드, 큰 작업의 시작. 바로 고치게 두기보다 먼저 방향을 잡고 싶을 때가 있습니다.

plan 모드는 Claude가 읽고 살펴보기만 하고, 소스는 건드리지 않습니다. 대신 "이렇게 하겠습니다" 하는 계획을 내놓습니다.

Plan mode tells Claude to research and propose changes without making them.

(plan 모드는 Claude에게 바꾸지는 말고, 조사해서 변경안을 제안하라고 시킵니다.)

저는 브레인스토밍 단계에선 plan으로 두고 쓰는 편입니다. 파일에 바로 손대기 시작하면 엉뚱한 데로 가서 일이 커질 수 있으니까요.

계획이 마음에 들면 그 자리에서 실행으로 넘어갑니다. 이때 바로 auto로 갈지, 편집만 맡기는 accept edits로 갈지, 하나씩 확인하는 default로 갈지 고를 수 있습니다. 그래서 보통 제 흐름은 plan으로 짜고 → auto로 돌린다입니다.

작업을 돌릴 때 — auto (⏵⏵). 그런데 이게 뭐냐

방향이 정해졌고, 길게 돌려야 하는 작업. 매번 확인을 누르는 게 일이 됩니다.

저는 이럴 때 auto로 둡니다. 문서가 꼽는 용도도 같습니다 — "긴 작업, 프롬프트 피로 줄이기(Long tasks, reducing prompt fatigue)".

문제는, "다 자동 승인"이라고만 알고 켜기 쉽다는 겁니다. auto는 그냥 풀어주는 게 아닙니다.

A separate classifier model reviews actions before they run, blocking anything that escalates beyond your request, targets unrecognized infrastructure, or appears driven by hostile content Claude read.

(별도의 AI(분류기 모델)가 실행 직전에 가로채 세 가지를 막습니다 — 시킨 범위를 넘는 행동(파일 하나 고치랬는데 폴더째 지우려 함), 평소 안 쓰던 외부 서버·시스템을 건드리는 행동, 읽어 들인 글·웹페이지에 몰래 심긴 지시에 끌려가는 행동.)

쉽게 말해, 맡기되 감독관을 한 명 붙이는 것입니다. 일상 작업(작업 폴더 안 편집·명령, 의존성 설치, 읽기)은 자동으로 통과시키되, 프로덕션 배포·강제 푸시(force push)·클라우드 대량 삭제·curl | bash처럼 되돌리기 어려운 행동은 기본으로 막아 세웁니다. 통과가 기본이 아니라, 위험한 부류엔 처음부터 차단선이 그어져 있는 셈이죠. 게다가 AI에게 "이건 하지 마"라고 말해둔 선도 지킵니다. 단, 이 감독관은 명백히 위험한 행동을 거를 뿐, 모든 실수를 잡아주진 않습니다.

⏵⏵가 두 개입니다 — accept edits와 auto

여기서 헷갈리는 지점. Shift+Tab을 돌리다 보면 ⏵⏵가 두 번 나옵니다. accept edits와 auto, 둘 다 같은 화살표를 답니다. 둘은 옆 글자로 구분합니다 — accept edits on인지 auto mode on인지 보세요.

순서로 보면 accept edits가 먼저 있던 모드고, auto는 나중에 들어왔습니다. 같은 아이콘을 달았지만 하는 일이 다릅니다.

구분accept editsauto
자동 승인 범위파일 편집 + 한정된 파일 정리 명령(mkdir 폴더 만들기·rm 지우기·mv 옮기기·cp 복사 등), 작업 폴더 안에서만모든 도구 호출(단, 파괴적 행동은 차단)
임의 셸 명령(한 줄짜리 명령)여전히 물어봄자동(감독관이 검토)
거르는 방식미리 정한 규칙 목록그때그때 판단(감독관 AI)

한 줄로: accept edits는 "이 편집들은 통과"라고 목록으로 정해둔 것이고, auto는 "해도 되나"를 그때그때 판단해서 거릅니다.

목록에 rm(지우기)이 있어 놀랄 수 있지만, accept edits도 작업 폴더 밖 파일은 못 건드립니다 — 자동으로 지워지는 건 지금 일하는 폴더 안에 한합니다.

그럼 accept edits는 언제? 편집은 맡기되, 명령 실행은 내 눈으로 보고 싶을 때. 문서 표현으로는 "나중에 에디터나 git diff로 변경을 검토하려는 경우"입니다.

건건이 보고 싶으면 — default (표시 없음)

아무 표시도 없는 기본 모드입니다. 읽기 말고는 다 물어봅니다. 파일 편집도, 명령도 매번 확인합니다.

위험한 변경이 섞여 있거나, Claude가 낯선 명령을 쓸 것 같을 때. 어떤 작업을 처음 맡겨보는 때. 문서가 꼽는 용도 그대로 "시작할 때, 민감한 작업(Getting started, sensitive work)"입니다.

가장 느리지만, 가장 안전합니다.

bypass — 이런 게 있는데, 웬만하면 쓰지 마세요

숨겨져 있는 모드가 하나 더 있습니다. bypassPermissions.

평소엔 안 보입니다. Shift+Tab 기본 순환에 없고, --dangerously-skip-permissions 같은 플래그로 켜야 나타납니다. 이름에 "dangerously(위험하게)"가 들어가는 건 우연이 아닙니다.

이 모드는 프롬프트도 안전검사도 끕니다. 막아주는 건 둘뿐입니다 — 미리 "이건 물어"라고 정해둔 규칙, 그리고 컴퓨터 전체나 개인 폴더를 통째로 지우는 것 같은(rm -rf /·rm -rf ~) 누가 봐도 파국인 명령. 그 외엔 가드레일이 없다고 보면 됩니다.

핵심 차이는 auto와 나란히 놓으면 드러납니다. auto엔 감독관(분류기)이 있고, bypass엔 없습니다. 그래서 공식 문서가 직접 이렇게 권합니다.

bypassPermissions offers no protection against prompt injection or unintended actions. For background safety checks with far fewer permission prompts, use auto mode instead.

(bypassPermissions는 프롬프트 인젝션이나 의도치 않은 행동을 전혀 막지 못합니다. 프롬프트를 훨씬 줄이면서 백그라운드 안전검사를 원한다면, 대신 auto 모드를 쓰세요.)

여기서 "프롬프트 인젝션"은, 쉽게 말해 누가 악의로 끼워 넣은 지시에 AI가 끌려가는 일입니다. auto는 그걸 걸러줄 감독관이 있고, bypass는 없다는 뜻이죠.

쓸 자리가 아예 없진 않습니다 — 인터넷이 끊긴 컨테이너나 일회용 VM처럼, 망가져도 버리면 그만인 격리된 환경. (평소 쓰는 노트북·작업 PC는 여기 해당하지 않습니다.) 거기까지입니다. 일반 작업에선 auto가 더 나은 선택입니다.

그래도 맡겼다 꼬이면? 같은 대화 안에서라면 /rewind로 이전 시점으로 되감을 수 있습니다 — 대화도, Claude가 고친 코드도요. 단, 선이 있습니다. 명령으로 지우거나 옮긴 파일(rm·mv 같은 한 줄 명령)은 되돌아오지 않습니다 — /rewind는 Claude가 편집 기능으로 직접 고친 것만 기록하거든요. 이미 외부로 나간 변경(push·배포)도 마찬가지고요. 특히 bypass는 그런 명령이 거침없이 도니, 격리 환경을 권하는 이유입니다. (어디까지 되돌아오는지는 /rewind 글에서 따로 다뤘습니다.)

그래서, 언제 뭘 켜나

맡기기 전에 저는 두 가지만 봅니다.

하나, 중간에 내가 또 봐야 할 일인가? 그렇다면 감독 쪽으로(plan·default). 아니라면 편의 쪽으로(accept·auto).

둘, 꼬이면 되돌릴 수 있나? 되돌릴 안전망(git 커밋·격리 환경, 같은 대화 안이라면 /rewind — 단 명령으로 지운 것·외부 변경은 못 되돌림)이 있으면 마음 편히 한 칸 더 맡깁니다.

저는 이렇게 씁니다. (정답은 아닙니다. 여러분만의 방법을 찾아보세요.) 탐색은 plan, 돌릴 땐 auto. 위험하면 default로 내려놓고, 편집만 맡기고 싶으면 accept edits. 저는 bypass는 안 씁니다.

참고 — 모드 한눈에, 그리고 켜는 법

화면 표시모드묻지 않고 되는 것용도(문서)
(없음)default읽기만시작할 때·민감한 작업
⏵⏵ accept edits onacceptEdits읽기·편집·한정 파일 명령(작업 폴더 안)검토하며 코드 반복 수정
⏸ plan mode onplan읽기만(편집 안 함)바꾸기 전 코드 탐색
⏵⏵ auto mode onauto대부분 자동, 파괴적 행동은 차단긴 작업·프롬프트 피로 줄이기
—bypassPermissions전부(안전검사 없음)격리된 컨테이너·VM에서만

(dontAsk라는 모드도 하나 더 있는데, 미리 허용한 것만 실행하는 CI·스크립트용이라 평소 화면엔 안 나옵니다.)

켜는 법. 대화를 켜 둔 동안엔 Shift+Tab으로 default → accept edits → plan을 순환합니다(맥·윈도우·리눅스 동일). auto는 조건을 갖추면 plan 뒤에 붙고, 처음 갈 때 한 번 동의를 묻습니다 — 조건을 못 갖추면 순환에 아예 안 나타나니, 안 보여도 고장이 아닙니다. plan은 프롬프트 앞에 /plan만 붙여도 됩니다. 시작할 때부터 한 모드로 켜고 싶으면, Claude Code를 켜는 명령에 옵션을 붙입니다 — 꺾쇠 자리에 모드 이름을 넣어 claude --permission-mode plan처럼요. 평소엔 Shift+Tab이면 충분합니다.

Shift+Tab 순서(default → accept edits → plan → auto)는 "맡김 세기" 순서와 똑같지 않습니다. plan은 오히려 가장 적게 맡기는 쪽인데(읽기만), 순환상 가운데에 있죠. 순서로 외우기보다 상황으로 고르는 편이 낫습니다.

참고한 문서