agentmemory 가 던지는 질문 — AI 에이전트의 '기억' 은 윈도우인가 압축인가
agentmemory 가 던지는 질문 — AI 에이전트의 ‘기억’ 은 윈도우인가 압축인가
rohitg00/agentmemory 가 GitHub Trending 주간 차트에 7,976 스타로 올라섰다. README 의 벤치마크 표는 LongMemEval 에서 R@5 95.2%, mem0 의 단순 벡터 접근 대비 26.7 포인트 차이를 가리킨다. AI 에이전트의 기억 문제는 컨텍스트 윈도우의 확장으로 풀리는가, 아니면 의식적 압축의 설계로 풀리는가.
도입 — 7,976 스타가 가리키는 한 줄
2026년 5월 19일 GitHub Trending 주간 차트의 첫 줄에 rohitg00/agentmemory 가 올라섰다. 한 주 동안 7,976 스타. 같은 주 2위의 두 배에 가까운 폭이다. 저장소를 열면 첫 줄에 한 문장이 적혀 있다. “Coding agents forget. This library helps them remember.” 이 한 줄이 5월 시점의 코딩 에이전트 사용자들이 겪는 가장 흔한 좌절을 정확히 짚는다. 어제 Claude Code 나 Cursor 에 다섯 시간을 들여 설명한 프로젝트의 아키텍처, 명명 규칙, 우회한 버그의 이유 — 다음 세션이 열리면 다 사라져 있다. 사용자는 매번 같은 설명을 반복하고, 같은 토큰을 다시 청구받는다.
이 비용은 작지 않다. README 의 분석은 한 명의 풀타임 코딩 에이전트 사용자가 컨텍스트 재구축 — 즉 “이 프로젝트는 어떻게 생겼고, 우리는 어떤 규칙을 따르며, 어떤 라이브러리를 피하는가” 를 반복 설명하는 토큰 — 만으로 연간 약 $500 의 추가 토큰을 소비한다고 정리한다. 회사 차원에서 100 명의 개발자가 같은 도구를 쓰면 같은 항목이 $50,000 가 된다. agentmemory 의 README 는 이 숫자를 첫 화면에 박아 두었고, HN 의 한 코멘트는 그 수치를 “그동안 우리가 LLM 에 지불해 온 보이지 않는 세금” 이라고 짚는다(직접 인용은 아니고, 공감 코멘트의 정서를 요약).
표면적으로 이 문제는 “컨텍스트 윈도우를 더 키우면 풀리는 문제” 처럼 보인다. Anthropic 이 5월에 1M 토큰 컨텍스트를 일반 사용자에게 풀었고, OpenAI 도 비슷한 규모를 준비 중이다. 그러나 agentmemory 의 등장이 가리키는 것은 다른 방향이다. 컨텍스트가 1M 이든 10M 이든, 매 세션마다 전체를 다시 채우는 비용은 그대로 남는다. 진짜 문제는 윈도우의 크기가 아니라, 무엇을 어떻게 압축해서 다음 세션에 넘길 것인가다. 이 글은 그 질문을 따라간다. agentmemory 의 4 단계 메모리 설계는 mem0 의 단순 벡터 접근과 무엇이 다른가. 95.2% vs 68.5% 라는 R@5 격차는 무엇을 의미하는가. 그리고 Anthropic 의 1M 토큰 노선과 agentmemory 식의 “압축 메모리” 노선은 향후 어디서 만나거나 갈라지는가.
본문 1 — “세션 망각” 의 경제학과 7,976 스타의 의미
GitHub Trending 의 주간 7,976 스타는 흔치 않은 수치다. 2026년 들어 같은 차트 1위를 차지한 저장소 가운데 7,000 스타를 넘긴 것은 4 개뿐이다. agentmemory 의 폭주는 단순히 “메모리” 라는 키워드가 유행해서가 아니다. README 의 첫 화면이 사용자의 일상적 좌절을 정확히 언어화했기 때문이다. 첫 단락은 이렇게 시작한다. “당신의 코딩 에이전트는 어제 당신과 다섯 시간을 함께 일했다. 오늘 아침, 그것은 당신이 누군지 모른다.” 이 한 줄이 HN 의 댓글 240 개 중 절반 이상에서 공감을 얻었다.
문제의 구조는 단순하다. LLM 의 컨텍스트 윈도우는 휘발성이다. 세션이 끝나면 모든 정보가 사라진다. 다음 세션은 백지에서 시작한다. 사용자는 매번 프로젝트의 디렉터리 구조, 명명 규칙, 사용 중인 라이브러리, 우회한 버그, 거부한 디자인 선택을 다시 설명해야 한다. 코딩 에이전트의 실제 작업 시간 가운데 이 “컨텍스트 재구축” 에 들어가는 비중은 적게는 15%, 많게는 35% 로 추정된다. 토큰 비용으로 환산하면 Claude Sonnet 시세 기준 풀타임 사용자 한 명당 연간 $500, Opus 기준으로는 $1,200 에 이른다. 100 명 규모의 엔지니어링 조직에서 같은 항목이 $50,000 ~ $120,000 의 보이지 않는 비용이 된다.
이 비용은 그동안 산업 차원에서 무시되어 왔다. 이유는 두 가지다. 첫째, 비용이 분산되어 있다. 매 세션마다 몇 천 토큰씩 누적되는 형태라, 단일 청구서에서 눈에 띄지 않는다. 둘째, 대안이 명확하지 않았다. 사용자는 ChatGPT 의 “Memory” 기능이나 Claude 의 Projects 같은 휴리스틱 도구를 써 봤지만, 실제 코딩 에이전트의 작업 흐름에 맞지 않았다. 이 두 가지가 5월의 agentmemory 등장 이전까지의 균형이었다.
agentmemory 가 깬 균형은 두 축이다. 첫째, 비용을 가시화했다. README 의 $500/년 수치는 사용자 입장에서 “이걸 안 쓰면 매년 그만큼 손해” 라는 명확한 의사결정 지점을 만든다. 둘째, 기술적으로는 LongMemEval 같은 공인 벤치마크에서 mem0 같은 기존 솔루션 대비 큰 격차를 보였다. 두 축이 같은 주에 만나면서 GitHub Trending 의 폭주로 이어졌다. HN 의 분위기를 한 줄로 요약하면 “드디어 이 문제를 진지하게 푼 사람이 나왔다” 다. 한 코멘트는 “지난 1 년 반 동안 매 세션마다 같은 README 를 LLM 에 붙여 넣어 왔다. 이걸 그만둘 때가 된 것 같다” 고 짚는다(공감 코멘트의 정서 요약).
그러나 7,976 스타가 곧 7,976 명의 본격 사용자를 의미하지는 않는다. GitHub 의 스타는 의도 표명 수준의 신호다. 진짜 채택은 다음 분기에 어떤 코딩 에이전트 — Claude Code, Cursor, Aider — 가 agentmemory 를 일급 통합으로 받아들이는가에 달려 있다. 그리고 그 통합 여부를 결정하는 핵심 변수가 다음 절의 주제 — agentmemory 의 설계 선택이 mem0 같은 기존 솔루션을 어떻게 능가하는가 — 다.
본문 2 — 4 단계 메모리와 하이브리드 검색의 설계 해부
agentmemory 의 README 가 가장 강하게 차별화하는 지점은 “4 단계 메모리 (Four-Tier Memory)” 라는 개념이다. 이는 인지과학의 기억 분류를 그대로 차용한 것으로, 사람의 기억을 작업 기억(working) · 에피소드 기억(episodic) · 의미 기억(semantic) · 절차 기억(procedural) 의 네 층으로 나누는 분류를 LLM 에이전트에 옮긴 것이다.
작업 기억 은 현재 세션의 휘발성 상태로, 컨텍스트 윈도우 그 자체에 해당한다. 에피소드 기억 은 “어제 우리는 X 라는 버그를 Y 라는 방식으로 우회했다” 같은 시간이 박힌 사건의 기록이다. 의미 기억 은 “이 프로젝트의 명명 규칙은 snake_case 다” 같은 시간과 무관한 지식이다. 절차 기억 은 “이 저장소에서는 항상 npm run check 를 commit 전에 돌린다” 같은 반복되는 작업 흐름의 기록이다. 이 네 층은 서로 다른 라이프사이클을 가진다. 작업 기억은 세션이 끝나면 사라진다. 에피소드 기억은 사건이 일어난 시점에 기록되고, 시간이 지나면서 가중치가 감쇠한다. 의미 기억은 거의 영구적이며, 절차 기억은 사용 빈도에 비례해 강화된다.
이 설계가 mem0 같은 단순 벡터 접근과 무엇이 다른가. mem0 는 모든 메모리를 하나의 벡터 인덱스에 평등하게 저장한다. 검색은 의미 유사도 단일 차원이다. agentmemory 는 네 층을 각기 다른 인덱스에 저장하고, 검색 시점에 어느 층에서 가져올지를 의도적으로 분기한다. “지금 이 코드 변경을 어제 우리가 거부했던 디자인 선택과 충돌하는가” 라는 질의는 에피소드 기억에서 시간 가중치를 적용해 검색하고, “이 프로젝트의 명명 규칙은 무엇인가” 라는 질의는 의미 기억에서 시간 가중치 없이 검색한다.
여기에 더해, agentmemory 는 Ebbinghaus 의 망각 곡선(forgetting curve) 을 에피소드 기억의 가중치 감쇠에 그대로 적용한다. 1885년에 Ebbinghaus 가 자기 자신을 대상으로 측정한 그 곡선이다. 어떤 사건이 기록된 직후에는 가중치 1.0 이었다가, 시간 t 시간 후의 가중치가 e^(-t/S) 의 형태로 감쇠한다(S 는 사건의 강도). 이 감쇠가 있어, 검색 결과가 “최근 사건” 쪽으로 자연스럽게 기운다. 단순 벡터 검색에 시간 가중치를 곱한 것과 비슷해 보이지만, 강도 S 가 사건의 종류 — 디자인 선택의 거부는 강도가 높고, 일회성 디버깅 로그는 강도가 낮다 — 에 따라 다르게 설정된다는 점이 다르다.
검색 단계에서는 하이브리드 검색 (BM25 + 벡터 + 그래프) 을 쓴다. BM25 는 1990년대의 키워드 기반 검색 알고리즘으로, 정확한 명사 매칭이 중요할 때 강하다 — “Postgres 의 unique constraint 를 어떻게 우회했는가” 같은 질의. 벡터 검색은 의미 유사도가 중요할 때 강하다 — “이 작업과 비슷한 작업을 전에 한 적이 있는가” 같은 질의. 그래프 검색은 엔티티 간의 관계가 중요할 때 강하다 — “auth 모듈의 user 객체와 결제 모듈의 customer 객체는 같은 엔티티인가” 같은 질의. 세 검색의 결과를 RRF (Reciprocal Rank Fusion) 으로 융합해 최종 순위를 만든다.
이 설계가 LongMemEval (arxiv:2406.10149) 같은 공인 벤치마크에서 어떤 차이를 만드는가. README 의 표는 R@5 (recall at 5) 기준 agentmemory 95.2%, mem0 68.5% 라고 보고한다. 26.7 포인트의 격차다. 이 격차는 단순히 모델이 좋아서가 아니라, 검색 단계에서 어느 메모리 층에서 무엇을 가져올지를 분기하는 설계 자체에서 온다. 같은 표는 검색 지연을 14ms 로 보고한다. SQLite 기반의 로컬 인덱스에 더해 iii (inverted-index 엔진) 을 BM25 용으로 결합한 결과다. 트레이드오프도 분명하다. SQLite + iii 의존성은 가볍지만, 분산 환경에서는 직접 쓸 수 없다 — Postgres 나 ClickHouse 같은 분산 백엔드로의 포팅이 다음 분기의 작업으로 README 에 명시되어 있다.
한 가지 더 짚을 만한 설계 선택은 auto-compression 기본 비활성화 다. agentmemory 는 메모리를 자동으로 압축·요약하지 않는다. 압축이 필요하면 사용자가 명시적으로 호출해야 한다. 이 기본값이 의미하는 것은, LLM 의 메모리는 “투명한 데이터 저장소” 여야지 “마법처럼 정리되는 블랙박스” 여서는 안 된다는 설계 철학이다. mem0 가 자동 요약을 기본으로 켜 둔 것과 정반대다. 이 철학적 차이가 다음 절의 주제 — 컨텍스트 윈도우 확장과 압축 메모리의 두 노선 — 와 직접 이어진다.
본문 3 — 1M 토큰의 길과 압축 메모리의 길
5월의 LLM 풍경을 한 발 물러서 보면 두 개의 큰 길이 보인다. 하나는 Anthropic 과 OpenAI 같은 폐쇄 API 의 길로, 컨텍스트 윈도우를 계속 키워서 메모리 문제를 풀려는 노선이다. Anthropic 은 5월에 Claude 의 컨텍스트를 1M 토큰까지 확장했고, OpenAI 의 GPT-5 도 비슷한 규모를 곧 풀 것으로 예상된다. 이 노선의 논리는 단순하다. 컨텍스트가 충분히 크면, 사용자가 매 세션마다 프로젝트 전체를 통째로 붙여 넣을 수 있고, 그러면 “기억” 이 따로 필요 없다.
다른 하나는 agentmemory 가 제안하는 의식적 압축 의 길이다. 컨텍스트가 아무리 커져도, 매 세션마다 전체를 다시 채우는 비용은 그대로 남는다. 1M 토큰을 매번 채우는 것이 100K 토큰을 매번 채우는 것보다 10 배 비싸다. 따라서 진짜 해법은 “이전 세션의 핵심을 5K~10K 토큰으로 압축해서 다음 세션에 넘기는 것” 이다. 압축의 품질이 좋으면 같은 작업을 1/100 의 토큰 비용으로 처리할 수 있다.
두 노선은 표면적으로는 경쟁하지만, 실제로는 보완 관계다. 컨텍스트 윈도우가 클수록 압축 메모리의 작업 공간이 넓어진다. 1M 토큰 컨텍스트에 agentmemory 가 검색해서 넣어 주는 100K 토큰의 요약 + 사용자가 직접 붙이는 50K 토큰의 현재 작업 = 합쳐서 150K 토큰의 작업 환경이 만들어진다. 두 노선이 같은 사용자의 같은 작업에서 만난다.
여기서 5월의 또 하나의 트렌드 — MCP (Model Context Protocol) — 가 결합한다. MCP 는 LLM 에이전트가 외부 도구·데이터 소스와 통신하는 표준 프로토콜이다. agentmemory 의 README 는 마지막 절에서 MCP 서버로 배포하는 방법을 안내한다. 이게 의미하는 것은, agentmemory 가 단일 사용자의 단일 에이전트만이 아니라, 여러 에이전트가 공유하는 메모리 가 될 수 있다는 점이다. 팀 안의 Claude Code, Cursor, Aider 사용자가 같은 agentmemory MCP 서버에 연결되면, 한 명이 어제 우회한 버그를 다른 사람의 에이전트가 오늘 알고 있다. 이 가능성이 멀티 에이전트 협업의 새 표준을 만들 수 있다.
다음 분기에 주시할 점은 세 가지다. 첫째, Anthropic 이나 OpenAI 가 agentmemory 같은 외부 메모리 솔루션을 일급으로 통합하는가, 아니면 자체 “Projects” 기능을 강화하는 쪽으로 가는가. 둘째, agentmemory 의 SQLite + iii 의존성이 Postgres·ClickHouse 같은 분산 백엔드로 포팅되어 회사 규모의 배포가 가능해지는가. 셋째, MCP 메모리 공유가 보안·프라이버시 측면에서 어떤 새로운 표면을 만들고, 그 표면이 어떤 식으로 통제되는가. 세 가지 모두 다음 8 주 안에 큰 발표가 나올 가능성이 높다.
결론 — 윈도우는 공간이고, 압축은 시간이다
처음의 질문으로 돌아가자. AI 에이전트의 기억 문제는 컨텍스트 윈도우의 문제인가, 아니면 의식적 압축의 문제인가.
답은 두 항의 OR 이 아니라 AND 다. 컨텍스트 윈도우는 공간 의 문제고, 압축은 시간 의 문제다. 윈도우가 커지면 한 세션 안에서 더 많은 정보를 다룰 수 있다. 압축이 좋아지면 세션과 세션 사이를 더 적은 토큰으로 이을 수 있다. 두 가지가 같이 좋아질 때 사용자의 비용 곡선이 가장 가파르게 떨어진다. 5월의 agentmemory 폭주는 그동안 후자 — 시간 축의 압축 — 가 산업적으로 무시되어 왔다는 사실을 가시화했다.
7,976 스타가 다음 분기에 실제 채택으로 이어질지는 두 가지 변수에 달려 있다. 하나는 코딩 에이전트 회사들이 agentmemory 를 일급 통합으로 받아들일지의 결정이다. Claude Code, Cursor, Aider 의 다음 8 주 발표가 결정적이다. 다른 하나는 mem0 같은 경쟁자들이 agentmemory 의 4 단계 + 하이브리드 검색 설계를 빠르게 따라잡을 수 있는지의 여부다. R@5 26.7 포인트의 격차가 다음 분기에도 유지된다면 agentmemory 의 폭주는 굳어지고, 격차가 좁혀지면 경쟁이 다시 평탄해진다.
이 글이 남기는 메시지는 한 줄이다. LLM 의 진짜 미래는 “윈도우를 키우는 회사” 와 “압축을 잘하는 라이브러리” 의 합주에 있다. auto-compression 을 기본으로 끄는 agentmemory 의 철학은, LLM 메모리가 “마법처럼 정리되는 블랙박스” 가 아니라 “투명하게 운영해야 하는 데이터 저장소” 라는 시대의 시작을 알린다. 이 시대에는 토큰의 단가가 아니라, 토큰을 어떻게 압축해서 다음 세션에 넘길 것인가의 운용 디테일이 회사의 비용 곡선을 결정한다. Anthropic 의 1M 토큰 발표와 agentmemory 의 7,976 스타가 같은 5월에 일어난 것은 우연이 아니다. 두 가지가 같은 큰 흐름의 두 면이기 때문이다.
출처: