💡 왼쪽 원문을 읽으면서 오른쪽에 따라 써보세요. Tab 키로 힌트를 받을 수 있습니다.

원문 렌더가 준비되기 전까지 텍스트 가이드로 표시합니다.

프롤로그 — 컨텍스트 윈도우가 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 │ │

│ └──────────────┘ └──────────────┘ └──────────────────┘ │

│ │

│ (실제 제품은 거의 모두 하이브리드) │

└─────────────────────────────────────────────────────────────────┘

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

| 모델 | 강점 | 약점 | 잘 맞는 워크로드 |

| --- | --- | --- | --- |

실제 제품에서는 거의 모두가 **두 가지 이상을 섞는다**. 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의 정신모델은 단순하다.

1. 대화에서 LLM이 **추출**할 가치가 있는 **사실**을 뽑는다.

2. 사실을 임베딩해 벡터 스토어에 넣는다(중복은 LLM이 합친다).

3. 새 메시지에 대해 유사도 검색으로 관련 사실을 회상한다.

4. 컨텍스트에 끼워서 모델을 호출한다.

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:

1. **Extract** — 문서/대화/코드를 가져온다.

2. **Cognify** — LLM이 엔티티/관계/온톨로지를 추출한다. **DataPoint**라는 추상화를 둔다.

3. **Load** — 그래프 DB(Neo4j, Kuzu, NetworkX)와 벡터 DB(LanceDB, Qdrant, ...)에 저장한다.

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가 자기 판단으로 메모리를 적을 수 있다.

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 컴포넌트:

1. **Memory Stream** — 모든 관측을 자연어로 기록(에피소딕).

2. **Reflection** — 주기적으로 LLM이 메모리를 읽어 **고차 추론**을 생성("나는 친구가 많지 않다"). 이게 메모리로 다시 들어간다.

3. **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순위 | 피해야 할 것 |

| --- | --- | --- | --- |

결정 트리

시작

│

├─ 메모리에 "왜 / 언제 / 무엇이 바뀌었는지"가 중요한가?

│ 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년의 토론은 **메모리 아키텍처**다.

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

1. **순수 벡터 메모리는 첫 단계일 뿐이다.** 시간/모순/관계가 들어오면 그래프나 episodic이 필요해진다.

2. **메모리는 모델보다 오래 산다.** 모델은 6개월마다 바뀌지만, 사용자 메모리는 몇 년을 가야 한다. 그래서 **데이터 포터빌리티**가 결정적이다 — 메모리를 SaaS에 가두지 말 것.

3. **메모리는 평가가 어렵다.** 벤치마크 표준이 미숙하다. 자체 회상 평가 셋(질문 → 기대 사실)을 만드는 게 가장 안전하다.

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

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

참고 / References

- [Mem0 — GitHub mem0ai/mem0](https://github.com/mem0ai/mem0)

- [Mem0 Documentation](https://docs.mem0.ai/)

- [Zep — Long-Term Memory for AI Assistants](https://www.getzep.com/)

- [Zep GitHub — getzep/zep](https://github.com/getzep/zep)

- [Graphiti — GitHub getzep/graphiti](https://github.com/getzep/graphiti)

- [Graphiti Documentation](https://help.getzep.com/graphiti)

- [Letta — GitHub letta-ai/letta](https://github.com/letta-ai/letta)

- [Letta Documentation](https://docs.letta.com/)

- [MemGPT paper — Towards LLMs as Operating Systems](https://arxiv.org/abs/2310.08560)

- [Cognee — GitHub topoteretes/cognee](https://github.com/topoteretes/cognee)

- [Cognee Documentation](https://docs.cognee.ai/)

- [Anthropic Memory & Context Management](https://docs.anthropic.com/en/docs/build-with-claude/context-windows)

- [OpenAI — Memory and new controls for ChatGPT](https://openai.com/index/memory-and-new-controls-for-chatgpt/)

- [Generative Agents paper — Park et al., Stanford 2023](https://arxiv.org/abs/2304.03442)

- [Generative Agents code — joonspk-research/generative_agents](https://github.com/joonspk-research/generative_agents)

- [MemoryBank paper](https://arxiv.org/abs/2305.10250)

- [Verba — GitHub weaviate/Verba](https://github.com/weaviate/Verba)

- [Sourcegraph Cody Memory](https://sourcegraph.com/docs/cody)

- [Postgres pgvector — GitHub pgvector/pgvector](https://github.com/pgvector/pgvector)

- [Qdrant — GitHub qdrant/qdrant](https://github.com/qdrant/qdrant)

- [Weaviate](https://weaviate.io/)

- [Pinecone](https://www.pinecone.io/)

- [LanceDB — GitHub lancedb/lancedb](https://github.com/lancedb/lancedb)

- [Chroma — GitHub chroma-core/chroma](https://github.com/chroma-core/chroma)

- [Neo4j](https://neo4j.com/)

- [Memgraph](https://memgraph.com/)

- [Kuzu — GitHub kuzudb/kuzu](https://github.com/kuzudb/kuzu)

- [Apache AGE — Postgres graph extension](https://age.apache.org/)

- [LlamaIndex Memory module](https://docs.llamaindex.ai/en/stable/module_guides/deploying/agents/memory/)

- [LangChain Memory documentation](https://python.langchain.com/docs/how_to/chatbots_memory/)

- [Upstage Solar](https://www.upstage.ai/)

- [NAVER HyperCLOVA X](https://clova.ai/hyperclova)

- [Sakana AI Research](https://sakana.ai/)

- [Preferred Networks PLaMo](https://www.preferred.jp/en/projects/plamo/)

- [Tulving 1972 — Episodic and Semantic Memory](https://alicekim.ca/12.EpisodicSemantic72.pdf)