AI 에이전트 메모리 시스템 비교: Mem0, Zep, Letta, 그리고 ClawMem
요약
AI 에이전트의 메모리 시스템이 단순한 회상을 넘어 에이전트 간 협업과 지식 동기화를 위한 인프라로 진화하고 있음을 설명합니다. Mem0, Zep, Letta, ClawMem 등 다양한 시스템의 필요성과 선택 기준을 다룹니다.
핵심 포인트
- 에이전트 메모리는 단일 비서의 기능을 넘어 인프라의 문제로 확장됨
- 여러 에이전트 간의 지식 동기화 및 최신성 유지가 핵심 과제
- 단순 검색 성능보다 수정 가능성과 협업 능력이 중요함
- 워크플로 요구사항에 따른 적절한 메모리 시스템 선택 필요
2026년에도 메모리가 여전히 중요한 이유는 무엇일까요? 이제 질문은 에이전트(Agent)가 메모리를 가져야 하는가에 대한 것이 아닙니다. 당연히 가져야 합니다.
하지만 팀들이 더 많은 워크플로(Workflow)에 더 많은 에이전트를 배치함에 따라, 메모리는 더 이상 단일 비서의 회상 기능에 머물지 않습니다. 그것은 조정(Coordination)의 문제, 정확성(Correctness)의 문제, 그리고 결과적으로 더 넓은 범위의 에이전트 및 인간 팀 전체에 걸친 인프라(Infrastructure)의 문제가 됩니다.
메모리 시스템이 실제로 해결해야 하는 문제
세 명의 에이전트가 소프트웨어 회사의 고객 운영을 돕고 있다고 가정해 봅시다: 지원 에이전트(Support Agent), 배포 에이전트(Deployment Agent), 그리고 운영 에이전트(Ops Agent)입니다.
지원 에이전트는 에스컬레이션(Escalation) 이후 다음과 같은 규칙을 학습합니다:
싱가포르 엔터프라이즈 테넌트(Tenant)는 주말 유지보수 시간 동안에만 스키마 변경(Schema changes)을 적용받을 수 있으며, 승인 경로는 Mika에게 전달된다.
2주 후, 배포 에이전트가 롤아웃(Rollout)을 준비하고 있습니다. 이 에이전트는 어떤 계정이 특별한 유지보수 시간이 필요한지 알아야 하지만, 이 규칙은 지원 에이전트의 메모리에만 존재합니다. 배포 에이전트는 이를 물어봐야 한다는 사실조차 모릅니다.
거의 동시에, 운영(Ops) 팀은 승인자를 Mika에서 Ren으로 업데이트하고, 이 정책을 제한된 배포 계정을 위한 더 넓은 내부 카테고리로 통합합니다.
이제 메모리 문제는 세 가지 계층을 갖게 됩니다:
- 배포 에이전트는 자신에게 필요한 규칙을 놓치고 있습니다.
- 지원 에이전트는 이미 오래된(Stale) 버전의 규칙을 보유하고 있습니다.
- 만약 인간이 어제 정책을 업데이트했다면, 에이전트가 이를 어떻게 알 수 있을까요?
어려운 질문은 모델이 기억할 수 있느냐가 아닙니다. 에이전트와 인간이 동일한 최신 메모리 표면(Memory surface) 위에서 작업에 대해 협업할 수 있는지, 그리고 지식이 진화함에 따라 이를 어떻게 동기화(Synchronized)된 상태로 유지할 수 있는지에 대한 것입니다.
시스템을 선택하는 방법
팀마다 시작점이 다릅니다. 아래 표는 가장 일반적인 요구사항을 가장 적합한 시스템과 매칭하여 보여줍니다.
| 요구사항 | 추천 시스템 | 이유 |
|---|---|---|
| 하나의 OpenClaw 워크스페이스 내에서 단순하고 지속 가능한 메모리 | OpenClaw 네이티브 메모리 (OpenClaw native memory) | 파일 기반이며 읽을 수 있고, 추가적인 인프라가 필요 없음. |
| ... | ... | ... |
이 비교가 실제로 측정하는 것
검색 벤치마크 (Retrieval benchmarks)는 팀이 실제 운영 환경 (production)에서 중요하게 생각하는 대부분의 요소를 놓치고 있습니다. 실질적인 질문은 다음과 같습니다:
필요할 때 올바른 것을 기억할 수 있는가?
내용이 틀렸거나 오래되었을 때 수정할 수 있는가?
여러 에이전트와 인간이 이를 안전하게 공유할 수 있는가?
사람들이 에이전트가 학습한 내용을 확인하고 이에 따라 조치를 취할 수 있는가?
기술 스택 (stack)이 변경될 때 이동하기가 얼마나 쉬운가?
아래의 프로필은 이러한 차원(dimensions)에서 각 시스템을 다룹니다.
시스템 프로필
OpenClaw 네이티브 메모리 (OpenClaw native memory)
최적의 용도: 추가 인프라 없이 지속 가능하고 읽을 수 있는 메모리가 필요한 단일 OpenClaw 에이전트.
메모리는 로컬 파일로 저장되며, 하이브리드 검색 (hybrid retrieval)을 통해 검색할 수 있습니다. 드림 메커니즘 (dreaming mechanism)은 시간이 지남에 따라 메모리를 승격시키고 통합하는데, 이는 메모리가 단순히 쌓이기만 하는 것이 아니라 개선됨을 의미합니다. 일반 파일 형태이므로 이식성 (portability)이 매우 높지만, OpenClaw에 밀접하게 결합되어 있습니다. 에이전트 간 공유나 워크스페이스 외부의 인간에게 메모리를 보여주는 기능에 대한 네이티브 지원은 제한적입니다.
지속 가능한 단일 에이전트 메모리를 위한 가장 마찰이 적은 경로를 원한다면 여기서 시작하세요.
트레이드오프 (Trade-off): 여러 에이전트 간에 메모리를 공유하거나 워크스페이스 외부의 더 넓은 팀에게 메모리를 공개하는 것에 대한 네이티브 지원이 제한적입니다.
ClawMem
최적의 용도: 단일 에이전트로 시작하여 나중에 에이전트와 인간 전체에 걸친 구조화된 공유 지식으로 확장하고자 하는 팀.
메모리는 단순한 장식용 메타데이터가 아니라 지속 가능한 스키마 (durable schema)의 일부인 레이블 (type, kind, topic)로 구조화됩니다. 이는 세 가지 이유로 중요합니다: 회상 정밀도 (recall precision)를 향상시키고, 인간이 감사 (auditing) 및 정리를 위해 탐색할 수 있는 구조를 제공하며, 사실들이 쌓이게 두는 대신 오래된 사실을 업데이트하거나 폐기할 수 있는 깨끗한 기반을 시스템에 제공합니다.
워크플로우 자체(대화 미러링, 후보 추출, 조정(reconcile), 제자리 업데이트(update-in-place), 오래된 정보 폐기(stale retirement), 중복 제거(dedup))가 위에서 설명한 시나리오가 실제 문제가 되는 것을 방지합니다. 승인자가 Mika에서 Ren으로 변경될 때, 조정(reconcile) 단계를 통해 세 명의 에이전트가 조용히 서로 다른 정보로 갈라지게 두는 대신, 에이전트 전반에 걸쳐 해당 사실의 모든 버전을 찾아 업데이트할 수 있습니다.
공유 메모리(Shared memory)는 별도로 덧붙여진 것이 아니라 네이티브(native)하게 내장되어 있습니다. 하나의 에이전트가 오늘 바로 ClawMem을 사용하기 시작할 수 있으며, 동일한 메모리 인터페이스를 나중에 다른 모델로 전환하지 않고도 다른 에이전트 및 인간과 공유할 수 있습니다. 콘솔 그래프(Console graph)는 메모리와 그 연결 관계를 팀이 시각적으로 확인할 수 있게 해줍니다.
트레이드오프(Trade-off): 현재 중간 수준의 호스트 결합도(host coupling)를 가지고 있어, 완전한 파일 기반 방식이나 클라우드 불가지론적(cloud-agnostic) 접근 방식에 비해 이식성(portability)이 제한됩니다.
mem0
최적의 용도: 제품 및 세션 전반에 걸친 사용자 선호도 메모리 및 어시스턴트의 연속성 유지.
mem0는 사용자, 에이전트, 앱 및 실행(run) 수준에서 잘 정의된 메모리 프리미티브(memory primitives)를 제공합니다. 관리형 업데이트(Managed updates)와 만료(expiration) 기능이 생명주기를 처리합니다. 어시스턴트가 대화 상대가 누구인지, 그리고 그 사람이 무엇을 선호하는지를 기억하도록 돕는 것이 목표일 때 매우 적합합니다.
ClawMem 또는 Hindsight와 비교했을 때, 공유된 조직적 지식(institutional knowledge)보다는 개인화(personalization)에서 시작한다는 점이 특징입니다.
트레이드오프(Trade-off): 팀 수준 또는 에이전트 간의 지식 공유에는 덜 자연스럽게 적합합니다.
Hindsight
최적의 용도: 검색 품질(retrieval quality)이 핵심 관심사인 성찰 중심(reflection-heavy)의 조직적 메모리.
Hindsight는 유지(retain) -> 회상(recall) -> 성찰(reflect) 루프를 중심으로 메모리를 구성하며, 다중 전략 검색(multi-strategy retrieval)과 학습된 회상(learned recall)을 통해 시간이 지남에 따라 성능이 향상됩니다. 주요 문제가 적절한 순간에 올바른 지식을 표면화하고 성찰을 통해 이를 개선하는 것이라면 이 시스템이 가장 강력합니다.
이러한 특징은 학습된 회상(learned recall)에 대한 매력적인 해답이 되지만, 메모리를 공유 작업 공간으로 취급하는 시스템과는 다른 접근 방식입니다.
트레이드오프(Trade-off): 에이전트 간의 지식을 조정하거나 일상적인 협업에서 인간에게 메모리를 가시화하는 데에는 덜 집중되어 있습니다.
Letta
최적의 용도: 메모리가 별도의 서비스가 아닌 에이전트 런타임 (runtime) 자체의 일부인 상태 유지형 에이전트 (stateful agents)에 적합합니다.
메모리는 런타임에 의해 관리되는 계층 구조 (hierarchy)로서 에이전트 모델 내부에 존재합니다. 업데이트와 영속성 (persistence)은 런타임 계층에서 처리되며, 런타임 UI를 통해 메모리 상태를 검사할 수 있습니다. 이는 에이전트가 자신의 상태를 직접 소유해야 한다는 아키텍처 철학을 가지고 있다면 매우 매력적인 선택입니다.
mem0와 비교했을 때, 사용자 연속성 (user continuity)보다는 지속적인 에이전트 상태 (persistent agent state)에 더 집중합니다.
트레이드오프 (Trade-off): 메모리가 독립적인 에이전트나 팀 간에 이식되거나 공유되어야 하는 경우 제약이 더 많습니다.
Zep / Graphiti
시간을 인식하는 업데이트 (time-aware updates) 및 무효화 (invalidation) 기능을 갖춘 그래프 기반 저장 방식은, 만료되거나 충돌하거나 혹은 특정 시점에만 유효한 사실 (facts)이 핵심 문제인 경우 이러한 시스템들이 특히 강력한 성능을 발휘합니다. 위 시나리오에서 정책이 언제 변경되었는지, 그리고 특정 시점에 어떤 버전이 유효했는지를 아는 것은 Zep과 Graphiti가 매우 잘 처리하는 유형의 문제입니다.
Letta와 비교했을 때, 런타임 관리형 상태보다는 시간 인식 지식 (time-aware knowledge)에 더 중점을 둡니다.
트레이드오프 (Trade-off): 인간의 가시성이나 팀 간 협업에 대한 집중도는 낮으며, 그래프 중심의 접근 방식은 많은 팀이 필요로 하는 것보다 더 많은 기계적 장치 (machinery)를 추가할 수 있습니다.
Mem9
최적의 용도: 여러 에이전트를 공유 메모리 풀 (shared memory pool)에 빠르게 투입하고자 할 때 적합합니다.
Mem9은 설계 단계부터 다중 에이전트 (multi-agent) 액세스를 위해 구축된 공유 메모리 서비스입니다. 관리자 인터페이스 (admin surface)를 통해 가시성을 제공하며, 풀 (pool)이 동시 읽기 및 쓰기를 처리합니다. 메모리의 시간적 진화보다는 에이전트 간의 조정 (coordination)이 즉각적인 필요 사항일 때 가장 강력한 선택지입니다.
트레이드오프 (Trade-off): 공유 풀은 더 명시적으로 조직된 시스템이 제공하는 것과 같은 장기적인 구조, 정리 규율 (cleanup discipline), 또는 메모리 유지 관리 인터페이스를 자동으로 제공하지는 않습니다.
Cognee
최적의 용도: 메모리 워크플로우 하위에 더 광범위한 지식 엔진 (knowledge engine)을 두고자 하는 팀에 적합합니다.
Cognee는 기억(remember), 회상(recall), 망각(forget), 개선(improve)을 지원하는 루프 내에서 그래프(graph) 및 벡터 검색(vector retrieval)을 결합합니다. 이는 단순한 협소한 메모리 애드온(add-on)이라기보다 재사용 가능한 지식 계층(knowledge layer)에 더 가깝게 느껴지며, 메모리가 더 큰 지식 관리 아키텍처(knowledge-management architecture)의 일부일 뿐인 경우에 유용합니다.
트레이드오프(Trade-off): 단순히 실용적인 메모리 워크스페이스를 찾는 팀에게는 다소 무겁게 느껴질 수 있습니다.
Supermemory
최적의 용도: 커스터마이징(customization)보다 통합 속도를 우선시하는 팀.
Supermemory는 프로필(profiles), 커넥터(connectors), RAG가 하나의 패키지로 구성된 호스팅된 컨텍스트 계층(context layer)입니다. 플랫폼에서 관리되며 가시성을 위한 대시보드를 제공하며, 주요 장점은 도입 시의 마찰(friction)이 낮다는 점입니다.
트레이드오프(Trade-off): 이러한 편리함에 대한 대가로 벤더(vendor)의 가격 정책과 벤더의 형태에 맞춰진 제품 인터페이스가 트레이드오프가 됩니다.
MemOS
최적의 용도: 메모리를 시스템 추상화(systems abstraction)로서 연구 중심의 작업을 수행하는 팀.
MemOS는 공유 큐브(shared cubes), 피드백 기반 정교화(feedback-driven refinement), 교차 계층 범위(cross-layer scope)를 갖춘 운영체제(operating-system)와 같은 계층으로 메모리를 정의합니다. 이는 메모리 시스템이 지향할 수 있는 어휘를 확장하며, 아직 기본 프로덕션(production) 선택지는 아닐지라도 지켜볼 가치가 있습니다.
트레이드오프(Trade-off): 직관적인 프로덕션 메모리 결정을 원하는 대부분의 팀이 원하는 것보다 여전히 연구 중심적입니다.
전체 비교
| 시스템 | 주요 적합성 | 메모리 범위 | 업데이트 및 진화 | 시각화 | 협업 | 이식성 |
|---|---|---|---|---|---|---|
| OpenClaw Native | 단일 에이전트 연속성 | 하나의 에이전트, 하나의 워크스페이스 | Dreaming 기반 통합 | 읽기 가능한 로컬 파일 | 제한적 | 높음 (파일), OpenClaw 결합형 |
| ... |
ClawMem이 차별화되는 지점
업계 전반을 비교해 본 결과, ClawMem의 차이점은 단순히 장기 메모리(long-term memory)를 가지고 있다는 점에 그치지 않습니다. 더 의미 있는 차이점은 지속성 메모리(persistent memory), 메모리 진화(memory evolution), 공유 가시성(shared visibility), 그리고 협업(collaboration)을 하나의 내구성 있는 표면(durable surface) 위에서 어떻게 연결하느냐에 있습니다.
단일 에이전트를 위해 작동하며, 메모리가 공유될 때도 계속 작동합니다
많은 시스템이 단일 에이전트 메모리(single-agent memory) 또는 공유 메모리(shared memory) 중 한쪽에서만 강점을 보입니다. ClawMem은 두 단계 모두에서 더 강력합니다.
단일 에이전트의 경우, ClawMem은 단순히 단절된 메모의 더미로 변하는 대신 시간이 지남에 따라 진화할 수 있는 구조화된 지속성 메모리(structured durable memory)를 이미 지원합니다. 하지만 이 동일한 메모리 모델은 더 많은 에이전트나 인간이 루프(loop)에 참여하더라도 깨지지 않습니다. 동일한 지속성 표면(durable surface)은 별도의 시스템으로 전환할 필요 없이, 한 에이전트를 위한 자기 개선형 메모리(self-improving memory), 멀티 에이전트 조정(multi-agent coordination), 그리고 더 넓은 팀 협업(team collaboration)을 지원할 수 있습니다.
레이블 메커니즘은 메모리에 가시적인 구조를 부여합니다
ClawMem의 가장 중요한 설계 선택 중 하나는 레이블 우선(label-first) 구조입니다.
ClawMem에서 레이블은 단순한 미적 메타데이터(cosmetic metadata)가 아닙니다. 레이블은 지속성 메모리 스키마(durable memory schema)의 일부입니다. 메모리는 단순한 텍스트 덩어리(text blob)가 아닙니다. 다음과 같은 가시적인 구조를 가질 수 있습니다:
- type: memory
- kind:*
- topic:*
이것이 중요한 이유는 레이블이 세 가지 방식으로 도움을 주기 때문입니다:
- 더 나은 회상 정밀도(recall precision): 메모리를 종류(kind), 주제(topic), 지속성 표면(durable surface)별로 좁힐 수 있기 때문입니다.
- 더 나은 조직화(organization): 인간이 동일한 가시적 구조를 사용하여 메모리를 탐색하고 정리할 수 있기 때문입니다.
- 더 나은 진화(evolution): 사실관계가 변할 때, 시스템이 오래된 메모리(stale memory)를 업데이트, 병합 및 폐기할 수 있는 더 깔끔한 구조를 갖기 때문입니다.
이러한 특징 덕분에 메모리는 단순히 축적된 잔여물(accumulated residue)이 아니라 유지 관리 가능한 지식(maintainable knowledge)처럼 느껴집니다.
팀 공유와 협업이 네이티브하게 느껴집니다
ClawMem은 공유 메모리를 어시스턴트 간의 수동적인 전달(manual handoff)이 아닌, 메모리 시스템의 네이티브(native)한 부분으로 취급합니다. 메모리 공간은 하나의 에이전트에게 비공개로 유지될 수도 있고, 특정 에이전트 팀이나 프로젝트 그룹과 공유될 수도 있으며, 팀 전체에서 사용되는 조직 수준(organization-level)의 공간이 될 수도 있습니다.
계층 구조는 명시적입니다. 조직(Organizations)은 최상위 협업 경계를 정의합니다. 팀(Teams)은 해당 경계 내부에서 실질적인 공유 단위가 됩니다. 이후 구성원과 에이전트(Agents)에게 각 메모리 공간에 대해 명확한 읽기, 쓰기 또는 관리자 권한(admin permissions)과 가시적인 초대 상태를 부여하여 적절한 수준의 액세스 권한을 제공할 수 있습니다. 이를 통해 한 공간은 팀 전용으로 유지하면서, 다른 공간은 조직 전체에 더 폭넓게 공유할 수 있습니다.
이러한 구조는 에이전트, 팀, 그리고 조직 간의 공유를 네이티브(native)하게 느껴지도록 만듭니다. 지원 에이전트(support agent)가 고객 패턴을 한 번 포착하면, 연구 에이전트(research agent)가 나중에 이를 확장할 수 있으며, 운영 에이전트(operations agent)는 별도의 워크플로(workflows)에서 동일한 지식을 재생성하는 대신 동일한 영구적 메모리 공간(durable memory space)을 재사용할 수 있습니다. 그 결과 개인 메모리, 팀 메모리, 그리고 조직 메모리가 공존할 수 있는 더 명확한 협업 모델이 만들어집니다.
최종 결론 (Final take)
OpenClaw 네이티브 메모리는 이미 단일 에이전트 메모리(single-agent memory)를 실현했습니다. Dreaming은 이를 더욱 개선합니다. 어떠한 정직한 비교라도 바로 그 지점에서 시작되어야 합니다.
AI 자동 생성 콘텐츠
본 콘텐츠는 Dev.to AI tag의 원문을 AI가 자동으로 요약·번역·분석한 것입니다. 원 저작권은 원저작자에게 있으며, 정확한 내용은 반드시 원문을 확인해 주세요.
원문 바로가기