메모리가 새로운 해자(moat)다: AI 코딩 에이전트들이 기억하려고 경쟁하는 이유

지난주, 서로 조율하지 않은 네 팀이 AI 코딩 에이전트를 위한 영구 메모리 시스템을 출시했다. Engram, Beads, Memori, memsearch — 모두 며칠 간격으로 GitHub에 등장했고, 모두 같은 문제를 해결했다. 당신의 AI 코딩 에이전트는 기억 상실증을 앓고 있다.

이런 수렴은 우연히 일어나지 않는다. 서로 무관한 네 팀이 동시에 같은 문제가 만들 가치가 있을 만큼 긴급하다고 결정할 때, 당신은 우연이 아닌 시장 신호를 목격하고 있는 것이다. 그리고 그것이 신호하는 것은 이렇다. AI 툴링에서 다음 경쟁 우위는 모델 지능이 아니라 메모리다.

기억 상실 문제

Steve Yegge는 그것을 "첫 번째 데이트 50번(50 First Dates)" 문제라고 부른다. 매일 아침 당신의 에이전트는 어제의 기억 없이 깨어난다. 당신은 각 세션의 첫 10~12분을 프로젝트 아키텍처, 팀의 관례, 왜 그 함수가 의도적으로 이상하게 만들어졌는지를 다시 설명하는 데 쓴다. 에이전트는 작업을 완수한다. 세션을 닫는다. 내일이면 다시 낯선 사람이다.

계산해보자. 세션당 12분, 하루 몇 세션, 주 5일. 한 달에 대략 하루 일과 분량을 에이전트의 메모리 역할로 쓴다. 여섯 에이전트 프로덕션 시스템을 운영하는 한 개발자는 직접적으로 말했다. "에이전트들은 CLAUDE.md 지침을 조용히 잃고, 어떤 파일이 변경됐는지 잊고, 30분 전 작업을 다시 한다. 우리에게 절대 말하지 않는다."

이것은 프롬프트 문제도 아니다. 긴 대화에서 에이전트들은 새로운 토큰을 위한 공간을 만들기 위해 초기 컨텍스트를 압축한다. 더 나은 시스템 프롬프트는 컨텍스트 윈도우 한계를 고칠 수 없다. 이건 시스템 문제다 — 시스템 해결책이 필요하다.

우리가 사용해온 임시방편들은 기껏해야 1.0 버전이다. CLAUDE.md와 AGENTS.md 파일들 (이제 6만 개 이상의 저장소에 있다)은 매 세션 로드되면서 정보가 관련 있든 없든 컨텍스트를 잡아먹는다. 메가 프롬프트와 수동으로 관리되는 컨텍스트 문서들은 인지 부하를 개발자에게 떠넘긴다. 당신이 메모리 시스템이 된다. 그리고 그것은 에이전트를 갖는 것의 요점 절반을 무색하게 한다.

네 가지 해결책, 네 가지 철학

graph LR
    A[Engram] -->|SQLite + FTS5| B[Keyword Search]
    C[Beads] -->|Dolt| D[Version-Controlled Graph]
    E[Memori] -->|SQL-native| F[Zero-Config MCP]
    G[memsearch] -->|Milvus| H[Semantic Vector Search]

이번 주 메모리 툴 폭발에서 흥미로운 점은 모두가 만들고 있다는 것만이 아니다 — 같은 문제에 완전히 다른 접근 방식을 취하고 있다는 것이다.

Engram: Unix 철학

Engram은 단일 Go 바이너리다. 의존성 없음, 설정 의식 없음. SQLite와 FTS5 전문 검색을 쓰고, MCP 서버, HTTP API, CLI로 동시에 자신을 노출한다.

데이터 모델은 의도적으로 단순하다. 모든 메모리는 What/Why/Where/Learned로 구조화된다. 에이전트가 자동으로 쓰고 읽는 개발자의 현장 일지처럼 생각하면 된다. brew install로 1분 안에 실행할 수 있다.

하지만 진짜 영리함은 Engram이 기억하지 않는 것에 있다. 현대 Anki를 구동하는 것과 같은 간격 반복 알고리즘인 FSRS-6 덕분에 메모리가 일정에 따라 소멸된다. 중요하지 않은 것들은 영원히 쌓이는 대신 서서히 잊혀진다. 모든 메모리는 유형으로 분류된다. FACT, DECISION, PREFERENCE, GOAL, PROCEDURE, PRINCIPLE. 에이전트는 "사용자는 스페이스보다 탭을 선호한다" (PREFERENCE)와 "배포 스크립트는 Node 20이 필요하다" (FACT)의 차이를 안다. 대부분의 메모리 시스템은 이 구분을 하지 않는다 — 그냥 덩어리를 저장한다.

