Claude Code permission risk register: agent가 행동하기 전에 허용 범위 정하기

왜 별도 산출물로 만들어야 하는가

이 글은 개인 Claude Code 사용에서 팀 approval rule로 넘어가는 팀를 위한 permission risk register를 만든다. 흔한 실패는 단순하다. agent가 이미 수정, deploy, risky command 요청을 한 뒤에야 권한 논의가 시작된다. Claude Code 작업은 자신감 있는 답변에서 끝나면 안 된다. 다른 사람이 확인할 수 있는 산출물을 남겨야 한다. 여기서 산출물은 action, default decision, proof, owner를 적는 작은 risk register이다.

이 산출물을 prompt, command line, public page 사이의 계약으로 다룬다. Claude Code가 무엇을 읽었고, 무엇을 바꿨고, 어떤 command로 증명했으며, 독자를 다음에 어떤 revenue path로 보낼지 보여야 한다. 이 주제는 harness engineering, getting started, permissions와 연결된다.

운영 루프

루프는 다섯 단계다. action을 정의하고, proof를 고르고, Claude Code가 가장 작은 유용한 일을 하게 하고, output을 검증하고, 다음 revenue action을 기록한다. 여기서 proof는 코드 실행만이 아니다. approval count, denied commands, rollback notes, deploy proof, consultation intent를 본다. 이 필드가 보이면 추측으로 글을 고치지 않는다.

1. Read-only repo mapping은 마지막 note에 읽은 범위를 남긴다면 기본 허용으로 둘 수 있다.

2. Content edit은 diff review, build, public URL verification을 필수로 하면 허용하기 쉽다.

3. Secrets, billing, customer data, force push는 agent가 정확해도 owner approval로 남긴다.

복사해서 쓰는 starter

permission_risk_register:
  - action: "read repository files"
    default: "allow"
    proof: "list files read in the final note"
  - action: "edit content files"
    default: "allow after diff review"
    proof: "build passes and URL matches the slug"
  - action: "deploy production"
    default: "ask first"
    proof: "build log, deploy URL, rollback note"
  - action: "touch secrets or billing"
    default: "never without owner approval"
    proof: "human approval id"

현장 예시 세 가지

예시 1. Read-only repo mapping은 마지막 note에 읽은 범위를 남긴다면 기본 허용으로 둘 수 있다.

예시 2. Content edit은 diff review, build, public URL verification을 필수로 하면 허용하기 쉽다.

예시 3. Secrets, billing, customer data, force push는 agent가 정확해도 owner approval로 남긴다.

셀프 리뷰 체크

이 workflow를 습관으로 만들기 전에 release note처럼 글을 다시 본다. 첫 번째는 scope다. 독자가 언제 permission risk register를 쓰고, 언제 더 작은 checklist로 충분한지 알아야 한다. 두 번째는 proof다. 모든 권장 사항은 command, URL, diff, metric 중 하나로 이어져야 한다. 세 번째는 routing이다. free PDF, Gumroad guide, consultation path가 서로 경쟁하지 말고 다른 긴급도에 답해야 한다.

작은 owner rule도 둔다. artifact owner, verification owner, next CTA experiment owner를 구분한다. solo workflow라면 같은 사람이어도 된다. 하지만 note에는 역할 이름을 남긴다. 이렇게 하면 Claude Code가 publishing, measuring, selling을 하나의 흐린 task로 다루기 어렵다. 다음 run도 어디서 이어갈지 더 쉽게 판단한다.

가장 실용적인 질문은 이것이다. 내일 아침 이 글을 더 쉽게 검증하게 만드는 것은 무엇인가? 답이 screenshot이면 저장한다. 답이 더 강한 prompt이면 prompt pack에 넣는다. 답이 더 명확한 boundary이면 setup note에 넣는다. action, default decision, proof, owner를 적는 작은 risk register는 다음 session에서 살아남을 때만 유용하다.

실패 사례

첫 번째 실패는 PV만 점수로 삼는 것이다. 두 번째는 proof command 없이 변경을 승인하는 것이다. 세 번째는 free PDF나 consultation이 더 맞는 독자에게도 같은 paid product만 보내는 것이다. CTA를 바꾸기 전에 routing rule을 쓰면 이 문제를 줄일 수 있다.

수익 경로

독자는 병목으로 나눈다. command fluency가 필요하면 free PDF 또는 free Gumroad cheatsheet로 보낸다. 같은 일을 매주 반복하면 50 Prompt Templates나 Setup Guide가 맞다. rollout, risk, revenue design이 문제라면 consultation이다. 이 글에서는 Setup Guide는 policy baseline에, consultation은 production과 revenue approval 설계에 맞다.

검증 지표

게시 후에는 HTTP 200만 보지 않는다. h1, canonical, hero image, 본문 첫 부분, CTA link, mobile layout, language를 확인한다. 그리고 approval count, denied commands, rollback notes, deploy proof, consultation intent를 본다. 지표가 움직이지 않으면 전체 rewrite보다 첫 번째 구체 예시 근처의 CTA를 먼저 고친다.