AI 에이전트 메모리 & 장기 컨텍스트 2026 — Mem0 / Zep / Letta / Cognee / Graphiti / Anthropic Memory 심층 가이드

프롤로그 — 컨텍스트 윈도우가 1M이어도 메모리는 풀리지 않았다

2024년에 우리는 "컨텍스트 윈도우가 1M이 되면 메모리 문제는 사라진다"고 믿었다. 2026년에는 그게 거짓말이었다는 걸 안다.

1M 토큰을 매 턴 보내면 레이턴시가 폭발하고, 비용이 폭발하고, needle-in-haystack 성능이 무너진다.
컨텍스트는 세션 종료와 함께 증발한다. 어제의 대화는 오늘 다시 시작이다.
모델이 컨텍스트를 받았다고 그걸 활용한다는 보장은 없다. "lost in the middle" 문제는 여전히 살아있다.

그래서 2026년의 AI 엔지니어링에서 가장 뜨거운 인프라 카테고리 중 하나가 에이전트 메모리다. Mem0이 YC에서 등장하고, Zep이 Series A를 받았고, Letta(구 MemGPT)는 "에이전트 OS"를 표방하며 자리잡았다. Anthropic은 2025년 Memory API 프리뷰를 냈고, OpenAI는 ChatGPT에 Memory 기능을 기본 탑재했다.

이 글은 그 지형 전체를 본다. 메모리 계층을 분해하고, 주요 라이브러리·API를 하나씩 보고, 저장 백엔드를 비교하고, 한국·일본의 움직임을 다루고, 마지막으로 누가 무엇을 골라야 하는지 권고한다.

1장 · 2026년 AI 에이전트 메모리 지도 — Vector / Graph / Episodic 3 모델

에이전트 메모리는 2026년 시점에 크게 세 가지 모델로 수렴했다.

┌─────────────────────────────────────────────────────────────────┐
│                      에이전트 메모리 3 모델                       │
│                                                                 │
│  ┌──────────────┐   ┌──────────────┐   ┌──────────────────┐    │
│  │ Vector       │   │ Graph        │   │ Episodic         │    │
│  │ Memory       │   │ Memory       │   │ Memory           │    │
│  │              │   │              │   │                  │    │
│  │ 임베딩 + 검색 │   │ 엔티티+관계   │   │ 사건의 시퀀스    │    │
│  │ 유사도 기반   │   │ 추론 가능     │   │ 시간 + 인과      │    │
│  │              │   │              │   │                  │    │
│  │ 대표:        │   │ 대표:        │   │ 대표:            │    │
│  │ - Mem0       │   │ - Cognee     │   │ - Letta          │    │
│  │ - Verba      │   │ - Graphiti   │   │ - Generative     │    │
│  │ - OpenAI Mem │   │ - Zep(그래프)│   │   Agents         │    │
│  │              │   │              │   │ - MemoryBank     │    │
│  └──────────────┘   └──────────────┘   └──────────────────┘    │
│                                                                 │
│            (실제 제품은 거의 모두 하이브리드)                     │
└─────────────────────────────────────────────────────────────────┘

각 모델의 강점과 약점은 명확하다.

모델	강점	약점	잘 맞는 워크로드
Vector	빠른 검색, 단순한 정신모델, 풍부한 인프라	관계 추론 약함, "왜"를 모름	챗봇 FAQ, 문서 RAG, 사용자 선호
Graph	다중 홉 추론, 명확한 사실, 갱신 가능	추출 비용, 스키마 설계 부담	CRM, 코드베이스, 조직도
Episodic	시간 + 인과, 사건의 흐름	무겁다, 회상 알고리즘 복잡	캐릭터 에이전트, 장기 동반자, 시뮬레이션

실제 제품에서는 거의 모두가 두 가지 이상을 섞는다. Zep은 벡터 + 그래프 + 시간축이고, Letta는 episodic + semantic + procedural을 운영체제처럼 묶고, Mem0는 벡터 중심에 그래프 모드를 옵션으로 단다.

