26단계규칙은 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는 자기가 이해한 대로 여러 곳을 한꺼번에 고친다. 이해가 어긋났다면 되돌릴 것도 그만큼 많아진다.

그래서 큰일은 계획부터 받는다. Claude Code에는 플랜 모드가 있다. 이 모드에서는 파일을 고치지 않고 읽기만 하면서, 어떻게 할지 계획을 짜서 보여 준다. 무엇을 만들고, 어느 파일을 고치고, 어떤 순서로 할지가 담긴다. 내가 읽고 동의해야 실제 작업으로 넘어간다. 터미널에서는 단축키로 모드를 돌려 가며 바꾸는 방식이 안내돼 있는데, 조작법은 바뀔 수 있으니 공식 문서에서 확인하자. 모드를 쓰지 않더라도 "고치기 전에 계획만 먼저 보여 줘"라고 말하면 비슷한 효과를 얻는다.

계획을 읽을 때 코드를 이해할 필요는 없다. 세 가지만 보면 된다.

셋 중 하나라도 걸리면 그때 바로 묻는다. 계획 단계에서 묻는 데는 비용이 거의 들지 않는다. 실행한 뒤에 되돌리는 것은 비싸다. 영업지원팀 최 대리의 경우를 보자. 견적 계산기에 할인율 항목을 추가해 달라고 했는데, 받아 본 계획에 "기존 가격표 파일을 새 형식으로 바꾼다"는 항목이 끼어 있었다. 최 대리가 가격표는 건드리지 말라고 짧게 답하자 Claude는 계획을 고쳐 다시 보여 줬다. 그대로 실행했다면 가격표를 쓰는 다른 화면이 소리 없이 깨졌을 것이다.

계획을 받을 때 덧붙이면 좋은 요청이 하나 더 있다. "왜 그렇게 설계했는지 먼저 설명해 줘." 이유를 들으면 내가 모르던 제약이 보이고, Claude가 내 사정을 모르고 있는 부분도 드러난다. 제1부 12단계의 "모르는 게 있으면 먼저 물어봐"와 같은 원리다.

자주 쓰는 / 명령어

/init을 쳐 봤으니 이제 그 친구들을 만날 차례다. Claude Code 입력창에 빗금(/) 하나만 치면 쓸 수 있는 명령 목록이 뜬다. 글자를 더 치면 목록이 좁혀지고, 방향키로 골라 엔터를 누르면 된다. 이것을 슬래시 명령이라고 부른다. Claude에게 하는 부탁과 달리 슬래시 명령은 Claude Code라는 프로그램 자체를 다루는 조작이다. 대화를 새로 시작하고, 모델을 바꾸고, 지금까지 쓴 양을 확인하는 식이다.

외울 필요는 없다. 막막하면 /help를 친다. 지금 쓰는 버전에 들어 있는 명령이 설명과 함께 나온다. 명령은 버전이 오를 때마다 새로 생기고, 이름이 바뀌고, 없어지기도 한다. 아래 표는 이 책을 쓰는 시점에 자주 쓰던 것들이다. 화면과 다르면 /help와 공식 문서(code.claude.com/docs)가 맞다.

이 가운데 비개발자가 가장 자주 손대게 되는 것은 대화·맥락 묶음이다. Claude가 한 번에 붙들고 있을 수 있는 대화의 양에는 끝이 있다. 대화가 길어질수록 앞에서 한 약속이 흐려지고, 엉뚱한 답이 늘고, 사용량도 빨리 찬다. 그래서 셋을 나눠 쓴다.

• 과제가 바뀌면 /clear. 방문 일지를 고치다가 분기 보고서를 합치러 갈 때처럼, 앞의 대화가 도움이 안 되면 비우고 시작한다. CLAUDE.md는 새 대화에서도 다시 읽히니 규칙은 사라지지 않는다.
• 같은 과제가 길어지면 /compact. 흐름은 이어 가되 무게를 덜고 싶을 때다. /compact 결정한 규칙과 남은 할 일 위주로처럼 무엇을 남길지 덧붙일 수 있다.
• 잘못 갔으면 /rewind. 대화와 Claude가 고친 파일을 앞 시점으로 돌린다. 다만 모든 변경이 돌아오는 것은 아니다. Claude가 실행한 명령이 바깥에 남긴 결과나 내가 손으로 고친 파일은 되돌리지 못할 수 있다. 그래서 사내 도구는 29단계의 커밋으로, 업무 파일은 27단계의 원본 사본으로 한 번 더 지킨다.

