에이전트 메모리 프로바이더 비교: 캡처 정책과 셀프 호스팅

2026년 9월 업데이트: Mnemosyne 및 Memori 추가, Honcho와 Hindsight 설정 확장, 기존 인프라 표와 함께 캡처 정책 비교표 추가.

컨텍스트 윈도우를 벗어나는 어떤 것도 영속화되지 않는 한, 최신 어시스턴트는 탭을 닫으면 모든 것을 잊게 됩니다. Agent memory providers(에이전트 메모리 제공자) 는 세션 간에 사실과 요약을 유지하는 서비스 또는 라이브러리이며, 프레임워크는 가볍게 유지하면서 메모리가 확장되도록 플러그인 형태로 연결되는 경우가 많습니다.

이 가이드는 Hermes Agent 외부 메모리 플러그인으로 제공되는 메모리 백엔드 — Honcho, OpenViking, Mem0, Hindsight, Holographic, RetainDB, ByteRover, Supermemory, Mnemosyne, Memori — 를 비교하고, 이들이 더 넓은 AI 시스템 스택에 어떻게 통합되는지 설명합니다. 같은 벤더들은 커뮤니티 또는 공식 통합을 통해 OpenClaw 및 기타 에이전트 툴링에도 등장합니다. AI Systems Memory 허브 에는 이 기사가 Cognee 및 관련 가이드와 함께 나열되어 있습니다.

Hermes 특유의 바운디드 코어 메모리(MEMORY.md와 USER.md), 고정 동작, 트리거에 대해서는 Hermes Agent 메모리 시스템 을 참고하세요. Hermes의 네이티브 메모리 제공자가 OpenClaw 대비 성장하는 채택 우위에 어떻게 기여하는지에 대한 맥락 — GitHub 스타 수, OpenRouter 토큰 순위, 생태계 규모 비교를 포함 — 에 대해서는 OpenClaw vs Hermes Agent: Stars, Downloads & Usage 2026를 참고하세요.

검색 품질만큼이나 중요한 또 다른 축이 있습니다: 메모리 거버넌스. 제공자들이 자동적으로 무엇을 캡처하는지, 어시스턴트가 생성한 출력이 영속적 메모리가 될 수 있는지, 반성(reflections)이 사실로 저장되는지, 모순이 어떻게 해결되는지, 그리고 인간이 쓰기가 미래 컨텍스트가 되기 전에 검토할 수 있는지에 따라 극단적으로 다릅니다. 장기 실행되는 에이전트들에게는 이러한 차이가 리콜 벤치마크의 몇 점 차이가 더 중요할 수 있습니다 — 자동 캡처가 생성된 결론을 미래의 전제로 바꾸는 이유에 대해서는 AI 에이전트의 자기 강화 메모리 루프를 참고하고, 보수적인 구성 사례에 대해서는 Mnemosyne for Hermes Agent: Local Memory Quickstart를 참고하세요.

Hermes Agent는 영구적이고 세션 간 지식을 위한 10개의 외부 메모리 제공자 플러그인을 나열합니다 — 원래의 8개에 Mnemosyne와 Memori가 추가된 것입니다. 동시에 활성화될 수 있는 외부 제공자는 하나뿐입니다. 내장된 MEMORY.md와 USER.md는 함께 유지됩니다 — 대체가 아닌 부가적 역할입니다.

외부 의존성. Holographic를 제외한 모든 외부 제공자는 최소 한 개의 외부 서비스 호출이 필요합니다 — 메모리 추출용 LLM, 시맨틱 검색용 임베딩 모델, 또는 PostgreSQL과 같은 데이터베이스. 이러한 의존성은 프라이버시, 비용, 그리고 메모리 스택이 완전히 자가 호스팅될 수 있는지 여부에 직접적인 영향을 미칩니다. Hindsight, ByteRover, Mnemosyne은 가장 많은 의존성을 번들링하거나 제거하며, Honcho, Mem0, Supermemory는 가장 많은 컴포넌트가 필요합니다. 제공자가 Ollama 또는 OpenAI 호환 엔드포인트를 지원하는 경우, LLM 및 임베딩 호출을 로컬 모델로 라우팅하여 데이터를 완전히 서드파티 서버에서 멀리 둘 수 있습니다.

