코딩 AI의 기억 상실을 해결하는 agentmemory와 claude-mem의 설계 차이

Claude Code를 다시 열 때마다, 에이전트는 지난주에 자신이 무엇을 했는지 기억하지 못한다. CLAUDE.md를 읽어 들여 "이 프로젝트는 이런 구성입니다"라고 재학습하지만, 그럼에도 "왜 이 라이브러리를 선택했는지"는 모른 채 더듬거리며 시작한다. 코딩 에이전트의 "기억"은 결국 인간이 직접 손으로 써 내려간 마크다운(Markdown) 한 장뿐이다. 이러한 건망증을 툴 측면에서 메우려는 OSS(Open Source Software)가 지금 조용히 늘어나고 있으며, 설계 사상이 명확하게 갈리고 있다. 대표 격인 agentmemory와 claude-mem을 1차 소스 리포지토리와 대조하며 읽어본다.

LLM(Large Language Model) 본체는 스테이트리스(Stateless)다. 대화를 종료하면 문맥은 사라지고, 다음 세션은 백지 상태에서 시작된다. 긴 CLAUDE.md에 전부 적으면 된다는 발상도 있지만, 이는 매번 통째로 프롬프트(Prompt)에 실리게 된다. agentmemory의 측정에 따르면, 전체 문맥을 계속 붙여넣으면 연간 2,000만 토큰(Token) 가까이 소모되는 반면, 필요한 기억만 인출하는 방식이라면 17만 토큰 정도로 해결된다고 한다(README). 컨텍스트 윈도우(Context Window)는 "전부 넣는" 장소가 아니라 "지금 관계있는 것만 넣는" 장소라는 전제에 서면, 검색 가능한 외부 기억이 필요하다.

두 도구가 채택하는 기본 형태는 거의 동일하다. 에이전트가 툴을 실행할 때마다(PostToolUse) 무엇을 했는지 관측(Observation)으로서 포착하고, LLM으로 요약·압축하여 벡터(Vector)와 키워드 색인(Index)에 저장한다. 그리고 다음 세션 시작 시(SessionStart)에 지금 착수하고 있는 작업과 관련된 파편만을 인출하여 주입한다. 이 "포착한다·압축한다·불러온다"의 입출구에, 에이전트의 라이프사이클(Lifecycle)에 자체 스크립트를 삽입하는 hook과, 에이전트에 외부 툴을 붙이는 표준 프로토콜인 MCP(Model Context Protocol)를 사용한다.

agentmemory는 서버 상주형이며, 입력이 빠르다.

npm install -g @agentmemory/agentmemory
agentmemory # 메모리 서버를 기동 (REST API는 :3111)
agentmemory connect claude-code # 에이전트 측에 hook과 MCP를 배선

관측이 들어온 후 기억이 되기까지의 파이프라인이 명시되어 있는 것이 특징으로, PostToolUse 훅 → SHA-256으로 중복 제거 → 프라이버시 필터 → 생(Raw) 로그 저장 → LLM으로 압축 → 구조화된 사실 → 벡터 임베딩(Embedding) → BM25+벡터 색인,이라는 순서로 흐른다. 기억은 Working / Episodic / Semantic / Procedural의 4개 층으로 정리되며, 불러오기는 BM25·벡터·지식 그래프(Knowledge Graph)의 3개 계통을 RRF(여러 검색 순위를 하나로 융합하는 기법)로 통합한다.

이 부분이 나의 평가 포인트다. 많은 "AI 메모리" 계열 툴들은 구조도만 그럴싸하고 정밀도를 말하지 않지만, agentmemory는 장기 기억 벤치마크인 LongMemEval-S(500문항)에서 recall@5가 95.2%라고 수치를 제시하고 있다. recall@5는 "상위 5개 항목 안에 정답이 포함되어 있었던 비율"로, 요컨대 주입 후보 상위권을 보면 필요한 기억을 거의 다 가져올 수 있다는 주장이다. 임베딩은 @xenova/transformers를 통해 로컬에서 실행(무료)하며, 압축용 LLM은 Anthropic, OpenAI, Gemini, Ollama 등에서 선택할 수 있다. 라이선스는 Apache-2.0이며, 집필 시점 기준 v0.9.27(2026년 6월 7일)이다.

