2026년 AI 메모리의 현황: 주장된 수치 vs 관찰된 수치

AI 메모리는 현재 AI 툴링 스택(tooling stack)에서 가장 많이 벤치마크(benchmark)되지만, 가장 재현이 안 되는 카테고리입니다. 벤더(Vendors)들은 높은 수치들을 발표합니다. 이 수치들은 Twitter 스레드와 컨퍼런스 발표 자료, 그리고 "에이전트 인프라스트럭처 (agent infrastructure)" 랜딩 페이지를 통해 퍼져 나갑니다. 실제로 그 수치가 재현되는지 확인하기 위해 직접 하네스(harness)를 실행하는 사람은 거의 없습니다. 저희는 직접 했습니다.

이 포스트는 그 작업의 결과물입니다. 이는 2026년에 경쟁하고 있는 AI 메모리 벤더들의 지형도이며, 이 분야가 수렴한 두 가지 벤치마크(LongMemEval 및 LoCoMo)에 대한 탐방이자, 각 벤더가 발표한 내용과 저희가 오픈 하네스(open harness)에서 동일한 평가를 재실행했을 때 관찰된 내용을 나란히 비교한 것입니다. 재현을 완료한 부분에서는 두 수치를 모두 인용했습니다. 완료하지 못한 부분은 명확하게 밝힙니다. 하네스는 오픈 소스(open-source)입니다. 더 큰 재현 격차를 설명하는 상세한 감사 노트는 마지막에 링크되어 있습니다.

이 글은 긴 읽을거리입니다. 지름길 버전은 6개 섹션 아래에 있는 결과 테이블에 있습니다. 만약 "AI 메모리의 현황" 검색을 통해 이곳에 오셨다면, 당신이 실제로 원했던 것은 바로 그 테이블일 것입니다.

2026년에 메모리가 병목 현상(bottleneck)인 이유

백만 토큰 컨텍스트 윈도우(context window) 경쟁은 메모리 문제를 해결하지 못했습니다. 대신 비용을 이동시켰을 뿐입니다. 이제 단일 프롬프트(prompt)에 백만 토큰을 밀어 넣을 수 있으며, 이는 메모리가 불필요해질 것처럼 들리지만, 잘 문서화된 두 가지 실패 모드 (failure modes)는 프로덕션 규모(production scale)에서 그러한 약속을 막연한 희망 사항으로 바꿔 놓습니다.

컨텍스트 부패 (Context rot)는 긴 컨텍스트 창 (long windows)의 약속을 무너뜨립니다. 컨텍스트가 채워짐에 따라, 어텐션 (attention) 품질은 단순히 가장자리뿐만 아니라 전체 시퀀스(sequence)에 걸쳐 저하됩니다. 8K 토큰의 컨텍스트에서는 깔끔하게 답변하던 동일한 모델이, 800K 토큰의 대화 기록이 주어지면 환각 (hallucinate)을 일으키거나, 스스로 모순된 말을 하거나, 불필요하게 확답을 피하게 됩니다. 최근의 여러 평가(Chroma의 컨텍스트 부패 연구, 2023년 이 연구 흐름을 시작한 'lost-in-the-middle' 연구, 그리고 대부분의 프런티어 모델 (frontier model) 제품군에 대한 후속 연구들)는 긴 컨텍스트 (long context)가 집중된 컨텍스트 (focused context)와 동일하지 않음을 확인해 줍니다.

'Lost-in-the-middle' 현상은 이 문제를 더욱 악화시킵니다. 모델의 크기나 윈도우 길이 (window length)에 관계없이, 긴 프롬프트 (prompt)의 중앙에 배치된 정보는 시작 부분이나 끝부분에 있는 정보보다 일관되게 낮은 정확도로 검색됩니다. 수 주간의 대화 기록을 축적한 에이전트 (agent)에게 이는 사용자의 선호도, 이전의 약속, 이전 에스컬레이션 (escalation)의 해결책과 같은 중요한 사실들이 검색 성능이 가장 낮은 컨텍스트 영역에 일상적으로 놓이게 된다는 것을 의미합니다.

따라서 메모리 레이어 (memory layers)가 존재하는 이유는 컨텍스트 창 (context window)이 상태 유지 동작 (stateful behavior)을 위한 잘못된 추상화 (abstraction)이기 때문입니다. 기억력이 있는 에이전트라면 사용자가 간결한 답변을 선호하고, 결제 [컴플라이언스 (compliance)] 분야에서 일하며, 시리즈 B SaaS 기업을 운영하고, 2주 전에 SOC 2 통제 항목에 대해 물어봤다는 사실을 상기하기 위해 전체 대화 기록을 다시 읽어야 해서는 안 됩니다. 메모리 레이어는 적절한 스코핑 프리미티브 (scoping primitives)와 적절한 추상화 수준에서, 필요한 시점에, 중요한 정보만을 검색하도록 설계되어야 합니다.

