MemFail Paper review
MemFail: Stress-Testing Failure Modes of LLM Memory Systems
https://arxiv.org/abs/2605.26667
MemFail은 UC Berkeley에서 만든 메모리 시스템 진단 벤치마크이다.
메모리 시스템을 요약·저장·검색 세 연산으로 나눠서, 틀린 답이 어느 단계에서 나왔는지 찾아낸다.
2026년 5월 26일에 나왔고, 저자 4명에 42쪽이다.
앞의 열여섯 편에서는 시스템들이 얼마나 잘하는지를 봤다. 이 논문은 어디서 실패하는지를 본다.
기존 벤치마크는 QA 정확도를 합쳐서만 보고하고 메모리 시스템을 블랙박스로 다룬다고 한다. 그래서 틀린 답이 시스템의 어떤 실패 때문인지 알 수가 없다는 것이다.
앞에서 본 Anatomy 리뷰가 평가가 제대로 된 건지를 따졌다면, 이 논문은 진단 도구를 만든다.
좀 더 자세히 알아보자.
1. 세 연산과 네 실패 모드
메모리 시스템을 요약(summarization), 저장(storage), 검색(retrieval) 세 연산을 이어 붙인 것으로 본다.
연산마다 나오는 실패가 있다.
- Summary failure : 요약하다가 중요한 정보를 지우거나 망가뜨린다
- Storage failure : 새 정보를 제대로 반영하지 못한다
- Retrieval failure : 관련 메모리를 못 꺼내거나, 의미는 비슷하지만 맥락상 안 맞는 걸 꺼낸다
- Reasoning failure : 맞는 메모리를 꺼냈는데도 판단을 틀린다
1번 예시로 “I am deathly allergic to peanuts”가 “allergic to peanuts”로 압축되는 경우를 든다. 뒤에서 추론할 때 필요한 심각도가 빠진다.
사실은 남았는데 정도가 사라진 것이다. 땅콩 알레르기가 있는 건 맞지만 “죽을 수도 있다”가 빠졌다.
2번은 두 가지다.
- 오래된 사실을 안 덮어씀 : 사용자가 “Dan은 이제 피자를 싫어한다”고 했는데 “Dan likes pizza”를 그대로 둔다
- 같이 있어도 되는 사실을 거절 : “Dan likes burgers”를 저장된 “Dan likes pizza”와 모순이라고 보고 안 넣는다
두 번째가 앞에서 본 Mem0 리뷰의 DELETE 위험이다. 모순이라고 판단한 게 틀렸을 때 생긴다.
4번은 메모리 시스템의 실패가 아니라서 참고용으로 재기만 한다고 한다.
기존 연구는 긴 대화 이력을 넣고 사용자 성격이나 선호를 추론하게 하면서, 이 네 가지를 섞어서 평가하고 구분하지 않았다고 한다.
2. 다섯 데이터셋, 네 과제
과제마다 실패 모드 하나를 일부러 노린다.
Task 1: Conditional-Facts
요약 실패를 노린다.
“엔티티 E는 조건 C를 만족할 때만 행동 B를 한다”는 규칙을, 같은 엔티티에 대한 상관없는 무조건 사실 4~7개와 함께 5~8문장 에세이에 넣는다.
질문은 특정 상황 X에서 E가 B를 할지 묻는다. 요약하면서 C를 빼고 “E does B”로 저장한 시스템은 X와 상관없이 “예”라고 답한다.
변형이 두 개다.
- Easy : 규칙 전체가 한 문장에 있다. 문장을 그대로 복사하는 시스템은 맞힌다
- Hard : 규칙을 떨어진 세 문장(행동 문장, 조건 문장, 연결 문장)으로 쪼개서 8~12문장 에세이에 흩어놓는다
Easy와 Hard가 같은 엔티티와 조건을 쓴다. 그래서 성능 차이는 규칙이 흩어진 방식 때문이라고 볼 수 있다.
예시(Easy) : “Sylas는 협상을 막 끝냈을 때만 정교한 지도를 그린다.”
질문 : “Sylas가 방금 조용히 명상을 했고 협상은 안 했다. 지금 정교한 지도를 그릴까?”
정답 : 아니오
Task 2: Coexisting-Facts
저장 + 검색 실패를 노린다.
요즘 메모리 시스템은 들어오는 정보를 기존 DB와 적극적으로 맞추는데, 같이 있어도 되는 두 사실(“사용자는 피자를 좋아한다”, “사용자는 라멘을 좋아한다”)을 모순으로 보고 이전 사실을 덮어쓰는 실패가 생길 수 있다고 한다.
100개 선호 범주에서 범주마다 N ∈ {2,3,4,5}개 선호를 각각 따로 된 1인칭 문장으로 넣고, N개가 전부 필요한 질문을 던진다.
예시 : 모자 스타일. “페도라를 즐겨 쓴다”, “비니가 추운 날 기본”, “버킷햇은 화창한 주말용”.
질문 : “날씨가 뒤섞인 일주일 여행을 싸는데, 모든 경우를 커버하려면 어떤 모자를 가져가야 할까?”
정답 : 페도라, 비니, 버킷햇
Task 3: Persona-Retrieval
저장 실패를 노린다.
다른 사람에 대해 물었을 때 엉뚱한 프로필을 꺼내오는지 본다. 이름 있는 엔티티 E에 대한 10~15문장 에세이에 특이한 사실 4~5개를 넣고, 질문을 두 가지로 50/50 섞는다.
- 직접 질의 : E를 지목한다. 에세이 내용으로 답할 수 있다
- 오도 질의 : 상관없는 인물 D를 지목한다. 모른다고 하는 게 정답이다
예시 : 에세이에 Yuki Tanaka가 갑각류를 안 먹는다고 나온다.
오도 질의 : “Noah Brooks는 갑각류를 먹나?” → “정보가 없다”
앞에서 본 SYNAPSE 리뷰의 “dog 질의가 의미적으로 가까운 Rex와 매칭돼 환각”과 같은 실패를 재는 것이다.
Task 4: Long-Hop
검색 실패를 노린다.
K ∈ {1,2,3} 홉짜리 이어지는 사슬을 만든다. 기분, 루틴, 의견, 개인 물건처럼 주관적인 것들이라 세계 지식만으로는 답할 수 없다.
평가할 때 각 사실을 메모리 시스템에 하나씩 따로 준다고 한다. 그래야 한 대화에서 읽는 게 아니라 흩어진 저장소에서 사슬을 찾아서 이어야 한다.
예시(K=3) : “아침 에스프레소를 마시면 엄마에게 전화한다” / “엄마에게 전화한 뒤엔 당일치기를 계획한다” / “당일치기를 계획하면 간식을 챙긴다” / “간식을 챙기면 풍경 사진을 찍는다”
질문 : “아침 에스프레소를 마시면 [결국 무엇을 하나]?”
3. 평가 설계
Mem0, A-MEM, SimpleMem, StructMem 네 시스템을 평가한다.
세 함수만 노출하면 평가할 수 있게 만들었다고 한다.
store_conversation(H)
retrieve_memories(Q, H, k)
get_all_memories()
-> 본문에서는 앞의 두 개만 설명하고, get_all_memories는 뒤에 평가 대상 시스템 얘기할 때 나온다.
답하는 모델과 채점 모델은 gpt-5-mini로 고정한다. 메모리 시스템 내부 모델이 아니라 메모리를 받아서 답하는 LLM이다. 그래서 시스템 간 차이는 메모리 시스템 때문이라고 볼 수 있다.
채점도 검증했다. 사람이 채점한 100개 예시에서 gpt-5-mini가 98%를 맞혔고, 오류 유형은 98.4% 맞게 분류했다고 한다.
4. 결과
Q1: 검색 개수 k를 늘리면?
MEMFAIL은 최신 시스템에도 어렵고, k를 늘려도 성능이 잘 안 오른다고 한다. Coexisting-Facts만 예외인데, 많이 꺼내면 같이 있는 사실이 우연히라도 걸릴 확률이 커지기 때문이다.
과제별로 실패가 갈린다.
- Coexisting-Facts : 검색 실패. 대부분 시스템이 관련 사실을 전부 질문과 연결하지 못한다
- Conditional-Facts (Hard) : 요약 실패. 모든 시스템이 너무 많이 압축한다. 원래 메시지를 바꾸거나 세부를 빼버린다
- Persona-Retrieval : 요약 실패(긴 페르소나를 과하게 압축). Mem0만 예외인데, LLM 도구 호출로 갱신하는 방식이라 처음부터 세부를 다 저장하지 못한다
- Long-Hop : 검색 실패. 멀어 보이는 엔티티 사이의 인과 관계를 못 잡는다
Mem0 말고는 저장 실패가 거의 없었다고 한다. 실패는 거의 다 요약이나 검색에서 나왔다.
검색 개수를 늘리면 검색 오류가 많은 과제에서는 오르고, 요약 오류가 병목이면 별로 안 오른다고 한다.
앞에서 본 MemMachine 리뷰에서는 k를 20→30으로 올리면 +4.2%p였는데, 그 이득도 어떤 실패가 병목이냐에 따라 달라진다는 것이다.
Q2: 더 좋은 모델을 쓰면?
더 강한 모델을 써도 정확도가 안 오르고, 대부분 과제에서 오히려 떨어지기도 한다고 한다. 더 똑똑한 추론 모델이 메모리를 너무 길게 만들어서 컨텍스트를 오염시킬 수 있다는 것이다.
다른 LLM 에이전트 분야는 모델이 좋아지면 벤치마크 성능도 오르는데, 메모리 시스템은 모델 성능이 아니라 구조에 묶여 있다고 한다.
앞에서 본 Anatomy 리뷰의 백본 민감도, NEMORI 리뷰의 “휴리스틱이 문제”와 이어진다. 모델을 바꿔서 풀리는 문제가 아니다.
Q3: 토큰을 더 쓰면?
요약 실패가 병목인 과제(Persona-Retrieval, Conditional-Facts Hard)에서는 토큰을 늘리면 성능이 오른다. 반대로 검색 과제는 토큰을 더 쓰면 떨어질 수도 있다고 한다.
Coexisting-Facts에서 특히 그런데, 메모리를 크게 저장하면 의미 임베딩이 “오염”돼서 검색이 나빠진다는 것이다.
토큰을 더 쓰면 성능이 오른다는 게 여기서는 안 맞는다.
그리고 A-MEM은 다른 시스템보다 토큰을 훨씬 많이 쓰는데 그만큼 성능이 안 나온다고 한다.
앞에서 본 A-MEM 리뷰에서는 토큰 효율이 좋다고 봤는데(1,200~2,500 vs MemGPT 16,900), 그건 질문할 때 넣는 컨텍스트 기준이었다. 여기서 말하는 건 메모리 자체 크기다. 두 수치가 다른 걸 잰 것이다.
5. 지금 관점: 도입 검증 체크리스트
네 과제를 그대로 테스트 케이스로 쓸 수 있을 것 같다.
- 조건부 사실 테스트 : “X일 때만 Y”를 저장하고 X가 아닌 상황을 묻는다. “심하게 알레르기”가 “알레르기”가 되는 종류라 제일 위험하다. 업무 쪽이면 “이 승인은 금액이 500만원 이상일 때만 필요하다” 같은 규칙이 여기 해당한다.
- 공존 사실 테스트 : 같은 범주 선호를 여러 개 따로 말하고 전부 필요한 질문을 던진다. Mem0의 DELETE나 Zep의 무효화가 모순이 아닌 걸 모순으로 보는지 확인한다.
- 오도 질의 테스트 : A에 대해 저장하고 B에 대해 묻는다. “모른다”가 정답이다. 앞에서 본 LongMemEval의 ABS, SYNAPSE의 거절 게이팅과 같은 얘기다.
- 다중홉 테스트 : 사슬의 각 고리를 따로따로 저장한다. 한 대화에 다 넣으면 의미가 없다.
-> k를 올릴지 토큰을 늘릴지는 요약 실패냐 검색 실패냐에 따라 반대라서, 병목이 어딘지부터 봐야 할 것 같다.
-> Q2를 보면 모델만 바꿔서 해결하려고 하면 안 될 것 같고, Q3을 보면 메모리를 크게 만들면 임베딩 오염으로 검색이 나빠질 수도 있다.
6. Conclusion
conclusion 부분을 보면, 지금 시스템들은 구조적인 제약에 묶여 있어서 토큰을 더 쓰거나 더 똑똑한 모델을 쓴다고 해결되지 않는다고 한다.
저자들이 아는 한 실패 모드를 세밀하게 분석할 수 있는 첫 벤치마크라고 하고, 3장의 API만 구현하면 어떤 메모리 시스템이든 평가할 수 있다고 한다. 데이터셋과 평가 코드도 공개했다.
한계도 적어뒀다. MEMFAIL 데이터셋은 전부 LLM으로 만들고(gpt-4.1-mini, gpt-5-mini, gpt-5) 걸렀다. 모든 항목을 사람이 확인했지만, 대화·엔티티·표현이 실제 서비스 환경보다 좁을 수 있다고 한다. 그래서 MEMFAIL 점수는 특정 실패에 대한 진단 신호로 봐야지 실제 성능 예측으로 보면 안 된다고 한다.
여태까지 메모리 벤치마크가 정확도 하나로 시스템을 비교했다면, 이 벤치마크는 틀린 답이 요약·저장·검색 중 어디서 나왔는지를 나눠서 본다.
-> 앞의 시스템 논문들이 다 좋은 수치를 냈는데, 그 수치 뒤에 어떤 실패가 있는지는 이런 걸로 봐야 할 것 같다. 도입할 거면 벤치마크 점수보다 이 네 테스트를 직접 돌려보는 게 나을 것 같다.
다음은 Janus다. 새 메모리를 바로 쓰지 않고 옛 메모리랑 비교해서 나은 쪽을 남기는 갱신 컨트롤러다.
Leave a comment