이것이 "한 가지를 잘 하라" 접근 방식이다. 그래프 데이터베이스 없음, 벡터 임베딩 없음, 복잡한 압축 알고리즘 없음. 사려 깊은 정보 아키텍처를 갖춘 SQLite의 구조화된 텍스트. 많은 팀에게 그것이 정확히 올바른 것이다.

Beads: 버전 관리 그래프

Steve Yegge와 Gastown 팀의 Beads는 반대 입장을 취한다. 플랫 마크다운 계획을 Dolt — 버전 관리 SQL 데이터베이스 — 로 뒷받침되는 의존성 인식 그래프로 대체한다.

핵심 혁신은 그들이 "메모리 소멸"이라고 부르는 것이다. 오래된 메모리를 자동으로 요약하고 압축하는 의미론적 압축 프로세스로, 컨텍스트 윈도우가 역사적 잡음에 압도되는 것을 막는다. 해시 기반 ID는 여러 에이전트가 메모리를 동시에 읽고 쓰는 멀티 에이전트 워크플로에서 병합 충돌을 없앤다.

Beads는 코딩 에이전트 오케스트레이션에 관한 Addy Osmani의 O'Reilly CodeCon 2026 강연에서 언급됐으며, 동반 툴 Gastown은 Beads의 메모리를 활용하는 멀티 에이전트 워크스페이스 매니저다. 에이전트에 작업을 할당하기 위한 gt sling, 감독을 위한 Mayor 세션, 그리고 내장된 stuck-agent 감지.

확장 수치가 이야기를 말해준다. Dolt 없이는 Gastown이 동시 에이전트 4개 이상에서 어려움을 겪었다. Beads를 뒷받침하는 Dolt의 버전 관리 SQL 덕분에, 단일 호스트에서 ~160개의 에이전트를 동시에 실행하고 있으며, 로드맵에 ~600개가 있다. 이건 점진적인 개선이 아니다 — 다른 범주의 툴이다.

Addy Osmani는 O'Reilly CodeCon 2026 강연에서 이것을 "전통적인 벡터 기반 RAG가 아니라, 플랫 마크다운 파일을 훨씬 넘어서는 구조화되고 쿼리 가능한 조직적 메모리"라고 설명했다. Yegge 자신은 그것을 "MCP+Playwright 이후 에이전틱 코딩에서 가장 큰 진전"이라고 부른다.

이것이 "메모리는 인프라다" 접근 방식이다. 설정이 더 복잡하지만, 대규모 코드베이스에서 여러 에이전트를 실행하는 팀을 위해 설계됐다.

Memori: 제로 설정 레이어

Memori는 자신을 "에이전트 네이티브 메모리 인프라"로 마케팅한다. SQL-native, LLM 불가지론적, 그리고 — 결정적으로 — SDK 통합이 필요 없다. MCP 서버로 추가하면 Claude Code, Cursor, Codex, Warp, Antigravity와 그냥 작동한다.

핵심 제안은 메모리가 보이지 않아야 한다는 것이다. 생각할 필요도, 설정할 필요도, 관리할 필요도 없어야 한다. 에이전트 실행에서 구조화된 영구 상태를 캡처하고 세션, 에이전트, 팀 구성원들 사이에서 사용 가능하게 한다. 시간이 지나면서 당신의 코딩 패턴, 리뷰어 선호도, 프로젝트 관례를 학습한다.

수치가 이를 뒷받침한다. LoCoMo 장기 대화 메모리 벤치마크에서 81.95% 정확도, 전체 컨텍스트 접근 방식 대비 컨텍스트 사용량은 ~5%에 불과하다. Zep, LangMem, Mem0 대비 20배의 컨텍스트 비용 절감이다.

이것이 "메모리 서비스" 접근 방식이다. 진입 장벽이 가장 낮고, MCP를 범용 통합 레이어로 가장 크게 베팅한다.

memsearch: 벡터 경로

Milvus를 만든 Zilliz가 구축한 memsearch는 또 다른 접근 방식을 취한다. 마크다운 우선이다. 세션이 마크다운으로 캡처되고, LLM으로 요약된 다음 Milvus 벡터 데이터베이스에 인덱싱된다.

의미론적 검색 각도가 여기서 중요하다. 키워드 매칭(Engram)이나 그래프 순회(Beads) 대신, memsearch는 의미로 관련 메모리를 찾는다. "지난번에 인증을 어떻게 처리했지?"라고 물으면, 그 세션들에서 "auth"라는 단어를 한 번도 쓰지 않았어도 관련 세션을 찾아낸다.

