Claude Code 승인 판단 로그: read/edit/run/deploy를 헷갈리지 않는 법

금요일 저녁, 저는 Claude Code에게 “이 페이지의 링크만 고쳐줘”라고 부탁했습니다. 돌아온 건 화면을 가득 채운 확인 메시지였어요. “이 명령을 실행해도 될까요?”라고 묻길래, 지쳐 있던 저는 내용을 제대로 읽지도 않고 Enter를 눌렀습니다.

다음 날 아침, 운영 사이트의 요금 표시가 바뀌어 있었습니다. 링크를 고치는 김에, AI가 가격을 적어둔 다른 파일까지 “이왕 하는 김에” 손을 댄 거였죠. 허락 버튼을 누른 건 틀림없이 저였습니다.

문제는 AI가 똑똑해서가 아닙니다. 어제 OK했던 작업과 오늘 막아야 할 작업의 경계선이 제 머릿속에만 있어서 매번 흔들렸다는 게 진짜 문제였어요. 그날 기분에 따라 “뭐 괜찮겠지”가 움직인다면, 사고는 시간문제입니다. 오늘은 이 경계선을 머리 밖으로 꺼내는 “승인 로그” 만드는 법을 적어보겠습니다.

핵심 요약

Claude Code 승인은 “읽기·수정·실행·배포” 4가지로 나누면 헷갈림이 사라집니다.
각 작업을 “허용·확인·금지”로 분류하고, 이유와 확인 명령을 매일 한 파일에 남깁니다.
AI에게 맡기는 건 사전 조사와 초안, 사람이 쥐는 건 요금·운영 배포·삭제 4종류입니다.
복사해서 쓰는 로그 템플릿과, AI에게 분류를 초안 작성시키는 프롬프트를 넣었습니다.
망설여지면 “허용”으로 두지 않습니다. 이것만으로 “김에 사고”가 거의 사라졌습니다.

승인을 “읽기·수정·실행·배포” 4가지로 나눈다

Claude Code를 쓰다 보면 온갖 확인 메시지가 날아옵니다. 이걸 전부 한 덩어리로 묶어 “Yes냐 No냐”로 생각하니까 매번 힘든 거예요. 할 일을 4종류로 쪼개면 판단이 단숨에 가벼워집니다.

읽기: 파일이나 로그의 내용을 보기만 하는 것. 기본은 허용해도 문제없습니다.
수정: 파일을 고쳐 쓰는 것. 글의 오타라면 가볍게 가도 됩니다. 요금표는 다른 얘기죠.
실행: 명령을 돌리는 것. 동작 확인은 가볍게, 하지만 바깥에 영향을 주는 건 신중하게.
배포: 운영 사이트에 반영하는 것. 여기는 늘 마지막 방어선으로 다룹니다.

같은 “수정”이라도 블로그 본문의 오타와 결제 설정 파일은 무게가 완전히 다릅니다. 그래서 저는 작업의 종류뿐 아니라 “어느 파일인가”까지 한 세트로 정하기로 했습니다.

판단을 3단계로 분류한다

4종류로 나눴으면, 각각을 3단계로 분류합니다. 어려운 말은 필요 없습니다.

단계	의미	예시
허용	말없이 진행해도 됨	글 폴더 읽기, 본문 오타 수정
확인	한 번 나에게 묻기	요금 파일 수정, 운영에 배포
금지	이번엔 시키지 않음	파일 일괄 삭제, 강제 덮어쓰기

요령은 하나뿐입니다. 조금이라도 망설여지면 “허용”에 넣지 않는다. 일단 “확인”에 둡니다. 나중에 “이건 매번 안전하네” 하고 알게 된 다음에 “허용”으로 승격하면 됩니다. 처음엔 전부 고삐를 쥐고, 안전하다고 확인된 것만 고삐를 풉니다. 이 순서만 지키면 서두에 나온 요금 사고 같은 일은 일어나지 않습니다.

매일 한 파일에 남긴다: 로그 템플릿

