에이전트 메모리의 측정 — 평가 벤치의 등장 배경 및 범위

TL;DR

• 에이전트 메모리 평가 벤치 세 개가 한 주 사이에 같은 곳에 동시 등장했다. LongMemEval-V2(2026-05-13, UCLA) · MEME(2026-05-13, KAIST + 튀빙겐 + NAVER) · MemPrivacy(2026-05-10, MemTensor + Tongji). 같은 카테고리지만 각자 직교하는 축을 측정한다 — 누적(LongMemEval-V2), 의존성 추론(MEME), 프라이버시-효용 균형(MemPrivacy).
• 세 벤치가 모두 기존 벤치가 측정하지 않던 지점을 잡는다. LongMemEval-V2는 환경 경험 누적(웹 에이전트가 "경험 있는 동료"가 될 수 있는가)을, MEME는 다중 엔티티 의존성 추론(한 엔티티 변경이 의존된 엔티티에 전파되는가)을, MemPrivacy는 프라이버시 등급별 유틸리티 손실을 측정. 같은 모먼트에 서로 다른 빈 곳 세 개가 동시 메워졌다.
• 핵심 발견 — 셋이 모두 시스템이 깨지는 지점을 발견했다. LongMemEval-V2: 최고 메모리 시스템(AgentRunbook-C)도 Environment Gotchas 48.3%에 머무름. MEME: 모든 시스템이 Cascade(의존성 전파) 3%·Absence(불확정 인식) 1%에서 동시 붕괴. Claude Opus 4.7로 간신히 부분 해결 가능하지만 70× 비용. MemPrivacy: 일반 LLM은 2-96초 걸리는 작업을 0.4-2초에 처리하는 specialized 모델이 등장.
• 측정 도구가 생겼다는 것은 카테고리가 굳었다는 신호다. 세 벤치의 교집합이 아니라 합집합이 큰 대목이 이 카테고리의 현재 표면적. 셋이 동시 등장했다는 사실 자체가 학계가 메모리를 별도 도메인으로 인정했다는 첫 객관적 증거 — Agent Framework 카테고리가 그랬듯, 같은 임계점을 지나고 있는 국면.

1. 왜 측정 도구의 등장이 신호인가

카테고리 인덱스가 깐 정의를 다시 끌어오면 — 에이전트 메모리는 컨텍스트 윈도우 외부에 무엇을 어떻게 누적할 것인가에 대한 답. 2025년~2026년 1분기 사이에 메타프레임마다 자기 답을 들고 등장했지만, 그 답들이 서로 비교 가능하려면 공통 측정 도구가 필요하다. 측정 도구가 생기기 전까지는 주장의 비교만 가능했지 증거의 비교는 불가능.

세 벤치가 같은 한 주에 등장했다는 사실이 이 대목의 핵심. 학계가 카테고리를 별도 도메인으로 인정하기 시작했다는 첫 객관적 증거이며, 동시 등장 자체가 수렴 신호다. 자연발생적 우연이 아니라, 카테고리가 측정 가능한 단계에 도달했다는 시그널.

세 벤치는 서로 다른 빈 곳을 메운다. LongMemEval V1(2025)이 대화형 메모리(user-assistant chat)에 머물렀던 지점을 LongMemEval-V2가 환경 메모리(web/work agent)로 확장하고, RULER·LoCoMo·MemBench가 다루지 못한 의존성 추론을 MEME가 잡고, 기존 벤치 모두가 다루지 않던 프라이버시-효용 균형을 MemPrivacy가 잡는다. 셋이 직교한다는 점이 합집합의 가치를 키운다.

2. LongMemEval-V2 — "경험 있는 동료가 될 수 있는가"

2.1. 무엇을 측정하나

UCLA(Di Wu et al., 2026-05-13)가 LongMemEval-V2로 잡는 질문은 단순하다 — 메모리 시스템이 에이전트를 "환경 경험이 있는 동료"로 만들 수 있는가. 기존 V1(2025)이 대화형 메모리(user-assistant chat)에 머물렀던 지점에서 V2는 웹 환경 에이전트의 경험 누적으로 확장.