2장 · 메모리 분류 — Short-term / Working / Long-term

라이브러리를 비교하기 전에 용어를 정리하자. 2026년 시점에서 거의 모든 메모리 시스템이 동의하는 계층은 다음과 같다.

┌────────────────────────────────────────────────────┐
│                                                    │
│  Short-term Memory (단기)                          │
│   = LLM 컨텍스트 윈도우 자체                       │
│   = 현재 턴에 보이는 모든 메시지                   │
│   = 세션 끝나면 사라진다                           │
│                                                    │
├────────────────────────────────────────────────────┤
│                                                    │
│  Working Memory (작업)                             │
│   = 에이전트의 "스크래치패드"                      │
│   = 현재 태스크에 관련된 추출/요약/계획            │
│   = 컨텍스트 + 외부 스토어의 활성 페이지           │
│                                                    │
├────────────────────────────────────────────────────┤
│                                                    │
│  Long-term Memory (장기) — 3 종류                  │
│                                                    │
│   ┌──────────────────────────────────────────┐    │
│   │ Semantic   — "지식". 사실, 선호, 정의     │    │
│   │   예: "사용자는 한국에 산다"              │    │
│   │   예: "프로젝트 X는 Rust로 작성됐다"      │    │
│   └──────────────────────────────────────────┘    │
│                                                    │
│   ┌──────────────────────────────────────────┐    │
│   │ Episodic   — "사건". 시간 + 인과의 흐름   │    │
│   │   예: "지난주 화요일 A를 시도하고 실패"   │    │
│   │   예: "B 모듈을 리팩토링한 후 테스트 통과"│    │
│   └──────────────────────────────────────────┘    │
│                                                    │
│   ┌──────────────────────────────────────────┐    │
│   │ Procedural — "방법". 절차, 스킬, 패턴     │    │
│   │   예: "이 코드베이스에서 PR 여는 방식"    │    │
│   │   예: "이 사용자의 디버깅 스타일"         │    │
│   └──────────────────────────────────────────┘    │
│                                                    │
└────────────────────────────────────────────────────┘

이 분류는 인지과학에서 빌려온 것이다(Tulving 1972, Squire 1992). 2023년 Stanford의 Generative Agents 논문이 이 모델을 LLM 에이전트에 적용하면서 업계 표준이 됐다.

왜 이 계층이 중요한가?

메모리 종류마다 저장, 회상, 망각 전략이 다르다.
Semantic은 갱신/덮어쓰기가 자연스럽고, Episodic은 추가만 한다.
Procedural은 사용 빈도로 가중치를 주고, Semantic은 신뢰도로 가중치를 준다.
컨텍스트에 주입할 때도 우선순위가 다르다 — 시작에는 procedural, 중간에는 semantic, 마지막에 episodic.

이 분류를 머리에 넣고 라이브러리들을 보면 각자가 어디에 강한지 보인다.

3장 · Mem0 (YC) — 2026년 가장 인기있는 메모리 라이브러리

Mem0는 2024년 YC를 졸업하면서 빠르게 사실상의 표준이 됐다. 단순한 SDK, 좋은 디폴트, 그리고 "5분 안에 메모리 붙이기"라는 마케팅이 정확히 시장을 때렸다.

핵심 모델

Mem0의 정신모델은 단순하다.

대화에서 LLM이 추출할 가치가 있는 사실을 뽑는다.
사실을 임베딩해 벡터 스토어에 넣는다(중복은 LLM이 합친다).
새 메시지에 대해 유사도 검색으로 관련 사실을 회상한다.
컨텍스트에 끼워서 모델을 호출한다.

from mem0 import Memory

m = Memory()

# 사용자 메시지에서 사실 자동 추출
m.add("내 이름은 영주이고, Postgres를 쓴다", user_id="user-42")

# 다음 턴에 회상
results = m.search("DB 뭐 쓰지?", user_id="user-42")
# -> [{"memory": "사용자는 Postgres를 쓴다", "score": 0.91, ...}]

