AI 에이전트에게 기억을 장착하기: Knowledge-and-Memory-Management v0.0.2 실전

AI 에이전트에게 기억을 장착하기: Knowledge-and-Memory-Management v0.0.2 실전

매번 새로운 세션은 백지상태에서 시작됩니다. 이는 AI 에이전트(AI Agent)를 사용하는 모든 사람이 겪는 문제입니다. 어제의 조사 결론, 지난주에 작성한 분석, 지난달에 겪었던 시행착오 등을 새로운 세션에서는 모두 다시 시작해야 합니다. 시중에 나온 많은 솔루션은 특정 에이전트에 종속되어 있어, 에이전트를 바꾸면 설정을 다시 해야 합니다.

Knowledge-and-Memory-Management v0.0.2(이하 KMM)는 다른 길을 택했습니다. 에이전트의 핵심 코드를 건드리지 않는 외장형 기억 계층(External Memory Layer) 방식입니다. KMM은 지식 수집, 구조화된 축적, 세션 간 호출(Cross-session Retrieval)이라는 세 가지 핵심 능력을 중심으로 전개됩니다.

4가지 수집 엔진

KMM의 knowledge_collector 모듈은 네 가지 수집 파이프라인을 제공하여 다양한 소스로부터 원시 지식을 가져옵니다:

• WebCollector: 6가지 수집 엔진을 통해 경량 HTTP 추출부터 안티 디텍션(Anti-detection) 브라우저(Scrapling + Cloudflare Turnstile 우회)까지 지원하며, 5단계 보호 전략을 커버합니다.
• VideoCollector: 8가지 엔진/도구를 지원하며, 틱톡(Douyin)/YouTube/웨이보(Weibo) 등 다중 플랫폼을 지원합니다. Whisper ASR 음성 전사 + 화면 OCR을 활용합니다.
• ArticleCollector: 소셜 미디어, RSS, 긴 글의 콘텐츠 추출을 담당합니다.
• DocumentCollector: PDF 및 이미지 OCR 스캔을 담당합니다.

각 수집기의 출력은 통일된 CollectionResult 구조를 거쳐 하위의 노트 생성 파이프라인으로 전달됩니다.

수집 → 노트 → 그래프 → 동기화

이것이 KMM의 가장 흥미로운 부분입니다. 원시 재료를 검색 가능한 지식 자산으로 변환하며, 이 과정에서 특정 에이전트에 의존하지 않습니다:

원시 재료 수집 → LLM 구조화 추출 → Markdown 노트 작성 → gbrain 지식 그래프(Knowledge Graph) 입고 → 클라우드 드라이브 동기화

핵심은 두 번째 단계에 있습니다. LLM이 원시 재료에서 핵심 논점, 주요 데이터, 타임라인 및 관련 읽을거리를 추출하여, 구조화된 YAML frontmatter + Markdown 본문으로 구성된 노트 파일을 생성하고 $AGENT_HOME/knowledge/notes/에 저장합니다. 그 후 자동으로 gbrain 지식 그래프 노드를 생성하여 하이퍼링크, 태그, 타임라인을 구축하며, 마지막으로 rclone을 통해 클라우드 드라이브로 푸시합니다.

RAG 검색: 4가지 경로의 병렬 융합

from notes_rag import NotesRAGManager

manager = NotesRAGManager()
...

NotesRAGManager의 search 메서드는 ThreadPoolExecutor를 통해 네 가지 쿼리를 병렬로 실행합니다. 즉, 로컬 Markdown 전체 텍스트 검색, Hermes state.db FTS5, Hindsight Warm Layer(온층) 시맨틱 검색, gbrain 지식 그래프를 호출한 뒤, RRF(Reciprocal Rank Fusion) 알고리즘을 사용하여 결과를 병합하고 정렬합니다. 네 가지 소스가 서로를 보완하므로, 단일 소스를 사용할 수 없을 때 자동으로 다운그레이드되어 작동합니다.

적용 시나리오

이 솔루션은 누구에게 적합할까요? 만약 당신이 여러 AI 에이전트(Hermes + Codex + Claude Code)를 동시에 관리하거나, 세션 간에 지식 축적물을 자주 재사용해야 한다면, 특정 에이전트에 종속된 기억 시스템보다 KMM의 외장형 설계가 훨씬 유연합니다. 설치 시 $AGENT_HOME 환경 변수를 통해 대상을 전환할 수 있어, 하나의 스크립트로 여러 에이전트를 관리할 수 있습니다.

단점은 외부 의존성이 도입된다는 점입니다. PostgreSQL 16, Hindsight, gbrain이라는 세 가지 하위 컴포넌트가 필요하며, 배포 복잡도가 로컬 파일 방식보다 한 단계 높습니다. 하지만 그 대가로 3계층 호출(Hot → Warm → Cold)과 RRF 융합을 통한 높은 검색 품질을 얻을 수 있습니다.

운영 환경에서는 cron을 설정하여 memory_maintenance_cycle.py를 정기적으로 실행함으로써 아카이브, 인덱스 재구축, 컨텍스트 주입을 무인 파이프라인으로 만드는 것을 권장합니다. 최초 배포 후 검증 단계에서는 sidecar_acceptance_check.py를 실행하여 한 번에 통과 여부를 확인할 수 있습니다.