08. 권한과 승인 모델

왜 권한이 핵심인가

Claude Code가 파일을 수정하거나, 셸 명령을 실행하거나, 네트워크 요청을 하려 할 때 — 기본적으로 멈추고 당신에게 승인을 묻습니다. 권한 모델은 "이 멈춤이 얼마나 자주 일어나는가"를 조절하는 장치입니다.

비유하자면, 권한 모드는 운전 보조의 신뢰 단계와 같습니다. 매 회전마다 확인받을 수도, 고속도로 구간만 알아서 달리게 둘 수도, 폐쇄된 테스트 트랙에서 완전 자율로 둘 수도 있습니다. 상황에 맞는 단계를 고르는 게 핵심입니다.

권한 모드

flowchart LR
    D[default<br/>매 행동 확인]:::safe --> A[acceptEdits<br/>편집 자동 승인]:::mid
    A --> Au[auto<br/>분류기가 검토 후 실행]:::mid
    Au --> B[bypassPermissions<br/>모든 검사 생략]:::danger

    P[plan<br/>읽기 전용]:::safe
    DA[dontAsk<br/>미승인은 조용히 거부]:::mid

    classDef safe fill:#A5D6A7,stroke:#43A047,color:#000
    classDef mid fill:#FFE082,stroke:#F9A825,color:#000
    classDef danger fill:#EF9A9A,stroke:#E53935,color:#000

모드 바꾸는 법

• 세션 중 Shift+Tab: default → acceptEdits → plan 순환 (현재 모드는 상태 표시줄에)
• auto·bypassPermissions·dontAsk는 기본 순환에 없고, CLI 플래그나 옵트인으로 추가됩니다
• 영구 기본값은 .claude/settings.json의 defaultMode:

```json

{ "permissions": { "defaultMode": "acceptEdits" } }

```

유효값: default, acceptEdits, plan, dontAsk, bypassPermissions

⚠️ 모드는 채팅으로 바꾸는 게 아닙니다. "권한 좀 풀어줘"라고 Claude에게 부탁하는 게 아니라, 위의 조작·설정으로 당신이 바꿉니다.

권한 규칙: 모드 위에 얹는 세밀 제어

모드가 큰 그림(baseline)이라면, 권한 규칙은 특정 도구를 콕 집어 미리 허용하거나 차단합니다. /permissions로 UI를 열거나 settings.json의 permissions에 직접 씁니다.

{
  "permissions": {
    "allow": ["Bash(npm run *)", "Bash(git commit *)"],
    "ask":   ["Bash(git push *)"],
    "deny":  ["Bash(rm *)", "Read(./.env)"]
  }
}

규칙 형식은 Tool 또는 Tool(지정자)입니다.

평가 순서: deny → ask → allow

flowchart TB
    Action[행동 발생]:::user --> Deny{deny 매칭?}:::danger
    Deny -->|예| Blocked[차단]:::danger
    Deny -->|아니오| Ask{ask 매칭?}:::mid
    Ask -->|예| Prompt[승인 요청]:::mid
    Ask -->|아니오| Allow{allow 매칭?}:::safe
    Allow -->|예| Run[실행]:::result
    Allow -->|아니오| ModeDefault[모드 기본 동작]:::agent

    classDef user fill:#FFE082,stroke:#F9A825,color:#000
    classDef danger fill:#EF9A9A,stroke:#E53935,color:#000
    classDef mid fill:#FFE082,stroke:#F9A825,color:#000
    classDef safe fill:#A5D6A7,stroke:#43A047,color:#000
    classDef result fill:#A5D6A7,stroke:#43A047,color:#000
    classDef agent fill:#80DEEA,stroke:#00ACC1,color:#000

deny가 항상 우선합니다. 첫 매칭 규칙이 이깁니다. 글롭(*)은 어느 위치에서나 쓸 수 있습니다: Bash(npm run *), Bash(git * main), Bash(* --version) 등.

⚠️ 흔한 실수들:

• 과소 권한: 계속 "Allow"만 누르면 의미가 없습니다. 반복 작업은 /permissions로 미리 허용하거나 acceptEdits 모드를 쓰세요.
• 무차별 허용: Bash(*)로 모든 Bash를 허용하지 마세요. Bash(npm run *)처럼 범위를 좁히세요.
• 인자 제한에 Bash 규칙 의존 금지: 예를 들어 curl을 특정 URL로만 제한하려는 시도는 깨지기 쉽습니다. URL 필터링은 WebFetch 도메인 규칙을 쓰세요.

auto 모드: 분류기가 지키는 자율 실행

auto 모드는 일상 권한 프롬프트 없이 Claude가 실행하게 하되, 별도의 분류기 모델이 각 행동을 사전 검토합니다. 요청 범위를 벗어나 권한을 확대하거나, 미인식 인프라를 건드리는 행동을 차단합니다.

핵심 동작과 한계:

• 분류기가 읽는 "경계(boundary)"는 규칙으로 저장되는 게 아니라 매번 대화 기록에서 다시 읽힙니다. 그래서 컴팩션이 그 메시지를 지우면 경계가 사라질 수 있습니다. 확실한 보장이 필요하면 경계 대신 deny 규칙을 쓰세요.
• 분류기가 연속 3회 또는 누적 일정 횟수 차단하면 auto 모드가 멈추고 다시 프롬프트로 돌아옵니다.
• -p 비대화형 모드에선 막힌 행동이 반복되면 물어볼 사람이 없으므로 세션이 중단됩니다.

bypassPermissions: 마지막 수단

모든 권한 검사를 건너뜁니다. CLI로는 claude --dangerously-skip-permissions. 반드시 컨테이너·VM·일회용 CI 러너처럼 Claude가 영구적 피해를 줄 수 없는 격리 환경에서만 쓰세요.

안전·편의 다이얼 맞추기

민감/낯선 작업    →  default (또는 plan으로 먼저 검토)
신뢰하는 개발 세션  →  acceptEdits + 좁은 allow 규칙
긴 자율 작업       →  auto (+ 핵심 금지는 deny로 못박기)
격리된 자동화      →  bypassPermissions (격리 환경 한정)

📌 deny 규칙으로 "절대 안 되는 것"(예: rm -rf, .env 읽기)을 못박아 두면, 어떤 모드에서도 그 선은 지켜집니다. 보안 설계는 23장에서 더 다룹니다.

이 장에서 배운 것

• 권한 모드는 "승인 멈춤이 얼마나 자주 일어나는가"를 조절한다: default·acceptEdits·plan·auto·dontAsk·bypassPermissions.
• 권한 규칙은 deny → ask → allow 순으로 평가되며 deny가 항상 우선, 첫 매칭이 이긴다.
• 모드는 Shift+Tab·CLI 플래그·defaultMode 설정으로 바꾸지, 채팅 부탁으로 바꾸지 않는다.
• auto 모드의 경계는 대화 기록에서 매번 읽히므로 컴팩션에 취약 — 확실히 막으려면 deny 규칙.
• bypassPermissions는 격리 환경에서만 쓰는 마지막 수단이다.

✍️ 확인 문제

1. 권한 규칙의 평가 순서는 무엇이며, 충돌 시 무엇이 이기나요?
2. "절대 rm 명령은 못 쓰게" 확실히 보장하려면 auto 모드의 경계와 deny 규칙 중 무엇을 써야 하나요? 왜죠?
3. bypassPermissions를 써도 되는 환경은 어떤 곳인가요?

🎉 2부 완료! 다음 장부터는 3부 프로젝트 설정입니다.
다음 장: 09. CLAUDE.md 메모리 파일