단기부터 공유까지 — AI 에이전트 메모리 6종 비교 가이드

AI 에이전트의 6가지 메모리 타입, 언제 무엇을 써야 하나

LLM 기반 에이전트의 성능을 결정하는 변수는 점점 모델 자체가 아니라 "무엇을, 언제, 어떻게 기억하는가"로 옮겨가고 있습니다. 이 글은 단기·장기·일화적·의미론적·절차적·공유라는 6가지 메모리 타입이 각각 어떤 한계를 해결하기 위해 등장한 구조적 처방인지 분해하고, 실전에서 어떤 조합으로 쌓아야 하는지 정리합니다.

이 글은 AI 에이전트 및 백엔드 개발자가 6가지 메모리 타입의 구조와 한계를 이해하고, 자신의 에이전트에 어떤 메모리 조합을 도입할지 판단하는 기준을 얻도록 돕습니다.

배경 지식으로 RAG와 벡터DB 정도만 알고 있다면 충분합니다. 다만 이 글은 "어떤 메모리가 가장 좋은가"가 아니라 "어떤 한계를 풀고 싶은가"를 먼저 묻습니다. 그 질문이 빠지면 어떤 메모리 도입도 과잉 설계가 되기 쉽다는 점을, 6가지 타입을 하나씩 풀어가며 짚어보겠습니다.

이 글에서 다루는 것

• 단기·장기·일화적·의미론적·절차적·공유 메모리의 구조와 작동 원리
• 각 메모리 타입의 본질적 한계(검색 품질 의존성, 무한 증가, 회귀 위험 등)
• 벡터DB vs 지식 그래프 트레이드오프와 다층 메모리 스택 조합 패턴
• 메모리 타입별 최적 활용 시기(Best for)와 도입 우선순위

이 글에서 다루지 않는 것

• Pinecone·Weaviate·Chroma 등 특정 벡터DB 제품 비교 및 쿼리 최적화
• 메모리 시스템 운영 비용 분석 및 클라우드 인프라 요금 책정
• 구체적인 코드 구현 예제 및 라이브러리 사용법
• 메모리 보안·프라이버시 이슈(GDPR 등 개인정보 처리)

왜 컨텍스트 윈도우만으로는 부족한가 — 메모리가 등장한 4가지 한계

Gartner는 2026년 AI 프로젝트의 60%가 컨텍스트 및 데이터 준비 부족으로 중단될 것이라 전망합니다. 모델 품질이 아니라 "모델이 무엇을 알고 있느냐"가 실패 원인의 절반 이상을 차지한다는 뜻입니다. 그리고 그 "안다"의 거의 모든 무게가 실리는 곳이 바로 메모리입니다.

AI 에이전트 메모리는 한 줄로 정의하면, LLM의 휘발성 컨텍스트 윈도우가 처리하지 못하는 정보를 외부에 저장·관리·검색하는 보완적 정보 시스템입니다. 즉 메모리는 그 자체로 독립된 시스템이 아니라, 컨텍스트 윈도우의 4가지 본질적 한계를 메우기 위해 붙는 보조 장치입니다.

그 4가지 한계는 다음과 같습니다. 첫째, 시간 지속성입니다. 컨텍스트 윈도우는 세션이 끝나면 비워집니다. 어제 사용자와 나눈 대화가 오늘 그대로 이어지지 않습니다. 둘째, 경험 누적입니다. 같은 실수를 반복해도 모델은 "지난번에 이렇게 해서 실패했지"를 떠올리지 못합니다. 셋째, 지식 정제입니다. 원본 로그·문서를 매번 통째로 밀어 넣으면 토큰이 폭증하고, 핵심만 추려서 보관하려면 별도 파이프라인이 필요합니다. 넷째, 협업입니다. 에이전트 A가 알아낸 사실을 에이전트 B가 공유하려면 공통의 저장소가 있어야 합니다.