Hermes Agent와 함께 활성화하기

아래 명령어 단계를 Hermes Agent CLI 치트시트의 표와 동일하게 구성했습니다.

hermes memory setup   # 인터랙티브 선택기 + 구성
hermes memory status  # 활성 상태 확인
hermes memory off     # 외부 제공자 비활성화

또는 ~/.hermes/config.yaml에서 수동으로:

memory:
  provider: openviking  # 또는 honcho, mem0, hindsight, holographic, retaindb, byterover, supermemory, mnemosyne, memori

제공자 비교

캡처 정책 및 거버넌스

저장과 의존성은 “이것을 실행할 수 있는가?“라는 질문에 답합니다. 아래 표는 장기 실행 에이전트에게 그만큼 중요한 또 다른 질문에 답합니다: 요청하지 않아도 무엇이 기록되는가, 그리고 그것이 영구적이 되기 전에 인간 또는 정책이 개입할 수 있는가? 이 축이 왜 중요한지 AI 에이전트의 자기 강화 메모리 루프를 참고하세요.

이는 품질 점수가 아닌 아키텍처 리스크 범주입니다 — 주의 깊게 구성된 정교한 제공자가 제대로 구성되지 않은 단순한 제공자보다 실제로 더 안전할 수 있습니다.

상세 분석

Honcho

최적 용도: 멀티 에이전트 시스템, 세션 간 컨텍스트, 사용자-에이전트 정렬.

Honcho는 기존 메모리와 함께 실행됩니다 — USER.md는 그대로 유지되고, Honcho는 추가 컨텍스트 계층을 제공합니다. 대화를 메시지를 주고받는 피어(peers)로 모델링합니다 — Hermes 프로필당 사용자 피어 1명과 AI 피어 1명으로, 모두 워크스페이스를 공유합니다.

외부 의존성: Honcho는 세션 요약, 사용자 표현 유도, 변증법적 추론을 위해 LLM이 필요하며, 관찰을跨越하는 시맨틱 검색을 위해 임베딩 모델, 벡터 저장을 위해 pgvector 확장된 PostgreSQL, 캐싱을 위해 Redis가 필요합니다. api.honcho.dev의 관리형 클라우드는 이 모든 것을 처리해 줍니다. 자가 호스팅 배포(Docker, K3s, 또는 Fly.io)의 경우, 자신의 자격 증명을 제공해야 합니다. LLM 슬롯은 Ollama와 vLLM을 포함한 OpenAI 호환 엔드포인트를 모두 수용하므로, 추론을 온프레미스로 유지할 수 있습니다. 임베딩 슬롯은 기본적으로 openai/text-embedding-3-small을 사용하지만 LLM_EMBEDDING_API_KEY와 LLM_EMBEDDING_BASE_URL을 통해 구성 가능한 제공자를 지원합니다 — BGE 모델과 함께 vLLM과 같은 로컬 옵션을 포함한 OpenAI 호환 임베딩 서버라면 모두 작동합니다.

도구: honcho_profile (피어 카드 읽기/업데이트), honcho_search (시맨틱 검색), honcho_context (세션 컨텍스트 — 요약, 표현, 카드, 메시지), honcho_reasoning (LLM 종합), honcho_conclude (결론 생성/삭제).

주요 구성 항목:

• contextCadence (기본값 1): 베이스 레이어 새로고침 사이의 최소 턴 수
• dialecticCadence (기본값 2): peer.chat() LLM 호출 사이의 최소 턴 수 (1-5 권장)
• dialecticDepth (기본값 1): 호출당 .chat() 패스 (1-3로 제한)
• recallMode (기본값 ‘hybrid’): hybrid (자동+도구), context (주입만), tools (도구만)
• writeFrequency (기본값 ‘async’): 플러시 타이밍: async, turn, session, 또는 정수 N
• observationMode (기본값 ‘directional’): directional (모든 것 켜짐) 또는 unified (공유 풀)

