Claude Code의 settings.json과 권한 설계 — 「확인 지옥」과 「과도한 허용」 사이의 균형 잡기

Claude Code의 권한 설정과 관련하여, 다음과 같은 상태에 놓여 있지 않으신가요?

• 명령어를 실행할 때마다 「실행해도 될까요?」라고 물어봐서, 매번 y를 누르는 것이 은근히 힘들다
• 그렇다고 전부 허용하기에는 무섭다 (rm -rf를 멋대로 실행하지 않았으면 좋겠다)
• settings.json에 무엇을 어떻게 적어야 안전한지, 그 경계선을 모르겠다
• 팀에서 사용할 때, 어디까지 공유해도 될지 망설여진다

권한은 「전부 확인」 아니면 「전부 허용」이라는 이지선다가 아닙니다. settings.json의 permissions를 통해, 안전한 것은 허용(allow), 위험한 것은 거부(deny), 애매한 것은 확인(ask)하도록 세밀하게 경계를 나눌 수 있습니다. 이 기사에서는 그 설계 방식과 구체적인 작성법을 정리합니다.

주의:

settings.json의 키(key)나 권한 규칙의 표기법은 변경될 수 있습니다. 본 기사는 작성 시점(2026년 6월)의 공식 문서를 참조하고 있으나, 실제 설정 시에는 가지고 계신 최신 문서를 확인해 주시기 바랍니다.

settings.json의 permissions에는 허용 리스트(allow)와 거부 리스트(deny)를 작성할 수 있습니다. 공식 문서의 예시는 다음과 같습니다.

{
"$schema": "https://json.schemastore.org/claude-code-settings.json",
"permissions": {
...

읽는 법은 다음과 같습니다.

• allow: 여기에 작성된 것은 확인 없이 실행됩니다.
• deny: 여기에 작성된 것은 실행되지 않습니다 (최우선).

Bash(...)는 명령어, Read(...)는 파일 읽기라는 형태로, 도구(tool)별로 대상을 지정합니다.

권한 규칙에는 평가 순서가 있습니다. 공식 문서에 따르면, deny → ask → allow 순으로 평가되며, 가장 먼저 매칭된 규칙이 적용됩니다.

평가 순서 (먼저 매칭된 쪽이 승리)
├─ ① deny … 거부 (최우선)
├─ ② ask … 확인
...

이는 안전 측에 무게를 둔 설계입니다. deny가 가장 먼저 평가되므로, 거부하고 싶은 것은 확실하게 거부됩니다. "실수로 allow에 적었지만 deny에도 있는 경우"에도 deny가 승리합니다.

매번 명령어가 조금씩 바뀌는 경우(인자가 다른 경우)에는 와일드카드 *를 사용하여 "형태"를 허용할 수 있습니다. 공식 문서의 예시입니다.

{
"permissions": {
"allow": [
...

여기서의 설계 의도를 알기 쉽게 설명하면 다음과 같습니다.

• npm run *: npm 스크립트 전반은 허용 (빌드, 테스트 등)
• git commit *: 커밋은 허용
• * --version / * --help *: 버전 확인 및 도움말 표시는 무해하므로 허용
• git push *: push는 거부 (원격 저장소를 멋대로 변경하지 못하게 함)

"커밋은 OK지만 push는 안 됨"과 같이, 읽기 및 로컬 작업은 허용하고 외부로 영향을 주는 조작은 차단하는 경계선을 그대로 표현할 수 있습니다.

무엇을 allow로 하고 무엇을 deny로 할 것인가. 고민된다면 다음 기준을 참고하세요.

분류	예시	권장 사항
읽기 및 상태 확인	git status / git diff / ls / 테스트 실행	allow (쾌적함)
로컬에서 완결되는 작업	npm run build / git commit	allow에 가까움
파괴적·비가역적	rm -rf * / git push --force	deny (차단)
외부로의 송신·취득	curl *	필요할 때만 확인, 원칙적으로 deny
비밀 정보 읽기	.env / secrets/**	deny (읽지 못하게 함)

특히 중요한 것이 **비밀 정보의 deny**입니다. 공식 예시에서도 .env나 secrets/**를 deny에 넣고 있습니다. API 키 등을 실수로 읽게 하여 대화 내용에 포함되는 사고를 방지할 수 있습니다. 명령어 계열의 권한은 사용 중인 셸(shell)에 맞춰 작성합니다. Windows에서는 PowerShell(...) 형태가 됩니다. 공식 문서의 예시입니다.

{
"permissions": {
"allow": [
...

생각하는 방식은 동일합니다. "상태 확인 및 커밋은 허용, 삭제 계열은 거부"입니다. 본인의 환경에 맞는 셸(shell)에 맞춰 구분하여 작성해 주세요.

settings.json을 리포지토리(repository)에 포함하면 권한 설정을 팀 단위로 공유할 수 있습니다. 단, 모두가 "안전하다"고 납득할 수 있는 범위로 한정하는 것이 원칙입니다.

• 공유하는 allow는 누가 봐도 무해한 것(읽기·테스트·빌드)으로 제한합니다.
• 개인적인 선호에 따라 확장하고 싶은 권한은 개인 설정 측에 둡니다 (공유 리포지토리에 섞지 않습니다).
• deny (비밀 정보·파괴 계열)는 팀 공통으로 묶어두는 것이 안전합니다.

권한은 "속도"와 "안전" 사이의 트레이드오프(trade-off)입니다. 공유 설정은 안전한 쪽으로 기울이고, 편의성은 개인 측에서 추가하는 방식으로 분담하면 마찰을 줄일 수 있습니다.

• 권한은 settings.json의 permissions (allow / deny)를 통해 세밀하게 설계할 수 있습니다.
• 평가 순서는 deny → ask → allow입니다. 거부(deny)가 최우선이며 안전한 쪽을 지향합니다.
• 와일드카드 *를 사용하여 "명령어의 형태"를 허용할 수 있으며, "commit은 OK, push는 안 됨"과 같은 표현이 가능합니다.
• 비밀 정보(.env / secrets/**)와 파괴 계열은 deny로 고정하는 것을 추천합니다.

우선은 "매번 확인받느라 지치는 명령어"를 allow에, "절대로 막아야 하는 명령어와 비밀 파일"을 deny에 넣는 것부터 시작하면, 확인 지옥과 과도한 허용 양쪽을 모두 피할 수 있습니다.

권한 설계는 "Claude Code에게 무엇을 어디까지 맡길 것인가"를 결정하는 작업입니다. CLAUDE.md로 규칙을 명문화하고 개발의 틀을 잡아두면 권한의 경계선을 판단하기가 더 쉬워집니다. 제가 사용 중인 스킬을 무료로 공개하고 있습니다.

무료 스타터 (GitHub · CC BY 4.0):

CLAUDE.md 설계 · 계획 우선 개발 (PIV) · AI 커밋 전략 · 애자일(Agile) 프롬프트 설계의 4가지 스킬이 일본어와 영어로 포함되어 있습니다. 규칙과 진행 방식의 토대를 먼저 다진 후, 권한을 자신의 운영 방식에 맞춰 깎아 나가는 것이 매끄럽습니다. 우선 무료 리포지토리부터 시도해 보세요.

최신 팁은 X에서도 발신하고 있습니다: @k___n___t_1125