클로드 코드 권한 설정: 되돌리기 비용 기준

이 포스팅은 쿠팡 파트너스 활동의 일환으로, 이에 따른 일정액의 수수료를 제공받습니다.

AI 코딩 도구를 매일 쓰는 팀의 진짜 질문은 "어디까지 자동으로 실행하게 둘 것인가"입니다. 이 글은 되돌리기 비용으로 위임 범위를 나누는 기준, 클로드 코드·Cursor·VS Code의 승인 모델 차이, 그 기준을 규칙 파일이 아니라 강제 레이어에 고정하는 방법을 다룹니다.

이 글은 2026년 7월 기준 정보입니다. AI 분야는 변화가 빨라 발행 후 내용이 달라질 수 있습니다. 도구 기능 서술은 모두 같은 시점의 공식 문서를 근거로 합니다.

위임 기준은 위험도가 아니라 되돌리기 비용입니다#

위험도는 사람마다 다르게 읽힙니다. 누군가에게 DB 마이그레이션은 일상이고, 누군가에게는 사고 직전입니다. 기준을 "되돌리는 데 얼마가 드는가"로 바꾸면 팀원 누구에게 물어도 답이 거의 같아집니다.

층	무엇이 해당되나	되돌리는 법	맡길 수준
1층	작업 브랜치 파일 수정, 테스트 실행, 로컬 리팩터링	revert 한 번	자율 실행
2층	커밋 이력, 푸시된 브랜치, PR 코멘트	되돌리되 흔적이 남음	사후 리뷰
3층	공개 URL 변경, DB 마이그레이션·삭제, 운영 배포, 과금·메일 API	사실상 없음	사전 승인

이미 색인된 URL, 이미 나간 메일, 이미 지워진 행에는 revert가 없습니다. 3층만 확실히 막으면 나머지는 과감하게 풀어도 됩니다.

과잉 확인은 승인 피로를 만듭니다#

1층에서 확인을 요구하는 건 손해입니다. 실패해도 비용이 초 단위인 작업마다 승인 창이 뜨면, 개발자는 읽지 않고 엔터를 치는 습관을 들입니다. 그 습관이 3층 승인 창에서도 그대로 나옵니다.

2층은 실행을 막지 않되 관문을 실행 전에서 병합 전으로 옮기는 구조가 맞습니다. AI가 쓴 코드를 어떤 눈으로 볼지는 AI 시대 개발자 생존법에 리뷰 관점으로 정리했습니다.

도구별 자동 실행 설정은 이름부터 다릅니다#

세 도구가 같은 문제를 다루지만 용어가 전혀 다릅니다. 팀 문서에서 섞어 쓰면 설정이 어긋납니다.

도구	부르는 이름	설정 위치	문서상 기본 동작
클로드 코드	권한 모드	settings의 `defaultMode`	읽기 전용은 승인 없이, Bash·파일 수정은 승인 필요
Cursor	Run Modes	`.cursor/permissions.json`, IDE 설정	Auto-review 권장 기본
VS Code Copilot	자동 승인 설정	`chat.tools.*.autoApprove`	안전한 명령만 자동, `rm`·`del`은 항상 수동
Copilot CLI	autopilot	실행 플래그	`--allow-all` 없으면 승인 요청은 자동 거부

각주: 2026년 7월 기준 공식 문서 서술입니다.

표에 담기지 않는 함정이 셋 있습니다. 첫째, 클로드 코드에서 Bash의 "항상 허용"은 저장소·명령 단위로 영구 저장되지만 파일 수정의 "항상 허용"은 세션이 끝나면 사라집니다. 같은 버튼인데 유효기간이 다릅니다.

둘째, bypassPermissions는 승인을 건너뛰지만 무제한은 아닙니다. 루트나 홈 디렉터리 삭제에는 서킷 브레이커가 걸립니다. 공식 문서는 컨테이너·VM 같은 격리 환경에서만 쓰라고 경고하고, 조직 차원에서는 permissions.disableBypassPermissionsMode로 막을 수 있습니다.

셋째, Cursor의 Auto-review는 allowlist 매칭, 샌드박스 실행, LLM 분류기 심사 순으로 처리하는데, 문서가 분류기의 오판 가능성을 명시합니다. 3층 방어선으로 쓸 수 없다는 뜻입니다.