내부적으로 Mem0는 두 번의 LLM 호출을 한다:

추출 호출 — 메시지에서 사실을 뽑고, 기존 사실과 충돌하면 갱신/삭제 결정
검색 호출은 LLM이 아니라 임베딩 유사도

이 "추출 호출" 비용이 Mem0의 가장 큰 단점이자 가장 큰 강점이다. 비용은 들지만, 노이즈가 적은 메모리가 쌓인다.

그래프 모드와 멀티 에이전트

2025년 중반 Mem0는 Graph Memory 기능을 GA했다. Neo4j를 백엔드로 엔티티/관계를 함께 저장한다. 사용자 - 프로젝트 - 도구의 관계를 추론해야 하는 시나리오에서 유리하다.

또한 multi-actor 메모리 — user_id 외에 agent_id, run_id로 메모리를 분리한다. 멀티 에이전트 시스템에서 각 에이전트가 자기 기억을 갖는다.

Mem0의 위치

가장 잘 맞는 곳: 챗봇, 어시스턴트, 사용자 선호 기반 추천
가장 안 맞는 곳: 복잡한 코드베이스 추론, 장기 시뮬레이션, 학술 연구
한 줄 평: "2026년에 메모리를 처음 붙인다면 90%는 Mem0로 시작한다"

4장 · Zep — 그래프 + 벡터 하이브리드 (Series A)

Zep은 2024년 Series A를 받으며 엔터프라이즈 메모리 카테고리에서 자리를 잡았다. 차별점은 그래프 + 벡터 + 시간축의 하이브리드다.

핵심 컴포넌트 — Graphiti

Zep의 엔진은 Graphiti라는 오픈소스 KG(Knowledge Graph) 프레임워크다. Graphiti가 하는 일:

대화/문서에서 엔티티와 관계를 추출한다.
추출된 사실을 시간 양방향 KG에 넣는다. 즉 사실마다 valid_from / valid_to 시간이 있다.
같은 엔티티의 모순되는 사실이 들어오면, 새 사실을 valid로 만들고 옛 사실은 invalid 처리(완전 삭제 아님).
회상 시 그래프 트래버설 + 벡터 유사도 + 시간 필터를 결합한다.

from zep_python.client import Zep
from zep_python.types import Message

client = Zep(api_key="...")
client.user.add(user_id="user-42", first_name="영주")

# 메시지 추가 — Zep이 자동으로 KG에 통합
client.memory.add(
    session_id="sess-1",
    messages=[Message(role="user", content="회사를 Acme에서 Bravo로 옮겼다")],
)

# 회상 — 그래프 사실 + 관련 메시지
mem = client.memory.get(session_id="sess-1")
# -> facts: ["사용자는 Bravo에 근무한다 (이전: Acme)"]

시간 추론이 왜 중요한가

전통 벡터 메모리의 약점: 새 사실이 들어와도 옛 사실이 살아남는다. "유저는 Acme에 근무한다"와 "유저는 Bravo에 근무한다"가 둘 다 회상돼서 모델을 혼란시킨다.

Zep/Graphiti는 이걸 bi-temporal 모델로 푼다. 사실이 언제 사건이 발생했는지 + 언제 DB에 들어왔는지 둘 다 기록한다. 그래서 회상 시 "지금 시점에 valid한 사실만"을 자연스럽게 필터링한다.

Zep의 위치

가장 잘 맞는 곳: CRM, 영업 어시스턴트, 장기 운영 에이전트, 규제 산업
가장 안 맞는 곳: 단순 챗봇, 빠른 프로토타입
한 줄 평: "엔터프라이즈에서 '사실의 일관성'이 중요하면 Zep"

5장 · Letta (구 MemGPT) — 에이전트 OS 접근

Letta(구 MemGPT)는 UC Berkeley에서 시작한 프로젝트로, 2024년 Letta로 사명을 바꾸며 회사화됐다. 다른 라이브러리와 결이 다르다 — 메모리 라이브러리가 아니라 메모리 중심의 에이전트 런타임이다.

