에이전트의 기억을 마크다운으로 돌려주는 agent-memory

대화가 길어질수록 에이전트는 무엇을 기억해야 할까요

AI 에이전트를 오래 사용하다 보면 의외로 단순한 문제가 반복됩니다. 지난번에 결정한 규칙을 잊고, 이미 설명한 취향을 다시 묻습니다. 도구가 바뀔 때마다 같은 배경을 처음부터 전달해야 하는 일도 생깁니다.

tigerless-labs/agent-memory는 이 문제를 에이전트의 장기기억을 어떻게 저장하고 다시 찾으며 정리할 것인가라는 관점에서 다루는 Python 기반 오픈소스 프로젝트입니다. 제공된 자료 기준으로 별은 822개입니다. 프로젝트가 내세우는 특징은 네 가지입니다. 평범한 마크다운을 기억의 원본으로 사용하고, 필요한 기억을 로컬에서 순위화해 검색합니다. 기억을 관리하는 독립적인 sleep-time Manage layer를 두며, API 키 없이 Claude Code와 Codex가 하나의 저장소를 공유할 수 있다고 설명합니다.

먼저 밝혀둘 제약이 있습니다. 이번 자료에는 README 확보 실패라고 적혀 있어 설치법, 명령어, 내부 구성, 지원 범위, 성능 측정 결과는 확인할 수 없습니다. 아래에서는 제공된 프로젝트 설명과 토픽에서 직접 확인되는 내용, 그 구조에서 읽히는 의미를 나누어 다룹니다. 구체적인 구현 상태나 완성도를 추정해 사실처럼 말하지 않겠습니다.

핵심은 기억을 모델 안이 아니라 읽을 수 있는 파일에 두는 것입니다

agent-memory가 내세우는 가장 중요한 선택은 plain Markdown as the source of truth, 즉 평범한 마크다운을 정본으로 삼는 것입니다.

정본(source of truth)은 여러 시스템이 같은 정보를 참고할 때 최종 기준이 되는 원본입니다. 연락처를 메신저, 휴대전화, 수첩에 각각 다르게 적어 놓으면 어느 것이 최신인지 알기 어렵습니다. 하나의 주소록을 기준으로 삼으면 수정과 확인이 쉬워집니다.

프로젝트 설명대로라면 에이전트의 기억에서는 마크다운 파일이 이 주소록 역할을 합니다. 기억이 사람이 읽기 어려운 내부 형식에만 갇히지 않고, 사용자가 직접 열어 내용을 확인할 수 있습니다.

이 선택은 기억을 단순한 저장 기능이 아니라 소유하고 검토할 수 있는 기록으로 본다는 데 의미가 있습니다. 에이전트가 어떤 정보를 기억하는지 사람이 읽고, 잘못된 내용이 있다면 원본을 찾아 고칠 수 있습니다. 기억을 특정 모델이나 하나의 대화 화면에 맡기는 방식과는 출발점이 다릅니다.

제공된 자료만으로는 마크다운 파일의 구체적인 형식이나 여러 파일이 충돌할 때의 처리 방식, 변경 이력 관리 여부까지 알 수 없습니다. 확인되는 사실은 마크다운이 부가적인 내보내기 형식이 아니라 기억의 원본으로 명시돼 있다는 것입니다.

모든 기억을 매번 읽는 대신 필요한 것을 먼저 찾습니다

기억을 파일에 쌓는 것만으로는 충분하지 않습니다. 기록이 많아질수록 지금 필요한 내용을 골라내는 일이 중요해집니다.

agent-memory는 local ranked retrieval, 즉 로컬에서 수행하는 순위 기반 검색을 제시합니다. 검색 결과를 단순히 나열하지 않고 현재 요청과 더 관련 있다고 판단되는 기록을 앞에 배치하는 방식입니다.

일상적인 서랍을 떠올리면 이해하기 쉽습니다. 모든 영수증과 메모를 한 상자에 보관하는 것은 저장입니다. 오늘 필요한 보증서를 관련성이 높은 순서로 찾아 책상 위에 올려주는 일은 검색입니다. 장기기억 시스템에서는 상자의 크기보다 필요한 순간에 올바른 문서를 꺼낼 수 있느냐가 더 중요합니다.

