클로드코드 권한, 어디까지 자동으로 풀어도 될까

클로드코드를 며칠 써보면 "해도 될까요?" 묻는 창이 은근히 성가십니다. 그렇다고 다 자동으로 풀면 불안하고요. 그 중간 어디쯤에 선을 그을지를, 직접 설정 파일을 만져본 순서대로 적었습니다.

클로드코드 권한 설정은 "귀찮은 승인 창을 어떻게 줄이느냐"의 문제처럼 보이지만, 사실은 "내 컴퓨터에서 AI가 손대도 되는 범위를 내가 미리 정해두느냐"의 문제예요. 이 둘은 다릅니다. 앞은 편의고, 뒤는 안전이죠. 이 글은 그 선을 스스로 그을 수 있게 돕는 심화편입니다.

클로드코드가 뭔지, 어떻게 깔고 로그인하는지는 클로드코드 사용법 글에서 이미 다뤘습니다. 승인 창이라는 안전장치가 "있다"는 소개도 거기 있고요. 여기서는 그 장치를 실제로 내 손으로 조절하는 데까지 들어갑니다. 아직 설치 전이라면 그 글부터 보고 오시는 편이 낫습니다.

▲ 노트북 화면에 뜬 파일 편집 승인 확인 창과 그 위로 다가가는 손, 옆에는 클로드코드가 그냥 하는 일과 멈춰 서서 묻는 일을 나눈 대비 카드. (자체 제작 이미지)

1. 클로드코드는 무엇을 묻고, 무엇을 그냥 하는가

승인 창을 조절하려면, 먼저 클로드코드가 어떤 기준으로 물어보는지를 알아야 합니다.

기준은 의외로 단순합니다. 되돌릴 수 있는 일은 그냥 하고, 흔적이 남는 일은 물어봅니다. 파일 내용을 읽거나 폴더 목록을 훑는 것처럼 컴퓨터 상태를 바꾸지 않는 조회 작업은 대개 승인 없이 진행돼요. 반대로 파일을 고치거나(편집), 새 파일을 만들거나(쓰기), 터미널 명령을 실행하거나, 인터넷에 접속하는 것처럼 결과가 남고 되돌리기 번거로운 작업 앞에서는 멈춰 서서 확인을 구합니다.

그래서 승인 창이 자주 뜬다는 건, 뒤집어 보면 "지금 결과가 남는 일을 하려는 참"이라는 신호이기도 합니다. 무작정 성가신 게 아니라 일종의 브레이크죠.

한 가지 더. 승인 창이 떴을 때 그냥 "예"만 있는 게 아닙니다. "이번만 허용"과 "앞으로 이 명령은 안 물어봄"을 고를 수 있어요. 뒤엣것을 고르면 그 규칙이 설정 파일에 저장되고, 다음부터 같은 작업은 조용히 통과합니다. 사실 대부분의 권한 설정은 이 버튼 하나로 조금씩 쌓입니다. 다음 장에서 볼 설정 파일 편집은, 그 쌓인 규칙을 한눈에 보고 손보는 일에 가깝습니다.

2. 권한을 적어두는 곳 — settings.json 세 자리

클로드코드의 권한 규칙은 settings.json이라는 파일에 적힙니다. 이름이 딱딱하지만, 그냥 설정을 담아둔 메모장 파일이라고 보면 됩니다. 이 파일이 놓이는 자리가 세 군데예요. 어디에 적느냐에 따라 규칙이 미치는 범위가 달라집니다.

자리	파일 위치	적용 범위
사용자(전체)	`~/.claude/settings.json`	내 컴퓨터의 모든 작업 폴더
프로젝트(공유)	`.claude/settings.json`	그 폴더 하나. 팀과 공유(깃에 올라감)
로컬(나만)	`.claude/settings.local.json`	그 폴더 하나. 나만(깃에서 제외)

~는 내 사용자 홈 폴더를 가리키는 기호입니다. 윈도우에서는 %USERPROFILE%\.claude가 같은 자리고요.

