저는 제 터미널을 Anthropic의 새로운 프런티어 모델(frontier model)인 Fable 5로 전환하고, 직설적인 질문을 던졌습니다: 당신은 Claude Code의 내장형 자동 메모리(auto-memory)에서 구동되었고, 지금은 나의 메모리 기질(memory substrate) 위에서 구동되고 있습니다. 실제로 차이를 느낄 수 있습니까?

그것은 '예'라고 답했고, 동일한 세션 내에서 20분 전의 증거를 제시했습니다.

저는 그것에게 일상적인 질문을 했습니다: 나의 다음 예정된 블로그 포스트는 무엇인가요? 저의 콘텐츠 캘린더는 메모리 그래프(memory graph)에 저장되어 있는데, 그 그래프에는 두 가지 버전이 있었습니다. 원래 순서가 담긴 오래된 셀(cell)과, 이를 재배열한 새로운 셀이 '모순됨(contradicts)' 엣지(edge)로 연결되어 있었습니다. 모델이 턴(turn)을 시작할 때 읽는 컴파일 패킷(compile packet)에는 충돌(conflicts) 섹션이 포함되어 있으며, 그 섹션은 모델이 오래된 순서를 인용하기도 전에 해당 순서가 도전받았음을 표시했습니다. 모델의 자체 요약은 다음과 같았습니다: 자동 메모리(auto-memory)를 사용할 경우, 오래된 캘린더는 대체되었다는 표시 없이 단순 텍스트로 돌아오기 때문에, 저는 당신에게 잘못된 포스트를 자신 있게 알려주었을 것입니다.

그것이 한 문장으로 요약된 차이점입니다. 한 시스템은 모델에게 신념 상태(epistemic state)가 부착된 사실을 전달합니다: 신뢰도, 도전받음, 오래됨, 작성자 및 작성 시점 등입니다. 다른 시스템은 모델이 액면 그대로 받아들여야 하는 텍스트를 전달합니다.

먼저 자기 보고(self-report)를 배제하십시오

어떤 것에 대한 모델의 의견을 인용하기 전에, 혼란 변수(confound)를 명시해야 합니다: 모델은 질문하는 사람의 프레임(framing)에 동조하는 경향이 있으며, 제가 질문하고 있는 대상은 바로 제가 만든 것입니다. 따라서 이 인터뷰는 증거가 아닌 참고 자료(color)로 취급하십시오.

증거는 점수 산정 루프에 LLM이 포함되지 않은 스토어 수준의 배터리 테스트입니다. 두 개의 스토어를 대상으로 일곱 가지 결정론적 시나리오(deterministic scenarios)를 실행했습니다: Claude Code의 자동 메모리를 충실히 구현한 플랫 파일(flat-file) 모델(실제 MEMORY.md 인덱스 및 메타데이터 프런트매터(metadata frontmatter)가 포함된 사실별 .md 파일, 수정 시 제자리 덮어쓰기 방식)과 격리된 데이터베이스 상의 실제 Recall CLI입니다.

감사 점수(Audited score): Recall 6.5/7, auto-memory 3.5/7. 이 감사(audit) 과정은 제가 가장 신뢰하는 부분입니다. 첫 번째 실행에서는 7 대 2.5의 점수를 기록했습니다. 그 후 세 명의 독립적인 에이전트(agent)가 적대적 방식(adversarially)으로 하네스(harness)를 검토하였고, Recall에 약간 편향되어 있다고 판단했으며, 실제 오탐(false positive)을 하나 발견했습니다. 따라서 제가 유지하고 있는 수치는 수정된 실행 결과입니다. 감사 후에 점수가 덜 좋게 나온 벤치마크가, 감사를 한 번도 거치지 않은 벤치마크보다 더 가치가 있습니다.

그리고 분리된 결과에 대한 솔직한 해석은 다음과 같습니다: 기초적인 부분에서는 auto-memory가 동점입니다. 별도의 에이전트 수준 A/B 테스트에서, 두 저장소 모두 단순한 현재 값 질문에 대해 3전 3승을 기록했습니다. 평이한 산문(flat prose)은 단순한 대체(supersession)를 잘 시뮬레이션할 수 있습니다. 격차는 규모가 커지고 수정이 발생할 때 벌어집니다. 현재 제 그래프(graph)는 약 1,180개의 셀(cell)과 86개의 추적된 모순(contradiction)을 보유하고 있습니다. 이 정도 규모의 플랫 파일(flat file)은 문장들의 더미일 뿐이며, 그 안의 어떤 문장도 "화요일 이후 무엇이 바뀌었는가" 또는 "이 믿음들 중 어떤 것이 논쟁 중인가"라는 질문에 답할 수 없습니다. 왜냐로써 이러한 질문들은 파일 내부의 특정 사실에 대한 것이 아니라, 시간에 따른 저장소의 상태(state)에 관한 질문이기 때문입니다.

작업을 수행하는 네 가지 메커니즘

