Agent Memory Architecture: Retrieval System과 Knowledge Container 선택 가이드

https://www.anthropic.com/engineering/effective-harnesses-for-long-running-agents

Author: Claude Opus 4.6, mangowhoiscloud
Purpose: Agent Memory Architecture 비교 분석 Knowledge Base
Date: 2026-02-07

Executive Summary

Agent 시스템의 메모리 구현 방식은 기술 선택을 넘어 아키텍처 철학의 문제입니다. Vector DB + RAG와 파일/MD 기반 메모리는 흔히 비교 대상으로 거론되지만, 본질적으로 retrieval system과 knowledge container로서 역할이 구분됩니다. 본 문서는 4가지 핵심 축(Retrieval Complexity, Latency & Cost, Knowledge Freshness, Cognitive Load)으로 두 접근 방식을 비교하고, Layered Memory Architecture를 정리합니다. 또한 Anthropic Engineering이 공개한 Long-Running Agent Harness(2025.11)를 파일 기반 메모리의 실전 검증 사례로 분석합니다.

---

1. 정의

Vector DB / RAG: 모르는 정보가 있을 때 가장 관련 있는 조각을 빠르게 찾기 위한 인덱스 시스템입니다.
파일 / MD / in-memory: LLM이 참고할 수 있는 정적 또는 준정적 지식 저장소입니다.

이 둘은 검색 엔진과 문서 보관함 수준으로 역할이 다릅니다. Anthropic이 Claude Code의 메모리를 CLAUDE.md라는 마크다운 파일 기반으로 설계한 것은 이 구분을 명확히 인식한 결과로 볼 수 있습니다.

"Instead of relying on complex vector databases and semantic search, Anthropic opted for a transparent, file-based approach. Memory is stored in simple Markdown files named CLAUDE.md."
— Skywork AI, "Claude Memory: A Deep Dive" (2025.09)

 
반면 MemOS 논문(2025.07)은 RAG의 구조적 한계를 다음과 같이 지적합니다:

"RAG remains fundamentally an 'on-the-fly retrieval and transient composition' pipeline, rather than an integrated memory management system. It lacks core memory manageability features such as lifecycle tracking, versioning, and permission-aware scheduling."
— MemOS: A Memory OS for AI System (arXiv, 2025.07)

---

2. 핵심 비교: 4가지 축

2.1 Retrieval Complexity (검색 난이도)

Vector DB는 embedding 기반 semantic search를 통해 키워드 매칭 없이도 의미적으로 유사한 문서를 탐색합니다. 예를 들어 query: "refund policy" → doc: "return & reimbursement" 매칭이 가능합니다.

파일 / MD / memory는 keyword search(grep), BM25, 또는 agent의 파일 순회에 의존합니다.
스케일에 따른 적합성은 다음과 같습니다:

~50	충분	과잉 설계
50~3,000	하이브리드 구간	선택적 활용
3,000+	토큰 한계 도달	권장

 
MIRIX(Wang et al., 2025.07)는 구조화된 메모리 계층을 전제로 RAG baseline 대비 35% 높은 정확도와 99.9% 스토리지 절감을 보고하였습니다. 다만 이는 단순 파일 순회가 아닌 계층적 메모리 구조에서의 결과입니다. 대규모 데이터에서의 검색 능력은 Vector DB가 우위에 있습니다.

---

2.2 Latency & Infra Cost

이 축에서는 규모에 따른 역전 현상이 관찰됩니다.
파일 / MD / memory는 embedding 생성, network hop, DB 조회가 불필요합니다. local agent + filesystem 조합은 latency 측면에서 압도적으로 유리하며, Anthropic이 Claude Code에서 이 방식을 채택한 배경이기도 합니다.

