Claude Code를 오래 쓰다 보면 같은 명령에 같은 확인 창이 반복해서 뜹니다. 그때마다 승인을 누르는 게 일이 되죠.

내장 스킬 /fewer-permission-prompts는 그 반복을 줄이라고 만들어진 도구입니다. 내가 지금까지 친 명령 기록을 읽어서, 자주 쓰는 읽기 전용 명령을 골라 허용 목록에 대신 적어 줍니다.

편해지는 건 맞는데, 그러면 무엇이 허용되고 무엇이 그대로 막히는지가 궁금해져요. 그래서 스킬이 읽는 자리를 같은 방식으로 읽어 세어 봤습니다. Claude Code v2.1.263 기준입니다.

여러 문 가운데 일부만 열린 장면 여러 문 가운데 일부만 열린 장면 — 출처: 개념 컷 · agy 자가 생성

이 스킬이 읽는 곳과 쓰는 곳

세션 기록이 남는 **~/.claude/projects/<폴더>/*.jsonl**을 훑어 도구 호출을 꺼내고, 빈도로 줄을 세운 뒤 읽기 전용만 골라 프로젝트의 **.claude/settings.json** 안 **permissions.allow**에 병합합니다.

단계 하는 일
읽기 최근 50개 세션의 jsonl에서 Bash·MCP 호출 추출
집계 Bash는 명령 + 첫 서브커맨드, MCP는 도구 이름 전체
거르기 읽기 전용만, 3회 미만은 버리고 상위 20개까지
쓰기 permissions.allow에 병합, deny·ask는 건드리지 않음

git log와 git log –oneline을 따로 세지 않고 명령과 첫 서브커맨드 짝으로 묶어서, 결과가 Bash(git log *) 같은 패턴 하나로 나옵니다.

읽는 범위는 현재 프로젝트에 그치지 않습니다. 사용자의 프로젝트 폴더 전체를 훑어 호출을 모읍니다.

쓰는 자리는 프로젝트 설정 하나로 못 박혀 있습니다. 홈 디렉터리의 전역 설정도, settings.local.json도 건드리지 않고, 기존 항목은 지우지 않으며 중복만 걸러 붙입니다.

세션 50개, 명령 12,411건을 세어 봤습니다

스킬이 보는 자리를 같은 방식으로 직접 집계했습니다. 최근 수정된 jsonl 50개에서 도구 호출 3,650건을 꺼냈고, 그중 Bash 명령을 파이프와 논리 연산자 단위로 쪼개 12,411개 조각으로 폈습니다. heredoc 본문과 셸 키워드는 명령이 아니어서 빼고, 실제로 실행 파일이 있는 이름만 남겼어요.

고유한 명령과 서브커맨드 조합은 2,871개였고, 그중 스킬의 기준인 3회 이상은 426개였습니다. 여기까지는 꽤 많아 보이죠.

명령 호출 12,411건의 분류 막대그래프 명령 호출 12,411건의 분류 막대그래프 — 출처: 트랜스크립트 직접 집계 기반 자가 렌더

그런데 스킬의 거르는 규칙을 그대로 적용하자 결과는 정반대였습니다. 규칙으로 남을 자리가 전체의 1.0%, 120건뿐이었어요. 3회 이상 나온 조합으로 따지면 아홉 개입니다.

MCP 쪽은 더 적었습니다. 50개 세션에서 53건, 여덟 종이 전부였고 3회 이상은 브라우저 조작과 메일 검색 도구 네 종이었어요. MCP는 이름 자체가 구체적이라 와일드카드 없이 그대로 적히니, 종수가 곧 규칙 수가 됩니다.

호출의 81%는 자동 허용 대상

가장 큰 비중은 이미 자동 허용되는 명령이었습니다. 호출 10,055건, 전체의 81.0%예요. Claude Code는 읽기 전용이 확실한 명령을 처음부터 확인 없이 실행하기 때문에, 여기 해당하는 것은 허용 목록에 적어도 달라지는 게 없습니다.

분류 예
인자와 무관하게 허용 echo · ls · cat · head · tail · cd · diff
안전한 옵션만 허용 grep · find · sort · jq · rg
git 읽기 전용 status · log · diff · show · branch
gh 읽기 전용 pr view · issue list · run view

이미 열려 있는 문과 끝까지 잠긴 문이 갈리는 장면 이미 열려 있는 문과 끝까지 잠긴 문이 갈리는 장면 — 출처: 개념 컷 · agy 자가 생성

제 기록에서 가장 많이 나온 명령이 echo 1,082건, head 1,026건, tail 547건, ls 255건이었는데 넷 다 이 목록에 있습니다. 스킬은 이런 것을 제안 목록에서 아예 빼도록 지시받아요.

허용 조건이 명령마다 다른 것도 눈여겨볼 만합니다. pwd와 whoami는 인자가 없을 때만, node –version처럼 정확히 그 형태일 때만 통과하는 것도 있어요. find는 자동 허용이지만 파일을 지우거나 다른 명령을 부르는 옵션이 붙으면 막히고, printf는 옵션이 하나라도 붙으면 막힙니다. 읽기 전용인지를 명령 이름이 아니라 실제 인자까지 보고 판정한다는 뜻입니다.

허용 목록에 올릴 수 없는 명령

호출 1,462건, 11.8%가 임의 코드 실행에 해당해 허용 목록에 올릴 수 없는 명령이었습니다.

많이 썼지만 허용 목록에 올릴 수 없는 명령 많이 썼지만 허용 목록에 올릴 수 없는 명령 — 출처: 트랜스크립트 직접 집계 기반 자가 렌더

스킬 지시문은 이 경계를 범주로 못 박아 뒀습니다.

범주 예
인터프리터 python · node · bun · ruby · perl
셸과 원격 실행 bash · sh · zsh · eval · exec · ssh
패키지 러너 npx · bunx · uvx · uv run
작업 러너 와일드카드 npm run * · make * · cargo run *

작업 러너의 허용 기준은 조금 다릅니다. Bash(bun run typecheck)처럼 정확한 한 줄은 괜찮지만 Bash(bun run *) 는 안 됩니다. 스크립트 이름만 바뀌면 무엇이든 돌아가니 결국 임의 실행과 같아서예요.

여기에 상태를 바꾸는 명령 774건, 6.2%가 더해집니다. 지우고 옮기고 밀어 넣고 설치하는 것은 전부 빠지고, 애매하면 빼라고 적혀 있어요.

같은 도구 안에서도 갈립니다. git status와 git log는 자동 허용이라 규칙이 필요 없지만, git add와 git commit, git push는 상태를 바꾸니 스킬이 손대지 않습니다. gh도 pr view와 pr list는 통과하고 pr merge는 남아요. 명령 이름이 아니라 서브커맨드 단위로 기준이 나뉩니다.

자주 쓴다는 사실은 허용 목록에 올려도 된다는 근거가 아닙니다

허용 규칙으로 남는 1.0%

남은 1.0%가 이 스킬의 실제 몫입니다. 제 경우엔 awk와 ffprobe, dig처럼 읽기만 하면서 자동 허용 목록에는 없는 명령 몇 개였어요.

허용 목록 규칙으로 남은 호출 비율 게이지 허용 목록 규칙으로 남은 호출 비율 게이지 — 출처: 트랜스크립트 직접 집계 기반 자가 렌더

숫자만 보면 실망스러워 보이지만, 반복 확인이 어디서 오는지를 알려 준다는 값어치가 있습니다. 프롬프트가 자주 뜬다면 원인은 대개 읽기 전용 명령이 아니라 스크립트 실행 쪽이고, 그건 규칙으로 풀 문제가 아니라 작업 방식으로 풀 문제입니다.

기록이 적으면 제안되는 규칙도 적습니다. 3회 미만은 버리고 상위 20개만 남기니, 쓴 지 얼마 안 된 환경에서 돌리면 제안이 거의 안 나와요. 반대로 오래 쓴 환경이라면 다른 프로젝트에서 쓰던 명령까지 딸려 올 수 있으니 목록을 한 번 읽고 병합하는 편이 낫습니다.

전체 허용 옵션과의 차이

–dangerously-skip-permissions는 확인 자체를 없앱니다. 무엇이 허용됐는지 목록이 남지 않고, 지우거나 밀어 넣는 명령도 그대로 지나갑니다.

허용 목록은 반대 방향이에요. 허용할 것을 적어 두고 나머지는 계속 물어봅니다. 적은 것이 파일로 남아 나중에 읽고 지울 수 있고, 스킬은 그 목록에 인터프리터와 상태 변경 명령을 넣지 않아요. 편의를 얻는 방식이 다른 게 아니라 남는 흔적이 다릅니다.

권한 프롬프트를 줄이는 작업 방식

집계 결과를 뒤집어 보면 실마리가 나옵니다. 제 경우 확인이 붙을 수밖에 없는 호출의 대부분이 Python heredoc 412건처럼 그 자리에서 코드를 짜 넣는 형태였어요. 이건 규칙으로 허용할 수 없습니다.

줄이는 방법은 그 코드를 프로젝트 스크립트로 옮기는 쪽입니다. 매번 다른 코드를 인라인으로 넘기는 대신 파일로 두면, 와일드카드 없이 정확한 한 줄만 허용 목록에 올릴 수 있어요.

스킬 동작 정리 5항목 카드 스킬 동작 정리 5항목 카드 — 출처: 개념 정리 · 자가 렌더

스킬을 부르면 제안 목록이 표로 먼저 나오니, 병합하기 전에 그 표를 읽고 낯선 항목이 있는지 보세요. 병합한 뒤에는 프로젝트의 설정 파일을 열어 무엇이 들어갔는지 확인하고, 필요 없는 줄은 지우면 됩니다.

스킬 실사용 (1) — 책 한 권을 AI 스킬로 압축하는 법, book-to-skill 직접 써봤습니다

스킬 실사용 (2) — grill-me 로 가상 사업 계획을 캐물었습니다

참고 출처