벡터 검색 실패를 해결하기 위해 6개월간 에이전트 메모리 시스템을 구축했습니다 — 그 과정에서 배운 것(그리고 만든 것)

다들 안녕,

에이전트 워크플로우 만드는 개발자라면 다들 공감하겠지만, 나도 몇 달 동안 기존 벡터 스토어나 RAG 메모리 레이어 쓰면서 장기 기억 처리 제대로 안 돼서 진짜 골머리 썩었거든.

파고들수록 확실해진 건, 단순 유사도 검색이 곧 유용성으로 이어지지는 않는다는 거야. 예를 들어, 사용자가 매트리스 브랜드에 대해 물어보면 일반적인 리트리버는 그냥 예전 매트리스 관련 대화만 긁어오지. 정작 3개월 전에 했던 중요한 제약 사항인 "비싼 거 살 땐 무조건 보증 기간이 제일 중요해" 같은 건 싹 다 놓쳐버린다고.

게다가 메모리 쌓일수록 무거운 크로스 인코더 리랭커(cross-encoder rerankers)는 지연 시간 잡아먹는 주범이 되고, 모든 컨텍스트를 그냥 텍스트 덩어리로만 취급하니까 시간이 지나면서 바뀌는 의사결정의 미묘한 차이도 다 뭉개지더라고.

그래서 내가 직접 만든 게 MindCache야. 핵심 아이디어 4가지를 바탕으로 만든 오픈소스 에이전트 메모리 프레임워크지.

• 데이터 입력 단계에서 지능형 처리: 실시간 쿼리 때 복잡한 그래프 탐색 돌리느라 시간 낭비하지 마. MindCache는 관계 매핑, 그래프 클러스터링, 요약 생성 같은 무거운 작업들을 데이터 입력 단계에서 미리 처리해버려. 덕분에 리트리벌 지연 시간을 ~25초에서 1.08초로 (23배 속도 향상) 줄였는데, 컨텍스트 품질은 그대로 유지했어.
• 메모리 유형별 특화: 모든 기억이 똑같을 순 없잖아. MindCache는 메모리를 User(지속적인 행동 제약), Knowledge(도메인 지식), Episodic(시간순 로그), Decision Memories(시간에 따른 제안, 트레이드오프, 최종 결론 추적)로 딱딱 나눠서 관리해.
• 살아있는 지식 계층 구조: 관리도 안 되는 정적인 그래프 붙잡고 있지 마. MindCache는 Leiden community detection을 써서 메모리를 의미 단위의 로컬 클러스터로 쪼개. 덕분에 컨텍스트가 쌓여도 그래프 유지보수가 아주 효율적이지.
• 유사도 검색 대신 증거 조합: 그냥 비슷한 텍스트 찾는 게 끝이 아니야. LLM이 제대로 추론할 수 있게 필요한 최소한의 증거(사용자 선호도, 계층적 요약, 결정 상태 등)를 딱딱 계획해서 조합해 가져온다고.

장기 에이전트 메모리 평가를 위해 설계된 ICLR 2026 벤치마크인 BEAM에서 테스트해 봤는데, MindCache가 Mem0보다 컨텍스트 변화 대응, 모순 해결, 세션 간 요약 추론 능력에서 훨씬 앞섰어. 더 중요한 건, 리트리벌 윈도우만 무식하게 키운 게 아니라 입력 단계에서의 지식 구조화를 잘해서 이뤄낸 성과라는 거지.

5가지 실패 사례, 전체 아키텍처, 벤치마크 결과까지 싹 다 정리한 23분짜리 엔지니어링 포스트모템도 써놨어. 프로젝트는 깃허브에 오픈소스로 다 풀었고, PyPI에서도 바로 받을 수 있어 (pip install mindcache-ai).

다들 장기 실행 에이전트 만들 때 시간 경과에 따른 데이터 소실(temporal decay)이나 그래프 유지보수, 의사결정 추적은 어떻게 해결하고 있는지 궁금하네. 다들 의견 좀 공유해 줘!