메모리가 부재할 때 발생하는 문제는 단순한 불편 이상입니다. 모델은 매번 처음 만난 사용자처럼 행동하기에 개인화가 불가능하고, 같은 정보를 매번 다시 주입해야 하기에 토큰 비용이 누적되며, 잘못된 컨텍스트가 들어가면 환각이 증폭됩니다. 메모리는 "있으면 좋은" 기능이 아니라, 일정 규모 이상의 에이전트가 무너지지 않고 작동하기 위한 최소 인프라에 가깝습니다.

6가지 메모리 타입의 인지 모델 — CoALA 4분류와 실무 6분류의 차이

Princeton 연구팀이 2023년 발표한 CoALA(Cognitive Architectures for Language Agents) 프레임워크는 "언어 에이전트의 인지 아키텍처는 인간 기억 모델을 차용해 4가지로 공식화한다"고 정리합니다. 그 4가지는 Working(작업), Episodic(일화적), Semantic(의미론적), Procedural(절차적) 메모리입니다. 학계는 대체로 이 분류를 표준으로 따릅니다.

반면 실무에서는 같은 현상을 6가지로 자르는 경우가 더 일반적입니다. CoALA의 4가지에 더해 단기(Short-Term)와 장기(Long-Term)를 시간적 지속성 기준으로 별도 분리하고, 멀티 에이전트 시나리오에서 빠질 수 없는 공유(Shared) 메모리를 추가합니다. 단기 메모리는 사실상 CoALA의 Working 메모리와 같지만, "세션이 끝나면 사라진다"는 운영 특성을 부각하려고 별도로 두는 것입니다.

어느 분류가 더 옳다고 말하기는 어렵습니다. 둘은 같은 현상의 다른 절단면이고, 어떤 절단면을 쓸지는 무엇이 필요한지에 따라 갈립니다. 학술적 엄밀성이 필요하면 CoALA 4분류가 적합합니다. 연구 논문이나 인지 아키텍처 비교에서는 용어 통일이 중요하기 때문입니다. 반면 실무 설계 지침이 필요하면 6분류가 더 유용합니다. "이 메모리는 세션이 끝나면 사라지나?"라든가 "이 메모리는 여러 에이전트가 동시에 쓰나?"처럼, 운영 시점의 의사결정 기준이 분류에 그대로 박혀 있기 때문입니다.

이 글은 실무 관점에서 6분류를 택합니다. 그리고 6가지를 한꺼번에 펼쳐놓기보다, 지속성·저장 형태·그 메모리가 답하는 본질적 질문이라는 세 축으로 묶어서 다음 절부터 두 개씩 비교하며 살펴보겠습니다. 두 개씩 묶는 이유는, 각 메모리의 성격이 다른 메모리와의 대비 속에서 가장 잘 드러나기 때문입니다.

단기·장기 메모리 — 가장 기본이지만 가장 자주 무너지는 두 층

단기 메모리는 컨텍스트 윈도우 그 자체입니다. 모든 에이전트가 별도 설계 없이 자동으로 보유하며, 세션마다 초기화됩니다. 단일 세션 안에서 즉각적인 추론과 단기적 대화 흐름을 유지하는 데 최적이지만, 컨텍스트가 비워지면 메모리도 같이 소멸합니다. "단기"라는 이름이 붙은 만큼, 이 메모리의 한계는 곧 LLM 추론의 시간 경계와 같습니다.

장기 메모리는 그 경계를 넘기 위해 등장합니다. 세션이 끝나도 사라지지 않고 영구 지속되는 저장소이며, 주로 벡터DB에 임베딩 형태로 저장됩니다. 개인 비서 에이전트가 "사용자가 어제 어떤 일정을 잡았는지" 기억하거나, 고객 지원 에이전트가 "이 고객의 지난 문의 이력"을 떠올리는 것이 모두 장기 메모리의 영역입니다. 세션 간 일관성이 필요한 시스템이라면 장기 메모리 도입은 거의 필연적입니다.

그런데 여기서 가장 자주 오해되는 지점이 있습니다. 장기 메모리 도입이 곧 정확도 상승은 아니라는 점입니다. 오히려 검색 품질이 낮으면 잘못된 컨텍스트가 모델에 주입되어 환각이 증가할 수 있습니다. 장기 메모리의 본질적 병목은 "저장"이 아니라 "검색"입니다. 아무리 많은 정보를 보관해도, 올바른 시점에 올바른 정보를 끌어오지 못하면 그 메모리는 무용지물에 가깝습니다.

