RAG가 에이전트 메모리에서 실패하는 지점, xMemory는 어떻게 풀었나

지난달 논의한 예산 계획의 최종 결정이 무엇이었는지 에이전트에게 물으면, 표준 RAG는 '예산 계획에 대해 논의하자'는 초반 메시지만 잔뜩 끌어오고 정작 최종 결정이 담긴 메시지는 놓치는 경우가 있다. 멀티세션 AI 에이전트가 기업 환경에 본격 도입되면서, 장기 대화 맥락을 어떻게 효율적으로 관리할 것인가는 실질적인 운영 과제로 부상했다.

대규모 이질적 코퍼스를 위한 도구가 대화에는 맞지 않는 이유

기존의 RAG(Retrieval-Augmented Generation) 방식은 대규모 이질적 코퍼스를 대상으로 설계됐다. 반복적이고 상호 연관된 대화 스트림을 다루는 에이전트 메모리 환경에서는 구조적 한계를 드러낸다. 2026년 2월 킹스 칼리지 런던과 앨런 튜링 연구소 연구팀이 발표한 xMemory(Beyond RAG for Agent Memory: Retrieval by Decoupling and Aggregation, arXiv 2602.02007)는 이 문제를 정면으로 해결하는 메모리 최적화 프레임워크로, 일부 작업에서 쿼리당 토큰 사용량을 9,000개 이상에서 4,700개 수준으로 절반 가까이 줄이면서도 답변 품질을 동시에 향상시켰다.

표준 RAG 파이프라인은 쿼리와 코퍼스 간의 단순 유사도 매칭을 전제로 한다. 그러나 에이전트 메모리는 다른 성격을 갖는다. 에이전트가 다루는 메모리는 특정 사용자 혹은 작업과 연결된 유한한 대화 기록이라 수백~수천 개의 과거 메시지 중에서 관련 맥락을 찾아야 하는 경계성(Boundedness), 대화 메시지들이 서로 밀접하게 연관돼 유사도 기반 검색이 이 상관성을 무시하고 유사한 내용을 중복으로 가져오는 고상관성(High Correlation), 과거의 특정 사실 A가 B의 전제가 되는 경우가 많아 Top-k 검색이 이러한 시간적 연쇄 관계를 절단할 위험이 있는 시간 의존성(Temporal Dependency)이 그것이다.

쿼리: "지난달에 논의한 예산 계획의 최종 결정은?"

Top-k 검색 결과 (유사도 기준):
- 메시지 #47: "예산 계획에 대해 논의하자" (유사도 0.91)
- 메시지 #48: "예산 계획 검토 필요" (유사도 0.89)
- 메시지 #52: "예산 계획 관련 회의 예정" (유사도 0.87)

문제: 실제 최종 결정이 담긴 메시지 #61은 Top-k에 포함되지 않음
     메시지 #47~#48은 중복된 내용으로 토큰을 낭비

유사도 기반 검색은 의미적으로 가장 관련 있는 내용을 반드시 상위에 올리지 않으며, 중복된 정보로 컨텍스트 윈도우를 채워 토큰 낭비를 유발한다.

대화를 압축하는 것이 아니라, 층으로 쌓는다

xMemory의 핵심 아이디어는 원시 메시지를 의미 단위로 분리(Decoupling)하고 계층적으로 재조직한 뒤, 추론 시점에 상향식이 아닌 하향식으로 집계(Aggregation)해 검색하는 것이다. 연구팀은 에이전트 메모리가 일반 RAG의 전제 조건과 근본적으로 다르다는 점에 주목했다. 일반 RAG가 다루는 코퍼스는 다양하고 이질적인 문서들의 집합인 반면, 에이전트 메모리는 경계가 있고 일관성 있는 대화 스트림이다. 이 차이를 무시한 채 동일한 검색 파이프라인을 적용하면 중복 컨텍스트가 과도하게 주입되거나, 다중 추론에 필요한 연결 고리가 잘려나가는 문제가 발생한다.

⤢✕

