포스트

MemPalace는 원문을 보존하면서 오래 기억할까? 계층 검색, 충돌, 로컬 운영

MemPalace의 핵심은 대화를 짧은 요약으로만 덮어쓰지 않고 원문과 검색용 구조를 함께 남기는 데 있습니다. 다만 원문이 남아 있다는 사실만으로 AI가 올바른 기억을 꺼내는 것은 아니며, 검색 재현율, 시점 충돌, 삭제 가능성과 모델 호출 경로를 따로 검증해야 합니다. 따라서 “완벽한 장기 기억”보다 로컬 기록 보관소와 검색 계층을 결합한 실험적 메모리 시스템으로 보는 편이 정확합니다.

MemPalace 저장소가 설명하는 문제는 분명합니다. 긴 프로젝트에서는 대화 요약 과정에서 예외 조건이나 결정 이유가 사라지고, 전체 기록을 매번 프롬프트에 넣으면 비용과 컨텍스트를 많이 씁니다. MemPalace는 원문을 보관한 채 필요한 일부만 다시 찾는 방식으로 이 두 선택지 사이를 노립니다.

원문 보존은 요약 방식보다 언제 유리할까

요약은 읽을 양을 줄이지만 무엇을 버릴지 작성 시점에 결정합니다. 당시에는 사소해 보였던 버전 번호, 오류 메시지, 반대 의견이 몇 달 뒤 장애 원인을 찾을 때 중요해질 수 있습니다. 원문을 유지하면 나중에 다른 질문으로 다시 검색할 여지가 생긴다는 점이 장점입니다.

반대로 “무손실 저장”과 “무손실 답변”은 같지 않습니다. 검색기가 관련 서랍을 찾지 못하거나, 오래된 결정을 최신 결정으로 오인하거나, 긴 원문에서 모델이 조건을 놓치면 결과는 틀릴 수 있습니다. 저장 단계의 손실을 줄였더라도 검색, 랭킹, 답변 단계의 오류는 남습니다.

Wing, Room, Drawer 계층은 검색 범위를 어떻게 줄일까

MemPalace는 원문과 탐색용 표현을 분리합니다. 원문 보존은 사후 질문의 선택지를 남기고, 계층과 색인은 매번 전체 대화를 읽지 않도록 검색 범위를 줄이는 역할을 합니다.

“요약하지 마라. 추출하지 마라. 날것의 대화 원본(Verbatim)을 그대로 보존하고, 최신 벡터 임베딩과 계층형 그래프 검색으로만 찾아라.”

시스템은 장소법(Method of Loci)을 비유로 사용하며 ChromaDB를 통한 시맨틱 검색과 SQLite 기반의 시간(Temporal) 지식 그래프를 결합한다고 설명합니다. 두 저장소를 함께 쓴다면 원문 레코드, 벡터 항목과 시간 그래프가 동일한 식별자를 공유하고 한쪽 갱신이 실패했을 때 재색인할 수 있어야 합니다.

단순한 플랫(Flat) 텍스트 파일이 아니라 철저하게 5단계 계층으로 나뉩니다.

  • Wings (날개): 최상위 네임스페이스. 프로젝트 단위나 협업하는 사람을 의미합니다 (예: Project_Driftwood 윙).
  • Rooms (방): Wing 내부의 특정 서브 도메인입니다 (예: Auth_Migration 방).
  • Halls (복도): 여러 Wing을 관통하는 공통 기억의 유형입니다. 확정된 사실을 모아두는 hall_facts, 마일스톤인 hall_events 등으로 묶입니다.
  • Drawers (서랍): 요약되지 않은 원본 대화 텍스트(Verbatim)를 보관하는 최하단 저장소입니다.
  • Closets (옷장): 서랍을 가리키는 메타데이터와 고압축 요약본이 들어가는 공간입니다.

AAAK(AI-readable shorthand)는 사람이 읽는 일반 문장 대신 모델이 처리할 구조화된 축약 표현을 둔다는 제안입니다. 프로젝트가 제시하는 압축률은 고유명사, 부정, 수치가 유지되는지, 모델을 바꿔도 같은 의미로 해석되는지, 축약본에서 원문으로 역추적 가능한지를 같은 데이터로 재현한 뒤 판단해야 합니다.

