에이전트 메모리는 복잡한 파이프라인이 아니라 파일 포맷이어야 한다
핵심 요약 (TL;DR): 자율 에이전트의 장기 메모리는 특정 벡터 DB나 복잡한 RAG 파이프라인에 종속되지 않고, 인간과 LLM이 모두 읽고 수정할 수 있는 마크다운 및 SQLite 기반의 독립적인 파일 포맷(Memoryfield)으로 다루어야 이식성과 유지보수성이 극대화된다.
flowchart TD subgraph PipelineBased["복잡한 파이프라인 기반 (Anti-Pattern)"] A1["원문 데이터"] --> A2["외부 임베딩 API"] A2 --> A3["Vector DB / pgvector"] A3 --> A4["복잡한 RAG 오케스트레이션"] A4 --> A5["불투명한 검색 결과 (디버깅 난항)"] end subgraph FileFormatBased["파일 포맷 기반 (Memoryfield Pattern)"] B1["마크다운 문서<br>(인간 & LLM 가독)"] --> B2["SQLite 결정론적 색인"] B2 --> B3["단 2회의 도구 호출 조회<br>(목록 스캔 -> 본문 읽기)"] B3 --> B4["100% 재현 가능한 에이전트 메모리"] end
1. 배경 및 문제의식 (Why Pipelines Fail)
- 파이프라인 복잡도와 취약성:
- 많은 AI 에이전트 프레임워크가 장기 메모리를 구현할 때 pgvector, 그래프 DB, 복잡한 비동기 임베딩 파이프라인에 의존합니다.
- 이러한 파이프라인은 인프라 종속성이 높고, 에이전트가 잘못된 컨텍스트를 참조했을 때 어디서 문제가 발생했는지 추적하기가 매우 어렵습니다.
- 소프트웨어 수명과 데이터 이식성:
- 특정 에이전트 하네스나 클라우드 서비스가 폐기되면 축적된 에이전트의 메모리 데이터도 함께 증발하는 종속성(Lock-in) 문제가 발생합니다.
2. 핵심 원리 및 아키텍처 (The Memoryfield Pattern)
Cal Paterson이 제안한 메모리필드(Memoryfield) 아키텍처는 다음 3가지 원칙을 제시합니다:
- 파일 중심의 데이터 격리 (File as First-Class Citizen):
- 에이전트가 생성하고 갱신하는 메모리는 순수 마크다운(Markdown) 문서 파일로 디스크에 저장됩니다.
- 인간 사용자가 언제든지 일반 에디터(Obsidian 등)로 열어보고 직접 수정하거나 검증할 수 있습니다.
- 결정론적 2단계 조회 메커니즘:
- Step 1 (Index Scan): SQLite 기반의 색인이나 카탈로그(
index.md)를 통해 조회 대상을 빠르게 좁힙니다. - Step 2 (Direct Read): 필요한 마크다운 파일을 직접 읽어 완결된 컨텍스트를 확보합니다.
- 불투명한 유사도 점수 기반의 청크 조각 모음 대신, 완결된 문서 단위로 읽어 환각(Hallucination)을 방지합니다.
- Step 1 (Index Scan): SQLite 기반의 색인이나 카탈로그(
- 로컬 퍼스트 및 제로 인프라 비용:
- 별도의 벡터 데이터베이스 서버 운영 비용 없이, 로컬 파일 시스템과 표준 SQLite만으로 완벽한 에이전트 메모리를 유지할 수 있습니다.
3. 세컨드 브레인(Second Brain)과의 연계
- 이 원리는 현재 구축 중인 Obsidian + Quartz 기반의 세컨드 브레인(LLM Wiki) 구조의 정당성을 증명합니다.
content/zettel/내의 원자적 마크다운 노트들과agents/wiki-index.md카탈로그는 LLM에게 가장 안전하고 결정론적인 메모리 파일 포맷 역할을 수행합니다.
References
- Agent Memory Should Be a File Format, Not a Pipeline (Cal Paterson)
- 2026-09-03 일간 뉴스 큐레이션