핵심 아이디어 — Memory as OS

Letta의 발상은 운영체제의 가상 메모리다.

LLM 컨텍스트 윈도우 = RAM
외부 메모리(벡터 + KV 스토어) = 디스크
LLM 자체가 도구 호출로 자기 메모리를 페이지 인/아웃한다.

구체적으로 Letta 에이전트는 항상 다음 컨텍스트를 갖는다:

Core memory — 사용자 페르소나 + 자기 페르소나(고정, 매 턴 보임)
Conversation buffer — 최근 메시지(롤링)
Archival memory — 외부 벡터 스토어(검색으로 접근)
Recall memory — 모든 과거 메시지(검색으로 접근)

에이전트는 도구를 통해 자기 메모리를 편집한다.

from letta_client import Letta

client = Letta(base_url="http://localhost:8283")
agent = client.agents.create(
    name="my-agent",
    memory_blocks=[
        {"label": "human", "value": "사용자는 한국에 사는 ML 엔지니어"},
        {"label": "persona", "value": "도움이 되는 AI 동료"},
    ],
)

# 대화. 에이전트는 자기 판단으로 core memory를 갱신한다
client.agents.messages.create(
    agent_id=agent.id,
    messages=[{"role": "user", "content": "방금 Bravo로 이직했어"}],
)
# -> 에이전트는 core_memory_replace 도구를 호출해 "human" 블록을 갱신

Letta의 차별점

상태가 서버에 산다. Letta 에이전트는 stateless 호출이 아니다 — Letta 서버에 영구 상태로 존재한다.
에이전트 간 메시지 — 에이전트들이 서로 메시지를 보낼 수 있다. 멀티 에이전트 자연스러움.
셀프 수정 메모리 — 에이전트가 자기 페르소나/사용자 프로필을 직접 편집한다. 좋게도 나쁘게도.

Letta의 위치

가장 잘 맞는 곳: 상시 실행 어시스턴트, 멀티 에이전트 협업, 캐릭터/동반자 에이전트
가장 안 맞는 곳: 순간적 RAG, stateless API 서비스
한 줄 평: "메모리를 일급 시민으로 두는 에이전트 OS가 필요하면 Letta"

6장 · Cognee — 지식 그래프 자동 생성

Cognee는 2024년에 등장한 오픈소스 프로젝트로, "데이터 → KG 자동 변환"에 집중한다. 메모리라기보다 에이전트용 KG 빌더에 가깝다.

파이프라인 — ECL (Extract, Cognify, Load)

ETL을 흉내낸 ECL:

Extract — 문서/대화/코드를 가져온다.
Cognify — LLM이 엔티티/관계/온톨로지를 추출한다. DataPoint라는 추상화를 둔다.
Load — 그래프 DB(Neo4j, Kuzu, NetworkX)와 벡터 DB(LanceDB, Qdrant, ...)에 저장한다.

import cognee

await cognee.add("프로젝트 X는 Rust로 작성됐고 Y에 의존한다")
await cognee.cognify()

results = await cognee.search(
    query_type="GRAPH_COMPLETION",
    query_text="프로젝트 X는 어떤 언어로 작성됐지?",
)
# -> "Rust"

다른 라이브러리와의 차이

Mem0는 사실 한 줄을 회상한다.
Zep은 사실 + 관련 메시지를 회상한다.
Cognee는 그래프 패턴을 회상한다 — "X 노드에 연결된 Y 타입 노드들"처럼.

Cognee의 위치

가장 잘 맞는 곳: 문서 KG, 코드베이스 KG, 도메인 지식 그래프
가장 안 맞는 곳: 빠른 채팅 메모리, 사용자 선호
한 줄 평: "KG가 메모리의 형태라면 Cognee"

7장 · Anthropic Memory API (2025 미리보기)

