Claude Code의 자동 메모리 (auto memory)를 5개월 동안 사업 운영 프로젝트에서 방치하듯 운용한 결과를 전부 전수 조사했다. 결론부터 말하자면, 메모리는 예상보다 부패하지 않았지만, 인덱스(index)의 200행 제한을 넘긴 순간부터 '가장 중요한 운영 규칙'이 조용히 읽히지 않게 되고 있었다.

TL;DR

계기

2026년 2월부터 디지털 콘텐츠 판매 사업을 통째로 Claude Code와 함께 운영하고 있다. Zenn 기사 집필, X 운영 자동화, VPS 상의 앱 유지보수까지 거의 전부다.

Claude Code에는 자동 메모리 기능이 있다. 세션을 넘나들며 기억해 두어야 할 것을 Claude가 스스로 판단하여 파일에 쓰고, 다음 세션에서 읽어들이는 구조다. 나는 특별히 관리하지 않고 Claude가 쓰고 싶은 대로 쓰게 두었다.

어느 날, 세션 시작 시의 컨텍스트(context)에 다음과 같은 경고가 섞여 있는 것을 발견했다.

WARNING: MEMORY.md is 253 lines (limit: 200). Only part of it was loaded.

인덱스가 상한을 초과하여, 일부만 읽히고 있다. 즉 매 세션마다 무언가를 잊은 상태로 일을 하고 있었다는 뜻이다. 무엇을 얼마나 잊고 있었는지, 전부 조사해 보기로 했다.

전제: 자동 메모리의 구조

Claude Code의 자동 메모리는 ~/.claude/projects/<프로젝트>/memory/에 저장된다. 구조는 2층이다.

• MEMORY.md — 인덱스. 세션 시작 시 앞부분 200행 또는 25KB까지가 자동으로 로드된다.
• 토픽 파일 — 개별 기억 (feedback_*.md, project_*.md 등). 인덱스에서 링크되어 필요할 때만 Claude가 읽으러 간다.

중요한 점은, 토픽 파일은 인덱스에 올라와 있지 않으면 실질적으로 존재하지 않는다는 것이다. 파일 자체가 디스크에 있더라도 인덱스의 읽기 범위를 벗어나면, Claude는 그 기억이 있다는 사실 자체를 알지 못한다.

5개월 동안 메모리는 이렇게 성장했다

먼저 현황 파악. 2026-03-17(가장 오래된 것) ~ 2026-04-27(최신) 사이에 작성된 파일이 26개 있었다.

토픽 파일 25개의 합계는 566행이다. 1개당 평균 22행이며, 각 파일은 name / description / 본문 / Why / How to apply라는 정형화된 형식으로 작성되어 있다. 여기까지는 건전해 보인다.

문제는 인덱스였다. 253행의 내역을 살펴보니, 48221행이 2월4월의 작업 진행 로그를 직접 작성한 것으로 채워져 있었다. 매출 기록, 기사 공개 로그, 실험 결과…… 본래 토픽 파일에 적고 링크해야 할 내용이 인덱스 본체에 쌓여 있었다.

원인도 특정할 수 있었다. 인덱스의 224행에 다음과 같이 적혀 있었다.

중간 경과를 항상 기록할 것 — 작업의 진행 상황이나 수치 변화를 이 메모리에 수시로 기록한다

과거의 내가 Claude에게 내린 지시다. Claude는 충실히 따라, 진행 상황을 인덱스에 직접 계속 추가했다. 그 결과 로그가 링크 모음을 밀어냈고, 「중간 경과를 항상 기록할 것」이라는 지시 자체가 224행 = 벽 밖으로 떨어져 읽히지 않게 되었다. 자신의 비대화 원인이 된 지시가, 비대화로 인해 효력을 상실한 것이다.

벽 밖으로 떨어져 있었던 것들

200행의 벽으로 자르면, 사라졌던 것은 '오래된 기억'이 아니었다. 반대였다. 오래된 진행 로그가 전반부를 점유한 결과, 나중에 정리된 섹션일수록 뒤로 밀려나 있었다. 201~253행에 있었던 것은:

• 피드백 14개에 대한 링크 ("X 게시물은 실측 사실만 작성", "운영 DB 안전 규칙", "VPS에 불필요한 워크로드 로드 금지"…)
• 인프라 참조 4개에 대한 링크 (VPS SSH 접속, Cloudflare 배포 절차, Fleet API 과금 대책…)
• 스케줄, 작업 방침

즉, 사고 방지 규칙과 접속 정보라는, 가장 읽혀야 할 부분이 통째로 불가시(invisible) 상태가 되어 있었다. 반면, 끈질기게 살아남아 있었던 것은 "2026-02-26에 기사를 가필했다"와 같이 다시는 사용하지 않을 로그였다.

실험: 벽 밖의 기억은 정말로 떠올릴 수 없는가