스코핑 (Scoping)은 그 자체로 미묘한 문제입니다. B2B 환경에서는 동일한 회사의 두 사용자가 조직적 컨텍스트(회사가 선호하는 어휘, 내부 프로세스, 이전 지원 이력, 구성 선택 사항 등)를 공유해야 하는 동시에, 개인적인 수준에서는 격리된 상태를 유지해야 합니다. 모든 사용자를 하나의 고립된 섬으로 취급하는 메모리 레이어 (memory layer)는 명백한 B2B 가치를 놓치게 되며, 모든 것을 하나로 통합하는 메모리 레이어는 명백한 개인정보 보호 및 개인화 요구 사항을 놓치게 됩니다. 2026년의 흥미로운 과제는 이 두 가지를 동시에 처리할 수 있는 스코핑 프리미티브 (scoping primitives)를 구축하는 것입니다.

2026년 현재, 이는 더 이상 희망 사항이 아닙니다. 메모리는 우리가 살펴본 모든 진지한 에이전트 (agent) 제품의 핵심 경로 (critical path)에 있습니다. 세션 전반에 걸쳐 개인화되는 코파일럿 (copilots), 티켓 간의 이력을 유지하는 고객 지원 에이전트, 각 사용자와 장기적인 컨텍스트를 구축하는 소비자용 채팅 앱, 그리고 지난 화요일에 무엇을 했는지 기억해야 하는 내부 도구 에이전트 등이 그 예입니다. 병목 현상은 실재합니다. 이를 해결하기 위해 경쟁하는 벤더 (vendors)들도 실재합니다. 이 분야가 진보를 측정하기 위해 사용하는 벤치마크 (benchmarks)도 실재합니다. 발표된 수치들은 별개의 문제이며, 바로 이 지점이 이 포스트가 제 역할을 하는 부분입니다.

벤더 맵 (The vendor map)

에이전트-메모리 (agent-memory) 지형은 명확하게 세 가지 카테고리로 나뉩니다. (ChatGPT Memory나 Maximem의 자체 제품인 Vity와 같은 개인 및 소비자용 메모리 제품은 서로 다른 벤치마크와 구매자를 가진 별도의 시장이며, 이 포스트의 범위에서는 제외됩니다.)

카테고리 1: 전용 오픈 소스 (open-source) 메모리 라이브러리. Mem0의 OSS 레이어 (생태계 견인력이 가장 높은 것), Letta (Berkeley에서 나온 MemGPT 연구 라인의 후계자), Cognee (온톨로지 (ontology) 기반이며 포지셔닝이 약간 더 학술적임). 이것들은 사용자가 직접 설치하고 실행하는 제품들입니다. 트레이드오프 (trade-off)는 운영 측면에서 발생합니다. 즉, 런타임 (runtime), 스토리지 (storage), 업그레이드, 온콜 (on-call)을 직접 책임져야 합니다. 장점은 이식성 (portability)과 완전한 제어권입니다.

두 번째 카테고리: 전용 호스팅 메모리 제품 (dedicated hosted memory products). Mem0 Cloud, Zep (그래프 구조 메모리 (graph-structured memory) 분야에서 가장 성숙함), SuperMemory (B2B 지향적이며, 사례 연구에서 고객 지원 비중이 높음), 그리고 Synap (Maximem이 구축한 제품; 멀티 테넌트 스코핑 프리미티브 (multi-tenant scoping primitives)를 갖춘 구조화된 장기 메모리)가 있습니다. 이 세그먼트는 현재 가장 활발한 상업적 경쟁이 벌어지고 있는 분야입니다. 가격 페이지들이 6개월 전부터 서로 비슷해지기 시작했는데, 이는 보통 구매자들이 동일한 비교 질문을 던지기 시작했다는 신호입니다.

세 번째 카테고리: 에이전트 프레임워크 (agent frameworks) 내부의 메모리 기능. LangGraph, LlamaIndex, Vercel AI SDK, OpenAI Agents SDK 및 기타 몇몇 프레임워크들은 프레임워크의 일부로서 최소한의 메모리 프리미티브 (memory primitives)를 제공합니다. 이들은 일반적인 사례(최근 대화 회상 (recent-turn recall), 단순 키-값 지속성 (simple key-value persistence))를 다루지만, 더 어려운 문제들인 표면 형태 간의 엔티티 해상도 (entity resolution), 버전 관리된 사실에 대한 시간적 추론 (temporal reasoning), 대화 간 합성 (cross-conversation synthesis) 단계에는 미치지 못합니다. 만약 실제적인 메모리가 필요하면서 이러한 프레임워크 중 하나를 사용하고 있다면, 거의 항상 별도의 전용 메모리 계층을 연결하게 됩니다.

