"Memory Systems — 컨텍스트 밖에서 정보를 보존하는 법 (하네스 시리즈 3/6)"

-

Part 2에서 컨텍스트 윈도우는 작게 쓰는 게 답이라고 했다. 그럼 옛 정보는 어디로 가는가? 답은 외부 메모리 시스템. 2026년 들어 메모리 자체가 별도 인프라 영역이 됐다.

이 글은 LLM 에이전트의 메모리를 다룬다. 단기·장기·세 종류, 벡터 vs 그래프, Mem0/Zep 같은 솔루션, 그리고 직접 구축할 때 SQLite+FTS5와 Pinecone 사이 어디가 실용적 출발점인지.

시리즈 (6편)

  1. 하네스 엔지니어링이란
  2. Context Engineering
  3. Memory Systems ← 이 글
  4. Tools & Sandboxing
  5. Multi-Provider Routing
  6. Evaluation & Ops

1. 메모리 = 컨텍스트 윈도우의 연장이 아니다

흔한 오해: "컨텍스트가 메모리다."

정확한 구분: - 컨텍스트 = 현재 turn의 모델 입력 (휘발성, 비용 발생) - 메모리 = 세션을 넘어 보존하는 외부 저장 (영속, 검색 가능)

컨텍스트는 매 turn 새로 채워진다. 메모리는 매 turn 어떤 부분만 골라 컨텍스트에 주입된다.

2026년 합의: "메모리는 first-class 아키텍처 컴포넌트다." 자체 벤치마크(LoCoMo, LongMemEval), 자체 연구 문헌, 측정 가능한 성능 격차, 전용 도구 생태계가 형성됨.

2. 세 가지 메모리 유형

2-1. Episodic (일화 기억)

무엇이 일어났는가. 시간 순서가 있는 사건들. - "사용자가 어제 X 함수를 만들었다" - "지난 세션에서 인증 모듈을 리팩터했다"

2-2. Semantic (의미 기억)

무엇을 알고 있는가. 시점 무관 사실. - "사용자는 Python 개발자" - "프로젝트는 PostgreSQL을 쓴다"

2-3. Procedural (절차 기억) — 2026년 새로 도입

어떻게 하는가. 반복되는 절차를 저장. - "이 프로젝트의 PR 절차: lint → test → review → merge" - "이 사용자는 commit 전에 conventional commits 형식 검증"

Mem0 v1.0.0 API에서 명시적으로 추가됨 (2026). 이전에는 episodic + semantic만 있었음.

3. 벡터 vs 그래프 vs SQL/FTS5

벡터 메모리 (semantic search)

  • 질문을 임베딩 → 가장 유사한 메모리 N개 회수
  • 장점: 의미적 근접, fuzzy 매칭
  • 단점: 정확한 관계 표현 약함

예: 사용자가 "Python 언급함"을 검색하면 잘 찾음.

그래프 메모리 (relational reasoning)

  • 사건·엔티티·관계를 그래프로 저장
  • 장점: 다단계 추론 ("X가 Y의 무엇이고, Y는 Z의 일부")
  • 단점: 구축·유지 비용 ↑

예: "사용자는 Python 개발, 데이터 파이프라인 담당, pandas 사용, 회사는 dbt 사용, Spark에서 마이그레이션 중" — 이런 연결된 사실을 회수.

SQL + FTS5 (키워드 + 구조화)

  • SQLite의 FTS5 모듈은 빠르고 가벼운 키워드 검색
  • 장점: 인프라 zero (단일 파일), 4,300 메모리 검색 1ms 미만
  • 단점: fuzzy 검색 약함, 임베딩 의미 검색 없음

Pinecone p95 지연 25~50ms. SQLite+FTS5는 같은 규모에서 1ms 미만. 단순 키워드 매칭이면 SQL이 압승.

하이브리드 (RRF — Reciprocal Rank Fusion)

  • 벡터 검색 결과 top-N + FTS5 결과 top-N → RRF로 결합
  • 의미 + 키워드 양쪽 강점 활용
  • OpenClaw memcore와 wikycore가 이 패턴 사용

4. 솔루션 비교 (2026-04 기준)

Mem0 (managed)

  • 포지션: 사용자 personalization + 비용 효율 최적화
  • 핵심 기술: Memory Compression Engine — chat history를 고밀도 표현으로 압축
  • 효과: prompt 토큰 80% 절감 주장
  • 가격: 관리형 SaaS. 자체 호스팅도 가능 (open source).

