저는 수개월 동안 파일 기반의 지속적 메모리(persistent file-based memory)를 사용하여 Claude Code를 실제 업무 환경에서 매일 실행해 왔습니다. 정말 잘 작동합니다. 그러다 방금 한계에 부딪혔고, 그 한계를 보고하려던 중 그 한계보다 더 흥미로운 사실을 발견했습니다. 문서에 없는 세 가지 사항은 다음과 같습니다: 1. 항상 로드되는 메모리 인덱스(memory index)에는 하드 캡(hard cap)이 있습니다 — 약 24.4 KB / 약 200행. 2. 이를 초과하면 콘텐츠가 조용히 삭제됩니다. 유일한 경고는 시스템 프롬프트(system prompt)에 들어있는데, 다른 무언가를 디버깅하고 있지 않는 한 절대 볼 수 없습니다. 3. 절단(Truncation) 시 가장 오래된 항목은 보존하고 가장 최신의 항목을 삭제합니다. 세 번째 사항은 정말 중요하게 기억해야 할 부분입니다. 인덱스는 대략 연대순으로 구성되므로, 캡을 초과하면 지난 봄의 기록이 아니라 이번 주의 규칙과 발견 사항을 가장 먼저 잃게 됩니다. 그리고 이는 모든 사람이 조언하는 관리 방식과 정반대로 작동합니다. "오래된 것을 정리하라"는 조언은 오래된 것 = 가치가 가장 낮은 것이라고 가정합니다. 하지만 방향이 틀렸습니다: 오래된 항목들이 새로운 항목을 보호해야 할 예산을 점유하고 있는 것입니다. 저는 그 스레드를 읽기 전까지 저만의 정리 원칙을 거꾸로 적용하고 있었습니다. 오늘 측정한 제 수치와 실제 시스템 데이터입니다:

그가 알고 있는 것의 98.6%는 이미 컨텍스트(context) 밖에 있습니다. 라우팅 테이블(routing table) 하나만으로도 하드 캡의 73%를 차지하고 있으며, 압박은 한 방향으로만 가해집니다. 그 표에서 뽑아낼 만한 두 가지 사실이 있습니다. 문제가 되는 것은 행 제한이 아니라 바이트(byte) 제한입니다. 저는 93행에서 크기 제한의 73%에 도달해 있으며, 이는 허용된 약 200행의 절반도 되지 않습니다. 만약 안전을 위해 행 수를 모니터링하고 있다면, 잘못된 숫자를 보고 있는 것입니다. 그리고 오늘 아침 그 인덱스는 **81%**였습니다. 저는 수동으로 순서를 재정렬하고 일부 링크를 끊어서 약 2KB의 여유를 확보했습니다.

그것이 제가 할 수 있는 유일한 복구 방법이었습니다 — 메커니즘도, 설정도 없었으며, 그저 사람이 파일을 편집하며 어느 쪽 끝이 잘려 나가는지 알고 있어야 했습니다. 핵심적인 갈등 요소: 인덱스는 검색 (retrieval)을 올바르게 라우팅할 수 있을 만큼 충분히 완전해야 하는 동시에, 모든 세션에 로드될 수 있을 만큼 충분히 작아야 합니다. 코퍼스 (corpus)가 커짐에 따라 이 두 가지는 서로 어긋나게 됩니다. 완전성은 알려진 정보량에 따라 확장되지만, 예산 (budget)은 그렇지 않기 때문입니다. 이 교차점은 *런타임 (runtime)*의 함수이며, 이는 성공적으로 오랫동안 사용되는 모든 에이전트 메모리는 결국 이곳에 도달하게 된다는 것을 의미합니다. 이 지점에 도달하지 않는 설정들은 많은 것을 축적하지 못하고 있는 것입니다. 그 후 저는 이슈를 등록하러 갔습니다. 네 가지 기존 이슈가 있었습니다:

• #34776 — 전체 메모리 거버넌스 제안: 인덱스 병목 현상, 수정 사항 만료, 우선순위 포화, /memory-audit. 진정으로 훌륭하며, 대규모 환경을 다루는 사람이 명확하게 작성했습니다. '계획되지 않음 (not planned)'으로 종료되었습니다. '오래된 이슈 (stale)'로 라벨이 지정되었습니다.
• #57574 — 조용한 잘라내기 (truncation) 보고. '중복 (duplicate)'으로 종료되었습니다.
• #27298 — 계층형 메모리 + 시맨틱 검색 (semantic search). 오픈 상태, 미해결.
• #38452 — 200라인 제한 상향. 오픈 상태, 미해결.

결론은 이렇습니다: 알려진 문제이며, 신중하게 논증되었으나, 거절되었습니다. #34776은 현재 잠겨 있으며, 해당 봇은 영향을 받는 사람들에게 새로운 이슈를 등록하라고 권고하고 있습니다. 하지만 진짜 발견은 그 스레드(thread)에 있었습니다. 세 명의 실무자가 독립적으로 동일한 아키텍처에 도달했습니다:

