Executive Summary

언어 모델은 기본적으로 무상태(stateless)다. 한 번의 요청에 담긴 프롬프트만 보고 답하고, 답을 내보내는 순간 그 대화는 모델의 머릿속에서 사라진다. 컨텍스트 윈도우 바깥은 존재하지 않는 세계다. 그래서 상담 챗봇에게 "그럼 그건 왜죠?"라고 이어 물으면 앞의 맥락을 잃고 엉뚱한 대답을 한다. 흔히 이 현상을 "기억력이 나쁘다"고 표현하지만, 정확히는 앞 대화를 애초에 보내지 않았을 뿐이다.

이 진단이 중요한 이유는, 해법의 난이도를 완전히 바꾸기 때문이다. 문제가 "장기 기억의 부재"라면 벡터DB와 검색 파이프라인과 추출 로직을 갖춘 무거운 시스템이 필요하다. 하지만 문제가 "앞 대화를 안 보낸 것"이라면, 매 요청에 이전 대화를 함께 실어 보내는 것만으로 대부분 풀린다. 페블러스 상담 제품(내부 코드네임 4호)이 지금 마주한 결핍이 바로 후자다. 기억 문제의 상당 부분은 장기 기억이 없는 게 아니라, 방금 나눈 말을 다시 건네지 않은 데서 온다.

이력을 통째로 보내면 비용이 제곱으로 는다

그런데 "앞 대화를 함께 보낸다"를 순진하게 구현하면 곧 벽에 부딪힌다. 매 턴마다 지금까지의 전체 대화를 다시 실어 보내면, 대화가 길어질수록 입력 토큰이 대화 길이의 제곱(O(n²))으로 불어난다. 10번째 턴에서 앞 9턴을 함께 보내고, 50번째 턴에서 앞 49턴을 함께 보내는 식이니, 누적 비용은 걷잡을 수 없이 커진다. 대안은 단순하다. 오래된 턴은 고정 크기의 요약으로 접고, 최근 몇 턴만 원문으로 유지하는 것이다. 그러면 누적 토큰이 선형(O(n))으로 수렴한다.

아래 표는 이 차이를 예시로 추정한 것이다. 상담 대화 한 턴(질문과 응답)을 평균 150토큰으로 잡고, 방식 A는 매 턴 전체 이력을 재전송, 방식 B는 고정 요약 600토큰에 최근 10턴만 원문으로 유지한다고 가정했다. 특정 논문의 수치가 아니라 두 방식의 증가 곡선을 비교하기 위한 계산이다.

예시 추정 계산(조사자 자체 산정, 특정 논문 수치 아님). Claude Sonnet 5 입력 도입가 $2/M 기준으로 환산하면 200턴 대화 누적 비용은 방식 A 약 $6.03, 방식 B 약 $0.81이다.

이 곡선의 벌어짐을 그림으로 보면 더 분명하다. 아래는 두 방식의 누적 입력 토큰을 대화 길이에 따라 그린 것이다. 방식 A는 위로 휘어 오르고, 방식 B는 완만한 직선에 가깝게 눕는다.

요약 접기가 무엇을 남기고 무엇을 버릴지의 설계라는 점은 뒤에서 다시 다룬다. 우선 확인할 것은 이 방법이 프레임워크 없이, 표준 라이브러리만으로 구현 가능한 가장 가벼운 해법이라는 사실이다.

"기억한다"는 한 단어는 실은 서로 다른 대여섯 개의 기능을 뭉뚱그린 말이다. 무엇이 필요한지부터 갈라야 도구 선택이 명확해진다. 대화형 AI의 기억은 크게 두 축으로 나뉜다. 하나는 지금 이 순간 프롬프트 안에 담긴 작업 기억(컨텍스트 윈도우)이고, 다른 하나는 대화가 끝나도 밖에 남겨 두는 장기 기억이다. 장기 기억은 다시, 언제 무슨 일이 있었는지를 담는 일화적(episodic) 기억과, 사실과 선호를 압축해 담는 의미적(semantic) 기억으로 갈린다.

