Claude Code에 어디까지 맡길까? 사고 안 나는 자율도 4단계 규칙

금요일 밤, 저는 “이 블로그 옛날 글들, 깨진 링크만 고쳐 둬”라고 Claude Code에 부탁하고 잠들었습니다. 다음 날 아침 커밋 기록을 보니 글 12편이 바뀌어 있었습니다. 링크는 분명히 고쳐져 있었죠. 그런데 김에 제목 표현까지 “다듬어” 놓았고, 제가 일부러 남겨 둔 옛날 표현까지 덮어쓰여 있었습니다.

되돌리는 데 두 시간이 걸렸습니다. 똑똑할 Claude Code가 왜 이런 쓸데없는 짓을 했을까요. 답은 단순합니다. 제가 “어디까지 해도 되는지”를 한 번도 알려 주지 않았기 때문입니다.

반대 경우도 있습니다. 무서워진 나머지 이번엔 한 줄 고칠 때마다 “이거 실행해도 돼?”라고 묻는 설정으로 바꿨더니, 30분 만에 승인 버튼 누르는 데 지쳐 결국 제가 직접 쓰는 게 더 빨랐습니다. 너무 맡겨서 사고가 나거나, 너무 막아서 지치거나. 많은 사람이 이 양 극단 사이에서 길을 잃습니다.

이 글은 그 헤맴을 끝내기 위한 “자율도 4단계” 이야기입니다. 읽히기만, 고치게 하기, 공개시키기, 사람만 손대기 — 이 네 가지를 처음에 선 그어 두면 매번 하던 판단이 거의 사라집니다.

핵심 요약

• Claude Code에 맡기는 작업은 위험도에 따라 4단계로 나누면 판단이 편해집니다. 읽기만 / 되돌릴 수 있는 수정 / 공개·반영 / 사람 전용.
• 각 단계에는 “끝났다는 증거”를 반드시 하나 정합니다. 차이(diff)가 나온다, 빌드가 통과한다, 공개 URL이 맞다 같은 것입니다.
• 삭제·운영 데이터·결제·force push는 익숙해져도 자동화하지 않습니다. 여기만은 매번 사람이 누릅니다.
• 단계는 YAML 한 장에 적어 CLAUDE.md 가까이에 두면, Claude Code 스스로 “지금 몇 단계인지” 자기 신고하게 됩니다.
• 처음엔 한 단계 낮게 시작하고, 안전하다고 확인한 작업만 나중에 올립니다. 반대는 하지 않습니다.

왜 “똑똑함”보다 “선 긋기”인가

Claude Code에서 막히는 사람 대부분은 모델 성능이 아니라 작업을 닫는 방식에서 실패합니다. 도입부의 저도 그랬습니다. 지시 자체는 나쁘지 않았어요. 다만 “링크만”이라는 범위를 문장으로만 전달했습니다. 문장으로 하는 부탁은 바쁜 아침에 동료에게 던지는 말 한마디와 같아서, 해석이 쉽게 어긋납니다.

여기서 효과를 내는 게 위험도에 따른 선 긋기입니다. 해도 되는 일을 “부탁의 문장”이 아니라 “단계”로 정해 둡니다. 그러면 Claude Code가 뭔가 하려 할 때마다 “그건 몇 단계 작업인가”를 대조할 수 있습니다. 애매한 한국어 해석 다툼이 기계적인 점검으로 바뀌는 겁니다.

이 발상은 새로운 게 아닙니다. 공장에서도 견학만 하는 사람, 부품을 조립하는 사람, 출하 버튼을 누르는 사람, 금고를 여는 사람은 처음부터 권한이 나뉘어 있습니다. Claude Code에도 같은 선을 그을 뿐입니다.

4단계의 내용

제가 실제로 쓰는 4단계는 다음과 같습니다. 표로 먼저 전체 그림을 보여 드리죠.

단계	시킬 일	끝났다는 증거
0 읽기만	파일 구조 파악, 위험 요소 정리, 확인 명령어 제안	마지막 메모에 “읽은 파일 목록”이 있다
1 되돌릴 수 있는 수정	글 한 편 수정, 테스트 한 건 갱신	diff가 나오고 빌드가 통과한다
2 공개·반영	빌드 후 배포, 공개 URL 확인	h1·정규 URL·동선·되돌리기 절차가 갖춰진다
3 사람 전용	(Claude Code에는 안 시킴)	—