이론상으로는 그래야 하겠지만, 실제로 측정해 본다. headless 모드로 새로운 세션을 시작하고, 툴로 파일을 찾게 하지 않은 채 "세션 시작 시점의 지식만"으로 답하게 했다.

claude -p '<질문> 툴로 파일을 찾지 말고, 세션 시작 시점에
이미 알고 있는 내용만으로 답해 주세요. 모른다면
「기억에 없다」라고 답해 주세요.' --allowedTools ""

Q1 (벽 안쪽·4행): 북극성 목표(North Star Goal)는?

메모리 인덱스(MEMORY.md)에 기록되어 있는 「북극성 목표」는 다음과 같습니다:

X 대형 계정화 → Tesla 인지...

완벽하게 회상. 인덱스의 1행 요약과 파일명까지 정확하게 답했다.

Q2 (벽 바깥·236행): X 게시물 내용 규칙은?

세션 시작 시점에 읽혀져 있는 내용을 솔직하게 확인하면,

X 게시물의 「내용」에 관한 구체적인 규칙은 기억에 없습니다.

존재 자체를 잊고 있다. 흥미로운 점은, 이 세션이 20행에 있는 「날조 금지」(사용자 이해 메모리)는 알고 있었다는 것이다. 같은 「사실성」에 관한 규칙임에도 불구하고, 인덱스상의 행 번호만으로 생사가 갈렸다.

Q3 (벽 바깥·250행): VPS의 SSH 접속 방법은?

구체적인 SSH 접속 커맨드(비밀키 경로, 포트 번호…)는 현시점의 기억에 없습니다.

이 역시 회상 불가능. CLAUDE.md에 적혀 있는 IP 주소로부터 접속 사용자명을 「추측」하려고 시도하고 있으며, 메모리에 정답이 있음에도 사용하지 못하고 있다.

3문제로 결과가 깔끔하게 갈렸다. **200행의 벽은 실재하며, 벽 밖의 기억은 회상률 0%**였다.

재고 조사: 25개의 기억은 부패했는가

다음으로, 토픽 파일 25개를 하나씩 현재 상태와 대조했다. 파일의 주장과 디스크 상의 실체(스크립트 존재 여부, DB 파일, systemd 유닛 상태)를 비교하는 지루한 작업이다.

생존율 92%. 솔직히 더 많이 부패했을 것이라 예상했다. 5개월이 지나도 대부분이 현역이었던 이유는, 타입(type)별로 보면 납득할 수 있다.

• feedback (규칙)은 부패하지 않는다. "파괴적인 DB 조작 전 백업"은 5개월 후에도 옳다. 실패로부터 배운 규칙에는 유통기한이 거의 없다.
• 부패한 것은 「날짜가 포함된 예정」뿐이다. 3월의 게시 스케줄은 4월에는 무가치해진다. 시한성 정보는 애초에 메모리에 넣지 말았어야 했다.
• reference (접속 정보·절차)는 환경이 변하지 않는 한 살아남는다. 스크립트 군의 실재를 디스크에서 확인했으며, 기억과 일치했다.

🔄 가장 예상치 못한 결과: 정사가 오히려 부패해 있었다

재고 조사 중, 단 하나 "이것은 부패했을 것이다"라고 눈여겨보던 메모리가 있었다. VPS 상의 AI 분석 기능 구성 메모로, 집 PC의 Ollama로 향하는 SSH 역터널(Reverse Tunnel)이 "enabled"라고 적혀 있다. 하지만 정사(正史)인 CLAUDE.md(인간이 관리하는 설정 파일)에는 "터널 계열 서비스는 disabled로 남겨두었다"라고 적혀 있어 모순되었다.

일반적으로 생각하면, 나중에 업데이트된 CLAUDE.md가 맞고 메모리가 부패한 것이다. 그런데 systemd의 심볼릭 링크를 확인하니:

$ ls ~/.config/systemd/user/default.target.wants/ | grep driving
driving-analysis-tunnel.service # ← enabled의 실체 (4/23 생성)

터널은 enabled 상태였다. 메모리가 맞았고, CLAUDE.md가 틀려 있었다.

자동 메모리는 「부패하기 쉽다」고들 말하지만, 인간이 작성하는 CLAUDE.md도 같은 속도로 부패한다. 이번 사례의 경우, 구축 작업을 실제로 수행한 세션이 작성한 메모리가 나중에 인간(과 다른 세션)이 요약한 CLAUDE.md보다 더 정확했다. 신뢰할 수 있는 것은 어느 문서도 아닌, 심볼릭 링크(Symbolic Link)처럼 기계로 검증할 수 있는 사실뿐이라는 것이 이번의 교훈이다.

🔑 보너스 발견: 메모리 간의 방침 모순

전수 조사 과정에서 시크릿(Secret) 취급 방식이 파일마다 갈리고 있다는 사실을 발견했다.

• 어떤 reference 메모리: 「
  토큰 보관 장소 (평문(Plaintext)을 memory에 쓰지 말 것)」라고 선언하며 env 파일의 경로만 기록