키보드도 두 가지만 알아 두자. Claude가 엉뚱한 방향으로 달려가면 Esc로 멈춘다. 멈춰도 그때까지 한 일은 남으니 무엇이 바뀌었는지 물어보고 다시 지시한다. Esc를 두 번 누르면 이전 메시지로 돌아가는 메뉴가 열린다. Shift+Tab은 모드를 차례로 바꾼다. 누를 때마다 입력창 아래 표시가 바뀌는데, 여기서 앞서 말한 플랜 모드를 고른다. 파일 이름 앞에 @를 붙이면(@index.html) 그 파일을 콕 집어 가리킬 수도 있다. 단축키 역시 버전에 따라 바뀔 수 있으니 화면 아래의 안내를 먼저 읽는다.

나만의 명령 만들기. 기본 명령 말고도 자주 하는 지시를 파일로 적어 두면 /이름으로 부를 수 있다. 방식은 두 가지다. 하나는 작업 폴더 안 .claude/commands/ 폴더에 푸시전점검.md 같은 파일을 두고 그 안에 늘 하던 지시를 적는 것이다. 그러면 /푸시전점검으로 불린다. 다른 하나는 스킬이다. .claude/skills/이름/SKILL.md를 만들어 두면 Claude가 필요할 때 알아서 꺼내 쓰고, /이름으로 직접 부를 수도 있다. 폴더 위치와 형식은 버전에 따라 달라질 수 있으니 만들기 전에 공식 문서를 확인하자. 영문 이름이 더 안전한 환경도 있다. 파일 이름에 한글이 문제를 일으키면 pre-push처럼 바꾼다. 32단계에서 윤 과장이 "푸시 전 점검"을 명령 하나로 묶는 것이 이 방식이고, SKILL.md를 쓰는 법은 제5부(43단계, 48단계)에서 자세히 다룬다.

현장 장면

첫 페이지를 만든 지 사흘째, 윤 과장은 같은 말을 세 번째 하고 있었다. "화면 문구는 우리말로." "거래처 이름 대신 업종·지역으로." 더는 안 되겠다 싶어 /init을 실행했다. 초안에는 "이 프로젝트는 HTML 단일 파일로 구성된다" 같은 기술 설명만 있었다. 윤 과장은 그 아래에 규칙과 금지 사항을 적어 나갔다. 개인정보에 관해 처음 쓴 문장은 "개인정보 조심"이었다.

그 문장은 하루도 버티지 못했다. 다음 날 Claude가 새로 붙인 "메모" 항목에 거래처 담당자 이름을 적으라는 안내 문구를 넣은 것이다. "조심"이라는 말만으로는 무엇을 하지 말아야 하는지 알 수 없었다. 윤 과장은 그 규칙을 "거래처명, 사람 이름, 전화번호를 적는 항목이나 안내 문구를 만들지 않는다"로 바꿨다. 그 뒤로는 새 항목을 붙여도 같은 일이 생기지 않았다.

다음 과제는 저장이었다. 지금 페이지는 적고 나서 새로고침하면 내용이 사라졌다. 이번에는 바로 시키지 않고 계획만 달라고 했다. 첫 계획의 목적은 "방문 기록을 저장하고 팀장이 모아 볼 수 있게 한다"였다. 파일 목록을 보니 외부 데이터베이스 서비스에 가입해 연결하는 항목과 로그인 화면까지 들어 있었다. 방문 일지 하나 만드는 데 가입에 로그인이라니. 윤 과장은 두 가지를 물었다. 왜 외부 서비스가 필요한지, 없이 할 수는 없는지. Claude의 설명은 이랬다. 팀장이 여러 사람의 기록을 모아 보려면 기록을 한곳에 모으는 저장소가 필요하고, 각자 휴대폰에만 저장하면 모아 보기는 할 수 없다.

설명을 듣고 나니 문제가 보였다. 목적 하나에 두 가지 일이 섞여 있었다. 윤 과장은 이번 목적을 "각자 휴대폰에서 적은 기록이 새로고침해도 남아 있고, 하루치를 표로 내려받아 팀장에게 보낼 수 있다"로 좁혔다. 모아 보기는 CLAUDE.md의 "다음에 할 것" 목록에 적어 두었다. 고쳐진 계획은 index.html 하나만 고치는 짧은 계획이 됐고, 윤 과장은 끝까지 읽은 뒤 승인했다.

