ai-memory: AI 코딩 에이전트를 위한 장기 기억 레이어

AI 코딩 에이전트는 터미널을 닫는 순간 모든 걸 잊어버립니다. 작업 중이던 Claude Code를 종료하고 같은 폴더에서 Codex를 열면, 아키텍처와 이미 실패한 접근법들, 아직 풀리지 않은 질문들을 처음부터 다시 설명해야 합니다. ai-memory는 한 개발자가 내놓은 답입니다 — 어떤 코딩 에이전트를 쓰든 그 밑에 깔려서, 에이전트를 바꿔도 살아남는 무료 오픈소스 메모리 서버입니다.

이 프로젝트는 대부분 한 사람이 만들고, 릴리스를 거의 매일 찍어냅니다 — 이렇게 활발한 프로젝트치고 특이하게도, 이 글에 나오는 모든 수치는 GitHub나 Docker Hub에서 직접 확인할 수 있는 것들입니다. 이 시리즈에서 낯익은 형태이기도 합니다: 역시 대부분 한 명의 개발자가 이끄는 또 다른 AI 코딩 툴 Aider도 같은 1인 체제, 빠른 출시 패턴을 따랐습니다.

ai-memory가 실제로 하는 일

자체 GitHub 설명에 따르면 이 프로젝트의 세일즈 포인트는 직설적입니다: "Quit Claude Code mid-task, start OpenAI Codex in the same directory, continue without re-explaining the architecture…"(작업 중이던 Claude Code를 종료하고, 같은 디렉터리에서 OpenAI Codex를 시작해도, 아키텍처를 다시 설명할 필요 없이 이어갈 수 있다) README에 나온 작동 방식은, 로컬(또는 홈랩 서버)에서 돌리는 작은 Rust 서버가 여러분이 쓰고 있는 어떤 에이전트에든 훅으로 연결되는 형태입니다.

공식 지원 대상은 현재 Claude Code, Codex, Cursor, Gemini CLI, OpenCode를 포함해 20개가 넘는 툴에 걸쳐 있으며, VS Code Copilot이나 Zed 같은 몇몇 툴은 MCP 전용으로만 지원합니다.

설계상 눈에 띄는 선택이 두 가지 있습니다. 첫째, 메모리 자체가 데이터베이스에 갇혀 있지 않습니다 — git으로 관리되는 순수 마크다운 파일 폴더이며, grep으로 뒤지거나 손으로 직접 수정하거나 Obsidian에서 열어볼 수 있도록 설계되어 있습니다. 그 밑에 깔린 SQLite 인덱스는 명시적으로 재구축 가능한 파생물일 뿐, 원본 소스가 아닙니다. 둘째, 캡처와 검색은 기본적으로 API 호출 없이 동작합니다(마크다운 전체 텍스트 검색). 벡터 검색과 LLM이 생성하는 요약은 필수가 아니라 선택적으로 켤 수 있는 추가 기능입니다.

AI 에이전트 툴링이라는 화려한 분야에 있는 프로젝트치고는 의도적으로 수수한 아키텍처입니다. README는 왜 네트워크 구조가 팀에게 중요한지도 설명합니다: 여러 사람이 서버 하나를 함께 가리키면, 뭉뚱그려진 공유 덩어리가 아니라 프로젝트별 공유에 사람별 귀속(attribution)과 감사 로그(audit log)까지 딸려 온다는 것입니다.

이름은 하나, 기여자는 여럿, 저장소는 매우 활발

LICENSE 파일은 MIT이며, "Copyright (c) 2026 Fabio Akita"라는 문구가 적혀 있습니다. Fabio Akita는 브라질에 거주하는 개발자로, GitHub 소개란에는 "Agile Senior Vibe Coder"(애자일 시니어 바이브 코더)라고 적혀 있습니다. 소속으로 Codeminer 42를 밝히고 있고, GitHub 팔로워는 20.6k명입니다 — 익명 계정은 아니지만, 그렇다고 투자를 받은 스타트업 팀도 아닙니다.

다만 완전히 혼자 하는 건 아닙니다. 커밋 히스토리를 보면 akitaonrails 본인 외에도 abhisheksharma2411, rafaelkenedy, fuxicodex 같은 외부 기여자들이 Windows CI 타임아웃과 불안정한 테스트를 고친 기록이 있고, 여러 커밋에는 claude 공동 저자(co-author) 태그도 붙어 있습니다 — README도 이를 직접 뒷받침하는데, 이 코드베이스가 문서화된 계획에 따라 "built collaboratively with Claude Code (Anthropic Claude Opus 4.7)"(Claude Code(Anthropic Claude Opus 4.7)와 협업하여 만들어짐)라고 명시하고 있습니다.