최하단인 원시 메시지(Raw Messages)는 에이전트와 사용자 간의 실제 대화 내용이 그대로 저장되는 계층으로, 직접적인 검색 대상이 되기보다는 상위 계층의 근거 자료로 쓰이며 불확실성이 해소되지 않을 경우의 최후 참조 지점이다. 에피소드(Episodes)는 연속된 원시 메시지들을 의미 있는 블록으로 묶어 요약한 단위로, 단일 주제나 작업에 대한 대화가 하나의 에피소드로 압축되고 시간적 연속성을 보존해 인과 관계 추론에 필요한 전후 맥락이 유지된다. 시맨틱(Semantics)은 에피소드에서 추출된 재사용 가능한 핵심 사실들로, 반복적인 대화 패턴에서 변하지 않는 핵심 정보만을 증류한다("사용자의 선호 언어는 Python", "프로젝트 마감일은 3월 말" 같은 정보). RAG의 청크(chunk)와 달리 시맨틱은 에피소드의 반복적 내용에서 벗어난 탈맥락화된 사실 단위다. 테마(Themes)는 관련된 시맨틱들을 묶은 고수준 주제 그룹으로, 검색의 진입점 역할을 하며("기술 스택 선호도", "프로젝트 일정 관리", "팀원 역할 분담" 등) 관련 있는 시맨틱 클러스터 전체를 빠르게 식별할 수 있게 해준다.

너무 많아도, 너무 적어도 안 되는 균형

xMemory가 계층 구조를 최적화하는 방식은 단순한 클러스터링이 아니다. 연구팀은 두 가지 상반된 요구를 동시에 충족하는 목적 함수를 설계했다. 테마와 시맨틱 노드가 너무 많아지면 검색 속도가 저하되므로 노드 수를 최소화하는 방향으로 병합(merge)을 유도하는 희소성(Sparsity), 노드가 너무 적어지면 의미적 다양성이 사라지고 증거 집계 능력이 약해지므로 분리(split)를 유도하는 시맨틱 일관성(Semantic Coherence)이다. 이 두 힘의 균형이 메모리 계층의 품질을 결정하며, 메모리가 지속적으로 업데이트될 때마다 이 목적 함수에 따라 노드 분리와 병합이 자동으로 수행된다.

추론 시점의 검색은 세 단계로 진행된다. 쿼리와 관련된 테마를 먼저 선택해 관련 없는 대부분의 메모리를 제거하는 테마 레벨 탐색, 선택된 테마 내의 시맨틱 노드들을 탐색해 다양하고 컴팩트한 사실 집합을 구성하고 멀티홉(multi-hop) 추론이 필요하면 여러 테마에 걸쳐 시맨틱을 수집하는 시맨틱 레벨 확장, 시맨틱만으로 불확실성이 해소되지 않는 경우에만 하위 에피소드와 원시 메시지를 참조하는 에피소드 레벨 드릴다운이다. 불필요한 상세 메시지를 기본적으로 배제함으로써 토큰을 절약한다. 이 방식은 기존 RAG의 상향식 청크 검색과 정반대의 접근법이다. 항상 높은 추상 수준에서 출발해 필요한 경우에만 상세 수준으로 내려간다.

벤치마크가 보여준 숫자

멀티세션 대화를 평가하는 대표적 벤치마크인 LoCoMo에서 xMemory는 Qwen3-8B 백본 기준으로 다음 성과를 달성했다.

지표	기존 최고 방식	xMemory	개선율
BLEU-1	28.5	34.5	+21%
F1 Score	40.5	44.0	+8.6%
쿼리당 토큰 수	기준치	-29%	29% 절감

장기 질의응답(Long-Term QA) 벤치마크인 PerLTQA에서도 일관된 성능 향상이 확인됐다. GPT-4o-mini(GPT-5 nano에 해당) 기준으로:

지표	기존 방식	xMemory	개선율
F1 Score	기준치	50.00	향상
BLEU Score	기준치	38.71	향상
쿼리당 토큰 수	9,155	6,581	28% 절감

연구팀이 보고한 최대 절감 사례에서는 쿼리당 토큰 사용량이 9,000개 이상에서 약 4,700개로 감소했다. 약 48%의 절감률로, "토큰 사용량 절반 절감"이라는 표현이 과장이 아님을 보여준다. 실제 절감 효과는 작업의 특성에 따라 다르게 나타난다. 관련 시맨틱만 검색하는 단순 사실 조회는 28~~30% 절감, 테마-시맨틱 레벨만으로 해결 가능한 복합 추론 쿼리는 35~~48% 절감, 에피소드까지 참조해야 하는 시간적 연쇄 추론은 20~25% 절감이다.