저장 기능을 붙이는 데는 오후 내내 걸렸다. 네 시쯤 되자 Claude가 오전에 정한 날짜 형식을 잊은 듯 다른 형식으로 저장하기 시작했다. 윤 과장은 /compact로 대화를 줄이면서 "날짜 형식과 저장 방식 결정 위주로 남겨 줘"라고 덧붙였다. 그 뒤로는 형식이 다시 맞았다. 한 번은 버튼 위치만 옮기라고 했는데 입력란 순서까지 바뀌었다. Esc로 멈추고 /rewind로 그 지시 전으로 돌아간 다음, "버튼만, 다른 건 그대로"라고 다시 말했다. 퇴근 전 다음 날 할 일을 CLAUDE.md에 적게 하고 /exit로 나왔다. 이튿날 아침에는 /resume으로 어제 대화를 불러와 이어서 했다.

따라 하기

1. 작업 폴더에서 Claude Code를 켜고 /init을 실행한다. 성공 기준: 작업 폴더 맨 위에 CLAUDE.md가 생긴다.
2. 초안을 열어 읽고, 위 예시를 참고해 "규칙"과 "하지 말 것"을 각각 세 줄 이상 채운다. 성공 기준: "깔끔하게", "조심"처럼 흐린 말이 하나도 없다.
3. /exit로 끝내고 다시 켠 뒤, 규칙을 말하지 않고 페이지 한 곳을 고쳐 달라고 한다. 성공 기준: 말하지 않은 규칙이 지켜진다.
4. 여러 파일에 걸칠 만한 기능 하나를 정하고, 플랜 모드로 바꾸거나 아래 두 번째 프롬프트로 계획만 요청한다. 성공 기준: 파일은 하나도 바뀌지 않고 계획만 돌아온다.
5. 계획에서 목적, 파일 목록, 지우기·덮어쓰기 세 가지를 표시하고, 걸리는 부분 하나를 묻는다. 성공 기준: 고쳐진 계획이 다시 돌아온다.
6. 동의한 뒤 실행하게 하고, 끝나면 계획에 없던 파일이 바뀌지 않았는지 묻는다. 성공 기준: 바뀐 파일 목록이 계획의 목록과 같다.
7. 입력창에 /만 쳐서 목록을 띄우고, /context로 대화가 얼마나 찼는지 본 뒤 /compact를 한 번 실행한다. 성공 기준: 줄인 뒤에도 CLAUDE.md의 규칙과 방금 정한 계획을 Claude가 기억한다.

복사해 쓰는 프롬프트

이 폴더를 훑어보고 CLAUDE.md를 정리해 줘.
이 폴더는 [무엇을 만드는 곳인지 한 문장]이고, 쓰는 사람은 [누가, 어떤 화면으로]야.
지킬 규칙: [규칙 두세 개].
하지 말 것: [금지 사항 두세 개].
한 화면 안에 들어오게 짧게 쓰고, 서로 부딪히는 규칙이 있으면 고치기 전에 먼저 물어봐.

[추가하고 싶은 기능]을 붙이고 싶어. 이번에 하지 않을 것: [빼 둘 기능].
아직 파일은 고치지 말고 계획만 보여 줘. 계획에는 다음을 꼭 넣어 줘.
- 이 기능의 목적을 한 문장으로
- 고칠 파일과 새로 만들 파일 목록
- 지우거나 덮어쓰는 것이 있으면 따로 표시
- 왜 그렇게 설계했는지 짧은 이유
내가 모르는 사정 때문에 판단이 어려운 곳이 있으면 계획보다 질문을 먼저 해 줘.

막히면 이렇게

실습 파일

공개 저장소에 올려 둔 가공 자료와 양식이다. 회사 자료 대신 먼저 이것으로 해 본다.

• 샘플 자료 영업_방문기록.csv · 영업 사원 네 명의 3월 방문 기록 30건
• 채워 쓰는 양식 CLAUDE_예시.md · 내 작업 폴더에 CLAUDE.md로 이름을 바꿔 두는 규칙 파일 양식

스스로 점검

• ☐ CLAUDE.md의 규칙이 모두 눈으로 확인할 수 있는 문장인가
• ☐ 여러 파일에 걸친 일을 계획 없이 맡기지 않았는가
• ☐ 계획에서 지우거나 덮어쓰는 항목을 찾아봤는가
• ☐ /clear, /compact, /rewind를 각각 언제 쓰는지 말할 수 있는가

기억할 것

• 두 번 말한 규칙은 CLAUDE.md로 옮기고, 확인할 수 있는 문장으로 쓴다. 비밀 값은 적지 않는다.
• 여러 파일에 걸친 일은 계획을 먼저 받고, 목적·파일 목록·지우는 일 세 가지를 본다.

더 알아보기 · 명령어 전체 목록 · 메모리와 CLAUDE.md · 모범 사례