벤치의 본체는 451개의 수기 큐레이션 질문 + 100~500개 trajectory haystack + 최대 115M 토큰. 5개의 핵심 메모리 능력을 직접 측정:

5개 축이 서로 다른 종류의 망각에 대응한다. 같은 사용자라도 Static State Recall에서 잘 하면서 Premise Awareness에서 무너진다면 메모리 시스템의 어느 부분이 빈지 정확히 가리킬 수 있다.

2.2. 어떻게 측정하나 — Context Gathering Formulation

V2의 디자인 핵심은 측정의 직접성이다. 기존 벤치 다수가 task success를 통해 메모리를 간접 측정했다면 V2는:

Insert(trajectory) → Query(question) → Truncated_Context(200K) → Reader_LLM → Answer

고정 reader LLM(Qwen3.5-9B, 200K 컨텍스트 truncation)이 메모리 시스템이 반환한 컨텍스트만 보고 답한다. 메모리 시스템의 quality가 reader 성능에 직접 반영되도록 reader를 고정. 다운스트림 에이전트가 실제로 쓸 인터페이스와 동일.

규모도 압도적 — 25M(Small) ~ 115M(Medium) 토큰. V1의 1.5M 최대를 15-100× 초과. 외부에서 parametric knowledge로 답할 수 없도록 frontier LLMs(Gemini-3-Pro, GPT-5.2, Grok-4.1, Claude-Opus-4.6)로 사전 필터링.

2.3. 핵심 발견 — 코딩 에이전트가 메모리 컨트롤러가 되는 자리

V2 본체는 두 baseline 메모리 시스템도 같이 제안:

• AgentRunbook-R (RAG-based) — 세 knowledge pool(raw states·events·notes), Qwen3-Embedding-8B + Qwen3.5-9B controller. 58.6% (Small).
• AgentRunbook-C (Coding agent-based) — 모든 trajectory를 디스크 파일로 두고 Codex(GPT-5.4-mini, xhigh reasoning) sandbox가 evidence를 직접 수집. 74.9% (Small).

가장 중요한 결과는 RAG가 깨지는 지점에서 코딩 에이전트가 잡는다는 점이다. RAG는 단일 query → vector similarity 모델이라 workflow와 procedure를 다층으로 끌어오지 못한다. 코딩 에이전트는 파일 시스템을 직접 탐색하므로 evidence를 정제할 수 있다.

단 능력별 breakdown을 보면 Environment Gotchas가 48.3%로 가장 약하다 — 즉 최고 시스템도 "환경별 실패 패턴 인식"에서는 절반밖에 못 한다. 메모리는 알고 있는 것을 기억하는 대목에서는 잘 하지만 알고 있어야 할 것을 인식하는 대목에서는 약하다는 신호.

비용도 정직히 노출 — AgentRunbook-C는 query당 108초. AgentRunbook-R(27초)보다 4× 느리지만 정확도는 17%p 높다. latency-accuracy 트레이드오프의 새 frontier를 그렸다는 것이 V2의 직접 기여.

2.4. V1 → V2 — 카테고리 진화의 한 마디

V1과 V2의 차이를 한 줄로 줄이면 대화형 메모리에서 환경 메모리로. V1은 "이 사용자가 저번에 뭐라 말했지"를 측정, V2는 "이 사용자가 일하는 환경에서 어떻게 동작해야 하는지를 기억하는가"를 측정. 측정 단위가 발화에서 trajectory로 이동한 셈. 메타프레임(GSD .planning/·gstack /learn·ECC instinct)이 모두 환경 메모리를 첫 시민으로 두는 디자인과 학계 측정 도구가 같은 자리에 도착한 모먼트.

3. MEME — "의존성 추론이 깨지는 자리"

3.1. 무엇을 측정하나

KAIST + 튀빙겐 + NAVER(Seokwon Jung et al., 2026-05-13)의 MEME — Multi-entity & Evolving Memory Evaluation. 잡는 질문은 더 좁고 더 날카롭다 — 한 엔티티의 변경이 의존된 엔티티에 올바르게 전파되는가.

