33개의 AI 메모리 엔진을 테스트했습니다 — 실제로 작동하는 것은 무엇인가

6개월 전, 저는 제 AI 에이전트에게 우리가 지난주에 무엇을 작업했는지 물었습니다. 에이전트는 전혀 알지 못했습니다. 기억을 못 해서가 아니라 — ChatGPT는 메모리가 있고, Claude도 메모리가 있지만 — 제가 그것이 무엇을 저장했는지 볼 수 없었고, 쿼리(query)할 수 없었으며, 무엇을 잊어야 할지 말해줄 수 없었기 때문입니다. 그저 "memory: on"이라고 적힌 토글 스위치가 달린 블랙박스(black box)였을 뿐입니다.

그래서 저는 제가 찾을 수 있는 모든 메모리 프레임워크를 테스트하기 시작했습니다 — 총 33개의 엔진을 OpenClaw (GitHub 스타 365K+ 이상)에서 실행했습니다. 대부분은 한 가지 문제는 잘 해결했지만 나머지 모든 것에는 실패했습니다.

6개월 후, 저는 실제로 작동하는 아키텍처(architecture)를 찾아냈습니다. 그것은 하나의 마법 같은 엔진에 관한 것이 아니라, 레이어(layers)에 관한 것입니다.

에이전트에게 실제로 필요한 메모리 스택 (memory stack)

33개의 엔진을 자세히 살펴보기 전에, 제가 배운 점은 다음과 같습니다: 에이전트 메모리는 단일 요소가 아닙니다. 인간의 뇌가 단기 기억, 장기 기억, 그리고 정보를 찾아보는 능력을 갖춘 것처럼, 하나의 스택(stack)입니다.

제대로 작동하는 에이전트 메모리 스택은 3개의 레이어를 가집니다:

레이어 1: 대화 압축 (Conversation compression) — 방금 일어난 일을 기억하기

모든 대화는 결국 컨텍스트 윈도우(context window) 제한에 도달합니다. 이 레이어가 없다면, 당신의 에이전트는 현재 대화의 시작 부분을 말 그대로 잊어버리게 됩니다. 대화 압축기(conversation compressor, 예: Lossless-Claw)는 요약본의 DAG(Directed Acyclic Graph)를 유지합니다 — 즉, 가장 최근의 대화 턴(turn)은 그대로 유지하면서 오래된 턴들을 응축된 요약본으로 압축합니다. 이를 통해 에이전트는 세션 중간의 컨텍스트(context)를 절대 놓치지 않습니다.

레이어 2: 네이티브 파일 + 시맨틱 검색 (Native files + semantic search) — 지속적인 기록

에이전트가 읽고 쓰는 일반적인 마크다운(markdown) 파일들입니다: 일기(2026-05-28.md), 큐레이션된 MEMORY.md, 선호도 파일, 프로젝트 노트 등입니다. 단순하고, 버전 관리(version-controlled)가 가능하며, 사람이 읽을 수 있습니다. 데이터베이스도, API도, 의존성(dependencies)도 없습니다 — 이것이 모든 상황에서도 살아남는 메모리 레이어입니다.

로컬 임베딩 모델 (local embedding model)이 이 파일들을 인덱싱하여, 에이전트가 단순히 키워드가 아닌 의미(meaning)를 통해 검색할 수 있게 합니다. "인증(auth) 마이그레이션을 어떻게 처리했지?"라고 물으면, 'auth'라는 단어를 한 번도 사용하지 않았더라도 정확한 항목을 찾아냅니다. QMD는 333MB 크기의 GGUF 모델을 로컬에서 실행합니다. 1초 미만의 검색 속도, API 비용 없음, 데이터가 기기를 벗어나지 않는 보안성을 제공합니다. 파일이 신뢰할 수 있는 단일 원천(source of truth)이며, 임베딩 (embeddings)은 이를 즉시 검색 가능하게 만듭니다.

레이어 3: 장기 지능 엔진 — 여기서 선택이 갈립니다

처음 두 레이어는 기본 요건(table stakes)입니다. 모든 진지한 에이전트에게 반드시 필요합니다. 세 번째 레이어는 제가 테스트한 33개의 엔진이 등장하는 지점이며, 진정한 차이점이 나타나는 곳입니다.

제가 테스트한 33개의 엔진

벤치마크나 데모가 아닌, 실제 일상적인 에이전트 작업에 투입하여 실무 환경에서 검증한 모든 메모리 프레임워크(memory framework)를 소개합니다. 이들은 자연스럽게 6가지 카테고리로 분류되며, 각 카테고리는 서로 다른 유형의 '기억하기' 문제를 해결합니다.