단계 3에 들어가는 건 비밀 키, 결제, 운영 데이터, force push입니다. 여기는 아무리 익숙해져도 자동화하지 않습니다. 틀렸을 때의 손실이 아낄 수 있는 수고와 균형이 맞지 않기 때문입니다.

각 단계에서 중요한 건 “끝났다는 증거”를 반드시 정해 두는 것입니다. 증거가 없으면 Claude Code가 “끝났습니다”라고 해도 정말 끝났는지 알 수 없습니다. diff가 나온다, 빌드가 통과한다, 공개 URL을 열어 h1이 맞다 — 이렇게 기계로 확인할 수 있는 것을 증거로 고릅니다.

AI에 맡길 범위와, 사람이 정할 범위

선 긋기를 분명히 하면 역할 분담도 자연스럽게 정해집니다.

Claude Code에 맡겨도 되는 건 손이 많이 가고 결과를 기계로 확인할 수 있는 작업입니다. 많은 파일을 읽고 요약하기, 정해진 형식으로 글 고치기, 테스트를 돌려 로그 읽기. 이런 건 사람보다 빠르고 정확합니다.

사람이 정해야 하는 건 되돌릴 수 없는 판단과, 손실이 큰 작업입니다. 이 글을 정말 공개해도 되는가, 이 옛날 표현을 지워도 되는가, 이 고객 데이터를 덮어써도 되는가. 여기는 Claude Code에 “제안”은 시켜도 “실행”은 사람이 누릅니다.

헷갈릴 때 기준은 하나입니다. “실패해도 10분 안에 되돌릴 수 있는가?” 되돌릴 수 있으면 단계 1, 못 되돌리면 단계 2나 3입니다. 도입부의 제 사고는 되돌리는 데 두 시간이 걸린 시점에서, 사실은 단계 2의 신중함이 필요한 작업이었던 겁니다.

복붙해서 쓰는 단계 정의

단계를 머릿속에만 두면 결국 흔들립니다. YAML 한 장으로 적어 프로젝트 바로 아래에 autonomy.yml로 두세요. CLAUDE.md에서 참조하게 하면 Claude Code 스스로 “지금은 단계 1이라 공개는 안 합니다”라고 자기 신고하게 됩니다.

# autonomy.yml — Claude Code에 건네는 자율도 선 긋기
safe_autonomy_ladder:
  level_0_read_only:
    allowed: ["파일 구조 파악", "위험 요소 정리", "확인 명령어 제안"]
    proof: "마지막 메모에 읽은 파일 목록이 있다"
  level_1_reversible_edit:
    allowed: ["글 한 편 수정", "테스트 한 건 갱신"]
    proof: "git diff가 나오고 build가 통과한다"
  level_2_publish_or_deploy:
    allowed: ["build 후 배포", "공개 URL 확인"]
    proof: "h1·정규 URL·동선·되돌리기 절차가 갖춰진다"
  level_3_owner_only:
    allowed: []
    examples: ["비밀 키", "결제", "force push", "고객 데이터"]

CLAUDE.md에는 이 한 문장만 더하면 충분합니다.

작업 전에 autonomy.yml을 읽고, 이번 작업이 몇 단계인지 가장 먼저 선언할 것.
단계 2 이상의 작업은 실행하지 말고 사람의 승인을 기다릴 것.

단계를 기계로 점검하는 검증 스크립트

선언만 시키는 건 불안해서, 저는 “단계 2 작업(공개)이 증거 없이 이뤄지지 않았는지”를 기계로 감시합니다. 아래 스크립트는 배포 후 공개 URL을 가져와 h1이 비어 있지 않은지, 정규 URL이 자기 slug를 가리키는지 확인합니다. Node.js 18 이상이면 그대로 돌아갑니다.

// verify-publish.mjs — 단계 2의 "끝났다는 증거"를 기계로 확인한다
// 사용법: node verify-publish.mjs https://claudecode-lab.com/blog/your-slug

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