기존 메모리 벤치(RULER·LoCoMo·LongMemEval·MemBench)는 단일 엔티티 업데이트만 측정. 현실 에이전트는 의존된 지식을 다룬다 — 사용자가 새 도시로 이사하면 통근 시간·근처 시설·집값이 전부 바뀐다. 한 변경이 여러 결과를 만든다.

MEME는 2개의 직교 축으로 6개 task를 정의:

이 중 Cascade · Absence · Deletion 세 task는 기존 벤치 어디도 측정하지 않는 지점.

• Cascade: 의존성 규칙에 따라 변경을 전파 — parent 엔티티가 바뀌면 child도 바뀌어야 함
• Absence: 해소 규칙이 없을 때 불확정성을 인식 — "이전 값은 무효지만 새 값은 모름"을 보고할 수 있는가
• Deletion: 명시적으로 삭제된 사실을 더 이상 보고하지 않는지 검증

3.2. 데이터셋의 정직성

MEME의 데이터셋은 DAG 기반 knowledge graph로 손수 구축. 두 도메인(Personal Life 39 엔티티·34 엣지·5 패턴; Software Project 51 엔티티·27 엣지·6 패턴). 100 episode(~35K 토큰/episode), episode당 694 평가 질문. Verifiable ground truth by construction — 구조적으로 정답이 명확하다.

GPT-4o judge가 98.6%의 인간 annotator 동의를 보임(메타-검증). 즉 주관적 평가 게임이 아니라 객관적 정답이 명시된 벤치.

3.3. 핵심 발견 — 모든 메모리 시스템이 의존성 추론에서 동시 붕괴

MEME가 측정한 6 시스템:

• Raw retrieval: BM25 · text-embedding-3-small
• LLM-processed: Mem0 · Graphiti (temporal knowledge graph)
• File-based agents: MD-flat (markdown + tool-use) · Karpathy Wiki (daily log → compiled topic)

결과:

평균 3% Cascade·1% Absence. 모든 시스템이 동시에 붕괴한다. 부분적 회피를 위한 시도 — k=5→40으로 retrieval 깊이 늘리기, DSPy SIMBA로 프롬프트 최적화, 답변 LLM을 Sonnet 4로 업그레이드, filler noise를 0/32K/128K로 조절 — 어느 것도 효과 없음.

3.4. 실패의 3단계 — encoding·retrieval·answering

MEME가 정직히 펼친 failure mode 분석:

1. Encoding ✓ — 의존성 규칙·pre-change 값·change event는 모두 잘 저장됨.
2. Retrieval ✗ — change event가 pre-change 값에 ranking에서 밀린다. Vector retriever는 의미적으로 가까운 pre-change value를 우선 반환. Tool-use/graph도 change event를 surface 못 함.
3. Answering ✗ — k=20/40으로 rule + change가 둘 다 검색되어도 LLM이 propagate하지 못한다 — 오래된 값을 그대로 보고.

즉 3단계 모두에 문제가 있다. 의존성 추론은 retrieval만 고친다고 풀리지 않는다는 진단.

3.5. 유일한 working solution — 70× 비용의 자기 propagation

MEME가 발견한 유일하게 부분 동작하는 메커니즘: MD-flat + Claude Opus 4.7. Cascade 0.32, Absence 0.59까지 도달.

메커니즘은 단순 — Opus가 ingest 시점에 "Contingency:" 항목을 명시적으로 작성하고, upstream 변경 시 propagate된 값을 직접 메모리에 적는다. 즉 retriever가 발견 가능한 형태로 자기 변환.

비용 — episode당 $4.54 vs baseline gpt-4.1-mini $0.065 = 70×. 그리고 부작용 — Exact Recall이 0.94→0.60으로 떨어지고 Tracking도 0.77→0.20으로 떨어진다. 의존성 추론을 잡으려고 active write를 늘리면 기본 retrieval이 어지러워진다는 trade-off.

한 줄로: 2026-05 시점 의존성 추론을 실용 비용에 풀어내는 메모리 시스템은 없다. MEME는 이 대목을 정직히 노출한 첫 벤치.

