당신의 AI Agent에는 채팅 기록이 아닌 '3계층 메모리'가 필요합니다

작년에 저는 Hermes Agent를 위한 지식 베이스(Knowledge Base) 구축을 시작했습니다. 처음 생각은 간단했습니다. 벡터 데이터베이스(Vector Database)를 설치해서 자료를 찾을 때 검색이 되면 된다는 것이었죠. 하지만 한 바퀴 돌려본 결과, Agent 시나리오에서 순수 벡터 검색(Pure Vector Retrieval)만으로는 부족하다는 것을 발견했습니다.

어떤 기억은 정확하게 묘사할 수 있고(예: "지난번에 gbrain 단일 페이지에 대해 설명한 그 기사 좀 찾아줘"), 어떤 기억은 대략적으로만 기억나며(예: "지식 그래프(Knowledge Graph)에 관한 게 있었는데..."), 어떤 기억은 심지어 무엇을 알아야 하는지조차 모를 때가 있습니다(예: "연결되지 않은 내 노트에는 어떤 것들이 있지?"). 하나의 검색 전략으로는 이 세 가지 시나리오를 모두 커버할 수 없습니다.

이것이 바로 Knowledge-and-Memory-Management (KMM) v0.0.2가 해결하고자 하는 문제입니다.

3계층은 '많이' 만들기 위함이 아니라 '상호 보완'을 위함입니다

이 프로젝트는 현재 Hermes Agent 생태계에서 실행되는 확장 레이어이며, 기반은 hermes-memory-installer가 제공하는 gbrain (지식 그래프, Knowledge Graph) + Hindsight (벡터 메모리, Vector Memory)입니다. KMM은 그 위에 수집, 노트/RAG, 클라우드 드라이브 동기화, 지식 증강(Knowledge Augmentation)이라는 네 가지 모듈 그룹을 추가했습니다.

그중 가장 엔지니어링 가치가 높은 설계는 **3계층 교차 호출(Three-layer Cross-layer Recall)**입니다:

FTS5 전체 텍스트 검색 (Full-Text Search)  →  정확한 일치, 당신이 원하는 것을 파악
Hindsight 벡터 의미론 (Vector Semantics)  →  모호한 매칭, 키워드가 부족할 때 의미에 의존
gbrain 지식 그래프 (Knowledge Graph)  →  관계 탐색, 당신은 모르지만 관련 있는 노드

lightweight_recall.py는 이 세 단계를 하나의 파이프라인(Pipeline)으로 연결합니다. 먼저 로컬 SQLite FTS5를 조회하여 일치하면 즉시 반환하고, 일치하지 않으면 Hindsight의 텍스트 임베딩(Text Embedding) 매칭을 수행하며, 그래도 만족스럽지 않으면 gbrain을 사용하여 지식 그래프의 인접 노드(Adjacent Nodes)를 확장합니다.

코드는 $AGENT_HOME/scripts/lightweight_recall.py에 있으며, 호출 방법은 복잡하지 않습니다:

# 3계층 호출 예시
from knowledge_collector.knowledge_management import KnowledgeManager

...

FTS5는 SQLite 내장 기능을 사용하여 의존성이 없으며, Hindsight는 8890 포트, gbrain은 8787 포트를 사용합니다. 각 계층은 독립적으로 다운그레이드(Degradable)가 가능합니다. 즉, 벡터 서비스가 중단되어도 전체 텍스트 검색은 그대로 작동할 수 있습니다.

실제로 일을 하는 것은 40개 이상의 도구들입니다

3계층 호출이 검색 레이어라면, 수집 레이어는 지식 베이스에 먹일 내용을 채워넣는 입구입니다. 이 프로젝트에는 유형별로 분류된 40개 이상의 수집 및 분석 도구가 포함되어 있습니다:

• 웹 수집 (9개 엔진): Scrapling을 통한 안티 디텍션(Anti-detection), Crawl4AI를 통한 스마트 라우팅을 지원하여 공식 계정(WeChat Official Accounts) 크롤링도 효율적으로 수행합니다.
• 비디오 수집 (12개 도구): yt-dlp로 스트림을 가져오고 → Whisper ASR로 전사(Transcription)한 뒤 → PaddleOCR로 핵심 프레임을 추출하여, TikTok/YouTube 등을 한 번에 잡습니다.
• 문서 분석 (9개 도구): SenseNova 3종 세트(PDF/PPT/Word)를 통해 스캔된 문서와 복잡한 레이아웃을 처리합니다.
• 도서 정제 (6개 도구): book_to_skill 파이프라인이 PDF/EPUB을 구조화된 Skill + KMM 노트로 분해합니다.

매주 일요일 새벽에는 knowledge_discovery.py가 실행되어 OneDrive의 새로운 노트를 스캔하고 gbrain에 자동으로 입력하며, 동시에 단일 페이지 링크 복구 작업을 수행합니다. 이는 "당신이 존재를 알 필요는 없지만, 시스템이 부패하지 않도록 만드는" 인프라 작업에 해당합니다.

몇 가지 엔지니어링적 선택

• 순수 벡터 우선 방식을 지양함: FTS5를 1단계로 둔 이유는 지연 시간(Latency)이 낮고(밀리초 단위), 코드나 설정을 찾을 때는 의미론적 검색보다 정확한 키워드 매칭이 훨씬 뛰어나기 때문입니다.
• gbrain의 단일 페이지 처리 필수성: 지식 그래프에 링크 유지 관리가 이루어지지 않으면, 3개월 후에는 페이지의 90%가 고립된 섬(Island)이 됩니다 (직접 테스트 결과, 10,666개의 페이지 중 1,716개의 고립 페이지를 33개로 줄였습니다).
• 검색보다 수집 우선: 좋은 수집 파이프라인이 없다면 검색이 아무리 강력해도 빈 데이터베이스를 대상으로 작동할 뿐입니다. 프로젝트에 40개 이상의 수집 도구를 쌓아둔 것은 단순히 기술을 과시하기 위함이 아닙니다.

적용 시나리오

만약 당신의 Agent가 다양한 소스(웹, 비디오, 문서, 공식 계정)로부터 지속적으로 지식을 흡수해야 하며, 그 지식이 정확한 검색, 모호한 회상, 관계 탐색이라는 세 가지 차원에서 모두 검색되어야 한다면, 3계층 모드를 시도해 볼 가치가 있습니다. 전부 배포할 필요는 없으며, FTS5 + gbrain 두 계층만 연결해도 작동하며 각 계층은 독립적으로 다운그레이드 가능합니다.

GitHub: mage0535/Knowledge-and-Memory-Management, MIT 라이선스.