같은 문제에 대해, claude-mem은 다른 방식의 승부수를 던진다. 설치는 한 줄이지만, 여기에 함정이 있다.

npx claude-mem install # hook 등록부터 워커(Worker) 기동까지 한 번에 수행
# 주의: npm install -g claude-mem은 라이브러리만 설치되며, hook은 등록되지 않음

Gemini CLI나 OpenCode에 넣으려면 --ide gemini-cli와 같이 대상을 지정해야 한다. 내부적으로는 SessionStart / UserPromptSubmit / PostToolUse / Stop / SessionEnd의 5가지 라이프사이클 훅과, 포트 37777에서 동작하는 워커(HTTP API 및 web UI 포함)로 구성된다. 저장 방식은 SQLite를 주 데이터베이스로 사용하고, 의미 검색(Semantic Search)을 위해 Chroma 벡터 DB를 병용하는 하이브리드 구성이다.

흥미로운 점은 검색을 "3층 워크플로우 (3-layer workflow)"로 설계하여 MCP 도구(Tool)를 역할별로 나누었다는 점이다. search는 ID와 수십 토큰의 인덱스(Index)만을 반환하고, timeline으로 전후 맥락을 파악하며, get_observations로 ID를 지정하여 본문을 가져온다. 갑자기 전체 텍스트를 주입하는 대신, 범위를 좁힌 뒤 가져오는 방식을 통해 약 10배의 토큰 절약을 주장한다. 에이전트에게 "먼저 인덱스만 보고, 필요한 부분만 전개하라"는 검색 방식(Search etiquette) 자체를 부여하는 발상으로, Claude Code의 플러그인으로서 자연스럽게 녹아든다. 라이선스는 마찬가지로 Apache-2.0이며, v13 계열이다.

	agentmemory	claude-mem
방식	상주 서버 + 배선 명령 (Wiring command)	에이전트 플러그인
...

동일한 "포착하기·압축하기·불러오기" 과정이라도, agentmemory는 검색 엔진을 정교하게 구축하여 수치로 정당화하는 방향인 반면, claude-mem은 기존 에이전트에 대한 융합성과 검색 방식의 가벼움으로 승부하는 방향이다. 두 방식 모두 관측(Observation) 내용을 LLM으로 요약한 뒤 저장한다는 점은 공통적이며, 바로 이 지점에 실무상의 가장 큰 주의사항이 있다. 압축은 비가역적(Irreversible)이다. 요약 과정에서 "왜 그렇게 했는지"에 대한 세부 사항이 누락되면, 나중에 불러온 기억이 조용히 사실과 어긋나게 된다. 압축용 모델에 도구 실행 로그(Tool execution log)를 흘려보내게 되므로, 기밀 정보 필터링이 작동하는지(agentmemory는 파이프라인에 명시, claude-mem은 모델 선택으로 제어)는 도입 전에 반드시 확인해야 한다.

나라면 우선 설정을 빈번하게 오가는 횡단적인 대규모 리포지토리(Repository)에서, 로컬 임베딩(Local embedding) 구성인 것부터 시도해 볼 것이다. 상주 서비스가 하나 늘어나는 비용과 매 세션마다 다시 설명해야 하는 수고가 사라지는 가치를 자신의 워크플로우에서 저울질해 보면 된다. CLAUDE.md를 수동으로 계속 유지보수하는 것에 지쳐 있다면, 기억을 별도의 레이어(Layer)로 분리하는 이 흐름은 적어도 실험해 볼 가치가 있다.