CLAUDE.md, 잘 쓰고 있는지 5가지 기준으로 진단하세요 (복붙용 개선 프롬프트 포함)

CLAUDE.md가 제대로 동작하지 않는 이유

며칠 전 Claude Code의 핵심 기능 아홉 개를 순서대로 정리한 영상을 올렸습니다. 영상을 공개하고 나서 가장 많이 받은 질문은 CLAUDE.md에 관한 것이었습니다. 파일은 만들어 두었는데 제대로 동작하는지 모르겠다는 내용이었습니다.

실제로 나타나는 증상은 비슷합니다. 파일 위치를 적어줬는데도 매번 폴더를 열어보며 찾고, 같은 선호도를 세 번째 설명하게 됩니다. 이미 연결한 API를 사용할 수 없다고 답하거나 지난달에 실패한 방법을 다시 시도하기도 합니다. 이때 CLAUDE.md를 대신 정리해준다는 플러그인부터 찾는 경우가 많습니다.

제가 여러 프로젝트에서 확인해보니 먼저 필요한 것은 관리 도구보다 현재 문서에 대한 진단이었습니다. 플러그인을 추가해도 CLAUDE.md 안의 오래된 정보나 빠진 규칙이 저절로 고쳐지지는 않습니다. 어떤 항목이 비어 있는지 먼저 판정하면 실제 수정할 부분은 몇 줄에 그치는 경우도 많았습니다.

이번 글에서는 CLAUDE.md 진단 기준 5가지와 구조 점검 4항목을 정리하고 진단부터 개선 실행까지 한 번에 굴리는 3-Phase 프롬프트를 전문 그대로 올려두겠습니다. Claude Code는 업데이트 주기가 빨라서 세부 경로와 권장값은 작성일 기준입니다.

CLAUDE.md 진단 기준 5가지

진단할 때는 아래 다섯 항목을 차례로 확인합니다. 각 항목을 충족, 부분 충족, 미충족으로 판정하고 그 근거를 함께 남깁니다. 참고로 이 기준은 Anthropic의 공식 체크리스트가 아니라 제가 여러 프로젝트를 운영하면서 정리한 진단 방식입니다.

1. 프로젝트 지도 (Project Map)

먼저 문서에 적힌 폴더 구조와 실제 프로젝트 구조가 일치하는지 확인합니다. 주요 디렉터리의 역할이 적혀 있는지, 코드만 보고는 알기 어려운 진입점이나 예외적인 파일 위치가 적혀 있는지도 봅니다. 전체 디렉터리 목록을 복사하기보다 실제로 탐색이 반복되는 위치만 남깁니다. 폴더 구조가 오래된 상태라면 에이전트가 잘못된 위치를 다시 탐색하고 그만큼 컨텍스트도 사용하게 됩니다.

2. 규칙서 (Rules & Preferences)

코딩 스타일, 언어 선호, 라이브러리 선호가 적혀 있는지 봅니다. 자주 빠지는 항목은 커뮤니케이션 스타일입니다. 응답 포맷, 설명 깊이, 사용 언어를 정해두지 않으면 같은 지적을 계속 반복하게 됩니다. 프로젝트 목표와 맥락, 이미 유효하지 않은 규칙이 남아 있는지도 봅니다. 갈아엎은 구조를 전제로 쓴 규칙은 지울 대상입니다.

3. 능력의 경계선 (Capability Boundaries)

쓸 수 있는 외부 API와 DB, 자동화 스크립트가 명시되어 있는지, 내부 API 문서의 참조 경로가 안내되어 있는지를 봅니다. 이 칸이 비면 "이 기능을 수행할 수 없습니다"라는 답이 나옵니다. 할 수 있는데 못 한다고 판단하는 구간이라 손해가 가장 큽니다.

4. 시행착오 일지 (Lessons Learned)

실패한 접근 방식과 라이브러리·버전 호환성 문제가 기록되어 있는지 확인합니다. 같은 실수를 막는 규칙이 있는지도 봅니다. 이 내용은 프로젝트를 운영하면서 하나씩 쌓입니다. 오래 운영한 프로젝트인데도 비어 있다면 이전에 해결한 문제가 문서에 반영되지 않은 상태입니다.

5. 실행 모델 (Execution Model)

Advisor와 Worker의 역할 분담 규칙이 문서에 있는가, subagent 위임 기준과 검증 절차가 정의되어 있는가.