Zep (graph)

  • 포지션: 시간 인식 지식 그래프
  • 핵심 기술: Temporal Knowledge Graph — 사실의 시점까지 저장
  • 장점: "X가 과거에는 Python을 썼지만 현재는 Rust" 같은 시간 의존 질의 가능
  • 지연: 서브초

Memanto (학술)

  • arXiv 2604.22085
  • "Typed Semantic Memory with Information-Theoretic Retrieval for Long-Horizon Agents"
  • 정보이론 기반 회수 — 메모리 항목을 불확실성 감소로 정렬

MemMachine (학술)

  • arXiv 2604.04853
  • "Ground-Truth-Preserving Memory System for Personalized AI Agents"
  • 원본 정보 보존을 우선하는 압축 정책

memcore (OpenClaw)

  • SQLite + 벡터 + RRF + memory layers (3-tier)
  • Plan / Lessons / Sessions 패턴
  • v0.5에서 MemPalace 기법 도입 (위치 기반 회상)

5. 실전 패턴

5-1. 3-Layer Memory (CLAUDE.md 표준)

Layer 1: Project Knowledge (docs/) — 영구, 키워드 인덱스
Layer 2: Behavioral Rules (lessons.md) — 무엇을 할/말 것인가
Layer 3: Session Restore (sessions/) — 휘발성 스냅샷

CLAUDE.md 패턴은 이 3계층을 권장. Claude Code, OpenClaw, Hermes 모두 이 골조 사용.

5-2. Auto-Harvesting

세션 종료 시 자동으로 새 학습을 적절한 레이어에 저장: - 에러 해결 → lessons.md - 새 도메인 지식 → docs/{category}/ - 진행 상태 → sessions/

CLAUDE.md "Automatic Memory Harvesting (Instinct Pattern)" 섹션이 이 흐름.

5-3. Dedup + Cascade Update

  • 같은 패턴 2회 → 규칙 승격 (lessons.md count 증가)
  • 새 정보가 기존 메모리와 충돌 → 충돌 표시 + 사용자 확인
  • 한 사실 변경 → memory-map.md로 연결된 다른 파일까지 검토

5-4. Eviction 정책

무한 누적은 노이즈만 늘림. 정책 예: - Time-based: 90일 이상 미사용 → archive - Use-based: count < 2이고 30일 미사용 → 제거 - LRU: 컨텍스트 압박 시 가장 오래된 것부터

6. SQL vs Vector — 어느 것부터?

시작 단계 (개인 프로젝트, 사용자 1명)

SQL + FTS5 단독 - SQLite 파일 1개로 시작 - 100~10,000 메모리 규모는 충분 - 인프라 zero, 백업 = 파일 복사 - OpenClaw memcore 초기 버전이 이렇게 시작했음

중간 단계 (다중 사용자, 1만 메모리 이상)

SQL + FTS5 + 벡터 (하이브리드) - Chroma 또는 Qdrant 추가 - bge-m3 임베딩 (oMLX에서 무료 로컬 가능) - RRF로 결과 결합

대규모 (수백만 메모리)

Mem0 / Zep / 자체 인프라 - Mem0: 사용자 인격 추출 자동화 - Zep: 시간 그래프 + 복잡 관계 - 자체 구축: ElastiCache + Neptune Analytics (AWS) 패턴

7. Anti-patterns

7-1. "벡터 DB 안 쓰면 후진"

4,300 메모리에서 SQLite+FTS5는 1ms, Pinecone p95는 25~50ms. 인프라 비용도 SQLite가 zero. 시작은 SQL.

7-2. "다 넣자, 어차피 검색하면 됨"

무한 누적 → 노이즈 폭발. eviction 정책 없으면 1년 후 검색 정확도 떨어짐.

7-3. "메모리는 한 번 쓰고 끝"

메모리는 살아있는 시스템. 갱신·충돌 해결·archive 흐름 없으면 stale 메모리가 잘못된 답으로 이끔.

CLAUDE.md 인용: "memory records can become stale over time. Verify before using."

7-4. "임베딩 모델 한번 정하고 끝"

임베딩 모델이 바뀌면 기존 벡터 무용지물. 마이그레이션 비용 막대. 처음에 잘 골라야 함 (bge-m3, voyage-3 같은 검증된 것).

8. Knowledge Graph (KG) 관점

