MemPalace는 일주일 만에 4만 1천 개의 스타를 모았습니다. 이건 과장이 아니라 고통입니다. 개발자들은 AI와 나눈 대화를 더 이상 잃고 싶지 않은 겁니다. 모든 디버깅 세션, 모든 아키텍처 결정, "우리가 X를 시도했고 Y 때문에 실패했다"는 식의 맥락이 세션이 끝나면 사라집니다.
MemPalace는 이 문제를 해결하겠다고 말합니다. 모든 걸 로컬에 저장하고, ChromaDB로 검색하고, LongMemEval에서 96.6% recall을 얻는다. API 키도 없고, 클라우드도 없고, 비용도 없습니다. 그리고 그 점수는 실제로 재현됐습니다.
저는 이 프로젝트를 진심으로 존중합니다. 팀이 출시 48시간 안에 과장된 수치를 공개적으로 철회할 정도로 정직했다는 건, 이 분야에서는 드문 일입니다.
하지만 코드와 벤치마크를 읽어본 뒤에는, MemPalace를 포함해 Mem0, Zep, 그리고 지금 나와 있는 거의 모든 메모리 시스템이 문제의 잘못된 레이어를 풀고 있다고 생각하게 됐습니다.
96.6%가 실제로 뜻하는 것
MemPalace의 대표 점수는 raw verbatim 모드에서 나옵니다. 전체 대화를 ChromaDB에 넣고, semantic similarity search를 돌리고, 상위 5개 결과를 반환합니다. 요약도 없고, 추출도 없고, LLM도 중간에 없습니다.
이건 브루트포스 접근이고, retrieval 벤치마크에서는 아주 잘 작동합니다. GraphQL 마이그레이션을 논의했던 정확한 대화를 저장해뒀고, 누군가 "왜 우리가 GraphQL로 바꿨지?"라고 물으면 ChromaDB가 그걸 찾아냅니다. 원문이 그대로 있고, similarity search가 그걸 집어냅니다.
Palace 비유, wings, halls, rooms, closets, drawers는 ChromaDB 위의 계층형 metadata filtering을 우아하게 포장한 마케팅입니다. 실제로 그들 벤치마크도 분해해서 보여줍니다. 필터 없는 검색은 60.9%, wing 필터를 추가하면 73.1%, wing + room이면 94.8%입니다. 유용합니다. 동시에 metadata field를 가진 벡터 DB라면 흔한 기능이기도 합니다. 팀이 처음 주장했던 "+34% palace boost"도 나중에는 정확히 이 효과라고 정정됐습니다.
이건 비판이 아닙니다. 구조화된 metadata가 붙은 raw verbatim storage는 정당한 설계 선택입니다. 한 가지에 최적화된 선택이죠. 과거 대화를 찾는 것. 그리고 그건 분명 잘합니다.
문제는 과거 대화를 찾는 것만으로 충분하냐는 겁니다.
Retrieval은 메모리가 아니다
이런 사고 실험을 해봅시다. MemPalace를 6개월째 쓰고 있다고 해보죠. 15개의 프로젝트 wing에 걸쳐 2만 개의 대화 조각이 저장돼 있습니다. 이제:
동료가 "지금 우리의 auth 전략이 뭐지?"라고 묻습니다. 검색합니다. MemPalace는 다섯 개 조각을 돌려줍니다. 1월에 Auth0를 선택했던 기록, 3월에 Clerk로 마이그레이션을 논의했던 기록, 4월에 실제로 옮긴 기록, 5월에 새 Clerk 설정의 edge case를 다룬 두 개의 기록. 이 중 무엇이 현재 상태를 나타낼까요? MemPalace는 모릅니다. 시간적 유효성이나 supersession이 아니라 유사도 순으로 다섯 개를 반환합니다. 결국 당신이나 AI가 다 읽고 타임라인을 복원해야 합니다.
이번에는 이렇게 물어봅시다. "우리가 처음부터 지금까지 데이터베이스 선택에 대한 입장이 바뀌었나?" 이건 하나의 지식 원자, "우리는 Postgres를 쓴다" 같은 것이 만들어졌고, 나중에 업데이트되거나 모순됐는지, 그 변화를 추적해야 답할 수 있는 질문입니다. 그런데 raw verbatim search는 "database"라는 단어가 들어간 조각만 돌려줍니다. 서사를 재구성하는 일은 독자 몫으로 남습니다.
이게 retrieval과 memory의 차이입니다. Retrieval은 텍스트를 찾습니다. Memory는 상태를 이해합니다. 무엇이 현재인지, 무엇이 대체됐는지, 무엇이 무엇과 모순되는지, 지식이 시간에 따라 어떻게 진화했는지를 다룹니다.
MemPalace도 이 간극을 알고 있습니다. fact_checker.py라는 contradiction detection 유틸리티와 temporal knowledge graph를 만들었습니다. 하지만 2026년 4월 정정 시점 기준으로 contradiction detector는 knowledge graph 작업 흐름에 연결되어 있지 않습니다. 별도 스크립트로 존재합니다. 이건 나중에 고치면 되는 버그가 아닙니다. 구조화된 이해를 원시 저장소 위에 얹는 부가 기능으로 취급하는 아키텍처의 증상입니다.
아무도 말하지 않는 Portability 문제
제가 retrieval 품질보다 더 크게 보는 문제는 이겁니다.
MemPalace는 모든 걸 로컬 머신의 ChromaDB + SQLite에 저장합니다. 자기들 형식으로. export 표준도 없고, migration 경로도 없습니다.
오늘은 Claude Code와 함께 MemPalace를 씁니다. 6개월 동안의 대화가 wings와 rooms로 잘 정리돼 있다고 해보죠. 이제:
Cursor로 옮깁니다. 메모리를 가져갈 수 있을까요? Cursor에 MemPalace MCP integration이 있고, MCP 서버가 돌아가고 있고, 같은 ChromaDB 인스턴스를 바라본다면 가능할 수 있습니다. 즉, 메모리는 portable한 게 아니라 특정 도구와 특정 런타임을 통해서만 접근 가능한 상태입니다.
휴대폰에서 메모리를 쓰고 싶습니다. MemPalace는 ChromaDB를 사용하는 로컬 Python 패키지입니다. hosted 옵션도, sync도, mobile 경로도 없습니다.
팀이 shared memory를 원합니다. MemPalace는 single-user, single-machine입니다. multi-user story가 없습니다.
Mem0나 Zep을 써보고 싶습니다. 2만 개의 조각은 MemPalace의 ChromaDB schema 안에 있습니다. 다른 시스템이 가져갈 수 있는 표준 export format이 없습니다.
이건 MemPalace만의 문제가 아닙니다. 업계 전체 패턴입니다. 모든 메모리 시스템이 자기만의 storage format, 자기만의 schema, 자기만의 retrieval logic을 만듭니다. 시스템을 바꾸면 메모리를 잃습니다. Harrison Chase가 모델 제공자에 대해 경고했던 바로 그 락인이, 이제는 메모리 제공자 쪽에서 다시 일어나고 있는 겁니다.
| 시스템 | 저장소 | Portable? | 표준 포맷? |
|---|---|---|---|
| MemPalace | ChromaDB + SQLite | No | No |
| Mem0 | Proprietary cloud | No | No |
| Zep | Neo4j cloud | No | No |
| Letta | Embedded in harness | No | No |
| Claude Memory | Behind API | No | No |
| ChatGPT Memory | Behind API | No | No |
모든 행이 사일로입니다. 당신의 메모리는 도구 선택에 인질로 잡혀 있습니다.
메모리가 실제로 필요로 하는 것
한 걸음 물러서서 진짜 메모리 시스템에 무엇이 필요한지 물어보면, retrieval은 긴 목록 중 하나의 기능일 뿐입니다.
Atomization: 대화를 사실, 결정, 선호, 관계 같은 개별 지식 단위로 쪼개서 각각을 추적, 업데이트, 대체할 수 있어야 합니다. Raw verbatim storage는 이 단계를 통째로 건너뜁니다.
Temporal awareness: 1월의 "우리는 Auth0를 쓴다"가 4월의 "우리는 Clerk로 마이그레이션했다"에 의해 대체됐다는 걸, 사용자가 두 조각을 읽고 직접 추론하지 않아도 알아야 합니다.
Portability: 도구, 기기, 플랫폼을 넘어 함께 움직이는 메모리. 한 머신의 한 벡터 DB에 잠기지 않는 메모리여야 합니다.
Scope management: 프로젝트 지식, 개인 선호, 세션 한정 맥락을 구분해야 합니다. 모든 것이 모든 쿼리에 속하면 안 됩니다.
Decay and relevance: 어떤 지식은 시간이 지나며 가치가 떨어집니다. 이미 리팩터링된 코드베이스의 구현 디테일이 현재 아키텍처 결정과 같은 무게로 retrieval 순위를 다투면 안 됩니다.
Protocol-level interoperability: 어떤 하니스든, 어떤 도구든, 어떤 백엔드든 말할 수 있는 표준 계약이 필요합니다. 그래야 메모리가 한 제품의 기능이 아니라 인프라가 됩니다.
MemPalace는 메모리 시스템의 첫 요구사항, 데이터를 잃지 않는다는 점은 제대로 해결합니다. 하지만 위 여섯 가지가 있어야 저장된 데이터가 작동하는 메모리가 됩니다.
AMCP: 프로토콜로서의 메모리
그래서 제가 AMCP, Agent Memory Continuity Protocol를 만들고 있습니다. Apache 2.0 오픈 표준이고, MCP(도구), A2A(에이전트 협업) 옆에 놓이는 세 번째 에이전트 인프라 레이어로 생각하고 있습니다.
핵심 아이디어는 이겁니다. 메모리는 제품이 아니라 계약이어야 한다. 어떤 하니스든 표준 인터페이스를 통해 메모리를 저장하고 recall할 수 있어야 하고, 어떤 백엔드든 그 인터페이스를 구현할 수 있어야 합니다. 사용자는 어떤 도구를 쓰든 자기 메모리를 계속 소유해야 합니다.
AMCP는 다음을 정의합니다.
- 지식 단위를 위한 표준 atom shape
- Scope와 visibility control (project, user, session)
- Similarity search와 scope filtering을 포함한 recall
- Portable format의 export/import
- Backend-agnostic transport (local SQLite, hosted cloud, third-party)
스펙은 github.com/goldberg-aria/amcp에 있습니다.
3122: 하니스 통합이 실제로 어떤 모습이어야 하는가
프로토콜은 동작하는 구현이 없으면 그냥 문서입니다. 3122는 이 아키텍처가 실제로 된다는 걸 보여주는 AMCP 네이티브 코딩 하니스입니다.
3122는 두 종류의 상태를 명확하게 나눕니다.
Continuity Runtime State는 하니스 안에 남습니다. Session transcript, trajectory compression (goal -> attempt -> failure -> verification -> next-step), 모델 전환 시 handoff snapshot, 파일 단위 working memory. 이런 것들은 하니스가 책임져야 하는 운영 상태입니다.
Portable Memory는 AMCP를 거칩니다. Item shape는 하나입니다. 백엔드는 바꿔 낄 수 있습니다. 내 머신의 SQLite를 쓰는 local-amcp, 호스팅 백엔드인 nexus-cloud, 그리고 프로토콜만 말하면 무엇이든 붙일 수 있는 third-party-amcp.
흥미로운 건 통합의 깊이입니다. 3122는 AMCP를 그냥 검색 API로 부르지 않습니다. Trajectory-aware recall을 씁니다. 지금 작업 중인 파일과 마주친 에러에 관련된 atom을 우선합니다. Context budget도 관리합니다. 세션이 길어질수록 conversation recall부터, 그다음 오래된 memory, 그다음 recent history 순으로 줄입니다. 모델을 바꾸면 handoff snapshot도 남겨서, 새 모델이 첫 턴에서 context boost를 받게 합니다.
이 모든 건 하니스 로직입니다. 하니스가 무엇을 넣을지 결정하고, AMCP는 무엇 중에서 고를지를 제공합니다. 깔끔한 분리, 깊은 통합입니다.
그리고 portability 이야기는 이렇습니다.
# 전부 내보내기
3122 memory export --format amcp-jsonl --output my-knowledge.jsonl
# 백엔드 바꾸기
3122 memory migrate --from local-amcp --to nexus-cloud
# 워크스페이스를 지우고 다시 만들어도
# 메모리는 살아 있다.레포는 github.com/goldberg-aria/3122-harness에 있습니다.
Raw Storage도 자기 자리가 있다
분명히 하고 싶습니다. 저는 MemPalace 접근이 틀렸다고 말하는 게 아닙니다. Semantic search가 붙은 raw verbatim storage는 유효한 도구입니다. 자기 노트북에서 과거 Claude 대화를 검색하고 싶은 개인 개발자에게는 아주 좋습니다.
하지만 문제 공간은 로컬 검색보다 큽니다. 팀은 shared memory가 필요하고, 워크플로우는 구조화된 지식이 필요하고, 사용자는 도구를 바꿔도 살아남는 메모리가 필요합니다. 업계에는 사일로를 멈추게 할 표준이 필요합니다.
MemPalace의 96.6% recall은 retrieval 문제가 풀 수 있는 문제라는 걸 보여줍니다. 하지만 그것이 다루지 않는 것, 그리고 현재 어떤 시스템도 제대로 다루지 못하는 것은 portability와 structure 문제입니다.
그걸 위해 AMCP와 3122가 있습니다.
지형도
우리는 아직 AI 메모리의 초반에 있습니다. MemPalace, Mem0, Zep, Letta, 그리고 물론 Nexus와 AMCP까지, 이 공간의 모든 프로젝트는 서로 다른 트레이드오프를 실험하고 있습니다. MemPalace가 일주일 만에 4만 1천 스타를 모았다는 사실은 수요가 진짜이고 엄청 크다는 걸 보여줍니다.
제 베팅은, 결국 이기는 아키텍처는 세 가지 관심사를 분리하는 쪽이라는 겁니다.
- 하니스는 컨텍스트 관리를 맡는다. 무엇을 프롬프트에 넣을지, 토큰을 어떻게 예산 잡을지, 언제 compact할지
- 메모리 레이어는 persistence와 recall을 맡는다. atom 저장, temporal validity 관리, scope 처리
- 프로토콜은 둘을 연결한다. 그래서 하니스도 백엔드도 락인을 만들지 못하게 한다
MCP가 도구에 대해 했던 일을, AMCP는 메모리에 대해 하려 합니다.
당신의 대화는 세션이 끝났다고 죽어서는 안 됩니다. 하지만 동시에 한 도구 안에 영원히 갇혀서도 안 됩니다.
---
AMCP spec: github.com/goldberg-aria/amcp 3122 harness: github.com/goldberg-aria/3122-harness 이 시리즈의 첫 글: 하니스는 바뀌어도, 기억은 바뀌면 안 됩니다.