머리로 외우려 하니까 무너집니다. 하루에 한 파일, 그날의 분류를 적어 남기기만 하면 됩니다. 형식은 뭐든 좋지만, 저는 이 형태로 정착했습니다. 복사해서 그대로 쓸 수 있습니다.

{
  "date": "2026-06-07",
  "범위": "글 본문과 도입 동선 교체만",
  "읽기":   { "허용": ["site/src/content/**", "site/src/lib/gumroadProducts.ts"] },
  "수정":   { "허용": ["새 글 파일"], "확인": ["요금", "결제 설정", "운영 시크릿"] },
  "실행":   { "허용": ["npm run build", "공개 URL 표시 확인"], "확인": ["배포", "git push"] },
  "배포":   { "확인할 것": ["빌드가 통과한다", "공개 URL의 h1이 올바르다", "각 언어 표시를 눈으로 확인"] },
  "다음 메모": "요금은 앞으로도 확인 유지. 글 동선 교체는 안전 확인 후 허용으로."
}

쓰는 데 2~~3분입니다. 하지만 이 2~~3분이, 다음 날 “어, 이거 어제 어떻게 했더라” 하고 고민하는 10분을 없애줍니다. 범위 한 줄이 은근히 효과적입니다. 오늘 작업이 어디까지인지 먼저 적어두면, AI가 그 바깥으로 나간 순간 알아챌 수 있습니다.

AI에게 맡기는 범위와, 사람이 판단하는 범위

여기를 섞으면 사고가 납니다. 경계선을 분명히 해둡니다.

AI에게 맡겨도 되는 것

어느 파일이 관련 있을지 찾기
변경 초안 만들기
변경 전후의 차이를 보여주기
“빌드가 통과하는지” 확인하는 명령 돌리기

사람이 반드시 쥐어야 하는 것

요금·결제·신청 폼을 건드리는 변경
운영 사이트로의 배포 (배포 버튼은 내가 직접 누른다)
파일이나 데이터의 삭제
되돌리는 법을 설명할 수 없는 작업

제 규칙은 단순합니다. “돈” “운영” “지운다” “되돌릴 수 없다” 이 4가지가 얽히면 반드시 내 손으로 최종 판단한다. 뒤집어 말하면, 그 외의 사전 조사나 초안은 사양 없이 AI에게 던집니다. 이 경계선의 사고방식은 엔지니어가 아닌 사람을 위한 Claude Code 입문에서도 다뤘지만, 전문 지식이 없어도 “돈과 운영만은 내가”라고 정해두면 충분히 지킬 수 있습니다.

AI에게 분류를 초안으로 만들게 하는 프롬프트

분류 그 자체를 AI에게 거들게 할 수도 있습니다. 다만, 나온 결과를 그대로 믿지 말고 마지막엔 직접 봅니다. 다음 지시문을 그대로 붙여서 쓸 수 있습니다.

오늘의 Claude Code 작업에 대해, 작업을 "허용·확인·금지"로 분류해 주세요.
대상은 다음 4종류입니다: 읽기 / 수정 / 실행 / 배포.

각 항목에 대해 다음을 돌려주세요:
1. 허용해도 되는 작업 목록
2. 한 번 확인해야 할 작업 목록
3. 이번엔 금지할 작업 목록
4. 안전을 확인하기 위한 확인 명령 (예: npm run build)
5. 다음을 위한 메모 (확인 → 허용으로 올리는 조건)

요금·결제·운영 배포·삭제에 관련된 작업은, 망설여지면 "확인"에 넣어 주세요.

포인트는 마지막 한 줄입니다. 이걸 넣어두면 AI가 멋대로 “이건 허용해도 되겠죠”라며 판단을 느슨하게 푸는 걸 막을 수 있습니다. 프롬프트 작성법을 더 다듬고 싶은 분은 Claude Code 프롬프트 설계도 함께 보세요.

이런 상황에서 효과적이다 (3가지)

