사람들은 이미 Obsidian을 에이전트의 메모리로 사용하고 있습니다. 실제 구현 버전을 공개합니다.

이번 주에 올라온 글은 Obsidian과 Claude Code를 공유 메모리 스택으로 사용하는 방법을 소개하며, 실제로 저자가 운영하는 방식입니다. 단순한 사고 실험이 아닙니다. 개발자들은 이미 로컬 노트를 자신들의 에이전트가 세션 전반에 걸쳐 읽고 쓰는 레이어로 취급하고 있습니다.

cover

같은 주에 올라온 다른 두 개의 글이 이 글의 양옆에 있습니다. 한 글은 에이전트에게 메모리가 전혀 필요하지 않고, 문서화(documentation)가 필요하다고 주장합니다. 또 다른 글은 코딩 에이전트를 반복 작업에서 더 저렴하게 만드는 메모리 레이어를 선보입니다. 모두가 노트와 컨텍스트 조합 방식에는 문제가 있다고 동의하지만, 무엇으로 대체할지는 아무도 합의하지 못하고 있습니다.

Obsidian에 대한 게시글의 직관은 맞지만, 빠진 조각(missing piece)은 말하기는 쉽고 만들기는 어렵습니다. 즉, 노트 폴더 자체가 아직 메모리 시스템이 아니라는 것입니다. 노트에는 출처(source)나 타임스탬프가 없으며, 어떤 노트를 영구적인 믿음으로 간주할지 결정하는 것도 없고, 언제 더 이상 검색 대상에서 제외되어야 할지를 결정하는 것도 없습니다. Obsidian은 에디터만 제공합니다. 그 아래 레이어가 메모리처럼 작동해야 하는 부분입니다.

Windows용 에이전트의 메모리 역할을 하는 것이 HyperMarrow이며, 제가 강제하는 다섯 가지 속성이 있습니다. 이들은 실패가 가장 적게 발생하는 시점(쓰기 시간)을 기준으로 순서가 정해져 있습니다.

1. 결정 사항은 출처와 타임스탬프를 포함하여 기록되어야 합니다

선호도, 결정 또는 결론은 어디에서 왔는지, 그리고 언제였는지를 담아 실제 기록물로 영구적인 로컬 스토리지에 저장되어야 합니다. 매 턴 트랜스크립트에서 재추론된 가설에는 주소나 출처, 역사가 없습니다. 일단 기록물이 출처(provenance)를 가지게 되면,

어떤 작업 컨텍스트도 영구적인 사본이 존재하고 확인되기 전까지는 요약되거나 사라질 수 없습니다. 이것은 쓰기 선행 규칙(write-ahead rule)이며, 다섯 가지 중 가장 먼저 작동합니다. 만약 컴팩션(compaction)이 먼저 실행된다면, 그것이 버린 것은 사라지며, 그 손실에 대해 오류를 발생시키지 않습니다. 그냥 조용히 무언가를 가져갑니다.

3. 망각은 경계가 있고 예정되어 있습니다; 고정된 기록은 결코 소멸하지 않습니다

무한한 메모리는 기능이 아닙니다. 관련성이 없어진 기록들은 영원히 유지되는 것이 아니라 일정에 따라 노화되며, 사용자가 명시적으로 고정한(pin) 기록은 소멸에서 면제됩니다. 경계가 없다면 검색 공간만 커지고, 긴 기록에 대한 짧은 쿼리는 사용할수록 나아지기보다 악화됩니다.

4. Recall은 당신의 단어를 반환하며, 그 출처를 보여줍니다

무엇이 쓰였을 때 이미 손실적(lossy)이었다면, 어떤 랭커도 필요한 문장을 복구할 수 없습니다. Recall은 패러프레이즈가 아닌 저장된 기록 자체를 가져오며, 해당 히트와 함께 그 출처가 어디인지를 알려줍니다. 이것이 크로스-세션 연속성(cross-session continuity)을 실제로 만드는 것입니다: 한 세션에서 내려진 결정이 다른 세션에서도 그 출처와 함께 재발견될 수 있습니다.