설계 철학은 투명성이다. 모든 메모리는 사람이 읽을 수 있는 텍스트 파일이다. 에이전트가 무엇을 알고 있는지 정확히 볼 수 있고, 파일을 편집해 잘못된 메모리를 수정하면 memsearch가 자동으로 변경을 반영한다. 독점 대시보드 없음, 블랙 박스 없음. 2주 안에 18만 9천 개 이상의 GitHub 스타를 모은 OpenClaw의 메모리 서브시스템에서 추출됐다.

이것이 "메모리를 검색으로" 접근 방식이다 — 기본적으로 자신의 에이전트 이력에 대한 RAG이며, 사람이 읽을 수 있는 저장소라는 추가적인 장점도 있다.

왜 지금인가?

이 수렴의 타이밍은 우연이 아니다. 세 가지가 맞아떨어졌다.

MCP가 보편화됐다. 이제 거의 모든 AI 코딩 툴이 MCP를 쓴다. MCP 서버로 구축된 메모리 시스템이 Claude Code, Cursor, Codex, Gemini CLI 등 다른 것들과 즉시 작동한다는 의미다. MCP 이전에는 메모리 시스템을 구축하면 모든 툴에 대해 다른 통합을 짜야 했다. 이제 하나를 쓰면 어디서든 작동한다.

에이전트가 메모리를 필요로 할 만큼 자율적이 됐다. Claude Code의 새로운 자동 모드 — 에이전트가 권한 프롬프트 없이 파일을 편집하고 명령을 실행하는 — 는 질적 전환이다. 에이전트들이 단순히 질문에 답하던 때에는 기억 상실이 귀찮았다. 이제 에이전트들이 독립적으로 다단계 작업을 실행하므로, 기억 상실은 위험하다. 어제 자신이 무엇을 했는지 기억하지 못하는 자율 에이전트는 작업을 다시 하거나, 이전 결정과 모순되거나, 신중한 선택을 덮어쓸 수 있다.

멀티 에이전트 워크플로가 주류에 진입했다. Gastown, Invoke, Parallel Code — 코드베이스에서 여러 에이전트를 실행하는 툴들이 확산되고 있다. 세 에이전트가 서로 다른 기능을 동시에 작업할 때, 공유 메모리는 있으면 좋은 것이 아니다. 그것들이 서로를 밟지 않게 하는 유일한 방법이다. 에이전트 A는 에이전트 B가 한 시간 전에 인증 모듈을 리팩토링했다는 것을 알아야 한다.

해자 주장

여기서 하고 싶은 주장이 있다. 12개월 안에, AI 코딩 툴의 승자는 가장 좋은 모델을 가진 것이 아닐 것이다. 가장 좋은 메모리를 가진 것들일 것이다.

모델 품질은 수렴하고 있다. Claude, GPT, Gemini — 모두 탁월하게 유능하고, 매 릴리즈마다 그들 사이의 격차는 좁아지고 있다. 차별화 요소는 원시 지능에서 축적된 컨텍스트로 스택 위로 이동하고 있다.

사용자의 관점에서 생각해보라. 당신의 아키텍처 결정, 팀의 네이밍 관례, 수정한 버그들, 거부한 접근 방식들을 기억하는 에이전트 — 그 에이전트는 매 세션마다 더 빠르고 더 정확해진다. 경쟁자로 전환하는 것은 제로에서 시작한다는 의미다. 그것이 해자(moat)다.

이것은 Google 검색을 지배적으로 만든 것과 같은 역학이다. 검색 알고리즘이 중요했지만, 사용자를 실제로 잠그게 만든 것은 그들이 무엇을 원하는지에 대한 누적된 이해였다. 메모리는 피드백 루프를 만든다. 더 나은 메모리가 더 정확한 결과로 이어지고, 그것이 더 많은 사용을 이끌고, 그것이 더 많은 메모리를 이끈다.

graph TD
    A["Better Memory"] --> B["More Accurate Results"]
    B --> C["Increased Usage"]
    C --> D["More Data Captured"]
    D --> A
    E["Switching Cost: Start from Zero"] -.->|"Lock-in"| A

개발자들에게 의미하는 것

오늘날 AI 코딩 에이전트를 사용한다면, 해볼 가치가 있는 세 가지 일이 있다.

1. 지금 메모리 시스템을 선택하고 시작하라. 오늘 쌓는 메모리가 내일의 우위가 된다. 잘 관리된 CLAUDE.md 파일처럼 간단한 것도 없는 것보다 낫다. 더 구조화된 것을 원한다면, Engram이 가장 쉬운 시작점이다 — brew install 한 번으로 실행된다.

