Claude Code에는 이미 두 개의 built-in memory surface가 있습니다. CLAUDE.md는 명시 규칙을, auto memory는 반복 교정에서 학습하는 pattern을 맡습니다. Claude Memory MCP는 그와 다른 것으로, Claude Code의 built-in machine-local memory boundary 밖에 context를 저장하거나 가져오는 external MCP server를 뜻합니다.
이 구분이 보이면 추천도 바로 달라집니다. 문제가 repo rules, startup instructions, 반복되는 preference, one-machine habits에 머물러 있다면 먼저 정리해야 할 것은 built-in layers입니다. 반대로 중요한 문맥을 /compact 뒤에도 남겨야 하거나, 여러 tools 사이에서 retrieval이 필요하거나, 머신 사이 continuity가 필요하거나, team-shared memory가 실제로 필요하다면 그때 external memory MCP가 현실적인 선택지가 됩니다.
Anthropic의 current Claude Code memory docs와 MCP docs도 이 둘을 여전히 다른 surface로 다룹니다. CLAUDE.md와 auto memory는 Claude Code의 built-in behavior이고, MCP servers는 approval, scope, operator trust, third-party risk를 동반하는 external integrations입니다. 그래서 먼저 물어야 할 것은 어떤 tool이 더 세 보이느냐가 아니라, 어떤 layer가 이 context를 먼저 가져가야 하느냐입니다.
| 지금의 실제 문제가... | 먼저 가야 할 곳 | 왜 이 lane이 먼저인지 |
|---|---|---|
| repo rules, 시작부터 필요한 instructions, 명시 규칙 | CLAUDE.md | Claude가 세션 시작부터 봐야 하는 built-in explicit layer이기 때문 |
| 반복 수정으로 쌓이는 habits, one-machine preference | auto memory | built-in learning layer이지 universal shared store가 아니기 때문 |
/compact 이후 continuity, cross-tool retrieval, cross-machine continuity, team sharing | external memory MCP | 여기서부터 built-in normal boundary를 넘어가기 때문 |
앞의 두 줄로 설명되는 문제라면, 지금은 server를 더하지 않는 편이 맞습니다. 외부 memory가 value를 가지는 시점은 세 번째 줄이 실제 병목이 되었을 때뿐입니다.
외부 layer를 붙이기 전에 Claude Code가 이미 기억하는 것
많은 사람이 너무 빨리 external memory를 찾는 이유는 memory를 하나의 기능처럼 보기 때문입니다. 하지만 Claude Code의 built-in memory는 이미 역할이 나뉘어 있습니다.
CLAUDE.md는 explicit rule layer입니다. 테스트 명령, review expectation, 위험한 작업 경계, 디렉터리 규칙, 반복해서 다시 설명하고 싶지 않은 workflow rule은 여기에 두는 것이 맞습니다. 이 layer의 강점은 “강제력”보다 “시작부터 보인다”는 점입니다.
auto memory는 learning layer입니다. 반복 correction으로 학습할 수 있는 습관, preference, local pattern을 맡기기에 좋습니다. 다만 이것도 current contract 안에서는 분명히 bounded입니다. machine-local layer이지, 어디서나 자동으로 따라오는 shared memory는 아닙니다.
그래서 더 유용한 질문은 “Claude가 기억하느냐”가 아니라 “어느 layer가 무엇을 기억해야 하느냐”입니다. repo rules면 CLAUDE.md, 반복 habit이면 auto memory, cross-tool·cross-machine·team 공유면 external memory MCP. 이 분기가 잡히면 혼란이 크게 줄어듭니다.
/memory와 /context도 건너뛰지 않는 편이 좋습니다. external memory가 필요하다고 느낀 문제 상당수는 실제로는 built-in contract가 명시적이지 않았거나, 로드된 layer를 잘못 이해한 경우입니다. built-in memory 전체 구조가 필요하면 Claude Code Memory 가이드로 가고, 이 페이지는 “언제 외부 layer가 필요한가”만 좁게 다룹니다.
external memory MCP가 실제로 해결하는 문턱은 무엇인가
external memory MCP는 추상적으로 “더 강한 memory”가 아니라, built-in 밖의 continuity problem을 해결할 때 의미가 있습니다.
첫 번째 문턱은 compaction survival입니다. 중요한 작업 문맥이 /compact 이후 반복해서 사라지고, 그걸 매번 대화만으로 복구하기 어렵다면 이제 chat 바깥에 있는 persistence surface가 필요해집니다.
두 번째는 cross-tool retrieval입니다. 필요한 정보가 repo rules나 learned habit이 아니라 notes, issue history, shared docs, 다른 tool 안에 있는 경우입니다. 이때는 built-in memory를 더 두껍게 만드는 문제가 아니라 retrieval 문제를 풀고 있는 셈입니다.
세 번째는 cross-machine continuity입니다. Claude Code의 built-in memory는 여전히 machine-local입니다. 여러 머신과 remote environment를 오가며 같은 memory surface가 따라와야 한다면, 그 자체가 external layer의 정당한 이유가 됩니다.
네 번째는 team sharing입니다. 가장 그럴듯하게 들리지만 동시에 가장 빨리 과잉 업그레이드되기 쉬운 문턱이기도 합니다. 팀 공용 memory는 shared recall이나 shared retrieval이 정말 반복 업무가 되었을 때만 자연스럽습니다.
시장의 memory-MCP product pages는 대체로 이 네 가지를 팔고 있습니다. 거기서 읽어야 할 것은 “external memory의 대표 job이 무엇인가”이지, “Claude Code 기본 기능이 무엇을 빠뜨렸는가”가 아닙니다.
plugin, remote MCP, project-shared 중 무엇을 고를까
external threshold가 실제라는 것이 확인되면, 다음 질문은 product name보다 ownership이 됩니다.
가장 안전한 기본값은 personal first입니다. 아직 한 사람이 workflow를 검증하는 단계라면 setup도 personal로 두는 편이 낫습니다. plugin-like path든 remote MCP든 상관없지만, 먼저 증명할 것은 “외부 memory가 정말 필요한가”입니다.
Remote MCP는 external retrieval이나 persistence 자체가 핵심 value일 때 자연스럽습니다. 하지만 remote는 operator trust, service availability, dependency boundary를 함께 늘립니다. marketing 문구가 아니라, 이름 붙일 수 있는 continuity failure를 닫아 주는지로 판단해야 합니다.
Project-shared는 더 뒤입니다. Anthropic이 local / project / user scope를 나눠 두는 이유는 ownership이 recommendation을 바꾸기 때문입니다. repo가 integration을 소유해야 하는 때는 그것이 이미 shared workflow가 되었을 때입니다.
그래서 이 글은 Claude Code에서 먼저 추가할 MCP보다 더 narrow해야 합니다. 저 글이 broader MCP choice라면, 이 글은 memory-specific escalation judgment입니다.
memory-MCP claim을 hype 그대로 읽지 않는 방법
Anthropic official docs가 built-in baseline을 정하고, vendor pages는 external market signal을 보여 준다고 보면 판단이 쉬워집니다.
각 claim을 operational question으로 바꿔 보면 됩니다.
Persistent memory: 무엇이 어디까지 persistent한가./compact이후인지, cross-tool인지, cross-machine인지, 팀 전체인지.Works with Claude: MCP extension인지, built-in feature처럼 들리게만 쓰고 있는지.Shared memory: data ownership은 누구에게 있고, 누가 쓰며, 누가 prompt-injection risk를 감당하는지.Easy setup: 한 사람에게 쉬운지, repo 차원에서도 maintainable한지.
잘못된 upgrade는 도움이 안 되는 수준이 아니라, low-trust context를 새로 들여오는 문제가 됩니다. 그래서 먼저 built-in official truth를 baseline으로 세우고, 그 다음 gain·ownership·maintenance cost로 external layer를 비교해야 합니다.
지금은 아무것도 더하지 않는 편이 맞는 경우
이 페이지의 중요한 결론 중 하나는, 어떤 reader에게는 “지금은 추가하지 않는다”가 가장 좋은 답이라는 점입니다.
다음 중 하나에 해당한다면 외부 layer를 서두르지 않는 편이 낫습니다.
- repo rules가 아직
CLAUDE.md에 정리되어 있지 않다 - auto memory가 지저분하거나, 명시 규칙이 맡아야 할 일까지 떠안고 있다
/memory로 실제 로딩 상태를 아직 확인하지 않았다- pain의 정체가 continuity gap보다 context bloat에 더 가깝다
- workflow가 아직 one-machine / one-repo 안에 머물러 있다
이 상태에서 external memory server를 더하면 confusion만 가리기 쉽습니다. 그래서 stop rule은 FAQ가 아니라 본문 앞쪽에 있어야 합니다.
FAQ
Claude Code에 memory MCP가 기본으로 필요한가요?
보통은 아닙니다. 문제가 repo rules, learned habits, one-machine continuity 수준이면 먼저 CLAUDE.md와 auto memory를 정리하는 편이 맞습니다.
Claude Code는 기본으로 무엇을 기억하나요?
CLAUDE.md를 통한 explicit rules와 auto memory를 통한 learned patterns입니다. 하지만 universal shared memory는 아닙니다.
/compact가 external layer를 정당화하는 때는 언제인가요?
중요한 문맥이 compaction 이후 반복해서 사라지고, 그 문맥이 chat 밖에 살아 있어야 할 때입니다. rule이 애초에 CLAUDE.md에 없었다면 built-in부터 고쳐야 합니다.
plugin과 remote MCP 중 무엇을 먼저 생각해야 하나요?
가장 가벼운 personal setup부터입니다. remote는 external retrieval / persistence 자체가 핵심일 때만 앞당겨집니다. project-shared는 그보다 더 늦습니다.
언제 “아직 아무것도 더하지 말자”가 정답인가요?
CLAUDE.md, auto memory, /memory의 역할이 아직 정리되지 않았을 때입니다. 그 단계에서는 built-in hygiene가 거의 항상 더 높은 value를 줍니다.