에이전트 메모리 프로바이더 비교 — Honcho, Mem0, Hindsight 및 기타 5개

탭을 닫으면 컨텍스트 윈도우를 벗어나는 정보 외에는 현대적인 어시스턴트들이 모든 내용을 잊어버립니다. **에이전트 메모리 제공자(Agent memory providers)**는 세션 간에 사실과 요약을 유지하는 서비스 또는 라이브러리이며, 프레임워크는 가볍게 유지하면서 메모리 확장성을 위해 플러그인으로 연결되는 경우가 많습니다.

이 가이드는 Hermes Agent 외부 메모리 플러그인으로 제공되는 8가지 백엔드(Honcho, OpenViking, Mem0, Hindsight, Holographic, RetainDB, ByteRover, Supermemory)를 비교하고, 이들이 더 넓은 AI 시스템 스택에 어떻게 통합되는지 설명합니다. 동일한 벤더들은 커뮤니티 또는 공식 통합을 통해 OpenClaw 및 다른 에이전트 도구에서도 사용됩니다. **AI 시스템 메모리 허브**에서는 이 기사를 Cognee 및 관련 가이드와 함께 나열합니다.

Hermes의 고유한 유한 코어 메모리(MEMORY.md 및 USER.md), 고정(freezing) 동작, 그리고 트리거에 대해서는 **Hermes Agent 메모리 시스템**을 참조하십시오.

Hermes Agent는 영구적이고 세션 간 지식을 위해 8개의 외부 메모리 제공자 플러그인을 지원합니다. 동시에 하나의 외부 제공자만 활성화될 수 있습니다. 내장된 MEMORY.md와 USER.md는 이에 추가적으로 함께 로드되며, 대체되지 않습니다.

외부 의존성. Holographic을 제외한 모든 외부 제공자는 최소 하나의 외부 서비스 호출이 필요합니다. 예를 들어 메모리 추출을 위한 LLM, 시맨틱 검색을 위한 임베딩 모델, 또는 저장을 위한 PostgreSQL 데이터베이스 등이 해당됩니다. 이러한 의존성은 프라이버시, 비용, 그리고 메모리 스택이 완전히 자체 호스팅 될 수 있는지에 직접적인 영향을 미칩니다. Hindsight와 ByteRover는 가장 많은 의존성을 번들링하거나 제거하며, Honcho, Mem0, Supermemory는 가장 많은 구성 요소가 필요합니다. 제공자가 Ollama 또는 OpenAI 호환 엔드포인트를 지원한다면 LLM 및 임베딩 호출을 로컬 모델로 라우팅하여 데이터를 제3자 서버로 완전히 보내지 않을 수 있습니다.

Hermes Agent와의 활성화

hermes memory setup   # 인터랙티브 선택기 및 구성
hermes memory status  # 활성화된 항목 확인
hermes memory off     # 외부 제공자 비활성화

또는 ~/.hermes/config.yaml에서 수동으로 설정할 수 있습니다:

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

제공자 비교

상세 분석

Honcho

적합한 분야: 다중 에이전트 시스템, 세션 간 컨텍스트, 사용자-에이전트 정렬.

Honcho는 기존 메모리와 함께 작동합니다 — USER.md는 그대로 유지되며 Honcho는 추가적인 컨텍스트 계층을 제공합니다. 대화는 메시지를 교환하는 동료(peers)로 모델링됩니다 — Hermes 프로필당 하나의 사용자 동료와 하나의 AI 동료가 워크스페이스를 공유합니다.

외부 의존성: 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 (공유 풀)

아키텍처: 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.

설정:

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, 로컬 Qdrance 인스턴스 모두 Memory.from_config를 통해 구성됩니다.

도구: 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은 관리되는 pg0 데이터 디렉토리를 통해 임베디드 Python 설치와 함께 번들링됩니다; 외부 PostgreSQL 인스턴스를 가리킬 수도 있습니다. 완전 로컬의 제로 클라우드 설정을 위해 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

Holographic

적합한 분야: 프라이버시에 초점을 맞춘 설정, 로컬만 저장.

Holographic은 메모리 인코딩을 위해 HRR(Holographic Reduced Representation) 대수학을 사용하며, 메모리 신뢰도를 위해 신뢰도 점수를 사용합니다. 클라우드 의존성이 없습니다 — 모든 것이 자체 하드웨어에서 로컬로 실행됩니다.

외부 의존성: 없음. Holographic은 LLM, 임베딩 모델, 데이터베이스, 네트워크 연결이 필요하지 않습니다. 메모리 인코딩은 프로세스 내에서 실행되는 HRR 대수학을 통해 완전히 처리됩니다. 이는 8개 제공자 중 유일하게 외부 호출이 전혀 없는 유일한 제공자입니다. 단점은 검색 품질이 임베딩 기반 시맨틱 검색보다 낮으며, Hindsight의 reflect와 같은 크로스-메모리 합성이 없다는 점입니다. 프라이버시와 제로 의존성 작동이 불가결한 사용자에게 Holographic은 이를 무조건적으로 제공하는 유일한 옵션입니다.

도구: 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 (메모리 삭제).

설정:

hermes memory setup  # "retaindb" 선택

ByteRover

적합한 분야: 인간이 읽을 수 있고 감사 가능한 저장을 갖춘 로컬 우선 메모리.

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

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

도구: 메모리 작업을 위한 3개의 도구.

설정:

hermes memory setup  # "byterover" 선택

Supermemory

적합한 분야: 컨텍스트 펜싱 및 세션 그래프 수집을 갖춘 엔터프라이즈 워크플로우.

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

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

도구: 메모리 작업을 위한 4개의 도구.

설정:

hermes memory setup  # "supermemory" 선택

선택 방법

• 다중 에이전트 지원이 필요합니까? Honcho
• 자체 호스팅과 무료가 필요합니까? OpenViking 또는 Holographic
• 제로 구성이 필요합니까? Mem0
• 지식 그래프가 필요합니까? Hindsight
• 델타 압축이 필요합니까? RetainDB
• 대역폭 효율성이 필요합니까? ByteRover
• 엔터프라이즈 기능이 필요합니까? Supermemory
• 프라이버시(로컬만)가 필요합니까? Holographic
• 외부 서비스가 전혀 없는 완전 로컬이 필요합니까? Holographic (전혀 의존성 없음) 또는 Ollama를 사용하는 Hindsight/Mem0/ByteRover
• 임베딩 파이프라인이 없는 인간이 읽을 수 있고 감사 가능한 메모리가 필요합니까? ByteRover

프로필별 제공자 구성과 실제 워크플로우 패턴에 대해서는 Hermes Agent 프로덕션 설정을 참조하십시오.

관련 가이드

• AI 시스템 메모리 허브 — 이 서브클러스터의 범위 및 Cognee 가이드 링크
• Hermes Agent 메모리 시스템 — 플러그인 이전의 핵심 2 파일 메모리
• Hermes Agent 프로덕션 설정 — 실제 환경에서의 제공자를 위한 프로필 와이링