이 명제가 실무에 주는 함의는 큽니다. 장기 메모리를 도입한다는 결정은 사실상 RAG 시스템 한 벌을 설계한다는 결정과 같습니다. 임베딩 모델 선택, 청킹 전략, 하이브리드 검색(키워드 + 벡터) 구성, 재순위(re-ranking) 단계 도입 여부 — 이 모든 것이 메모리 품질의 변수가 됩니다. "벡터DB에 다 박아두면 알아서 잘 나오겠지"라는 가정은 거의 항상 깨집니다. 검색 품질을 측정하고 개선하는 별도의 평가 루프 없이 장기 메모리를 운영하면, 메모리는 비용만 늘리고 정확도는 오히려 떨어뜨리는 부담이 되기 쉽습니다.

일화적·의미론적 메모리 — "언제"와 "무엇"을 나누는 시간축의 의미

일화적 메모리는 타임스탬프가 붙은 과거 경험의 기록입니다. 단순히 무엇을 알고 있는지가 아니라, "언제, 어떤 상황에서, 어떤 행동을 했고, 그 결과는 무엇이었는지"를 시계열로 보관합니다. 검색은 시간 순서로도 가능하고 유사도로도 가능합니다. 자기 개선 에이전트가 "지난 화요일에 이 코드 리팩터링이 실패했지"를 떠올리거나, 행동 디버깅에서 특정 시점의 상태를 재현할 때 일화적 메모리가 토대가 됩니다.

문제는 이 메모리가 요약 없이는 무한 증가한다는 점입니다. 에피소드는 계속 쌓이는데 버리는 메커니즘이 없으면, 저장소는 곧 한계에 부딪히고 검색은 점점 느려집니다. 그래서 일화적 메모리는 거의 항상 메모리 통합(memory consolidation) 메커니즘과 함께 설계됩니다. 원자(raw) 경험을 반추(reflection)와 요약을 거쳐 재사용 가능한 형태로 변환하는 과정이며, 이 과정의 출력물이 바로 다음에 살펴볼 의미론적 메모리입니다.

의미론적 메모리는 특정 경험과 무관한 사실적 지식을 저장합니다. "사용자 김씨는 채식주의자다"라든가 "이 시스템의 결제 모듈은 Stripe를 사용한다"처럼, 시간 정보가 빠진 정제된 사실들입니다. 저장 매체는 지식 그래프 또는 구조화된 벡터DB이며, 일화적 메모리에서 통합되어 올라오기도 하고 외부 문서에서 추출되기도 합니다.

이 메모리가 주는 효과는 토큰 비용에서 가장 극적으로 나타납니다. Mem0의 의미론적 메모리 구현은 컨텍스트 직접 주입 대비 p95 지연시간 91% 감소, 토큰 비용 90% 절감을 달성했다고 보고합니다. 매번 원본 대화 로그를 전부 넣는 대신, "이 사용자에 대해 알아야 할 핵심 사실 N개"만 추려서 주입하기 때문입니다.

다만 이 메모리에도 그림자가 있습니다. 첫째, 추출 파이프라인 자체가 비용입니다. 원자 경험에서 사실을 뽑아내려면 별도의 LLM 호출 또는 규칙 기반 처리가 필요하며, 이 비용을 절감 효과에서 빼고 계산해야 합니다. 둘째, 사실이 stale될 수 있습니다. "김씨는 채식주의자"라는 사실이 1년 후에도 유효한지 누가 보장하나요? 의미론적 메모리는 시간 정보를 의도적으로 버린 만큼, 그 사실이 언제 학습되었는지·여전히 유효한지를 별도로 추적하지 않으면 잘못된 정보를 자신만만하게 주입하는 위험을 안게 됩니다.

