Claude Code에 오늘 어디까지 맡길까? 승인 라인을 4단계로 정하는 워크시트

금요일 저녁, 저는 스테이징 환경에 작은 수정 하나만 넣을 생각이었습니다.

“문서 오타 좀 고치고, 김에 빌드가 통과하는지 봐 줘”라고만 부탁했더니, Claude Code는 오타를 고친 뒤 멋대로 의존 패키지를 두 개 업데이트하고, .env.production 참조까지 바꿔 놓았습니다. 로컬 빌드는 통과했으니 본인(AI)은 “완료했습니다”라며 태평한 얼굴입니다.

제가 식은땀을 흘린 건, 변경 diff를 끝까지 보고 나서야 그 사실을 알아챘다는 점입니다. AI가 나빴다기보다, “어디까지 해도 되는지”를 제가 한 번도 말로 정해두지 않았던 게 원인이었습니다.

반대로 어떤 날엔 “허용하시겠습니까? Yes/No”가 30번쯤 연달아 뜨면서, 커밋 하나 만드는 데 손가락 힘을 다 써버린 적도 있습니다. 너무 넓히면 사고가 나고, 너무 조이면 일이 안 나간다. 이 글은 그 사이에서 딱 알맞은 선을 긋기 위한 한 장짜리 워크시트 이야기입니다.

핵심 요약

• Claude Code에 맡길 작업을 “읽기만”, “고치기만”, “공개하기”, “비밀 정보 만지기”의 4단계로 나눕니다.
• 단계마다 “누가 마지막에 OK를 내는가”와 “무엇을 보면 안전하다고 말할 수 있는가(증거)“를 먼저 정해 둡니다.
• 0단계와 1단계는 AI에 맡기고, 2단계는 사람이 확인, 3단계는 담당자만 손을 댑니다.
• 아침에 “오늘은 여기까지”라고 한 문장으로 선언하고 작업을 시작하면, 승인 횟수가 단번에 줄어듭니다.
• 복사해서 쓰는 대장(台帳) 코드와, 매일 아침 1분이면 정하는 템플릿을 준비했습니다.

왜 “승인 예산”을 먼저 정하는가

승인 때문에 지치는 원인은 Claude Code의 성능이 아닙니다. 오늘 어디까지 허용할지 정하지 않고 달리기 시작한 것입니다.

정하지 않으면 사람은 둘 중 하나로 기웁니다. 귀찮다고 전부 “허용”을 눌러대다가, 어느 날 위험한 작업까지 통과시켜 버린다. 아니면 지나치게 신중해져서 오타 수정에까지 확인을 끼우고, 일이 안 나가게 된다. 둘 다 판단을 “그때그때 기분”에 맡기고 있다는 게 공통점입니다.

그래서 쓰는 게 “승인 예산”이라는 생각법입니다. 돈의 예산과 똑같이, 오늘은 이 레인까지 자유, 그 너머는 사람이 판단이라고 미리 칸을 정해 둡니다. 칸이 있으면 AI의 답변을 볼 때마다 두근거릴 필요가 없어집니다. 봐야 할 건 “AI가 똑똑한가 아닌가”가 아니라 “어느 레인에서 멈췄는가”가 됩니다.

판단 기준을 말로 정해 두면 팀에서도 다투지 않습니다. “왠지 불안해서 멈췄다”가 아니라 “이건 2단계니까 사람이 확인할 차례”라고 말할 수 있기 때문입니다. 권한 설계의 사고방식 자체는 Claude Code 입문 가이드에서도 다루지만, 여기서는 더 현실적으로 “오늘의 선 긋기”에 집중합니다.

맡길 작업을 4단계로 나눈다

먼저 Claude Code에 시키고 싶은 작업을 위험한 순서대로 4개 단계로 분류합니다. 어렵게 생각하지 말고, “되돌릴 수 있는가”, “공개되는가”, “돈이나 비밀에 닿는가”만으로 나눕니다.

단계	작업 예시	마지막에 OK를 내는 사람	안전하다고 말할 증거
0	파일을 읽는다, 구성을 파악한다	AI에 맡김	읽은 범위의 목록
1	되돌릴 수 있는 파일 1개를 고친다	AI(사람이 diff를 봄)	diff와 빌드 결과
2	공개 사이트에 반영한다	사람이 판단	공개 URL과 롤백 절차
3	비밀 정보·과금·고객 데이터를 만진다	담당자만	문서로 된 승인

