정적 파이프라인이 막히는 지점
현재 메모리 증강 에이전트 대부분은 검색을 먼저 끝낸 뒤 추론을 시작하는 retrieve-then-reason 구조를 씁니다. 이 구조는 검색 단계가 고정돼 있어, 추론 중간에 나온 증거를 다시 검색 경로에 반영하지 못합니다. 국립싱가포르대(NUS) 연구진이 2026년 6월 공개한 논문 'Memory is Reconstructed, Not Retrieved'는 이 경직성이 멀티홉 질문에서 답을 놓치거나 무관한 문서를 끌어와 프롬프트만 불리는 원인이라고 지적합니다.
Cue-Tag-Content 그래프와 능동 재구성
이 논문이 제안한 MRAgent는 메모리를 단서(Cue)·태그(Tag)·내용(Content) 3층 그래프로 저장하고, 태그를 세부 단서와 저장된 내용을 잇는 의미 다리로 씁니다. 검색을 한 번에 끝내는 대신 LLM 추론을 메모리 접근 과정에 통합해, 누적된 증거를 보고 탐색 경로를 넓히거나 가지치기하는 것을 반복합니다. 그 결과 프롬프트 토큰 소비가 쿼리당 A-Mem 63만2천 개, LangMem 326만 개인 구간에서 MRAgent는 11만8천 개로 줄었고, 여러 모델과 질문 유형에서 기준선 대비 정답률도 유의미하게 앞섰습니다.
탐색에서 정지까지: 그래프 메모리 재구성 도입 체크리스트
그래프 메모리로 옮기기 전에 팀 목표부터 숫자로 못박아야 합니다. 쿼리당 프롬프트 토큰은 논문 관찰치 11만8천 개에 여유를 두어 20만 개 이하를 상한으로 잡고, 탐색 홉 수는 3홉 이내 수렴을 기준으로 삼습니다. 멀티홉 질문 정답률은 기존 벡터 단일 검색 대비 15%p 이상 개선을 목표로 하고, 재구성 1회당 지연은 p95 4초 이하로 관리합니다.
태그 스키마도 기획 단계에서 확정해야 합니다. 하나의 콘텐츠 노드에 태그가 과도하게 붙으면 탐색이 방사형으로 퍼져 홉 수 상한을 넘기고, 반대로 태그가 성기면 재구성이 걸리지 않은 채 벡터 검색으로 되돌아갑니다. 태그당 평균 연결 콘텐츠 노드 수를 8개 안팎으로 관리하는 것이 출발점입니다.
실패 패턴은 크게 세 갈래로 나타납니다. 탐색이 수렴 조건 없이 그래프를 계속 넓혀가는 폭발형, 오래된 태그가 최신 콘텐츠를 가리키지 못해 재구성이 엉뚱한 노드에 멈추는 드리프트형, 그리고 홉을 반복해도 새 증거가 나오지 않는데 계속 도는 공회전형입니다.
복구는 유형별로 다르게 걸어야 합니다. 폭발형은 홉 수 상한과 탐색 노드 수 상한을 함께 걸어 초과 시 지금까지 모은 증거로 답을 생성하도록 강제 종료하고, 드리프트형은 태그-콘텐츠 매핑에 버전을 붙여 오래된 매핑이 걸리면 벡터 검색으로 안전 축소합니다. 공회전형은 연속 두 홉에서 신규 노드 발견이 없으면 재구성을 멈추고 누적 증거만으로 답하는 조기 종료 규칙을 둡니다.
배포 전에는 LoCoMo·LongMemEval류 골든셋으로 재구성 정답률과 토큰 비용을 함께 재고, 그래프 노드에 개인정보가 섞이지 않도록 단서·태그 필드는 저장 전에 마스킹합니다. 로그에는 홉 수, 탐색 노드 수, 최종 토큰 소비, 조기 종료 사유를 필수 필드로 남겨야 재구성 실패와 벡터 검색 실패를 구분해 추적할 수 있습니다.
전환은 일괄이 아니라 기존 벡터 단일 검색과 병행하는 카나리 구간으로 시작합니다. 트래픽 10%에서 시작해 토큰 비용과 정답률 델타가 목표 안에 들어오면 단계적으로 넓히고, 어긋나면 라우팅만 바꿔 벡터 검색으로 되돌립니다.
매주 조기 종료·드리프트로 실패한 재구성 트레이스를 유형별로 모아 태그 스키마를 손보고, 반복적으로 걸리는 오래된 매핑은 그래프에서 정리합니다. 홉당 신규 증거 발견율이 떨어지는 태그군을 표로 남겨 두면 다음 스키마 개편 때 우선순위로 참고할 수 있습니다.
실행 요약
검색 후 추론을 정적으로 고정하면 멀티홉 질문에서 정답을 놓치거나 토큰만 태우기 쉽습니다. 단서·태그·콘텐츠 그래프에 능동 재구성을 결합하면 쿼리당 토큰을 LangMem 대비 최대 27배까지 줄일 수 있다는 것이 MRAgent의 관찰치이며, 홉 수 상한·태그 버전 관리·조기 종료 규칙을 먼저 걸어야 폭발형·드리프트형 실패를 막고 이 수치에 다가갈 수 있습니다.
참고 링크
Memory is Reconstructed, Not Retrieved: Graph Memory for LLM Agents — arXiv:2606.06036
New agentic memory framework uses 118K tokens per query, LangMem burns through 3.26M — VentureBeat