요약하면 두 메모리의 본질적 차이는 시간축의 처리 방식입니다. 일화적 메모리는 "언제"를 1급 시민으로 다루기에 자기 개선의 토대가 되지만 무한 증가가 필연이고, 의미론적 메모리는 "무엇"으로 정제해 시간축을 떨어내기에 토큰을 극적으로 줄이지만 stale 위험과 추출 비용을 함께 떠안습니다.

절차적·공유 메모리 — 데이터가 아닌 "방법"과 "협업"의 메모리

지금까지 본 메모리는 모두 "무엇을 아는가"에 관한 것이었습니다. 절차적 메모리는 그 축을 비틀어 "어떻게 하는가"를 저장합니다. 그래서 저장 매체부터 다릅니다. 도구(Tool) 정의, 프롬프트 템플릿, 그리고 파인튜닝된 모델 가중치 자체 — 이 셋이 절차적 메모리의 저장 형태입니다. CoALA는 절차적 메모리를 "에이전트 아키텍처에 직접 내장되기 때문에 가장 논의가 적은 메모리 타입"으로 설명합니다. 너무 당연히 거기 있기 때문에 오히려 메모리로 인식되지 않는 셈입니다.

절차적 메모리의 효용은 반복적인 다단계 워크플로우에서 분명합니다. 코드 리뷰 에이전트라면 "어떤 순서로 어떤 검사를 돌리는지"가, 데이터 파이프라인 에이전트라면 "어떤 변환을 어떤 형식으로 적용하는지"가 절차적 메모리에 누적됩니다. 같은 작업을 반복할수록 절차적 메모리는 다듬어지고, 다듬어진 절차는 다음 작업의 성능을 끌어올립니다.

하지만 절차적 메모리에는 다른 메모리 타입에는 없는 고유의 문제가 있습니다. 회귀(regression) 위험입니다. 새로운 작업을 잘하도록 절차를 업데이트했더니 기존에 잘하던 작업이 무너지는 현상입니다. 특히 파인튜닝 가중치 형태의 절차적 메모리에서 이 위험은 큽니다. 모델 가중치는 한 곳을 건드리면 다른 곳이 어떻게 변할지 예측하기 어렵기 때문입니다. 상대적으로 프롬프트 템플릿과 도구 정의는 교체가 안전한 편이지만, 그 경계가 어디인지에 대한 업계 표준 업데이트 전략은 아직 정착되지 않은 미해결 과제입니다.

공유 메모리는 또 다른 축의 메모리입니다. 지금까지의 모든 메모리는 단일 에이전트가 혼자 쓰는 것을 전제했지만, 공유 메모리는 다수의 에이전트가 동시에 읽고 쓰는 중앙 저장소입니다. 멀티 에이전트 오케스트레이션에서 정보 공유의 기반이 되며, 에이전트 A가 발견한 사실을 에이전트 B가 활용하고 에이전트 C가 보완하는 흐름이 가능해집니다.

문제는 공유 메모리가 도입되는 순간 분산 시스템의 고전적 문제들이 그대로 따라온다는 점입니다. 두 에이전트가 동시에 같은 항목을 수정하면 어느 쪽이 이기는가(race condition), A가 쓴 내용을 B가 잘못 해석해서 다시 덮어쓰면 어떻게 추적하는가(쓰기 출처 추적), A가 B를 호출하고 B가 다시 A를 호출하면 무한 루프가 되지 않는가(순환 의존), 한 에이전트의 잘못된 정보가 전체에 퍼지면 어떻게 격리하는가(cross-agent contamination) — 이 모두가 데이터베이스 설계에서 수십 년간 다뤄온 주제와 본질적으로 같습니다.

실무 권장 순서가 "공유 메모리는 가장 마지막에 도입하라"인 이유가 여기에 있습니다. 격리 수준 설정(역할별 read-only / no-modify / draft-only), 트랜잭션 경계, 락 전략 — 이 모든 것을 단일 에이전트도 안정화되지 않은 상태에서 한꺼번에 짊어지면 시스템이 무너지기 쉽습니다.

저장 기술의 트레이드오프 — 벡터DB vs 지식 그래프 vs 이벤트 로그

