권한 모드란 무엇인가, 왜 한 번에 정해 두나
권한 모드(permission mode)는 클로드 코드에게 '내가 매번 확인해 주지 않아도 무엇을 실행해도 되는지'를 한 번에 정해 두는 설정이다. 클로드 코드는 파일을 읽고 고치고, 터미널 명령을 실행하고, 패키지를 설치하는 등 실제 작업을 하는데, 매 동작마다 사람에게 '이거 해도 됩니까'를 물으면 긴 작업일수록 승인하느라 붙어 있어야 한다. 권한 모드는 그 승인 기준을 미리 한 번 정해, 안전한 범위 안에서는 묻지 않고 진행하게 만든다.
설정은 간단하다. 클로드 코드 화면에서 shift 키를 누른 채 tab을 치면 모드가 순서대로 바뀐다. manual → acceptEdits → plan → auto 네 가지가 이 순환으로 넘어가고, 지금 어떤 모드인지는 화면 아래 상태바(status bar)에 표시된다. 나머지 두 모드(dontAsk, bypassPermissions)는 무인 실행이나 격리 환경 같은 특수한 경우에 쓴다.
핵심은 '모드를 작업에 맞추는' 것이다. 코드를 한 줄씩 눈으로 확인하며 짜는 초반에는 많이 묻는 모드가 안전하고, 방향이 잡혀 반복 작업만 남았을 때는 덜 묻는 모드가 빠르다. 아래에서 여섯 모드를 '얼마나 자동으로 허용하는가' 순서로 짚는다.
| 모드 | 무엇을 자동으로 하나 | 언제 쓰나 |
|---|---|---|
| manual | 읽기만. 그 외 모든 동작은 매번 물음 | 한 동작씩 확인하며 신중하게 진행할 때 |
| acceptEdits | 읽기 + 파일 편집 + 흔한 파일시스템 명령 | 코드를 반복 수정하고 나중에 몰아서 리뷰할 때 |
| plan | 읽기·조사·제안만. 편집은 안 함 | 실행 전에 계획부터 받아 볼 때 |
| auto | 전부 실행하되 분류기가 위험 동작을 사전 차단 | 손을 떼고 맡기는 기본값 |
| dontAsk | 사전 승인된 도구만. 나머지는 조용히 자동 거부 | CI·야간 배치 등 승인할 사람이 없을 때 |
| bypassPermissions | 모든 검사를 건너뜀 | 격리된 컨테이너·VM 안에서만 |
매번 묻는 쪽 — manual과 plan
manual은 가장 보수적인 모드다. 클로드 코드가 파일을 읽는 것만 묻지 않고 허용하고, 파일을 고치거나 명령을 실행하는 등 그 외의 모든 동작은 실행 전에 사람에게 확인을 받는다. 무엇이 바뀌는지 하나하나 눈으로 보고 승인하고 싶을 때, 또는 낯선 코드베이스를 조심스럽게 다룰 때 적합하다.
plan(플랜 모드)도 읽기만 한다는 점은 같지만 목적이 다르다. plan은 코드를 조사해 '무엇을 어떻게 바꾸겠다'는 계획을 세워 제안할 뿐, 실제로 파일을 편집하지는 않는다. 큰 작업을 시작하기 전에 클로드가 먼저 코드를 훑고 실행 계획을 내놓게 하고, 그 계획을 읽어 본 뒤 방향을 잡아 주는 용도다. 계획이 촘촘할수록 이후 실행에서 어긋날 여지가 줄어든다.
리뷰를 뒤로 미루는 쪽 — acceptEdits
acceptEdits는 읽기와 파일 편집, 그리고 자주 쓰는 파일시스템 계열 터미널 명령까지 묻지 않고 진행한다. 클로드가 코드를 고치는 동안 매번 승인 버튼을 누를 필요 없이 흐름을 이어 가고, 사람은 결과가 나온 뒤에 한꺼번에 검토한다.
그래서 acceptEdits는 '지금은 빠르게 반복하고, 검토는 나중에'라는 작업 방식에 맞는다. 이미 방향이 정해진 코드를 여러 번 다듬을 때 특히 효율적이다. 다만 편집을 사후에 확인하는 구조이므로, 바뀐 내용을 나중에 반드시 되짚어 봐야 한다는 전제가 따라온다.
핸즈오프의 기본값 — auto 모드와 분류기
손을 떼고 맡기는 상황에서 가장 먼저 고려할 모드는 auto다. auto 모드에서 클로드는 사람에게 묻지 않고 동작을 실행하지만, 그 앞단에 별도의 분류기 모델(classifier)이 매 동작을 실행 직전에 검사한다. 분류기가 위험하다고 판단한 동작만 가로막고, 나머지 일상적인 작업은 그대로 통과시킨다. 즉 '전부 자동'이되 위험한 것만 골라 멈추는 구조다.
분류기가 막는 것은 '요청 범위를 넘어서 판을 키우는' 동작이다. 예를 들어 운영 환경 배포와 데이터베이스 마이그레이션, 강제 푸시(force push), 내려받은 코드를 곧바로 셸로 파이프해 실행하는 것, 민감한 데이터를 외부로 보내는 것, 세션에 필요한 파일을 지워 버리는 것 등이다. 반대로 통과시키는 것은 일상 작업이다. 내 프로젝트 안의 로컬 편집, 잠금 파일(lockfile)에 적힌 의존성 설치, 읽기 전용 요청, 내 브랜치로의 푸시 같은 것들이다.
auto는 shift+tab 순환의 마지막 자리에 있어 손쉽게 켤 수 있고, 상태바로 지금 auto인지 확인할 수 있다. '핸즈오프의 기본값'이라 부르는 이유는, 사람이 계속 붙어 승인하지 않아도 위험한 경계만 분류기가 지켜 주기 때문이다.
분류기의 맹점과 stop hook
auto의 분류기에는 분명한 한계가 있다. 분류기는 '의도'를 지킬 뿐, 코드가 실제로 맞게 동작하는지는 보지 않는다. 예를 들어 클로드에게 인증 로직을 리팩터링하라고 시켰는데 결과가 깨진 인증 코드라면, 분류기는 이를 그냥 통과시킨다. '깨진 것'은 '위험한 것'이 아니기 때문이다.
그래서 auto는 테스트를 돌리는 stop hook과 함께 쓰는 것이 정석이다. stop hook은 클로드가 한 차례 작업을 마친 시점에 자동으로 실행되는 검사로, 여기에 테스트 실행을 걸어 두면 auto가 '무엇을 하려는지(의도)'를 지키는 동안 hook이 '코드가 실제로 도는지(정확성)'를 확인한다. 의도는 분류기가, 정확성은 hook이 나눠 맡는 셈이다.
auto의 안전장치는 아직 발전 중이라, 무엇을 막고 무엇을 허용하는지의 목록은 계속 바뀐다. 실제로 auto를 쓸 때는 공식 문서에서 현재의 차단·허용 목록을 확인하는 것이 좋다.
{
"hooks": {
"Stop": [
{ "hooks": [ { "type": "command", "command": "npm test" } ] }
]
}
}무인 파이프라인은 dontAsk, 격리 환경은 bypassPermissions
dontAsk는 사람이 승인해 줄 수 없는 자동화 상황을 위한 모드다. 미리 승인해 둔 도구만 실행을 허용하고, 그 목록에 없는 동작은 사람에게 묻지 않고 곧바로 자동 거부한다. CI 파이프라인, 예약 작업, 밤새 도는 배치처럼 옆에 사람이 없는 상황에서, 아무도 눌러 주지 않을 승인 창에 걸려 멈추는 대신 파이프라인이 계속 흐르게 한다.
bypassPermissions는 모든 검사를 건너뛴다. 클로드 코드의 '위험을 무릅쓰고 권한 확인을 건너뛰는'(dangerously-skip-permissions) 설정과 같은 것으로, 분류기도 승인도 없이 무엇이든 실행한다. 그만큼 위험하므로 격리된 컨테이너나 가상 머신(VM) 안에서만 돌려야 한다. 내 실제 작업 환경에서 상시로 쓰는 모드가 아니다.
결론 — 작업에 모드를 맞춘다
권한 모드는 여러 가지가 있지만 매일 쓰는 것들은 shift+tab 순환으로 닿는다. 손을 떼고 맡기는 기본값은 auto이고, 그 안전은 두 겹으로 지켜진다. 실행 전에는 분류기가 의도를 검사하고, 작업을 마친 뒤에는 stop hook이 코드가 실제로 도는지 확인한다.
옆에 승인할 사람이 없는 무인 파이프라인은 dontAsk가 맡고, 모든 검사를 건너뛰는 bypassPermissions는 격리된 컨테이너와 VM 안에서만 쓴다. 결국 하나로 접힌다. 얼마나 손을 뗄지를 배짱이 아니라 작업에 맞춰 정하고, 그 작업에 맞는 권한 모드를 고르면 된다.