local이라는 표현도 짚어볼 필요가 있습니다. 공개된 설명에 따르면 검색 과정이 로컬에서 이뤄지는 구조를 지향합니다. 프로젝트가 local-first를 토픽으로 내세우고 API 키가 필요하지 않다고 설명하는 것도 같은 방향입니다.

다만 어떤 검색 알고리즘을 쓰는지, 의미 기반 검색인지 단어 기반 검색인지, 둘을 결합하는지, 순위가 얼마나 정확한지는 자료에서 확인되지 않습니다. 로컬 순위 검색이 존재한다는 설명과 실제 검색 품질이 뛰어나다는 판단은 구분해야 합니다.

기억을 사용하는 일과 정리하는 일을 분리합니다

세 번째 특징은 독립적인 sleep-time Manage layer입니다. 직역하면 에이전트가 쉬는 시간에 작동하는 관리 계층 정도입니다.

여기서는 sleep-time보다 independent, 독립적이라는 표현이 중요합니다. 공개된 설명에서는 기억을 당장 찾아 사용하는 과정과 축적된 기억을 별도로 관리하는 과정을 나눕니다.

사람도 회의 중에는 메모를 빠르게 남기고, 회의가 끝나면 중복된 내용을 합치거나 중요도를 표시합니다. 대화 도중 저장과 검색, 정리를 한꺼번에 수행하면 반응 과정이 복잡해질 수 있습니다. 사용 과정과 관리 과정을 분리하면 각각의 책임이 비교적 분명해집니다.

README를 확인하지 못했기 때문에 이 관리 계층이 구체적으로 무엇을 하는지는 알 수 없습니다. 오래된 기억을 삭제하거나 중복 내용을 병합하고 요약·분류한다고 단정해서는 안 됩니다. 자료에서 확인되는 범위는 별도의 Manage 계층이 존재한다는 설계 설명까지입니다.

이러한 분리는 중요한 질문을 드러냅니다. 에이전트 기억의 품질은 얼마나 많이 저장했느냐만으로 결정되지 않습니다. 잘못됐거나 낡은 내용, 서로 충돌하는 내용이 누적되면 검색이 정확해도 틀린 기억을 불러올 수 있습니다. 기억 시스템에는 저장과 검색뿐 아니라 유지관리라는 세 번째 책임이 필요합니다. agent-memory는 이 책임을 프로젝트 설명에서 별도 계층으로 드러냈습니다.

Claude Code와 Codex가 같은 기억을 본다는 의미

프로젝트는 Claude Code와 Codex가 하나의 저장소를 공유한다고 설명합니다. 이 대목은 특정 모델의 기능보다 도구 사이에서 이어지는 작업 맥락에 관한 제안에 가깝습니다.

개발자가 한 가지 에이전트만 계속 사용하리라는 법은 없습니다. 어떤 작업은 Claude Code에서 진행하고, 다른 작업은 Codex에서 이어갈 수 있습니다. 기억이 각 도구 안에만 갇혀 있으면 사용자는 프로젝트 규칙과 이전 결정, 선호하는 작업 방식 등을 반복해서 설명해야 합니다.

공유 저장소는 기억의 중심을 개별 에이전트에서 사용자의 작업 공간으로 옮기는 접근입니다. 직원마다 별도의 개인 수첩만 갖는 대신 함께 읽을 수 있는 업무 기록부를 두는 것과 비슷합니다.

검증할 부분은 남아 있습니다. 두 도구가 어떤 방식으로 저장소에 연결되는지, 동시에 수정할 때 충돌을 어떻게 다루는지, 접근 권한을 나눌 수 있는지, 기억의 범위를 프로젝트별로 격리할 수 있는지는 제공된 자료만으로 알 수 없습니다. 장기기억에는 코드 작성 습관뿐 아니라 민감한 프로젝트 정보도 들어갈 수 있습니다. 공유가 편리한 것과 안전하게 공유되는 것은 별개의 문제입니다.

API 키가 필요 없다는 주장이 겨냥하는 마찰

프로젝트 설명에는 No API key가 명시돼 있습니다. 공개된 자료 기준으로 별도의 API 키 없이 사용할 수 있다는 뜻입니다.

설치하고 사용하기 시작할 때 외부 서비스 계정이나 별도 인증 정보를 요구하지 않는 방향으로 읽힙니다. 로컬 우선 구조와 결합하면 사용자가 기억을 직접 보유하고 운용하려는 설계 의도가 선명해집니다.