또한 기존 시스템이 클라우드 종속적이었다면, MemPalace는 데이터를 지키는 데 진심입니다. 아래 마크다운 표를 통해 현존하는 메모리 생태계의 트레이드오프를 대조해 보았습니다.

아키텍처 설계 철학MemPalace (New!)기존 클라우드 AI 메모리 (Mem0, Zep 등)단순 로컬 파일 관리 (CLAUDE.md)
저장/압축 방식원본 100% 보존 (Verbatim) + AAAK 약어LLM 기반 정보 추출 및 추상적 요약 (Lossy)수동 작성, 단순 텍스트 플랫 (Flat) 관리
인프라 의존성100% 로컬 (ChromaDB + SQLite)종속적 클라우드 인프라 (Neo4j 기반 등)무의존성 (순수 로컬 파일)
운영 비용의 위치로컬 저장, 색인, 백업을 직접 부담서비스와 모델 호출 조건에 따라 달라짐저장은 단순하나 매번 읽을 범위를 관리해야 함
검색 및 랭킹시맨틱 + 시간 기반(Temporal) 지식 그래프클라우드 내부 블랙박스 RAG매 실행 시 프롬프트로 전체 텍스트 로드

MCP 연결을 이용하면 여러 AI 클라이언트가 같은 저장소를 조회할 수 있습니다. 아래는 원문에 제시된 의사 코드 흐름이며, 설치 명령과 수치는 실제 사용 전 저장소 문서와 재현 가능한 평가에서 확인해야 합니다.

1
2
3
4
5
6
7
8
9
10
11
# 터미널에서 Claude에 MemPalace MCP 서버를 연동하는 로컬 CLI 설정
$ pip install mem-palace
$ claude mcp add mempalace -- python -m mempalace.mcp_server .

# --- 실제 동작 로직 (Under the Hood) ---
> User: "우리 예전에 Auth0 대신 Clerk 쓰기로 한 이유가 뭐였지?"
> AI 내부 트리거:
  1. SQLite Temporal Graph에서 'Auth' & 'Clerk' 엔티티 및 유효 기간 추출.
  2. ChromaDB 쿼리 -> Project_Driftwood Wing -> Auth_Migration Room 진입.
  3. 서랍(Drawer)에서 3개월 전의 원본 대화(Verbatim) 스니펫 정확히 인출 (96.6% 정확도).
> AI 응답: "당시 가격 정책과 개발자 경험(DX) 측면에서 Kai가 강력히 권장했기 때문입니다."

어떤 실무 질문에 먼저 시험할까

초기 시험은 답이 있는 질문으로 제한해야 합니다. “왜 A 대신 B를 골랐나”, “이 오류의 마지막 해결책은 무엇이었나”, “정책은 언제 바뀌었나”처럼 이유, 사실, 시간 질문을 섞고 사람이 정답 원문을 표시합니다.

시나리오 1: 마이크로서비스(MSA) 전환 중 발생하는 컨텍스트 스파이크 대처 거대한 모놀리스 시스템을 마이크로서비스로 쪼개는 작업은 그야말로 의사결정의 지옥입니다. 하루에도 수십 개의 아키텍처 결정이 쏟아지고 번복되죠. “User API 분리할 때 왜 GraphQL을 버리고 gRPC로 갔지?” 반년만 지나도 당사자조차 기억하지 못합니다. 이때 MemPalace가 구축되어 있다면, 팀원과 AI가 나눴던 치열한 토론 기록이 hall_decisions에 고스란히 남아있습니다. 밋밋한 요약본이 아니라, “그때 A 라이브러리의 1.4 버전에 심각한 메모리 릭(Leak) 이슈가 있어서 눈물을 머금고 우회했다”는 날것의 삽질 기록까지 딸려오기 때문에, 향후 레거시 시스템을 수정할 때 엄청난 인사이트를 제공합니다.

시나리오 2: 멀티 툴 환경에서의 로컬 ‘Single Source of Truth(SSOT)’ 구축 보통 개발을 할 때 에디터(Cursor)에서 코딩하다가, 터미널(Claude Code)에서 인프라 스크립트를 짜고, 웹 브라우저(ChatGPT)에서 개념을 검색하는 등 여러 환경을 오가며 일합니다. 기존에는 툴을 바꿀 때마다 AI에게 “내가 지금 뭘 하고 있었냐면…” 하며 상황을 다시 브리핑해야 했습니다. 하지만 MemPalace는 내 로컬 장비 내의 SSOT 역할을 확고히 합니다. 여러 에이전트가 MCP를 통해 백그라운드에서 하나의 궁전에 접속하여 서랍을 열어볼 수 있으므로, 어떤 툴을 켜든 당신의 비서는 이미 전체 히스토리를 완벽히 꿰고 있는 상태로 작업을 시작합니다.

