LongMemEval 83.2% 왜 이 숫자가 99%보다 의미 있는가

6번의 반복 실험이 리더보드 숫자보다 더 많은 것을 가르쳐줬습니다.

지난주, Supermemory라는 회사가 LongMemEval_S에서 약 99% 정확도를 달성했다는 블로그 포스트를 올렸습니다. 글은 순식간에 퍼졌고, 이후 그들은 포스트를 업데이트했습니다. 전체가 "사회적 실험"이었고, 현재 메모리 벤치마킹 문화가 얼마나 무의미해졌는지 보여주기 위한 패러디였다는 설명이었습니다.

그들의 지적은 맞았습니다. 그리고 저희는 그 문제를 몸으로 확인했습니다.

Nunchi AI에서 저희는 Nexus를 만듭니다. Nexus는 Synapsis 원자화 엔진 기반의 AI 에이전트 메모리 인프라입니다. 지난 한 주 동안 LongMemEval_S를 연구용 프로토타입이 아니라 실제 프로덕션 엔진에 돌렸습니다. 리더보드용 12-에이전트 앙상블이 아니라, 실제 API 트래픽을 처리하는 바로 그 엔진입니다.

최종 점수는 83.2%였습니다. 여기서는 그 숫자보다, 그 숫자에 도달하기까지의 과정이 왜 더 중요한지 이야기합니다.

LongMemEval이 실제로 테스트하는 것

LongMemEval_S는 ICLR 2025에서 발표된 500개 질문 벤치마크입니다. 각 질문에는 30개에서 50개의 대화 세션, 약 115K 토큰이 붙어 있고, 메모리 시스템은 이를 수집하고 인덱싱한 뒤 다시 검색해서 답해야 합니다. 이 벤치마크는 다섯 가지 핵심 능력을 평가합니다.

정보 추출: 단일 세션에서 특정 사실을 회수하는 능력
선호도 파악: 암묵적인 유저 취향을 이해하는 능력
멀티세션 추론: 여러 세션에 흩어진 사실을 종합하는 능력
시간 추론: 날짜 계산과 사건 순서를 다루는 능력
지식 업데이트: 오래된 정보가 새 정보로 대체되었음을 인식하는 능력

이 벤치마크가 어려운 이유는, 50개 세션 중 정답이 1개에서 3개 세션에만 숨어 있는 경우가 많고, 질문도 의도적으로 간접적이기 때문입니다. 일부는 여러 세션에 걸친 카운트, 비교, 날짜 계산을 요구합니다.

v1 기준선: 76.8%

LongMemEval 세션을 프로덕션 Synapsis 파이프라인에 그대로 투입했습니다. 대화, 원자화, 벡터 저장, 코사인 유사도 검색, LLM 답변 생성의 순서였습니다.

v1 점수는 다음과 같았습니다.

정보 추출 (유저): 95.7%
정보 추출 (어시스턴트): 98.2%
선호도 파악: 66.7%
멀티세션 추론: 66.9%
시간 추론: 66.2%
지식 업데이트: 83.3%
전체: 76.8%

단일 세션 추출 점수가 높았다는 것은 핵심 검색 엔진이 작동한다는 뜻이었습니다. 반대로 낮은 카테고리들은 어디를 봐야 하는지 알려줬습니다.

v2 과잉 엔지니어링의 재앙: 60.8%

진단에 확신을 갖고 모든 것을 한꺼번에 넣었습니다. 멀티쿼리 분해와 RRF, 시간 가산점, 오래된 atom 삭제 로직, 쿼리 확장, 날짜순 재정렬까지 들어갔습니다.

결과는 60.8%였습니다. 시간 추론은 66.2%에서 12.8%로 무너졌고, 지식 업데이트는 83.3%에서 57.7%로 떨어졌습니다.

원인은 세 가지였습니다.

시간 가산점이 검색 랭킹에 시간 근접도를 주입하면서, 단순히 최근인 atom이 실제로 관련 있는 atom보다 위로 올라왔습니다.
지식 삭제 로직이 오래된 atom을 제거해 최신 정보만 남겼지만, 벤치마크는 옛 정보와 새 정보를 함께 보고 어느 쪽이 현재인지 판단해야 했습니다.
날짜순 재정렬이 컨텍스트 윈도우 내부 순서를 바꿔 관련 있는 atom을 토큰 한도 밖으로 밀어냈습니다.

교훈은 명확했습니다. 검색 순서를 건드리면 안 됩니다.

v4 정교한 실패: 72.4%

조금 더 원칙적인 접근도 시도했습니다. 검색, 증거 패킹, 답변의 3단계 파이프라인을 만들고, 카테고리별 패킹 전략도 넣었습니다. 라운드로빈 세션 다양성, GPT-4o-mini 선호도 요약, 상위 20개 최신순 재정렬도 적용했습니다.

구조는 우아했지만 결과는 72.4%였습니다. v1보다 낮았습니다.

문제는 비슷했습니다.

