콘텐츠로 이동

2026년 AI 에이전트 메모리: 지식 그래프, 시간 사실, OS 스타일 페이징

· 13 min read · default
aiagentsmemoryknowledge-graphsragllm

2023년에 만들어진 에이전트에게 지난주 말한 것을 물어보세요. 그것은 쾌활하게 뭔가 만들어 낼 것입니다. 왜냐하면 그것은 아무 생각이 없기 때문입니다. 모델의 컨텍스트 윈도우 — 아무리 크더라도 — 는 작업 메모리이지 장기 메모리가 아닙니다: 현재 프롬프트에 맞는 것을 유지하고 대화가 끝나거나 윈도우가 넘칠 때 즉시 모든 것을 잊습니다. 일회성 질문에 답하는 챗봇의 경우, 이는 문제없습니다. 주(week)에 걸쳐 당신을 도우려는, 당신의 선호도를 기억하고, 프로젝트를 추적하거나, 시간에 따라 변하는 사실에 대해 추론해야 하는 에이전트의 경우, 치명적 제한입니다. 더 큰 컨텍스트 윈도우는 이를 수정하지 않습니다. 그것은 단지 망각을 지연시키고 각 호출을 더 비싸게 만듭니다. 에이전트가 필요한 것은 메모리 레이어 — 무엇을 지속할지 결정하고, 검색할 수 있도록 구조화하고, 그것이 중요할 때 관련 조각을 다시 컨텍스트에 주입하는 시스템입니다.

2026년까지, 에이전트 메모리는 자체 규율이 되었고, 자체 도구, 벤치마크, 건축 토론을 가집니다. 이 가이드는 환경을 조사합니다: 왜 컨텍스트 윈도우가 메모리가 아닌지, 세 가지 지배적 건축 접근 (벡터, 그래프, 시간), 그리고 그것들을 구현하는 주요 오픈소스 프레임워크 — Mem0, Cognee, GraphitiZep, Letta/MemGPT. 목표는 당신의 에이전트가 실제로 필요한 메모리의 종류에 대해 추론하고 어느 도구가 맞는지 이해할 수 있도록 남기는 것입니다. 최근에 유행했던 프레임워크를 무작정 가져오는 대신.

컨텍스트 윈도우가 메모리가 아닌 이유

유혹적인 주장은 다음과 같습니다: 컨텍스트 윈도우가 계속 커지고 있으니 그냥 모든 것을 프롬프트에 넣으세요. 이는 세 가지 구체적인 이유로 실패합니다. 첫째, 비용과 지연시간은 컨텍스트로 확장됩니다. 프롬프트의 모든 토큰은 모든 호출에서 결제되므로, 한 달의 히스토리를 각 요청에 채우는 에이전트는 돈을 태우고 기억하는 양에 따라 선형적으로 속도를 늦춥니다. 둘째, 매우 긴 컨텍스트에서 관련성이 저하됩니다. 모델은 매우 긴 컨텍스트에서 불완벽하게 주의를 기울이고, 수만 개의 무관 토큰 중 하나의 관련 사실을 묻어버리면 측정 가능하게 검색과 추론을 해합니다 — "중간에서 잃어버린" 문제. 셋째, 그리고 가장 근본적으로, 윈도우는 일시적입니다. 세션이 끝나면 컨텍스트는 사라집니다. 뭔가 의도적으로 저장하지 않으면 다음 대화에 지속되지 않습니다.

메모리 레이어는 접근을 역전시켜 모든 세 가지를 해결합니다. 모든 것을 수행하는 대신, 정보를 컨텍스트 외부에서 오래 저장하고, 매 턴마다 작고 관련 있는 조각만 검색하여 주입합니다. 에이전트의 프롬프트는 마른 상태로 유지되고, 비용은 제한되고, 관련성은 높으며 — 중요하게 — 메모리는 세션 전체에서 살아남습니다. 흥미로운 질문은 무엇을 해야 하는가가 아니라 구조화되어야 하는 방법이고, 그 곳에서 접근이 달라집니다.

방법 1: 벡터 메모리

가장 간단한 메모리 레이어는 사실을 벡터 데이터베이스에 임베딩으로 저장하고 의미 유사성으로 검색합니다 — 본질적으로 에이전트 자신의 히스토리에 적용되는 RAG. 에이전트가 뭔가 배우면 ("사용자가 다크 모드를 선호합니다"), 임베딩하고 저장합니다; 컨텍스트가 필요하면, 현재 상황을 임베딩하고 가장 가까운 저장 메모리를 검색합니다. 이는 기초이고, 특정 작업에 잘 작동합니다: 개인화 및 개별 사실의 회상.