3.6. ripple effect — knowledge editing 문헌과의 연결

MEME가 잡는 ripple effect는 knowledge editing 문헌의 핵심 도전을 메모리 시스템에 옮긴 지점. LLM 가중치를 직접 수정하는 knowledge editing이 한 facts 수정이 의존된 facts에 어떻게 전파되는지를 다루는데, MEME는 외부 메모리 시스템에서도 같은 도전이 발생한다는 점을 측정. 두 분야가 같은 문제를 다루지만 분리된 채로 진화해왔다는 대목.

4. MemPrivacy — "프라이버시와 유틸리티의 트레이드오프"

4.1. 무엇을 측정하나

MemTensor Shanghai + Tongji University(Yining Chen et al., 2026-05-10)의 MemPrivacy. LongMemEval-V2와 MEME가 메모리 시스템 자체를 측정한다면, MemPrivacy는 엣지-클라우드 에이전트의 프라이버시 표면을 측정한다.

문제 설정 — 엣지 디바이스(개인 휴대폰·노트북)에서 민감한 정보가 클라우드 LLM으로 전송되는데, prompt injection·multi-turn memory attack·leakage attack이 69-75% 성공률. 기존 대응은 raw masking(***로 치환)이지만 유틸리티 손실이 26-41% — 프라이버시를 보호하면 task가 망가진다.

MemPrivacy의 측정 대상 — 프라이버시 누설 위험 vs 유틸리티 손실의 Pareto frontier:

min ℛ_priv(ℱ_san) subject to ℒ_util(ℱ_san, ℱ_res) ≤ ε

4.2. 4단계 프라이버시 분류

PL1 ~ PL4로 민감도 분류:

사용자가 어느 등급까지 보호할지 선택 가능. 기본 디자인 가정 — PL4만 보호하면 유틸리티 손실 <0.18%, PL2-PL4 전체 보호 시 1.6% 이내.

4.3. 메커니즘 — typed placeholder의 reversible pseudonymization

MemPrivacy 핵심은 masking이 아니라 typed placeholder:

• Raw Masking: "패스워드는 secret123" → "패스워드는 ***" (의미 파괴)
• Untyped Placeholder: "패스워드는 secret123" → "패스워드는 <MASK_1>" (타입 손실)
• MemPrivacy: "패스워드는 secret123" → "패스워드는 <PASSWORD_1>" (타입 보존·값 보호)

타입 정보가 보존되므로 클라우드 LLM이 자연스러운 응답 생성 가능하고, 엣지 디바이스의 로컬 DB에 원본을 저장해 응답에서 placeholder를 원본으로 복원. 즉 cloud-side leakage가 발생해도 placeholder만 노출된다는 아키텍처 레벨 격리.

4.4. 핵심 발견 — specialized 작은 모델이 frontier LLM 압도

MemPrivacy 4B-RL이 MemPrivacy-Bench에서 F1 85.97%, 일반 LLM 최고(Gemini-3.1-Pro) 78.41% 대비 +7.56%p. 더 인상적인 대목은 latency:

50-200× 빠르다. 0.6B 모델조차 대부분 일반 LLM 보다 정확도가 높다 — task-specific specialization이 generalist 대비 압도적인 대목.

이는 MemPrivacy가 SFT + GRPO RL로 학습했기 때문 — GRPO가 precision-recall 균형을 reward로 직접 최적화. SFT만으로는 도달 못 한다는 ablation도 같이 제공.

4.5. 유틸리티 손실의 정직한 펼침

MemPrivacy를 LangMem·Mem0·MemoBase 세 메모리 시스템 위에 얹어 측정:

Raw masking은 메모리 시스템을 사실상 무용지물로 만든다(-26~42%). MemPrivacy는 동등 보호 수준에서 -1.6% 이내. 프라이버시-유틸리티 트레이드오프가 정직히 풀린 대목.

4.6. 카테고리 위치 — governance 자리와의 만남