2. 에이전트가 무엇을 기억해야 할지 생각하라. 모든 것이 영구화할 가치가 있는 것은 아니다. 아키텍처 결정, 거부된 접근 방식, 팀 관례, 프로젝트별 용어 — 이것들이 고가치 메모리다. 지난 화요일 디버깅 세션의 스택 트레이스는 아니다. Engram이 사용하는 What/Why/Where/Learned 구조는 다른 툴을 사용하더라도 좋은 정신 모델이다.

3. 멀티 에이전트 조율 공간을 지켜봐라. Beads와 Gastown이 어떤 지표든 된다면, 메모리 다음 최전선은 오케스트레이션이다 — 컨텍스트를 공유하고, 작업을 분할하고, 충돌을 피하는 여러 에이전트. 영구 메모리를 먼저 파악하는 팀이 멀티 에이전트 워크플로에서 상당한 선두 우위를 갖게 될 것이다.

불편한 질문

아무도 직접적으로 말하지 않는 긴장이 있다. 메모리 덕분에 에이전트가 시간이 지날수록 더 가치 있어지고, 그 메모리가 특정 툴의 생태계에 묶여 있다면, 우리는 새로운 종류의 벤더 잠금을 구축하고 있는 것이다. 당신의 CLAUDE.md는 Claude와 작동한다. 당신의 Engram 데이터베이스는 MCP 호환 모든 것과 작동한다 — 하지만 프로토콜이 발전하면 어떻게 되는가? Beads의 Dolt 데이터베이스나 memsearch의 Milvus 인덱스에 저장된 메모리는 어떻게 되는가?

에이전트 메모리의 이식성은 실제 문제가 될 것이다. 지금은 모든 시스템이 자체 스키마, 자체 저장 형식, 자체 검색 로직을 쓴다. "내 에이전트의 메모리를 내보내서 다른 시스템으로 가져오기"에 대한 표준이 없다. 하나의 생태계에 오래 투자할수록, 떠나기가 더 어려워진다.

이것은 지켜볼 가치가 있다 — 그리고 툴 선택에 반영할 가치가 있다. 개방되고 사람이 읽을 수 있는 형식(마크다운, SQLite)으로 메모리를 저장하는 시스템이 독점적 인덱스에 잠그는 것보다 더 오래간다.

이것이 향하는 곳

예측 하나를 하겠다. 2026년 말이 되면, 영구 메모리는 별도 툴이 아닐 것이다. 모든 주요 AI 코딩 에이전트의 내장 기능이 될 것이다. 지금 우리가 보고 있는 독립형 메모리 툴들은 초기 소스 제어 시스템과 같다 — 너무 근본적인 문제를 해결해서 필연적으로 플랫폼에 흡수된다.

흥미로운 질문은 어떤 접근 방식이 이기는가이다. Engram의 Unix 철학적 단순성? Beads의 버전 관리 정교함? Memori의 제로 마찰 투명성? memsearch의 의미론적 풍부함?

내 예측은 "모두, 다른 사용 사례를 위해"다. 솔로 개발자는 단순하고 이식 가능한 것을 원할 것이다. 멀티 에이전트 워크플로를 실행하는 엔터프라이즈 팀은 그래프 기반, 버전 관리 접근 방식이 필요할 것이다. 벡터 검색 접근 방식은 구조화된 회상보다 의미론적 검색이 더 중요한 곳이면 어디든 자신의 틈새를 찾을 것이다.

graph LR
    subgraph "Solo Developer"
        A["Engram"]
    end
    subgraph "Small Team"
        B["Memori"]
    end
    subgraph "Semantic-Heavy"
        C["memsearch"]
    end
    subgraph "Enterprise Multi-Agent"
        D["Beads + Gastown"]
    end
    A --> B --> C --> D

마무리로 할 만한 반직관적 생각이 있다. 메모리는 AI 문제가 아니다. 데이터 엔지니어링 문제다. 승리하는 해결책들 — Engram, Beads, Dolt — 은 SQLite, 전문 검색, 버전 관리 SQL 위에 구축됐다. 지루한 데이터베이스 기술이다. Simon Willison은 그것을 "컨텍스트 오프로딩"이라고 부른다. 예측 불가능한 프롬프트에서 내구성 있는 저장소로 상태를 이동시키는 것. 에이전트 메모리를 ML 연구 프로젝트가 아닌 데이터베이스 설계 과제로 접근하는 팀들이 지금 작동하는 해결책을 내놓고 있다.

기억 상실을 앓던 AI 에이전트의 시대가 끝나가고 있다. 오늘 에이전트의 메모리를 구축하기 시작하는 팀들이 내일 뒤돌아볼 수 없게 될 것이다.