에이전트 메모리 설계 2026: Mem0 단일 패스 추출·다중 신호 검색으로 LLM 에이전트의 기억을 토큰 효율적으로 관리하는 방법

반복 작업을 수행하는 에이전트가 기억을 잃는 이유

RAG(Retrieval-Augmented Generation)가 LLM에 외부 지식을 연결하는 방법이라면, 에이전트 메모리는 LLM이 자신의 과거 행동과 사용자의 맥락을 기억하는 방법이다. 둘은 역할이 다르다. RAG는 정적 지식 검색이고, 에이전트 메모리는 세션 간에 살아남아야 하는 동적 상태다.

문제는 구현이 어렵다는 것이다. 단순히 대화 기록을 벡터 스토어에 넣으면 어떻게 될까?

세션이 쌓일수록 메모리 스토어가 비대해진다.
같은 사실이 세 가지 버전으로 중복 저장된다.
사용자가 선호를 바꿨을 때 오래된 사실이 더 높은 점수로 검색된다.
10번째 세션의 에이전트가 1번째 세션의 정보를 신뢰하다 틀린 판단을 내린다.

2026년 4월, mem0는 이 문제를 구체적인 알고리즘으로 다룬 토큰 효율 메모리 알고리즘을 공개했다. LoCoMo, LongMemEval, BEAM 세 가지 표준 벤치마크에서 측정 가능한 성능을 보고하며 에이전트 메모리 설계를 공학적 문제로 다루겠다는 태도를 보여줬다.

왜 전체 컨텍스트를 넘기는 방식이 막히는가

가장 직관적인 에이전트 메모리 구현은 "모든 과거 대화를 컨텍스트에 넣는다"는 방식이다. 컨텍스트 창이 100만 토큰까지 확장된 지금, 이 방법이 더 현실적으로 보인다.

그러나 세 가지 현실적 문제가 있다.

문제	설명
비용	쿼리마다 수만 토큰 처리. 사용자 수가 늘면 선형이 아닌 지수 비용
주의력 희석	컨텍스트가 길수록 초기 내용에 대한 LLM 응답 품질이 하락
업데이트 불가	사용자가 선호를 변경해도 이전 발언을 "무효화"할 방법이 없음

Mem0의 벤치마크 비교에 따르면, 전체 컨텍스트 접근 방식은 쿼리당 25,000+ 토큰을 소모하면서도 LongMemEval에서 80점 초반대에 머물렀다. Mem0 2026 알고리즘은 6,800~7,000 토큰으로 93점 이상을 달성했다.

4개 연산으로 메모리를 관리하는 방법

Mem0의 핵심 설계는 새 입력이 들어올 때 메모리를 무조건 추가하지 않는다는 것이다. 대신 네 가지 연산 중 하나를 결정한다.

ADD — 기존 메모리에 없는 새 사실을 추가
UPDATE — 기존 메모리에 있는 사실이 바뀌었을 때 교체
DELETE — 기존 메모리가 더 이상 유효하지 않을 때 제거
NOOP — 이미 알려진 사실의 재확인이거나 기억할 가치가 없을 때 무시

예를 들어 사용자가 "뭄바이에 살아요"라고 했다가 다음 세션에서 "방갈로르로 이사했어요"라고 하면, 시스템은 UPDATE 또는 DELETE+ADD 조합을 선택해 오래된 위치 정보를 교체한다. "오늘 날씨가 좋네요" 같은 발화는 NOOP으로 처리돼 메모리 스토어에 남지 않는다.

새 입력 (메시지 페어)

↓

추출 단계: 기억할 사실 식별

↓

기존 메모리와 비교 (의미적 유사도)

↓

ADD

새 사실

기존 없음

UPDATE

사실 변경

기존 교체

DELETE

무효화

기존 제거

NOOP

이미 알고 있음

또는 무관

↓

메모리 스토어 갱신 완료

Mem0 메모리 연산 결정 흐름

이 설계의 핵심은 메모리 스토어가 최근의 사실을 우선하는 정제된 상태를 유지한다는 점이다. 단순 append-only 방식과 달리, 스토어 크기가 세션 수에 비례해 무한 성장하지 않는다.

단일 패스 추출: 에이전트 발화도 기억한다

