MCP

Dense-Mem 셀프 호스팅 MCP 메모리 서버 첫 사용 가이드

Dense-Mem은 AI 에이전트에 셀프 호스팅 방식의 추적 가능한 장기 기억을 붙이고 PostgreSQL 운영을 감수할 팀에 적합하다. 다만 시작하기 전에 AI 공급자 환경변수 다섯 개를 모두 갖춰야 하며, 증거 텍스트·proposal 컨텍스트·recall 쿼리는 설정한 공급자로 전송된다. 이 트래픽을 자신의 경계 안에 두려면 공급자를 직접 호스팅하는 수밖에 없다.

Official source · Dense-Mem

Install

curl -fsSLo docker-compose.yml \
  https://raw.githubusercontent.com/markhuangai/dense-mem/main/examples/docker-compose.base.yml
curl -fsSLo .env.example \
  https://raw.githubusercontent.com/markhuangai/dense-mem/main/examples/.env.example

cp .env.example .env
# Fill in POSTGRES_PASSWORD, CONTROL_PORTAL_TOKEN, and AI_API_KEY.
${EDITOR:-vi} .env

docker compose up -d

누구에게 맞나

Dense-Mem은 AI 에이전트에 셀프 호스팅 장기 기억을 붙이고 PostgreSQL과 Redis를 함께 운영할 의향이 있는 개발자나 팀에 맞다. 세션에 임시 컨텍스트만 얹고 데이터베이스 운영은 피하고 싶다면 어울리지 않는다. 기억 자동화 계약은 MCP(Streamable HTTP, 엔드포인트 /mcp)로 외부에 제공된다. 먼저 정확한 증거를 스테이징하고, 서버 쪽에서 검증된 정책으로 의미 상태를 도출한 뒤, 활성 증거 컨텍스트와 그래프형 Relationship 핸들을 돌려준다. 지식·수명 주기·출처 추적·검색·권한·감사의 영구 권위는 모두 PostgreSQL이고 Redis는 조정 전용이다. 브라우저 라우트는 퍼스트파티 인터페이스일 뿐 외부 자동화 입구가 아니다.

사용 전제와 맞지 않는 경우:

  • 시작하려면 embedding과 verifier 두 AI 서비스 설정(아래 다섯 변수)을 모두 갖춰야 하며, 설정 없이 돌아가는 모드는 없다.
  • 사용 전에 알아야 할 데이터 유출 부작용: 증거 텍스트, proposal 컨텍스트, recall 쿼리는 설정한 공급자에게 전송된다. 공급자를 직접 호스팅하면 트래픽이 자신의 경계 안에 남고, 호스티드 서비스라면 그렇지 않다.
  • 공식 지원 MCP 클라이언트 목록, 리소스 요구사항, 운영 비용 근거는 제시되지 않아 확인되지 않았다.

3분 만에 첫 시험

전제: docker compose를 실행할 수 있는 머신. .env에 POSTGRES_PASSWORD, CONTROL_PORTAL_TOKEN, AI_API_KEY를 채운다. 시작에는 embedding과 verifier 설정 역시 완전해야 한다: AI_API_URL, AI_API_KEY, AI_API_EMBEDDING_MODEL, AI_API_EMBEDDING_DIMENSIONS, AI_VERIFIER_MODEL — 공식이 명시한 시작 전제이므로 선택 사항으로 여기면 안 된다.

알림: 조회형 첫 시험도 recall 쿼리를 설정한 공급자에게 보낸다.

공식 주 경로(Docker Compose):

curl -fsSLo docker-compose.yml \
  https://raw.githubusercontent.com/markhuangai/dense-mem/main/examples/docker-compose.base.yml
curl -fsSLo .env.example \
  https://raw.githubusercontent.com/markhuangai/dense-mem/main/examples/.env.example

cp .env.example .env
# Fill in POSTGRES_PASSWORD, CONTROL_PORTAL_TOKEN, and AI_API_KEY.
${EDITOR:-vi} .env

docker compose up -d

컨테이너가 뜬 뒤 MCP 클라이언트에서 /mcp에 연결한다. 첫 호출은 조회형인 recall_memory를 권한다. 공식 설명에 따르면 활성 증거 컨텍스트와 Relationship 핸들을 반환한다. 막 시작해 증거를 아직 쓰지 않은 인스턴스에서 무엇을 반환하는지는 근거에 없다. 성공 신호: docker compose up -d가 정상적으로 끝나고, 클라이언트가 /mcp로 서비스에 접근할 수 있는 것.

사용 사례

사례 1: 출처를 남기는 세션 간 기억을 에이전트에 만들어 준다. 장면: 에이전트가 세션에 걸친 사실을 기억하고 나중에 출처를 설명할 수 있어야 한다. 방법: remember로 증거를 쓰고, 이후 recall_memory로 활성 증거 컨텍스트를 불러 확인한다. remember의 매개변수와 입력 형식은 근거에 없어 "공식 증거 입력 입구"라는 점까지만 확인된다. 기대 결과: 증거가 받아들여지고 의미 상태는 서버 쪽 정책으로 도출된다.

사례 2: 관계가 어떻게 생겼는지 설명한다. 장면: 어떤 Relationship의 형성 과정을 다른 사람이나 하류 시스템에 보여준다. 방법: trace_memory를 호출한다. 공식 설명은 같은 팀의 한 Relationship을 따라 증거·의사결정·계보를 추적한다는 것. 매개변수와 반환 구조는 근거에 없어 "이런 조회 기능이 제공된다"까지만 확인하고 여기서 예시를 지어내지 않는다.

사용 경계

  • 읽기/쓰기 성격: remember는 증거를 쓴다. retract_evidence는 호출자 소유 증거를 철수시키며 append-only 출처를 보존한다. correct_relationship는 소유자만 가능한 활성 Relationship 교체(원래 관계를 대체하고 support lineage 보존)다. recall_memory, trace_memory, export_memory_pack은 조회/내보내기형이다. 공식은 도구별 읽기/쓰기 표시를 남기지 않아 조회류가 절대 쓰지 않는지는 확인되지 않았다.
  • 정정 경로는 위의 철수와 교체 두 가지뿐이며, 다른 쓰기는 취소 가능하다고 이해하면 안 된다.
  • 자격 증명과 데이터면: .env 필수 세 값 외에 실행은 PostgreSQL(영구), Redis(조정), 외부 AI 공급자에 의존한다. 증거 텍스트, proposal 컨텍스트, recall 쿼리는 공급자로 나가며 자신의 경계 안에 남는지는 배치 위치에 달려 있다.
  • 미확인: 기본 포트와 전체 URL, 데이터 보존·삭제 정책, 팀/테넌트 격리 의미론, CONTROL_PORTAL_TOKEN 외의 인증 세부사항.