지금까지 본 메모리 타입들은 결국 어딘가에 물리적으로 저장되어야 합니다. 그 저장 기술의 선택이 메모리 품질의 또 다른 변수입니다. 현재 실무에서 쓰이는 주요 저장 기술은 크게 세 가지로, 벡터DB·지식 그래프·이벤트 로그입니다.

벡터DB는 텍스트를 임베딩 벡터로 바꿔 저장하고 ANN(Approximate Nearest Neighbor) 인덱스로 유사도 검색을 제공합니다. 구현이 단순하고 광범위하게 지원되며, 의미론적으로 비슷한 텍스트를 빠르게 찾는 데 강합니다. 그래서 장기·일화적·의미론적 메모리의 기본 선택지로 가장 자주 쓰입니다.

그러나 벡터DB에는 두 가지 본질적 한계가 있습니다. 첫째, 유사도는 관련성을 보장하지 않습니다. 의미론적으로 비슷한 텍스트가 지금 필요한 정보와 일치한다는 보장이 없다는 뜻입니다. "고양이 사료 추천"이라는 쿼리에 "강아지 사료 비교" 문서가 높은 유사도로 잡힐 수 있습니다. 둘째, 규모 증가에 따른 성능 저하입니다. 10배 규모 증가 시 성능이 약 25% 저하된다는 보고가 있습니다. 모든 메모리를 단일 벡터DB에 무한히 쌓는 설계는 어느 시점에서는 반드시 깨집니다.

지식 그래프는 다른 접근입니다. 엔티티와 관계를 노드·엣지로 표현하는 구조화 저장소이며, (entity – relation – entity) 트리플 단위로 사실을 보관합니다. 강점은 다중 홉 추론입니다. "사용자가 자주 가는 카페의 사장이 추천한 책의 작가가 쓴 다른 책"처럼, 여러 관계를 거쳐야 답이 나오는 쿼리는 순수 유사도 매칭으로 연결할 수 없지만 그래프 탐색으로는 해결됩니다. 시간적 팩트 추적("이 사실은 언제부터 언제까지 유효했나"), 설명 가능성("이 답이 왜 이 답인가"), 계층적 조직화에서도 우위가 있습니다.

수치로 보면 차이가 더 분명합니다. Zep의 시간 기반 지식 그래프 구현은 MemGPT 대비 94.8% vs 93.4% 정확도, 응답 지연 90% 감소를 달성했다고 보고합니다. 다만 GraphRAG 계열에는 분명한 트레이드오프가 있습니다. 텍스트에서 엔티티와 관계를 추출하는 단계가 LLM 호출에 크게 의존하기에 추출 비용이 높고, 임베딩 인덱스 대비 GPU 오버헤드가 크며, 동적으로 콘텐츠가 갱신되는 환경에서는 그래프 갱신 지연이 발생합니다. 이 비용을 감수할 만큼 다중 홉 추론이 필요한지가 도입 판단의 핵심이 됩니다.

이벤트 로그는 세 번째 축입니다. 모든 작업을 시간 순서로 추가-전용(append-only)으로 기록하는 단순한 구조이며, 일화적 메모리의 원자 저장소로 자주 쓰입니다. 단독으로 검색 성능을 내기는 어렵지만, 벡터DB·지식 그래프의 인덱스를 이벤트 로그 위에 얹는 구조가 자연스럽습니다. "원본은 로그에, 인덱스는 벡터/그래프에"라는 분업입니다.

현재 전문가 컨센서스는 셋 중 하나를 고르라는 것이 아니라 상호 보완적 하이브리드입니다. 한 자료의 표현을 빌리면, "그래프 기반 메모리는 전통 설계를 대체하는 것이 아니라 통합된 확장 가능한 프레임워크를 제공한다"는 것입니다. 신뢰할 수 있는 멀티 에이전트 시스템은 벡터·그래프·로그 세 가지 메모리 계층을 조합하되, 각 계층의 역할과 실패 모드를 명확히 분리해야 한다는 지적도 같은 맥락입니다.

