주요 에이전트 메모리 도구 3종을 리버스 엔지니어링해 봤습니다. 그리고 Obsidian 대신 마크다운 파일과 LLM 위키로 돌아갔죠.
I reverse-engineered the three biggest agent-memory tools. Then I went back to markdown files and LLM wikis over Obsidian.
핵심 요약
복잡한 지식 그래프 기반 메모리 도구 대신 마크다운과 단순한 텍스트 검색을 활용하는 것이 개인용으로는 훨씬 효율적이라는 의견입니다.
- 메모리 도구 분석 — Cognee, Graphiti, Neo4j의 복잡한 지식 그래프 구조를 리버스 엔지니어링함
- 개인용 도구의 한계 — 개인 규모에서 지식 그래프는 과도한 인프라와 데이터 종속 문제를 야기함
- 마크다운의 효율성 — Obsidian과 LLM 위키를 활용한 단순한 파일 기반 메모리가 더 실용적임
- 데이터 보존의 중요성 — 추출된 요약본보다 원본 에이전트 세션 기록을 보존하는 것이 장기적으로 더 가치 있음
Cognee, Graphiti, Neo4j의 agent-memory가 에이전트 메모리 아키텍처를 어떻게 구축하는지 몇 주 동안 읽어봤습니다. 그들은 모두 동일한 무거운 지식 그래프 설계로 수렴하더군요: 온톨로지, LLM 추출 파이프라인, 중복 제거 등등 말이죠.
제 개인적인 용도로 사용하고 싶었지만, 너무 무거운 설정이라 마찰이 많고 데이터가 고립될 것 같았습니다. 게다가 별다른 가치도 없는데 데이터만 그들의 서비스에 갇히는 느낌이었죠.
그래서 제 "장기 기억"은 여전히 Obsidian, Readwise, Google Drive에 남아 있고, 에이전트의 메모리로는 프로젝트별 LLM 위키를 사용합니다. 인프라가 전혀 없죠. 그리고 전 이게 좋습니다.
그들은 메모리를 제품으로 출시하는데, 제 생각에 개인이나 소규모 단위에서는 과잉입니다. LLM 위키 메모리 내의 평범한 .md 파일들로도 똑같은 "지식 그래프" 경험을 만들 수 있습니다.
하지만 그래프는 강력하기 때문에, Cognee, Graphiti, Neo4j agent-memory 스택의 아키텍처를 차용해서 MongoDB, VoyageAI, Gemini Flash만으로 데이터 마이닝 도구를 만들었습니다. 다만 지식 그래프의 노이즈를 피하기 위해 아주 특정한 문제와 온톨로지 도메인으로 범위를 제한했죠.
반대로 중대형 규모의 제품을 출시하고 싶다면 Neo4j, Zep, HydraDB 같은 괴물들을 사용하는 게 합리적입니다.
궁금한 점이 있습니다: 여러분의 장기 기억 설정은 어떤가요? Obsidian + LLM 위키인가요, 아니면 Cognee/Graphiti/Zep인가요? 실제로 Cognee나 Zep 같은 도구를 사용하시나요?