5. 개인 정보 보호 경계는 약속이 아니라 설정입니다

기록들이 어디에 존재하며, 특정 기록이 기기를 벗어날 수 있는지 여부는 정책 문서의 한 단락이라기보다는 구성(configuration) 결정 문제입니다. 이것이 공유 스택(shared stack)에 있어 로컬 우선(local-first)이 중요한 이유이기도 합니다. 만약 팀 전체의 메모리가 하나의 빌드 머신에 있는 폴더라면, 접근, 보존 및 삭제는 변경 로그에서 약속된 것이 아니라 실제로 볼 수 있는 것들입니다.

Notes 대 그 아래층 레이어

• 노트(Note)는 콘텐츠입니다. 기록(Record)은 주장(Claim)입니다. 이 레이어는 결정 사항과 누가 언제 말했는지 저장하여 나중에 반박할 수 있게 합니다.
• 노트는 검색(Search)으로 검색됩니다. 기록은 회상(Recall)으로 검색됩니다. 성장하는 폴더에 대한 검색은 표류하지만, 범위와 종류를 가진 회상은 경계가 있습니다.
• 노트는 만료되지 않습니다. 기록은 만료됩니다. 노트는 정리할 때까지 쌓입니다. 기록은 계획에 따라 감쇠하고, 고정된(pinned) 기록은 그렇지 않습니다.
• 폴더는 형식(Format)이고, 레이어는 인터페이스(Interface)입니다. MCP 위에서 노출되므로 에이전트가 도구마다 맞춤형 통합을 할 필요가 없습니다.

여전히 부족한 점

• Provenance 웹사이트(hm.qianshi.cool)는 기록의 출처를 알려줄 뿐입니다. 그 출처가 신뢰할 만했는지까지는 알려주지 않습니다. 판단하는 것은 여전히 사용자에게 달려 있습니다. 소스 태그는 증거이지, 판결이 아닙니다.
• 분류(Classification)는 모델에 의존적입니다. 작성 시점에 문장이 어떤 종류의 메모인지 결정하는 모든 것은 어느 정도 확률로 오분류를 일으킬 것입니다. 데이터 손실보다 더 조용히 실패하지만, 여전히 실패합니다.
• 편집 가능한 메모는 나쁜 편집도 가능하다는 의미입니다. 잘못된 기록을 수정할 수 있게 해주는 열린 문은 그 옆에 있는 기계가 그것을 반대 방향으로 변경할 수도 있게 합니다.
• 순위 지정(Ranking)은 여전히 어렵습니다. 문자 그대로의 회상이 항상 의역보다 나은 것은 아니며, 긴 기록에 대한 짧은 질의는 여전히 예상보다 더 자주 실패합니다.

여러분에게 맡깁니다

노트 폴더가 커뮤니티를 통해 거의 완성 단계까지 도달했기 때문에 널리 퍼졌습니다. 그것이 할 수 없는 부분은 무엇을 믿음으로 간주할지 결정하고, 그 출처를 유지하며, 언제 놓아줄지 아는 것입니다. 만약 여러분의 에이전트 메모리가 폴더라면, 그 폴더가 다른 사람의 기계에 있을 때는 어떻게 될까요?

HyperMarrow는 Windows 데스크톱 메모리 레이어입니다. 로컬 우선(local-first) 빌드는 여기에서 이용할 수 있습니다: HyperMarrow

공개 고지: 제가 HyperMarrow를 만들었으므로, 이 점을 염두에 두고 위 내용을 읽어주세요. 여기에 인용된 커뮤니티 게시물은 실제적이고 공개적인 것이며, 본 포스팅을 위해 어떤 숫자, 사용자 수 또는 추천사도 만들어지지 않았습니다.