수개월 치 업무 대화를 다루는 법

개인화된 기업 AI 어시스턴트에 xMemory를 적용하면 수개월에 걸친 업무 대화를 효율적으로 관리할 수 있다.

[테마 구조 예시]
├── 업무 환경 설정
│   ├── 선호 도구: IntelliJ, Slack, Confluence
│   ├── 코딩 언어: Java, Python
│   └── 코드 리뷰 스타일: 상세 피드백 선호
├── 진행 중인 프로젝트
│   ├── 프로젝트 A: 마감 2026-04-30, 담당 팀원 3명
│   └── 프로젝트 B: 요구사항 분석 단계
└── 조직 구조
    ├── 팀장: 김OO
    └── 주요 이해관계자: 박OO (CTO)

이 구조에서 "프로젝트 A의 현재 상태는?"이라는 쿼리가 들어오면, xMemory는 "진행 중인 프로젝트 > 프로젝트 A" 시맨틱만 검색해 응답에 필요한 최소한의 토큰만 사용한다. 6개월 이상의 소프트웨어 개발 프로젝트를 지원하는 에이전트라면 xMemory 없이는 매 쿼리마다 수만 개의 토큰을 소비해야 할 수 있다. xMemory를 적용하면 아키텍처 선택의 배경이 시맨틱으로 보존되는 설계 결정 추적, 해결하지 못한 이슈가 시맨틱으로 유지되는 기술 부채 관리, 담당자 변경·역할 조정 등이 테마 수준에서 관리되는 팀 컨텍스트 유지가 가능해진다.

다른 메모리 시스템과 나란히 놓으면

특성	표준 RAG	MemGPT	Mem0	xMemory
저장 구조	플랫 벡터	계층형	적응형	(4계층 계층형)
검색 방식	Top-k 유사도	키워드+벡터	그래프 기반	하향식 테마-시맨틱
중복 처리	없음	부분적	있음	목적 함수로 자동 최적화
멀티홉 추론	약함	중간	중간	강함
토큰 효율	낮음	중간	중간-높음	높음
시간적 연속성	없음	있음	부분적	에피소드 단위로 보존

언제 쓸 만하고, 언제는 아닌가

xMemory가 모든 상황에서 최선의 선택은 아니다. 대화 스트림을 4계층으로 조직화하는 과정에서 추가 처리 비용이 발생하는 메모리 인덱싱 비용은, 쿼리 빈도가 낮은 단기 에이전트라면 오히려 비효율적일 수 있다. xMemory는 세션 수가 10회 이상인 장기 에이전트, 동일 사용자와의 반복적 인터랙션, 다중 주제에 걸친 복합 추론이 필요한 경우, 토큰 비용이 운영 비용의 주요 요인인 경우에 가장 높은 효과를 낸다. 구현 복잡도도 표준 RAG 대비 높다. 희소성-시맨틱 목적 함수를 적용하는 메모리 관리 루프, 계층 업데이트 로직, 하향식 검색 엔진을 별도로 구현해야 하며, 현재 공개된 오픈소스 구현체(GitHub: HU-xiaobai/xMemory)를 참조하면 시작점을 확보할 수 있다. xMemory는 특정 LLM에 종속되지 않는다. 논문의 실험에서 Qwen3-8B, GPT-4o-mini 등 다양한 모델에서 일관된 성능 향상이 확인됐다.

xMemory는 멀티세션 AI 에이전트 운영에서 토큰 비용과 답변 품질이라는 두 목표를 동시에 달성한 연구 성과다. 기존 RAG의 플랫한 유사도 검색 대신, 대화를 테마-시맨틱-에피소드-원시 메시지의 계층으로 조직화하고 하향식으로 검색하는 방식은 에이전트 메모리의 고유한 특성을 정확히 파악한 설계다. 25년간 시스템 아키텍처를 다루면서 느끼는 것은, 좋은 데이터 구조가 알고리즘의 복잡도를 줄이는 것처럼, 좋은 메모리 구조가 토큰 소비를 줄인다는 단순한 원리다. 장기 에이전트를 구축하거나 운영 중인 개발자와 아키텍트라면, 이 접근법이 실질적인 비용 절감과 품질 향상의 두 마리 토끼를 잡는 유력한 수단이 될 것이다.