MemPrivacy가 단지 프라이버시 도구가 아니라 governance 카테고리와 만나는 지점임을 의식해야 한다. Agent Governance 카테고리가 정리한 audit·approval·compliance 표면이 영속 메모리에서 다시 등장하는 대목. 운영자 도메인(ECC의 healthcare·logistics·finance 스킬 군집)에서 메모리가 PII·PHI·금융 정보를 누적할 때 MemPrivacy 같은 mediation layer가 필요하다는 점을 측정으로 보여줌.

5. 셋이 측정하지 않는 자리 — 카테고리의 빈 부분

세 벤치가 직교한다는 점이 합집합의 가치를 키운다고 §1에서 말했다. 그렇다면 셋이 모두 다루지 않는 곳은 어디인가. 카테고리의 현재 빈 표면적이 여기서 드러난다.

5.1. 다중 사용자 공유 메모리 — 없음

세 벤치 모두 단일 사용자 시나리오. 그러나 gstack의 도메인 스킬 promote-to-global이나 ECC의 /instinct-export·/instinct-import 같은 사용자 간 공유 메커니즘은 각자의 신뢰도 가중이 다른 환경에서도 유효한지가 핵심 질문. 측정 도구 없음.

5.2. 편집·revert 워크플로 — 없음

사용자가 메모리를 직접 편집·삭제·revert하는 워크플로의 정확성. Anthropic Memory tool은 파일 단위 편집 가능하지만 편집 후 일관성은 측정되지 않는다. MEME가 Deletion task를 다루지만 시스템이 자동 처리하는 삭제만 측정 — 사용자 주도 편집은 빈 곳.

5.3. 시간 decay 정확성 — 부분만

ECC instinct의 신뢰도 decay나 GSD .planning/의 milestone closure 같은 시간 기반 메모리 약화 메커니즘이 어떤 정보를 언제 약화시켜야 하는지. MEME가 Tracking·Deletion으로 명시적 변화는 다루지만 시간만으로 약화되어야 하는 정보(e.g. "이 사용자가 작년에 좋아했던 라이브러리")는 빈 지점.

5.4. 팀 수준 일관성 — 없음

gstack team-mode나 ECC GitHub App(150+ install) 같은 팀 도입 시나리오에서 팀원 간 메모리 동기화·충돌 해소. 어느 사용자의 instinct가 정본인가, 팀 위키 vs 개인 메모리의 우선순위. MemPrivacy가 개인 보호를 다루지만 팀 공유 vs 개인 보호의 균형은 빈 영역.

5.5. vertical 도메인 특화 평가 — 없음

운영자 워크플로(ECC vertical 스킬 §3.2)에서 healthcare HIPAA·finance PII·customs trade compliance의 도메인 특화 메모리 평가. LongMemEval-V2는 WebArena·WorkArena 일반 환경, MEME는 Personal Life·Software Project, MemPrivacy는 일반 PII — 규제 도메인 vertical 평가는 빈 부분.

이 다섯 곳이 다음 6개월 메모리 카테고리의 측정 도구 후속에 등장할 것 같은 대목. 벤치의 동시 등장이 카테고리 형성을 알린다면, 벤치 사이의 빈 곳이 다음 진입을 알린다.

6. 셋의 종합 — 측정의 분담 표

세 벤치를 측정 대상의 분담으로 정리하면:

세 측정의 공통 시사점:

1. 메모리 시스템마다 강한 부분이 다르다. coding agent가 LongMemEval에서 강하지만 MEME에서는 MD-flat이 가장 강함. 즉 능력 축마다 best system이 다르다 — single-best memory system은 존재하지 않는다.
2. frontier LLM에 의존하지 않는 specialized 메모리 모델이 등장 중. MemPrivacy 4B-RL이 그 첫 사례 — task-specific하게 학습된 작은 모델이 generalist를 압도. 카테고리가 메모리 task만 잘 하는 모델 학습이 의미 있는 단계에 도착했다는 신호.
3. 비용-정확도 trade-off가 정직히 노출됨. 코딩 에이전트 메모리 컨트롤(LongMemEval-V2 AgentRunbook-C: 6.9× 비용), Opus 4.7 active propagation(MEME: 70× 비용), specialized 모델(MemPrivacy: 50-200× 더 빠름). 메커니즘마다 비용 표면이 다르다.

