23단계규칙은 CLAUDE.md에, 큰일은 계획부터
매번 하는 설명은 파일 하나에 적어 두고, 큰일은 계획을 받아 읽은 뒤 맡깁니다. 읽지 않은 계획은 승인한 것이 아닙니다.
걸리는 시간 · 읽기 약 15분 · 따라 하기 약 45분 · 난이도 ★★★ 심화 · 화면 확인 2026.09.27
이 단계를 마치면
/init으로 CLAUDE.md 초안을 받고, 확인할 수 있는 문장으로 규칙을 고쳐 쓸 수 있습니다.- 여러 파일에 걸친 일을 맡기기 전에 계획만 받아 낼 수 있습니다.
- 받은 계획에서 목적, 파일 목록, 지우기·덮어쓰기 세 가지를 찾아 되물을 수 있습니다.
- 자주 쓰는
/명령으로 대화를 새로 시작하고, 줄이고, 앞 시점으로 되돌릴 수 있습니다.
"우리 회사 색은 남색이야." "파일 하나로 끝내." "고객 이름은 화면에 그대로 쓰지 마." 같은 말을 사흘 내리 하고 있다면, 일하는 방식을 바꿀 때가 됐습니다.
CLAUDE.md. 대화가 바뀔 때마다 이런 말을 되풀이하면 제1부에서 프로젝트 지침 없이 대화하던 때와 다를 게 없습니다. CLAUDE.md가 이 반복을 끊어 줍니다. 작업 폴더 맨 위에 CLAUDE.md라는 이름의 파일을 두면, Claude Code는 일을 시작할 때 이 파일부터 읽습니다.
무엇을 적을까요. 세 가지면 됩니다. 이 폴더가 무엇을 만드는 곳인지, 지켜야 할 규칙, 하지 말아야 할 일. 규칙은 짧고 분명하게 씁니다. "깔끔하게 만들어" 같은 말은 사람마다 받아들이는 뜻이 달라서 소용이 없습니다. 확인할 수 있는 문장으로 바꿔 씁시다.
| 흐린 규칙 | 확인할 수 있는 규칙 |
|---|---|
| 깔끔하게 만들어 | 색은 남색과 흰색 두 가지만 씁니다 |
| 모바일도 신경 써 | 휴대폰 화면을 먼저 맞추고, 가로로 밀리는 곳이 없게 합니다 |
| 개인정보 조심해 | 예약자는 성만 보여 줍니다 |
| 함부로 고치지 마 | 시키지 않은 파일은 고치지 않습니다. 지우기 전에는 반드시 묻습니다 |
| 잘 확인해 | 끝났다고 말하기 전에 브라우저로 열어 목록이 보이는지 확인하고, 확인한 방법을 적습니다 |
총무팀 이 과장이 회의실 예약 현황판을 만든다고 해 봅시다. 처음 며칠은 대화마다 "회의실 이름은 층수로 부른다", "예약자 이름은 성만 보여 준다"를 말해야 했습니다. 이것을 CLAUDE.md로 옮긴 뒤로는 말하지 않아도 지켜집니다. 새로 온 팀원이 같은 폴더를 이어받아도 규칙이 함께 따라갑니다. 사람에게 건네는 인수인계서 노릇까지 합니다.
처음부터 직접 쓸 필요는 없습니다. Claude Code에는 /init이라는 슬래시 명령이 있어서 폴더를 훑어보고 CLAUDE.md 초안을 만들어 줍니다. 실행하면 폴더의 파일을 읽는 과정이 지나가고, 파일을 만들어도 되는지 묻습니다. 허락하면 작업 폴더에 CLAUDE.md가 생깁니다. 초안은 대개 기술적인 설명 위주입니다. 내가 읽고, 우리 팀의 말로 규칙과 금지 사항을 보탭니다. 일하다가 같은 실수가 두 번 나오면 "이 규칙을 CLAUDE.md에 추가해 줘"라고 말합니다. 그렇게 규칙 파일은 실수가 나올 때마다 조금씩 자랍니다.
주의할 점도 있습니다. 규칙이 너무 길어지면 정작 중요한 규칙이 묻힙니다. 한 화면을 넘어갈 만큼 길어졌다면 서로 부딪히는 규칙은 없는지 한 번 정리합시다. 그리고 비밀번호나 인증키는 절대 이 파일에 적지 않습니다. CLAUDE.md는 저장소에 함께 올라가 다른 사람도 읽는 파일입니다. 아래는 짧은 예시입니다. 우리 팀 도구에 맞게 고쳐 쓰면 됩니다.
# 회의실 예약 현황판
## 이 폴더는
총무팀이 쓰는 회의실 예약 현황판이다. 직원들이 휴대폰으로 연다.
## 규칙
- 화면은 휴대폰을 먼저 맞춘다.
- 색은 남색과 흰색만 쓴다.
- 회의실은 층수로 부른다. (예: 3층 대회의실)
- 예약자는 성만 보여 준다.
- 오류가 나면 원문 대신 우리말 한 문장으로 알린다.
## 하지 말 것
- 인증키나 비밀번호를 코드에 적지 않는다.
- 파일을 지우기 전에는 반드시 먼저 묻는다.
- 시키지 않은 파일은 고치지 않는다.
- 저장소 기록을 강제로 덮어쓰지 않는다.
## 끝났다고 말하기 전에
- 브라우저로 열어 예약 목록이 보이는지 직접 확인하고, 확인한 방법을 적는다.
칼럼에서 읽기 「바이브 코딩은 대화(對話) 코딩이고, 에이전틱 코딩은 대리(代理) 코딩이다」
“운전대를 넘기려면 먼저 목적지를 말해 줘야 합니다. 어디로 가는지 모른 채 출발하는 대리운전은 없습니다. 컴퓨터가 무엇을 만들고 무엇은 만들지 않을지, 어떤 조건을 채우면 끝으로 볼지를 미리 적게 합니다.”
“… 에이전트가 매번 읽고 들어가야 하는 지침 파일입니다. 기계에게 건네는 위임장이자 업무지시서입니다.”
칼럼에서 말한 위임장이 바로 CLAUDE.md입니다. 이 폴더가 무엇을 만드는 곳인지, 지킬 규칙과 하지 말 일, 끝났다고 말하기 전에 확인할 것까지 적어 두면 Claude Code는 일을 시작할 때마다 그 위임장부터 읽습니다.
계획 먼저. 규칙 파일이 기본을 잡아 준다면, 계획은 큰일마다 방향을 잡아 줍니다. 작은 수정은 바로 시켜도 됩니다. 버튼 글자 하나, 색 하나 바꾸는 정도입니다. 그런데 "예약 기능을 붙여 줘"처럼 여러 파일에 걸친 일은 다릅니다. 바로 시키면 Claude는 자기가 이해한 대로 여러 곳을 한꺼번에 고칩니다. 이해가 어긋났다면 되돌릴 것도 그만큼 많아집니다.
그래서 큰일은 계획부터 받습니다. Claude Code에는 플랜 모드가 있습니다. 이 모드에서는 파일을 고치지 않고 읽기만 하면서, 어떻게 할지 계획을 짜서 보여 줍니다. 무엇을 만들고, 어느 파일을 고치고, 어떤 순서로 할지가 담깁니다. 내가 읽고 동의해야 실제 작업으로 넘어갑니다. 터미널에서는 단축키로 모드를 돌려 가며 바꾸는 방식이 안내돼 있는데, 조작법은 바뀔 수 있으니 공식 문서에서 확인하십시오. 모드를 쓰지 않더라도 "고치기 전에 계획만 먼저 보여 줘"라고 말하면 비슷한 효과를 얻습니다.
계획을 읽을 때 코드를 이해할 필요는 없습니다. 세 가지만 보면 됩니다.
| 볼 것 | 걸리는 신호 | 그때 할 말 |
|---|---|---|
| 목적 | 계획 첫 줄이 내가 말한 목적과 다릅니다 | "목적은 [한 문장]이야. 거기 맞춰 다시 짜 줘" |
| 파일 목록 | 이번 일과 상관없어 보이는 파일이 끼어 있습니다 | "[파일]은 왜 고쳐야 해? 안 고치는 방법은?" |
| 지우기·덮어쓰기 | 기존 파일을 지우거나 새 형식으로 바꾼다는 항목이 있습니다 | "그건 하지 말고, 꼭 필요하면 이유를 먼저 설명해 줘" |
셋 중 하나라도 걸리면 그때 바로 묻습니다. 계획 단계에서 묻는 데는 비용이 거의 들지 않습니다. 실행한 뒤에 되돌리는 것은 비쌉니다. 영업지원팀 최 대리의 경우를 봅시다. 견적 계산기에 할인율 항목을 추가해 달라고 했는데, 받아 본 계획에 "기존 가격표 파일을 새 형식으로 바꾼다"는 항목이 끼어 있었습니다. 최 대리가 가격표는 건드리지 말라고 짧게 답하자 Claude는 계획을 고쳐 다시 보여 줬습니다. 그대로 실행했다면 가격표를 쓰는 다른 화면이 소리 없이 깨졌을 겁니다.
계획을 받을 때 덧붙이면 좋은 요청이 하나 더 있습니다. "왜 그렇게 설계했는지 먼저 설명해 줘." 이유를 들으면 내가 모르던 제약이 보이고, Claude가 내 사정을 모르고 있는 부분도 드러납니다. 제1부 9단계의 "모르는 게 있으면 먼저 물어봐"와 같은 원리입니다.
Codex에서는 CLAUDE.md가 하는 일을 AGENTS.md가 합니다. /init으로 초안을 받는 것도 같습니다. Codex는 CLAUDE.md를 저절로 읽지 않으니, 두 도구를 함께 쓸 때는 규칙 파일을 어떻게 맞출지 따로 정해야 합니다. 계획 모드는 /plan이나 Shift+Tab으로 켭니다. 33단계에서 다룹니다.
자주 쓰는 / 명령어
/init을 쳐 봤으니 이제 그 친구들을 만날 차례입니다. Claude Code 입력창에 빗금(/) 하나만 치면 쓸 수 있는 명령 목록이 뜹니다. 글자를 더 치면 목록이 좁혀지고, 방향키로 골라 엔터를 누르면 됩니다. 이것을 슬래시 명령이라고 부릅니다. Claude에게 하는 부탁과 달리 슬래시 명령은 Claude Code라는 프로그램 자체를 다루는 조작입니다. 대화를 새로 시작하고, 모델을 바꾸고, 지금까지 쓴 양을 확인하는 식입니다.
외울 필요는 없습니다. 막막하면 /help를 칩니다. 지금 쓰는 버전에 들어 있는 명령이 설명과 함께 나옵니다. 명령은 버전이 오를 때마다 새로 생기고, 이름이 바뀌고, 없어지기도 합니다. 아래 표는 이 책을 쓰는 시점에 자주 쓰던 것들입니다. 화면과 다르면 /help와 공식 문서(code.claude.com/docs)가 맞습니다.
| 쓰임 | 명령 | 언제 쓰나 |
|---|---|---|
| 시작·설정 | /init |
새 작업 폴더에서 CLAUDE.md 초안을 받을 때 |
/memory |
CLAUDE.md 같은 메모리 파일을 열어 규칙을 직접 고칠 때 | |
/config |
화면 색, 알림 같은 설정을 바꿀 때 | |
/model |
더 빠른 모델이나 더 꼼꼼한 모델로 바꿔 쓰고 싶을 때 | |
/permissions |
매번 묻는 허락 가운데 늘 허용할 것과 늘 막을 것을 정리할 때(28단계) | |
/login, /logout |
다른 계정으로 바꾸거나 로그인이 풀렸을 때 | |
/doctor |
설치가 제대로 됐는지, 무엇이 문제인지 점검할 때 | |
| 대화·맥락 | /clear |
앞의 일과 상관없는 새 과제를 시작할 때. 지금까지의 대화를 비웁니다 |
/compact |
대화가 길어져 Claude가 앞의 약속을 흘리기 시작할 때. 지금까지를 요약해 가볍게 만듭니다 | |
/context |
대화가 맥락 공간을 얼마나 차지하고 있는지 볼 때 | |
/resume |
어제 하던 대화를 골라 이어 갈 때 | |
/rewind |
방금 시킨 일이 잘못돼 대화와 파일을 앞 시점으로 돌리고 싶을 때 | |
| 확인·비용 | /status |
지금 쓰는 계정, 모델, 버전을 확인할 때 |
/usage (/cost) |
얼마나 썼는지 볼 때. /cost는 /usage의 다른 이름입니다 |
|
/review |
바뀐 코드를 검토해 달라고 할 때(30단계의 확인과 함께 씁니다) | |
| 넓히기 | /mcp |
연결한 MCP 서버를 확인하고 관리할 때(29단계) |
/agents |
검토 담당 같은 서브에이전트를 만들고 관리할 때(29단계) | |
/hooks |
설정된 훅을 보고 관리할 때(29단계) | |
/plugin |
명령·스킬·훅을 묶은 플러그인을 찾아 설치할 때 | |
/add-dir |
지금 폴더 밖의 다른 폴더도 함께 읽게 할 때 | |
| 끝내기·보고 | /exit |
Claude Code를 끝낼 때 |
/bug, /feedback |
이상한 동작을 Anthropic에 알릴 때. 보내기 전에 대화 기록을 얼마나 넣을지 고르고 확인 화면을 거칩니다 |
이 가운데 비개발자가 가장 자주 손대게 되는 것은 대화·맥락 묶음입니다. Claude가 한 번에 붙들고 있을 수 있는 대화의 양에는 끝이 있습니다. 대화가 길어질수록 앞에서 한 약속이 흐려지고, 엉뚱한 답이 늘고, 사용량도 빨리 찹니다. 그래서 셋을 나눠 씁니다.
- 과제가 바뀌면
/clear. 방문 일지를 고치다가 분기 보고서를 합치러 갈 때처럼, 앞의 대화가 도움이 안 되면 비우고 시작합니다. CLAUDE.md는 새 대화에서도 다시 읽히니 규칙은 사라지지 않습니다. - 같은 과제가 길어지면
/compact. 흐름은 이어 가되 무게를 덜고 싶을 때입니다./compact 결정한 규칙과 남은 할 일 위주로처럼 무엇을 남길지 덧붙일 수 있습니다. - 잘못 갔으면
/rewind. 대화와 Claude가 고친 파일을 앞 시점으로 돌립니다. 다만 모든 변경이 돌아오는 것은 아닙니다. Claude가 실행한 명령이 바깥에 남긴 결과나 내가 손으로 고친 파일은 되돌리지 못할 수 있습니다. 그래서 사내 도구는 26단계의 커밋으로, 업무 파일은 24단계의 원본 사본으로 한 번 더 지킵니다.
키보드도 두 가지만 알아 둡시다. Claude가 엉뚱한 방향으로 달려가면 Esc로 멈춥니다. 멈춰도 그때까지 한 일은 남으니 무엇이 바뀌었는지 물어보고 다시 지시합니다. Esc를 두 번 누르면 이전 메시지로 돌아가는 메뉴가 열립니다. Shift+Tab은 모드를 차례로 바꿉니다. 누를 때마다 입력창 아래 표시가 바뀌는데, 여기서 앞서 말한 플랜 모드를 고릅니다. 파일 이름 앞에 @를 붙이면(@index.html) 그 파일을 콕 집어 가리킬 수도 있습니다. 단축키 역시 버전에 따라 바뀔 수 있으니 화면 아래의 안내를 먼저 읽습니다.
나만의 명령 만들기. 기본 명령 말고도 자주 하는 지시를 파일로 적어 두면 /이름으로 부를 수 있습니다. 방식은 두 가지입니다. 하나는 작업 폴더 안 .claude/commands/ 폴더에 푸시전점검.md 같은 파일을 두고 그 안에 늘 하던 지시를 적는 방식입니다. 그러면 /푸시전점검으로 불립니다. 다른 하나는 스킬입니다. .claude/skills/이름/SKILL.md를 만들어 두면 Claude가 필요할 때 알아서 꺼내 쓰고, /이름으로 직접 부를 수도 있습니다. 폴더 위치와 형식은 버전에 따라 달라질 수 있으니 만들기 전에 공식 문서를 확인하십시오. 영문 이름이 더 안전한 환경도 있습니다. 파일 이름에 한글이 문제를 일으키면 pre-push처럼 바꿉니다. 29단계에서 윤 과장이 "푸시 전 점검"을 명령 하나로 묶는 것이 이 방식이고, SKILL.md를 쓰는 법은 제6부(48단계, 53단계)에서 자세히 다룹니다.
Codex에서는 /model, /compact, /resume, /status, /review처럼 이름이 같은 명령이 많습니다. 새 대화는 /new나 /clear로 시작하고, 바뀐 내용은 /diff로 봅니다. /rewind 같은 되돌리기 명령은 CLI에 없으니, 작업 전후로 커밋해 두는 습관이 되돌리기를 맡습니다. 명령 목록과 설정 파일은 37단계에서 정리합니다.
현장 장면
첫 페이지를 만든 지 사흘째, 윤 과장은 같은 말을 세 번째 하고 있었습니다. "화면 문구는 우리말로." "거래처 이름 대신 업종·지역으로." 더는 안 되겠다 싶어 /init을 실행했습니다. 초안에는 "이 프로젝트는 HTML 단일 파일로 구성된다" 같은 기술 설명만 있었습니다. 윤 과장은 그 아래에 규칙과 금지 사항을 적어 나갔습니다. 개인정보에 관해 처음 쓴 문장은 "개인정보 조심"이었습니다.
그 문장은 하루도 버티지 못했습니다. 다음 날 Claude가 새로 붙인 "메모" 항목에 거래처 담당자 이름을 적으라는 안내 문구를 넣은 것입니다. "조심"이라는 말만으로는 무엇을 하지 말아야 하는지 알 수 없었습니다. 윤 과장은 그 규칙을 "거래처명, 사람 이름, 전화번호를 적는 항목이나 안내 문구를 만들지 않는다"로 바꿨습니다. 그 뒤로는 새 항목을 붙여도 같은 일이 생기지 않았습니다.
다음 과제는 저장이었습니다. 지금 페이지는 적고 나서 새로고침하면 내용이 사라졌습니다. 이번에는 바로 시키지 않고 계획만 달라고 했습니다. 첫 계획의 목적은 "방문 기록을 저장하고 팀장이 모아 볼 수 있게 한다"였습니다. 파일 목록을 보니 외부 데이터베이스 서비스에 가입해 연결하는 항목과 로그인 화면까지 들어 있었습니다. 방문 일지 하나 만드는 데 가입에 로그인이라니. 윤 과장은 두 가지를 물었습니다. 왜 외부 서비스가 필요한지, 없이 할 수는 없는지. Claude의 설명은 이랬습니다. 팀장이 여러 사람의 기록을 모아 보려면 기록을 한곳에 모으는 저장소가 필요하고, 각자 휴대폰에만 저장하면 모아 보기는 할 수 없습니다.
설명을 듣고 나니 문제가 보였습니다. 목적 하나에 두 가지 일이 섞여 있었습니다. 윤 과장은 이번 목적을 "각자 휴대폰에서 적은 기록이 새로고침해도 남아 있고, 하루치를 표로 내려받아 팀장에게 보낼 수 있다"로 좁혔습니다. 모아 보기는 CLAUDE.md의 "다음에 할 것" 목록에 적어 두었습니다. 고쳐진 계획은 index.html 하나만 고치는 짧은 계획이 됐고, 윤 과장은 끝까지 읽은 뒤 승인했습니다.
저장 기능을 붙이는 데는 오후 내내 걸렸습니다. 네 시쯤 되자 Claude가 오전에 정한 날짜 형식을 잊은 듯 다른 형식으로 저장하기 시작했습니다. 윤 과장은 /compact로 대화를 줄이면서 "날짜 형식과 저장 방식 결정 위주로 남겨 줘"라고 덧붙였습니다. 그 뒤로는 형식이 다시 맞았습니다. 한 번은 버튼 위치만 옮기라고 했는데 입력란 순서까지 바뀌었습니다. Esc로 멈추고 /rewind로 그 지시 전으로 돌아간 다음, "버튼만, 다른 건 그대로"라고 다시 말했습니다. 퇴근 전 다음 날 할 일을 CLAUDE.md에 적게 하고 /exit로 나왔습니다. 이튿날 아침에는 /resume으로 어제 대화를 불러와 이어서 했습니다.
따라 하기
- 작업 폴더에서 Claude Code를 켜고
/init을 실행합니다. 성공 기준: 작업 폴더 맨 위에 CLAUDE.md가 생깁니다. - 초안을 열어 읽고, 위 예시를 참고해 "규칙"과 "하지 말 것"을 각각 세 줄 이상 채웁니다. 성공 기준: "깔끔하게", "조심"처럼 흐린 말이 하나도 없습니다.
/exit로 끝내고 다시 켠 뒤, 규칙을 말하지 않고 페이지 한 곳을 고쳐 달라고 합니다. 성공 기준: 말하지 않은 규칙이 지켜집니다.- 여러 파일에 걸칠 만한 기능 하나를 정하고, 플랜 모드로 바꾸거나 아래 두 번째 프롬프트로 계획만 요청합니다. 성공 기준: 파일은 하나도 바뀌지 않고 계획만 돌아옵니다.
- 계획에서 목적, 파일 목록, 지우기·덮어쓰기 세 가지를 표시하고, 걸리는 부분 하나를 묻습니다. 성공 기준: 고쳐진 계획이 다시 돌아옵니다.
- 동의한 뒤 실행하게 하고, 끝나면 계획에 없던 파일이 바뀌지 않았는지 묻습니다. 성공 기준: 바뀐 파일 목록이 계획의 목록과 같습니다.
- 입력창에
/만 쳐서 목록을 띄우고,/context로 대화가 얼마나 찼는지 본 뒤/compact를 한 번 실행합니다. 성공 기준: 줄인 뒤에도 CLAUDE.md의 규칙과 방금 정한 계획을 Claude가 기억합니다.
복사해 쓰는 프롬프트
이 폴더를 훑어보고 CLAUDE.md를 정리해 줘.
이 폴더는 [무엇을 만드는 곳인지 한 문장]이고, 쓰는 사람은 [누가, 어떤 화면으로]야.
지킬 규칙: [규칙 두세 개].
하지 말 것: [금지 사항 두세 개].
한 화면 안에 들어오게 짧게 쓰고, 서로 부딪히는 규칙이 있으면 고치기 전에 먼저 물어봐.
[추가하고 싶은 기능]을 붙이고 싶어. 이번에 하지 않을 것: [빼 둘 기능].
아직 파일은 고치지 말고 계획만 보여 줘. 계획에는 다음을 꼭 넣어 줘.
- 이 기능의 목적을 한 문장으로
- 고칠 파일과 새로 만들 파일 목록
- 지우거나 덮어쓰는 것이 있으면 따로 표시
- 왜 그렇게 설계했는지 짧은 이유
내가 모르는 사정 때문에 판단이 어려운 곳이 있으면 계획보다 질문을 먼저 해 줘.
막히면 이렇게
| 증상 | 원인 | 처방 |
|---|---|---|
| CLAUDE.md에 적었는데 규칙이 지켜지지 않습니다 | 문장이 흐리거나 다른 규칙과 부딪힙니다 | 확인할 수 있는 문장으로 고치고, 부딪히는 규칙을 정리해 달라고 합니다 |
| 계획만 달라고 했는데 파일을 고쳤습니다 | 지시가 실행 요청으로 읽혔습니다 | 되돌리게 하고, 플랜 모드로 바꾸거나 "파일은 고치지 말고"를 첫 줄에 씁니다 |
| 계획이 너무 길어 읽을 수 없습니다 | 한 번에 목적을 여러 개 줬습니다 | 목적을 하나로 좁히고, 나머지는 "이번에 하지 않을 것"으로 뺍니다 |
| 대화가 길어지자 앞에서 정한 규칙을 자꾸 잊습니다 | 대화가 맥락 공간을 많이 차지했습니다 | 같은 과제면 /compact로 줄이고, 새 과제면 /clear로 비웁니다. 꼭 지킬 규칙은 CLAUDE.md로 옮깁니다 |
책에 나온 / 명령이 목록에 없습니다 |
버전에 따라 이름이 바뀌거나 없어졌습니다 | /help로 지금 버전의 목록을 보고, 공식 문서에서 비슷한 이름을 찾습니다 |
실습 파일
공개 저장소에 올려 둔 가공 자료와 양식입니다. 회사 자료 대신 먼저 이것으로 해 보세요.
- 샘플 자료 영업_방문기록.csv · 영업 사원 네 명의 3월 방문 기록 30건
- 채워 쓰는 양식 CLAUDE_예시.md · 내 작업 폴더에
CLAUDE.md로 이름을 바꿔 두는 규칙 파일 양식
스스로 점검
- ☐ CLAUDE.md의 규칙이 모두 눈으로 확인할 수 있는 문장입니까?
- ☐ 여러 파일에 걸친 일을 계획 없이 맡기지 않았습니까?
- ☐ 계획에서 지우거나 덮어쓰는 항목을 찾아봤습니까?
- ☐
/clear,/compact,/rewind를 각각 언제 쓰는지 말할 수 있습니까?
점검 해설 보기
- CLAUDE.md에 "깔끔하게", "조심" 같은 말이 없고, 규칙마다 화면을 열어 지켜졌는지 예·아니오로 가릴 수 있으면 통과입니다. 흐린 규칙이 남아 있다면 흐린 규칙과 확인할 수 있는 규칙을 비교한 표를 보고 고쳐 씁니다.
/exit후 다시 켜서 규칙을 말하지 않고 한 곳을 고치게 해 지켜지는지 시험합니다. - 여러 파일에 걸친 기능을 맡길 때 파일이 하나도 바뀌지 않은 상태에서 계획을 먼저 받았으면 통과입니다. 바로 실행해 버렸다면 되돌리게 하고, 플랜 모드로 바꾸거나 두 번째 프롬프트처럼 "파일은 고치지 말고"를 첫머리에 씁니다. 「계획 먼저」 부분을 다시 읽습니다.
- 받은 계획에서 목적, 파일 목록, 지우기·덮어쓰기 항목을 찾아 표시하고 걸리는 곳 하나를 되물어 고쳐진 계획을 받았으면 통과입니다. 어디를 봐야 할지 모르겠으면 "볼 것 / 걸리는 신호 / 그때 할 말" 표를 옆에 두고 계획을 다시 읽습니다.
- 과제가 바뀌면
/clear, 같은 과제가 길어지면/compact, 잘못 갔으면/rewind라고 예를 들어 말할 수 있으면 통과입니다. 헷갈리면 「자주 쓰는 / 명령어」의 대화·맥락 설명을 다시 읽습니다./rewind로 모든 변경이 돌아오지는 않는다는 점도 함께 기억합니다.
기억할 것
- 두 번 말한 규칙은 CLAUDE.md로 옮기고, 확인할 수 있는 문장으로 씁니다. 비밀 값은 적지 않습니다.
- 여러 파일에 걸친 일은 계획을 먼저 받고, 목적·파일 목록·지우는 일 세 가지를 봅니다.
더 알아보기 · 명령어 전체 목록 · 메모리와 CLAUDE.md · 모범 사례