• 한 명은 3개월 동안 140시간 이상의 자율 사용을 보고했으며 목록에 있는 모든 문제에 직면했습니다. 그들의 해결책은 다음과 같습니다: 인덱스를 저장소가 아닌 순수한 포인터 파일로 취급할 것; 발견 가능성을 위해 모든 메모리 파일에 프런트매터 (frontmatter)를 사용할 것; 오래된 수정 사항을 제거하기 위해 매주 검토하는 타임스탬프 기반의 지식 파일 운영; 그리고 '절대 규칙 (absolute rules, 항상 로드됨)'과 '지식 (knowledge, 주제 일치 시 로드됨)' 사이의 엄격한 분리.
• 원작자는 몇 주 후 자신이 독립적으로 구축한 거의 동일한 아키텍처를 가지고 돌아왔습니다 — 100라인 미만의 인덱스 전용 파일, 별도의 항상 로드되는 디렉토리에 있는 행동 규칙, 그리고 주기적인 감사 (audit) 기술을 갖춘 구조였습니다.

가장 강력한 발견점들은 다음과 같습니다: 만료일이 없는 수정 사항은 교리가 되고(dogma), 신뢰도 평가는 모델이 메모리를 하류에서 가중치를 부여하는 방식을 변화시키며, 그리고 압축된 세션은 품질을 저하시킵니다. 이는 메모리가 유일한 진실의 원천이 되기 때문에 모든 공백이 더 크게 느껴지기 때문입니다. - 한 팀은 어떤 메모리가 인덱싱되었는지, 고아(orphaned) 상태인지, 또는 인덱싱되지 않았는지를 볼 수 있는 UI가 있는 메모리 관리자 플러그인을 만들었습니다. 디렉토리를 검색하는 방식으로는 감사(auditing)를 확장할 수 없기 때문입니다. 이러한 수렴이 실제 신호입니다. 세 사람이 각기 다른 방식으로 제가 도달한 동일한 분할 지점에 이르렀습니다: 어떤 메모리는 상주해야 하고 어떤 것은 가져올 수 있으며, 시스템은 이 둘을 구별하지 못합니다. 아무도 이를 해결하는 툴링을 가지고 있지 않습니다. 그들은 모두 같은 임시방편을 만들었을 뿐입니다. 제가 생각하기에 아무도 언급하지 않은 두 가지가 있고, 이것이 제가 단순히 제 설정을 수정하는 대신 게시물을 올리는 이유입니다: 1. 사실(Facts)은 깔끔하게 계층화되지만, 선험적 지식(Priors)은 그렇지 않습니다. 사실은 손실 없이 온디맨드(on-demand)로 검색됩니다. 에이전트는 자신이 그 값을 필요로 한다는 것을 알고 가서 가져옵니다. 선험적 지식은 다릅니다.

조용한 *가지치기 (pruning)*가 일반적인 사례이며, 캡(cap)을 높이는 것은 이 문제에 영향을 주지 않습니다. 제가 실제로 효과를 본 방법은 (모두 메커니즘이 아닌 절제력의 결과입니다): 온디맨드(on-demand)로 로드되는 2단계 인덱스 · 검색 가능한 상태로 유지되는 아카이브 디렉토리 · 항목들이 포인터(pointer)로 유지되도록 하는 엄격한 라인 예산(line-budget) · 예정된 심층 가지치기(deep prunes) · 그리고 오늘 기준으로, 최근의 핵심 자료가 절단(truncation)이 닿지 않는 상단에 위치하도록 인덱스의 순서를 정렬하는 것입니다. 마지막 방법은 비용이 들지 않으며 문서화된 동작 방식과 함께 작동합니다. 가능한 규모를 보여드리자면: #57574 보고자는 동일한 계층화 방식의 더 엄격한 버전을 사용하여 34.3 KB → 3.5 KB로 90%를 감소시켰습니다. 따라서 상위 단계에서 무언가 변경되기 전에, 실무자적 접근 방식만으로도 충분한 여유 공간(headroom)이 있습니다. 제가 질문하는 것:

• 2~3년 동안 대규모 메모리를 운영해 온 분들 중, 500개의 메모리나 1,000개의 메모리 상태에서도 실제로 유지되는 것은 무엇인가요?
• 가지치기 오류에 대한 피드백 신호를 구축한 분이 계신가요? 삭제된 메모리가 중요했을 것임을 감지할 방법이 있을까요?
• 매니페스트(manifest)를 유지하는 대신 세션 시작 시 저장소에 대해 시맨틱 검색 (semantic retrieval)을 수행하는 분이 계신가요? 관련성 매칭(relevance-matching)이 선험적 지식(priors)을 포착하나요, 아니면 당신이 요청해야 할지조차 몰랐던 바로 그 요소들을 놓치게 되나요?
• 제가 찾지 못하고 있는 사실(fact)과 선험적 지식(prior)의 구분법에 대한 선행 기술(prior art)이 있나요?

누구에게든 도움이 된다면 모든 측정값이 포함된 전체 보고서를 공유하겠습니다. 운영 수치를 추가하고 싶은 분이 있다면, 여기 좁혀진 기능 요청(feature request)으로 제출되었습니다: https://github.com/anthropics/claude-code/issues/81710 /u/bobnolley 제출 [link] [comments]