벡터 유사도 (Vector similarity) — 기초 레이어

이 엔진들은 임베딩 (embeddings)을 저장하고 의미적 유사성 (semantic similarity)에 따라 검색합니다. 대부분의 다른 메모리 시스템이 이 위에 구축되는 기본 구성 요소입니다.

#	엔진	기능
1	ChromaDB	임베딩 기반의 의미론적 검색, 가볍고 개발자 친화적
...

이 엔진들은 "X와 유사한 것을 찾아줘"라는 요청에는 탁월하지만, 자신들이 무엇을 저장하고 있는지는 이해하지 못합니다. 벡터 저장소 (vector store)는 사용자의 선호도, 프로젝트 아키텍처, 그리고 지난 화요일 스탠드업 미팅 노트 등을 모두 동일하게 부동 소수점 배열 (floating-point arrays)로 취급합니다. RAG (검색 증강 생성) 및 문서 검색에는 필수적이지만, 에이전트 메모리 측면에서는 필요한 레이어일 뿐 그것만으로는 충분하지 않습니다.

세션 및 대화 메모리 (Session & conversation memory) — 현재 스레드 기억하기

이들은 대화 내부 및 대화 간에 오간 내용을 추적합니다.

#	엔진 (Engine)	기능
13	Zep	자동 사실 추출 (fact extraction) 기능이 포함된 장기 대화 메모리 (Long-term conversation memory)
...

이들은 세션 내에서 "이미 말했잖아요" 문제를 해결합니다. Zep은 이 분야에서 돋보이는데, 단순한 버퍼 저장 (buffer storage)을 넘어 대화로부터 구조화된 사실 (structured facts)을 추출합니다. 하지만 세션 메모리(session memory)만으로는 에이전트에게 당신의 세계에 대한 지속적인 이해를 제공할 수 없습니다.

프레임워크 메모리 모듈 (Framework memory modules) — 기능으로서의 메모리

이들은 더 큰 에이전트/RAG 프레임워크 내에 구축된 메모리 구성 요소입니다.

#	엔진 (Engine)	기능
17	LlamaIndex Memory	채팅 메모리 (Chat memory) + 지식 인덱스 (knowledge index) 통합
...

이미 해당 생태계 내에 있다면 유용합니다. 이들은 메모리 추상화 (memory abstractions; 버퍼, 요약, 엔티티 추적 등)를 제공하지만, 해당 프레임워크와 밀접하게 결합되어 있습니다. 메모리는 이 도구들의 핵심 미션이 아니라 하나의 기능 (feature)입니다.

에이전트 및 자율 메모리 (Agentic & autonomous memory) — 에이전트가 스스로 메모리를 관리

이 방식은 에이전트 스스로 무엇을 기억하고 무엇을 잊을지 결정하게 합니다.

#	엔진 (Engine)	기능
23	Letta (MemGPT)	내부/외부 독백 (inner/outer monologue)을 통한 자기 편집 메모리 (Self-editing memory)
...

매우 흥미로운 연구 방향입니다. 특히 Letta/MemGPT는 모델이 스스로 자신의 메모리 계층 (memory tiers)을 관리한다는 개념을 개척했습니다. 프로덕션 환경에서의 과제는, 무엇이 보관할 가치가 있는지 결정하는 것을 LLM에 맡겨야 하며, 그 결정의 품질은 모델과 컨텍스트에 따라 달라진다는 점입니다.

개인용 AI 및 북마크 (Personal AI & bookmarks) — 에이전트가 아닌 인간을 위한 메모리

#	엔진 (Engine)	기능
28	Khoj	파일 기반 메모리를 사용하는 셀프 호스팅형 개인용 AI
...

이들은 에이전트 메모리 계층이라기보다 개인 지식 도구에 가깝게 설계되었습니다. 해당 사용 사례에는 잘 작동하지만, 이들은 다른 문제를 해결하고 있습니다. 즉, 에이전트에게 지속적인 이해를 제공하는 것이 아니라, 당신이 무언가를 기억하도록 돕는 것입니다.

구조화된 메모리 엔진 (Structured memory engines) — 에이전트 지능을 위해 특화 설계됨

이 엔진들은 에이전트에게 구조화되고, 쿼리 가능하며, 지속적인 메모리 (memory)를 제공하기 위해 특별히 설계되었습니다:

#	엔진 (Engine)	기능
31	Mem0	지능형 사실 추출 (fact extraction), 중복 제거 (deduplication), 모순 해결 (contradiction resolution)
...

이 지점이 흥미로워지는 부분이며, 제가 6개월 중 대부분을 보낸 곳이기도 합니다.