여기에 기억을 다루는 세 가지 동작이 겹친다. 무엇을 저장할지, 질의 시점에 무엇을 검색할지, 시간이 지나 무엇을 갱신·폐기할지다. 다섯 프레임워크는 이 지도 위 서로 다른 자리에 선다. Letta는 작업 기억 자체를 스스로 편집하고, Mem0는 의미적 기억을 얇게 붙이며, Zep은 일화적·의미적 사실을 시간 축이 있는 그래프로 쌓는다. LangGraph는 작업 기억의 스냅샷을 저장·복원하고, LlamaIndex는 검색(RAG)과 대화 버퍼를 묶는다.

큰 컨텍스트 윈도우가 요약을 대체하지 못한다

2026년 현재 주요 모델의 컨텍스트 윈도우는 1M 토큰에 이르렀고, 초과 구간 서차지도 대부분 사라졌다. 그러니 "이제 대화를 통째로 넣어도 되지 않느냐"는 반론이 자연스럽다. 아래는 대표 모델의 윈도우 크기와 입력 가격이다.

출처: Anthropic 공식 발표(2026-06-30), Morph LLM context window comparison(2026). 2026년 3월부로 Anthropic은 200K 초과 롱컨텍스트 서차지를 폐지했다.

문제는 광고된 크기와 실제로 쓸 수 있는 크기가 다르다는 점이다. NVIDIA RULER는 22개 주요 모델에서 실사용 가능한 컨텍스트가 광고치의 50~65%에 그친다고 보고했고, Adobe NoLiMa는 3.2만 토큰 지점에서 12개 모델 중 11개가 단문 대비 성능이 절반 밑으로 떨어졌다고 관찰했다. Chroma의 context rot 연구는 윈도우 크기와 무관하게 약 3만 토큰을 넘어서면서부터 성능 저하가 가속된다는 점을 짚었다.

이 분야의 원조는 Letta, 옛 이름으로 MemGPT다. 발상이 가장 우아하다. 운영체제가 한정된 RAM과 넉넉한 디스크 사이에서 페이지를 옮기며 무한한 메모리를 흉내 내듯, MemGPT는 한정된 컨텍스트 윈도우를 RAM처럼, 외부 저장소를 디스크처럼 다룬다. 모델은 자기 프롬프트 안의 핵심 기억(core memory) 블록을 스스로 편집하고, 넘치는 정보는 아카이벌(archival) 저장소로 페이징해 두었다가 필요할 때 다시 불러온다. 대화가 아무리 길어져도 핵심 기억을 손으로 고쳐 쓰며 유지하는 것이다.

원 논문(Packer 외, 2023, arXiv:2310.08560)은 이 방식이 DMR(Deep Memory Retrieval) 벤치마크에서 93.4%를 기록해, 재귀적 요약 베이스라인 35.3%를 크게 앞섰다고 보고했다. 다만 이 대비는 조심해서 읽어야 한다. 여기서 비교 대상이 된 "재귀적 요약"은 이후 Zep 팀이 "너무 쉬운 베이스라인"이라 비판한 설정이고, Zep은 같은 DMR에서 풀컨텍스트를 베이스라인으로 삼아 94.4%를 재현했다. 평가 조건이 다르므로 두 수치를 직접 비교할 수는 없다. 뒤에서 다시 보겠지만, 이 분야의 벤치마크는 대부분 이런 식으로 조건이 엇갈린다.

발상이 우아한 만큼 몸집은 무겁다. Letta는 라이브러리가 아니라 사실상 풀스택 서버다. PyPI 기준 직접 의존성이 118개에 이르고, Postgres·마이그레이션 도구 등을 함께 끌어온다. GitHub 스타는 23,817개로 화제성은 충분하지만, PyPI 월 다운로드(약 14.9만)는 나머지 넷에 비해 20~450배 작다. 화제성과 실제 설치 규모 사이의 간격이 이 도구의 성격을 잘 보여준다. 코어 라이선스는 Apache-2.0이라 자체 호스팅에 제약은 없다.