7. 종합 — 측정 도구가 등장했다는 사실 자체가 카테고리 신호다

세 줄로 줄이면:

1. 세 벤치가 같은 한 주에 등장했다는 사실이 카테고리 형성 신호다. LongMemEval-V2(5/13)·MEME(5/13)·MemPrivacy(5/10) — 자연발생적 동시성이 아니라 학계가 메모리를 별도 도메인으로 인정하기 시작했다는 첫 객관적 증거. Agent Framework 카테고리가 4개 메타프레임의 동시 진입으로 형성됐듯, Agent Memory 카테고리는 3개 벤치의 동시 등장으로 측정 가능 단계에 도달.
2. 셋이 서로 다른 빈 곳을 메운다 — 직교 측정. LongMemEval-V2는 환경 경험 누적, MEME는 의존성 추론, MemPrivacy는 프라이버시-유틸리티 균형. 셋의 교집합은 작지만 합집합은 카테고리의 현재 표면적을 정의한다. 메타프레임의 메모리 메커니즘(Superpowers·GSD·gstack·ECC)을 어느 벤치 위에서 측정해야 하는지가 이제 분리되어 있다.
3. 셋이 모두 깨지는 지점을 발견했다. LongMemEval-V2의 Environment Gotchas 48.3%, MEME의 Cascade 3% · Absence 1%, MemPrivacy의 raw masking 26-42% utility loss. 벤치의 정직성이 메모리 시스템의 한계를 surface하고, 다음 메커니즘이 들어갈 지점을 가리킨다.

운영 결론: 메타프레임을 도입할 때, 어느 측면을 평가받아야 하는지가 벤치로 분리되어 있음을 의식. 환경 작업이 많은 사용이면 LongMemEval-V2에서 잘 동작하는 시스템(coding agent + scaffolding) 우선. 다중 엔티티 의존성 추론이 필요한 도메인(예: 프로젝트 관리·관계형 데이터)이면 MEME가 발견한 70× 비용 함정 의식. PII/PHI를 다루는 vertical이면 MemPrivacy 같은 typed placeholder mediation layer가 raw masking을 대체해야 함. 벤치마크는 마케팅 클레임을 검증할 도구이지 카테고리를 정의하는 본체가 아니다 — 단, 세 벤치가 같은 한 주에 등장했다는 사실이 카테고리가 객관 측정 가능 단계에 진입했음을 명확히 한다.

한 줄 추천 — 메모리 시스템을 평가받아야 한다면, 자기 작업의 축이 셋 중 어디에 가까운지부터 물어라. 환경 경험 누적(LongMemEval-V2)·의존성 추론(MEME)·프라이버시 균형(MemPrivacy) 셋이 서로 다른 망각을 측정한다. 같은 메모리 시스템이 셋 모두에서 강할 가능성은 작다. 벤치 선택이 곧 메모리 평가의 첫 결정이다 — 이 글은 그 결정의 세 좌표를 깐다.

참고

1차 자료

• LongMemEval-V2 paper — UCLA, Di Wu et al., 2026-05-13
• LongMemEval-V2 project site — dataset · code · leaderboard
• MEME paper — KAIST + 튀빙겐 + NAVER, Seokwon Jung et al., 2026-05-13
• MEME project site — code · data
• MemPrivacy paper — MemTensor + Tongji, Yining Chen et al., 2026-05-10
• MemPrivacy GitHub — code · models · MemPrivacy-Bench
• MemPrivacy models on HuggingFace

카테고리 인덱스 + 시리즈

• Agent Memory 카테고리 — 4축(Capture·Storage·Retrieval·Lifecycle) 분해
• Agent Framework 시리즈 — 4 프레임의 메모리 메커니즘이 박혀있는 글들
• Agent Governance 카테고리 — 영속 메모리의 거버넌스·감사 표면

이전 벤치 (V2가 확장한 자리)

• LongMemEval V1 (NAACL 2025) — Di Wu et al., 대화형 메모리 측정
• RULER · LoCoMo · MemBench — MEME 표 1의 비교 대상