지난 3년 중 대부분의 기간 동안 "AI 메모리"란 채팅 기록을 컨텍스트 윈도우 (context window)에 밀어 넣고 모델이 이를 계속 추적하기를 바라는 것을 의미했습니다. 그러한 프레임워크는 이제 끝났습니다. 2026년 현재, 메모리는 에이전트 설계에서 독자적인 벤치마크, 연구 문헌, 그리고 공격 표면 (attack surface)을 가진 일급 아키텍처 계층 (architectural layer)이 되었습니다. 만약 당신이 지금 에이전틱 시스템 (agentic systems)을 구축하거나 평가하고 있다면, 메모리는 더 이상 챗봇에 덧붙여진 있으면 좋은 기능이 아닙니다. 그것은 당신의 에이전트가 첫 번째 세션을 넘어 실제로 유용할지 여부를 결정하는 핵심 요소입니다.

컨텍스트 윈도우에서 실제 아키텍처로

과거의 모델은 단순했고, 단순히 불충분했습니다. 마지막 N개의 메시지를 버퍼링하고, 나머지는 요약하여 그것을 메모리라고 불렀습니다. 에이전트가 미화된 챗봇이었을 때는 그것이 작동했습니다. 하지만 에이전트가 실제 워크플로우(workflow) — 코드 리뷰, 조달, 보안 운영, 연구 파이프라인 — 를 실행하기 시작한 순간부터 그것은 작동하지 않았습니다. 에이전트는 단지 5분 전에 무엇이 말해졌는지가 아니라, 어제 무엇을 했는지를 기억해야 하기 때문입니다.

이 분야는 시스템을 설계할 때 내재화할 가치가 있는 장기 메모리 (long-term memory)의 대략적인 분류 체계로 수렴되었습니다:

• 에피소드 메모리 (Episodic memory) — 구체적인 과거 경험과 결과 ("이 익스플로잇은 X 때문에 이 타겟에 대해 실패했다")
• 의미론적 메모리 (Semantic memory) — 그러한 경험으로부터 추출된 일반적인 사실과 관계
• 절차적 메모리 (Procedural memory) — 학습된 기술과 재사용 가능한 행동 시퀀스 (action sequences)

오늘날 대부분의 프로덕션 시스템은 여전히 절차적 메모리 측면에서 취약합니다. 에피소드 및 의미론적 검색 (retrieval)이 벡터 검색 (vector search)에 깔끔하게 매핑되기 때문에 대부분의 관심을 받지만, "에이전트가 시간이 지남에 따라 특정 클래스의 작업에 대해 측정 가능할 정도로 개선된다"는 속성은 절차적 메모리가 제 역할을 수행하는지에 달려 있으며, 이 부분은 여전히 성숙해가는 단계입니다.

검색 스택이 두 진영으로 나뉘고 있습니다

최근 메모리 프레임워크 환경을 살펴보셨다면, 분열된 양상을 눈치채셨을 겁니다. 한 진영은 **대화 컨텍스트(conversation context)**를 처리합니다. 이는 에이전트가 단일 상호작용 전반에 걸쳐 일관성을 유지하도록 하는 세션 수준의 흐르는 상태입니다. 다른 진영은 **축적된 운영 지식(accumulated operational knowledge)**을 다룹니다. 이는 에이전트가 학습한 내용을 복합적으로 활용할 수 있게 해주는 영속적인, 세션 간 교차 저장소입니다.

두 번째 진영 안에는 알아둘 만한 추가적인 아키텍처적 분열이 있습니다: 순수 벡터 유사성(pure vector similarity) 대 그래프 증강 검색(graph-augmented retrieval). 벡터 메모리는 의미적으로 유사한 사실들을 찾아내는 데 능하지만, 관계성은 인식하지 못합니다. 그래프 기반 접근 방식—Zep의 Graphiti 엔진이 자주 언급되는 예시입니다—은 단순히 임베딩 거리만으로 사실을 검색하는 것이 아니라 엔티티와 그들의 관계를 통해 사실을 검색하며, 현재 LongMemEval과 같은 시간적 추론 벤치마크에서 의미 있게 더 나은 점수를 기록하고 있습니다. 이 두 가지 접근 방식 중 어느 것도 단독으로는 충분하지 않습니다. 앞으로의 방향은 다중 신호 검색(multi-signal retrieval)입니다: 즉, 의미적 유사성, 키워드 매칭, 엔티티 연결을 하나의 순위가 매겨진 결과로 융합하는 것입니다.