한마디로 가장 우아한 발상이지만 가장 무거운 몸집이다. "모델이 스스로 기억을 관리한다"는 그림은 매력적이나, 4호처럼 통제 가능성과 가벼움을 우선하는 제품에는 지금 단계에서 과한 도구다.

Letta가 모델 안에 기억을 집어넣는다면, Mem0와 Zep은 모델 바깥에 기억을 쌓는다. 둘 다 대화에서 사실을 뽑아 저장했다가 필요할 때 검색해 붙이지만, 저장하는 모양이 다르다. Mem0는 사용자별 사실을 얇은 층으로, Zep은 시간 흐름이 있는 지식 그래프로 쌓는다.

Mem0 — 사용자별 얇은 기억 층

Mem0의 그림은 단순하다. 대화가 오갈 때마다 "이 사용자가 전에 무엇을 물었고 무엇을 선호했나" 같은 사실을 추출해 저장하고(store), 다음 대화에서 관련된 것만 골라 검색해(retrieve) 프롬프트에 얇게 얹는다. 전체 이력을 다 넣는 대신, 이 사용자에게 필요한 조각만 붙이는 방식이다. 커뮤니티도 가장 크다. GitHub 스타 60,967개로 다섯 중 1위이고, PyPI 월 다운로드는 약 319만이다.

수치 주장은 화려하다. 원 논문(Chhikara 외, 2025, arXiv:2504.19413)은 LOCOMO에서 풀컨텍스트 대비 쿼리당 토큰을 약 90% 절감하고(2.6만 → 약 1,764토큰), p95 검색 지연을 크게 줄였다고 보고했다. 2026년 후속 블로그는 신형 알고리즘이 LOCOMO 91.6점, LongMemEval 93.4점에 이른다고 주장한다. 다만 이 후속 수치는 별도 논문 심사 없이 벤더 블로그에만 존재한다는 점을 함께 기억해야 한다.

Zep — 시간의 지식 그래프

Zep은 한 걸음 더 나아가, 대화에서 뽑은 사실을 시간 축(bi-temporal)이 있는 지식 그래프로 쌓는다. "언제 이 사실이 참이었고, 언제 우리가 그것을 알게 됐나"를 함께 기록하는 것이다. 질의 시점에 그 그래프를 검색해 답을 보강하니, 이는 사실상 그래프 검색 증강(graph RAG)의 한 갈래다. 원 논문(Rasmussen 외, 2025, arXiv:2501.13956)은 LongMemEval(gpt-4o)에서 71.2%로 풀컨텍스트 60.2%를 앞섰다고 보고했다. 정작 Zep 팀은 자기 논문에서 오래된 DMR 벤치마크가 최신 모델에는 너무 쉬워져 변별력을 잃었다고 스스로 인정했다. 벤더가 자기 벤치마크의 포화를 인정한 드문 사례다.

한결같이 이롭기만 한 것도 아니다. 같은 LongMemEval에서 대부분의 질문 유형은 개선됐지만 "단일 세션 어시스턴트" 유형만은 오히려 성능이 떨어졌다(gpt-4o 기준 약 17.7%p 하락). 사실을 그래프로 쪼개 저장하는 방식이 모든 질문에 유리하지는 않다는 뜻이다. 제3자 리뷰는 이 논문의 지연 측정이 비대칭이었다는 점도 짚었다. 원격 Zep 서버로의 왕복 네트워크 지연이 Zep 쪽 측정에만 얹히고 풀컨텍스트 베이스라인에는 없었다는 것이다. 벤더의 자체 수치는 유리한 쪽으로 프레이밍되기 쉽다는 사실을, 이 예외 항목이 오히려 정직하게 드러낸다.

