AI 에이전트를 구축하려는 급박한 흐름 속에서, 우리는 복잡한 벡터 데이터베이스(Vector Database)를 기본값으로 선택해 왔습니다. 하지만 트래픽이 높은 플랫폼들은 더 단순하고 견고한 기반, 즉 일반 파일(Plain files)로 수렴하고 있습니다.

대부분의 장기 에이전트 메모리(Long-term agent memory) 설정은 과도하게 설계(Over-engineered)되어 있습니다.

개발자들이 LLM 애플리케이션을 구축하기 시작할 때, 거의 항상 주어지는 처방은 다음과 같습니다: "관리형 벡터 데이터베이스(Managed vector database)를 실행하고 RAG 파이프라인을 구축하세요."

하지만 트래픽이 가장 높은 프로덕션 에이전트 플랫폼(Claude Code, Manus, OpenClaw 등)을 살펴보면, 조용한 트렌드가 나타나고 있습니다. 이들은 엔터프라이즈 임베딩 저장소(Enterprise embeddings store)를 우회하여 일반 마크다운(Markdown) 파일을 주요 메모리 기질(Memory substrate)로 사용하고 있습니다.

이것은 단순함으로의 퇴보가 아닙니다. 제대로 수행된다면, 파일은 검사 가능하고(Inspectable), 차이 비교가 가능하며(Diffable), 휴대 가능하고(Portable), Git 친화적(Git-native)이기 때문에 더 강력한 엔지니어링 기반이 됩니다.

하지만 구조가 없는 일반 텍스트 노트 폴더는 그저 느리고 인덱싱이 제대로 되지 않는 데이터베이스일 뿐입니다. 파일 우선 아키텍처(File-first architecture)를 대규모로 작동시키려면, 근본적인 시스템 디자인 원칙을 따라야 합니다: 저장(Storage)과 검색(Search)을 분리하는 것입니다.

핵심 불변량: 저장(Storage) vs 검색(Search)

에이전트 메모리 설계에서 내릴 수 있는 가장 영향력 있는 단일 결정은 저장 계층(Storage layer)과 검색 인덱스(Search indexes)를 완전히 별개의 시스템으로 취급하는 것입니다.

• 저장 (Canonical Source of Truth, 정전/신뢰할 수 있는 단일 원천): 버전 관리되는, 사람이 읽을 수 있는 파일 (Markdown + YAML frontmatter).
• 검색 (Derived Index, 파생된 인덱스): 파생된 검색 구조 (벡터 데이터베이스(Vector databases), 전문 검색 BM25 인덱스(Full-text BM25 indexes), 엔티티 그래프(Entity graphs), 키워드 인덱스(Keyword indexes)).

이 아키텍처에서 모든 검색 인덱스는 일회성 산출물(Disposable artifact)로 취급됩니다. 언제든지 벡터 임베딩 데이터베이스를 삭제하거나 엔티티 그래프를 재구축할 수 있으며, 이때 기반이 되는 메모리의 손실은 전혀 없습니다.

이를 통해 세 가지 이점을 얻을 수 있습니다:

1. 무료로 얻는 감사 가능성 (Auditability for free): 메모리를 텍스트 파일로 저장함으로써 Git을 사용하여 버전 관리를 할 수 있습니다. 모든 메모리 업데이트, 대체(supersession), 또는 수정 사항은 별도의 커스텀 데이터베이스 버전 관리 로직 없이도 차이점 비교(diffable)가 가능하며, 출처 추적이 가능하고, 되돌릴 수 있습니다.
2. 알고리즘의 자유 (Algorithmic freedom): 임베딩 모델(embedding models)을 교체하거나, 청킹 전략(chunking strategies)을 조정하거나, 랭킹 알고리즘(ranking algorithms)을 동적으로 변경할 수 있습니다. 그저 마크다운(markdown) 파일로부터 인덱스(index)를 다시 구축하기만 하면 됩니다. 핵심 데이터는 결코 특정 기술에 종속(lock-in)되지 않습니다.
3. 이식성 (Portability): 메모리 저장소는 특정 벤더의 데이터베이스 형식으로부터 완전히 분리(decoupled)되어 있습니다. 런타임(runtime)을 마이그레이션하는 것은 데이터베이스 마이그레이션 프로젝트가 아니라, 단순한 파일 복사(cp) 작업입니다.

쓰기 경로 지능 (Write-Path Intelligence): 메모리 구조화

검색(Retrieval) 품질은 쓰기(write) 품질의 하류(downstream)에 있습니다. 깨끗하고 구조화된 메모리에 대해 단순한 검색을 수행하는 시스템은, 노이즈가 많은 메모리에 대해 복잡한 RAG 파이프라인을 사용하는 시스템보다 일관되게 더 나은 성능을 보입니다.

