Claude Code의 컨텍스트, 메모리, MCP는 같은 기능이 아닙니다. 긴 세션 후 답변이 흔들리거나, 새 세션에서 프로젝트 규칙을 잊거나, MCP 도구 결과가 너무 커서 대화가 복잡해지는 현상은 모두 "기억 문제"처럼 보입니다. 하지만 원인은 현재 작업 창, 시작 시 로드되는 내장 메모리, 외부 도구 레이어 중 하나입니다. memory MCP를 추가하기 전에 어느 레이어가 실패했는지 먼저 증명해야 합니다.
가장 빠른 순서는 다음과 같습니다.
| 증상 | 먼저 실행 | 증명하는 것 | 서버 전 작은 수정 |
|---|---|---|---|
| 긴 세션 뒤 답변이 이전 분기를 끌고 온다 | /context | 대화, 파일, tool 결과, MCP 출력이 현재 창을 압박하는지 | 경계에서 압축, 잔여 분기 정리, 작업 분리, 출력 축소 |
| 새 세션에서 프로젝트 규칙이 없다 | /memory | 어떤 CLAUDE.md, import, auto memory가 로드됐는지 | 올바른 범위의 내장 메모리 수정 |
| 외부 도구가 많거나 끊기거나 noisy하다 | /mcp | 어떤 MCP server가 연결되고 외부 레이어가 무엇을 하는지 | server 범위 축소, noisy tool 비활성화, 연결 수정 |
| 반복 절차를 매번 다시 설명한다 | /skills 또는 subagent | 기억이 아니라 재사용 절차가 필요한지 | skill로 만들거나 큰 탐색을 격리 |
중단 규칙은 단순합니다. 정리된 CLAUDE.md, /compact, /clear, skill, subagent, 코드 검색으로 해결된다면 외부 memory MCP는 아직 필요하지 않습니다. 외부 서버는 여러 기기, 여러 도구, 팀 공유 회상, 또는 내장 메모리에 넣기 어려운 동적 작업 상태가 필요할 때만 후보가 됩니다. 그때도 저장 위치, 삭제 방법, 읽기 권한, 비밀 정보 유입 가능성을 먼저 확인해야 합니다.
빠른 판단: 어느 레이어가 실패했나
Claude Code의 연속성은 하나의 "기억력"이 아니라 여러 레이어입니다. 현재 대화는 Claude가 지금 보고 있는 작업 창입니다. 내장 메모리는 세션 시작 시 그 창에 들어오는 프로젝트나 사용자 배경입니다. MCP는 외부 도구, 데이터, 액션에 연결되는 레이어입니다. skill은 반복 가능한 방법을 담고, subagent는 메인 스레드를 오염시키지 않아야 하는 큰 탐색을 분리합니다.
실무에서 흔한 오해는 memory MCP와 context bloat를 바로 하나의 해결책으로 묶는 것입니다. 이 수요는 현실적이지만, 설치를 첫 단계로 만들면 위험합니다. 문제가 현재 컨텍스트 창의 포화라면, 새 memory MCP는 tool 정의, 반환 결과, 권한 판단을 더 추가할 수 있습니다. 따라서 질문은 "어떤 memory MCP가 좋나"가 아니라 "이미 있는 어느 레이어가 실패했나"가 되어야 합니다.
| 실패 패턴 | 가능성이 높은 소유자 | 확인 표면 | 다음 행동 |
|---|---|---|---|
| 긴 세션에서 폐기한 계획을 다시 끌고 온다 | 현재 context window | /context | 압축, clear, 분리, output 제한 |
| 새 세션에서 안정 규칙이 없다 | 내장 memory | /memory | CLAUDE.md, import, user memory 수정 |
| MCP tool이 중복되거나 너무 큰 결과를 준다 | MCP | /mcp | server를 줄이고 tool 출력 제한 |
| 매번 같은 흐름을 설명한다 | skill | /skills | 절차를 skill로 이동 |
| 많은 파일을 읽어야 하지만 본문 흐름을 지켜야 한다 | subagent | handoff summary | 탐색을 격리하고 결론만 반환 |
| 여러 기기, 팀, 도구 사이에 동적 기억이 필요하다 | 외부 memory MCP | server policy | retention, deletion, permission 검토 |
이 표의 목적은 memory MCP를 부정하는 것이 아닙니다. 올바른 위치로 늦추는 것입니다. 실패가 내장 메모리라면 CLAUDE.md를 고치면 됩니다. 실패가 MCP라면 server 범위를 줄이면 됩니다. 실패가 반복 절차라면 skill이 더 적합합니다. 외부 memory MCP는 이보다 작은 선택지가 맞지 않을 때만 설계 대상이 됩니다.
/context가 증명하는 것
/context는 현재 작업 창을 증명합니다. 그 안에는 대화, 읽은 파일, tool 결과, MCP 출력, 로드된 메모리, 압축 요약, 선택된 도구 정보가 들어갑니다. 긴 세션이 진행될수록 이 창은 무거워지고, 이전 탐색의 잔여물이 현재 판단에 영향을 줄 수 있습니다. 따라서 같은 세션 후반에서 품질이 떨어지면 가장 먼저 /context를 봅니다.
전형적인 신호는 다음과 같습니다. 이미 버린 접근을 Claude가 다시 제안합니다. 큰 로그나 웹 스냅샷을 읽은 뒤 답변이 거칠어집니다. MCP server가 원본 JSON을 너무 크게 반환합니다. compaction 후 핵심 경계가 사라지고 넓은 요약만 남습니다. 한 스레드 안에 조사, 구현, 리뷰, 배포 결정이 모두 섞입니다. 이 상황에서 memory MCP를 추가하면 더 많은 외부 결과가 같은 창으로 들어와 문제를 키울 수 있습니다.
수정 순서는 작게 갑니다. 안정된 결론이 생긴 지점에서 /compact를 사용합니다. 부차적 조사는 다른 스레드나 subagent로 옮깁니다. tool에는 summary, handle, pagination, 필요한 필드만 요구합니다. 현재 창이 이미 잘못된 분기를 많이 담고 있다면 /clear로 새로 시작하고 프로젝트 메모리를 다시 로드하는 편이 낫습니다.
내장 메모리가 담당하는 것
내장 메모리는 새 세션이 시작될 때 Claude Code가 알고 있어야 하는 안정된 배경을 담당합니다. 저장소 규칙, 이름 규칙, 테스트 명령, 릴리스 경계, 사용자 선호, 짧은 운영 원칙, 긴 문서로 가는 포인터가 여기에 들어갑니다. CLAUDE.md, import, auto memory는 시작 시 context window로 들어오기 때문에, 너무 길면 매 세션의 시작부터 부담이 됩니다.
좋은 메모리는 짧고 안정적입니다. 나쁜 메모리는 모든 과거 대화, 긴 조사 기록, 큰 표, 로그, 임시 결정을 그대로 담습니다. 그렇게 되면 "기억"이 오히려 컨텍스트를 압박합니다. 긴 증거는 파일이나 이슈, 문서, 데이터베이스에 보관하고, 메모리에는 어디를 봐야 하는지와 어떤 규칙이 중요한지만 남기는 것이 안전합니다.
/memory는 새 세션에서 유지되어야 할 규칙이 보이지 않을 때 사용합니다. 규칙이 아예 저장되지 않았는지, 잘못된 scope에 저장됐는지, 저장됐지만 현재 창이 너무 복잡해 잘 활용되지 않는지를 분리합니다. 처음 두 경우는 내장 메모리를 수정합니다. 마지막 경우는 /context 정리 문제입니다. 세 경우 모두 외부 memory MCP가 자동 답은 아닙니다.
MCP가 담당하는 것
MCP는 외부 접근을 담당합니다. 코드 검색, DB, 브라우저, issue tracker, 문서, 내부 서비스, 액션, 외부 저장소 같은 것을 Claude Code에 연결합니다. memory MCP도 이 레이어의 server이므로, 기억 기능으로만 볼 수 없습니다. transport, 권한, tool 설명, output 크기, retention, deletion을 모두 평가해야 합니다.
/mcp는 외부 레이어 자체가 의심스러울 때 봅니다. server가 끊겼는지, tool이 중복됐는지, 같은 기능이 여러 server에서 노출되는지, description이 지나치게 긴지, 각 호출이 큰 원본 데이터를 반환하는지 확인합니다. 이 문제가 남아 있으면 memory MCP를 추가하기 전에 MCP 레이어를 정리해야 합니다.
코드 검색, 프로젝트 메모리, 장기 작업 상태도 분리해야 합니다. 코드 검색은 파일과 symbol 위치를 찾습니다. 내장 메모리는 프로젝트 결정과 규칙을 유지합니다. 외부 memory MCP는 세션과 도구를 넘어 변화하는 상태를 찾아야 할 때 의미가 있습니다. 코드 위치를 memory에 저장하기 시작하면, 오래된 정보와 진짜 규칙이 섞여 유지보수가 어려워집니다.
외부 memory MCP 전에 더 작은 수정
반복 절차는 memory보다 skill이 낫습니다. skill은 절차, 참고 자료, 체크리스트, 예시를 담을 수 있지만 매번 모든 세부 정보를 context에 올리지 않아도 됩니다. memory는 "무엇을 알아야 하는가"를 담당하고, skill은 "어떻게 실행하는가"를 담당합니다. 이 차이를 두면 많은 연속성 문제가 사라집니다.
큰 탐색은 subagent로 분리합니다. 메인 스레드에는 결론, 증거 경로, 남은 위험, 다음 행동만 필요합니다. 코드베이스 전체 탐색, 로그 분석, 문서 비교, 로컬라이즈 판단 같은 작업은 읽은 과정 전체가 메인 컨텍스트에 남으면 뒤의 판단을 흐립니다. 격리된 탐색에서 짧은 handoff만 가져오는 편이 품질을 지킵니다.
/compact와 /clear도 실무적으로 중요합니다. /compact는 안정된 결론을 짧은 상태로 남길 때 사용합니다. /clear는 대화 잔여물이 너무 많아 새로 시작하는 편이 나을 때 사용합니다. 이 두 명령으로 품질이 회복된다면 문제는 외부 기억이 아니라 현재 컨텍스트 관리입니다.
외부 memory MCP가 정당화되는 조건
외부 memory MCP는 실제 임계값을 넘을 때 가치가 있습니다. 첫째, 여러 기기나 여러 IDE 사이에서 작업 상태가 이어져야 합니다. 둘째, 팀이 같은 프로젝트 사실과 결정을 공유해야 합니다. 셋째, issue, 문서, 채팅, 코드 이벤트를 한 조회 레이어로 묶어야 합니다. 넷째, 동적 작업 상태가 너무 크거나 자주 바뀌어 CLAUDE.md에 넣기 어렵습니다.
그 후에도 데이터 질문이 먼저입니다. server는 어디에 저장합니까? 누가 읽을 수 있습니까? 어떻게 삭제합니까? 원본 대화, 요약, embedding, 사용자가 쓴 fact 중 무엇을 저장합니까? secret이나 고객 데이터가 들어가지 않도록 어떻게 막습니까? audit와 rollback은 있습니까? 이 답이 모호하면 기본 워크플로에 넣지 않습니다.
도입은 작게 시작합니다. 한 프로젝트, 허용되는 fact, 금지되는 fact, 삭제 경로, 성공 조건을 정합니다. 몇 번의 실제 작업 후 반복 설명이 줄었는지, context bloat가 줄었는지, retrieval이 정확해졌는지, 잘못된 기억이 늘지 않았는지 비교합니다. 증거가 없으면 server는 실험으로 남겨야 합니다.
수정 매트릭스와 증거 패킷
아키텍처를 바꾸기 전에는 다음 증거를 남깁니다.
| 캡처할 것 | 중요한 이유 | 의사결정 용도 |
|---|---|---|
| 증상과 발생 시점 | 새 세션 실패인지 긴 세션 드리프트인지 분리 | /memory와 /context 우선순위 결정 |
| /context 출력 | 현재 창의 압박과 재료 출처 확인 | 압축, 분리, output 제한 결정 |
| /memory 출력 | 실제 로드된 메모리 확인 | CLAUDE.md나 import 수정 위치 결정 |
| /mcp 상태 | active server와 외부 레이어 확인 | server 중지, 축소, 수정 결정 |
| 큰 tool 결과 | context bloat의 원인 찾기 | summary, pagination, handle 요구 |
| compaction 경계 | 어떤 판단이 남아야 하는지 설명 | 압축 후 누락 방지 |
| 데이터 보관 조건 | 외부 기억의 안전성 판단 | memory MCP 가능 여부 결정 |
이 패킷은 "왜 더 작은 수정으로는 부족한지"를 보여주기 위한 것입니다. 증거가 내장 메모리를 가리키면 CLAUDE.md를 고칩니다. 현재 컨텍스트를 가리키면 재료를 줄입니다. MCP를 가리키면 server를 정리합니다. 반복 절차를 가리키면 skill을 만듭니다. 외부 recall을 가리킬 때만 memory MCP 비교로 넘어갑니다.
자주 묻는 질문
Claude Code의 context와 memory는 같은가요?
아닙니다. context는 현재 작업 창입니다. memory는 새 세션 시작 시 그 창에 로드되는 지속 배경입니다. memory는 context의 일부가 될 수 있지만, context 자체가 장기 저장소는 아닙니다.
Claude Code memory MCP를 바로 설치해야 하나요?
보통은 아닙니다. 먼저 /context, /memory, /mcp로 레이어를 확인하세요. 내장 메모리, cleanup, skill, subagent, 코드 검색으로 해결되지 않는 cross-session 또는 cross-tool recall이 있을 때만 검토합니다.
Tool Search가 MCP의 context 비용을 없애나요?
없애지 않습니다. Tool Search는 초기에 로드되는 tool 정의를 줄일 수 있지만, 실제로 사용한 tool과 결과는 여전히 모델이 처리해야 하는 재료가 됩니다. compact description, bounded output, filter, summary, handle이 필요합니다.
프로젝트 규칙은 CLAUDE.md와 MCP server 중 어디에 둬야 하나요?
대부분의 안정 규칙은 CLAUDE.md나 import된 내장 메모리에 둡니다. MCP는 외부 접근과 액션을 위한 레이어입니다. 짧은 규칙을 외부 tool 호출로 만들면 오히려 시스템이 취약해질 수 있습니다.
memory 대신 skill을 쓰는 경우는 언제인가요?
문제가 반복 가능한 방법이면 skill을 씁니다. 리뷰, 릴리스, 데이터 정리, 글 작성, 장애 대응 같은 절차가 여기에 해당합니다. memory는 시작 시 알아야 할 사실과 선호를 담습니다.
코드 검색은 memory인가요?
아닙니다. 코드 검색은 파일과 symbol을 찾는 기능입니다. memory는 결정과 규칙을 유지합니다. 외부 memory MCP는 그 둘을 넘어서는 지속 recall이 필요할 때 사용합니다.