AI 에이전트의 장기 기억 아키텍처를 ‘LanceDB + SQLite + Markdown SSOT’ 하이브리드 구성으로 전환해본 기록 〜Obsidian 단독 연동과의 비교〜

📅 작성일: 2026/10/16, 수정일: 2026/10/16 ⏱️ 예상 읽기 시간 약 6분 (2,598자)

AI 에이전트의 장기 기억을 Obsidian 단독 연동에서 ’LanceDB + SQLite FTS5 + Markdown SSOT’로 전면 개편. GUI 종속성, 키워드 불일치, 토큰 낭비 문제를 해결한 아키텍처 설계와 마이그레이션 실전 기록.

개요
왜 AI 에이전트에게 장기 기억(Memory Hub)이 필요한가
주요 AI 에이전트별 장기 기억 현주소와 접근법
초기 시도: Obsidian 단독 연동에서 마주한 4가지 장벽
신규 아키텍처: LanceDB + SQLite + Markdown SSOT 전체 구조
1. 주요 컴포넌트
결론

개요

자율형 AI 코딩 에이전트(Google Antigravity, Claude Code, Kiro 등)를 일상적인 페어 프로그래밍 파트너로 운용하기 시작하면 모든 엔지니어가 동일한 장벽에 직면합니다. 바로 “세션이 종료될 때마다 과거의 시행착오와 설계 판단을 완벽히 잊어버린다” 는 문제입니다.

현재 Claude Code의 MEMORY.md (Auto-memory), Kiro의 공식 Memory 기능( kiro.dev/docs/memory ), Google Antigravity의 Brain 디렉터리( .brain ) 및 /learn 명령, OpenAI Codex의 컨텍스트 유지 등 각 에이전트 진영에서 ‘장기 기억(Long-term Memory)’을 위한 기능 개발이 활발히 진행되고 있습니다. 하지만 대규모 코드베이스와 장애 대응 노하우를 토큰 낭비 없이 정확하고 안전하게 다루기에는 여전히 실질적인 과제가 남아 있습니다.

초기에는 로컬 마크다운 노트의 대표 주자인 Obsidian(Vault)과 다양한 커뮤니티 플러그인을 결합하여 에이전트에게 지식을 전달하는 방식을 시도했습니다. 그러나 자동화 루프가 고도화될수록 데스크톱 GUI 종속성, 키워드 완전 일치 검색 한계, 토큰 낭비라는 구조적 벽에 부딪혔습니다.

이를 근본적으로 해결하기 위해 AI 에이전트 장기 기억 기반(Agent Memory Hub)을 전면 쇄신하여 LanceDB(임베디드 벡터 DB) + SQLite FTS5(전문 검색 BM25) + 재귀 CTE(WikiLink 그래프 탐색) + 로컬 Cross-Encoder(ONNX INT8 리랭커) + Markdown SSOT 결합 아키텍처로 전환했습니다.

본 글에서는 주요 에이전트의 장기 기억 현주소를 짚어보고, Obsidian 단독 구성에서 겪은 한계와 Gen 3 하이브리드 아키텍처의 설계 및 실측 성능 지표를 상세히 소개합니다.

왜 AI 에이전트에게 장기 기억(Memory Hub)이 필요한가

에이전트는 기본적으로 세션 단위로 격리 되어 동작합니다. 따라서 다음과 같은 핵심 지식이 세션을 넘어 계승되지 않습니다.

아키텍처 설계 결정(ADR) : 특정 라이브러리를 채택하고 대안 패턴을 배제한 배경
장애 재발 방지책 : 특정 환경 변수나 타임아웃 설정으로 발생했던 과거의 장애와 조치 이력
특정 오류 돌파 절차 : 난해한 빌드 오류나 타입 불일치를 해결했던 구체적 방법
프로젝트 고유 규칙 : 커밋 메시지 규약, 네이밍 표준, 포트 할당 정책

이를 매번 프롬프트에 길게 입력하는 것은 토큰 낭비이자 추론 정확도 저하를 부릅니다. 필요할 때 필요한 지식만 즉시 상기할 수 있는 세션 횡단 장기 기억 허브가 필수적입니다.

주요 AI 에이전트별 장기 기억 현주소와 접근법