두 도구의 성능 주장은 서로 반박한다. Mem0 논문은 Zep의 토큰 사용량을 대화당 60만+로 제시했지만, Zep은 Mem0의 벤치마크 설정(화자 라벨링, 타임스탬프를 메시지 텍스트에 삽입, 순차 검색)에 이의를 제기하며 자체 재현 시 LOCOMO 75.14%를 보고했다. Mem0가 발표한 Zep 점수(65.99%)보다 높은 숫자다. 어느 쪽도 단정할 수 없다. 이 상호반박 자체가 이 절의 교훈이다.

벤치마크를 향한 과최적화의 위험을 보여주는 사례도 있다. 한 메모리 시스템의 메인테이너는 "100%"라던 헤드라인 수치가 실제로는 "450문항 중 98.4%"였다고 정정하면서, 마지막 0.6%는 틀린 답을 하나하나 들여다보며 맞춘 것이라고 인정했다. 시험지를 미리 보고 공부하면 점수는 오르지만, 그 점수가 곧 실력을 뜻하지는 않는다. 벤더가 자기 벤치마크에 맞춰 시스템을 다듬는 순간, 그 수치는 독립 검증과 점점 멀어진다.

그래프 기억을 쓰려는데, Zep은 이제 설치형이 아니다

여기서 이 보고서만의 사실 하나를 짚어야 한다. Zep은 2025년 4월, 자체 호스팅형 오픈소스인 Zep Community Edition의 유지·업데이트를 중단한다고 공식 블로그로 발표했다. 코드는 저장소의 legacy/ 폴더로 옮겨졌고 더 이상 지원되지 않는다. 사유는 "완전 오픈소스 커뮤니티 버전과 기능이 풍부한 상용 서비스를 동시에 유지하는 것이 서로 타협을 강요했다"는 것이다. 이후 Zep의 오픈소스 역량은 시간 그래프 엔진인 Graphiti(Apache-2.0)에 집중됐다.

이 변화는 지형을 바꾼다. 그래프 검색 증강이 필요하다고 해서 이제 "Zep을 설치"할 수는 없다. 대신 Graphiti 엔진에 Neo4j·FalkorDB·Kuzu 같은 그래프DB를 직접 프로비저닝하고, Zep이 관리형으로 제공하던 멀티테넌시·인제스천 파이프라인·관측성은 직접 만들어야 한다. 실제로 자체 호스팅 경로의 유지보수 우선순위가 낮다는 정황도 보인다. 커뮤니티 제보에 따르면 공식 Docker 이미지가 6개월 이상 옛 버전(v0.10)에 머물러 있던 사이 실제 최신 릴리스는 v0.22를 넘어섰다. 상징적으로도 Graphiti 저장소(28,799 스타)가 Zep 저장소(4,757 스타)보다 6배 이상 크다. 설치형을 원하는 사람들이 이미 엔진 쪽으로 몰렸다는 신호다.

형님이 관심을 둔 그래프 검색 증강과 한 갈래인 Zep이, 정작 설치형으로는 더 이상 살 수 없게 됐다. 그래프 기억이 진짜 필요해지는 날이 오면, 이제 후보는 "Zep 도입"이 아니라 "Graphiti 조립" 또는 "Mem0 부착"이다.

앞의 셋이 "기억"을 전문으로 다루는 도구라면, LangGraph와 LlamaIndex는 그보다 넓은 종합 프레임워크다. 기억은 그 안의 한 기능일 뿐이다. LangGraph는 대화 상태를 체크포인트로 저장하고 복원하는 데 강하다. 스레드 단위로 대화의 스냅샷을 남겨 두었다가, 중단된 지점부터 다시 이어 갈 수 있다. LlamaIndex는 검색 증강(RAG)과 채팅 기억 버퍼를 묶는 데 강하다. 문서 인덱스에서 관련 내용을 찾아오고, 최근 대화를 버퍼로 유지하는 두 흐름을 하나로 엮는다.

두 도구를 두고 흔히 "짐이 크다"고 한다. 그런데 이 말은 라이선스 문제가 아니다. 둘 다 코어가 각각 MIT 라이선스라 상업 사용과 자체 호스팅에 제약이 없다. 문제는 의존성의 무게와 강요되는 사고방식이다.