관찰 모드와 자체 모델링. 새 구성의 기본값인 directional은 사용자 피어와 AI 피어가 모두 자신과 서로를 관찰할 수 있게 합니다 — 더 풍부한 변증법적 추론이지만, AI가 쓴 메시지가 Honcho의 AI 자체 모델에 기여한다는 뜻이기도 합니다. unified는 더 보수적인 옵션입니다: AI는 사용자 메시지로부터 사용자를 모델링하지만, 자신의 출력으로부터 일치하는 자체 관찰 루프를 구축하지 않습니다. 생성된 결론이 미래 추론에 피드백되는 것에 대해 특별히 우려하는 경우 — AI 에이전트의 자기 강화 메모리 루프 참고 — unified를 더 안전한 기본값으로 취급해야 합니다.

아키텍처: 2층 컨텍스트 주입 — 베이스 레이어 (세션 요약 + 표현 + 피어 카드) + 변증법적 보충 (LLM 추론). 콜드 스타트와 워밍 프롬프트를 자동 선택합니다.

멀티 피어 매핑: 워크스페이스는 프로필 간에 공유되는 환경입니다. 사용자 피어(peerName)는 전역 인간 정체성입니다. AI 피어(aiPeer)는 Hermes 프로필당 하나입니다 (hermes 기본값, 다른 것은 hermes.<profile>).

설정:

hermes memory setup  # "honcho" 선택
# 또는 레거시: hermes honcho setup

구성: $HERMES_HOME/honcho.json (프로필 로컬) 또는 ~/.honcho/config.json (전역).

프로필 관리:

hermes profile create coder --clone  # 공유 워크스페이스와 hermes.coder 생성
hermes honcho sync                   # 기존 프로필의 AI 피어 백필

OpenViking

최적 용도: 구조화된 브라우징을 통한 자가 호스팅 지식 관리.

OpenViking은 단계적 로딩이 있는 파일시스템 계층 구조를 제공합니다. 무료이며, 자가 호스팅되어 메모리 저장소에 대한 완전한 제어를 제공합니다.

외부 의존성: OpenViking은 시맨틱 처리와 메모리 추출을 위해 VLM(비전-언어 모델)과 벡터 검색을 위해 임베딩 모델이 필요합니다 — 둘 다 필수입니다. 지원되는 VLM 제공자에는 OpenAI, Anthropic, DeepSeek, Gemini, Moonshot, vLLM(로컬 배포를 위해)이 포함됩니다. 임베딩의 경우, 지원되는 제공자에는 OpenAI, Volcengine (Doubao), Jina, Voyage, 그리고 Ollama를 통한 로컬 제공 임베딩 모델이 포함됩니다. openviking-server init 인터랙티브 마법사는 사용 가능한 RAM을 감지하고 적합한 Ollama 모델을 추천할 수 있습니다 (예: 임베딩용 Qwen3-Embedding 8B, VLM용 Gemma 4 27B) 그리고 완전 로컬, 제로-API-키 설정을 위해 모든 것을 자동으로 구성합니다. 외부 데이터베이스는 필요하지 않으며, OpenViking은 파일시스템에 메모리를 저장합니다.

도구: viking_search, viking_read (단계적), viking_browse, viking_remember, viking_add_resource.

사용자 메모리와 에이전트 메모리. OpenViking의 정체성 모델은 사용자의 메모리 네임스페이스와 선택적 어시스턴트 피어를 분리할 수 있습니다. 이러한 분리는 메모리 위생에 중요합니다: 사용자에 대한 사실과 에이전트가 생성한 경험은 동일한 보존 정책을 공유할 필요가 없으며, 이는 어시스턴트가 작성한 상태를 사용자가 작성한 상태와 격리하려는 경우 유용한 특성입니다.

설정:

pip install openviking
openviking-server init   # 인터랙티브 마법사 (로컬 설정용 Ollama 모델 추천)
openviking-server
hermes memory setup  # "openviking" 선택
echo "OPENVIKING_ENDPOINT=http://localhost:1933" >> ~/.hermes/.env