Anthropic은 2025년에 Memory API 프리뷰를 공개했다. 핵심 입장: 메모리는 서버 측 상태여야 한다.

모델

Anthropic Memory의 모델은 다음과 같다.

Conversation state는 Anthropic이 호스팅한다. 클라이언트는 conversation_id만 보낸다.
컨텍스트 윈도우 압박이 차오르면 Claude가 자동 압축을 수행한다(Claude Code의 compact가 API에 들어온 것).
그 외에 명시적 메모리 도구들이 제공된다 — memory_save, memory_recall, memory_list 등 — 그래서 Claude가 자기 판단으로 메모리를 적을 수 있다.

import anthropic

client = anthropic.Anthropic()

resp = client.messages.create(
    model="claude-sonnet-4-7",
    conversation_id="conv-42",   # 서버 측 상태 식별자
    memory={"enabled": True, "scope": "user-42"},
    messages=[{"role": "user", "content": "내가 어제 말한 그 책 다시 알려줘"}],
)
# Anthropic이 conv-42의 과거를 참조해서 응답을 만든다

왜 이게 큰 변화인가

지금까지 모든 메모리는 클라이언트 책임이었다. 컨텍스트를 모으고, 압축하고, 다시 보내는 것 모두.
서버 측 메모리는 그 부담을 모델 제공자에게 넘긴다. 그리고 모델이 자기 메모리를 가장 잘 안다 — 모델 내부 표현과 정렬된 압축이 가능하다.
단점: 벤더 락인. 메모리가 Anthropic 서버에 있으면 모델을 못 바꾼다.

Anthropic Memory의 위치

가장 잘 맞는 곳: Claude를 깊게 쓰는 제품, 빠른 출시, 클라이언트 단순화
가장 안 맞는 곳: 멀티 모델 라우팅, 자체 호스팅 요구, 메모리 데이터 소유권
한 줄 평: "Claude만 쓸 거고 빨리 출시하면 Anthropic Memory"

8장 · OpenAI Memory — 컨슈머 ChatGPT 기능

OpenAI Memory는 결이 다르다. 개발자용 SDK가 아니라 소비자 ChatGPT의 기능이다.

어떻게 작동하나

사용자가 ChatGPT와 대화하면 GPT가 가치 있는 사실을 자동 저장(2024년 초 GA).
"Memory updated"라는 인디케이터가 떠서 사용자가 인지한다.
Settings에서 메모리 목록을 보고 삭제할 수 있다.
2025년에 "Improved Memory" 업데이트로 모든 과거 대화를 참조 가능으로 확장.

개발자에게 의미하는 것

OpenAI Memory는 API에는 없다. 즉:

ChatGPT 사용자 경험은 메모리를 기본값으로 받아들이게 됐다. 이게 사용자 기대치를 만들었다 — "내 AI는 나를 기억해야 한다".
API로 같은 걸 만들고 싶으면 직접 짜거나 Mem0/Zep을 써야 한다.
단, 2025년부터 OpenAI Assistants API는 thread + 파일 + vector store 형태로 비슷한 걸 제공한다.

이 카테고리에서 OpenAI의 위치는 시장 교육자다. 일반 사용자가 "AI 메모리"가 뭔지 알게 했고, 그게 다음 카테고리(Mem0, Zep, Letta)의 성장 연료가 됐다.

9장 · Graphiti — Zep의 KG 프레임워크 (오픈소스)

Graphiti는 Zep이 2024년 오픈소스화한 KG 프레임워크다. Zep 제품의 엔진이지만, 단독으로도 쓸 수 있다.

핵심 디자인

Graphiti의 슬로건: "Temporal Knowledge Graphs for AI Agents".

모든 노드/엣지에 valid_from / valid_to 시간 속성.
새 정보가 들어오면 LLM이 기존 엣지와의 모순을 판단해 invalid 처리.
회상 시 시간 + 그래프 + 벡터를 결합한 하이브리드 검색.

from graphiti_core import Graphiti
from datetime import datetime

