다른 기기에서 Claude Code가 모든 것을 망각하는 이유와 해결 방법 (2026)

자동 메모리는 디렉터리이며, 이 디렉터리는 로컬에 존재합니다

자동 메모리는 기본적으로 켜져 있으며, 실제로 유용한 작업을 수행합니다. Claude는 진행하면서 빌드 명령어, 디버깅 인사이트, 발견한 컨벤션 등의 자체 노트를 프로젝트별 디렉터리에 작성합니다. 각 대화가 시작될 때 MEMORY.md 인덱스를 로드하고, 필요에 따라 주제별 파일을 읽어 들입니다.

이 모든 것은 한 컴퓨터의 홈 디렉터리 아래에 저장됩니다. 공식 문서에는 리포지토리의 모든 워크트리(worktree)와 하위 디렉터리가 하나의 메모리 디렉터리를 공유하며, 해당 파일은 기기나 클라우드 환경 간에 공유되지 않는다고 명시되어 있습니다. 따라서 "Claude가 우리의 빌드 명령어를 학습했다"는 말은 오직 그 노트북 한 대에만 해당하는 사실입니다.

기기마다 고유한 버전을 유지하므로 서로 어긋나게 됩니다

각 기기가 독립적으로 학습하기 때문에, 단순히 정보의 양만 다른 것이 아니라 서로 모순되는 정보를 가질 수 있습니다. 노트북은 Dockerfile을 수정하기 전에 빌드 명령어를 학습했고, 데스크톱은 수정한 후에 학습했을 수 있습니다. 두 기기는 서로의 존재를 알지 못하므로 충돌을 감지할 수도 없고 조정 단계도 존재하지 않습니다.

이것이 신뢰도에 미치는 영향을 생각해 보세요. 세션 내에서는 누락된 사실이 애초에 학습되지 않은 것인지, 아니면 다른 곳에서 학습된 것인지 구분할 수 없습니다. 대화 내부에서는 두 경우 모두 똑같이 보이기 때문입니다.

워크트리는 공유하지만, 기기는 공유하지 않습니다

사용자에게 유리하게 작용하는 경계가 하나 있는데, 이를 이해하면 다른 경계도 더 명확해집니다. 공식 문서에 따르면 리포지토리의 모든 워크트리와 하위 디렉터리는 단일 메모리 디렉터리를 공유합니다. 따라서 세 개의 브랜치를 위해 세 개의 워크트리를 유지하더라도 이들은 하나의 메모리를 공유하므로, 기능 브랜치에서 작업하는 동안 학습한 내용을 main 브랜치에서도 사용할 수 있습니다.

이는 올바른 설계이며, 실제 단위가 무엇인지 보여줍니다. 바로 '이 파일 시스템의 리포지토리'입니다. 이 파일 시스템을 벗어나면 다른 메모리 영역이 됩니다. 이것이 첫 번째 컴퓨터의 워크트리 5개는 메모리를 공유하는 반면, 두 번째 컴퓨터의 동일한 리포지토리는 빈 상태로 시작하는 이유입니다.

클라우드 또는 웹 세션도 또 다른 기기입니다

이 부분은 문제를 해결했다고 생각한 사람들을 놀라게 만드는 지점입니다. Claude Code 세션은 터미널이 아닌 다른 곳에서도 실행될 수 있습니다. 웹 및 모바일 클라이언트, Remote Control, 그리고 v2.1.224부터 지원되는 claude self-hosted-runner를 통해 자체 기기나 컨테이너를 세션 실행 환경으로 전환할 수 있습니다.

메모리 관점에서 보면 이들 각각은 완전히 독립된 파일 시스템입니다. 공식 문서의 표현대로 "기기 또는 클라우드 환경"이며, 컨테이너 내의 self-hosted runner가 바로 이에 해당합니다. 즉, 여러분의 노트북이 아니므로 노트북의 메모리도 아닙니다.

정리 작업(housekeeping)의 영향을 받는 폴더이기도 합니다

로컬 파일은 로컬 파일의 수명 주기를 따릅니다. ~/.claude 디렉터리의 보존 기간은 세션 기록을 정리하는 동일한 cleanupPeriodDays 설정의 지배를 받으므로, 메모리 디렉터리는 예외가 아니라 일반적인 정리 체계 내부에서 관리됩니다.