여기서 Advisor는 메인 세션을 뜻합니다. 요구사항을 나누고 설계를 정한 다음 Worker에게 전달할 작업 내용을 작성합니다. Worker인 subagent는 실제 코드 작성과 수정을 담당합니다. 작업이 끝나면 Advisor가 완료 보고만 확인하는 것이 아니라 diff를 열어보고 테스트도 직접 실행한 뒤 승인합니다.

여기에 보고 시점 규칙이 붙습니다. Worker는 실질적인 작업에 들어가기 전에 한 번, 완료를 선언하기 전에 한 번 보고합니다. 파일을 찾고 읽는 것은 실질적인 작업이 아니고, 쓰기 시작하거나 답을 확정하는 순간부터가 실질적인 작업입니다. 완료 보고 전에는 결과물을 파일로 먼저 저장하게 합니다. 세션이 끊겨도 남아야 하기 때문입니다.

구조 점검 4항목

다섯 가지 내용을 확인한 다음에는 문서 구조를 점검합니다. 내용이 들어 있어도 너무 길거나 적용 범위가 섞여 있으면 규칙을 제대로 따르기 어렵기 때문입니다. 확인할 항목은 네 가지입니다.

1. 총 라인 수. Claude Code 공식 문서는 CLAUDE.md 한 파일을 200줄 미만으로 유지하는 것을 목표로 삼으라고 권합니다. 강제 제한은 아니지만 길수록 컨텍스트 사용량이 늘고 지시 준수율이 낮아질 수 있습니다.
2. 사용자 범위와 프로젝트 범위 분리. ~/.claude/CLAUDE.md는 사용자 지침, ./CLAUDE.md 또는 ./.claude/CLAUDE.md는 프로젝트 지침입니다. 개인 선호와 저장소 규칙을 섞지 않습니다. ./CLAUDE.local.md는 커밋하지 않을 개인 프로젝트 지침에 씁니다.
3. .claude/rules/ 분리. 프로젝트가 커지면 주제별 파일로 나눌 수 있습니다. paths는 특정 파일군에만 적용할 규칙에 사용하고 저장소 전체 규칙에는 생략합니다. paths가 없는 규칙 파일은 시작 시 로드됩니다.
4. 계층형 CLAUDE.md. 하위 디렉터리에만 필요한 지시가 있으면 그 디렉터리에 CLAUDE.md를 두고 해당 파일을 다룰 때 온디맨드로 불러오게 합니다.

제 PC부터 세어 봤습니다. 홈 폴더 아래 프로젝트에 있는 CLAUDE.md 31개(남이 만든 예제 저장소 2개는 제외)의 줄 수입니다.

31개 중 6개가 200줄을 넘었고 가장 긴 파일은 704줄이었습니다(중앙값 87줄). 줄 수만 보면 안 되는 경우도 있습니다. 256줄짜리 파일 하나는 27KB로, 704줄짜리와 크기가 거의 같았습니다. 한 줄에 표나 긴 명령어가 몰려 있으면 줄 수는 적어도 컨텍스트는 많이 차지합니다. 구조 점검은 wc -l과 함께 파일 크기도 같이 보시는 걸 권장합니다.

find ~ -maxdepth 4 -name CLAUDE.md -not -path "*/node_modules/*" \
  -exec sh -c 'printf "%5d줄 %7d바이트  %s\n" $(wc -l < "$1") $(wc -c < "$1") "$1"' _ {} \; 2>/dev/null | sort -rn

위 명령은 홈 폴더 아래 4단계까지 CLAUDE.md를 찾아 줄 수와 바이트 크기를 긴 순서로 보여줍니다. 위 그래프도 이 결과로 그렸습니다.

3-Phase 진단·개선 프롬프트 전문

아래는 실제로 사용할 수 있는 프롬프트 전문입니다. 원본 영상의 고정 댓글에 올려둔 v2 버전과 같은 내용입니다.

사용 방법은 다음과 같습니다. 진단할 프로젝트 폴더에서 Claude Code를 열고, 지원하는 모델이라면 /effort high 또는 /effort xhigh를 선택합니다. 그다음 아래 블록을 통째로 붙여넣습니다. Phase 1에서 현재 상태를 판정하고, Phase 2에서 변경 목록을 확정한 뒤, Phase 3에서 실제 파일을 수정합니다. Claude Code는 AGENTS.md를 기본 지침 파일로 직접 읽지 않기 때문에 AGENTS.md만 있는 경우 CLAUDE.md에서 @AGENTS.md를 가져오도록 프롬프트에 반영했습니다.