세 자리에 같은 항목이 서로 다르게 적혀 있으면, 좁은 쪽이 이깁니다. 로컬이 프로젝트를 이기고, 프로젝트가 전체 설정을 이기죠. 회사가 관리하는 컴퓨터라면 조직 차원의 관리 설정이 그 위에 있어 개인이 못 뒤집기도 합니다.

이 구조가 왜 편한지는 4장에서 실감하게 됩니다. 지금은 "권한은 세 군데에 나눠 적을 수 있고, 좁게 적을수록 힘이 세다" 정도만 챙겨두면 충분해요.

3. 허용·차단 목록 직접 짜기

settings.json을 열면 권한은 이렇게 생긴 두 개의 목록으로 관리됩니다. allow는 "이건 묻지 말고 해도 돼"고, deny는 "이건 절대 하지 마"예요.

{
  "permissions": {
    "allow": [
      "Bash(npm run lint)",
      "Read(~/.zshrc)"
    ],
    "deny": [
      "Read(./.env)",
      "Read(./secrets/**)",
      "Bash(curl *)"
    ]
  }
}

읽는 법은 어렵지 않습니다. 괄호 앞 단어가 작업 종류입니다. Read는 파일 읽기, Edit은 편집, Write는 쓰기, Bash는 터미널 명령이죠. 괄호 안이 그 대상이고요.

위 예시를 말로 풀면 이렇습니다. npm run lint이라는 명령과 특정 설정 파일 읽기는 승인 없이 통과시키되, 비밀이 담긴 .env 파일과 secrets 폴더는 아예 읽지 못하게 막고, 인터넷에서 뭔가 내려받는 curl 명령도 차단한다. 참고로 * 기호는 "여기 뭐가 오든"이라는 뜻이라, curl 뒤에 어떤 주소가 붙어도 걸립니다.

비개발자에게 실질적으로 중요한 건 allow보다 deny입니다. allow는 안 적어도 그때그때 승인 버튼으로 채우면 되지만, deny는 내가 미리 못 박아두지 않으면 사고를 막을 방법이 없거든요. API 키나 비밀번호가 든 .env 파일, 개인 정보가 담긴 폴더처럼 "AI에게도 안 보여주고 싶은 것"이 있다면, 그것부터 deny에 적어두는 걸 권합니다.

allow를 손으로 채우기 부담스럽다면, 앞 장에서 말한 승인 창의 "앞으로 안 물어봄" 버튼을 쓰세요. 자주 반복하는 안전한 명령만 골라 그렇게 통과시키면, 목록이 자연스럽게 나에게 맞는 형태로 자랍니다. 파일을 직접 여는 건 그 목록을 정리하거나 위험한 항목을 빼고 싶을 때면 됩니다.

4. 프로젝트마다 권한을 다르게 주기

2장에서 설정 파일이 세 자리라고 했죠. 이게 왜 유용한지 실제 상황으로 옮겨보겠습니다.

가계부나 개인 메모를 정리하는 폴더에서는 권한을 넉넉히 풀어도 별 탈이 없습니다. 최악의 경우라야 내 파일 몇 개가 지저분해지는 정도니까요. 그런 폴더에서는 자주 쓰는 명령들을 그 폴더의 .claude/settings.json에 allow로 적어두고 편하게 씁니다.

반대로 회사 자료나 고객 정보가 든 폴더라면 이야기가 다릅니다. 여기서는 오히려 deny를 촘촘히 걸고, 웬만한 작업은 매번 눈으로 확인하고 넘기는 편이 낫죠. 폴더마다 성격이 다른데 권한을 하나로 통일하면, 안전한 곳에 맞추면 위험한 곳이 뚫리고 위험한 곳에 맞추면 안전한 곳까지 번거로워집니다.

여기서 공유용(.claude/settings.json)과 나만 보는 용(.claude/settings.local.json)의 구분이 중요해집니다. 앞엣것은 깃(버전 관리)에 올라가 협업자와 공유되고, 뒤엣것은 올라가지 않아 나에게만 남습니다. 혼자 쓰는 개인 폴더라면 그냥 로컬(.local.json)에 적으면 되고, 남과 나눠 쓸 규칙과 나만의 규칙을 갈라두고 싶을 때 이 구분이 힘을 발휘합니다.