Berkeley에서 나온 MemGPT 연구 계보를 기반으로 하는 Letta는 언급할 가치가 있는 다른 각도를 취합니다: '코어 메모리(core memory)'가 RAM처럼 작동하여 항상 컨텍스트 내에 있고 검색 호출이 필요 없는 OS 영감의 계층적 모델입니다. 반면, 나머지 모든 것은 계층 구조의 더 아래쪽에 존재하며 필요할 때 페이징되어 들어옵니다. 이는 단순히 에이전트 루프에 '붙여넣은 벡터 데이터베이스'라는 것과는 근본적으로 다른 사고방식이며, 메모리 관리를 에이전트가 수동적인 서비스로 쿼리하는 것이 아니라 능동적으로 참여하는 것으로 다루기 때문에 특히 주목받고 있습니다.

아무도 충분히 이야기하지 않는 공격 표면(attack surface)

특히 보안 배경을 가진 분이라면 더 많은 관심이 필요하다고 생각하는 부분이 바로 여기입니다: 영속적인 메모리는 영속적인 공격 표면이며, 전통적인 프롬프트 주입(prompt injection)과는 전혀 다르게 작동합니다.

프롬프트 주입 (Prompt injection)은 대화가 종료되면 초기화됩니다. 하지만 메모리 오염 (Memory poisoning)은 그렇지 않습니다. 공격자는 에이전트의 장기 저장소 (long-term store)에 악성 콘텐츠를 단 한 번만 심어두면, 이후의 모든 상호작용을 조용히 오염시킵니다. 때로는 며칠 또는 몇 주 뒤에 전혀 무관하고 완전히 무해한 후속 메시지에 의해 트리거되기도 합니다. 올해의 연구에 따르면, 기술에 따라 프로덕션 스타일의 에이전트 메모리 구현에 대한 공격 성공률이 80~99% 범위에 달하는 것으로 나타났으며, OWASP도 이에 주목했습니다: 메모리 및 컨텍스트 오염 (Memory and Context Poisoning)은 이제 2026년 에이전틱 AI Top 10의 ASI06으로 지정되었습니다. 이는 프롬프트 주입과는 명확히 구분되는 카테고리인데, 그 이유는 하나를 잡아내는 제어 장치가 다른 하나는 잡아내지 못하기 때문입니다. 입력 검사 (Input moderation)와 출력 필터링 (Output filtering)은 세션 단위로 제한됩니다. 악성 데이터가 벡터 저장소 (vector store)에 앉아 다음 주에 검색되기를 기다리고 있다면, 이러한 방식은 도움이 되지 않습니다.

새롭게 등장하고 있는 방어 패턴은 네 가지 계층으로 구성되며, 이를 펼쳐놓고 보면 일반적인 정보 보안 (infosec) 본능과 거의 직접적으로 일치합니다: 수집 전 정화 (sanitize before ingestion), 신뢰할 수 있는 출처와 신뢰할 수 없는 출처를 구분할 수 있도록 모든 저장된 항목에 출처 (provenance)를 첨부, 모든 저장된 메모리를 동일하게 신뢰하는 대신 검색 시점에 신뢰도를 고려한 가중치 적용 (trust-aware weighting), 그리고 행동 드리프트 (behavioral drift) 모니터링 — 학습해서는 안 될 신념을 옹호하기 시작하는 에이전트는 단순한 특이점이 아니라 하나의 신호입니다. 만약 영속적인 경험 캐시 (persistent experience cache)나 자율적으로 기록되는 기술 라이브러리 (skill library)를 사용하는 시스템을 운영 중이라면, 모든 항목에 대한 출처 추적 (provenance tracking)은 선택적인 강화 조치가 아니라 기본적인 위생 (baseline hygiene)입니다.