이 표의 핵심은 오른쪽 두 칸입니다. “누가 OK를 내는가”와 “무엇을 보면 안전하다고 말할 수 있는가”를 작업을 시작하기 전에 정해 둡니다. 나중에 정하면, AI가 “완료했습니다”라고 말한 기세에 휩쓸려 확인을 건너뛰게 되기 때문입니다.

1단계의 “되돌릴 수 있는”이 포인트입니다. 오타 수정이나 주석 추가는 틀려도 금방 되돌릴 수 있습니다. 그래서 AI에 맡기고, 사람은 diff를 슥 보기만 하면 됩니다. 반면 의존 패키지 업데이트는 2단계로 올립니다. 작아 보여도 영향 범위가 읽히지 않기 때문입니다. 서두의 제 사고는, 바로 이것을 1단계 취급으로 했던 게 원인이었습니다.

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

선 긋기를 조금 더 또렷하게 합니다. AI에 맡겨도 되는 건 틀려도 금방 알아채고, 금방 되돌릴 수 있는 작업입니다. 사람이 판단해야 하는 건 한 번 실행하면 밖으로 영향이 나가는 작업입니다.

• AI에 맡긴다: 읽기, 조사, 초안 작성, 되돌릴 수 있는 파일 1개 수정, 테스트 실행
• 사람이 마지막에 판단한다: 공개, 운영 데이터 변경, 외부 서비스 등록, 의존 업데이트, 삭제

망설여지면 단계를 하나 올린다. 이것만 기억해 두면 크게 빗나가지 않습니다. 안전하다고 확신한 작업만, 나중에 한 단계씩 내려서 자동화해 갑니다. 처음부터 완전 자동을 노리지 않는 게 요령입니다. 이 “단계적으로 승격”하는 사고방식은 프로젝트 규칙을 쓰는 CLAUDE.md 작성법과도 궁합이 좋으니, 정한 선 긋기는 파일에 남겨 두면 재현할 수 있습니다.

복사해서 쓰는 승인 대장

말로만 하면 자꾸 잊어버립니다. 그래서 4단계를 기계가 읽을 수 있는 형태로 만들어, “오늘은 어디까지”를 필터로 뽑을 수 있게 합니다. Node.js가 있으면 그대로 동작합니다.

// 승인 대장: 작업마다 "위험 단계", "담당", "증거"를 갖게 한다
const approvalBudget = [
  { action: "파일을 읽는다",                level: 0, owner: "AI",            proof: "읽은 범위의 목록" },
  { action: "되돌릴 수 있는 파일 1개를 고친다", level: 1, owner: "AI(사람이 확인)", proof: "diff와 빌드 결과" },
  { action: "공개 사이트에 반영한다",        level: 2, owner: "사람",          proof: "공개 URL과 롤백 절차" },
  { action: "비밀 정보나 과금을 만진다",      level: 3, owner: "담당자만",       proof: "문서로 된 승인" },
];

// 오늘의 상한. 0이면 읽기만, 1이면 되돌릴 수 있는 수정까지 AI에 맡긴다
const todayMax = Number(process.env.APPROVAL_MAX ?? 1);

const allowedToday = approvalBudget.filter((item) => item.level <= todayMax);
const needsHuman   = approvalBudget.filter((item) => item.level > todayMax);

console.log(`오늘 AI에 맡길 상한: ${todayMax}단계`);
console.table(allowedToday);
console.log("사람이 판단할 작업:");
console.table(needsHuman);

실행은 이것뿐입니다. 환경 변수로 “오늘의 상한”을 바꿀 수 있습니다.

# 오늘은 "되돌릴 수 있는 수정"까지 맡긴다
APPROVAL_MAX=1 node approval-budget.mjs

# 오늘은 읽기만 하기로 한다
APPROVAL_MAX=0 node approval-budget.mjs

항목 이름은 그대로 두고, action과 proof의 내용을 자기 프로젝트에 맞게 바꿔 쓰세요. Claude Code에 이 코드를 건네면서 “우리 저장소에 맞게 값을 채워 줘”라고 부탁하면, 초안이 금방 만들어집니다.