"Anthropic reports 84% token reduction in extended workflows—essentially, agents doing more with less because they're not constantly re-loading information."
— Thomas Wiegold, "Claude API Memory Tool Guide" (2025.12)

 
Vector DB는 chunking → embedding 생성 → 저장 → query embedding → ANN search로 이어지는 파이프라인 전체의 latency가 누적됩니다. Chan et al.(2024)의 CAG(Cache-Augmented Generation) 연구(ACM Web Conference 2025 발표)는 이 차이를 정량적으로 제시합니다:

• SQuAD, HotPotQA 벤치마크에서 CAG가 RAG(BM25 + OpenAI embedding) 대비 동등 이상의 정확도 달성
• retrieval step 제거로 generation time 대폭 감소
• 제한된 knowledge base 환경에서 RAG 대비 최대 40배 빠른 응답 기록

단, knowledge base가 context window 내에 수용 가능한 규모일 때 유효한 결과입니다.
소규모~중규모 데이터에서의 속도 및 비용 효율은 파일/메모리 방식이 우위에 있습니다.

---

2.3 Knowledge Freshness (지식 최신성)

운영 환경에서 간과되기 쉬운 축입니다.
Vector DB는 문서 수정 시 re-chunk → re-embed → re-index 과정이 필요합니다. 빈번한 업데이트가 발생하는 환경에서는 운영 부담이 상당합니다.
파일 / MD는 파일 수정만으로 반영이 완료됩니다. agent의 다음 호출 시점부터 즉시 적용됩니다. 나아가 git과 결합하면 버전 관리 자체가 메모리 레이어로 기능합니다. Anthropic Engineering(2025.11)은 long-running agent harness에서 git commit log를 progress file과 함께 세션 간 메모리 브릿지로 활용하였으며, agent가 잘못된 코드 변경을 git revert로 복구하고 정상 상태로 되돌릴 수 있음을 보고하였습니다. 이는 Vector DB에서는 구현하기 어려운 시점 복원(point-in-time recovery) 을 파일 기반 메모리가 자연스럽게 지원하는 사례입니다.

"The memory tool operates client-side—you control where and how the data is stored through your own infrastructure."
— Anthropic Docs, Memory Tool (2025.09)

VentureBeat(2026.01)도 이 지점을 지적합니다:

"RAG will remain useful for static data, but agentic memory is critical for adaptive assistants and agentic AI workflows that must learn from feedback, maintain state, and adapt over time."
— VentureBeat, "6 data predictions for 2026" (2026.01)

빈번히 변경되는 운영 지식(ops runbook, oncall docs 등)에서 freshness는 파일 방식이 우위에 있습니다.

---

2.4 Cognitive Load (LLM 관점)

agent 설계에서 중요도가 높은 축입니다.
Vector RAG는 retrieval 결과가 이미 관련성이 높은 조각으로 필터링되어 들어옵니다. LLM의 reasoning budget 소비가 적고, hallucination 위험이 상대적으로 낮습니다.
파일 탐색 agent는 "어디서 찾을 것인가, 어떤 파일을 읽을 것인가, 얼마나 읽을 것인가"를 agent가 직접 결정해야 합니다. 이는 retrieval 부담을 모델에게 전가하는 구조입니다.
다만 이 문제는 세션 초기화 프로토콜을 통해 구조적으로 완화할 수 있습니다. Anthropic Engineering(2025.11)은 long-running agent harness에서 매 세션 시작 시 다음 절차를 고정함으로써 모델의 cognitive load를 억제하였습니다:

1. pwd로 작업 디렉토리 확인
2. git log + progress file 읽기 → 이전 세션 상태 파악
3. feature list에서 미완료 항목 선택 → 단일 feature에 집중

이 패턴은 agent가 "무엇을 읽을지"를 스스로 판단하지 않도록 탐색 경로를 사전에 고정하는 설계입니다. 파일 기반 메모리의 cognitive load 문제가 구조적으로 해소 불가능한 것이 아니라, harness 수준의 프로토콜 설계로 상당 부분 완화 가능함을 시사합니다.
MemBench(Tan et al., 2025.06) 벤치마크는 이 문제를 4가지 역량으로 체계적으로 측정합니다:

