메모리 문제: AI 에이전트에게 컨텍스트(Context)가 아닌 아키텍처(Architecture)가 필요한 이유

아무리 유능하더라도 상태가 없는 (Stateless) LLM은 관계를 구축하거나, 실수로부터 배우거나, 세션 전반에 걸쳐 전문 지식을 전달할 수 없습니다. LLM은 마치 당신을 처음 보는 것처럼 각 프롬프트를 처리합니다. 이것은 철학적인 결함이 아니라 아키텍처(Architectural)의 결함입니다. 그리고 2026년, 이 분야는 마침내 이를 해결하기 위한 어휘, 벤치마크(Benchmarks), 그리고 프로덕션 시스템(Production systems)을 갖추게 되었습니다.

에이전트 메모리 아키텍처(Agent memory architecture)는 본격적인 AI 배포를 위한 결정적인 엔지니어링 규율로 부상했습니다. 이는 단순히 위에 덧붙여진 기능이 아니라, 자체적인 연구 문헌, 측정 가능한 성능 격차, 그리고 이를 중심으로 구축된 성장하는 생태계를 가진 일급 구성 요소(First-class component)입니다. 현재 상황은 다음과 같습니다.

금붕어 문제 (The Goldfish Problem)

LLM은 금붕어와 같은 기억력을 가지고 있습니다. 각 추론(Inference)은 독립적입니다. 출력이 입력을 따르고, 모델은 변하지 않으며, 아무것도 지속되지 않습니다. 이러한 상태 없음(Statelessness)은 재현성(Reproducibility), 단순성, 깔끔한 테스트와 같은 이점을 제공합니다. 하지만 배포의 야망이 커짐에 따라 구체적인 문제들을 야기합니다.

컨텍스트 윈도우(Context window)의 제한이 가장 먼저 타격을 줍니다. 긴 대화, 에이전트 워크플로우(Agentic workflows), 그리고 다중 세션 작업은 각 프롬프트에 전체 채팅 기록을 다시 도입해야 합니다. 컨텍스트가 커짐에 따라 모델은 "중간에서 길을 잃는(Lost in the middle)" 어텐션(Attention) 패턴을 겪게 됩니다. 즉, 긴 컨텍스트의 시작과 끝 근처에 있는 사실은 중간에 있는 사실보다 더 안정적으로 회상됩니다. KV 캐시(KV cache) 비용은 이차 함수적으로(Quadratically) 증가하며, 새로운 메시지가 올 때마다 캐시 키(Cache key)가 변경되기 때문에 프롬프트 캐싱(Prompt caching)은 비효율적이 됩니다.

계산 효율성(Computational inefficiency)의 저하가 이를 가중시킵니다. 전체 컨텍스트 접근 방식(Full-context approaches)—전체 대화 기록을 컨텍스트 윈도우에 로드하는 방식—은 운영상으로는 간단하지만 경제적으로는 지속 불가능합니다. 일반적인 API 가격으로 실행되는 100,000 토큰 컨텍스트의 경우, 단 한 번의 긴 세션만으로도 입력 토큰 비용으로만 몇 달러가 들 수 있습니다. 또한 전체 컨텍스트 방식은 다중 세션의 연속성(Multi-session continuity)으로 확장되지 않습니다. 수개월 동안 축적된 상호작용을 담을 수 있을 만큼 큰 컨텍스트 윈도우는 존재하지 않기 때문입니다.

더 깊은 문제는 학습의 부재입니다. 메모리가 없다면 모델은 배포(deployment) 경험을 통해 스스로 개선될 수 없습니다. 과거의 성공을 바탕으로 발전하거나 과거의 실패를 피할 수 없습니다. 모든 세션이 처음부터 다시 시작된다는 것은, 매 세션마다 이전에 학습된 내용을 낭비한다는 것을 의미합니다.

3단계 분류 체계 (The Three-Tier Taxonomy)

에이전트 생태계는 인지 과학(cognitive science)에서 빌려온 매우 일관된 메모리 분류 체계인 에피소드 메모리(episodic memory), 의미론적 메모리(semantic memory), 그리고 절차적 메모리(procedural memory)로 수렴되었습니다. 각 계층은 서로 다른 종류의 정보를 저장하며 서로 다른 검색 메커니즘을 요구합니다.

**에피소드 메모리 (Episodic memory)**는 구체적인 과거 사건, 즉 무엇이, 언제, 어떤 맥락에서 일어났는지를 기록합니다. 에이전트 시스템에서 이는 대화 로그(conversation logs), 도구 호출 추적(tool-call traces), 그리고 상호작용 시퀀스(interaction sequences)에 해당합니다. 핵심 속성은 시간적 순서(temporal ordering)입니다. 에피소드 메모리는 특정 시점에 고정된 사실입니다.