아래 Execution Model은 Anthropic 공식 템플릿이 아니라 제가 만든 검증 중심 운영 규칙입니다. 팀의 비용 정책과 사용 가능한 모델에 맞게 조정해야 합니다.

현재 프로젝트의 CLAUDE.md를
아래 절차에 따라 진단하고 개선까지 완료해줘.
CLAUDE.md가 없고 AGENTS.md만 있으면 내용을 중복 복사하지 말고
CLAUDE.md를 만든 뒤 @AGENTS.md import를 우선 검토해줘.
둘 다 없으면 실제 프로젝트를 조사한 근거만으로 CLAUDE.md를 신규 생성해줘.
Phase 1 → 2 → 3 을 중간 승인 없이 연속 실행한다.
각 Phase 결과를 요약 출력하고 즉시 다음 Phase로 진행해줘.

━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
Phase 1. 진단
━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━

아래 5가지 기준으로 각각 [충족 / 부분 충족 / 미충족] 판정하고 근거를 제시해줘.

1. 프로젝트 지도 (Project Map)
   - 실제 폴더 구조와 문서에 기술된 구조가 일치하는가
   - 주요 디렉토리별 역할이 명시되어 있는가
   - 파일 탐색 없이 코드 위치를 바로 찾을 수 있는 수준인가

2. 규칙서 (Rules & Preferences)
   - 코딩 스타일, 언어 선호, 라이브러리 선호가 명시되어 있는가
   - 커뮤니케이션 스타일 (응답 포맷, 설명 깊이, 언어) 이 정의되어 있는가
   - 프로젝트 목표와 맥락이 포함되어 있는가
   - 유효하지 않은 규칙이 남아있는가

3. 능력의 경계선 (Capability Boundaries)
   - 사용 가능한 외부 API, DB, 자동화 스크립트가 명시되어 있는가
   - 프로젝트 내부 API 문서의 참조 경로가 안내되어 있는가
   - "이 기능을 수행할 수 없습니다"로 잘못 판단할 영역이 있는가

4. 시행착오 일지 (Lessons Learned)
   - 실패한 접근 방식이 기록되어 있는가
   - 라이브러리/버전 호환성 이슈가 문서화되어 있는가
   - 반복 실수를 막는 가드레일이 존재하는가

5. 실행 모델 (Execution Model)
   - Advisor/Worker 역할 분담 규칙이 문서에 존재하는가
   - 서브에이전트 위임 기준과 검증 절차가 정의되어 있는가

구조 점검:
- 총 라인 수 (200줄 이내 권장)
- 사용자 지침(~/.claude/CLAUDE.md)과 프로젝트 지침 분리 여부
- .claude/rules/ 디렉토리 활용 여부
- 하위 폴더별 CLAUDE.md 계층 구조 활용 여부
- 중복 내용 존재 여부

━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
Phase 2. 변경 목록 확정
━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━

진단 결과 기반으로 변경 목록을 확정해줘. 원칙:

1. 잘 작동하는 기존 부분은 건드리지 마.
2. 각 변경 사항을 아래 포맷으로 기록:
   - 변경 위치: (파일 경로)
   - 변경 유형: [추가 / 수정 / 삭제 / 분리]
   - 현재 상태 → 개선 후
   - 이유
   - 우선순위: [높음 / 중간 / 낮음]
3. Claude Code 공식 문서의 범위 규칙 반영:
   - CLAUDE.md는 가능하면 200줄 미만을 목표로 하되 유효한 규칙을 억지로 삭제하지 말 것
   - 주제가 나뉘어 유지보수성이 좋아질 때 .claude/rules/ 사용
   - paths는 경로 한정 규칙에만 사용하고 저장소 전체 규칙에는 생략
   - 하위 디렉터리 전용 지시는 필요할 때 계층형 CLAUDE.md로 분리
   - 언어는 팀이 실제 사용하는 언어와 기존 문서 언어를 유지
4. 아래 "Execution Model"은 작성자 운영안이다. 현재 프로젝트에 subagent 작업이 실제로 필요할 때만 포함시켜줘.
   Advisor 호출 타이밍과 조언 처리 규칙까지 포함된 전체 버전이며,
   분량이 크면 .claude/rules/execution-model.md 로 분리하고
   CLAUDE.md에는 참조 한 줄만 남긴다.