기존 접근법의 숨겨진 문제는 사용자 발화만 메모리 후보로 보는 경향이다. 하지만 에이전트가 "이 방법을 추천드립니다"라고 말했다면, 다음 세션에서 에이전트는 자신이 무엇을 추천했는지 알아야 일관성을 유지할 수 있다.

Mem0 2026 알고리즘의 단일 패스 추출(single-pass extraction)은 사용자 발화와 에이전트 발화를 동등하게 다룬다. 입력 메시지 페어(사용자 + 에이전트) 전체를 한 번의 LLM 호출로 분석해 기억할 사실 후보를 뽑는다. 두 번의 패스로 나눠 처리하던 이전 방식보다 지연이 낮고 에이전트의 관점도 포함된다.

추출 결과는 자연어 명제 형태로 저장된다. 예:

사용자가 Python을 선호한다
에이전트가 FastAPI 사용을 권했다
사용자가 서울에 거주한다

벡터 스토어에는 이 명제들이 임베딩되어 저장된다. 그래프 계층에는 엔티티 간 관계(예: 사용자-거주지, 에이전트-추천 항목)가 링크된다.

다중 신호 검색: 벡터만으로는 부족한 이유

에이전트가 "지난번에 추천한 라이브러리가 뭔가요?"라고 물어볼 때, 순수 벡터 유사도 검색은 종종 틀린 기억을 가져온다. 임베딩 공간에서 의미적으로 비슷하지만 시점이 다른 항목들이 섞이기 때문이다.

Mem0의 다중 신호 검색(multi-signal retrieval)은 세 가지 신호를 병렬로 점수화한 뒤 합산한다.

검색 쿼리

↓

의미 유사도

임베딩 코사인 유사도

벡터 스토어 ANN 검색

BM25 키워드

역인덱스 기반 검색

정확한 용어 매칭

엔티티 매칭

그래프 기반 관계 검색

사람·장소·개념 연결

↓

통합 점수 계산 → 상위 k개 메모리 반환

다중 신호 검색 아키텍처

BM25가 중요한 이유는 시간 관련 쿼리("지난주에", "처음 말했을 때")에서 벡터 검색이 약하기 때문이다. "지난주에 방문한 식당"이라는 쿼리에서 의미적으로는 "맛집 추천"이 더 가까울 수 있지만, BM25는 "지난주"와 "식당"이라는 키워드에 높은 점수를 준다. 두 신호를 합산하면 두 약점을 상쇄한다.

시간 쿼리에서의 성능 향상(+29.6 포인트)이 가장 큰 이유가 여기에 있다.

세 가지 메모리 스코프

Mem0는 메모리를 세 가지 스코프로 분리한다. 이 구분은 검색 시 어떤 메모리를 우선할지 결정하는 데 사용된다.

스코프	식별자	용도
사용자(User)	`user_id`	세션을 넘나드는 영구적 선호·사실
세션(Session)	`run_id`	현재 대화의 임시 컨텍스트
에이전트(Agent)	`agent_id`	특정 에이전트 인스턴스의 도메인 지식

조직(org/app) 수준 스코프도 지원해 멀티테넌트 환경에서 분리를 보장한다.

검색 시에는 사용자 스코프와 에이전트 스코프를 교차 참조한다. 예를 들어 특정 에이전트가 사용자에게 무엇을 권장했는지는 두 스코프의 교집합에서 나온다.

벤치마크: LoCoMo, LongMemEval, BEAM

2026년 에이전트 메모리 분야에서 세 벤치마크가 표준으로 자리 잡았다.

LoCoMo

멀티세션 대화 데이터(1,540개 질문, 4가지 카테고리)를 기반으로 에이전트가 세션을 넘어 사실을 얼마나 잘 기억하는지 측정한다. 단일 홉·다중 홉·오픈도메인·시간 추론으로 나뉜다.

LongMemEval

500개 질문으로 구성되며, 단일 세션 사용자 회상·에이전트 회상·선호 기억·지식 업데이트·시간 추론·다중 세션 회상 6가지를 평가한다.

BEAM

1M 토큰(단기 메모리 집약)과 10M 토큰(장기 메모리 집약) 두 설정에서 측정한다. 토큰 규모가 커질수록 어떤 시스템이 성능을 유지하는지 드러낸다.