Mem0은 이 형태의 주요 프레임워크이고, 원본 벡터 저장소보다 더 정교합니다. 그것은 다층 시스템을 제공합니다 — 사용자, 세션, 에이전트 범위 — 벡터, 그래프 관계, 키 값 조회를 결합하는 하이브리드 저장소를 지원하고, 그것은 능동적 메모리 관리를 수행합니다: 대화에서 두드러진 사실을 추출하고, 통합하고, 무분별하게 추가하는 대신 업데이트합니다. 대화 개인화 — 이름, 선호도, 반복하는 작업을 기억하는 어시스턴트 — 이는 종종 정확히 맞고, 필요한 메모리가 본질적으로 잘 관리된 사용자 사실 집합일 때 가장 강한 선택입니다.

순수 벡터 메모리의 제한은 각 사실을 격리된 포인트로 취급합니다. "사용자가 Acme에서 일합니다"와 "사용자는 CTO입니다"를 검색할 수 있지만, 이 사실이 연결되어 있거나 관계에 대해 추론한다는 것을 본질적으로 나타내지 않습니다. 메모리가 구조화해야 할 때 — 사실 간의 관계가 사실만큼 중요할 때 — 그래프가 그림에 들어갑니다.

방법 2: 그래프 메모리

그래프 기반 메모리는 정보를 지식 그래프로 저장합니다: 엔티티는 노드, 관계는 엣지. 독립적인 사실의 가방 대신, 에이전트의 메모리는 연결된 구조가 되고, 벡터 유사성이 도달할 수 없는 추론을 잠금 해제합니다 — 다중 홉 질문, "X와 Y가 어떻게 관련되어 있는가", 많은 연결된 사실 전체에서의 합성.

CogneeECL 파이프라인 — Extract, Cognify, Load를 갖는 그래프 네이티브 접근을 exemplifies합니다. 많은 소스 타입에서 데이터를 수집하고, 엔티티와 관계의 지식 그래프를 구축하는 "cognify"로 구조화하고, 검색을 위해 그래프와 벡터 저장소로 로드합니다. 결과는 메모리가 수동적 저장소가 아닌 활성적이고 쿼리 가능한 구조이고, 클라우드 종속성 없이 그래프 추론을 원할 때 로컬 우선, 프라이버시 중심 배포에 적합합니다. 에이전트가 지식 본문 전체 점을 연결해야 할 때 — 단순히 격리된 사실을 회상하지 않고 — 그래프 메모리와 같은 Cognee의 아키텍처가 그것을 지원합니다.

그래프 메모리의 강점은 정확히 그 구조이고, 그 비용은 그래프를 구축하고 유지하는 것이 저장소에 벡터를 떨어뜨리는 것보다 더 많은 일이라는 것입니다. 추출은 엔티티와 관계를 올바르게 식별해야 하고, 새 정보가 도착할 때 그래프를 업데이트해야 합니다. 에이전트의 값이 연결된 지식에 대한 추론에 달려 있는 경우, 그 비용은 지불할 가치가 있습니다; 간단한 개인화의 경우, 그것은 과하게 하는 것입니다.

방법 3: 시간 메모리

그래프는 관계를 캡처하지만, 평범한 그래프는 미묘한 맹점을 가집니다: 그것은 무엇이 참인지를 나타내지만, 언제 참이었는지 또는 어떻게 변했는지는 나타내지 않습니다. 현실 세계 사실은 히스토리를 가집니다 — 누군가가 직업을 바꾸고, 프로젝트가 단계를 이동하고, 선호도를 업데이트합니다 — 그리고 이전 사실을 덮어쓰는 에이전트는 변화에 대해 추론할 능력을 잃지만, 시간 구조 없이 둘 다 유지하는 에이전트는 모순으로 혼동됩니다. 시간 지식 그래프는 모든 사실에 유효성 시간을 부착하여 이를 해결합니다.