로컬 우선 설계의 실패 조건은 무엇일까

프로젝트가 제시하는 벤치마크 숫자는 데이터셋, 검색 후보 수, 모델과 평가 기준이 같을 때만 비교할 수 있습니다. 한 숫자보다 관련 원문이 상위 검색 결과에 포함된 비율, 오래된 결정을 최신으로 오인한 비율, 질문당 토큰과 응답 시간을 함께 기록해야 합니다.

  • 직접 운영: ChromaDB의 벡터 인덱스와 SQLite를 함께 백업하고 업그레이드 뒤 재색인, 복구를 시험해야 합니다. 원문, 인덱스와 그래프가 어긋나면 검색 결과가 조용히 누락될 수 있습니다.
  • 멀티 디바이스 충돌: SQLite와 벡터 인덱스를 단순 파일 복사로 동시에 동기화하면 충돌할 수 있습니다. 원문 이벤트를 기준으로 동기화하고 각 기기에서 색인을 재생성하는 방식처럼 쓰기 규칙이 필요합니다.
  • 저장량과 삭제: 원문, 임베딩, 메타데이터가 함께 증가합니다. 특정 사람이나 프로젝트를 삭제할 때 원문뿐 아니라 벡터, 그래프, 로그와 백업의 잔존 데이터도 다뤄야 합니다.
  • 로컬 저장과 외부 추론: 저장소가 로컬이어도 임베딩이나 답변 모델이 외부 API라면 선택된 원문이 네트워크를 떠날 수 있습니다. 실제 호출 경로를 관찰하고 민감 영역의 허용 모델을 정해야 합니다.

도입 판단은 작은 읽기 전용 평가로 시작한다

짧고 종료가 분명한 작업에는 잘 관리한 프로젝트 문서가 더 단순할 수 있습니다. 반면 수개월 동안 의사결정이 누적되고 여러 AI 도구를 오가며 같은 배경을 반복 설명하는 환경에서는 작은 시험 가치가 있습니다. 민감도가 낮은 한 프로젝트와 읽기 전용 MCP 연결로 시작해 검색 근거를 사람이 확인합니다.

2~4주 동안 검색 성공률, 잘못된 최신성 판단, 저장 증가량, 백업, 복구 시간과 실제로 줄어든 재설명 시간을 기록합니다. 결론적으로 MemPalace의 흥미로운 지점은 “요약을 없앤다”는 구호가 아니라 원문과 검색용 표현을 분리한다는 설계입니다. 정확한 출처, 시간 충돌 처리, 권한과 삭제가 계층 구조만큼 중요합니다.

원문과 버전 확인

함께 읽으면 이해가 이어지는 글

자주 묻는 질문

대화 원문을 모두 저장하면 AI가 정확히 기억하게 되나요?

아닙니다. 원문 보존은 정보 손실을 줄이지만, 질문에 맞는 기록을 찾고 시점과 출처를 구분하는 검색 품질은 별도로 검증해야 합니다.

로컬에 저장하면 대화가 외부로 전송되지 않나요?

저장소가 로컬이라는 뜻일 뿐 임베딩, 응답 모델까지 로컬이라는 보장은 없습니다. 실제 모델 호출 경로와 로그 정책을 함께 확인해야 합니다.

MemPalace는 어떤 팀에 먼저 시험해 볼 만한가요?

오래 이어지는 의사결정 기록을 자주 되찾고, 로컬 데이터베이스의 백업, 삭제, 권한을 직접 운영할 수 있는 작은 팀이나 개인 프로젝트에 적합합니다.

THE END / OPSOAI

여기까지 읽었습니다

핵심 장면을 한 번 더 떠올려 보세요. 이해가 남았다면 이 책은 제 역할을 다했습니다.

다른 책 고르기
표지 1 —

←→ 키와 좌우 스와이프를 지원합니다. 읽던 페이지는 이 기기에 저장됩니다.

CONTENTS

이 책의 목차

    9개 장 19 분읽는 시간