에이전트 메모리는 복잡한 파이프라인이 아니라 파일 포맷이어야 한다

핵심 요약 (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)

  1. 파이프라인 복잡도와 취약성:
    • 많은 AI 에이전트 프레임워크가 장기 메모리를 구현할 때 pgvector, 그래프 DB, 복잡한 비동기 임베딩 파이프라인에 의존합니다.
    • 이러한 파이프라인은 인프라 종속성이 높고, 에이전트가 잘못된 컨텍스트를 참조했을 때 어디서 문제가 발생했는지 추적하기가 매우 어렵습니다.
  2. 소프트웨어 수명과 데이터 이식성:
    • 특정 에이전트 하네스나 클라우드 서비스가 폐기되면 축적된 에이전트의 메모리 데이터도 함께 증발하는 종속성(Lock-in) 문제가 발생합니다.

2. 핵심 원리 및 아키텍처 (The Memoryfield Pattern)

Cal Paterson이 제안한 메모리필드(Memoryfield) 아키텍처는 다음 3가지 원칙을 제시합니다:

  1. 파일 중심의 데이터 격리 (File as First-Class Citizen):
    • 에이전트가 생성하고 갱신하는 메모리는 순수 마크다운(Markdown) 문서 파일로 디스크에 저장됩니다.
    • 인간 사용자가 언제든지 일반 에디터(Obsidian 등)로 열어보고 직접 수정하거나 검증할 수 있습니다.
  2. 결정론적 2단계 조회 메커니즘:
    • Step 1 (Index Scan): SQLite 기반의 색인이나 카탈로그(index.md)를 통해 조회 대상을 빠르게 좁힙니다.
    • Step 2 (Direct Read): 필요한 마크다운 파일을 직접 읽어 완결된 컨텍스트를 확보합니다.
    • 불투명한 유사도 점수 기반의 청크 조각 모음 대신, 완결된 문서 단위로 읽어 환각(Hallucination)을 방지합니다.
  3. 로컬 퍼스트 및 제로 인프라 비용:
    • 별도의 벡터 데이터베이스 서버 운영 비용 없이, 로컬 파일 시스템과 표준 SQLite만으로 완벽한 에이전트 메모리를 유지할 수 있습니다.

3. 세컨드 브레인(Second Brain)과의 연계

  • 이 원리는 현재 구축 중인 Obsidian + Quartz 기반의 세컨드 브레인(LLM Wiki) 구조의 정당성을 증명합니다.
  • content/zettel/ 내의 원자적 마크다운 노트들과 agents/wiki-index.md 카탈로그는 LLM에게 가장 안전하고 결정론적인 메모리 파일 포맷 역할을 수행합니다.

References