[Claude Code #3] 권한 관리 총정리, /permissions와 모드 순환

AI 코딩 도구를 쓰다 보면 딜레마가 하나 생깁니다. 매번 허락을 구하면 번거롭고, 다 풀어 주자니 git push나 rm -rf가 무섭죠.

Claude Code는 이 균형을 권한 규칙으로 풉니다. 어떤 명령은 조용히 통과시키고, 어떤 명령은 꼭 물어보고, 어떤 명령은 아예 막는 식이에요.

지난 Claude Code 2편에서 다룬 계획 모드도 이 권한 시스템 위에서 돌아갑니다. 이번 편에서 전체 그림을 정리할게요.

기본 동작: 무엇을 물어보나

공식 권한 문서 기준으로, 도구 종류마다 기본 규칙이 다릅니다.

파일 읽기나 검색 같은 읽기 전용 도구는 작업 디렉터리 안에서 승인 없이 돕니다.

셸 명령은 원칙적으로 승인이 필요합니다. 단, 내장된 읽기 전용 명령 집합은 예외예요.

파일 수정은 항상 물어봅니다. “다시 묻지 않기”를 골라도 세션이 끝나면 초기화돼요. 반면 셸 명령의 “다시 묻지 않기”는 저장소별 규칙으로 저장돼 다음 세션에도 유지됩니다.

/permissions로 규칙 보기

세션에서 /permissions를 입력하면 현재 적용 중인 규칙 목록이 열립니다. 각 규칙이 어느 settings.json에서 왔는지도 같이 보여 줍니다.

규칙은 세 종류입니다.

• allow: 묻지 않고 실행을 허용
• ask: 시도할 때마다 확인을 요구
• deny: 실행 자체를 차단

평가 순서가 전부입니다

규칙이 겹치면 어떻게 될까요? 순서는 deny → ask → allow이고 먼저 걸리는 규칙이 이깁니다.

중요한 건 구체성이 순서를 못 바꾼다는 점입니다. Bash(aws *)를 deny에 넣으면, allow에 Bash(aws s3 ls)를 아무리 구체적으로 적어도 차단됩니다.

deny 규칙은 예외를 허용하지 않습니다. “aws는 다 막되 s3 조회만 허용” 같은 구성은 불가능하니 규칙을 좁게 쪼개야 해요.

하나 더, deny에 괄호 없이 도구 이름만 적으면(예: Bash) 그 도구가 Claude의 컨텍스트에서 아예 사라집니다. Bash(rm *)처럼 범위를 좁힌 규칙은 도구는 남기고 해당 호출만 막습니다.

규칙 문법 빠르게 훑기

규칙은 도구 또는 도구(지정자) 형태입니다. Bash 규칙은 * 와일드카드를 지원하고 위치도 자유롭습니다.

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

명령 끝에 오는 별표 앞에 공백이 있으면(Bash(ls *)) 단어 경계를 지킵니다. ls -la는 매칭되지만 lsof는 안 걸려요. 공백 없는 Bash(ls*)는 lsof까지 매칭됩니다.

git status && npm test 같은 복합 명령은 하위 명령 각각이 규칙에 맞아야 통과합니다. Bash(safe-cmd *)를 허용해도 safe-cmd && other-cmd는 못 지나갑니다.

파일 경로 규칙은 Read(경로)와 Edit(경로) 두 가지만 검사 대상입니다. 여기에는 gitignore 패턴 문법을 씁니다. Write(docs/**)처럼 적으면 무시되니 Edit(docs/**)로 써야 해요.

덤으로 Read deny는 같은 경로의 편집·쓰기까지 함께 막습니다. 위 예시의 Read(./.env) 하나로 읽기와 수정이 모두 차단되는 거죠.

권한 모드: Shift+Tab 순환

규칙이 정밀 조준이라면, 권한 모드는 세션 전체의 기조입니다.

Shift+Tab을 누를 때마다 default(수동 승인) → acceptEdits(편집 자동 승인) → plan(계획 모드) 순으로 돌아갑니다. 계획 모드는 지난 편에서 다뤘죠.

공식 권한 모드 문서 기준으로, 계정·요금제 조건을 충족하면 auto 모드도 순환에 들어옵니다. 분류기 모델이 위험한 행동만 걸러내고 나머지는 묻지 않는 모드예요. 이때도 명시적 ask 규칙은 프롬프트를 강제합니다.

참고로 공식 발표 기준으로 2026년 8월 14일부터 Pro·Max·Team 요금제의 새 세션은 auto 모드가 기본값이 됩니다.

설정 파일 간 우선순위

규칙은 여러 층의 settings.json에 나눠 담을 수 있습니다. 개인 전역(~/.claude/), 프로젝트(.claude/settings.json), 로컬 전용, 그리고 조직 관리 설정까지요.

공식 설정 우선순위 문서가 밝히는 원칙은 단순합니다. 어느 층에서든 deny가 걸리면 다른 층의 allow로 못 뒤집습니다.

프로젝트가 allow한 걸 개인 설정의 deny로 막을 수 있고 반대도 마찬가지예요. 조직 관리 설정의 deny는 명령줄 플래그로도 못 풉니다.

규칙은 모델이 아니라 도구가 지킵니다

마지막으로 오해하기 쉬운 지점 하나입니다.

CLAUDE.md에 “git push 하지 마”라고 적는 건 부탁이지 강제가 아닙니다. 모델이 지시를 잊거나 잘못 판단하면 뚫릴 수 있어요.

권한 규칙은 다릅니다. Claude Code 클라이언트가 모델의 판단과 무관하게 기계적으로 집행합니다. 반드시 막아야 하는 건 CLAUDE.md가 아니라 deny 규칙에 넣으세요.

정리

권한 시스템의 뼈대는 세 가지입니다. allow·ask·deny 규칙, deny → ask → allow 평가 순서, 그리고 세션 기조를 정하는 권한 모드.

자주 쓰는 안전한 명령은 allow로 열어 프롬프트 피로를 줄이고, 위험한 명령은 deny로 못 박는 게 기본 전략입니다.

다음 편에서는 대화를 이어 가고 갈라 치는 /resume·/branch·/fork 3종 세트를 다룹니다.

출처 및 확인 기준

• Claude Code 공식 문서 — Configure permissions (Anthropic, 2026-08-13 확인)
• Claude Code 공식 문서 — Choose a permission mode (Anthropic, 2026-08-13 확인)

이어서 읽기

Claude Code 시리즈

• 이전 편: [Claude Code #2] /plan 계획 모드, 수정 전에 설계부터 합의하기
• 이전 편: [Claude Code #1] /init, CLAUDE.md 자동 생성으로 시작하기

관련 주제

• [에이전트 설계 #1] 하네스 엔지니어링이란? 프롬프트 다음에 오는 것