작지만 끈질긴 일부 팀들은 여전히 자체적으로 메모리 계층을 내부 구축 (in-house)하여 사용합니다. 이에 대한 논거(데이터 계층, 컴플라이언스, 이식성)는 초기 몇 달 동안은 타당하지만, 시스템이 운영되는 기간이 길어질수록 약해집니다. 우리가 목격한 대부분의 내부 구현 사례들은 더 어려운 문제들(엔티티 해상도, 시간적 추론, 스코핑, 멀티 테넌트 격리)에 도달하기도 전에 명백한 프리미티브들(청킹 (chunking), 임베딩 (embedding), 최신성 감쇠 검색 (recency-decay retrieval), 기본적인 중복 제거 (basic deduplication))을 재구현하는 데 그치고 맙니다. 비용은 복리로 증가합니다. 내부 구축에 대한 올바른 프레임워크는 "우리가 직접 만들었다"가 아니라 "우리가 더 나쁜 버전을 만들었고, 이제 그것을 영원히 유지보수해야 한다"입니다. 규제상의 이유로 직접 구축해야 하는 팀도 일부 있습니다. 대부분의 팀은 직접 구축해야 한다고 스스로를 설득하지만, 18개월 후에 이를 후회하며 결국 벤더로 이전하게 됩니다.

이 지도의 3가지 범주 다이어그램은 아래에 있습니다. 디자인 팀의 마커:

vendor-map-2026.svg

이 분야의 벤치마크 방식

2026년 발표된 주장들에서 두 가지 벤치마크(Benchmark)가 지배적입니다: LongMemEval과 LoCoMo입니다.

LongMemEval은 2024년 Adobe Research에서 발표되었으며 ICLR 2025에서 채택되었습니다. 이 벤치마크는 메모리 시스템이 길고 다중 세션(multi-session)인 대화 기록에 대해 질문에 얼마나 잘 답변할 수 있는지를 테스트합니다. 500개의 질문이 6가지 범주로 나뉘어 구성되어 있습니다: 단일 세션 사용자(single-session-user), 단일 세션 어시스턴트(single-session-assistant), 단일 세션 선호도(single-session-preference), 지식 업데이트(knowledge-update), 시간적 추론(temporal-reasoning), 그리고 다중 세션(multi-session)입니다. 가장 어려운 범주는 압도적으로 다중 세션인데, 이는 시스템이 단일한 최근 스레드에서 정보를 가져오는 대신 여러 개의 분리된 대화로부터 증거를 합성(synthesize)해야 하기 때문입니다. 발표된 방법론은 LLM-as-judge(판사로서의 LLM)를 사용하여 이진(binary) 정답/오답 라벨을 사용합니다.

ACL 2024에서 발표된 Snap Research의 LoCoMo는 긴 형태의 개방형 대화(open-ended conversations)에 초점을 맞춥니다. 이 벤치마크는 5가지 질문 범주를 포함합니다. 업계 관행(Mem0, Zep 및 대부분의 다른 서비스들이 따르는 관행)은 적대적(adversarial) 범주를 제외하고 1번부터 4번까지의 범주에 대해 보고하는 것입니다. 대략적으로는 다음과 같습니다: 멀티홉 추론(multi-hop reasoning), 시간적 추론(temporal reasoning), 오픈 도메인 의견(open-domain opinion), 그리고 싱글홉 회상(single-hop recall)입니다. 오픈 도메인은 벤더의 프롬프트 엔지니어링(prompt engineering)이 가장 큰 역할을 하는 경향이 있는 범주인데, 이는 정답(gold answers)이 종종 예측 가능한 패턴을 따르기 때문입니다 (예를 들어, 가장 최근에 참조된 이벤트가 좋지 않은 경험을 포함하고 있다면 "아마 아닐 것"이라는 답변이 정답일 가능성이 높은 식입니다).