Mem0

최적 용도: 자동 추출을 통한 손쉬운 메모리 관리.

Mem0은 모든 add 작업에서 LLM 호출을 통해 서버 측에서 메모리 추출을 처리합니다 — 대화를 읽고, 개별 사실을 추출하고, 중복을 제거하며, 저장합니다. 관리형 클라우드 API가 모든 인프라를 처리합니다. 오픈소스 라이브러리와 자가 호스팅 서버는 완전한 제어를 제공합니다.

외부 의존성: Mem0는 메모리 추출을 위해 LLM이 필요하며 (기본값: OpenAI gpt-4.1-nano; Ollama, vLLM, LM Studio(로컬 모델을 위해)를 포함한 20개 제공자 지원), 검색을 위해 임베딩 모델이 필요합니다 (기본값: OpenAI text-embedding-3-small; Ollama와 HuggingFace(로컬 모델을 위해)를 포함한 10개 제공자 지원). 저장은 라이브러리 모드에서 /tmp/qdrant의 Qdrant, 자가 호스팅 서버 모드에서 pgvector가 있는 PostgreSQL을 사용하며 — 둘 다 로컬에서 실행할 수 있습니다. 완전 로컬, 제로-클라우드 Mem0 스택은 달성 가능합니다: LLM용 Ollama, 임베딩용 Ollama, 로컬 Qdrant 인스턴스, 모두 Memory.from_config를 통해 구성됩니다.

Mem0는 근본적으로 추출 시스템입니다: LLM이 대화 자료를 개별 메모리로 변환하고 중복 제거 및 업데이트 로직을 수행합니다. 이는 편리하지만, 추출의 출처가 중요하다는 뜻입니다 — 캡처 경로가 추출 실행 전에 이를 필터링하지 않는 한, 생성된 어시스턴트 결론은 사용자가 진술한 사실과 구조적으로 구별될 수 없습니다.

도구: mem0_profile, mem0_search, mem0_conclude.

설정:

pip install mem0ai
hermes memory setup  # "mem0" 선택
echo "MEM0_API_KEY=your-key" >> ~/.hermes/.env

구성: $HERMES_HOME/mem0.json (user_id: hermes-user, agent_id: hermes).

Hindsight

최적 용도: 엔티티 관계를 가진 지식 그래프 기반 리콜.

Hindsight는 메모리의 지식 그래프를 구축하며, 엔티티와 관계를 추출합니다. 그 독특한 reflect 도구는 메모리 간 종합을 수행합니다 — 여러 메모리를 결합하여 새로운 통찰력을 만듭니다. 리콜은 4개의 검색 전략(시맨틱, 키워드/BM25, 그래프 탐색, 시간)을 병렬로 실행한 후, 상호 역순위 융합을 사용하여 결과를 병합하고 재정렬합니다.

외부 의존성: Hindsight는 retain 호출 시 사실과 엔티티 추출, reflect 호출 시 종합을 위해 LLM이 필요합니다 (기본값: OpenAI; 지원되는 제공자에는 Anthropic, Gemini, Groq, Ollama, LM Studio, OpenAI 호환 엔드포인트 포함). 임베딩 모델과 크로스-엔코더 리랭킹 모델은 Hindsight 자체에 번들링되어 있습니다 — hindsight-all 패키지 내에서 로컬로 실행되며 외부 API가 필요하지 않습니다. PostgreSQL은 임베디드 Python 설치 시 관리되는 pg0 데이터 디렉토리를 통해 번들링됩니다; 또는 외부 PostgreSQL 인스턴스를 Hindsight에 가리키도록 할 수 있습니다. 완전 로컬, 제로-클라우드 설정을 위해 HINDSIGHT_API_LLM_PROVIDER=ollama를 설정하고 로컬 Ollama 모델에 가리키세요 — retain과 recall은 완전히 작동하며, reflect는 도구 호출이 가능한 모델(예: qwen3:8b)이 필요합니다.

도구: hindsight_retain, hindsight_recall, hindsight_reflect (고유한 메모리 간 종합).

설정:

