Claude Code에서 CLAUDE.md와 auto memory를 구분하여 사용해야 하는 이유
요약
본 글은 Claude Code에서 지식 보존을 위한 두 가지 메커니즘인 CLAUDE.md와 auto memory의 차이점을 설명합니다. 개발자가 작성하는 '규칙 문서'는 팀 공유 및 강제성이 필요한 경우에 사용하며, Claude가 스스로 학습하고 기록하는 '학습 노트'는 역할이나 취향 등 보존 가치가 있는 정보를 담습니다.
핵심 포인트
- CLAUDE.md는 개발자가 작성하며, 팀 공유와 절차적 규칙을 정의할 때 적합합니다.
- auto memory는 Claude가 판단하여 저장하는 학습 기록으로, 개인의 경험과 취향이 주로 남습니다.
- 팀 전체에 지켜지게 하려면 git에 포함되는 CLAUDE.md나 Skills를 사용해야 합니다.
- 두 메커니즘 모두 강제력이 없으므로, 필수 조건은 hooks 등을 통해 기계적으로 보장해야 합니다.
이 글은 playpark Blog에서 전재된 내용입니다.
- CLAUDE.md와 auto memory 각각을 어떻게 구분하여 사용해야 하는지에 대한 이유
./.claude/rules/
・Skills, hooks를 포함한 선택지와의 비교 - 어떤 내용을 어디에 배치해야 할지에 대한 판단 기준
Claude Code에는 세션을 넘나들며 지식을 보존하는 두 가지 메커니즘이 있습니다. 개발자가 작성하는 '규칙 문서'인 CLAUDE.md와 Claude 스스로가 작성하는 '학습 노트'인 auto memory입니다. 둘 다 '기억'처럼 보이기 때문에, 'auto memory가 있으니 더 설명할 필요가 없을 것 같다'고 기대하기 쉽습니다. 하지만 누가 작성하고, 언제 읽히며, 누구에게 전달되는지가 완전히 다릅니다. 이 점을 파악하지 못하면, 기억되기를 바라는 것이 CLAUDE.md에 쌓이고, 지켜지기를 바라는 것이 memory에 맡겨져서 '말했던 것 같은데'가 일상적으로 발생하게 됩니다.
Claude Code에서 지식을 보존하는 수단은 실질적으로 네 가지입니다.
| 접근 방식 | 작성자 | 읽어들이는 시점 | 공유 범위 |
|---|---|---|---|
| CLAUDE.md | 개발자 | 세션 시작 시 상시 | git으로 팀 공유 |
./.claude/rules/ | 개발자 | 상시, 또는 paths 일치 파일을 읽을 때 | git으로 팀 공유 |
| auto memory | Claude | 시작 시에는 MEMORY.md의 처음 200줄/25KB만, 나머지는 온디맨드 | 해당 머신만 (동일 리포지토리의 worktree 간은 공유) |
| Skills | 개발자 | 설명문은 상시, 본문은 온디맨드 | git으로 팀 공유 |
CLAUDE.md는 4단계로 읽히며, 위에서부터 순서대로 적용됩니다. 조직 IT 부서가 관리하는 정책(managed policy), 사용자 개인의 ~/.claude/CLAUDE.md, 리포지토리에 들어갈 프로젝트용 .gitignore 대상의 로컬용입니다.
auto memory는 Claude가 '보존할 가치가 있다'고 판단했을 때만 작성됩니다. 자동으로 남는 것은 역할・취향(user), 수정 이력(feedback), 진행 중인 작업(project), 외부 정보의 위치(reference) 네 가지 종류입니다.
판단 기준은 두 가지로 좁혀집니다. '팀에게도 지켜지게 하고 싶은가'와 '특정 경로나 단계 절차에 연결되는가'입니다.
- 팀 공유가 필요 → git에 넣는다.
CLAUDE.md. 경로 한정이라면./.claude/rules/,
여러 단계의 절차라면 Skills - 자신만의 역할・취향・진행 중인 작업 →
auto memory에 맡긴다.
확실히 남기고 싶은 것만CLAUDE.local.md에 직접 작성한다 - 생략되면 곤란한 처리 → CLAUDE.md에만으로는 부족하여, hooks로 기계적으로 강제해야 한다.
CLAUDE.md도 auto memory도 Claude가 참조하는 '컨텍스트'일 뿐, 강제력을 가진 메커니즘은 아닙니다. 이 전제를 벗어나면, '테스트 전에 반드시 타입 체크'와 같은 절대 조건을 CLAUDE.md에 적어놓는 것만으로 만족하고 실행을 보장할 수 없게 됩니다.
팀 개발에서 머신 로컬성이 방해가 되는 상황에서는 명시적으로 비활성화할 수 있습니다.
// ./.claude/settings.json
{
"autoMemoryEnabled": false
...
}
환경 변수 CLAUDE_CODE_DISABLE_AUTO_MEMORY=1,
세션 중의 /memory 토글로도 막을 수 있습니다. /memory는 CLAUDE.md・CLAUDE.local.md・auto memory의 저장 위치를 일람하고, 파일을 선택하여 에디터에서 열 수 있는 관리 화면이기도 합니다.
auto memory의 내용은 코드 변경과 동기화되지 않는다는 점에도 주의해야 합니다. 명령어 이름을 변경해도, memory에 남아있는 오래된 추천은 그대로 남아있을 수 있습니다. 코드로부터 도출할 수 있는 사실은 애초에 memory에 적합한 정보가 아닙니다.
CLAUDE.md와 auto memory는 충돌하는 메커니즘이 아니라, '누가 작성하는지', '누구에게 전달되는지'에 따라 역할이 나뉘어 있습니다. 팀에게 전하고 싶은 규약이나 명령어는 CLAUDE.md로, 자신만의 역할이나 진행 중인 작업은 auto memory로, 생략되면 곤란한 처리는 hooks로 — 이렇게 라우팅을 정해두면 '어디에 써야 할지' 고민하는 시간이 줄어듭니다.
이 글에서는 CLAUDE.md와 auto memory의 사용 구분 이유를 설명했습니다.

Claude Code에서 '기억시키기'와 '지키게 하기' — auto memory와 CLAUDE.md의 사용법 구분하기 더 나아가:
- CLAUDE.md, rules, auto memory, Skills 4가지를 가로로 비교한 표
- '매번 다시 말하는 것을 어디에 둘지'를 판단하기 위한 분기 흐름도
- 실제로 자주 발생하는 3가지 잘못된 배치 패턴과 그 수정 방법
을 다루고 있습니다.
playpark LLC - 업무 자동화・AI 활용・웹 개발
AI 자동 생성 콘텐츠
본 콘텐츠는 Qiita AI의 원문을 AI가 자동으로 요약·번역·분석한 것입니다. 원 저작권은 원저작자에게 있으며, 정확한 내용은 반드시 원문을 확인해 주세요.
원문 바로가기