const res = await fetch(url);
if (res.status !== 200) {
  console.error(`HTTP ${res.status}: 아직 공개되지 않았습니다`);
  process.exit(1);
}

const html = await res.text();

// h1이 내용을 가진 채 존재하는가
const h1 = html.match(/<h1[^>]*>(.*?)<\/h1>/s);
const hasH1 = Boolean(h1 && h1[1].replace(/<[^>]+>/g, "").trim());

// 정규 URL이 이 페이지 자신을 가리키는가
const canonical = html.match(/<link[^>]+rel=["']canonical["'][^>]*>/i);
const canonicalOk = Boolean(canonical && canonical[0].includes(new URL(url).pathname));

console.log(`h1 있음:        ${hasH1 ? "OK" : "NG"}`);
console.log(`정규 URL 일치:  ${canonicalOk ? "OK" : "NG"}`);

if (hasH1 && canonicalOk) {
  console.log("단계 2의 증거가 갖춰졌습니다. 공개 완료로 봐도 됩니다.");
} else {
  console.error("증거가 부족합니다. 아직 완료로 처리하지 마세요.");
  process.exit(1);
}

HTTP 200만 성공이라고 믿으면, 메인 페이지의 fallback이나 옛날 글이 나와도 알아채지 못합니다. h1과 정규 URL까지 봐야 비로소 “이 단계는 끝났다”라고 말할 수 있습니다.

이런 상황에서 효과를 봅니다 (3가지)

1. 새 리포지터리에 막 들어갔을 때 구조도 명령어도 모르는 상태에서 다짜고짜 편집시키면 설정 파일을 망가뜨리기 쉽습니다. 처음엔 단계 0만 허용해서 파일 구성·쓸 수 있는 명령어·만지면 위험한 곳을 보고하게 합니다. 지도가 생긴 뒤에 단계 1로 올립니다.

2. 글의 오타 수정 이건 단계 1이면 충분합니다. diff가 나오고 빌드가 통과하면 증거 완성입니다. 도입부의 제 사고는 여기서 “수정은 오타만. 문장 표현은 바꾸지 마”라고 범위를 명시했다면 막을 수 있었습니다. Claude Code에 건네는 부탁 문장의 틀은 이렇습니다.

단계 1로 작업해 주세요.
대상: content/blog/foo.mdx 의 명백한 오타만
하지 말 것: 제목 바꿔 말하기, 문장 표현 변경, 다른 파일 편집
끝나면 git diff를 보여 주고, 변경이 오타 수정만인지 스스로 확인해 주세요.

3. 운영 공개 직전 단계 2에서는 빌드가 통과하는지·환경 변수가 갖춰졌는지·diff가 예상대로인지·되돌리기 절차가 있는지를 반드시 확인하게 합니다. 위 검증 스크립트를 마지막에 돌리면 공개 URL의 내용까지 점검할 수 있습니다.

제가 저지른 실수 3가지

솔직히 말하면, 이 4단계에 정착하기까지 여러 번 사고를 쳤습니다.

첫째는 단계를 한 번에 건너뛴 것입니다. 단계 0을 빼고 다짜고짜 단계 1로 대량 편집시켰더니, 검증할 수 없을 만큼 큰 diff가 나와 어디가 맞는지 저조차 알 수 없게 됐습니다. 지금은 반드시 0부터 차례로 올립니다.

둘째는 로컬 빌드만으로 “완료”로 처리한 것입니다. 손에서 통과했으니 공개했죠. 그런데 운영 환경에선 옛날 페이지가 표시되고 있었고, 반나절을 알아채지 못했습니다. 그 뒤로는 공개 URL의 h1과 정규 URL을 볼 때까지 완료로 처리하지 않습니다.

셋째는 승인을 제 눈에만 의존한 것입니다. “마지막에 내가 확인하면 돼”는 지친 밤에 반드시 무너집니다. 글자 수·깨진 링크·타입 에러처럼 기계로 알 수 있는 점검을 단계의 “증거”에 넣고 나서야 한밤중의 놓침이 크게 줄었습니다.

시작하는 법

처음부터 완전 자동의 똑똑한 에이전트를 노리지 마세요. 실패해도 되돌릴 수 있는 작은 일을 하나 고릅니다. 초안 오타 점검, 변경의 1차 리뷰, 스테이징 공개 전 확인. 이 정도가 딱 좋습니다.

순서는 늘 같습니다. ① 읽힐 범위를 좁게 정한다 → ② 결과물을 분명히 한다 → ③ 확인은 되도록 명령어에 시킨다 → ④ 위험한 작업(삭제·운영 데이터·결제·force push)은 처음엔 전부 “사람에게 묻기”로 둔다. 안전하다고 확인한 작업만 나중에 한 단계씩 올립니다. 반대로 낮추는 일은 하지 않습니다.

권한의 세세한 설정에서 막힌다면 Claude Code 시작하기를, CLAUDE.md에 단계 규칙을 적는 방법은 CLAUDE.md 작성법을 먼저 보면 이 4단계를 그대로 설정으로 옮길 수 있습니다. 엔지니어가 아닌 사람을 팀에 들이는 전제라면 비엔지니어용 사용법도 함께 보세요.

자주 묻는 질문

Q. 단계 나누기는 매번 손으로 설정하나요? 아니요. autonomy.yml을 한 장 만들어 CLAUDE.md에서 참조하게 하면, 이후엔 Claude Code가 스스로 “지금은 단계 1입니다”라고 선언합니다. 설정은 처음 한 번뿐입니다.

Q. 단계 2의 “공개”까지 자동화해도 괜찮나요? 증거가 기계로 갖춰진다면 익숙해진 뒤에 자동화해도 됩니다. 단, 위 검증 스크립트처럼 공개 URL의 내용을 확인하는 장치를 반드시 끼워 넣으세요. HTTP 200만 믿는 게 제일 위험합니다.

Q. 단계 3에 넣어야 할 작업은 어떻게 구분하나요? “실패하면 사과로 끝나는가, 배상이 필요한가”로 생각하면 빠릅니다. 고객 데이터 덮어쓰기, 결제, 운영 환경 삭제는 후자라 단계 3입니다. 익숙해져도 자동화하지 않습니다.

Q. 작은 팀에도 선 긋기가 필요한가요? 오히려 인원이 적을수록 효과가 큽니다. 누가 승인했는지 애매해지기 쉬워서, 단계 표를 공유해 두면 “이건 누가 OK를 내는 작업인지”가 한눈에 보입니다.

Q. 프롬프트를 잘 짜면 단계 나누기는 필요 없지 않나요? 프롬프트는 해석이 흔들립니다. 좋은 부탁 문장을 쓰는 힘은 따로 프롬프트 실전에서 키우되, 단계 나누기는 “문장 실력에 의존하지 않는 안전망”입니다. 둘 다 있으면 가장 강합니다.

실제로 해 본 결과

이 4단계를 제 블로그 운영에 넣은 뒤로, 도입부 같은 “부탁하지 않은 일까지 당하는” 사고는 0이 됐습니다. 확인한 건 두 가지입니다.

하나는, autonomy.yml을 CLAUDE.md에서 참조하게 했더니 Claude Code가 작업 전에 “이번엔 단계 1이라 공개는 안 합니다”라고 스스로 선언하게 된 것입니다. 선 긋기를 문장이 아니라 단계로 건네면 해석이 흔들리지 않는다고 실감했습니다.

또 하나는, verify-publish.mjs를 공개 후 반드시 돌리게 했더니, 예전에 반나절 못 알아챘던 “옛날 페이지가 운영에 나오는” 현상을 공개 직후에 잡아낼 수 있게 된 것입니다. h1과 정규 URL만 봐도 HTTP 200의 함정은 메워집니다.

똑똑한 모델을 찾기보다, 넘어져도 다치지 않는 단계를 먼저 정한다. 돌아가는 듯 보여도 이게 제일 빠르다는 게 지금의 실감입니다. 팀에서 Claude Code 권한 규칙을 정리하고 싶은 단계라면 연수·상담에서 함께 선 긋기를 설계할 수 있습니다. 공식 권한 설정은 Anthropic 문서도 함께 확인하세요.