Claude Code CLAUDE.md Permission Recipe: 반복 설명과 위험 권한 줄이기

Claude Code 실패는 모델이 약해서가 아니라 세션마다 프로젝트 규칙이 흔들려서 생길 때가 많습니다. 명확한 CLAUDE.md와 permission recipe는 반복 설명, 위험 수정, 검증 누락을 줄입니다.

이 글은 초급자가 먼저 만들어야 할 레시피를 다룹니다. 에이전트를 묶어 두는 것이 아니라 read-only, ask-before, never-touch, proof commands를 나누는 것이 목표입니다.

함께 읽기: permission safety ladder, Obsidian to CLAUDE.md workflow, getting started guide.

이 패턴이 효과적인 이유

CLAUDE.md는 기억이 아니라 작업 계약입니다. 검증 명령, 보호 디렉터리, PDF, Gumroad, 상담 링크까지 쓰면 개발과 게시에 모두 효과가 있습니다.

permission recipe는 그 계약을 행동으로 바꿉니다. 영역을 나누면 Claude Code가 사용자보다 앞서 위험한 작업으로 가는 확률이 줄어듭니다.

실무 흐름

CLAUDE.md에 목표, 품질 기준, 증거 명령, 수익 경로를 쓴다
파일 영역을 read-only, ask-before, never-touch로 나눈다
추가 승인 없이 실행 가능한 proof commands를 명시한다
deploy, 삭제, 되돌리기 어려운 작업은 인간 확인 뒤에 둔다
게시 후 h1, 본문 시작, CTA, Gumroad 링크를 스크린샷으로 본다

상황	안전한 진행	증거
개인 사이트	글 본문은 편집 허용, 폼과 API는 ask-before	build와 공개 URL
팀 PR	diff 리뷰는 허용하고 push와 deploy는 요청 전까지 멈춘다	PR diff
수익 페이지	상품 링크, 가격, 문의 폼을 보호한다	클릭 확인

복사해서 쓸 프롬프트와 코드

이 프로젝트를 위한 CLAUDE.md permission recipe를 만들어 주세요. read-only, ask-before, never-touch, auto proof commands, 공개 URL 확인, 무료 PDF/Gumroad/상담 경로 보호 규칙을 포함해 주세요.

const permissionRecipe = {
  readOnly: ["README.md", "package.json", "src/routes/"],
  askBefore: ["site/src/layouts/", "scripts/", "wrangler.toml"],
  neverTouch: [".env", "billing/", "customer-data/"],
  proofCommands: ["npm.cmd run build", "git diff --stat"]
};

function canRunWithoutAsking(command) {
  return permissionRecipe.proofCommands.includes(command);
}

console.log(canRunWithoutAsking("npm.cmd run build"));
console.log(canRunWithoutAsking("wrangler pages deploy"));

예시는 실제 설정 파일이 아니라 결정 방식을 코드로 표현한 것입니다. 팀 권한, CI, 배포 흐름에 맞춰 조정합니다.

세 가지 실제 예

첫 설정

README와 package.json을 읽게 한 뒤 첫 수정 전에 CLAUDE.md를 만듭니다. 첫 수정은 한 파일로 제한하면 성공과 실패가 보입니다.

다국어 글

slug와 frontmatter만 믿지 않습니다. 본문 시작과 CTA가 목표 언어인지 규칙에 넣고 스크린샷을 증거로 둡니다.

상담 전

권한표, 금지 영역, 증거 명령을 가지고 상담하면 추상 조언이 아니라 실행 회의가 됩니다.

피해야 할 실패 사례

CLAUDE.md에 원칙만 쓰고 구체적인 금지 영역을 쓰지 않는다.
편하다는 이유로 deploy나 삭제를 자동 허용한다.
상품 링크와 상담 폼을 일반 콘텐츠와 똑같이 다룬다.

규칙이 너무 길면 읽히지 않습니다. 짧게 시작하고 실제 실패 뒤 한 줄씩 추가하는 편이 지속됩니다.

무료 PDF, Gumroad, 상담으로 연결하는 방법

기본이 불안하면 무료 치트시트를 곁에 둡니다. CLAUDE.md, permissions, hooks, MCP, CI는 Setup Guide가 빠릅니다.

review와 debug 요청 표준화에는 50 Prompt Templates를 씁니다. 팀 규칙이나 수익 경로 설계는 상담이 맞습니다. 자료 비교는 products에서 합니다.

게시 전후 확인할 것

게시 전 새 CLAUDE.md 규칙과 글이 permission recipe와 충돌하지 않는지 봅니다. 게시 후 모바일에서 각 언어 h1, 본문 시작, CTA, 상품 링크를 확인합니다.

다음에 볼 지표

Setup Guide 클릭, PDF 시작, 상담 방문, 권한 관련 글 회유를 봅니다. 이 slug에서 상담이 늘면 독자는 템플릿보다 운영 설계를 원합니다.

30분 운영 리뷰

CLAUDE.md permission recipe를 실제 작업에 넣었다면 가장 중요한 리뷰는 다음 날입니다. run log를 보고 허용 범위, 실제 변경 파일, 검증 명령, 확인한 공개 페이지를 하나의 증거로 적습니다. “페이지 확인”처럼 쓰지 말고 모바일 h1, 본문 시작, CTA 영역, Gumroad 링크, 상담 경로를 본 사실을 남깁니다.

그다음 작업자의 안심과 독자의 행동을 나눠 봅니다. 작업자 쪽에서는 금지 영역을 건드리지 않았는지, build 증거가 있는지, 공개 URL이 같은 slug인지, 번역 페이지에 영어 본문이 남지 않았는지 확인합니다. 독자 쪽에서는 명령이 필요한 사람은 무료 PDF, 반복 병목이 있는 사람은 Gumroad, workflow 설계가 필요한 사람은 상담으로 이어지는지 봅니다.

마지막으로 리뷰를 다음 규칙 하나로 바꿉니다. 문제 하나에 규칙 열 개를 추가하지 않습니다. layout 수정 전 질문하기, 운영 Gumroad URL 모두 클릭하기, 각 언어 본문 시작을 스크린샷으로 남기기처럼 매일 지킬 수 있는 작은 규칙이 오래갑니다.