저장 기술	핵심 강점	본질적 한계	주 사용 메모리
벡터DB	구현 단순·광범위 지원·의미 유사도 검색	유사도 ≠ 관련성, 규모 증가 시 25% 성능 저하	장기·의미론적
지식 그래프	다중 홉 추론·시간 팩트 추적·설명 가능성	추출 비용·GPU 오버헤드·갱신 지연	의미론적·일화적
이벤트 로그	원본 보존·append-only·시간 정렬	단독 검색 성능 낮음	일화적 (원자 저장)

다층 메모리 스택 설계 — 어떤 조합을 어떤 순서로 도입할까

여기까지 6가지 메모리와 3가지 저장 기술을 살펴봤다면, 자연스럽게 따라오는 질문이 있습니다. "그래서 내 에이전트에는 어떤 조합을 어떤 순서로 넣어야 하나?" 결론부터 말하면, 실전 에이전트는 거의 항상 단일 메모리가 아닌 다층 스택(layered stack)으로 구성됩니다. 그리고 그 스택의 모양은 도메인에 따라 달라집니다.

자주 쓰이는 조합 패턴은 대략 네 가지입니다. 개인화 챗봇은 단기 + 장기. 사용자별 일관성만 유지되면 충분합니다. RAG 시스템은 단기 + 장기 + (선택적) 의미론적. 문서 검색에 더해 자주 묻는 사실들을 정제해두면 토큰 비용이 크게 줄어듭니다. 자기 개선 코딩 에이전트는 단기 + 일화적 + 절차적. "지난번에 실패한 패턴"을 일화적으로 기록하고, "성공한 패턴"은 절차적 도구로 굳혀나갑니다. 멀티 에이전트 워크플로우는 위 조합 + 공유 메모리. 에이전트 간 정보 공유가 필요한 순간 공유 메모리가 추가됩니다.

도입 순서의 일반 권장은 단기 → 장기 → 일화적 → 의미론적 → 절차적 → 공유입니다. 가장 적은 설계 비용으로 가장 큰 효과를 주는 순서이며, 뒤로 갈수록 복잡도와 운영 부담이 커집니다. 다만 이 순서는 절대적이지 않습니다. 의료·법률처럼 시점별 사실 정확성이 결정적인 도메인에서는 의미론적 메모리(특히 시간 추적이 되는 지식 그래프)가 거의 처음부터 필요할 수 있고, 처음부터 멀티 에이전트로 설계되는 시스템이라면 공유 메모리의 격리 모델을 초기에 잡고 가는 것이 더 안전할 수도 있습니다.

순서보다 더 중요한 질문이 있습니다. "내 에이전트가 풀려는 진짜 한계가 무엇인가?" 시간 지속성이 부족해서 단기 한계에 부딪히고 있는지, 경험이 누적되지 않아 같은 실수를 반복하는지, 협업이 안 되어 멀티 에이전트가 충돌하는지 — 이 진단이 빠진 채로 "유행하는 메모리 스택"을 그대로 따라 박으면 그것은 거의 항상 과잉 설계가 됩니다. 메모리는 한계를 풀기 위한 처방이지, 그 자체가 목적이 아닙니다.

마지막으로, 메모리 설계에서 흔히 놓치는 원칙 하나를 강조하겠습니다. 완벽한 무한 보존은 아키텍처 결함이라는 점입니다. 모든 정보를 영원히 기억하려는 시스템은 결국 검색 품질이 무너지고, 저장 비용이 폭증하며, stale 데이터에 의한 환각이 늘어납니다. 그래서 실전 메모리 설계는 거의 항상 지능형 망각(intelligent forgetting) 메커니즘을 함께 둡니다. 에빙하우스 망각 곡선에서 영감을 받은 TTL 계층(중요 정보 = 무한, 임시 정보 = 7~30일), 사용 시점마다 관련성 점수를 갱신하는 방식, 충돌이 발생했을 때 시간 기반으로 어느 쪽을 살릴지 조정하는 규칙 — 이 세 가지가 자주 함께 쓰입니다.