의존성부터 보면 표면 숫자가 오히려 오해를 부른다. 메타패키지 자체의 직접 의존성은 LangGraph 6개, LlamaIndex 4개로 가장 가벼워 보인다. 하지만 진짜 무게는 그 아래 깔린 핵심 서브패키지에 숨어 있다. langchain-core와 llama-index-core, 그리고 이들이 다시 끌어오는 임베딩·벡터DB·LLM 프로바이더 어댑터들이다. 표면 의존성 수 하나로 "가볍다"고 단정하면 실제 설치 트리에서 배신당한다.

채택 지표도 이 함정을 잘 보여준다. LangGraph의 PyPI 월 다운로드는 약 6,669만 회로 다섯 중 압도적 1위지만, 이는 액티브 사용자 수가 아니라 langchain 생태계의 다른 패키지가 전이 의존성으로 자동 설치하는 횟수를 대량 포함한다. GitHub 스타 순위(37,419개로 2위)와 다운로드 순위(1위, 나머지의 20~450배)가 어긋나는 것이 그 증거다. 스타가 곧 실사용은 아니고, 다운로드도 곧 실사용은 아니다.

종합 프레임워크는 여러 기능을 한 번에 얻고 싶을 때 값지다. 하지만 필요한 것이 "대화 상태를 이어 가기"뿐이라면, 그 하나를 위해 세계관 전체를 들이는 것은 비싼 선택이다.

다섯 도구를 한 화면에 놓고 보면 선택의 축이 드러난다. 세로축은 무게, 가로축은 능력이다. 무거울수록 더 많은 것을 해내지만, 페블러스처럼 설치형·의존성 0·읽기 전용을 제약으로 둔 스택에서는 "그냥 도입"이 가능한 후보가 생각보다 적다. 아래 표에서 특히 눈여겨볼 열은 설치형(self-host)이다. Zep만 여기에 막혀 있다.

스냅샷 2026-07-16. 의존성 수는 PyPI 메타데이터 직접 조회. 벤치마크 수치는 모두 벤더 자체 발표이며 측정 조건이 서로 다르다. LangGraph·LlamaIndex의 "표면 N개"는 메타패키지 직접 의존성으로, 실제 설치 트리는 훨씬 크다.

페블러스 4호의 스택은 설치형 모델, 표준 라이브러리, 의존성 0, 그리고 근거 안에서만 답하는 읽기 전용 grounding 원칙 위에 서 있다. 이 제약은 한계처럼 보이지만, 실은 무엇을 안 쓸지를 먼저 정해 주는 설계 원칙이다. 무거운 종합 프레임워크와 어긋나는 지점은 세 갈래로 나뉜다. 셋을 뭉뚱그리면 판단이 흐려지므로, 나눠서 봐야 한다.

첫째는 의존성과 아키텍처의 강제성이다. LangGraph·LlamaIndex의 무게는 라이선스가 아니라 실제 설치 트리와 강요되는 사고방식에서 온다. 둘째는 설치형 자체의 봉쇄다. Zep은 2025년 4월 이후 자체 호스팅 우회로가 없다. 이건 앞의 문제와 종류가 다르다. 걷어낸다고 해결되는 게 아니라, 애초에 설치가 불가능하다. 셋째는 관리형 서비스의 비용 도약이다.

세 번째를 표로 보면, 관리형으로 갈수록 비용 예측이 어려워지는 패턴이 드러난다. 특히 무료에서 첫 유료 티어로 넘어가는 도약폭이 크다.

2026-07 스냅샷, 공식 가격 페이지 기준. LangGraph·LlamaIndex는 코어 프레임워크가 무료이고 유료는 관측성·관리형 배포뿐이다. 반면 Zep은 self-host 우회로가 없어 관리형 과금을 피할 방법이 사실상 없다.