Zep의 Graphiti 엔진은 명시적인 이중 시간(bitemporal) 주석이 달린 에피소드 서브그래프(subgraphs)를 저장합니다. 여기서 주석은 이벤트 시간(해당 사실이 세상에서 참이었던 시간)과 수집 시간(에이전트가 이를 처음 관찰한 시간)을 포함합니다. 이러한 이중 시간 설계는 소급 수정(retroactive corrections)에 대한 정밀한 추론을 가능하게 합니다. 예를 들어 사용자가 주소를 업데이트하면, Graphiti는 어느 것도 잃지 않고 새로운 사실과 이전 사실을 구분할 수 있습니다. Letta의 회상 메모리(recall memory)는 모든 이전 메시지에 대한 검색 가능한 SQLite 또는 PostgreSQL 로그이며, 필요에 따라 컨텍스트 윈도우(context window)로 페이지 단위로 불러올 수 있습니다.

**의미론적 메모리 (Semantic memory)**는 선언적 사실(declarative facts)과 관계, 즉 사용자 선호도, 엔티티 속성, 도메인 지식 등을 저장합니다. 에피소드 메모리와 달리, 의미론적 메모리는 대체로 비시간적(atemporal)입니다. 즉, 에이전트가 현재 참이라고 믿는 내용을 나타냅니다.

Mem0는 2026년 중반 기준으로 가장 널리 배포된 의미론적 메모리 (semantic memory) 레이어입니다. 이 의미론적 레이어는 LLM 파이프라인을 통해 대화에서 개체명 (named entities)과 관계 (relationships)를 추출하고, 이를 그래프 데이터베이스 (graph database)의 노드 (nodes)와 엣지 (edges)로 저장하며, 퍼지 검색 (fuzzy search)을 위해 벡터 임베딩 (vector embeddings)과 상호 연결합니다. 새로운 사실을 기존 그래프 항목과 비교하여 병합, 업데이트 또는 해결을 위해 플래그를 지정하는 충돌 탐지 (conflict detection) 단계가 핵심적인 아키텍처 혁신입니다.

Cognee는 연구 중심적인 접근 방식을 취합니다. Cognee의 cognify 파이프라인은 문서 분류, LLM 기반의 트리플렛 추출 (triplet extraction; 주어, 관계, 목적어), 그리고 그래프 확정 (graph commitment)을 포함한 6단계를 실행합니다. 그 후 memify 작업이 결과 그래프를 정제하며, 오래된 노드를 제거 (pruning)하고, 사용 빈도에 따라 엣지의 가중치를 재설정 (reweighting)하며, 파생된 사실을 추가합니다. 그 결과는 정적인 인덱스 (static index)가 아닌, 자기 개선형 지식 구조 (self-improving knowledge structure)입니다.

**절차적 메모리 (Procedural memory)**는 무언가를 수행하는 방법, 즉 학습된 워크플로 (workflows), 성공적인 도구 호출 (tool-call) 시퀀스, 행동 휴리스틱 (behavioral heuristics)을 인코딩합니다. 이는 가장 지적으로 흥미로우면서도 가장 미성숙한 단계입니다.

결정적인 과제는 절차적 지식이 검색 가능한 데이터가 아닌 지침 (instructions)으로서 가장 유용하다는 점입니다. 에이전트가 "API Y를 호출하기 전에 항상 스키마 X로 JSON을 검증하라"는 것을 학습했을 때, 이 지식은 벡터 저장소 (vector store)에서 검색되는 것보다 시스템 프롬프트 (system-prompt) 지시문으로 주입될 때 가장 효과적입니다. 이로 인해 절차적 메모리는 다른 단계들과 아키텍처 측면에서 차별화됩니다.

두 가지 패턴이 등장했습니다. CLAUDE.md, AGENTS.md, .cursorrules와 같은 마크다운 설정 파일을 통한 정적 절차적 메모리는 학습된 관습을 세션 시작 시 주입되는 인간이 읽을 수 있는 지침으로 인코딩합니다. 동적 절차적 메모리는 에이전트가 런타임 (runtime) 중에 자신의 시스템 지침을 업데이트할 수 있게 합니다. LangMem의 SDK는 이를 명시적으로 지원합니다. 에이전트는 지정된 메모리 블록을 다시 쓰는 update_system_prompt 함수를 호출하여, 새롭게 학습된 휴리스틱을 남은 세션 동안 사용할 수 있도록 인코딩합니다.

그 이면의 아키텍처