벤치마크	Mem0 2026	사용 토큰/쿼리
LoCoMo	91.6	6,956
LongMemEval	93.4	6,787
BEAM (1M)	64.1	—
BEAM (10M)	48.6	—

전체 컨텍스트 방식은 25,000+ 토큰을 쓰면서도 LoCoMo 80점대에 머물렀다. 3.5배 이상 토큰을 쓰는 대신 11점 이상 낮은 결과다.

가장 큰 개선은 시간 추론(+29.6) 과 다중 홉 추론(+23.1) 에서 나왔다. BM25 신호가 시간 관련 쿼리를 잘 처리하고, 그래프 엔티티 링크가 여러 사실을 연결하는 추론을 돕기 때문이다.

운영 고려사항

Mem0는 Python SDK와 REST API 두 가지로 제공된다. 벡터 스토어는 20종 이상을 지원하며(pgvector, Qdrant, Weaviate, Chroma 등), LangChain·LlamaIndex·CrewAI 등 13개 에이전트 프레임워크와 통합 어댑터를 공개한다.

운영에서 주의할 판단 기준:

메모리 경계: 무엇을 기억하고 무엇을 잊을지. 규칙 기반 필터보다 LLM 기반 NOOP 판단이 더 유연하지만, 모델 변경 시 동작이 달라질 수 있다.
스코프 설계: 사용자 스코프가 너무 넓으면 무관한 정보가 검색된다. 에이전트 타입별 스코프 분리가 실용적이다.
사생활: 민감한 사용자 데이터가 메모리 스토어에 영구 저장될 수 있다. 보존 정책과 만료 TTL을 명시적으로 설계해야 한다.
업데이트 충돌: UPDATE 연산이 어떤 기존 메모리를 교체할지 모호할 때 오탐 위험이 있다.

한계와 Open Question

현재 에이전트 메모리 분야에서 아직 해결되지 않은 문제들이 있다.

BEAM 10M에서의 25% 성능 하락: 메모리 스토어가 1M 토큰 규모에서 10M 토큰 규모로 증가할 때 64.1 → 48.6으로 성능이 크게 떨어진다. 검색 공간이 넓어질수록 노이즈와 신호를 구별하기 어려워진다는 뜻이다. 대규모 장기 에이전트에서의 메모리 관리는 아직 Open question이다.

세션 간 신원 연속성: 동일 사용자가 다른 채널(API, 앱, 음성)로 접속하면 동일인임을 추론하기 어렵다. 신원 해소(identity resolution)는 현재 Mem0가 명시적으로 해결하지 않는다.

메모리 진부화(staleness): 수개월 된 선호가 여전히 유효한지를 시스템이 스스로 판단하기 어렵다. 지식 업데이트 쿼리에서 LongMemEval 성능이 다른 카테고리보다 낮게 나오는 이유 중 하나다.

추출 품질의 모델 의존성: 단일 패스 추출 단계가 LLM 출력에 의존하므로, 기반 모델이 변경되면 추출 품질이 바뀔 수 있다. 재현 가능성을 위한 버전 고정 전략이 필요하다.

정리

에이전트 메모리는 "세션이 끝나도 기억을 유지한다"는 요구에서 시작했지만, 2026년에는 무엇을 기억하고, 무엇을 교체하고, 무엇을 잊을 것인가를 관리하는 공학적 문제가 됐다.

Mem0의 ADD/UPDATE/DELETE/NOOP 연산 모델은 메모리 스토어를 단순히 쌓는 것이 아니라 정제하는 방향으로 설계된다. 다중 신호 검색은 순수 벡터 검색이 약한 시간·엔티티 추론을 보완한다. 그 결과 쿼리당 7,000 토큰 이하로 LongMemEval 93점을 달성했다.

대규모 장기 운영에서의 성능 유지, 세션 간 신원 연속성, 메모리 진부화는 여전히 열린 문제다. 그러나 표준 벤치마크(LoCoMo, LongMemEval, BEAM)의 등장으로 이 문제들이 측정 가능한 형태로 논의될 수 있게 됐다는 점 자체가 분야의 성숙을 보여준다.