API 키가 필요 없다고 해서 모든 비용이 사라지거나 모든 기능이 완전히 오프라인으로 작동하고, 보안 문제가 자동으로 해결되는 것은 아닙니다. 그런 내용은 자료에 없습니다. 에이전트 자체의 이용 조건과 기억 런타임의 조건도 따로 봐야 합니다.

토픽이 보여주는 기술적 범위와 아직 확인되지 않은 부분

저장소에는 agent-memory, ai-agents, claude-code, codex, llm, local-first, long-term-memory, markdown, mcp, python, retrieval, sqlite가 토픽으로 제시돼 있습니다.

이 목록을 보면 프로젝트가 에이전트 장기기억, 로컬 우선 운영, 검색, 마크다운, Python 생태계와 연결돼 있음을 알 수 있습니다. MCP와 SQLite도 토픽에 포함돼 있습니다. 다만 토픽은 프로젝트가 스스로 분류한 키워드입니다. README와 코드를 확인하지 못한 상태에서 MCP가 어떤 인터페이스를 제공하고 SQLite가 어떤 데이터를 저장하는지까지 추론해서는 안 됩니다.

오픈소스를 살펴볼 때는 이 구분이 중요합니다. 저장소의 설명과 토픽은 프로젝트가 풀려는 문제를 알려주지만 실제 사용 경험과 안정성까지 보증하지는 않습니다. 별 822개 역시 관심을 보여주는 공개 지표일 뿐, 운영 환경에서의 채택이나 지속적인 사용을 입증하는 수치는 아닙니다.

무엇이 새롭게 보이는가

agent-memory를 구성하는 각 단어가 완전히 새로운 개념이라고 말할 근거는 이번 자료에 없습니다. 개별 기능보다 눈에 들어오는 것은 선택한 조합입니다.

기억의 원본은 사람이 읽을 수 있는 마크다운에 둡니다. 그 원본에서 필요한 내용을 로컬 순위 검색으로 찾고, 기억을 사용하는 계층과 관리하는 계층은 분리합니다. 하나의 모델이나 도구에 종속되지 않도록 Claude Code와 Codex가 같은 저장소를 보게 하며, 별도 API 키를 요구하지 않는다고 설명합니다.

이 조합은 장기기억을 모델의 부속 기능이 아니라 여러 에이전트가 함께 쓰는 독립적인 로컬 런타임으로 봅니다. 기억의 중심을 모델 공급자가 아닌, 사용자가 관리하는 파일과 실행 환경에 두려는 것입니다.

투자자의 시각에서 보는 산업적 의미

여기부터는 공개된 사실이 아니라 그 사실에서 출발한 저의 해석입니다.

AI 에이전트가 실제 업무에서 오래 사용될수록 경쟁의 단위는 한 번의 답변 품질에서 지속적인 작업 관계로 이동할 가능성이 높습니다. 지속적인 관계에는 기억이 필요합니다. 그러나 기억이 특정 모델이나 제품 안에만 묶이면 사용자는 편리함을 얻는 대신 이동성을 잃을 수 있습니다.

agent-memory가 설명하는 공유 저장소와 마크다운 정본은 반대 방향을 제안합니다. 모델을 바꿔도 기억을 유지하고, 사람이 직접 내용을 확인하며, 여러 도구가 같은 기록을 사용하는 구조입니다. 실제로 작동한다면 기억 계층은 개별 에이전트에 붙는 작은 기능을 넘어 여러 에이전트 아래에서 공통으로 작동하는 기반 계층이 될 수 있습니다.

투자 관점에서 먼저 볼 것은 기억의 이동성이 실제 구매 기준이 되는지입니다. 사용자가 여러 에이전트를 오가며 일할수록 공용 기억 저장소의 가치는 커질 수 있습니다. 반대로 대부분의 사용자가 한 제품 안에서 제공되는 내장 기억에 만족한다면 독립 런타임의 필요성은 제한적일 수 있습니다.

사람이 읽을 수 있는 정본이 운영상의 신뢰로 이어지는지도 확인해야 합니다. 마크다운은 접근성과 투명성 면에서 이해하기 쉬운 선택입니다. 하지만 기억이 커지고 관계가 복잡해진 뒤에도 파일 중심 구조를 관리할 수 있어야 합니다. 단순함은 초기 채택에 유리하지만, 규모가 커진 뒤에도 장점으로 남을지는 별도의 검증이 필요합니다.