이것이 실제로 향하고 있는 방향

베팅할 만큼 충분히 지속 가능해 보이는 몇 가지 사항이 있습니다:

메모리는 단일 에이전트가 아닌 멀티 에이전트 (multi-agent) 방식으로 변하고 있습니다. 오케스트레이션 (orchestration) 아키텍처가 성숙해짐에 따라, 흥미로운 설계 질문은 "에이전트 하나가 어떻게 기억하는가"에서 "여러 에이전트가 어떻게 서로의 메모리를 공유하고, 분할하며, 신뢰하는가"로 이동합니다. 이는 이제 외부 입력뿐만 아니라 다른 에이전트의 쓰기 작업까지 신뢰해야 하므로, 출처 (provenance) 문제를 더 어려운 수준으로 다시 불러옵니다.

배관(plumbing) 작업에 대한 표준화가 다가오고 있습니다. 도구 호출 (tool-calling)을 위한 MCP와 같은 프로토콜을 추진하는 것과 동일한 동력이 메모리 교환 (memory interchange) 표준을 추진할 것입니다. 즉, 에이전트가 자신이 무엇을 알고 있는지, 그 지식이 어디에서 왔는지, 그리고 그 지식을 얼마나 신뢰해야 하는지를 기술하는 방식에 대한 표준입니다. 현재는 모든 프레임워크가 각자만의 스키마 (schema)를 사용하고 있는데, 이는 충분한 수의 프로덕션 시스템이 상호 운용성 (interoperability)의 벽에 부딪히게 되면 반드시 통합될 수밖에 없는 파편화의 전형적인 모습입니다.

가지치기 (Pruning)와 점수 매기기 (scoring)는 저장만큼이나 중요합니다. 효과적이라고 인용되는 시스템들은 모든 것을 기억하는 시스템이 아닙니다. 대신 점수 매기기 (scoring)나 경량화된 강화 신호 (reinforcement signals)를 사용하여 무엇을 유지할 가치가 있는지 결정하는 시스템들입니다. 무제한적인 메모리 성장은 용량 문제이기 이전에 비용 문제이자 신호 대 잡음비 (signal-to-noise) 문제입니다.

절차적 메모리 (Procedural memory)는 아직 충분히 구축되지 않은 부분입니다. 오늘날 대부분의 툴링 (tooling)은 "올바른 사실을 회상하기"에 최적화되어 있습니다. 반면 "올바른 행동 순서 (sequence of actions)를 회상하고 재사용하기"에 능숙한 시스템은 훨씬 적습니다. 이것이 더 어렵고 가치 있는 능력이며, 저는 에이전트의 유용성이 다음 단계로 도약하는 지점이 더 큰 컨텍스트 윈도우 (context window)나 더 나은 임베딩 (embeddings)이 아닌 바로 이 지점에서 올 것이라고 예상합니다.

이 모든 것을 관통하는 핵심은 다음과 같습니다: 메모리는 더 이상 컨텍스트 윈도우 (context-window)의 임시방편이 아니라, 상태가 없는 (stateless) 데모와 시간이 지남에 따라 업무 능력이 향상되는 시스템을 실제로 구분 짓는 요소가 되었습니다. 메모리를 데이터베이스 스키마 (database schema)나 인증 모델 (auth model)에 적용하는 것과 동일한 엄격함을 가지고 핵심 아키텍처 (core architecture)로 다루는 팀은 가치가 복리로 쌓이는 에이전트를 갖게 될 것입니다. 반면 메모리를 사후 고려 사항으로 취급하는 팀은 감사 (audit)할 수 없는 메모리로부터 발생하는, 설명할 수 없는 행동을 디버깅하게 될 것입니다.