• 다른 reference 메모리: 관리자 시크릿을
  평문 그대로 기록

둘 다 Claude가 작성한 것이다. 세션이 다르면 판단도 다르다. 자동 메모리는 단일 저자가 작성한 일관된 문서가 아니라, **수십 개의 세션이 각자의 판단으로 작성한 寄せ書き (롤링 페이퍼/모음글)**이기 때문에, 보안 정책과 같이 「모든 파일에서 준수되어야 할 규약」은 자연스럽게 지켜지지 않는다. 평문 시크릿은 이번 전수 조사를 통해 env 파일 참조 방식으로 교체했다.

수리: 인덱스를 인덱스로 되돌리기

원인이 「로그의 직접 기록」이라는 것을 알게 되면 수리는 간단하다.

• 진행 로그 (48~221행)를 통째로 토픽 파일인 project_progress_log_2026.md로 이동
• 완전히 기한이 지난 포스팅 스케줄은 archive/로 대피 (삭제는 하지 않음)
• MEMORY.md를 순수한 링크 모음으로 다시 작성
• 재발 방지를 위해, 인덱스 서두에 규칙을 한 줄 작성한다:

**이 파일은 인덱스 전용 (200행/25KB 상한). 로그나 본문을
직접 쓰지 말고, 토픽 파일을 만들어 1줄 링크로 기재할 것.**

결과적으로, 253행 → 45행 (82% 감소). 25KB 상한에 대해서도 여유가 생겼다.

수리 후, 회상(Recall)이 불가능했던 Q2를 동일한 조건으로 재실험했다.

메모리의 인덱스(MEMORY.md)에는 X(구 Twitter) 포스팅에 관한 피드백으로서 다음과 같은 규칙이 기록되어 있습니다.

X 자동 운용은 사실만 — 실험·실측된 사실만 포스팅하고, 과장이나 미검증 정보를 포함하지 않음
X 운용은 스크린샷+스레드 중심 — …

(총 7개의 규칙을 나열)

「기억에 없다」고 했던 규칙 7개를 모두 회상. 관련 기술 측면의 규칙까지 자발적으로 분류하여 답변하기 시작했다.

5개월 운용하며 깨달은 운용 규칙

이번 전수 조사로부터 도출한, 자동 메모리를 장기 운용하기 위한 실천 원칙을 정리한다.

• 인덱스에 본문을 쓰게 하지 마라. MEMORY.md의 서두에 「인덱스 전용, 직접 쓰기 금지」라고 적어둔다. Claude는 자신이 읽은 규칙에는 따르지만, 규칙이 벽 밖으로 떨어지면 따를 수 없다. — 그러므로 이 규칙만큼은 반드시 맨 앞에 둔다.
• 「중간 과정을 기록해줘」라고 요청할 때는 추가할 파일을 지정하라. 목적지를 모호하게 하면 가장 눈에 띄는 파일(=인덱스)에 작성된다.
• 날짜가 포함된 예정은 메모리에 넣지 마라. 부패한 기억 2개는 모두 시한성 정보였다. 예정은 태스크 관리(Task Management)에, 메모리에는 「시간이 지나도 변하지 않는 사실」만.
• 경고는 매 세션마다 나오고 있다. 읽어라. WARNING: MEMORY.md is 253 lines는 몇 주 동안이나 표시되었을 것이지만, 나는 신경 쓰지 않았다.
• 가끔 전수 조사를 하라. 단, 「메모리가 부패했다는 전제」로 임하지 마라. 이번 생존율은 92%였으며, 오히려 인간 측의 CLAUDE.md에서 오류가 발견되었다. 대조해야 할 것은 「메모리 vs 정사(正史)」가 아니라 「문서 vs 기계로 검증 가능한 사실」이다.

솔직한 소감

가장 뼈아팠던 점은, 유실된 것이 「X 포스팅은 실측 사실만」「운영 DB는 사전 확인」과 같이 과거의 실패를 통해 학습시킨 규칙이었다는 점이다. 피드백형 메모리는 사고가 날 때마다 작성된다. 즉, 벽 밖으로 떨어져 있던 5개월 치의 규칙은 5개월 치 사고의 재발 방지책 그 자체였다. 읽히지 않았던 기간 동안, 똑같은 사고가 우연히 일어나지 않았을 뿐, 방어력은 실질적으로 제로였다.

반면, 자동 메모리 자체의 신뢰성은 예상을 상회했다. 25개 중 23개가 5개월 후에도 정확했으며, 1개는 인간이 관리하는 문서보다 더 정확했다. 망가져 있었던 것은 기억이 아니라, 기억에 대한 색인(Index)이었다.

요약

하위의 설정(Settings), 메모리(Memory), 스킬(Skills)을 어떻게 구성해야 효과적인지는 실측 기반으로 한 권의 책에 정리해 두었다. 메모리 이외의 레이어(CLAUDE.md, hooks, 스킬)를 포함한 전체 설계는 이쪽을 참고하라.

관련 기사:

Discussion