정리하면 이렇습니다. 모든 폴더에 공통으로 걸고 싶은 최소한의 금지선은 전체 설정(~/.claude/settings.json)에, 폴더 성격에 따른 세부 규칙은 각 폴더의 설정에 나눠 담는다. 이 두 층만 잡아도 "안전한 곳은 편하게, 민감한 곳은 조심스럽게"가 저절로 굴러갑니다. 엑셀 파일을 취합하는 작업이나 카드내역으로 경비 보고서를 만드는 작업처럼 같은 일을 반복하는 폴더일수록, 그 폴더 전용 allow 목록의 효과가 큽니다.

$settings.json의 allow·deny 목록 예시 코드와 사용자 전체·프로젝트·로컬 세 자리의 적용 범위 및 우선순위를 정리한 도식.$ ▲ settings.json의 allow·deny 목록 예시 코드와 사용자 전체·프로젝트·로컬 세 자리의 적용 범위 및 우선순위를 정리한 도식. (자체 제작 이미지)

5. 훅 — 특정 작업만 콕 집어 막기

deny 목록이 "이 대상은 손대지 마"라면, 훅(hook)은 좀 더 똑똑한 문지기입니다. 작업이 실행되기 직전에 내가 정한 검사를 한 번 거치게 하고, 조건에 걸리면 그 작업만 막는 방식이죠.

예를 들어 "파일을 지우는 명령이면 무조건 멈춰라" 같은 규칙은 단순 목록으로 표현하기 까다롭습니다. 지우는 명령의 생김새가 제각각이니까요. 훅은 실행 직전 명령을 들여다보고 "여기 삭제 명령이 들었네" 하고 판단해 걸러낼 수 있습니다. 공식 문서에도 위험한 삭제 명령을 가로채는 예시가 나와 있고요.

훅은 settings.json 안에 "어떤 작업 직전에"(예: 터미널 명령 실행 전) "무엇을 실행할지"를 적어 설정합니다. 다만 여기서부터는 간단한 스크립트를 만져야 해서, 비개발자에게는 진입 문턱이 확 올라갑니다. 그러니 이렇게 접근하길 권합니다. 훅을 직접 짜려 들지 말고, "터미널에서 파일 삭제 명령은 항상 한 번 더 확인하도록 훅을 걸어줘"처럼 클로드코드에게 말로 부탁하세요. 무슨 규칙을 원하는지만 분명하면, 설정과 스크립트 작성은 클로드가 대신 해줍니다.

훅까지 필요한 사람은 사실 많지 않습니다. 대부분은 3장의 deny 목록으로 충분해요. "이 특정 위험 동작만은 시스템 차원에서 확실히 잠그고 싶다"는 요구가 생겼을 때, 그런 장치가 있다는 것만 기억해두면 됩니다.

6. 전체 자동승인은 언제, 왜 위험한가

승인이 정 귀찮으면 아예 다 꺼버리는 길도 있습니다. --dangerously-skip-permissions라는 옵션을 붙여 실행하면 모든 확인 창이 사라지고, 클로드코드가 묻지 않고 전부 실행합니다.

이름에 '위험하게(dangerously)'가 붙어 있는 건 엄포가 아닙니다. 이 상태에서는 파일 삭제든, 외부 접속이든, 되돌리기 힘든 명령이든 브레이크 없이 진행돼요. 잘못된 지시 하나, 혹은 클로드의 오판 하나가 곧장 실행됩니다. 그래서 중요한 파일이 든 평소 작업 컴퓨터에서 이걸 켜는 건 권하지 않습니다.

이 옵션이 제 몫을 하는 자리는 따로 있습니다. 지워져도 그만인 임시 폴더, 혹은 인터넷과 격리된 실험용 환경에서 같은 작업을 수십 번 반복 자동화할 때죠. 잃을 게 없는 공간에서 속도만 필요할 때. 그 조건이 아니라면 기본 승인 방식을 그대로 두는 편이 안전합니다.