2026년의 프로덕션 시스템(Production systems)은 다음과 같은 분류 체계를 반영하는 3계층 계층 구조로 수렴되었습니다.

**인컨텍스트 작업 메모리 (In-context working memory)**는 현재 세션의 원시 메시지 버퍼(raw message buffer), 도구 호출(tool calls), 그리고 활성 상태(active state)를 보유합니다. 설계상 휘발성(Ephemeral)이며, 세션이 종료되면 삭제됩니다. 이는 전통적인 시스템의 RAM과 동일합니다.

**세션 범위 압축 메모리 (Session-scoped compressed memory)**는 현재 세션에서 요약되거나 추출된 사실(facts)을 저장하며, 필요할 때 읽을 수 있습니다. 이곳은 세션이 "학습"하는 공간입니다. 대화 중에 추출된 사실들은 원시 버퍼가 삭제된 후에도 보존됩니다.

**장기 지속 저장소 (Long-term persistent store)**는 세션을 가로지르는 지식, 즉 사용자 선호도, 축적된 도메인 지식, 학습된 워크플로(workflows)를 보유합니다. 벡터+그래프 저장소(vector+graph storage)에 영구 저장되며, 여러 세션에 걸쳐 쿼리됩니다.

Letta의 아키텍처는 이러한 계층 구조를 가장 명확하게 구현한 사례입니다. 코어 메모리(Core memory, 항상 인컨텍스트 상태이며 기본적으로 2-4KB)는 사용자와 활성 작업에 대한 에이전트의 현재 이해도를 보유합니다. 아카이브 메모리(Archival memory)는 크기 제한이 없는 외부 벡터 저장소(external vector store)로, 임베딩 유사도(embedding similarity)를 통해 검색 가능합니다. 리콜 메모리(Recall memory)는 청크(chunks) 단위로 페이지를 넘길 수 있는 대화 기록 로그입니다. LLM 자체는 명시적인 메모리 연산을 통해 이 세 계층을 모두 제어합니다.

근본적인 긴장 관계는 인컨텍스트 가용성(in-context availability)과 아웃오브컨텍스트 검색(out-of-context retrieval) 사이에 존재합니다. 컨텍스트 윈도우(context window) 내부의 정보는 지연 시간(latency)이나 검색 오류 없이 즉시 접근할 수 있습니다. 반면 외부 저장소의 정보는 반드시 검색 과정을 거쳐야 하므로 지연 시간, 관련성 오류(relevance error), 그리고 토큰 비용이 발생합니다. 하이브리드 아키텍처(Hybrid architectures)는 벡터 유사도 검색(fuzzy semantic recall을 위한 용도)을 지식 그래프(relational 및 temporal reasoning을 결정론적 정밀도로 수행하기 위한 용도)와 계층화함으로써 이 문제를 해결합니다.

중요한 것을 측정하기

표준화된 벤치마크(benchmarks)의 등장은 메모리를 막연한 고민거리에서 측정 가능한 공학적 문제로 변화시켰습니다. 현재 세 가지 벤치마크가 측정 환경을 정의하고 있습니다.

LoCoMo (Snap Research)는 single-hop, multi-hop, open-domain, 그리고 temporal recall(시계열 회상)의 네 가지 카테고리에 걸쳐 1,540개의 질문을 통해 메모리 회상 능력을 테스트합니다. 대화는 최대 35개 세션, 300턴, 9,000개 토큰에 달합니다.

LongMemEval은 single-session user and assistant recall(단일 세션 사용자 및 어시스턴트 회상), preference recall(선호도 회상), knowledge update(지식 업데이트), temporal reasoning(시계열 추론), 그리고 multi-session recall(다중 세션 회상)의 여섯 가지 카테고리를 다룹니다. 특히 지식 업데이트와 다중 세션 작업에서 높은 난이도를 요구합니다.

BEAM은 1M 및 10M 토큰 규모에서 작동하며, 이는 일반적인 벤치마크보다 수십 배 더 큰 컨텍스트(Context) 볼륨입니다. 이는 단순히 컨텍스트 윈도우(Context Window)를 확장하는 것만으로는 해결할 수 없기에, 실제 프로덕션 규모의 배포에 가장 유의미한 벤치마크입니다.

현재 LoCoMo의 상위 성능 모델은 쿼리당 약 6,900개 토큰을 사용하는 Mem0로 92.5점을 기록했습니다. LongMemEval에서는 94.4점을 기록했습니다. 현대적 알고리즘에서 가장 큰 두 가지 성능 향상은 temporal queries(+29.6 포인트)와 multi-hop reasoning(+23.1 포인트)에서 나타났습니다. 이 카테고리들은 사실이 축적되고, 변화하며, 시간에 따라 서로 연관되는 실제 사용자 이력을 에이전트가 어떻게 처리하는지를 가장 직접적으로 반영합니다.