atom 순서를 재배치하는 모든 패킹 전략이 점수를 떨어뜨렸습니다.
선호도 요약 레이어는 원시 atom이 갖고 있던 정보를 잃었습니다.
라운드로빈 다양성은 높은 관련도의 atom 대신 낮은 관련도의 atom을 넣었습니다.

메모리 검색의 세 가지 법칙

v4까지 실험하면서 세 가지 규칙이 분명해졌습니다.

Atom을 삭제하지 말 것. 정답이 신구 정보 비교를 요구할 수 있습니다.
Atom 순서를 바꾸지 말 것. 코사인 유사도 랭킹이 LLM 리더에게 가장 좋은 컨텍스트 배치입니다.
유사도 외의 신호를 검색 점수에 주입하지 말 것. 시간, 최신성, 신선도는 랭킹 함수 밖에 둬야 합니다.

이것들은 단지 벤치마크 팁이 아니라, 프로덕션 엔진 설계 제약조건이 되었습니다.

v5 프롬프트만 변경: 80.6%

세 가지 법칙을 받아들이고, 검색은 v1 그대로 되돌린 뒤 프롬프트만 바꿨습니다.

선호도 파악 프롬프트를 바꾸자 66.7%에서 90.0%로 올랐습니다.
지식 업데이트 프롬프트를 바꾸자 83.3%에서 91.0%로 올랐습니다.
시간 추론에 question_date를 기준점으로 명시하자 66.2%에서 72.9%로 올랐습니다.

전체 점수는 80.6%가 됐습니다. 검색 변경도, 아키텍처 변경도 없었습니다. LLM 리더에게 더 좋은 지시를 준 것뿐이었습니다.

v6 읽기 오류 수정: 83.2%

남은 멀티세션 오답을 분석해 보니, 46개 오답 중 20개에서 같은 패턴이 보였습니다. LLM이 필요한 atom은 이미 다 가지고 있었지만, 카운트를 중간에 멈췄습니다. 정답이 4인데 "최소 3개"라고 답하거나, 리스트 마지막 항목을 빠뜨리거나, 확정 대신 헤지했습니다.

수정은 프롬프트 한 줄이었습니다.

답변 전에 모든 메모리를 스캔하고 관련 항목을 전부 번호 매긴 리스트로 추출한 뒤, 전체 리스트를 세고 정확한 숫자로 답하라고 지시했습니다. "최소"라고 말하지 말라고도 명시했습니다.

그 결과 멀티세션은 65.4%에서 76.7%로 뛰었고, 전체는 83.2%가 됐습니다.

v5와 v6를 비교하면 어디서 개선이 일어났는지가 더 분명하게 보입니다.

카테고리	v5	v6	변화
Info Extraction (User)	94.3%	95.7%	+1.4
Info Extraction (Asst)	98.2%	100.0%	+1.8
Preference Recall	90.0%	83.3%	-6.7
Multi-Session	65.4%	76.7%	+11.3
Temporal Reasoning	72.9%	72.2%	-0.7
Knowledge Update	91.0%	89.7%	-1.3
Task-Averaged	85.3%	86.3%	+1.0
Overall	80.6%	83.2%	+2.6

v6 최종 점수 자체는 다음과 같습니다.

정보 추출 (유저): 95.7%
정보 추출 (어시스턴트): 100.0%
선호도 파악: 83.3%
멀티세션 추론: 76.7%
시간 추론: 72.2%
지식 업데이트: 89.7%
전체: 83.2%

83.2%가 실제로 의미하는 것

이 숫자가 무엇이고 무엇이 아닌지 분명히 말씀드리겠습니다.

이 숫자는 실제 API 트래픽을 처리하는 동일한 Synapsis 파이프라인을, 가장 엄격한 공개 장기 메모리 벤치마크에서, GPT-4o를 답변 생성기와 채점기로 사용해 평가한 결과입니다.

반대로 이 숫자는, 이 특정 벤치마크만을 위해 최적화한 연구용 프로토타입 점수가 아닙니다. 저희는 12-에이전트 앙상블을 만들지 않았고, 여러 프롬프트 변형 중 최선의 답만 고르지도 않았고, 프로덕션에 배포하지 않을 기법을 쓰지도 않았습니다.

비교를 위해 다른 시스템들의 LongMemEval_S 결과를 보면 다음과 같습니다.

Mastra (Observational Memory): 95%, GPT-4o 기준. 연구 아키텍처이며 아직 프로덕션 API는 아닙니다.
Emergence AI: 86%, GPT-4o 기준. RAG 기반이고 레이턴시는 5.65초입니다.
Supermemory (ASMR): 약 99%, 자체 인정한 패러디이며 검색 1건당 12개 병렬 에이전트를 사용했습니다.
Supermemory (프로덕션): 멀티세션 71.4%, 시간 추론 76.7%. 실제 엔진의 공개 카테고리별 점수입니다.
TiMem: 76.88%, GPT-4o-mini 기준
Zep/Graphiti: 71.2%, GPT-4o 기준
Long-context GPT-4o, 메모리 없음: 약 60%