두 벤치마크는 발표된 수치를 읽기 전에 이해할 가치가 있는 구조적 특성을 공유합니다. 답변 모델(answer model)과 판정 모델(judge model)은 메모리 시스템의 일부가 아닙니다. 이들은 벤더(vendor)가 프롬프트(prompt)를 통해 구성하는 별도의 LLM(대규모 언어 모델)입니다. 이러한 분리는 의도적인 것입니다. 벤치마크는 LLM이 아니라 메모리 계층(memory layer)을 테스트하기 때문입니다. 하지만 이는 벤더가 모델에 무엇을 질문할지, 답변이 나오기 전 모델이 어떻게 추론할지, 그리고 판정 모델이 응답을 어떻게 채점할지를 제어한다는 것을 의미합니다. 세 가지의 영향력 지점(points of leverage)이 있으며, 이 모든 것은 프롬프트 파일에 들어 있습니다. 바로 이 지점에서 재현성(reproduction)이 중요해지기 시작합니다.

수치를 재실행한 방법

우리의 테스트 프레임워크(harness)는 단순한 원칙에 따라 작동합니다. 각 벤더의 유료 호스팅 제품(또는 호스팅 제품이 없는 경우 권장 구성의 OSS(오픈 소스 소프트웨어) 계층)을 사용합니다. 고객이 사용하는 방식과 정확히 동일하게 그들의 파이프라인(pipeline)을 통해 벤치마크 데이터셋을 수집(ingest)합니다. 그런 다음 우리가 제어하는 표준화된 답변기(answerer)와 판정기(judge)를 통해 질문을 실행함으로써, 벤더의 평가 스택(evaluation stack)이 아닌 메모리 계층을 측정합니다.

구체적으로는 다음과 같습니다: 전반적으로 gpt-5를 답변 모델로 사용하였고, CORRECT(정답)와 WRONG(오답)을 표시하기 위한 명시적 조건이 포함된 이진 판정 프롬프트(binary judging prompt)를 사용했습니다(예: "예 쪽으로 기울기" 편향 없음, 일방적인 무시 조항 없음, 인코딩된 데이터셋 힌트 없음). 또한 확률성(stochasticity)을 제어하기 위해 5개 시드(five-seed) 평균을 사용하였으며, 우리가 프로덕션 환경에서 벤더 SDK를 사용하는 모든 빌더에게 권장할 것과 동일한 수집(ingestion) 구성을 사용했습니다.

지금까지의 주요 재현 결과는 LongMemEval에서의 격차이며, Mem0를 두 번 실행했기 때문에 두 부분으로 나뉩니다. Mem0가 2026년 4월 14일에 새로운 SOTA (State-of-the-art, 최첨단) 수치를 발표하기 전, 우리는 LongMemEval haystack을 그들의 호스팅 제품에 수집(ingestion)하고 우리의 표준화된 답변자(answerer)와 판정기(judge)를 통해 질문을 실행했습니다. 그 결과 57.5%를 얻었습니다. 그들의 4월 14일 홍보(아래에서 자세히 설명할 프롬프트 튜닝(prompt-tuning) 커밋 이후) 이후, 우리는 업데이트된 호스팅 제품을 대상으로 동일한 평가를 다시 실행했습니다. 그 결과 73.8%를 얻었습니다. Mem0의 메모리 계층(memory layer)은 해당 기간 동안 실제로 16.3포인트 개선되었으며, 이는 인정할 만한 실제 엔지니어링 진보입니다. 하지만 동일한 발표에서 게시된 주장은 93.4%였으며, 이는 동일한 메모리 시스템과 동일한 데이터를 사용한 4월 14일 이후의 재현 결과보다 여전히 19.6포인트 높았습니다.

수치가 다른 이유는 메모리 계층 때문이 아닙니다. 평가 시점에 벤더가 메모리 계층 위에 쌓아 올리는(stacks) 요소 때문입니다. 특히 Mem0의 경우, 이 스택은 github.com/mem0ai/memory-benchmarks에 있는 답변 및 판정 프롬프트 파일에 존재합니다. 우리는 그들의 발표된 주장과 함께 배포된 정확한 커밋(commit) 시점의 파일들을 감사(audit)했습니다.

여기 LongMemEval 프롬프트 (2026년 4월 3일 커밋됨)와 LoCoMo 프롬프트 (2026년 4월 9일 커밋됨)가 있습니다. 두 프롬프트 모두 Mem0의 4월 14일 수치 발표 이전에 반영되었습니다. 프롬프트 튜닝에 대한 파일 수준의 증거는 Mem0 자체의 커밋 기록에 포함되어 있습니다 (그들의 4월 3일 커밋 메시지에는 부분적으로 다음과 같이 적혀 있습니다: "Sync prompts from evals: CONTEXT CHECK, Rule 14 (contradictions), BIAS CHECK in judge, 5-step FINAL CHECK").