Graphiti, Zep의 엔진, 주요 오픈소스 구현입니다. 그 엣지는 양시간이고, 세계에서 사실이 참이었을 때와 언제 수집되었을 때를 모두 추적합니다 — 그리고 — 중요하게 — 사실이 바뀔 때, Graphiti는 이전 사실을 삭제하지 않습니다. 이전 엣지를 무효 타임스탐프로 표시하고 새 것을 기록하므로, 히스토리가 보존되고 시점 쿼리 ("지난 달 현재 시점에서 무엇이 참이었는가?")가 가능합니다. 데이터를 증분적으로 수집합니다, 전체 그래프를 재계산하지 않고 에피소드를 추가합니다. 이는 현재 상태로 유지되어야 하는 메모리에 적합합니다. 에이전트가 변화하는 사실에 의존할 때 그리고 에이전트가 히스토리를 유지하면서 현재 진실로 추론하는 것이 중요하면, 시간 메모리가 접근입니다. Graphiti/Zep이 그것의 가장 명확한 표현입니다.

이 시간 기능은 정확히 2026년 에이전트 메모리의 경계입니다. 왜냐하면 너무 많은 현실 에이전트 작업이 진화하는 상태를 포함하기 때문입니다. 고객 관계, 코드베이스, 또는 긴 프로젝트를 추적하는 에이전트는 이것 없이 익사합니다 — 모든 업데이트는 히스토리를 덮어쓰거나 모순으로 축적합니다. 시간 그래프는 원칙있는 답을 제공합니다.

방법 4: OS 스타일 메모리 관리

네 번째 접근은 문제를 완전히 재구성합니다. 애플리케이션이 쿼리하는 별개 저장소보다, MemGPT — 이제 Letta 프레임워크 — 는 메모리를 운영체제처럼 모델링합니다. 컨텍스트 윈도우는 RAM입니다: 빠르고 작으며, 지금 활성적인 것을 유지합니다. 아카이브 저장소는 디스크입니다: 크고 검색 가능하며, 다른 모든 것을 유지합니다. 그리고 에이전트 자체는 OS이고, 도구 호출을 통해 무엇을 메인 컨텍스트로 페이징할지, 무엇을 아카이브 메모리로 쓸지 결정합니다. 에이전트는 도구 (core_memory_append, core_memory_replace)를 통해 자신의 항상 인컨텍스트 "코어 메모리" 블록을 편집하고, 페이징해 낸 것이 필요할 때 아카이브 메모리를 검색합니다.

이 모델의 우아함은 메모리 관리가 응용 프로그램에 의해 볼트된 로직이 아니라 에이전트 자신의 책임이 되고 도구를 통해 행사된다는 것입니다. 이는 Letta를 장기 실행 자율 에이전트에 특히 적합하게 만들고, 최소한의 외부 조율로 확장된 작업 전체에 일관된 상태를 유지해야 합니다 — 에이전트가 프로그램이 자신의 주소 공간을 관리하는 방식으로 자신의 메모리를 관리합니다. 트레이드오프는 에이전트의 판단에 대해 정확히 무엇이 저장되어야 하는지에 대한 외부 제어를 원할 때, 그것은 덜 작동합니다. 에이전트가 유능하고 작업이 자율을 보상할 때 잘 작동합니다.

메모리 작업: 추출, 통합, 망각

저장 아키텍처 너머, 메모리 레이어는 저장하는 것을 관리해야 합니다. 그리고 이 운영 측면은 진정한 메모리 시스템을 영광스러운 로그로부터 분리합니다. 세 가지 작업이 중요합니다. 첫 번째는 추출: 원본 대화를 저장 가능한 메모리로 바꾸기. 모든 문장이 기억할 가치가 있는 것은 아니고, 모든 것을 저장하는 것은 다른 장소에서 컨텍스트 윈도우 문제를 재현합니다. 좋은 메모리 시스템은 두드러진 사실을 추출합니다 — 선호도, 결정, 엔티티, 관계 — 잡담을 버리고, Mem0 같은 프레임워크가 전체 트랜스크립트를 저장소로 버리는 대신 능동적 사실 추출을 수행하는 이유입니다.

두 번째는 통합: 새 정보를 이미 저장된 것과 조화시키기. 에이전트가 기존 메모리를 업데이트하거나 모순하는 뭔가를 배우면, 순진한 시스템은 중복을 생성합니다 (저장소가 거의 동일한 사실으로 채워집니다) 또는 무분별하게 덮어씁니다 (히스토리 손실). 정교한 메모리 레이어는 새 사실이 이전 사실과 관련이 있음을 탐지하고 통합합니다 — 중복 병합, 값 업데이트, 또는 시간 시스템에서 이전 사실을 무효화하면서 새 것을 타임스탐프로 기록. 이는 메모리와 시간이 지나감에 따라 날카로워지는 메모리와 모순의 더미로 저하되는 메모리 간의 차이입니다.