1. 블로그 글 교체 인기 글 아래에 있는 신청 링크 하나만 바꾸고 싶다. 이럴 때 “관련 있을 만한 곳을 고쳐줘”라고 부탁하면 범위가 너무 넓어집니다. 먼저 “건드려도 되는 파일” “건드리지 않을 파일” “확인할 공개 URL”을 로그에 적어둡니다. 그러면 작업 후 확인이 “왠지 괜찮아 보인다”에서 “이 근거라면 배포해도 된다”로 바뀝니다.

2. 문의 분류 들어온 문의를 AI에게 읽혀서, 가망 있어 보이는 것만 알려달라고 한다. 읽는 건 “허용”이어도 됩니다. 하지만 고객 리스트 등록은 “확인”으로 남깁니다. AI가 분류를 틀려도, 멋대로 운영 데이터에 쓰기 전에 멈춥니다.

3. 다국어 글 배포 전 점검 frontmatter의 언어 설정이 맞아도 본문이 영어 그대로 남아 있는 경우가 있습니다. 각 언어로 제목·도입·동선 주변을 보고, 그 언어의 독자가 다음 행동을 이해할 수 있는지 확인합니다. 이 눈 확인을 “배포 전까지 확인 항목”으로 로그에 고정해 둡니다.

복사해서 동작하는: 승인 로그 점검 스크립트

로그를 적어도, 정작 중요한 “배포 전 확인”을 건너뛰면 의미가 없습니다. 그래서 배포 전 반드시 통과시키는 확인을 스크립트 한 개로 만들어 둡니다. 빌드가 통과하는지, 운영 URL의 제목이 올바른지를 기계에 확인시키는 예시입니다. Node.js가 있으면 동작합니다.

node check-before-deploy.mjs https://claudecode-lab.com/ko/blog/claude-code-permission-decision-log/

내용은 이게 전부입니다.

import { execSync } from "node:child_process";

// 인자로 넘긴 공개 URL을 확인한다
const url = process.argv[2];
if (!url) {
  console.error("확인할 공개 URL을 넘겨주세요");
  process.exit(1);
}

// 1. 빌드가 통과하는지 확인한다 (여기서 떨어지면 배포하지 않는다)
try {
  console.log("빌드를 확인하는 중...");
  execSync("npm run build", { stdio: "inherit" });
} catch {
  console.error("빌드가 실패했습니다. 배포를 중단합니다.");
  process.exit(1);
}

// 2. 공개 URL에 h1 제목이 한 개 있는지 확인한다
const res = await fetch(url);
const html = await res.text();
const h1Count = (html.match(/<h1[\s>]/g) || []).length;

if (res.status !== 200) {
  console.error(`URL을 열 수 없습니다 (상태 코드: ${res.status}). 배포를 재검토합니다.`);
  process.exit(1);
}
if (h1Count !== 1) {
  console.error(`h1 제목이 ${h1Count}개 있습니다. 1개가 되도록 고친 뒤 배포합니다.`);
  process.exit(1);
}

console.log("빌드·URL·제목 확인이 통과했습니다. 배포해도 됩니다.");

이 스크립트가 초록색이 되고 나서야 비로소 “배포”를 허용합니다. 뒤집어 말하면, 초록색이 되지 않는 건 무슨 일이 있어도 배포하지 않습니다. 판단을 사람의 기분이 아니라 기계의 O/X에 맡기는 게 요령입니다.

자주 하는 실수와 고치는 법

솔직히 적자면, 저는 한 차례 다 겪었습니다.

이유를 적지 않고 설정만 바꾼다. 설정 파일만 업데이트하고 “왜 그랬는지”를 남기지 않으면, 다음 날의 내가 같은 고민을 반복합니다. 고치는 법은 단순합니다. 로그의 “다음 메모”에 한 줄만 이유를 적습니다. “요금은 신뢰에 직결되니 확인 유지”처럼요.

기세에 휩쓸려 배포를 허용한다. 빌드가 통과한 기세 그대로 배포까지 허용해 버립니다. 하지만 배포 전 확인은 별개입니다. 운영 URL의 제목·표시 깨짐·모바일 표시까지 보는 항목을 “확인할 것”에 고정하고, 기계 점검을 통과하기 전엔 배포하지 않습니다.