저희의 83.2%는 프로덕션 실용 시스템 중 상위권에 해당합니다. 그리고 남은 16.8%가 어디에 있는지도 알고 있습니다. 멀티세션 검색과 시간 추론입니다. 둘 다 멀티쿼리 검색과 앵커 기반 키워드 회수 같은 명확한 해결책이 있는 엔지니어링 문제입니다.

답변 모델이 왜 이렇게까지 중요한가

v6 결과를 확정한 뒤, 동일한 검색 파이프라인과 프롬프트를 세 개의 다른 LLM으로 돌렸습니다. 같은 atom, 같은 컨텍스트 순서, 같은 지시문이었고 리더 모델만 바꿨습니다.

카테고리	n	GPT-4o	GPT-4o-mini	GPT-OSS-120B (Groq)
정보 추출 (유저)	70	95.7%	95.7%	95.7%
정보 추출 (어시스턴트)	56	100.0%	100.0%	98.2%
선호도 파악	30	83.3%	80.0%	43.3%
멀티세션 추론	133	76.7%	62.4%	25.6%
시간 추론	133	72.2%	57.1%	64.7%
지식 업데이트	78	89.7%	80.8%	82.1%
전체	500	83.2%	73.8%	63.8%

패턴은 선명했습니다. 단순 사실 추출은 모델에 거의 무관했습니다. 세 모델 모두 단일 세션 검색에서는 95% 이상을 기록했습니다. 차이는 복잡한 지시를 얼마나 안정적으로 따르느냐에서 벌어졌습니다.

GPT-4o-mini는 전체가 9.4%p 하락했고, 가장 큰 낙폭은 멀티세션과 시간 추론에서 나왔습니다. 정확히 v6 프롬프트가 "모든 항목을 나열한 뒤 세라", "이 기준점에서 날짜를 계산하라"라고 요구하는 카테고리입니다. mini는 이 지시를 덜 안정적으로 따랐습니다.

GPT-OSS-120B는 멀티세션에서 25.6%로 붕괴했습니다. atom이 컨텍스트 안에 존재하는데도 모델이 열거하지 못하는 카테고리입니다. 총 117B 파라미터 가운데 포워드 패스당 5.1B만 활성화되는 구조라, 단순 추출은 잘하지만 긴 컨텍스트에서 복잡한 다단계 카운팅을 유지하지 못합니다. 선호도 파악 43.3%도 같은 이야기입니다. 흩어진 증거에서 암묵적 패턴을 종합하는 작업이 활성 파라미터 예산을 넘어서는 것입니다.

여기서 두 가지 결론이 나옵니다.

벤치마킹 측면에서, 답변 모델을 공개하지 않은 LongMemEval 점수는 의미가 약합니다. 같은 검색 엔진이 어떤 LLM이 컨텍스트를 읽느냐에 따라 83.2%도, 63.8%도 나옵니다. 결과를 보고하는 시스템은 최종 답변을 생성하는 모델을 정확히 명시해야 합니다.

프로덕션 측면에서, 메모리 검색은 필요조건이지 충분조건이 아닙니다. 리더 모델이 천장입니다. 검색이 병목이 아닐 때까지 검색에 투자하고, 그 다음에는 답변 모델이 제약조건이 됩니다. Nexus의 단일 세션 추출이 95~100%인 것은 단순 쿼리에서는 검색이 이미 천장에 도달했음을 시사하고, 남은 개선 여지는 이미 검색된 것을 리더가 얼마나 잘 추론하느냐에 달려 있습니다.

정직한 벤치마킹 매니페스토

Supermemory의 사회적 실험은 실제 문제를 드러냈습니다. 메모리 벤치마크가 게임화되고 있다는 점입니다. 앙상블 기법, 프롬프트 변형 선택, 연구 전용 파이프라인이 프로덕션 품질과 무관한 숫자를 만들어내고 있습니다.

그래서 LongMemEval 결과를 보고할 때 최소한 다음 기준이 필요하다고 생각합니다.

시스템이 프로덕션인지 연구 전용인지 명시할 것
전체 점수뿐 아니라 모든 카테고리 점수를 공개할 것
답변 생성 모델을 공개할 것
반복 실험 이력을 공개할 것

저희가 v2의 60.8%, v4의 72.4% 같은 실패를 숨기지 않는 이유도 여기에 있습니다. 최종 숫자보다 더 많은 통찰이 그 실패 과정에 들어 있기 때문입니다.

메모리 레이어는 AI 에이전트의 다음 핵심 인프라입니다. 툴과 에이전트 협업만큼 중요합니다. 그 인프라는 정직한 측정을 받을 자격이 있습니다.

LongMemEval 자체는 LongMemEval GitHub 저장소에서 볼 수 있습니다. Nexus는 AMCP, Agent Memory Continuity Protocol을 구현하는 메모리 엔진입니다. 자세한 내용은 Nexus에서 확인하실 수 있습니다.

Nexus v6 LongMemEval_S 결과: 전체 83.2%, 테스트 시점 2026년 3월. 엔진 버전: Synapsis 프로덕션. 답변 모델: GPT-4o. 채점 모델: GPT-4o, LongMemEval 기본 설정.