이를 달성하기 위해, 모든 메모리 단위는 쓰기 시점에 구조화되어야 합니다. 파일 우선(file-first) 런타임에서의 전형적인 메모리 파일은 다음과 같은 형태를 가집니다:

---
id: mem_7c10e3
created: 2026-07-02T16:40:00Z
...

구조화된 프론트매터(frontmatter) 스키마를 강제함으로써 다음과 같은 이점을 얻습니다:

• 원자성 (Atomicity): 하나의 메모리 파일은 정확히 하나의 사실 또는 선호도를 인코딩합니다. 이는 중복 제거 및 충돌 해결을 정밀하게 만듭니다.
• 메타데이터 추적 (Metadata Tracking): 읽기 과정에서 원문 텍스트로부터 추론하려고 시도하는 대신, 출처, 타임스탬프(timestamp), 신뢰도(confidence), 엔티티(entities)를 즉시 기록합니다.
• 감사 추적 (Audit Trail): supersedes 키에 주목하십시오. 사용자의 선호도가 변경되면, 기존 파일을 직접 수정하지 않습니다. 대신 새 파일을 작성하고 이를 이전 파일과 연결합니다. 이전 파일은 활성 검색 인덱스에서는 제외되지만 Git 히스토리에는 남아 있어, 감사 추적을 완전히 온전하게 유지합니다.

검색 인덱스를 일회용으로 만들기 (Making the Search Index Disposable)

저장소는 디스크에 안전하게 보관되므로, 검색 계층(retrieval layer)을 공격적으로 튜닝할 수 있습니다. (정확한 키워드 매칭과 시간 관련 쿼리에 어려움을 겪는) 원시 벡터 유사성(raw vector similarity)에만 의존하는 대신, 일회용 하이브리드 인덱스(disposable hybrid index)를 구축할 수 있습니다.

강력한 읽기 경로(read-path)는 **다중 신호 융합 (Multi-Signal Fusion)**을 사용합니다:

1. 시맨틱 검색 (Semantic Search): 텍스트 본문을 매핑하는 벡터 인덱스 (vector index).
2. 키워드 검색 (Keyword Search): 정확한 토큰을 매칭하는 BM25 인덱스.
3. 엔티티 매칭 (Entity Match): entities 배열을 매핑하는 경량 인덱스.

**상호 순위 융합 (Reciprocal Rank Fusion, RRF)**을 사용하여, 이 세 가지 신호를 하나의 통합된 순위 목록으로 결합합니다:

RRF_Score(d) = 각 검색 방법에서 문서 d의 순위(rank)에 대해 1 / (k + rank)를 모두 더한 값.

여기서 rank는 특정 검색 방법에서의 문서 d의 위치이며, k는 상수(보통 60)입니다. 이는 코사인 유사도 (cosine similarity) 점수를 BM25 점수와 직접 평균 내는 방식에서 발생하는 척도 불일치 (scale-incompatibility) 문제를 방지합니다.

실제 환경에서의 트레이드오프 (Tradeoffs)

정직한 아키텍처는 자신의 한계를 다루어야 합니다. 파일 우선 메모리 (file-first memory) 방식의 두 가지 주요 과제는 다음과 같습니다:

1. 동시성 (Concurrency)

파일은 단일 작성자에게는 훌륭한 진실의 원천 (source of truth)입니다. 하지만 여러 에이전트나 병렬 프로세스가 동시에 쓰려고 시도할 때는 부담이 됩니다.

• 해결책: 단일 사용자 환경의 경우, 간단한 권고적 파일 잠금 (advisory file locking)만으로 충분합니다. 다중 에이전트 분산 시스템의 경우, 파일 쓰기 앞에 얇은 트랜잭션 게이트키퍼 (SQLite와 같은)를 배치하여 동시성을 중재하고, 파일 자체는 정전적 백업 (canonical backup)으로 유지합니다.

2. 메모리 오염 (Memory Poisoning, MINJA)

만약 에이전트가 신뢰할 수 없는 외부 소스(웹 페이지, 제3자 이메일 등)를 읽을 수 있다면, 공격자는

이것이 바로 우리가 tekmemo를 통해 해결하고자 하는 문제입니다. 우리는 쓰기 경로 지능 (write-path intelligence), 다중 신호 융합 (multi-signal fusion), 그리고 별도의 설정 없이 즉시 사용 가능한 git-native 감사 (automatic git-native auditing) 기능을 처리하는, AI 에이전트를 위한 프로덕션 준비 완료된 (production-ready) 파일 우선 방식의 장기 메모리 런타임 (long-term memory runtime)을 구축하고 있습니다.

곧 출시될 예정입니다. 복잡한 외부 벡터 데이터베이스 (vector databases)를 구축하지 않고도 내구성이 있고, 감사 가능하며, 회복 탄력성이 있는 에이전트 메모리를 구축하고 싶다면 곧 있을 저희의 출시를 기대해 주세요.