g = Graphiti("neo4j://localhost:7687", "neo4j", "password")
await g.build_indices_and_constraints()

await g.add_episode(
    name="meeting-2026-05-15",
    episode_body="영주가 Bravo로 이직했다. 직책은 Staff Engineer.",
    source_description="회의 노트",
    reference_time=datetime.now(),
)

results = await g.search("영주 어디 근무?")
# -> [{"fact": "영주는 Bravo에 근무한다", "valid_at": "2026-05-15"}]

다른 KG 프레임워크와의 차이

LangChain의 KG 메모리 — 시간 없음, 모순 처리 약함.
Neo4j LLM Graph Builder — 추출은 되지만 회상 추상화 없음.
LlamaIndex KG Index — 정적, 갱신/모순 어려움.

Graphiti의 차별점은 시간 + 모순 처리가 1급 시민이라는 것이다.

Graphiti의 위치

가장 잘 맞는 곳: Zep 백엔드, 자체 KG 메모리 구축, 시간 추론이 핵심인 도메인
가장 안 맞는 곳: KG를 안 쓰는 단순 RAG
한 줄 평: "Zep 클라우드 안 쓰고 KG 메모리만 원하면 Graphiti"

10장 · Verba (Weaviate) / Cody Memories (Sourcegraph) / MemPress

이 셋은 좁은 도메인에 특화된 메모리 시스템들이다.

Verba (Weaviate)

Weaviate가 만든 오픈소스 RAG 챗봇 프레임워크.
벡터 메모리에 집중하고, Weaviate를 백엔드로 깊게 통합.
메모리 자체보다 "RAG + 채팅 + 메모리"의 풀스택 데모 성격.
잘 맞는 곳: 사내 문서 챗봇을 Weaviate 위에 빨리 올리고 싶을 때.

Cody Memories (Sourcegraph)

Sourcegraph의 코드 어시스턴트 Cody에 들어간 메모리 기능.
코드베이스 컨텍스트 + 사용자 코딩 선호 + 프로젝트 컨벤션을 저장.
일반 메모리 SDK가 아니라 코드 도메인 전용. "이 사용자는 tabs를 쓰고, snake_case를 선호한다" 같은 사실.
잘 맞는 곳: 코드 어시스턴트의 "이 코드베이스에서의 나"를 기억해야 할 때.

MemPress

2025년에 등장한 에이전트 메모리 압축 라이브러리.
핵심 아이디어: 메모리가 쌓이면 LLM으로 계층적 요약을 만들어 검색을 빠르게 한다.
트리 구조: 원본 메시지 → 일자별 요약 → 주간 요약 → 월간 요약.
회상 시 위에서 아래로 내려가며 점점 디테일을 가져온다.
잘 맞는 곳: 메모리가 수만 건 이상 쌓이는 장기 운영 에이전트.

11장 · Generative Agents (Stanford 2023) — 학술 inspiration

상용 메모리 시스템의 거의 모든 디자인은 2023년 Stanford의 논문 "Generative Agents: Interactive Simulacra of Human Behavior"에 빚지고 있다.

실험

25명의 AI 캐릭터가 작은 마을(Smallville)에서 살아간다.
각자가 페르소나, 직업, 관계, 일정을 갖는다.
사용자 입력 없이 캐릭터들끼리 상호작용하며 하루를 보낸다.
결과: 자발적인 사회적 행동이 나타난다 — 발렌타인 파티가 자발적으로 조직되고, 시장 선거 캠페인이 벌어진다.

메모리 아키텍처

논문이 제안한 3 컴포넌트:

Memory Stream — 모든 관측을 자연어로 기록(에피소딕).
Reflection — 주기적으로 LLM이 메모리를 읽어 고차 추론을 생성("나는 친구가 많지 않다"). 이게 메모리로 다시 들어간다.
Planning — 메모리 + 반영을 바탕으로 하루 계획을 세운다.

회상은 importance + recency + relevance 3 점수의 가중합.

score = α·importance + β·recency + γ·similarity