매일 아침 1분이면 정하는 프롬프트 템플릿

대장이 만들어졌으면, 작업을 시작하기 전에 AI에게 “오늘의 칸”을 전합니다. 다음 문장을 복사해, 빈칸을 채우기만 하면 됩니다.

오늘 작업의 칸을 먼저 정합니다.

- 오늘의 목적: (예: 블로그 글 1편의 오타와 깨진 링크 수정)
- 읽어도 되는 범위: site/src/content/blog/ 만
- 고쳐도 되는 범위: 위 안의 파일 1개만 (되돌릴 수 있는 변경에 한함)
- 실행해도 되는 커맨드: npm run lint, 테스트 실행
- 건드리지 말 것: .env, 운영 배포, 의존 패키지 업데이트, 삭제

규칙:
- 2단계 이상(공개·운영 데이터·의존 업데이트·삭제)은 반드시 나에게 확인하고 멈출 것.
- 고쳤으면 변경 diff와 빌드 결과를 "증거"로 마지막에 정리해서 보여 줄 것.
- "완료했습니다"만으로 끝내지 말고, 어떤 커맨드로 확인했는지 적을 것.

이 한 문장만 있어도 AI는 “일단 전부 해버리기”를 그만두고, 칸 안에서 움직이게 됩니다. 익숙해지면 이 내용을 CLAUDE.md 작성법에 따라 프로젝트 규칙 파일로 옮기면, 매일 아침 붙여넣는 수고도 사라집니다.

이런 현장에서 효과가 있다 (3가지)

1. 블로그나 자료의 양산 점검 “글을 고쳐 줘”만 하면, AI는 본문도 이미지 경로도 링크도 한꺼번에 바꿔버립니다. 승인 대장으로 “본문 오타는 1단계, 공개 반영은 2단계”로 나눠 두면, 문장은 맡기면서 공개 버튼은 자기 손에 남길 수 있습니다. diff와 빌드 결과를 증거로 내게 하면, 한밤중의 재검토가 훨씬 편해집니다.

2. 문의 분류 들어온 문의를 읽고 분류하는 건 0단계라 AI에 맡겨도 됩니다. 하지만 고객 대장에 등록하는 건 3단계입니다. AI가 “상담이 될 것 같다”고 판단해도, 운영 데이터베이스에 쓰는 건 담당자가 버튼을 누를 때까지 보류합니다. 이걸 대장으로 강제하면, 잘못 분류한 손님을 멋대로 등록하는 사고가 사라집니다.

3. 배포 전 한 호흡 공개 반영은 반드시 2단계에 둡니다. 로컬 빌드가 통과한 것만으로 “완료”로 하지 말고, 공개 URL·제목·롤백 절차를 확인할 때까지 멈춥니다. 서두에서 제가 저지른 “의존 패키지의 멋대로 업데이트”도, 2단계를 명시해 뒀다면 반드시 사람 확인에서 멈췄을 것입니다.

자주 빠지는 함정과 고치는 법

가장 많은 건, 전부를 한 번의 의뢰로 끝내려다가, 아무도 검증할 수 없는 거대한 diff를 만드는 것입니다. 고치는 법은 단순합니다. 의뢰를 “한 번에 결과물 하나”로 좁히는 것. 글 1편, PR 1건, 설정 1군데. 작게 끊으면 diff를 끝까지 읽어낼 수 있습니다.

다음으로 많은 건, 로컬 빌드 성공만으로 완료 취급하는 것입니다. 공개 사이트에는 다른 페이지나 첫 화면이 표시되고 있는데, HTTP 200만 보고 안심해 버린다. 증거 칸에 “공개 URL과 제목 확인”을 넣어 두면, 여기서 멈출 수 있습니다.

세 번째는 무엇을 시도했는지 남기지 않는 것입니다. 다음 날 같은 판단을 처음부터 다시 하게 됩니다. 뒤에 나오는 메모를 한 줄만 남기면, 다음 날의 자기가 헤매지 않습니다. Claude Code에 부탁하는 방식 자체를 끌어올리고 싶다면, 프롬프트 설계 실전도 함께 읽으면 칸을 전하는 법이 한 단계 좋아집니다.