규칙 파일은 부탁이고, 훅은 차단입니다#

CLAUDE.md에 "운영 배포 전 반드시 확인할 것"이라고 적어두고 안심하는 경우가 많습니다. 가장 많이 어긋나는 지점입니다.

수단	실제로 하는 일	어길 수 있나
CLAUDE.md 등 규칙 파일	컨텍스트 제공. 시도하는 바를 형성	가능
권한 규칙	클로드 코드가 허용 여부를 강제	불가
PreToolUse 훅	도구 호출을 allow·deny·ask·defer로 결정	불가
샌드박스	파일시스템·네트워크를 OS 레벨 제한	불가

공식 문서는 프롬프트나 CLAUDE.md가 Claude Code의 허용 범위를 바꾸지 않는다고 정리합니다. 1층과 2층은 부탁으로 충분하지만 3층에 부탁을 쓰면 안 됩니다. 권한 규칙은 Tool 또는 Tool(specifier) 문법을 씁니다.

// .claude/settings.json
{
  "defaultMode": "default",
  "permissions": {
    "deny": ["Read(./.env)", "Bash(npm run deploy)"],
    "disableBypassPermissionsMode": "disable"
  }
}

훅 이벤트는 PreToolUse, PostToolUse, PostToolUseFailure, PermissionRequest, PermissionDenied, PostToolBatch입니다. PreToolUse 훅은 아래 형태로 도구 호출을 사용자 확인으로 승격합니다. 종료 코드 2도 차단 신호입니다.

{
  "hookSpecificOutput": {
    "hookEventName": "PreToolUse",
    "permissionDecision": "ask"
  }
}

3층 작업이라면 ask로 승격하는 훅 하나가 CLAUDE.md 열 줄보다 확실합니다. 훅 설계는 클로드 코드 하네스 엔지니어링에서 더 다룹니다.

확인을 받았는데도 결과가 틀리는 이유#

사전 승인을 걸어도 확인의 품질은 질문의 품질을 넘지 못합니다.

유형	어떤 상황에서	무엇을 확인해야 하나
틀린 전제	잘못된 사실관계로 A·B 선택지를 정리해 옴. 정답 C가 빠져도 모름	이 선택지가 정말 전부인가
정보 열위	오래된 프로젝트처럼 사람이 기억에 의존하는 상황	내 답은 코드를 본 것인가 기억인가
책임 전가	판단하기 곤란해서 던지는 질문. 결정만 넘어옴	이 질문에 근거와 추천안이 있나

확인을 거쳤다는 사실은 검증됐다는 착각을 만듭니다. 아무도 안 본 결정보다 한 번 승인된 잘못된 결정이 더 오래 삽니다. 좋은 확인 요청에는 판단 근거, 확인한 것과 추측한 것의 구분, 추천안이 함께 옵니다.

팀에 적용할 때 점검할 것#

3층 목록을 적습니다. 운영 배포 명령, 마이그레이션 실행, 공개 URL 변경, 발송·과금 API가 보통 여기 들어갑니다.
그 목록만 강제 레이어로 옮깁니다. 권한 규칙 또는 PreToolUse 훅의 ask 승격입니다.
1층에 남은 승인 창을 걷어냅니다. 3층 승인의 신뢰도를 지키는 방법입니다.
승인을 크게 완화한 모드는 컨테이너나 VM에서만 씁니다.
분기마다 다시 봅니다. 설정 이름과 기본값이 자주 바뀝니다.

에이전트가 만든 코드에서 무엇을 먼저 볼지는 바이브 코딩 보안 점검에, 클로드 코드 설정 전반은 클로드 코드 완전 활용 가이드에 정리해 두었습니다.

정리#

위임 범위는 되돌리는 데 얼마가 드는지로 나누면 합의가 빠릅니다. revert로 끝나는 1층은 자율, 흔적이 남는 2층은 사후 리뷰, 되돌릴 수 없는 3층은 사전 승인이 기본 매핑입니다.

3층은 규칙 파일에 적는 것으로 끝내면 안 됩니다. 실제 차단은 권한 규칙과 PreToolUse 훅이 합니다. 되돌릴 수 없는 작업 세 가지를 적고 그중 하나를 강제 레이어로 옮기는 것이 다음 단계입니다.