장기 메모리 (Long-term memory)의 3단계

33개를 모두 테스트한 결과, 구조화된 메모리 엔진들이 눈에 띄었습니다. 하지만 제가 도달하기까지 몇 달이 걸린 통찰은 이것입니다: 이 세 가지는 함께 실행되도록 만들어진 것이 아닙니다. 이들은 진화적인 단계 (evolutionary tiers)입니다. 각 단계는 이전 단계를 대체하며, 하위 단계의 기능을 포함하면서 새로운 역량을 추가합니다.

1단계 (Tier 1): Mem0 — 사실과 선호도

Mem0 (GitHub 스타 48K 이상, $24M Series A)는 지능형 사실 계층 (intelligent facts layer)입니다. 월요일에 에이전트에게 "나는 TypeScript를 선호해"라고 말하고 목요일에 "데이터 스크립트에는 Python을 사용해"라고 말한다면, Mem0는 두 개의 모순된 항목을 저장하지 않습니다. 대신 다음과 같이 업데이트합니다: 일반 개발에는 TypeScript, 데이터에는 Python. 모든 사실은 카테고리화되고, 타임스탬프가 찍히며, 신뢰도 점수 (confidence score)가 매겨집니다.

Zep의 사실 추출 (fact extraction)이 세션 메모리 (session memory)에 덧붙여진 기능인 반면, Mem0의 전체 아키텍처 (architecture)는 사실을 신뢰할 수 있게 만드는 것을 중심으로 구축되었습니다. 당신의 에이전트는 매 세션마다 당신의 선호도, 프로젝트의 특이점, 그리고 관례 (conventions)를 이미 알고 있는 상태로 시작합니다. 다시 설명할 필요가 없습니다.

가장 적합한 용도: 개발자 및 기술적 유스케이스 (technical use cases). 만약 당신의 에이전트가 주로 세션 전반에 걸쳐 선호도, 관례, 프로젝트 세부 사항을 기억해야 한다면, Mem0가 올바른 선택입니다. 설정이 가장 간단하며 가장 집중된 도구입니다.

2단계 (Tier 2): Cognee — 관계와 추론 (Mem0를 대체함)

Cognee ($7.5M 시드 투자, GitHub Secure Open Source 졸업생, 70개 이상의 기업에서 운영 중)는 지식 그래프 (Knowledge Graph)를 구축합니다. 이는 고립된 사실이 아니라 엔티티 (Entities), 관계 (Relationships), 그리고 의미론적 연결 (Semantic Connections)의 망을 형성합니다.

Mem0가 "클라이언트는 파란색 브랜딩을 선호한다"는 것을 안다면, Cognee는 클라이언트의 브랜드 가이드라인이 지난달 캠페인 성과와 연결되어 있고, 이것이 가장 많이 참여한 오디언스 세그먼트 (Audience Segments)와 연결되며, 다시 콘텐츠 캘린더 (Content Calendar)와 연결된다는 것을 압니다. Cognee는 14가지 검색 모드 (Retrieval Modes)와 사용하면 할수록 연결을 강화하는 자가 개선형 "memify" 기능을 제공합니다.

Cognee는 Mem0가 수행하는 모든 작업(사실은 그래프 내의 노드일 뿐입니다)을 처리할 뿐만 아니라, 그들 사이의 관계를 매핑합니다. 이것이 Cognee가 Tier 1을 대체하는 이유입니다. Cognee를 실행하고 있다면 Mem0는 필요하지 않습니다.

가장 적합한 용도: 마케팅, 콘텐츠, 그리고 다중 프로젝트 작업. 만약 당신의 에이전트가 브랜드, 캠페인, 오디언스, 프로젝트 전반에 걸쳐 추론해야 한다면 — 즉, 단순히 '무엇'인지가 아니라 사물들이 '어떻게' 연결되는지를 이해해야 한다면 — Cognee가 올바른 선택입니다.

Tier 3: Graphiti — 시계열 추론 (Cognee를 대체함)

Zep의 Graphiti는 시계열 지식 그래프 (Temporal Knowledge Graph)입니다. 이 도구의 핵심 통찰은 현재 상태를 아는 것만으로는 충분하지 않다는 것입니다. 사물이 '언제' 변했는지, 그리고 '이전에는 무엇이 사실이었는지'를 알아야 합니다.

모든 사실은 유효 기간 (Validity Intervals)을 가집니다. 새로운 정보가 기존 정보와 충돌할 때, Graphiti는 덮어쓰지 않습니다. 대신 시계열 기록 (Temporal Record)을 생성하고 이전 기록을 무효화하여 전체 이력을 보존합니다. "이 설정이 언제 변경되었나요?" "3월 배포 전에는 무엇이 달랐나요?" Graphiti는 로그를 뒤질 필요 없이 이에 대해 직접적으로 답변합니다.