2026년 들어 그래프 메모리가 부상. 이유: - LLM이 multi-hop reasoning을 잘 못함 (벡터 단독 회수의 한계) - 사실 간 관계가 단순 유사도로 잡히지 않음 - 시간 차원 (X 사실이 언제 진실이었는가) 표현

KG 메모리 구축 흐름

  1. 입력 (대화·문서) → entity 추출
  2. entity 간 관계 추출 (LLM이 직접 추출하거나 NER + 관계 분류기)
  3. 그래프 저장 (Neo4j, Neptune, 자체 SQLite)
  4. 질의 시 starting node → graph traversal → 관련 사실 회수

비용 vs 가치

  • 구축: 매 입력마다 LLM 호출 → 비용 ↑
  • 검색: graph traversal은 빠름
  • 가치: multi-hop 질의에서 질적 차이

권장: 사용자별 personal assistant라면 Zep 같은 KG 메모리 권장. 단일 작업 에이전트(예: 코딩)라면 hybrid (SQL+벡터)로 충분.

정리

메모리 결정 권장
시작점 SQLite + FTS5
의미 검색 추가 + 벡터 (Chroma/Qdrant) + bge-m3
관계 추론 필요 KG (Zep)
사용자 personalization Mem0
학술적 최첨단 Memanto / MemMachine

핵심 한 문장: "메모리는 컨텍스트의 연장이 아니라 별도 시스템이다."

다음 편(4/6)은 에이전트가 실제로 행동하는 영역 — Tools & Sandboxing.

참고 자료 (1차 출처)

  • Mem0 State of AI Agent Memory 2026: mem0.ai/blog/state-of-ai-agent-memory-2026
  • Memanto 논문: arxiv.org/abs/2604.22085
  • MemMachine 논문: arxiv.org/abs/2604.04853
  • AWS Mem0 + Neptune 통합: aws.amazon.com/blogs/database/build-persistent-memory-for-agentic-ai
  • Zep Temporal Knowledge Graph: getzep.com

댓글

댓글 쓰기

이 블로그의 인기 게시물

"LLM 핵심 학습 (1/6) — 기본: 토큰화·임베딩·어텐션·위치 인코딩"

-
이미지
(시리즈 시작) 📚 시리즈 목차 2/6 파인튜닝 → 트랜스포머 한 블록의 데이터 흐름을 문자열 → 토큰 → 임베딩 → 어텐션 → 출력 표현 까지 손으로 풀어 본다. 이번 편이 끝나면 "왜 \(\sqrt{d_k}\)로 나누는가", "RoPE는 무엇을 회전시키는가", "한국어가 영어보다 토큰이 많은 까닭은 무엇인가"가 한 줄로 설명될 수 있다. 0. 학습 목표 이 편을 마치면 다음을 직접 할 수 있다. BPE 토크나이저 가 어휘를 어떻게 학습하고 새 문자열을 어떻게 자르는지 종이 위에서 시뮬레이션한다. 임베딩 행렬 의 모양과 초기화, weight tying의 의미를 한 줄로 설명한다. Scaled Dot-Product Attention 의 식을 차원 단위로 추적하고 PyTorch 30줄로 재현한다. Multi-Head Attention 이 한 헤드와 비교해 무엇이 다른지, 헤드 수가 늘면 어디가 비싸지는지 답한다. Sinusoidal·RoPE·ALiBi 세 위치 인코딩의 식과 외삽 성질을 구분한다. 컨텍스트 확장이 왜 \(O(N^2)\)인지, "Lost in the Middle"이 왜 발생하는지 설명한다. 1. 핵심 요약 트랜스포머의 입력은 문자열 이 아니라 정수 ID 시퀀스 다. 토크나이저가 문자열 → ID로 자른다. 임베딩은 정수 ID를 \(d\)차원 벡터로 lookup하는 학습 가능한 테이블이다. Self-Attention은 \(\text{softmax}(QK^\top / \sqrt{d_k}) V\) 한 줄이 핵심이고, 멀티헤드는 같은 연산을 여러 부분 공간에서 병렬화한 것이다. 위치 정보는 임베딩에 직접 더하거나(Sinusoidal), Q·K에 회전을 가하거나(RoPE), 어텐션 스코어에 거리 패널티를 더해서(ALiBi) 주입한다. 컨텍스트 길이 \(N\)에 대해 표준 어텐션은 \(O(N^2)\) 비용을 갖고, 긴 컨텍스트에서는 중간 위...
Read more »