또한 버그의 영향을 받을 수도 있는데, 이는 과장하기보다 정확하게 짚고 넘어갈 필요가 있습니다. 2026년 8월 11일에 릴리스된 v2.1.228의 변경 로그에는 다음과 같은 내용이 포함되어 있습니다. "세션 정리 시 프로젝트의 메모리 폴더 내부 콘텐츠가 삭제되던 버그를 수정했습니다." 단 한 번의 릴리스로 해결되었습니다. 하지만 구조적인 교훈은 여전히 유효합니다. 도구 자체의 정리 로직에 의해 관리되는 생성된 디렉터리는 '기록'이 아니라 '캐시'이며, 버그가 없더라도 캐시로 취급해야 합니다.

세션 간 메시지 전송으로도 지식이 이동하지 않습니다

이제 Claude Code 세션은 기기 간을 포함하여 서로 메시지를 주고받을 수 있으며, 이것이 문제를 해결해 줄 것처럼 들립니다. 하지만 설계상 그렇지 않습니다. 메시지는 텍스트일 뿐, 히스토리나 파일이 아닙니다. 기기 간 메시징은 회신 전용(reply-only)입니다. 즉, 다른 기기의 세션이 여러분에게 답변할 수는 있지만, 아무런 맥락 없이 먼저 호출할 수는 없습니다. 또한 검색은 로컬 파일과 소켓에 의존하므로 컨테이너와 호스트는 서로를 전혀 볼 수 없습니다.

이것은 의도된 대로 작동하는 협업 채널일 뿐입니다. 문장을 전달할 뿐, 메모리를 전달하지는 않습니다.

`CLAUDE.md` 커밋하기. 올바른 방법이며 모두가 그렇게 해야 합니다. 프로젝트 파일은 버전 관리되므로 리포지토리와 함께 모든 기기와 팀원에게 전달됩니다. 한계점은 이 파일이 사용자가 직접 유지 관리하는 파일이라는 것입니다. 즉, Claude가 작업하면서 파악한 수많은 세부 사항이 아니라, 사용자가 정한 상시 규칙을 담고 있습니다.

새 기기에서 `/init` 다시 실행하기. 리포지토리에서 초기 CLAUDE.md를 가져오므로 실제로 유용하지만, 이는 이미 코드에 나타나 있는 내용을 다시 도출하는 것에 불과합니다. 불안정한 테스트에 대한 지식은 리포지토리에 없었기 때문에 복구할 수 없습니다.

Dropbox나 dotfiles 리포지토리로 `~/.claude` 동기화하기. 가장 많이 시도되지만 주의해야 하는 방법입니다. 도구가 독점적으로 소유하고 있다고 가정하는 경로에서 세션 데이터 및 자격 증명과 함께 생성된 상태를 동기화하게 되며, 두 기기가 동시에 쓸 가능성도 있습니다. 실제로 이렇게 하는 사람들도 있지만, 이는 공식 문서에 없는 설정이며 "내 에이전트의 메모리 폴더가 다른 호스트에 의해 절반만 작성되었다"는 끔찍한 상황을 마주할 수 있습니다. 시도해 보려면 동기화 범위를 좁히고 세션이 활성화되어 있을 때는 절대 동기화하지 마세요.

에이전트에게 다시 학습하도록 요청하기. 작동은 하지만 탐색 세션 비용이 발생하며, 다른 기기가 가진 것과 약간 다른 노트 세트가 생성됩니다. 이미 가지고 있는 정보를 재구축하기 위해 토큰 비용을 지불하는 셈입니다.

Remote Control을 사용하여 세션을 단 하나만 유지하기. 실질적인 전략입니다. 작업을 하나의 호스트에 유지하고 다른 곳에서 접속하는 방식입니다. 어긋남(drift)을 확실히 방지할 수 있지만, 이제 지식이 분실, 초기화 또는 정리될 수 있는 단일 노트북에만 종속된다는 의미이기도 합니다.

이 모든 방법은 로컬 캐시를 관리할 뿐입니다. 그 어떤 방법도 지식을 기기로부터 독립적으로 존재하게 만들지 못합니다.

폴더에 있는 내용을 필요한 주체에 따라 나누세요. 두 부분의 보관 장소가 다르기 때문입니다.

기기 특정적인 상태는 기기 특정적으로 유지되어야 합니다. 로컬 경로, 실행 중인 컨테이너, 고유한 환경의 특성 등이 이에 해당합니다. 이는 자동 메모리가 보관하도록 두고, 언제든 버릴 수 있도록 하세요.