저장소 페이지에서 직접 확인한 이 프로젝트 자체 수치는 조작하기 어려운 종류입니다: 메인 브랜치 기준 스타 7.7k개, 포크 520개, 커밋 1,961개이며, 열린 이슈 13개, 열린 풀 리퀘스트 12개입니다 — 스타만 쌓아놓고 잠들어 있는 저장소가 아니라, 작지만 살아 있는 백로그입니다.

이 분야에서 그의 프로젝트가 이것 하나뿐인 것도 아닙니다. 고정된(pinned) 저장소 목록에는 ai-jail도 있는데, 이는 AI 에이전트를 위한 동반 OS 샌드박스로, 자체 README에 따르면 "runs AI coding agents in an OS sandbox: bubblewrap plus Landlock, seccomp, and limits on Linux"(AI 코딩 에이전트를 OS 샌드박스 안에서 실행합니다: 리눅스에서 bubblewrap에 Landlock, seccomp, 각종 제한을 더한 방식)라고 설명합니다(스타 1.3k개, GPL-3.0, 열린 이슈 0개). 그 외에도 ai-usagebar, llm-coding-benchmark 같은 다른 에이전트 툴링 유틸리티들도 있습니다 — 이게 일회성 사이드 프로젝트가 아니라, 작고 초점이 분명한 에이전트 툴링 유틸리티를 계속 내놓는 패턴이라는 증거입니다. ECC를 해커톤 프로젝트에서 GitHub 트렌딩 페이지까지 끌어올린 것과 같은, 1인 체제로 빠르게 출시하는 패턴입니다.

진짜 이야기는 릴리스 주기다

특이한 건 스타 수가 아닙니다 — 그 정도는 AI 툴링 저장소라면 흔히 도달합니다. 특이한 건 출시 속도입니다. 릴리스 페이지를 보면 2026년 9월 6일부터 9월 21일 사이에 태그된 릴리스가 열 개나 있습니다 — v2.1.0부터 v2.4.0까지이며, 같은 날 나온 패치 릴리스도 하나 포함되어 있습니다(v2.2.0과 v2.2.1이 둘 다 9월 12일에 나왔습니다) — 대부분 한 사람이 관리하는 프로젝트치고는 상당한 속도입니다. Docker Hub 이미지도 독립적으로 이를 뒷받침합니다: 풀(pull) 수 10K+, 그리고 이 글을 확인하던 시점 기준으로 "Updated 26 minutes ago"(26분 전 업데이트됨)라고 표시되어 있었습니다. 이건 메인테이너가 직접 써넣은 뱃지가 아니라 플랫폼이 표시하는 수치입니다.

커밋 로그를 보면 이 속도가 추상적인 이야기가 아니라 구체적으로 드러납니다. 이 글을 확인한 날 기준 가장 최근 커밋 메시지 열 개에는 "the PowerShell-hook connect deadline for slow Windows CI"(느린 Windows CI를 위해 PowerShell 훅 연결 대기 시간을 늘림)를 고친 수정, "for the renumbered claim migration"(재번호가 매겨진 claim 마이그레이션을 위한) 스키마 버전 상향, 내부 sessions/ 폴더를 "from the reviewer's recent-page context"(리뷰어의 최근 페이지 컨텍스트에서) 제외하는 수정 같은 것들이 포함되어 있습니다 — 초기 출시 주목도에 안주하는 프로젝트가 아니라, 실제 엣지 케이스를 가진 실제 툴이 하는 수수한 유지보수 작업입니다.

엔지니어링 판단 근거가 공개되어 있고, 구체적이다

design-decisions.md 문서는 흔치 않은 문서입니다: 메인테이너가 무엇을 만들었는지뿐 아니라, 뻔한 대안들을 왜 거부했는지까지 적어뒀습니다. 데이터베이스 대신 git 안의 마크다운을 소스 오브 트루스로 선택한 이유: "Backup/move story is trivial - git clone or rsync a directory. The user explicitly asked for this."(백업·이전은 간단합니다 — 디렉터리를 git clone하거나 rsync하면 됩니다. 사용자가 명시적으로 이걸 요청했습니다.) Postgres를 기본값으로 삼지 않은 이유: "Postgres is a real-deployment-only pain."(Postgres는 실제 배포 단계에서만 골치 아픈 존재입니다.) 에이전트에게 수십 개의 툴 호출을 노출하는 대신 MCP 툴 표면을 좁게 유지한 이유: "basic-memory has ~25 tools, agentmemory has 53. Both have user confusion as a result"(basic-memory는 툴이 약 25개, agentmemory는 53개입니다. 둘 다 그 결과로 사용자 혼란을 겪고 있습니다) — 모호한 주장이 아니라, 같은 분야의 경쟁 오픈소스 프로젝트를 이름까지 밝히며 직접 비교한 내용입니다.