hermes memory setup  # "hindsight" 선택
echo "HINDSIGHT_API_KEY=your-key" >> ~/.hermes/.env

hindsight-client (클라우드) 또는 hindsight-all (로컬)을 자동 설치합니다. >= 0.4.22 필요.

구성: $HERMES_HOME/hindsight/config.json

• mode: cloud 또는 local
• recall_budget: low / mid / high
• memory_mode: hybrid / context / tools
• auto_retain / auto_recall: true (기본값)

로컬 UI: hindsight-embed -p hermes ui start

보수적인 메모리 위생을 위해, auto_recall=true를 유지하면서 auto_retain=false를 설정하는 것은 고려해 볼 만합니다 — 시맨틱 리콜은 여전히 사용 가능하지만, 완료된 턴은 더 이상 자동으로 장기 메모리에 들어가지 않습니다. reflect 출력은 독립적인 관찰이 아니라 메모리 전체를 통해 종합된 유도된 지식으로 취급하며, 그것들을 기반으로 한 메모리와 동일한 증거적 가중치를 갖지 않습니다.

Holographic

최적 용도: 로컬 전용 저장을 가진 프라이버시 우선 설정.

Holographic은 메모리 인코딩을 위해 HRR(홀로그래픽 리듀스드 리프레젠테이션) 대수를 사용하며, 메모리 신뢰도를 위해 신뢰도 평가를 사용합니다. 클라우드 의존성 없음 — 모든 것이 자신의 하드웨어에서 로컬로 실행됩니다.

외부 의존성: 없음. Holographic은 LLM, 임베딩 모델, 데이터베이스, 네트워크 연결이 필요하지 않습니다. 메모리 인코딩은 프로세스 내에서 실행되는 HRR 대수를 통해 완전히 수행됩니다. 이는 이 비교의 모든 제공자 중 독특합니다 — 제로 외부 호출로 작동하는 유일한 제공자입니다. 트레이드오프는 리콜 품질이 임베딩 기반 시맨틱 검색보다 낮고, Hindsight의 reflect 같은 메모리 간 종합이 없다는 것입니다. 프라이버시와 제로-의존성 작동이 불가결한 사용자를 위해, Holographic은 이를 조건 없이 제공하는 유일한 옵션입니다.

auto_extract는 기본적으로 false이므로, Holographic은 자율적인 전사-메모리 파이프라인이 아니라 신뢰도 점수가 있는 작은 명시적 사실 데이터베이스로 주로 작동할 수 있습니다. 제로 의존성과 결합하면, 이는 자동 캡처를 의도적으로 원하지 않는 독자를 위해 Mnemosyne와 함께 가장 간단한 옵션 중 하나가 됩니다.

도구: HRR 대수를 통한 메모리 작업용 2개 도구.

설정:

hermes memory setup  # "holographic" 선택

RetainDB

최적 용도: 델타 압축을 통한 고빈도 업데이트.

RetainDB는 델타 압축을 사용하여 메모리 업데이트를 효율적으로 저장하고, 하이브리드 검색(벡터 + BM25 + 리랭킹)을 사용하여 관련 컨텍스트를 표출합니다. $20/월 비용의 클라우드 기반이며, 모든 메모리 처리는 서버 측에서 처리됩니다.

외부 의존성: RetainDB의 LLM 호출, 임베딩 파이프라인, 리랭킹은 모두 RetainDB의 자체 클라우드 인프라에서 실행됩니다 — 당신은 RETAINDB_KEY만 제공합니다. 메모리 추출은 서버 측에서 Claude Sonnet을 사용합니다. 자가 호스팅 옵션이 없고 로컬 모드가 없습니다. 모든 대화 데이터는 처리와 저장을 위해 RetainDB 서버로 전송됩니다. 데이터 주권 또는 오프라인 작동이 사용 사례에서 중요한 경우, 이 제공자는 적합하지 않습니다.

도구: retaindb_profile (사용자 프로필), retaindb_search (시맨틱 검색), retaindb_context (작업 관련 컨텍스트), retaindb_remember (유형 + 중요도로 저장), retaindb_forget (메모리 삭제).