정리하면 메모리 설계는 다음 순서의 질문에 답하는 작업입니다. 첫째, 내 에이전트가 풀려는 한계는 무엇인가. 둘째, 그 한계에 대응하는 메모리 타입은 무엇인가. 셋째, 그 메모리를 어떤 저장 기술에 얹을 것인가. 넷째, 무엇을 언제 버릴 것인가. 6가지 메모리 타입은 이 질문들에 답하기 위한 선택지의 지도이지 정답 목록이 아닙니다. 자신의 에이전트에 맞춰 지도를 다시 그리는 것은, 결국 모델이 아니라 설계자의 몫입니다.

정리

LLM 에이전트의 성능을 끌어올리는 가장 큰 레버 중 하나는 모델 교체가 아니라 메모리 설계입니다. 단기·장기·일화적·의미론적·절차적·공유라는 6가지 메모리 타입은 각각 컨텍스트 윈도우의 서로 다른 한계 — 시간 지속성, 경험 누적, 시간축 처리, 지식 정제, 방법 보존, 협업 — 를 메우기 위한 구조적 처방입니다. 어떤 메모리도 만능이 아니며, 모든 메모리는 그 효용만큼 분명한 한계(검색 품질 의존, 무한 증가, stale 위험, 회귀 위험, 동시성 충돌)를 함께 가집니다.

저장 기술 측면에서 벡터DB는 기본 선택지이지만 유사도와 관련성의 차이, 규모 증가 시 성능 저하라는 한계가 있고, 지식 그래프는 다중 홉 추론과 시간적 일관성에서 우위지만 추출 비용과 갱신 지연을 감수해야 합니다. 이벤트 로그는 원본 보존 계층으로서 두 기술 아래에 자연스럽게 깔립니다. 셋은 경쟁 관계가 아니라 하이브리드로 묶어 쓰는 것이 현재 컨센서스입니다.

실전에서는 단일 메모리가 아닌 다층 스택이 표준입니다. 일반 도입 순서(단기 → 장기 → 일화적 → 의미론적 → 절차적 → 공유)는 출발점일 뿐이며, 진짜 결정은 "내 에이전트가 풀려는 한계가 무엇인가"라는 질문에 답하는 데서 시작합니다. 그리고 어떤 스택을 쌓더라도, 무한 보존이 아니라 지능형 망각을 함께 설계해야 메모리가 자산이 아닌 부채로 변하는 것을 막을 수 있습니다.

이 글이 자신의 에이전트에 어떤 메모리 조합을 어떤 순서로 도입할지 판단하는 지도가 되었기를 바랍니다. 다음 단계로는 자주 쓰는 조합 패턴 중 하나(예: RAG = 단기 + 장기 + 의미론적)를 골라, 저장 기술과 망각 정책까지 구체화한 작은 프로토타입을 만들어 보는 것을 권합니다. 실제로 한 층씩 쌓아가며 검색 품질과 토큰 비용을 측정해 보는 것이, 6분류 표를 외우는 것보다 훨씬 빠른 학습 경로입니다.

---

[1] Atlan, "Types of AI Agent Memory: Episodic, Semantic, Procedural and More". https://atlan.com/know/types-of-ai-agent-memory/
[2] Redis, "AI agent memory: types, architecture & implementation". https://redis.io/blog/ai-agent-memory-stateful-systems/
[3] Mem0, "State of AI Agent Memory 2026". https://mem0.ai/blog/state-of-ai-agent-memory-2026
[4] Sumers et al., "Cognitive Architectures for Language Agents (CoALA)", arXiv:2309.02427, Princeton, 2023. https://arxiv.org/abs/2309.02427
[5] "Graph-based Agent Memory: Taxonomy, Techniques, and Applications", arXiv:2602.05665. https://arxiv.org/html/2602.05665v1
[6] Analytics Vidhya, "Architecture and Orchestration of Memory Systems in AI Agents". https://www.analyticsvidhya.com/blog/2026/04/memory-systems-in-ai-agents/
[7] MarkTechPost, "Comparing Memory Systems for LLM Agents: Vector, Graph, and Event Logs". https://www.marktechpost.com/2025/11/10/comparing-memory-systems-for-llm-agents-vector-graph-and-event-logs/