그래서 4호의 다음 스프린트는 크게 벌이지 않는다. 지금 당장 깨지는 것부터, 딱 그만큼만 손본다. 향할 곳은 이미 분명하다.

1순위 — 프레임워크 없이 이력 전달 + 요약 접기

지금 당장 필요한 것은 장기 기억 시스템이 아니라, 매 요청에 대화 이력을 함께 싣는 얇은 층이다. 구현은 코드가 아니라 세 개의 정책으로 스케치할 수 있다. 첫째, 토큰 예산을 정한다. 컨텍스트에 쓸 상한을 잡고, context rot이 시작되는 3만 토큰보다 훨씬 아래로 둔다. 둘째, 슬라이딩 윈도우로 최근 몇 턴은 원문 그대로 유지한다. 셋째, 예산을 넘긴 오래된 턴은 고정 크기 요약 블록 하나로 접는다. 이 세 가지는 표준 라이브러리만으로 만들 수 있고, 의존성 0 원칙을 지킨다.

이 선택은 실무 관찰과도 어긋나지 않는다. 고정 토큰 예산과 슬라이딩 윈도우를 여러 갱신 정책과 견준 연구에서, 매 스텝 전체를 다시 채우는 방식은 정확도가 가장 높았지만 지연도 가장 컸다. 반면 슬라이딩 윈도우는 지연을 크게 줄이면서 품질 손실이 적어, 품질과 비용의 파레토 최적점에 가장 가까웠다. 4호가 향하려는 "이력 전달과 오래된 턴 요약 접기"가 정확히 그 지점에 놓인다.

단, 요약 접기는 공짜가 아니다. 요약이 누적되면 원 맥락의 뉘앙스가 미묘하게 왜곡되는 컨텍스트 드리프트(context drift)가 생긴다. 무엇을 요약에 남기고 무엇을 버릴지의 설계가 곧 데이터 품질 설계인 이유다. 요약이 사실을 왜곡하지 않는지 주기적으로 점검하는 장치가 함께 가야 한다.

2순위 — 필요해질 때 Graphiti 또는 Mem0를 옆에 붙인다

고객별 장기 기억이나 상담 기록의 그래프화가 실제로 필요해지는 날이 올 수 있다. 그때는 전면 교체가 아니라, 검증된 도구를 옆에 부착하는 방식이 실속 있다. 사용자별 사실을 얇게 쌓는 것이면 Mem0, 시간 흐름이 있는 그래프가 필요하면 Graphiti에 그래프DB를 조립한다. Zep 브랜드는 설치형이 막혀 후보에서 빠진다. 다만 이 단계에는 새로운 리스크가 따라온다.

페블러스가 주목하는 이유

이 보고서는 추상적인 서베이가 아니라, 실재하는 제품의 다음 스프린트를 위한 설계도다. 왜 페블러스가 메모리 프레임워크의 지형을 이렇게 정직하게 대보는지, 네 가지 각도로 짚는다.

비즈니스·기술 연결

페블러스 상담 제품 4호는 설치형 모델·표준 라이브러리·의존성 0 스택 위에 놓인 실제 제품이고, 이 글의 결론(이력 전달과 요약 접기)이 그 제품의 바로 다음 개선을 직접 가리킨다. 이는 DataClinic·AI-Ready Data 라인이 공유하는 "필요한 만큼만, 검증 가능하게"라는 제품 철학의 연장선이다. 카탈로그에서 가장 센 도구를 먼저 집는 대신, 지금 이 제품에 실제로 없는 것부터 채운다.

데이터 품질 관점

장기 기억은 본질적으로 데이터 품질 문제다. 무엇을 사실로 저장하고, 언제 갱신·폐기하느냐의 문제이기 때문이다. 잘못 저장된 기억은 grounding을 오염시키고, 환각을 일회성이 아니라 장기적인 것으로 굳힌다. 요약 접기에서 "무엇을 남기고 버릴지"의 설계가 곧 데이터 품질 설계이고, 그래프화에서 "어떤 사실을 노드로 승격하고 언제 만료시킬지"도 마찬가지다. DataClinic이 학습 데이터에 하는 일을, 메모리 계층에도 해야 한다.

