# Claude Memory MCP 가이드 (2026): 이것이 무엇인지, Claude Code가 이미 기억하는 것, 외부 memory가 정말 필요한 때

> Claude Code의 built-in memory와 external memory MCP의 경계를 정리하는 실용 가이드입니다. `CLAUDE.md`와 auto memory가 이미 하는 일, 외부 persistence가 실제로 가치를 더하는 순간, 그리고 가장 가볍고 안전한 setup surface를 구분합니다.

- URL: https://blog.laozhang.ai/ko/posts/claude-memory-mcp
- Published: 2026-04-15
- Updated: 2026-04-16
- Author: LaoZhang AI Team (https://blog.laozhang.ai/ko/about)
- Topic: Claude Code
- Tags: Claude Code, MCP, Memory, 개발자 워크플로

---
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를 가지는 시점은 세 번째 줄이 실제 병목이 되었을 때뿐입니다.

![Claude Code 내장 memory와 external memory MCP를 나누는 route board](https://blog.laozhang.ai/posts/ko/claude-memory-mcp/img/memory-routes.png)

## 외부 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 가이드](https://blog.laozhang.ai/ko/posts/claude-code-memory)로 가고, 이 페이지는 “언제 외부 layer가 필요한가”만 좁게 다룹니다.

## external memory MCP가 실제로 해결하는 문턱은 무엇인가

![external memory MCP를 정당화하는 실제 threshold board](https://blog.laozhang.ai/posts/ko/claude-memory-mcp/img/external-thresholds.jpg)

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 문제를 풀고 있는 셈입니다. 그 출처가 회의록 도구나 노트 앱이라면 [Claude Code에 회의록·노트 도구를 연결하는 네 가지 경로](https://blog.laozhang.ai/ko/posts/connect-claude-code-to-note-taker)부터 보는 편이 빠릅니다.

세 번째는 **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 중 무엇을 고를까

![plugin, remote MCP, project-shared를 고르는 ownership ladder](https://blog.laozhang.ai/posts/ko/claude-memory-mcp/img/setup-ladder.jpg)

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](https://blog.laozhang.ai/ko/posts/claude-code-best-mcp-servers)보다 더 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를 줍니다.