이 식은 지금도 거의 모든 메모리 시스템의 회상 알고리즘 기본형이다.

Generative Agents의 유산

Reflection 개념 — Mem0의 추출, Zep의 사실 일관성, Letta의 self-edit이 모두 여기서 파생.
Importance 점수 — 모든 사실이 동등하지 않다는 발상이 표준화됨.
Episodic-first — 의미 메모리는 에피소딕에서 파생된다는 모델.

학술 논문 한 편이 한 카테고리 전체의 디자인 언어를 만든 드문 사례다.

12장 · 저장 백엔드 — pgvector / Qdrant / Neo4j / Memgraph / Kuzu

메모리 라이브러리들은 결국 어디엔가 데이터를 쌓아야 한다. 2026년에 자주 쓰이는 백엔드들.

벡터 백엔드

백엔드	특징	잘 맞는 상황
Postgres + pgvector	운영 부담 적음, SQL 자유도, 트랜잭션	이미 Postgres가 있는 팀, 메모리 + 메타데이터 조인
Qdrant	Rust로 빠름, 필터링 강력, 셀프호스트 친화	100M+ 벡터, 복잡한 페이로드 필터
Pinecone	매니지드, 빠른 도입, 좋은 SLA	인프라 안 하고 싶을 때
Weaviate	멀티모달, GraphQL, 모듈러	텍스트 외 모달리티, 자체 변환 파이프라인
LanceDB	임베디드, Arrow 기반, 로컬 친화	노트북/엣지 에이전트
Chroma	로컬 친화, DX 단순	프로토타입, 데모

그래프 백엔드

백엔드	특징	잘 맞는 상황
Neo4j	KG 표준, Cypher 풍부	엔터프라이즈, 대형 KG
Memgraph	C++로 빠름, Neo4j 호환	실시간 KG, 스트리밍
Kuzu	임베디드, OLAP 컬럼 그래프	분석형 KG, 노트북
NetworkX	Python 인메모리	프로토타입, 소규모
AWS Neptune	매니지드, Gremlin	AWS 생태계

2026년 실전 가이드

시작은 Postgres + pgvector 단일 DB. 메모리 + 앱 데이터를 같이 두면 운영이 단순하다.
그래프가 필요해지면 Kuzu(임베디드)부터 본다. Neo4j는 운영 부담이 크다.
벡터 + 그래프를 둘 다 영구적으로 쓸 거면 Postgres + pgvector + AGE(Apache AGE 그래프 확장)도 1 DB 후보다.
회상 레이턴시가 문제가 되면 Qdrant/Pinecone으로 분리.

13장 · 한국 / 일본 — Upstage, NAVER HCX, Sakana, PFN

한국

Upstage — 자체 모델 Solar에 RAG/메모리 레이어 통합. 한국어 의미 검색 품질에서 강점. 엔터프라이즈 어시스턴트 시나리오.
NAVER HyperCLOVA X — HCX에 메모리 기능 내장. 네이버 생태계(블로그, 카페, 쇼핑) 데이터와 연결한 컨슈머 메모리가 차별점.
카카오 — 카카오톡 안의 AI 어시스턴트가 사용자 메모리를 운영. 메신저 컨텍스트가 풍부해서 메모리 자동 추출에 유리.
일반 트렌드: 한국 팀은 Mem0/Zep을 그대로 쓰기보다 한국어 임베딩 모델(Upstage, Cohere multilingual)과 직접 결합해 자체 메모리 레이어를 짜는 경우가 많다.

일본

Sakana AI — "진화적 모델 병합"으로 유명하지만, 2025년부터 에이전트 메모리 연구도 발표. 모델 자체에 메모리를 통합하는 접근에 관심.
Preferred Networks (PFN) — PLaMo 모델 시리즈에 장기 컨텍스트 + 외부 메모리 결합 연구.
Rinna / ELYZA — 일본어 특화 모델을 만드는 곳들. 메모리는 자체보다 Mem0/Zep을 일본어 임베딩과 결합해 쓰는 분위기.
일반 트렌드: 일본은 캐릭터/동반자 에이전트 시장이 커서 Letta형 영구 페르소나 메모리 수요가 강하다. 게임/엔터테인먼트 결합 사례가 미국보다 많다.

