검색 우선(Retrieval-first) 에이전트 메모리 DB 구축기: 두 논문은 검색이 잘못된 기본값이라고 말한다

저는 에이전트를 위한 MCP(Model Context Protocol) 네이티브 임베디드 메모리 데이터베이스인 mnemo를 관리하고 있습니다. 이 시스템의 읽기 경로(read path)는 검색(retrieval)입니다. 즉, RRF(Reciprocal Rank Fusion)로 융합된 하이브리드 검색(벡터 + BM25 + 그래프 + 최신성)을 사용합니다. 이번 주, 두 편의 논문은 장기적 목표를 가진 에이전트(long-horizon agents)에게 '저장소로부터의 검색(retrieval-from-a-bank)'이 잘못된 기본값이라고 주장했습니다. 제품 개발자로서 이 논문들을 어떻게 해석하고 있는지 공유합니다.

두 논문 중 Mem-π (ServiceNow + Mila, arXiv:2605.21463)는 정적인 항목을 검색하는 대신, 필요할 때마다 가이드(guidance)를 생성하도록 별도의 모델을 학습시킵니다. 이 모델은 언제 가이드를 내보낼지, 무엇을 내보낼지를 결정하며, 내보내지 않을 수도 있습니다. 결과적으로 웹 내비게이션(web-navigation) 작업에서 검색 기반 및 이전의 강화학습(RL) 메모리 베이스라인 대비 30% 이상의 상대적 성능 향상을 보였습니다.

MINTEval (UNC, arXiv:2605.18565, code)은 간섭(interference) 상황에서의 메모리를 벤치마킹합니다. 즉, 최대 1.8M 토큰에 걸쳐 문맥(context)에 따라 사실이 수정되거나 모순되는 상황을 다룹니다. 7개의 시스템(Long-context, RAG, 메모리 프레임워크)을 대상으로 테스트한 결과, 평균 정확도는 27.9%였으며, 다중 목표 집계(multi-target aggregation)에서 가장 낮은 성능을 보였습니다. 진단 결과는 다음과 같습니다: 병목 현상은 검색(retrieval)과 메모리 구축(memory construction)에 있으며, 업데이트가 쌓일수록 상황은 악화됩니다.

그들이 맞게 짚은 점:
정적 회상(Static recall)은 쉬운 절반입니다. 어려운 절반은 '오래된 사실(stale-fact)'의 경우입니다.

t0: 사용자 예산 = 5000
t1: 예산 = 7000
t2: 예산 = 4000 <- 현재의 진실
질의: "예산이 얼마인가요?"

단순한 top-k 유사도 방식은 세 가지를 모두 반환하며, 최신성이 아닌 코사인 유사도(cosine similarity)로 순위를 매깁니다. 벡터 인덱스는 '유사함'은 알지만 '현재 상태'는 모릅니다. 그 격차가 MINTEval의 27.9%라는 수치로 나타나며, 저 또한 프로덕션 환경에서 이를 경험했습니다.

제가 생성(Generation) 방식으로 전환하지 않는 이유:

생성 방식은 공짜가 아닙니다. 모든 회상(recall)의 핫 패스(hot path)에서 모델 호출이 발생하며, 이는 더 많은 토큰을 소모합니다.

검색이 구조적으로 가질 수 없는 실패 모드가 있습니다: 즉, 아예 저장된 적이 없는 메모리입니다. 검색 시스템은 잘못된 항목을 반환할 수는 있지만, 존재하지 않는 항목을 반환할 수는 없습니다.

감사(audit) 요건이 있는 DPDP/HIPAA 워크로드의 경우, 해시 체인(hash-chain)을 갖춘 감사 가능한 검색 로그가 감사 불가능한 생성 방식보다 우월합니다. 반면, 감사가 필요 없는 웹 내비게이션에서는 생성 방식이 승리할 수 있습니다. 워크로드에 따라, 기본값은 달라져야 합니다.

내가 실제로 바꾸려는 것: 두 논문이 지목한 두 가지의 미세한 변화:

간섭 평가 하네스 (Interference-eval harness) — MINTEval의 설정을 소규모로 재현합니다: 하나의 사실을 K번 수정하고, 가장 최근의 것을 쿼리하며, 정적 데이터셋에 대한 recall@k 대신 K번의 수정 하에서 현재 사실의 정확도 (current-fact accuracy)를 측정합니다.

어떤 사실이 현재인지 판별하는 리졸버 (Which-fact-is-current resolver) — 후보군이 LLM에 도달하기 전에, DB가 이미 저장하고 있는 타임라인상의 버전 충돌을 해결합니다: 모순되지 않은 가장 최근의 쓰기 작업을 선호하며, 증거로서 대체 체인 (supersession chain)을 드러냅니다.

생성이 아닌, 통제된 검색 (Governed retrieval). 감사 로그 (Audit log)는 온전하게 유지됩니다.

핵심 요약: 검색 (Retrieval)은 죽지 않았습니다. 단순한 검색 (Naive retrieval)이 죽은 것입니다. 제품의 핵심은 통제된 중간 단계입니다: 어떤 사실이 현재인지 알고, 모든 답변이 어디에서 왔는지 증명할 수 있는 검색입니다.

만약 프로덕션 환경에서 에이전트 메모리 (agent memory)를 운영 중이라면 댓글을 남겨주세요: "찾을 수 없음" 실패가 더 많습니까, 아니면 "잘못된 버전을 찾음" 실패가 더 많습니까? 그 답변이 무엇을 먼저 구축할지를 결정합니다.