Graphiti는 시맨틱 검색 (semantic search), 키워드 매칭 (keyword matching), 그리고 그래프 순회 (graph traversal)를 결합하여 Deep Memory Retrieval 벤치마크에서 MemGPT보다 뛰어난 성능을 보여줍니다.

Graphiti는 사실 (Mem0와 같은) 및 관계 (Cognee와 같은)를 처리할 뿐만 아니라, 그것들이 시간이 지남에 따라 어떻게 변하는지도 추적합니다. 이는 하위 계층의 두 가지 기능을 모두 대체하지만, 실행 시 가장 무겁습니다 (FalkorDB 사용, 더 많은 연산량, 더 높은 복잡도).

가장 적합한 용도: 운영 (operations), 경영 (executive), 비즈니스 유스케이스. 만약 당신의 에이전트가 시간에 따른 인과 관계 추론 — "무엇이 변했는가", "언제 고장 났는가", "이전에는 무엇이 사실이었는가" — 이 필요한 경우, Graphiti가 올바른 선택입니다.

세 가지 모두가 아닌, 하나만 선택하세요

유스케이스	선택할 계층	이유
개발자 / DevOps	Mem0	빠르고 신뢰할 수 있는 사실 회상이 필요합니다. 선호도, 관례, 프로젝트 세부 사항 등.
...

흔히 하는 실수는 "더 많은 엔진 = 더 나은 메모리"라고 생각하는 것입니다. 그렇지 않습니다. 각 계층은 이미 그 아래 계층의 기능을 포함하고 있습니다. Mem0를 Graphiti와 함께 실행하는 것은 중복입니다. Graphiti는 이미 사실을 저장하고 있기 때문입니다. 세 가지를 모두 실행하는 것은 연산량을 낭비하고 일관성 충돌 (consistency conflicts)을 일으킵니다.

당신의 작업에 맞는 계층을 선택하세요. 이를 기본 스택 (대화 압축 + 시맨틱 검색이 포함된 네이티브 파일)과 결합하면 당신의 에이전트는 중요한 모든 것을 기억할 것입니다.

전체 아키텍처

완전한 에이전트 메모리 스택은 다음과 같은 모습입니다:

모든 레이어는 모델에 컨텍스트 (context)를 제공합니다. 하위 두 레이어는 항상 켜져 있습니다. 최상위 레이어는 당신의 에이전트가 어떤 종류의 추론을 필요로 하는지에 따라 선택 사항입니다.

실행 방법

기본 스택(레이어 1–2)은 OpenClaw에 내장되어 있어, 대화 압축(conversation compression), 네이티브 메모리 파일(native memory files), 시맨틱 검색(semantic search)이 즉시 작동합니다. 장기 엔진(레이어 3)은 추가 설정이 필요합니다. Mem0는 벡터 저장소(vector store)가 필요하고, Cognee는 그래프 데이터베이스(graph database)가 필요하며, Graphiti는 FalkorDB에서 실행됩니다.

OpenClaw는 오픈 소스이며 전체 스택을 셀프 호스팅(self-host)할 수 있습니다. 인프라 구축 작업을 건너뛰고 싶다면, 저는 사용 사례에 맞는 적절한 메모리 스택을 사전 구성해 주는 관리형 OpenClaw 호스팅 서비스인 ClawBase를 구축해 왔습니다. 하지만 솔직히 말해서, 셀프 호스팅을 하더라도 여기서 얻을 수 있는 핵심 결론은 아키텍처(architecture)입니다. 즉, 당신의 작업에 맞는 장기 엔진을 선택할 수 있는 3계층 메모리 스택입니다.

메모리는 시간이 지남에 따라 축적됩니다. 어떤 방식으로 실행하든, 더 오래 사용할수록 성능은 더 좋아집니다.

제가 계속해서 강조하는 한 가지는 이것입니다. 에이전트가 실제 메모리 스택을 갖추게 되면, 더 큰 가능성의 문이 열린다는 점입니다. 바로 여러 에이전트 간의 일관된 공유 메모리(shared memory)입니다. 단순히 자신의 컨텍스트(context)를 기억하는 것을 넘어, 당신의 프로젝트, 선호도, 그리고 결정 사항에 대해 통일된 이해를 공유하는 에이전트 팀을 상상해 보세요. 그것은 완전히 다른 종류의 아키텍처이며, 향후 기사에서 자세히 다룰 예정입니다.