1. Accurate Retrieval: needle-in-haystack 수준의 정확한 추출
2. Test-Time Learning: in-context 적응 능력
3. Long-Range Understanding: 전체 맥락 요약
4. Conflict Resolution: 기존 사실과 새 증거 간 충돌 해결

파일 기반 방식에서는 1번(정확한 추출)과 4번(충돌 해결)에서 성능 저하가 관찰됩니다.
ICLR 2026 Workshop Proposal(MemAgents)에서도 이를 핵심 과제로 제시합니다:

"The limiting factor is increasingly not raw model capability but memory: how agents encode, retain, retrieve, and consolidate experience."
— ICLR 2026, MemAgents Workshop Proposal

 
모델 안정성은 Vector RAG가 우위에 있습니다.

---

3. 판단 기준

데이터 규모가 가장 결정적인 변수입니다.

< 50~100 docs	파일 기반	Vector 도입은 과잉 설계에 해당. CAG 연구가 이를 뒷받침
100~3,000 docs	BM25 + lightweight embedding	전환 구간. retrieval 품질 모니터링 후 점진적 vector 도입 검토
3,000+ docs	Vector DB 도입	agent 탐색 시 토큰 한계 도달. retrieval latency 100~200ms/turn 감수 가치 있음

---

4. "무조건 Vector DB" 경향에 대한 분석

LangChain / LlamaIndex 등의 프레임워크가 load → chunk → embed → query 파이프라인을 원스톱으로 제공하면서, retrieval 설계에 대한 깊은 고민 없이 Vector DB를 도입하는 경향이 확산되고 있습니다. 그러나 Frontier 진영에서는 이미 방향이 분화되고 있습니다. Shlok Khemani는 Anthropic의 접근을 다음과 같이 분석합니다:

"Most memory solutions today split into three separate systems: retrieval, storage, and the main conversation thread. Each operates independently. Anthropic is betting on unification. With tool calls, Claude handles all three in a single conversation flow."
— Shlok Khemani, "Anthropic's Opinionated Memory Bet" (2025.10)

 
UCStrategies(2026.02)는 보다 직접적으로 정리합니다:

"Standard RAG—the retrieve-then-generate pattern that dominated 2023-2024—is increasingly obsolete for static corpora under 1 million tokens."
— UCStrategies, "Standard RAG Is Dead" (2026.02)

---

5. Frontier 설계 트렌드: Layered Memory Architecture