도구 / 에이전트	장기 기억 및 컨텍스트 유지 방식	주요 특징과 장점	실무 운영상의 한계
Claude Code (Anthropic)	CLAUDE.md + MEMORY.md (Auto-memory)	에이전트가 발견한 빌드 명령과 버그 회피책을 MEMORY.md에 자동 기록	파일이 지속 비대화되어 컨텍스트 소모. BM25 완전 일치 및 동적 그래프 탐색 불가.
Google Antigravity	Brain 영역 (.brain) + /learn + 계층형 Rules/MCP	대화별 Brain 영속화, /learn을 통한 행동 학습, MCP 다층 기억 관리	세션을 넘어 레포지토리 전반의 기술 자산(ADR/장애 지식)을 초고속 검색하는 외부 허브 필요.
Kiro	공식 Memory 기능 + 사양 주도(Spec-Driven)	프로젝트 규칙과 환경 설정, 지시 메모를 자율 기억 및 참조 (kiro.dev/docs/memory)	사양 추종에 뛰어나나, 장애 로그 완전 일치 검색(BM25)과 동적 GraphRAG, 리랭커 부재.
Cursor	.cursor/rules + Codebase Indexing	파일 패턴별 규칙 적용 및 전체 코드베이스 벡터 임베딩 검색	현행 코드 검색 중심; 과거 장애 사례나 설계 이력을 동적으로 축적하는 지식 허브는 아님.
OpenAI Codex	AGENTS.md + 샌드박스 실행 이력	샌드박스 대화 상태 유지 및 프로젝트 가이드라인 로드	세션 종료 후 트러블슈팅 이력을 동적으로 탐색하는 독립 기억 허브로서는 미성숙.

초기 시도: Obsidian 단독 연동에서 마주한 4가지 장벽

데스크톱 GUI 상주 필수 (헤드리스 불가) : Obsidian 및 주요 REST API 플러그인은 GUI 앱 실행을 전제로 합니다. CLI, CI/CD, Docker 등 헤드리스 환경에서는 운용이 불가능합니다.
시맨틱 검색 편중에 따른 완전 일치(Lexical) 취약성 : 벡터 유사도 검색은 ERR_CERT_AUTHORITY_INVALID 같은 오류 코드나 S3 , Go 같은 2글자 고유명사를 정확히 집어내지 못하고 누락시킵니다.
동적 지식 그래프 탐색(GraphRAG)의 제약 : Obsidian 그래프는 사람의 시각적 확인용이며, 에이전트가 프로그래밍 방식으로 저지연 다중 홉 탐색을 수행할 표준 API가 없습니다.
리랭커 부재로 인한 토큰 낭비 : 벡터 검색 상위 청크를 그대로 프롬프트에 주입하면 노이즈가 섞여 할루시네이션이 발생하고 컨텍스트 비용이 급증합니다.

신규 아키텍처: LanceDB + SQLite + Markdown SSOT 전체 구조

Gen 3 아키텍처는 정본(SSOT)을 Obsidian 호환 마크다운으로 유지하면서, 검색 및 탐색 엔진을 완전 헤드리스 로컬 데몬으로 분리 했습니다.

주요 컴포넌트

Markdown SSOT : Git으로 관리되는 Vault 마크다운 파일군. VS Code, Obsidian, GitHub Web과 완벽 호환.
LanceDB : 상주 서버 데몬이 필요 없는 임베디드 벡터 DB. 단자리 밀리초 단위의 고속 벡터 검색.
SQLite FTS5 : Trigram 기반 BM25 검색으로 오류 코드 및 짧은 키워드의 100% 완전 일치 보장.
재귀 CTE 그래프 탐색 : WikiLink 관계를 재귀 쿼리로 1~2홉 자동 추적 (GraphRAG, < 5ms).
RRF + ONNX INT8 Cross-Encoder : RRF로 순위를 결합하고 경량 로컬 모델로 상위 3~5개 청크만 엄선 (< 200ms).

결론

Obsidian은 사람의 사고 정리에 최고의 도구입니다. 하지만 자율 AI 코딩 에이전트가 실무에서 진가를 발휘하려면 헤드리스 구동, 하이브리드 검색, 동적 GraphRAG, 로컬 리랭킹 이 결합되어야 합니다. 사람을 위한 마크다운 정본(SSOT)과 에이전트를 위한 초고속 검색 엔진(LanceDB + SQLite)의 분리 결합이 최적의 해답입니다.