--- Execution Model 섹션 예시 ---

## Execution Model: Advisor / Worker

The main session acts as Advisor. Focus on judgment,
not implementation labor.

Advisor (main session) handles:
- Requirement analysis, task decomposition, design decisions
- Writing task briefs for Workers
- Verification: inspect diffs directly, run tests directly
- Final commit approval and user reporting

Worker (subagent via Agent tool, model: "inherit") handles:
- All implementation: code writing, modification, test authoring
- Independent tasks are delegated in parallel

Brief requirements:
- Include context Advisor already gathered so Workers skip re-exploration
- Include file paths, project conventions, known pitfalls,
  and completion criteria (tests that must pass)

Boundaries:
- Never trust a Worker's completion report as-is.
  Approve only after verifying diffs and tests directly.
- Failed verification goes back as a revision brief.
  Direct fixes by Advisor are allowed only for trivial finishing touches.
- Tasks where delegation overhead exceeds the work itself
  (one or two line edits) are done directly.

Advisor consultation timing (when a Worker reports to Advisor):
- Report BEFORE substantive work: before writing, before committing
  to an interpretation, before building on an assumption.
  Orientation (finding files, reading sources, seeing what's there)
  is not substantive work. Writing, editing, and declaring an answer are.
- Report when the task seems complete. BEFORE this report, make the
  deliverable durable: write the file, save the result, commit the
  change. A durable result persists even if the session ends.
- Report when stuck: errors recurring, approach not converging,
  results that don't fit.
- Report when considering a change of approach.
- On tasks longer than a few steps, report at least once before
  committing to an approach and once before declaring done.
  On short reactive tasks where the next action is dictated by tool
  output just read, repeated reports are unnecessary. The first
  report adds most of the value, before the approach crystallizes.

Handling advice (how a Worker treats Advisor feedback):
- Give the advice serious weight. Adapt only when a step fails
  empirically, or primary-source evidence contradicts a specific
  claim (the file says X, the paper states Y).
- A passing self-test is not evidence the advice is wrong. The test
  likely does not check what the advice is checking.
- If retrieved data points one way and Advisor points another,
  do not silently switch. Surface the conflict in one more report:
  "I found X, you suggest Y, which constraint breaks the tie?"
  A reconcile step is cheaper than committing to the wrong branch.

--- 섹션 끝 ---

━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
Phase 3. 실행
━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━

확정된 변경 목록을 즉시 실행해줘. Phase 2에서 위임이 필요하다고 판단한 작업에만 Advisor/Worker 원칙 적용. 나머지는 메인 세션이 직접 수정하고 검증:
- 위임 이득이 분명한 파일 수정은 프로젝트 기본 모델을 상속한 Worker에게 브리프와 함께 위임
- Worker 브리프에 Advisor 보고 시점 2개를 명시:
  ① 접근 방식 확정 전 1회, ② 완료 선언 전 1회 (보고 전 결과물을 파일로 먼저 저장)
- 위임 이득이 확인된 독립 작업만 병렬 위임
- 완료 후 diff를 직접 확인한 뒤 승인
- 200줄을 초과하면 중복과 불필요한 설명을 먼저 검토하고, 주제나 적용 범위가 나뉠 때만 분리
- 단순 @import 분리는 시작 시 읽는 전체 컨텍스트를 줄이지 않으므로 분리 자체를 목표로 삼지 않음

완료 기준:
- Phase 1의 5가지 기준을 다시 판정하고 근거를 남김
- 해당 없음 또는 근거 없음인 항목은 내용을 지어내지 않고 그대로 보고
- Execution Model이 프로젝트에 필요하다고 판단한 경우에만 반영
- 가능하면 200줄 미만을 유지하고, 초과 시 분리 근거를 보고

전체 완료 후 최종 보고:
- 변경된 파일 목록과 각 파일의 핵심 변경 내용
- 개선 전후 판정 비교표
- 남은 권장 사항 (있는 경우)

프롬프트 안의 Execution Model 섹션은 재사용하기 쉽도록 영어 예시로 두었습니다. Anthropic이 CLAUDE.md를 영어로 쓰라고 요구하는 것은 아니므로 실제 팀의 언어를 유지하면 됩니다. 분량이 부담스러우면 .claude/rules/execution-model.md로 분리해 관리할 수 있습니다. 다만 paths가 없는 규칙과 @import한 문서는 시작 시 로드되므로, 파일을 나누는 것만으로 컨텍스트가 줄지는 않습니다. 적용 범위를 실제로 한정할 수 있을 때만 경로 조건을 사용하세요. 공식 memory 문서의 길이 권장은 강제 제한과 구분해야 합니다.

영어 예시가 부담스러운 분을 위해 같은 내용을 한국어로 옮겨 둡니다. 실제 CLAUDE.md에는 둘 중 팀에 맞는 언어 하나만 넣으면 됩니다.

Execution Model: Advisor / Worker (번역)

메인 세션은 Advisor 역할을 한다. 구현 노동이 아니라 판단에 집중한다.

Advisor(메인 세션)가 맡는 일: 요구사항 분석·작업 분해·설계 결정 / Worker에게 줄 작업 지시서 작성 / 검증(diff를 직접 열어보고 테스트를 직접 실행) / 최종 커밋 승인과 사용자 보고

Worker(Agent 도구로 띄운 subagent, model: "inherit")가 맡는 일: 코드 작성·수정·테스트 작성 등 모든 구현 / 서로 독립적인 작업은 병렬로 위임

지시서 요건: Advisor가 이미 모은 맥락을 넣어 Worker가 다시 탐색하지 않게 한다 / 파일 경로, 프로젝트 관례, 알려진 함정, 완료 기준(통과해야 할 테스트)을 넣는다

경계: Worker의 완료 보고를 그대로 믿지 않는다. diff와 테스트를 직접 확인한 뒤에만 승인한다 / 검증에 실패하면 수정 지시서로 되돌린다. Advisor가 직접 고치는 건 사소한 마무리만 허용한다 / 위임 비용이 일보다 큰 작업(한두 줄 수정)은 직접 한다

Worker가 Advisor에게 보고하는 시점: 실질적인 작업 전에 보고한다(쓰기 시작하기 전, 해석을 확정하기 전, 가정 위에 쌓기 전). 파일 찾기·자료 읽기·현황 파악은 실질적인 작업이 아니고 쓰기·수정·답 확정이 실질적인 작업이다 / 작업이 끝났다고 보일 때 보고한다. 그 전에 결과물을 파일 저장·커밋 등으로 남겨 세션이 끊겨도 사라지지 않게 한다 / 막혔을 때(같은 오류 반복, 접근이 수렴하지 않음, 결과가 맞지 않음), 접근을 바꾸려 할 때 보고한다 / 몇 단계 넘는 작업은 접근을 확정하기 전 한 번, 완료 선언 전 한 번은 꼭 보고한다. 방금 읽은 도구 출력이 다음 행동을 정해 주는 짧은 작업은 반복 보고가 필요 없다. 가치는 대부분 첫 보고, 접근이 굳기 전에 나온다

Worker가 조언을 다루는 법: 조언을 무겁게 받아들인다. 실제로 단계가 실패하거나 1차 출처가 특정 주장과 어긋날 때(파일에는 X, 논문에는 Y)만 바꾼다 / 자체 테스트가 통과했다고 조언이 틀린 증거는 아니다. 그 테스트는 조언이 확인하려는 것을 보지 않을 가능성이 크다 / 찾은 데이터와 Advisor 의견이 갈리면 조용히 방향을 바꾸지 말고 한 번 더 보고한다: "X를 찾았고 Y를 제안하셨는데, 어느 제약이 우선인가요?" 확인 한 번이 잘못된 갈래로 가는 것보다 싸다

적용 전후에 무엇이 달라지는가

프롬프트를 실행하면 Phase 1 결과가 먼저 나옵니다. 다섯 기준마다 판정과 근거가 표시되고, 총 라인 수와 사용자·프로젝트 범위의 분리 여부도 함께 확인할 수 있습니다.

Phase 2에서는 변경 목록을 확정합니다. 이때 잘 작동하는 기존 부분은 수정하지 않는다는 조건을 넣었습니다. 진단을 실행한 뒤 문서 전체가 다시 작성되면서 기존 규칙이 사라지는 문제를 막기 위해서입니다. 각 항목에는 변경 위치, 유형, 현재 상태와 개선 후, 이유, 우선순위가 표시됩니다.

Phase 3에서는 확정한 목록에 따라 파일을 수정합니다. Worker에게 작업 내용을 전달하고, 서로 영향을 주지 않는 수정은 병렬로 진행합니다. 작업이 끝나면 변경 파일 목록과 개선 전후 판정 비교표가 출력됩니다.

적용 전후 비교입니다.

판정표가 좋아져도 실제 행동을 다시 확인하세요

문서 진단에서 나오는 “충족” 표시는 에이전트가 내린 자기평가입니다. 규칙만 길게 추가해도 판정표는 좋아 보일 수 있습니다. 따라서 이전에 반복해서 실패했던 작은 작업 하나를 다시 요청하고 실제 행동이 바뀌었는지 확인해야 합니다.

예를 들어 “기존 버튼 문구만 바꾸고 관련 검사까지 실행해 달라”는 시험 작업을 정했다고 해보겠습니다. 실제 프로젝트 기록이 아닌 검증 방법의 예시입니다. 변경 전후에 같은 작업을 주고, 수정한 파일 범위·실행한 검사·완료 보고의 근거를 비교합니다. 요청하지 않은 컴포넌트를 재작성했다면 규칙을 읽었다고 말해도 범위 준수는 실패입니다.

이 문장들을 전부 추가할 필요는 없습니다. 실제로 반복되는 실패 하나에 대응하는 규칙만 남기고 효과를 확인합니다. 팀의 승인 절차가 있는 저장소에서는 위 프롬프트의 ‘중간 승인 없이 연속 실행’ 부분을 그대로 쓰지 말고, 진단과 변경 제안까지만 실행하도록 바꾸세요. 원본 프롬프트는 파일 수정까지 요청하는 용도입니다.

변경 전 상태는 별도 커밋이나 백업으로 보관해 비교할 수 있게 합니다. 규칙을 손본 뒤 지시가 더 자주 충돌한다면 새 규칙을 추가하기보다 서로 다른 범위에 중복된 지침이 있는지 먼저 찾습니다. 에이전트 설정 백업과 복원 확인도 함께 읽으면 누적된 지침을 보존하는 범위를 정하는 데 도움이 됩니다.

개인적인 생각

제가 운영하는 여러 프로젝트에 이 과정을 적용했을 때 미충족으로 가장 자주 판정된 항목은 4번 시행착오 일지와 5번 실행 모델이었습니다. 앞의 세 항목은 프로젝트를 시작할 때 작성하는 경우가 많지만, 뒤의 두 항목은 운영 과정에서 따로 기록하지 않으면 비어 있기 때문입니다.

CLAUDE.md를 만든 지 얼마 되지 않았고 프로젝트 규모도 작다면 이 프롬프트를 모두 적용할 필요는 없습니다. 앞의 세 항목만 직접 확인해도 충분합니다. 반년 이상 운영했고 문서가 이미 200줄을 넘었다면, 진단을 실행하고 판정표를 기준으로 수정할 부분을 정하는 방법이 더 빨랐습니다.

단서는 하나 달아두겠습니다. 1인 운영으로 개인 프로젝트 여러 개를 굴리는 제 표본에서 나온 판단입니다. 여러 저장소에 같은 컨벤션을 강제해야 하는 팀이라면 표준화된 플러그인이나 lint 쪽이 나을 수 있습니다. 플러그인과 진단 프롬프트의 전후를 수치로 비교한 데이터는 저에게 없습니다.

영상으로 더 보기 & Reference

이 프롬프트가 나온 원본 영상입니다. CLAUDE.md와 .claude/rules/를 포함해 Claude Code의 기능들이 어떤 순서로 필요해지는지를 계단 하나씩 짚었습니다.

원본 영상에서 전체 과정 보기

다음 글에서는 CLAUDE.md와 auto memory의 경계를 다루겠습니다. 내가 쓰는 규칙표와 Claude가 스스로 적는 수첩이 어떻게 다른지, 같은 지적을 두 번 했는데도 또 틀리면 어느 쪽을 손봐야 하는지 다룹니다.

Reference

• 원본 영상: 16분만에 알아보는 왕초보를 위한 클로드코드 9개 핵심 기능정리
• CLAUDE.md의 네 가지 역할을 다룬 보조 영상
• Claude Code 공식 문서: CLAUDE.md와 memory
• Claude Code 공식 문서: subagent
• Claude Code 공식 문서: model과 effort