두 번째 기기나 다른 사람에게 필요한 모든 것은 기기 외부에 존재해야 합니다. 실제로 작동하는 빌드 명령어, 특정 디렉터리가 금지된 이유, 결정 사항과 그 날짜, 불안정한 테스트와 그 이유 등이 이에 해당합니다. 이 중 어느 것도 노트북에 관한 것이 아니라 프로젝트에 관한 것입니다.

두 가지 조치로 이를 실현할 수 있습니다. 첫째, 이미 버전 관리되고 있는 스코프를 사용하세요. 리포지토리 루트에 커밋된 CLAUDE.md, 경로 범위 규칙을 위한 .claude/rules/, 그리고 서브에이전트를 사용하는 경우 홈 디렉터리에 머무는 대신 버전 관리를 통해 공유할 수 있는 .claude/agent-memory/<name-of-agent>/에 기록하는 memory: project를 활용하세요. 둘째, 규칙 형태가 아닌 지식은 모든 기기가 읽을 수 있는 저장소에 보관하세요.

MemoryLake는 이 두 번째 부분(결정 사항, 장애 보고서, 원본 문서 등)을 위한 메모리 레이어입니다. 모든 기기의 Claude Code, Codex, 그리고 API를 통한 ChatGPT에서 MCP를 통해 접근할 수 있는 단일 저장소입니다. 노트북은 캐시를 유지하고, 지식은 더 이상 노트북에 종속되지 않습니다.

1단계: API 키 생성

키를 생성하고 약 30초 만에 첫 번째 요청을 보낼 수 있습니다. 세션에 직접 붙여넣는 대신 환경 변수나 시크릿 관리자에 보관하세요. 이렇게 하면 새 기기를 설정할 때 다시 학습시킬 필요 없이 5분 만에 설정을 마칠 수 있습니다.

2단계: 첫 번째 메모리 업로드

다른 기기에서 다시 찾아내야 했던 문서, 이미지, 파일들을 업로드하세요. 런북, 아키텍처 결정 사항, 장애 보고서, API 규격서, "이 테스트가 불안정한 이유"에 대한 노트 등이 해당됩니다. 요약본이 아닌 원본 소스를 업로드하세요. 요약본은 로컬 메모리 폴더가 이미 가지고 있는 내용이며, 다른 곳으로 쉽게 이동하기 어렵습니다.

3단계: AI 및 에이전트 연결

Claude, Codex, OpenClaw 및 기타 AI 에이전트가 MCP 또는 API를 통해 메모리에 액세스할 수 있도록 하세요. 기기당 한 번만 MCP 서버를 구성하면 노트북, 데스크톱, 웹 세션, 컨테이너 내의 self-hosted runner 등 모든 세션이 동일한 저장소를 읽습니다. 이것이 로컬 메모리가 가질 수 없는 특징입니다.

첫 번째 차이점은 새 기기를 준비하는 과정이 '온보딩'이 아니라 단순한 '프로비저닝'이 된다는 것입니다. 리포지토리를 클론하고 저장소를 가리키기만 하면, 에이전트는 이 특정 컴퓨터가 기억하는 내용이 아니라 팀 전체가 알고 있는 지식을 가지고 시작합니다.

두 번째는 클라우드 및 컨테이너 세션이 더 이상 '이등 시민' 취급을 받지 않는다는 것입니다. self-hosted runner의 세션은 상속받을 로컬 메모리가 없기 때문에, 현재로서는 워크플로에서 가장 정보가 부족한 참여자입니다. 공유 저장소를 읽게 되면 노트북만큼이나 많은 정보를 갖게 되며, 이는 사용자가 직접 감독할 가능성이 가장 낮은 자동화 실행에서 가장 중요하게 작용합니다.

세 번째는 폴더를 잃어버려도 상관없어진다는 것입니다. 정리 작업으로 인한 삭제, 기기 초기화, 컨테이너 재설치 등은 손실이 아니라 단순한 번거로움에 불과하게 됩니다. 영구적으로 보존되어야 할 절반은 애초에 그 폴더에 없었기 때문입니다.

또한 이는 Claude Code가 기본적으로 수행하는 작업과 조화를 이룹니다. 자동 메모리는 리포지토리별로 로컬 노트를 계속 작성하고, CLAUDE.md는 버전 관리를 통해 상시 규칙을 계속 전달합니다. 둘 다 가장 적합하지 않은 역할인 '기준 시스템(system of record)'이 될 필요가 없습니다. 이는 하나의 메모리를 공유하는 여러 에이전트의 일관성을 유지하는 것과 동일한 역할 분담입니다.