이 프로젝트는 검색이 잘 된다고 그냥 주장만 하지 않고, 자체 검색 품질 수치도 공개합니다. 벤치마크 문서는 저장소 안에 들어 있는 재현 가능한 하네스로 LongMemEval-S 데이터셋을 돌린 결과, 현재 기본값인 로컬 임베딩 방식에서 hit@5 점수 0.823을 기록했다고 밝힙니다 — 2.0 이전 전체 텍스트 검색의 0.617에서 +20.6포인트 개선된 수치이며, 문서는 이를 두 가지 구체적인 변경 덕분이라고 설명합니다: FTS 쿼리에서 불용어(stopword)를 제거한 것, 그리고 마스크드 민 풀링(masked-mean pooling)을 수정한 인프로세스 임베더로 전환한 것입니다. 이건 본인 발표 기준 벤치마크입니다 — 독립된 제3자가 다시 돌려본 것은 아닙니다 — 하지만 방법론과 하네스가 모두 저장소에 공개되어 있어 누구든 직접 재실행해볼 수 있다는 점에서, 숫자 하나 없는 마케팅 주장보다는 의미 있게 높은 기준을 충족합니다.

하이라이트 릴에 들어맞지 않는 부분

이 프로젝트를 깔끔한 성공담으로만 보기 어렵게 만드는 요소도 몇 가지 있습니다.

네이티브 Windows 지원은 README에 여전히 명시적으로 "experimental"(실험적)이라고 표시되어 있고, 최근 커밋 여러 개가 Windows 전용 CI 타임아웃을 고치는 내용입니다 — 완성된 플랫폼이 아니라, 여전히 공개적으로 안정화되고 있는 중인 플랫폼입니다.

호스팅 제품도 없고 가격도 없습니다: 이건 자체 호스팅하는 MIT 라이선스 소프트웨어이며, 눈에 보이는 수익화 계획이 없습니다 — 이 시리즈의 유료 티어 사례들과는 실질적으로 다른 지점입니다. 여기서 보고할 매출 수치가 없는 건, 찾을 수 있는 매출 수치가 아예 없기 때문입니다.

거의 이틀에 한 번꼴로 새 태그 릴리스를 찍어내고, 자동 개선(auto-improve) 중복 제거 수정이나 사람 세션용 내장 로그인 페이지 같은 요청이 담긴 열린 이슈 13개를 안고 있는 프로젝트는, 안정된 1.0 형태로 자리 잡은 프로젝트라기보다는 여전히 자신의 경계를 적극적으로 찾아가는 중인 프로젝트입니다.

이것이 일반화되는 지점

여기서 다른 곳에도 적용할 수 있는 습관은 "메모리 레이어를 만들라"가 아닙니다 — 코드와 함께 판단 근거를 공개하라는 것입니다. 대부분의 오픈소스 AI 툴링은 기능 목록으로 가득한 README를 내놓고 거기서 멈춥니다. ai-memory는 자신이 검토한 경쟁 프로젝트 두 개를 이름까지 밝히고, 더 좁은 인터페이스를 선택하게 만든 정확한 툴 개수 수치까지 인용한 design-decisions.md를 공개했고, "빠르고 정확하다"는 근거 없는 주장 대신 직접 돌려볼 수 있는 하네스가 담긴 benchmarks/ 폴더까지 내놓았습니다. Claude Code든 다른 에이전트든 빠르게 출시하는 1인 빌더에게, 이건 추가하기엔 저렴하지만 스타 수가 오르기 시작하면 지키기 어려워지는 습관입니다: 무엇을 만들었는지만이 아니라, 어떤 특정 대안을 거절했고 그 대안의 구체적인 수치가 무엇이었는지까지 써두는 것 — 그래야 여러분의 프로젝트를 평가하는 다음 사람이 여러분의 말을 그냥 믿지 않아도 됩니다.