RetainDB의 Hermes 통합은 원격 메모리 데이터베이스를 넘어 성장했습니다 — 이제 변증법적 종합과 에이전트 자체 모델이 포함되어, 이는 간단한 벡터 저장소보다 Honcho에 아키텍처적으로 더 가깝게 만듭니다. 이는 연속성에 유용하지만, Honcho의 directional 모드에 적용되는 것과 동일한 우려처럼 출처 사실과 생성된 해석을 분리하는 중요성도 높입니다.

설정:

hermes memory setup  # "retaindb" 선택

Mnemosyne

최적 용도: 세분화된 보존 제어, 검사 가능한 SQLite 저장소, 구조화된 사실, 시간 메모리, 구성 가능한 통합을 가진 로컬 우선 메모리.

Mnemosyne은 Hermes의 원래 번들 메모리 제공자가 아닙니다 — 별도 Hermes 제공자 플러그인으로 출시되지만 동일한 MemoryProvider 인터페이스를 통해 통합됩니다. 그 주요 이점은 제어입니다: 대화 자동 저장은 sync_roles: []을 통해 역할로 제한하거나 완전히 비활성화할 수 있으며, 도구 결과 로깅은 기본적으로 꺼져 있고, 명시적 remember/recall/forget 조작은 항상 사용 가능하며, 최신 버전에는 컨텍스트 압축 경계 주변의 선택적 자체 에코 억제 기능이 포함됩니다.

외부 의존성: core 설치에는 없음; embeddings 추가 항목은 로컬 벡터 검색을 추가합니다. 저장은 FTS5와 선택적 벡터 검색이 있는 로컬 SQLite입니다. 시스템은 또한 워킹 메모리, 에피소딕 메모리, 구조화된 사실, 시간 삼중항, 정규화 사실, 통합을 유지합니다.

Mnemosyne는 또한 Hermes memory.write_approval을 위한 제공자별 단계적 쓰기를 구현하지만, 외부 제공자 승인은 아직 Hermes 전체에서 표준화되지 않았으므로, 이 경로는 배포되는 정확한 버전으로 테스트되어야 합니다. 추가적인 정교함에는 비용이 있습니다: 유도된 메모리는 검사하고 정리해야 할 더 많은 라이프사이클 상태를 생성합니다. 최근 Mnemosyne 릴리스는 충돌 검증, 삭제 동작, 자체 에코 처리를 특별히 강화했습니다 — 충돌 검증 변경을 동기로 한 프로덕션 감사에 대해서는 AI 에이전트의 자기 강화 메모리 루프를 참고하세요.

설정:

python -m pip install "mnemosyne-memory[embeddings]" mnemosyne-hermes
mnemosyne-hermes install
hermes config set memory.provider mnemosyne

완전한 설치와 보수적인 구성 워크스루에 대해서는 Mnemosyne for Hermes Agent: Local Memory Quickstart를 참고하세요.

Memori

최적 용도: 실행 이력이 대화 이력과만큼 중요한 에이전트.

Memori는 도구 인식 구조화 메모리에 초점을 맞춘 더 새로운 Hermes 통합입니다. 사용 가능한 실행 컨텍스트 — 도구 사용, 워크플로우 단계, 결정, 결과, 제약 — 와 함께 완료된 턴을 캡처합니다. 이는 운영 작업 기억에 매우 적합하지만, 모든 동작, 모델 결정, 도구 결과가 영구적 구조화 메모리가 될 수 있으므로 더 큰 피드백 표면도 생성합니다.

주로 매 턴 전에 큰 메모리 블록을 주입하는 제공자와 달리, Memori는 명시적인 리콜과 리콜-요약 도구를 노출하여, 에이전트가 모든 프롬프트가 아닌 실제로 필요할 때 운영 컨텍스트를 검색할 수 있게 합니다. 이는 프롬프트 오염을 줄이지만, 쓰기 측 피드백 위험을 자체적으로 제거하지는 않습니다 — 완료된 턴과 실행 추적은 여전히 백그라운드에서 자동으로 캡처될 수 있으므로, Memori는 엄격한 명시적 전용 보존을 요구하는 설치보다는 이전 작업에서 배우는 에이전트를 원하는 사용자에게 더 적합합니다.