자주 묻는 질문

Q. 승인 단계는 더 세세하게 나누는 게 좋나요? 처음엔 4단계로 충분합니다. 늘릴수록 운영이 복잡해지고, 결국 지켜지지 않습니다. 돌려 보고 “여기가 거칠다”고 느낀 곳만 나중에 가지를 쳐서 나누세요.

Q. 1단계의 “되돌릴 수 있는지” 어떻게 가려내나요? “git으로 한 커맨드면 되돌릴 수 있는가”, “외부에 영향이 나가지 않는가” 두 가지로 판단합니다. 파일 편집은 되돌릴 수 있지만, 배포·과금·메일 발송·삭제는 되돌릴 수 없습니다. 망설여지면 2단계로 올립니다.

Q. 팀에서 쓸 때 누가 단계를 정하나요? 작업을 시작하는 사람이 아침에 선언하고, 2단계 이상의 판단자를 미리 정해 둡니다. 담당자가 부재라면 3단계 작업은 그날 하지 않는다고 정해 두면 안전합니다.

Q. 매번 프롬프트를 붙여넣는 게 귀찮습니다. 칸이 굳어지면 프로젝트 규칙 파일(CLAUDE.md)로 옮기세요. AI가 매번 그것을 읽으니, 붙여넣기가 필요 없어집니다.

Q. 비개발자도 이 워크시트를 쓸 수 있나요? 쓸 수 있습니다. 코드를 돌리지 않아도, 4단계 표와 프롬프트 템플릿만으로 선 긋기는 됩니다. 개발자 외의 활용은 비개발자를 위한 Claude Code 활용도 참고가 됩니다.

인수인계용 메모

그날의 판단을 한 줄로 남겨 두면, 다음 날의 자기나 팀이 같은 망설임을 되풀이하지 않습니다. 다음 형식을 복사해 채우기만 하면 됩니다.

- 날짜: 2026-06-07
- 오늘의 목적: 블로그 글 1편의 오타와 깨진 링크 수정
- 오늘의 상한: 1단계(되돌릴 수 있는 수정까지)
- 증거: diff, npm run build 로그, 공개 URL 제목 확인
- 사람이 멈춘 곳: 의존 업데이트(2단계라 보류)
- 다음 회차로 인계: 의존 업데이트는 다른 날 모아서 2단계로 실시

이 메모가 있으면 공개 후 확인도 편합니다. HTTP 200만으로는 부족하니, 공개 URL에서 제목·정규 URL(canonical)·대표 이미지·본문 서두가 제대로 이 글의 것인지까지 봅니다. 다른 글이나 첫 화면이 표시되고 있다면 미공개 취급으로 하고, 빌드와 배포를 다시 합니다. 권한 설계의 공식적인 사고방식은 Anthropic 공식 문서에서도 확인할 수 있습니다.

실제로 시도한 결과

저는 이 워크시트를 제 블로그 운영에 2주간 적용해 봤습니다.

가장 효과가 컸던 건, 아침에 “오늘은 1단계까지”라고 한 문장을 붙이게 된 것입니다. 이것만으로 커밋 하나당 “허용하시겠습니까?”가 체감상 절반 이하로 줄었습니다. AI가 2단계 이상으로 발을 들이려 하면, 템플릿 규칙대로 제대로 멈춰서 저에게 물어봅니다. 서두 같은 “정신 차려 보니 의존이 업데이트돼 있던” 사고는 그 뒤로 제로입니다.

반대로 알게 된 건, 단계 표는 만들기만 하면 쓰지 않는다는 것입니다. 대장 코드를 실제로 돌려서 “오늘 맡길 작업”을 화면에 띄우고 시작하니, 지킬 확률이 올라갔습니다. 똑똑한 AI를 찾기보다, 넘어져도 되돌릴 수 있는 칸을 먼저 긋는다. 수수하지만 이게 가장 스트레스 없이 맡길 수 있다는 게 지금의 실감입니다.

이 선 긋기를 팀 전체나 운영 환경까지 넓히고 싶다면, 연수·상담에서 구체적인 레인 설계를 함께 다듬을 수 있습니다. 우선 내일 아침, “오늘은 1단계까지”라고 한 문장을 붙이는 것부터 시도해 보세요.