고객·파트너 실무 함의

상담 기록에는 개인정보가 섞인다. 장기 기억·그래프화는 프라이버시, 보존 정책, 삭제권(잊혀질 권리)과 직결된다. 관리형 메모리 서비스에 상담 데이터를 흘려보내는 순간 데이터 주권과 규제 준수 문제가 생긴다. 특히 Zep은 이제 self-host 우회로가 없어, "그래프 메모리를 쓰려면 데이터를 클라우드로 보내야 한다"가 기본값이 된다. 기업 고객이 장기 기억 도입을 검토할 때 이 조건과 리스크를 명확히 제시하는 것 자체가 실무 의사결정에 직접적 가치를 준다.

페블러스의 포지셔닝

이 글의 태도 자체가 포지셔닝이다. 전면 프레임워크 도입이 아니라, 제약을 존중한 최소 개입이다. 근거 안에서만 답하는 읽기 전용 원칙을 지키면서도 대화를 이어지게 만드는, 페블러스다운 균형점을 드러낸다. 벤더 카탈로그를 나열하는 매체와 달리, 페블러스는 "우리 제약에 정직하게 대본 결과"를 공유한다. 이 절제된 엔지니어링 태도가 곧 신뢰의 근거가 된다.

참고문헌

학술 (arXiv)

• 1.Packer, C. et al. (2023). MemGPT: Towards LLMs as Operating Systems. arXiv:2310.08560.
• 2.Chhikara, P. et al. (2025). Mem0: Building Production-Ready AI Agents with Scalable Long-Term Memory. arXiv:2504.19413 (ECAI 2025).
• 3.Rasmussen, P. et al. (2025). Zep: A Temporal Knowledge Graph Architecture for Agent Memory. arXiv:2501.13956.
• 4.Wu, D. et al. (2025). LongMemEval: Benchmarking Chat Assistants on Long-Term Interactive Memory. arXiv:2410.10813 (ICLR 2025).

벤더 공식 발표·블로그

• 5.Mem0 (2026). State of AI Agent Memory 2026.
• 6.Mem0 (2026). Introducing the Token-Efficient Memory Algorithm. (LOCOMO 91.6·LongMemEval 93.4 — 벤더 자체 발표)
• 7.Zep/getzep (2025-04). Announcing a New Direction for Zep's Open Source Strategy. (Community Edition 폐지 공식 발표)
• 8.Zep/getzep (2025). Zep Is the New State of the Art in Agent Memory.
• 9.Anthropic (2026-06-30). Introducing Claude Sonnet 5.

정책·통계·가격·독립 신호

• 10.GitHub REST API — 저장소 메타데이터 직접 조회(stars/forks/license/release), 2026-07-16.
• 11.PyPI(pypistats.org) / npm(registry.npmjs.org) 다운로드 통계, 직접 조회 2026-07-16.
• 12.Letta 공식 가격 문서. letta.com/pricing.
• 13.Mem0 공식 가격 페이지. mem0.ai/pricing.
• 14.Zep 공식 가격 페이지. getzep.com/pricing.
• 15.LangChain 공식 가격 페이지(LangSmith/LangGraph Platform). langchain.com/pricing.
• 16.LlamaIndex 공식 가격 페이지(LlamaCloud). llamaindex.ai/pricing.
• 17.Morph. LLM Context Window Comparison 2026.
• 18.NVIDIA RULER / Adobe NoLiMa / Chroma "context rot" 리서치 — 실효 컨텍스트·성능 저하 독립 연구.

페블러스 관련 글

• 19.에이전트의 지구력은 지능이 아니라 기억이다 — 메모리의 필요성.
• 20.AI 에이전트의 기억은 누구의 것인가 — 메모리 거버넌스·데이터 주권.
• 21.에이전트 컨텍스트 레이어 — 컨텍스트 인프라 개관.