검색보다 관리가 더 큰 차별점이 될 가능성도 있습니다. 기억을 많이 저장하는 제품은 만들 수 있어도 오래된 사실과 새로운 사실을 구분하고 충돌을 처리하기는 더 어렵습니다. agent-memory가 내세우는 독립 Manage 계층이 실제로 이 문제를 얼마나 다루는지가 중요합니다. 현재 자료에는 구체적인 동작이 없어 가능성만 확인할 수 있습니다.

가장 강한 반론은 내장 기능으로 충분할 수 있다는 것입니다

이 프로젝트를 긍정적으로만 볼 수는 없습니다. 가장 강한 반론은 에이전트 제품이 자체 기억 기능을 개선하면 별도의 장기기억 런타임이 필요하지 않을 수 있다는 것입니다.

독립 저장소는 이동성과 통제권을 제공할 수 있지만 사용자에게 설치와 관리의 책임을 떠넘길 수도 있습니다. 마크다운이 투명하더라도 기록이 계속 늘어나면 사람이 직접 관리하기 어려워집니다. 여러 에이전트가 같은 기억을 수정할 때 충돌이나 오염이 생길 수도 있습니다.

무엇보다 장기기억의 핵심은 저장 여부가 아니라 정확한 회상입니다. 잘못된 기억을 자신 있게 불러오는 시스템은 기억하지 않는 시스템보다 위험할 수 있습니다. 현재 자료에는 검색 정확도, 기억 충돌 처리, 권한 분리, 개인정보 관리, 장기간 사용 결과를 뒷받침하는 근거가 없습니다.

이 프로젝트의 투자 가설을 깨뜨릴 증거도 비교적 분명합니다. 여러 도구 사이에서 기억을 공유하려는 수요가 약하거나, 기록이 늘면서 검색 품질이 크게 떨어지거나, 관리 계층이 기억의 오류와 충돌을 충분히 다루지 못한다면 독립 기억 런타임의 가치는 약해질 수 있습니다.

다음 단계에서 확인하고 싶은 것

README와 실제 저장소 내용을 확인할 수 있다면 다음 항목부터 살펴보겠습니다.

• 기억이 저장되는 마크다운의 구조와 사용자가 직접 편집할 수 있는 범위
• 로컬 순위 검색의 방식과 관련성 판단 기준
• 독립 Manage 계층이 실제로 수행하는 작업
• Claude Code와 Codex가 하나의 저장소에 연결되는 구체적인 절차
• 동시 수정, 중복 기억, 상충하는 사실을 처리하는 방식
• 프로젝트별 또는 사용자별 기억 격리와 권한 관리
• MCP와 SQLite 토픽이 실제 구현에서 맡는 역할
• 설치 과정과 지원 환경, 테스트와 재현 가능한 사용 사례

이 항목들을 확인해야 프로젝트가 제시하는 개념이 실제로 견고한 도구로 구현됐는지 판단할 수 있습니다.

기억의 주도권을 누구에게 둘 것인가

agent-memory가 던지는 문제는 단순하지만 중요합니다. AI 에이전트의 기억을 모델이나 서비스 내부에 둘 것인가, 사용자가 읽고 소유할 수 있는 별도 저장소에 둘 것인가.

공개된 설명만 보면 이 프로젝트는 마크다운 정본, 로컬 순위 검색, 독립적인 관리 계층, Claude Code와 Codex의 저장소 공유, API 키 없는 사용이라는 분명한 방향을 갖고 있습니다. 반면 README를 확보하지 못해 실제 기능과 품질, 보안, 확장성은 아직 확인되지 않았습니다.

투자자의 시각에서 얻는 핵심은 이렇습니다. 에이전트 시장이 커질수록 모델만큼 중요해지는 것은 사용자의 맥락을 누가 보유하고 관리하느냐일 수 있습니다. agent-memory는 기억을 특정 에이전트에 종속시키지 않고 사용자의 로컬 파일로 돌려주려는 시도로 보입니다. 이제 확인해야 할 것은 이 철학이 실제 사용 환경에서도 정확하고 안전하며 편리하게 작동하는지입니다.