세 번째, 저평가된, 작업은 망각입니다. 인간 메모리는 적응적으로 잊어버립니다, 중요한 것을 유지하고 무관한 세부를 사라지도록 놔두고, 에이전트 메모리는 아날로그가 필요합니다. 가지치기 없이, 장기 실행 에이전트의 메모리는 제한 없이 증가하고, 검색은 느려지고, 오래된 사실은 결과를 오염시킵니다. 의도적 망각 — 저가치 메모리 감소, 액세스되지 않은 것 아카이브, 또는 메모리 크기 캡 — 시스템을 건강하게 유지합니다. 프레임워크는 자동화 정도와 애플리케이션에 남겨두는 정도가 다르고, 확인할 가치가 있습니다. 왜냐하면 메모리 레이어는 계속 축적만 하는 것은 결국 저하되는 메모리 레이어이기 때문입니다. 프레임워크를 평가할 때, 저장하는 방법뿐만 아니라 어떻게 추출, 통합, 망각하는지 묻습니다. 메모리 품질이 에이전트가 실행되면서 개선되는지 또는 저하되는지를 결정하는 운영 행동이기 때문입니다.

메모리 레이어 선택

결정은 에이전트가 실제로 기억해야 할 것과 어떻게 하는지로부터 따릅니다. 만약 작업이 사용자 사실의 개인화 및 회상이면 — 선호도와 히스토리를 기억하는 어시스턴트 — Mem0로 시작하세요; 그것의 관리된 다층 벡터 중심 메모리는 그를 위해 목적 지어지고 가장 가벼운 채택입니다. 에이전트가 연결된 지식에 대해 추론해야 하고, 관련 사실의 웹 전체에 걸쳐 합성하려면, 특히 로컬 우선 프라이버시가 중요할 때, Cognee처럼 그래프 네이티브 레이어를 선택하세요. 에이전트가 시간에 따라 변하는 사실에 의존하고 히스토리를 보존하면서 현재 진실로 추론해야 하면, Graphiti/Zep의 시간 그래프를 선택하세요. 그리고 당신이 최소한의 조율로 자신의 메모리를 관리해야 하는 장기 실행 자율 에이전트를 구축하고 있으면, Letta/MemGPT를 선택하세요.

이 카테고리는 엄격하지 않습니다 — Mem0는 그래프 관계를 통합하고, Cognee는 그래프와 벡터를 혼합하고, 현실 시스템은 종종 접근을 결합합니다. 하지만 중심 중력 프레이밍은 유용한 것입니다: 메모리 아키텍처를 에이전트가 기억해야 할 것의 형태와 맞춥니다. 흔한 실수는 단순 개인화가 하는 곳에 시간 지식 그래프를 가져가기, 사용하지 않는 능력을 위해 복잡도 비용을 지불하는 것입니다; 반대 실수는 전체 가치가 변화에 대한 추론에 달려 있는 에이전트에 평면 벡터 저장소를 볼트하는 것입니다. 먼저 메모리 필요를 진단하고, 그 후 그것에 맞는 아키텍처를 선택합니다.

핵심

컨텍스트 윈도우는 작업 메모리이지 장기 메모리가 아닙니다: 그것은 일시적이고, 커질 때 비싸지고 초점을 잃으며, 세션 간에 모든 것을 잊습니다. 현실 에이전트 메모리는 컨텍스트 외부 정보를 오래 저장하고 수요에 따라 관련 조각을 검색하는 전담 레이어에 산다. 그리고 2026년 그 레이어는 네 가지 맛이 온다 — 개인화를 위한 벡터 (Mem0), 연결된 지식 추론을 위한 그래프 (Cognee), 시간에 따라 변하는 사실을 위한 시간 그래프 (Graphiti/Zep), 그리고 자율 장기 실행 에이전트를 위한 OS 스타일 페이징 (Letta/MemGPT). 에이전트가 실제로 무엇을 기억해야 하는지 진단하고, 그것에 맞는 아키텍처를 맞추고, 에이전트는 지난주에 대해 뭔가 만들어 내기를 멈춥니다 — 왜냐하면 그것은 실제로 기억하기 때문입니다.

참고 및 리소스

프레임워크

배경 및 분석

관련 1337skills 치트시트