"LLM 핵심 학습 (2/6) — 파인튜닝: LoRA·QLoRA·증류·Adapter"

-
이미지
← 1/6 기본 📚 시리즈 목차 3/6 디코딩과 생성 → 사전학습된 LLM을 내 데이터 에 적응시키는 방법을 비용·메모리·일반화 관점에서 정리한다. Full FT의 한계 → Adapter → LoRA → QLoRA → Distillation 순으로 같은 그림을 점점 확대해 본다. 0. 학습 목표 Full fine-tuning의 메모리 병목을 옵티마이저 상태·그래디언트·가중치·활성화 의 4분할로 설명한다. Adapter(Houlsby 2019)와 LoRA(Hu 2021)의 식 차이를 한 줄로 적는다. LoRA의 \(A, B\) 행렬이 왜 저랭크 이고, rank \(r\) 선택이 무엇을 결정하는지 답한다. QLoRA(Dettmers 2023)의 NF4·double-quant·paged optimizer를 분리해서 설명한다. Catastrophic Forgetting을 분포 시프트 관점에서 정의하고 완화 기법을 두 개 이상 든다. Hinton 2015의 Knowledge Distillation 식을 손으로 유도한다. 1. 핵심 요약 Full FT는 메모리/디스크/시간 모두 비싸다. 7B 모델 full FT는 V100 8장 + A100 1장으로도 큰 부담이다. PEFT(파라미터 효율 파인튜닝) 일가족은 극히 일부 파라미터만 학습 해 같은 효과를 얻는다. LoRA: \(\Delta W = BA\) (rank \(r \ll \min(d_{\text{in}}, d_{\text{out}})\))로 가중치 업데이트를 저랭크 분해. QLoRA: 베이스 모델을 4-bit(NF4)로 양자화한 채 LoRA만 풀-정밀(BF16)으로 학습. Catastrophic Forgetting: 새 분포에 적응하느라 이전 능력이 무너지는 현상. PEFT 자체가 부분 완화책. Distillation: 큰 교사 모델의 soft target 을 학습 신호로 써서 작은 학생 모델 을 만든다. 2. 직관: 왜 사전학습만으로는 부족한가 사전학습은 일반...
Read more »

"ML 기초 학습 (1/9) — 머신러닝과 sklearn: 학습의 좌표계"

-
이미지
(시리즈 시작) 📚 시리즈 목차 2/9 이웃 알고리즘 → 이 시리즈는 신경망과 로컬 LLM으로 가기 전에 손에 익혀 둬야 할 머신러닝 기초 9편이다. 1편은 모든 ML 코드가 공유하는 공통 문법 을 잡는 데 쓴다. sklearn은 그 문법을 가장 일관되게 보여주는 도구다. 이번 편이 끝나면 어떤 모델을 만나도 fit → predict → score → 평가 흐름이 같다는 것이 손에 잡힌다. 0. 학습 목표 이 편을 마치면 다음을 할 수 있어야 한다. 지도학습·비지도학습·강화학습을 한 문장씩 구분해 설명한다. sklearn의 estimator 인터페이스 ( fit , predict , score , transform )를 코드 한 화면 안에서 쓸 수 있다. train/validation/test 분할을 왜 하는지, 어디서 데이터 누수가 생기는지 식과 그림으로 설명한다. 분류·회귀의 핵심 평가 지표(accuracy, precision, recall, F1, MSE, R²)를 정의에서 직접 계산할 수 있다. k-fold 교차검증 을 코드 한 줄로 돌리고, 결과의 평균과 표준편차를 함께 보고할 수 있다. Pipeline 으로 전처리와 모델을 묶어 데이터 누수를 구조적으로 막는 방법을 설명한다. 1. 핵심 요약 머신러닝은 데이터에서 함수 \(f: X \to Y\)를 찾는 작업 이다. 어떤 모델이든 이 본질은 같다. sklearn은 모든 모델을 같은 인터페이스( fit , predict , score )로 통일해, 모델을 바꿀 때 한 줄만 바꾸면 되게 한다. train/val/test 세 분할이 표준이다. 검증으로 하이퍼파라미터를 고르고, 테스트는 마지막에 한 번만 본다. 데이터 누수 (test 정보가 train에 새는 현상)는 ML 입문자가 가장 자주 만드는 실수이며, Pipeline + cross_val_score 조합으로 구조적으로 막을 수 있다. 평가 지표는 문제 유형 (분류/회귀) 과 클래스 불균형...
Read more »