덮어쓰기 대신 대체 (Supersession instead of overwrite). 사실이 수정될 때, auto-memory는 기존 파일을 제자리에서 덮어씁니다. 이 경우 이력은 사라지며, 수정된 사실은 한 번도 틀린 적이 없는 사실과 구별할 수 없게 됩니다. 그래프에서는 새로운 셀이 기존 셀로 향하는 모순(contradicts) 에지를 가집니다. 기존 셀의 유효 신뢰도(effective confidence)는 떨어지며, 대체된 상태로 계속 표시됩니다. 수정 사항은 삭제가 아닌 해결(resolution)로 기록됩니다.

시작 시 로드 대신 프롬프트별 푸시 (Per-prompt push instead of load-at-start). 훅(hook)이 관련 셀의 작은 인덱스를 컴파일하여, ID와 신선도 플래그(staleness flags)를 포함해 모든 프롬프트에 넣습니다. 모델은 찾아봐야 한다는 것을 기억할 필요가 없습니다. 그래프의 현재 상태가 매 턴마다 컨텍스트(context)로 다시 들어오기 때문입니다. 반면 auto-memory는 세션 시작 시 한 번 로드된 후 그대로 표류(drifts)합니다.

전체 파일 로드 대신 ID 우선 읽기 (Ids-first reads instead of whole-file loads). 컴파일된 패킷은 핸들(handles)을 반환합니다. 모델은 전체 저장소를 집어삼킨 뒤 관련 단락이 살아남기를 바라는 대신, 자신에게 필요한 두 개의 셀을 확장(expand)하여 사용합니다.

저장소 자체에 대한 질문들. 지난 하루 동안 무엇이 변했는가. 무엇이 오래되었는가(stale). 무엇이 충돌(contested)하는가. 이 질문들은 타임스탬프(timestamps)와 엣지(edges)를 읽는 diff 및 health 도구들에 의해 답변됩니다. 플랫 파일(flat-file) 방식의 대응물은 존재하지 않는데, 이는 아무도 만들지 않아서가 아니라 파일 자체에 해당 정보가 포함되어 있지 않기 때문입니다.

장기적인 관점에서의 답변

그다음 제가 실제로 궁금했던 후속 질문입니다: 장기 실행 작업(long-running task)을 수행할 때, 당신의 하단에 어떤 메모리가 있는 것을 더 선호합니까?

그 답변을 압축하자면 다음과 같습니다: 긴 세션(session)을 망치는 것은 컨텍스트 압축(context compaction)입니다. 컨텍스트 윈도우(window)가 요약되면서, 그 요약본은 손실이 발생하는 산문(lossy prose)이 되며, 그 과정에서 무엇이 누락되거나 수정되었는지 표시해 주는 장치가 아무것도 없습니다. 세션 시작 시 로드되는 메모리는 작업 중간에는 도움이 되지 않습니다. 프롬프트당 푸시(per-prompt push) 방식은 매 압축 이후에 요약에서 살아남은 내용이 아니라 그래프(graph)로부터 모델을 다시 닻 내리게(re-anchors) 합니다. 그리고 긴 작업은 수정 사항을 축적합니다: 1시간째에 믿었던 무언가가 3시간째에 거짓으로 판명될 수 있으며, 긴 자율 실행(autonomous runs)이 실패하는 구체적인 방식은 에이전트가 아무도 오래되었다고 알려주지 않은 믿음으로부터 자신 있게 작업을 재개할 때 발생합니다.

모델은 묻지도 않았는데 그 비용을 인정했는데, 이 점이 마음에 들었습니다. 쓰기 규율(write discipline)은 매 턴마다 토큰을 소모하며, 10분짜리 작업에서는 그 비용을 회수하지 못할 수도 있습니다. 하지만 긴 실행에서는 비용이 분할 상환(amortizes)되며, 쓰기 작업은 에이전트가 무엇을 왜 했는지에 대한 감사 추적(audit trail) 역할도 겸하게 됩니다.

만약 이 과정을 재현하고 싶다면 운영상의 각주를 하나 남기겠습니다: Claude Code의 네이티브 자동 메모리(auto-memory)는 기능이 켜져 있는 동안 외부 저장소를 그림자처럼 따라갑니다(shadows). 저희는 생각할 수 있는 모든 방법으로 에이전트에게 무장(arming)을 시도하며 테스트했습니다; 하지만 에이전트는 상관없이 계속해서 플랫 .md 파일들을 써 내려갔습니다. CLAUDE_CODE_DISABLE_AUTO_MEMORY=1이 스위치입니다. 이 두 방식은 공존할 수 없습니다.

다시, 두 가지 질문

인터뷰 형식을 걷어내면 제가 계속해서 되풀이하게 되는 두 가지 질문이 남습니다. 당신의 에이전트는 실제로 당신의 메모리를 사용하고 있습니까, 아니면 옆에 놓인 그림자 저장소(shadow store)를 사용하고 있습니까? 그리고 만약 그 메모리 속의 사실이 틀렸다면, 시스템 내의 그 어떤 것이 이를 알 수 있습니까?

프런티어 모델 (frontier model)의 자기 보고 (self-report)는 하나의 데이터 포인트일 뿐, 판결이 아닙니다. 그리고 이것은 제가 직접 구축한 부분도 절반이나 되는 하나의 스택 (stack)에서 가져온 현장 보고서입니다. 이 두 가지 질문을 여러분의 설정 (setup)에 적용해 보고, 제가 틀린 부분이 있다면 알려주세요: github.com/H-XX-D/recall-memory-substrate