설정:

pip install hermes-memori
hermes memory setup  # "memori" 선택

ByteRover

최적 용도: 인간이 읽을 수 있고, 감사 가능한 저장을 가진 로컬 우선 메모리.

ByteRover는 임베딩 벡터 또는 데이터베이스가 아니라, 도메인, 주제, 하위 주제 파일의 계층 구조인 구조화된 마크다운 컨텍스트 트리로 메모리를 저장합니다. LLM이 소스 콘텐츠를 읽고, 추론하고, 추출된 지식을 계층 구조의 올바른 위치에 배치합니다. 검색은 단계적 LLM 기반 검색으로 폴백되는 MiniSearch 전체 텍스트 검색이며, 벡터 데이터베이스가 필요하지 않습니다.

외부 의존성: ByteRover는 메모리 큐레이션과 검색을 위해 LLM이 필요합니다 (Anthropic, OpenAI, Google, Ollama, openai-compatible 제공자 슬롯을 통한 OpenAI 호환 엔드포인트를 포함한 18개 제공자 지원). 임베딩 모델과 데이터베이스가 필요하지 않으며 — 컨텍스트 트리는 평범한 마크다운 파일의 로컬 디렉토리입니다. 클라우드 동기화는 선택적이며 팀 협업에만 사용되며, 기본적으로 모든 것이 완전 오프라인으로 작동합니다. 완전 자가-contained 로컬 설정을 위해, Ollama를 제공자로 연결하세요 (brv providers connect openai-compatible --base-url http://localhost:11434/v1) 그리고 데이터가 기계를 떠나지 않습니다.

Hermes는 자동 큐레이션 훅을 비활성화하기 위해 auto_extract: false를 노출하며, 이는 ByteRover를 자동 캡처가 기본값이 아닌 옵트인인 제공자의 그룹인 Holographic과 Mnemosyne와 가깝게 만듭니다.

도구: 메모리 작업용 3개 도구.

설정:

hermes memory setup  # "byterover" 선택

Supermemory

최적 용도: 컨텍스트 펜싱과 세션 그래프 수집을 가진 엔터프라이즈 워크플로우.

Supermemory는 컨텍스트 펜싱(컨텍스트로 메모리 격리)과 세션 그래프 수집(전체 대화 역사 가져오기)을 제공합니다. 메모리를 자동 추출하고, 사용자 프로필을 구축하며, 시맨틱과 키워드 검색을 결합한 하이브리드 검색을 실행합니다. 관리형 클라우드 API가 주요 배포 대상입니다.

외부 의존성: Supermemory의 클라우드 서비스는 모든 LLM 추론과 임베딩을 서버 측에서 처리합니다 — Supermemory API 키만 제공합니다. 자가 호스팅은 엔터프라이즈 플랜 추가 항목으로만 사용 가능하며 Cloudflare Workers에 배포됩니다; pgvector 확장이 있는 PostgreSQL(벡터 저장을 위해)과 OpenAI API 키(필수, Anthropic과 Gemini는 선택적 추가)를 제공해야 합니다. Docker 기반 또는 로컬 자가 호스팅 경로는 없으며 — 아키텍처는 Cloudflare Workers 엣지 컴퓨팅에 긴밀하게 결합되어 있습니다. 엔터프라이즈 계약 없이 완전한 데이터 주권이 필요한 사용자에게, 이 제공자는 올바른 선택이 아닙니다.

현재 Hermes 통합은 Supermemory의 대화 엔드포인트를 통해 전체 세션을 단위로 쓰며, 대화를 버퍼링하고 세션 종료, 리셋, 또는 압축 시 수집합니다. 이는 격리된 사실 쓰기보다 더 풍부한 엔티티와 프로필 컨텍스트를 생성하지만, 생성된 어시스턴트 텍스트가 메모리 추출 파이프라인에 제시되는 자료의 일부이며 사용자 진술만이 아니라는 뜻이기도 합니다.

도구: 메모리 작업용 4개 도구.

설정:

hermes memory setup  # "supermemory" 선택

선택하는 방법

한 가지 글로벌 승자를 고르기보다, 제공자를 작업에 맞춰 보세요:

• 가장 단순한 로컬 명시적 메모리: Holographic — 제로 의존성, auto_extract 기본값 꺼짐
• 더 풍부한 라이프사이클 제어를 가진 로컬 메모리: Mnemosyne — SQLite, 세분화된 보존, 자체 에코 억제
• 그래프 중심 종합: Hindsight — 지식 그래프 + reflect
• 피어 또는 사용자 모델링: Honcho — 변증법적 추론, 보수적 자체 모델링을 위한 unified 모드
• 파일시스템 스타일 지식: OpenViking — 단계적 viking:// 계층 구조
• 손쉬운 자동 추출: Mem0 — 제로-구성 LLM 기반 사실 추출
• 운영/도구 인식 메모리: Memori — 턴과 실행 추적 캡처
• 인간이 읽을 수 있고, 감사 가능하며, 임베딩 파이프라인 없음: ByteRover — 평범한 마크다운 컨텍스트 트리
• 엔터프라이즈 컨텍스트 펜싱: Supermemory — 세션 그래프 수집, Cloudflare 호스팅
• 고빈도 업데이트, 자가 호스팅 불필요: RetainDB — 델타 압축, 변증법적 자체 모델

프로파일별 제공자 구성과 실제 워크플로우 패턴에 대해서는 Hermes Agent 프로덕션 설정을 참고하세요.

더 넓은 서드파티 Hermes 메모리 생태계

Hermes는 사용자 설치 디렉토리와 Python 엔트리 포인트를 포함한 외부 메모리 제공자를 위한 패키지/플러그인 인터페이스를 문서화하므로, 생태계는 이제 위의 전체 섹션을 가진 제공자를 넘어 확장되었습니다. 각기 전체 섹션을 추가하지 않고도 알아두면 좋은 몇 가지가 있습니다:

• Scope Recall은 SQLite를 영속적 진실로 취급하면서 원시 대화 캡처는 별도로 범위를 지정하여 유지하며, 보수적인 턴 후 검사를 위한 선택적 turn-closure-audit 동반 기능이 있습니다 — 즉시 등가 장기 지식으로 모든 캡처된 턴을 취급하는 대신, 원시 저널 증거와 영속적 시맨틱 메모리를 분리합니다.
• Cognee는 Hermes 대화 메모리 플러그인이 아니라 지식 그래프 / ECL 수집 파이프라인입니다. 구조화된 프로젝트 또는 기관 메모리에 뛰어남 하지만 명시적 사실 저장소보다 더 자동적입니다; Cognee 자가 호스팅 퀵스타트와 Cognee를 위한 올바른 LLM 선택를 참고하고, 드롭-인 Hermes 제공자로 취급하지 마세요.
• AgentMemory는 소스 이벤트, 감사 가능성, 삭제 의미론을 강조합니다 — 위에서 논의된 Mnemosyne의 고아 유도 레코드 문제 후 관련성이 있습니다.
• XMemo는 보수적인 기본값을 출시합니다: 자동 타임라인 캡처는 꺼진 상태로 유지할 수 있으며, 삭제는 제한될 수 있습니다. 채택은 아직 전체 섹션을 정당화할 정도로 초기 단계입니다.

관련 가이드

• AI Systems Memory 허브 — 이 서브클러스터의 범위와 Cognee 가이드에 대한 링크
• AI 에이전트의 자기 강화 메모리 루프 — 캡처 정책과 승인 게이트가 왜 중요한지, 심층적으로
• Mnemosyne for Hermes Agent: Local Memory Quickstart — 위에서 다룬 Mnemosyne 제공자를 위한 완전한 설치와 보수적 구성
• Hermes Agent 메모리 시스템 — 플러그인 이전의 핵심 2-파일 메모리
• Hermes Agent 프로덕션 설정 — 실제에서의 제공자 프로파일 배선