전체 자동승인까지 가지 않고 승인 피로만 덜고 싶다면, 더 부드러운 중간 단계가 있습니다. 클로드코드 화면에서 Shift+Tab을 누르면 승인 방식이 몇 단계로 바뀌는데, 그중에는 파일 편집만 자동으로 수락하고 나머지는 여전히 물어보는 모드도 있어요. 이건 그 세션에만 잠깐 적용되는 임시 조절이라, 설정 파일을 영구히 바꾸는 것보다 부담이 적습니다. "이번 작업 동안만 편집은 알아서 하게 두자" 싶을 때 쓰기 좋습니다.

▲ 기본 승인부터 편집 자동수락, 전체 자동승인까지 승인 강도를 안전한 쪽에서 위험한 쪽으로 배열한 스펙트럼 카드. (자체 제작 이미지)

7. 그래서 선을 어디에 그을까

여기까지 왔으면 도구는 다 손에 쥔 셈입니다. 남은 건 나만의 기준을 정하는 일이죠. 제가 쓰는 기준은 하나입니다. 자동으로 풀어도 되는 건 "잘못돼도 되돌릴 수 있는 일"뿐이고, 되돌리기 어려운 일은 번거롭더라도 눈으로 확인하고 넘긴다.

이 기준을 그대로 설정으로 옮기면 이렇게 됩니다. 자주 쓰는 안전한 명령은 승인 창의 "앞으로 안 물어봄"으로 하나씩 allow에 쌓고, 비밀이 든 파일과 폴더는 deny로 못 박고, 폴더 성격에 따라 그 규칙을 나눠 담는다. 전체 자동승인은 격리된 실험용에만. 대부분의 비개발자에게는 이 정도면 충분하고, 훅은 정말 특정 동작을 확실히 잠가야 할 때만 꺼내면 됩니다.

한 가지 덧붙이면, 실행 전에 계획부터 확인하는 플랜 모드도 사실은 권한 조절의 사촌쯤 됩니다. 승인을 개별 작업 단위로 막는 대신, 아예 "실행 전에 무엇을 할지 먼저 보여줘" 하고 앞단에서 한 번 거르는 방식이죠. 이건 클로드코드 프롬프트 6가지 글에서 다룬 그 안전장치입니다. 되돌리기와 판 갈아엎기 같은 "일이 어긋났을 때 수습하는 습관"도 그 글에 있으니, 권한 설정과 함께 쓰면 좋습니다.

권한을 조인다고 도구가 둔해지는 건 아닙니다. 오히려 어디까지 맡겨도 되는지가 분명해지면, 맡긴 부분에서는 마음 놓고 손을 뗄 수 있죠. 처음엔 승인 창을 그대로 두고 며칠 써보세요. 그러다 "이건 매번 안 물어도 되는데" 싶은 게 눈에 밟히기 시작하면, 그때가 이 글로 돌아와 목록을 짤 때입니다. 클로드코드와 코워크, n8n 중 무엇부터 시작할지 아직 고민 중이라면 노코드 AI 자동화 도구 비교 글이 갈림길을 정리해줍니다. 터미널 없이 쓰는 코워크에도 비슷한 안전장치가 있고요.

이 글은 정보 제공을 목적으로 하며, 작성 시점(2026년 7월) 기준입니다. 설정 항목 이름·옵션·기본 동작은 공식 문서에서 바뀔 수 있으니, 특히 권한처럼 안전과 직결되는 부분은 설정 전 원문을 한 번 확인하시길 권합니다. 이 글은 특정 설정을 안전하다고 보장하지 않으며, 자동승인 관련 판단의 최종 책임은 사용자에게 있습니다.

참고한 공식 자료 - 클로드코드 설정·권한(settings.json, allow/deny, 우선순위): code.claude.com/docs/settings - 클로드코드 훅(hooks): code.claude.com/docs/hooks - 설치·첫 실행: code.claude.com/docs/setup

클로드코드 권한, 어디까지 자동으로 풀어도 될까 — 승인·자동실행 안전 세팅