커밋할 수 있는 모든 것을 커밋하세요

리포지토리 루트의 CLAUDE.md, 범위 지정 규칙을 위한 .claude/rules/, 프로젝트 범위의 서브에이전트를 위한 .claude/agent-memory/ 등이 있습니다. 버전 관리되는 모든 것은 자동으로 다중 기기에서 사용 가능하며 팀원들과 공유됩니다. CLAUDE.local.md 및 로컬 범위 메모리는 기기를 절대 벗어나지 않아야 하는 항목에만 사용하세요.

메모리 폴더를 캐시로 취급하세요

오늘 밤 ~/.claude/projects/<project>/memory/가 사라진다면 무엇을 잃게 될지 스스로에게 물어보세요. 아쉬운 부분이 있다면 그 콘텐츠는 잘못된 위치에 있는 것입니다. 리포지토리에 기록하거나 공유 저장소에 저장하세요. v2.1.228 패치는 이를 상기시켜 주는 계기일 뿐, 근본적인 이유는 아닙니다.

MEMORY.md는 인덱스로 유지하세요

세션 시작 시 MEMORY.md 파일의 처음 200행 또는 25KB 중 먼저 도달하는 기준까지만 로드됩니다. 항목당 한 줄로 작성하고 세부 사항은 주제 파일에 기록하면 인덱스를 이 제한 내로 유지할 수 있습니다. 비대해진 인덱스는 경고 없이 잘려 나가며, 이는 사용자가 전혀 눈치채지 못하는 실패 모드입니다.

~/.claude를 무분별하게 동기화하지 마세요

동기화를 하더라도 범위를 좁히고 신중하게 진행해야 합니다. 활성 세션 중에는 절대 동기화하지 말고, 두 기기가 동시에 쓰지 않도록 하며, 생성된 상태가 안전하게 병합될 것이라고 가정하지 마세요. 지원되는 다중 기기 경로는 도구가 소유한 디렉터리의 파일 복제가 아니라, 버전 관리와 공유 저장소입니다.

자동화된 세션에도 터미널과 동일한 컨텍스트를 제공하세요

웹 세션, Remote Control, self-hosted runner는 로컬 메모리가 없는 상태로 시작합니다. 이러한 실행이 중요하다면 공유 저장소와 커밋된 파일에 필요한 모든 내용이 포함되어 있는지 확인하세요. 그렇지 않으면 가장 감독을 받지 않는 세션이 가장 적은 컨텍스트로 작업하게 됩니다.

강제 수단으로 기대하지 마세요

Claude Code의 공식 문서에서는 지침 파일과 자동 메모리를 강제된 설정이 아닌 컨텍스트로 설명합니다. 포맷터, 보호된 경로, main 브랜치로의 직접 푸시 금지 등 모든 기기에서 반드시 준수해야 하는 사항은 훅(hook)과 CI에 속해야 하며, 이 역시 커밋되므로 다중 기기에서 작동합니다.

다른 기기에서 Claude Code가 망각하는 이유는 메모리가 로컬 디렉터리이기 때문이며, 공식 문서에서도 파일이 기기나 클라우드 환경 간에 공유되지 않는다고 직접 명시하고 있습니다. 모든 호스트는 독립적으로 학습하고, 클라우드 및 컨테이너 세션은 추가적인 호스트일 뿐이며, 해당 폴더는 일반적인 보존 정리 대상에 포함됩니다. 8월 11일 변경 로그에서 세션 정리 시 프로젝트의 메모리 폴더 내부 콘텐츠가 삭제되는 버그를 수정한 것은 생성된 디렉터리가 캐시일 뿐이라는 사실을 다시 한번 상기시켜 줍니다.

그러니 캐시는 유지하되 거기에 의존하지는 마세요. 커밋할 수 있는 것(CLAUDE.md, .claude/rules/, 프로젝트 범위의 에이전트 메모리)은 커밋하세요. 그런 다음 규칙 형태가 아닌 지식(이유, 결정 사항, 어렵게 얻은 운영 세부 정보 등)은 모든 기기가 읽을 수 있는 단일 저장소에 보관하세요. 그렇게 하면 두 번째 기기는 새로운 시작이 아니라, 단지 또 다른 진입로가 될 것입니다.