가벼운 작업과 무거운 작업을 똑같이 취급한다. 본문 오타 수정과 신청 링크·가격 변경을 같은 “허용”으로 돌리면, 언젠가 서두의 사고가 일어납니다. gumroad 링크나 요금, 폼을 건드리는 작업은 오타 수정과는 다른 칸에 나눕니다. 이 경계선은 CLAUDE.md 작성법에 규칙으로 적어두면, 매번 고민하지 않아도 됩니다.

자주 묻는 질문

Q. 승인 로그와 보안 설정은 무엇이 다른가요? A. 보안 설정은 “무엇을 허용할지”를 고정하는 것, 승인 로그는 “오늘 그 판단을 왜 내렸는지”를 남기는 것입니다. 설정은 규칙, 로그는 일기에 가깝습니다. 둘 다 있으면, 다음 날의 나나 팀이 같은 판단을 재현할 수 있습니다.

Q. 매일 쓰는 건 번거롭습니다. 이어가는 요령은? A. 완벽을 노리지 않는 것입니다. 처음엔 “수정”과 “배포” 두 칸만으로도 충분히 효과적입니다. 2~3분이면 쓸 수 있는 형태로 만들어서, 작업을 시작하기 전 첫 입력으로 붙여 넣는 습관으로 만들면 이어집니다.

Q. AI가 제안하는 분류는 믿어도 되나요? A. 초안으로는 편리하지만, 최종 판단은 사람이 합니다. 특히 요금·운영·삭제에 관련된 줄은, AI가 “허용해도 된다”고 말해도 직접 확인으로 내립니다. 판단의 수고를 줄이는 게 목적이지, 판단 그 자체를 통째로 떠넘기는 도구가 아닙니다.

Q. 팀에서 쓸 때 주의할 점은? A. 로그를 한 곳에 모으고, “허용”에 넣는 작업은 누가 봐도 같은 판단이 되는 이유를 적는 것입니다. 이유 없는 허용은 사람마다 해석이 흔들려 사고의 원인이 됩니다. 승인을 단계적으로 넓히는 사고방식은 안전하게 자율성을 올리는 절차도 참고가 됩니다.

Q. 작은 블로그에도 이만큼 필요한가요? A. 규모가 작을수록 요금이나 링크 사고가 직접 매출에 영향을 줍니다. 오히려 개인이나 소규모 팀이야말로 “돈과 운영만은 확인”이라는 규칙 하나부터 시작할 가치가 있습니다.

참고 링크

실제로 시험해 본 결과

이 승인 로그를 2주 정도 이어가면서 가장 효과적이었던 건 뜻밖에도 “가벼운 작업”이었습니다. 글의 오타 수정은 안심하고 허용에 둘 수 있지만, 요금이나 링크, 신청 폼, 배포 설정은 확인에 남깁니다. 이 구분을 먼저 적어두는 것만으로, AI의 답을 읽은 뒤에 “이건 허용해도 되는 작업이었나” 하고 매번 다시 고민하는 수고가 사라졌습니다.

망설임이 나오기 쉬웠던 건 역시 “실행”과 “배포”였습니다. 빌드는 허용해도 되지만, 운영 URL을 확인하지 않은 채로의 배포는 아직 이릅니다. 한 번 제목·표시 깨짐·모바일 표시까지 눈으로 확인하고 나서는, 같은 종류의 배포를 다음부터 허용으로 올릴 수 있었습니다. 이렇게 단계가 기록에 남으니, 승인 로그는 딱딱한 보안 문서라기보다 매일의 판단을 가볍게 하는 메모로 쓰는 게 가장 현실적이라는 게 지금의 실감입니다.

권한의 경계선을 자기 팀에 맞게 다듬고 싶다, 운영 배포 규칙을 함께 정하고 싶다는 경우에는 연수·상담에서 구체적인 운영으로 풀어낼 수 있습니다.