2025~2026년 연구에서 가장 뚜렷한 트렌드는 계층적 메모리 구조입니다. 인간의 기억 시스템(Baddeley's working memory, Atkinson-Shiffrin model)에서 영감을 받은 설계입니다.

5.1 계층 모델

SIGARCH(2026.01)에서 제안한 컴퓨터 아키텍처 관점의 비유는 다음과 같습니다:

L1: Working Memory	in-process / redis. 현재 태스크 컨텍스트	CPU cache (L1/L2/L3)
L2: Structured Knowledge	file / MD / 구조화된 지식	Main memory
L3: Vector Retrieval	semantic search. 대규모 과거 데이터	Storage hierarchy
L4: Cold Storage	archive. 접근 빈도 극히 낮음	Tape / Glacier

 
Agent는 가까운 계층부터 조회하며, 이는 인간의 기억 접근 패턴과 유사한 구조입니다.

"Agent performance is an end-to-end data movement problem. Even if the model is powerful, if relevant information is stuck in the wrong layer, reasoning accuracy and efficiency degrade."
— SIGARCH, "Multi-Agent Memory from a Computer Architecture Perspective" (2026.01)

5.2 주요 구현 사례

MemoryOS (Kang et al., 2025.05): STM(Short-Term) / MTM(Mid-Term) / LPM(Long-term Personal Model) 3계층 구조를 제시하였습니다.
MIRIX (Wang et al., 2025.07): Core / Episodic / Semantic / Procedural 4계층 구조로, RAG baseline 대비 35% 정확도 향상 및 99.9% 스토리지 절감을 달성하였습니다.
MemOS (2025.07): memory를 OS 수준의 schedulable resource로 취급하며, working memory, long-term storage, cold archives를 통합 관리하는 프레임워크입니다.
Anthropic Memory Tool (2025.09, beta): 6가지 파일 오퍼레이션(view, create, str_replace, insert, delete, rename)으로 인터페이스를 단순화하였습니다. 모든 저장은 client-side에서 이루어지며, 개발자가 storage backend을 자유롭게 선택할 수 있습니다.

"The key architectural point: all storage happens client-side. Your application receives tool calls and executes file operations wherever you want—local disk, PostgreSQL, S3, encrypted storage."
— Thomas Wiegold, "Claude API Memory Tool Guide" (2025.12)

5.3 실전 검증: Long-Running Agent Harness (Anthropic Engineering, 2025.11)

Anthropic Engineering이 공개한 "Effective Harnesses for Long-Running Agents"(2025.11)는 파일 기반 메모리가 실제 multi-session agent에서 어떻게 작동하는지를 보여주는 실전 사례입니다.
 
문제 정의: context window를 넘어서는 장기 실행 agent는 매 세션이 빈 상태에서 시작됩니다. 이전 세션의 기억이 전혀 없는 상태에서 교대 근무를 하는 엔지니어에 비유할 수 있습니다. (필자는 교대 근무 경험이 없어 잘 모르니 비유로 봐주면 감사하겠습니다. 정시 출퇴근, 유연 근무, 수당 혹은 보상이 전제된 정직하고 투명한 연장 근무를 선호합니다.)
 
실패 패턴 (메모리 부재 시):

One-shotting	한 세션에서 전체를 완성하려 시도. context 소진 후 다음 세션이 미완성 상태를 추측해야 함
Premature completion	이전 진행 상황을 보고 프로젝트가 완료되었다고 판단
Broken state	버그와 미문서화된 진행 상태가 다음 세션에 전달

 
해결 구조: initializer agent + coding agent의 2단계 설계로, 모든 메모리가 파일 기반 artifact로 구현되었습니다.
 
메모리 artifact 구성:

Artifact	포맷	역할
claude-progress.txt	텍스트	세션 간 진행 상황 로그. 매 세션 종료 시 업데이트
feature_list.json	JSON	구조화된 기능 목록. passes 필드만 변경 허용
git commit log	git	변경 이력. revert를 통한 상태 복원 가능
init.sh	스크립트	환경 설정. 개발 서버 기동 등 반복 작업 자동화

주목할 점은 feature list의 포맷으로 Markdown이 아닌 JSON을 선택한 것입니다.
Anthropic은 그 이유를 다음과 같이 설명합니다:

"We landed on using JSON for this, as the model is less likely to inappropriately change or overwrite JSON files compared to Markdown files."
— Anthropic Engineering, "Effective Harnesses for Long-Running Agents" (2025.11)

 
이는 파일 기반 메모리 설계에서 포맷 선택이 데이터 무결성에 직접적으로 영향을 미침을 시사합니다.
구조화된 상태 정보에는 JSON, 서술적 기록에는 텍스트 파일이라는 역할 분리가 관찰됩니다.
 
Layered Memory 관점에서의 위치:
이 harness의 메모리 구조는 Section 5.1의 계층 모델에 대응합니다:

Layer	Harness 대응
L1: Working Memory	현재 세션의 context window
L2: Structured Knowledge	claude-progress.txt + feature_list.json + init.sh
L2.5: Version History	git commit log (시점 복원 가능)
L3: Vector Retrieval	미사용 (프로젝트 규모에서 불필요)

Vector DB 없이 파일 기반 artifact만으로 multi-session agent가 생산성 있는 작업을 지속할 수 있음을 보여주는 사례입니다.

---

6. 결론

6.1 핵심 관점

RAG는 Agent 시스템의 필수 요건이 아닙니다. 필수 요건은 retrieval strategy이며, Vector DB는 그 구현 방식 중 하나입니다.
VentureBeat(2026.01)는 2026년 데이터 예측에서 다음과 같이 정리합니다:

"The problem is that the original RAG pipeline architecture is much like a basic search. What is emerging are alternative approaches (like contextual memory), as well as nuanced and improved approaches to RAG."

6.2 판단 플로우

데이터 < 100 docs
  → 파일/MD + BM25 권장
  → CAG 연구(Chan et al., 2024)가 이 구간에서의 유효성을 뒷받침

데이터 100~3,000 docs
  → BM25 + lightweight embedding 하이브리드
  → retrieval 품질 모니터링 후 vector 점진적 도입 검토

데이터 3,000+ docs
  → Vector DB 도입
  → Layered Memory 설계 고려
  → L1(working) + L2(file) + L3(vector) 계층 분리

6.3 요약

retrieval 설계의 품질이 Vector DB 도입 여부보다 시스템 성능에 더 큰 영향을 미칩니다. 소규모 시스템에서는 파일 기반 접근이 속도, 비용, freshness 측면에서 유리하며, Anthropic의 Long-Running Agent Harness(2025.11)는 progress file + JSON feature list + git log라는 파일 기반 artifact만으로 multi-session agent의 지속적 작업이 가능함을 실증하였습니다. 규모가 확대됨에 따라 Layered Memory Architecture를 통해 각 계층의 강점을 조합하는 것이 현 시점에서 가장 균형 잡힌 접근으로 판단됩니다.

---

References

1. Chan, B. J., Chen, C.-T., Cheng, J.-H., & Huang, H.-H. (2024). "Don't Do RAG: When Cache-Augmented Generation is All You Need for Knowledge Tasks." ACM Web Conference 2025. arXiv:2412.15605
2. Anthropic. (2025.09). "Memory Tool - Claude Docs." docs.claude.com
3. Anthropic. (2025.09). "Manage Claude's Memory - Claude Code Docs." docs.anthropic.com
4. Khemani, S. (2025.10). "Anthropic's Opinionated Memory Bet." shloked.com
5. Liu, S. et al. (2025.12). "Memory in the Age of AI Agents: A Survey." GitHub
6. MemOS Team. (2025.07). "MemOS: A Memory OS for AI System." arXiv
7. SIGARCH. (2026.01). "Multi-Agent Memory from a Computer Architecture Perspective." sigarch.org
8. Wiegold, T. (2025.12). "Claude API Memory Tool: Build Agents That Learn." thomas-wiegold.com
9. Skywork AI. (2025.09). "Claude Memory: A Deep Dive." skywork.ai
10. VentureBeat. (2026.01). "6 data predictions for 2026." venturebeat.com
11. UCStrategies. (2026.02). "Standard RAG Is Dead: Why AI Architecture Split in 2026." ucstrategies.com
12. Wang, C. et al. (2025.07). "MIRIX: Multi-level Memory Architecture." EmergentMind.
13. Tan, Y. et al. (2025.06). "MemBench: A Multi-aspect Benchmark for Agent Memory." EmergentMind.
14. Hu, Z. et al. (2025.07). "MemoryAgentBench." EmergentMind.
15. ICLR 2026 Workshop. "MemAgents: Memory for LLM-Based Agentic Systems." OpenReview
16. Monigatti, L. (2025). "The Evolution from RAG to Agentic RAG to Agent Memory." leoniemonigatti.com
17. Serokell. (2025.12). "Design Patterns for Long-Term Memory in LLM-Powered Architectures." serokell.io
18. Young, J. / Anthropic Engineering. (2025.11). "Effective Harnesses for Long-Running Agents." anthropic.com