통합 생태계 (The Integration Ecosystem)

가장 빠르게 성장하는 영역은 통합 계층(Integration Layer)입니다. 2026년 기준으로 Mem0의 문서화된 통합 사례는 LangChain, LangGraph, LlamaIndex, CrewAI, AutoGen, Agno, CAMEL AI, Dify, Flowise, Google ADK, OpenAI Agents SDK, 그리고 Mastra(TypeScript-first)를 포함하여 21개의 프레임워크 및 플랫폼을 아우릅니다.

음성 에이전트(Voice agents)는 가장 중요한 신흥 유스케이스 중 하나입니다. 음성 상호작용에서는 사용자가 이전 내용을 스크롤하여 확인하거나, 컨텍스트를 복사하여 붙여넣거나, 과거 대화 내용을 에이전트에게 수동으로 상기시킬 수 없습니다. 만약 에이전트가 기억하지 못한다면, 그 마찰(Friction)은 즉각적이고 명확하게 드러납니다. ElevenLabs, LiveKit, Pipecat는 모두 음성 지연 시간(Latency)을 가중시키지 않도록 비동기 쓰기(Async writes)를 처리하는 전용 메모리 통합 기능을 갖추고 있습니다.

벡터 저장소(Vector store)의 확산은 하이브리드 아키텍처(Hybrid architecture) 트렌드를 반영합니다. 클라우드 및 셀프 호스팅(Self-hosted) 옵션 전반에 걸쳐 Qdrant, Chroma, Weaviate, Milvus, PGVector, Redis, Elasticsearch, FAISS, Pinecone, Azure AI Search 등 20개의 백엔드(Backends)가 지원됩니다. 지난 1년 동안 추가된 주목할 만한 요소들인 AWS 네이티브 그래프 지원을 위한 Neptune Analytics, 고처리량 분산 저장(High-throughput distributed storage)을 위한 Apache Cassandra, 그리고 동일한 목적의 Valkey 등은 엔터프라이즈급 인프라가 필요한 프로덕션 규모의 배포를 운영하는 팀들의 요구를 충족합니다.

해결되지 않은 과제들

세션 간 정체성(Cross-session identity) 문제는 여전히 해결되지 않았습니다. "오늘 세션의 이 사용자가 6개월 전에 상호작용했던 동일 인물이다"라는 것을 판별하려면 세션 전반에 걸쳐 유지되는 애플리케이션 수준의 인증(Authentication)이 필요합니다. 메모리 시스템은 사용자에 대한 사실(Facts)을 저장할 수는 있지만, 사용자 정체성을 생성할 수는 없습니다.

대규모 환경에서의 시간적 추상화(Temporal abstraction)는 어렵습니다. 대부분의 시스템은 "사용자가 2024년에 X라고 말했고 2026년에 Y라고 말했다"는 상황은 올바르게 처리합니다. 하지만 "사용자의 선호도가 3월에서 6월 사이에 X에서 Y로 진화했으며, 오늘 쿼리에 대한 관련 컨텍스트(Context)는 6월의 상태이지만, 3월의 상태는 여전히 역사적 추론(Historical reasoning)에 유효하다"는 상황을 처리하는 시스템은 훨씬 적습니다.

메모리 노후화(Memory staleness)는 아무도 말하고 싶어 하지 않는 문제입니다. 사실은 퇴색됩니다. 선호도는 변합니다. 지식은 부정확해집니다. 대부분의 프로덕션 메모리 시스템은 새로운 사실을 교체(Replacement)가 아닌 추가(Addition)로 취급하며, 이는 노이즈의 누적으로 이어집니다. 교체를 처리하는 시스템들은 새로운 사실이 기존의 사실을 대체하는 시점과, 두 사실이 진정으로 서로 다른 참된 상태를 나타내는 시점을 결정해야 하는 과제에 직면합니다.

이것들은 활발한 연구가 진행 중인 실제적인 미결 과제들입니다. 이 분야는 "에이전트에게 메모리가 필요한가?"라는 질문을 넘어 "어떻게 실제로 작동하는 메모리를 구축할 것인가?"의 단계로 넘어왔습니다. 그것이 바로 진보입니다.

출처: "State of AI Agent Memory 2026" (mem0.ai); "AI Agent Memory Architectures: From Context Windows to Persistent Knowledge" (zylos.ai); "From context to dreams: architecting memory for AI agents" (Red Hat Emerging Technologies); LoCoMo 및 LongMemEval 벤치마크 (GitHub)