14장 · 누가 무엇을 골라야 하나

시나리오별 권고를 한 장으로 압축.

시나리오	1순위	2순위	피해야 할 것
빠른 사용자 선호 메모리 (챗봇, FAQ)	Mem0	OpenAI Assistants threads	KG 빌드
엔터프라이즈, 사실 일관성 (CRM, 영업)	Zep	Graphiti 직접 + Neo4j	순수 벡터 + 자동 망각
멀티 에이전트, 영구 페르소나	Letta	Mem0 multi-actor 모드	stateless API + 클라이언트 단순 메모리
코드 어시스턴트 메모리	Cody Memories(SaaS) 또는 자체 + Mem0	Cognee(코드베이스 KG용)	일반 챗 메모리 그대로 사용
도메인 KG 빌드 (제약, 법무)	Cognee	Graphiti	벡터만으로 해결 시도
사내 문서 RAG + 메모리	Verba	Mem0 + 자체 RAG	메모리 없이 RAG만
Claude 중심 제품, 빠른 출시	Anthropic Memory API	Mem0 + Claude	자체 컨텍스트 매니지먼트
장기 시뮬레이션, 캐릭터 에이전트	Letta + Generative Agents 아이디어	MemPress(압축)	윈도우만 키우기
연구, 실험	Generative Agents 코드 베이스 + 자체	LlamaIndex Memory + 자체 KG	SaaS 메모리(블랙박스)
메모리가 너무 커져서 느려짐	MemPress(요약 트리)	Zep(자체 요약)	단순 TTL 만료

결정 트리

시작
  │
  ├─ 메모리에 "왜 / 언제 / 무엇이 바뀌었는지"가 중요한가?
  │     YES → 그래프/시간 메모리 필요 → Zep 또는 Cognee+Graphiti
  │     NO  → 다음
  │
  ├─ 에이전트가 항상 켜져 있고, 자기 페르소나를 가져야 하나?
  │     YES → Letta
  │     NO  → 다음
  │
  ├─ Claude 한 모델만 쓰고, 단순함이 최우선인가?
  │     YES → Anthropic Memory API
  │     NO  → 다음
  │
  ├─ 그냥 "사용자 선호 + 사실"을 기억하고 회상하면 되나?
  │     YES → Mem0
  │     NO  → 위로 돌아가 다시 정의
  │
  └─ 메모리가 수십만 건 넘게 쌓일 예정인가?
        YES → 위 선택 + MemPress로 압축 계층

에필로그 — 메모리는 2026년 AI 인프라의 다음 결정 지점

2023~2024년 인프라 토론은 벡터 DB였다. 2025년은 에이전트 프레임워크였다. 2026년의 토론은 메모리 아키텍처다.

세 가지 큰 흐름을 기억하자.

순수 벡터 메모리는 첫 단계일 뿐이다. 시간/모순/관계가 들어오면 그래프나 episodic이 필요해진다.
메모리는 모델보다 오래 산다. 모델은 6개월마다 바뀌지만, 사용자 메모리는 몇 년을 가야 한다. 그래서 데이터 포터빌리티가 결정적이다 — 메모리를 SaaS에 가두지 말 것.
메모리는 평가가 어렵다. 벤치마크 표준이 미숙하다. 자체 회상 평가 셋(질문 → 기대 사실)을 만드는 게 가장 안전하다.

"에이전트의 지능은 모델로 결정되지만, 에이전트의 유용성은 메모리로 결정된다."

같은 모델이라도 메모리 시스템이 다르면 완전히 다른 어시스턴트가 된다. 그래서 메모리 선택을 인프라 결정으로 다뤄야 한다 — 모델 선택만큼 무겁게.