【#4】Hermes Agent 분석하기

연재 「Hermes Agent 분석하기」 제4회.

지난 회에서, Hermes는 context(문맥)가 절반 정도 차면 대화 중반부를 요약하여 압축(fold)한다고 기술했다. 압축한다는 것은 잊는다는 것이다. 그렇다면 묻고 싶다——매 턴마다 잊어가는 에이전트에게, 연속된 '그 사람다움'이 깃들 수 있는가.

나는 이 연재를 통해 하나의 테제(thesis)를 내걸고 있다. 인격 = 지능 × 기억. 모델의 똑똑함(지능)만으로는 인격이 세워지지 않는다. 같은 모델이라도 무엇을 기억하고 있으며, 무엇을 문맥(context)으로 가져오느냐에 따라 행동은 다른 사람이 된다. 기억은 인격의 동적인 기반이다.

그리고 압축은 그 기반을 위협한다. 제4회에서는 Hermes가 어떻게 이 위협에 저항하며, 기억을 **재주입(re-injection)**함으로써 인격의 연속성을 담보하고 있는지를 읽어본다.

Hermes의 기억은 시간 스케일에 따라 3개 층으로 나뉜다.

대화 context (휘발성)— 지금 바로 window(윈도우)에 있는 대화. 압축으로 인해 요약될 수 있는 가장 덧없는 층 -
MEMORY.md / USER.md (중기)— 파일로서 남음. 에이전트의 메모와 사용자상 -
장기 프로바이더 (영속성)— 외부의 전용 메모리 기반에 저장하는 층

휘발성 층이 압축으로 인해 빈약해지더라도, 중기·장기 기억으로부터 다시 불러올 수(pull back) 있다. 이것이 연속성의 핵심이다.

장기 기억은 단일 구현에 얽매이지 않는다. MemoryProvider라는 추상 기저 클래스(ABC, Abstract Base Class)가 창구 역할을 한다. prefetch(선독) / sync_turn(턴 동기화) / on_session_*(세션 경계의 훅)과 같은 메서드를 정의하고, 각 백엔드가 이를 구현한다.

중요한 제약이 하나 있다. 빌트인(built-in) 메모리는 항상 동작하며, 외부 프로바이더는 단 하나만——라는 배타 제어가 작동하고 있다 (memory_manager.py:245-265). 여러 개의 외부 메모리를 동시에 연결하여 기억이 분열되는 사고를 설계 단계에서 방지하고 있다.

이곳이 하이라이트의 핵심이다. 기억을 어느 타이밍에, 어디에 삽입할 것인가.

비동기 선독 (Asynchronous prefetching): 메모리 취득은 느리다 (외부 API를 호출하는 경우도 있다). 그래서 Hermes는 이전 턴 중에 다음 턴을 위한 기억을 미리 선독해 두고, 다음 턴의 시작 시점에 그것을 소비한다. 레이턴시(latency)를 턴 경계에 숨기는 고전적이지만 효과적인 수법이다.

주입 위치: 취득한 기억은 <memory-context> 태그를 통해 사용자 메시지 측에 주입된다. 이 부분이 영리하다. 시스템 프롬프트(system prompt)는 불변으로 유지한다——기억을 system prompt에 섞으면 매 턴 내용이 바뀌어 prefix 캐시(prefix cache)를 사용할 수 없게 된다. 사용자 메시지 측으로 몰아줌으로써, system prompt를 고정하고 프로바이더의 prefix 캐시(동일 접두사 사용에 따른 비용 및 지연 절약)를 보존한다. 기억의 신선도와 캐시 효율을 양립시키는 판단이다.

스크러버 (Scrubber): 사용자 입력에 <memory-context>와 같은 제어 태그가 섞여 들어오면, 주입을 위장당할 위험이 있다. 이를 방지하기 위해 주입 전 입력을 스크러빙(scrubbing, 무해화)하여 태그 주입을 차단한다. 제10회의 프롬프트 인젝션(prompt injection)론과도 이어지는 방어 기제다.

빌트인 이외의 장기 프로바이더는 8개(honcho + 기타 7개)이다. 대표적으로 Honcho를 살펴본다. Honcho는 대화 상대를 'peer'로 모델링하여, 상대의 심적 상태의 표상(representation)을 구축한다.

peer / representation / peer card— 상대를 peer로서 표상화하고, 요약 카드를 가짐 -
dialectic— 기억으로부터의 추론 깊이를 단계별로 제어 (reasoning_level) -
recall mode (hybrid / context / tools)— 회상 방식을 context 주입, 툴(tool) 경유, 혹은 양자 하이브리드 중에서 선택 -
SOUL.md seeding— SOUL.md로 초기 인격 및 전제를 seed(시드)함

SOUL.md라는 명명에서 사상이 드러난다. 기억 기반이 '영혼의 씨앗'을 가진다는 발상이다. 본 연재의 테제와 정면으로 공명한다.

남은 7개는 다음과 같다 (plugins/memory/ 직하의 디렉토리 실측치. 엔드포인트는 실제 코드에서 확인한 값이다).

프로바이더	유형	스토리지 / 검색	요약의 소재	외부 서비스
mem0	SaaS	서버 측에서 사실 추출 + 의미 검색 (Semantic Search) + rerank	서버	Mem0 (정확한 URL은 확인 필요)
supermemory	SaaS	문서 + 프로필, 하이브리드 (Hybrid) 검색. 세션 종료 시 일괄 인제스트 (Ingest)	프로필 합성	api.supermemory.ai/v4
retaindb	SaaS	의미 검색 + 변증법적 (Dialectic). SQLite의 내구 큐 (Durable Queue)로 쓰기 작업의 크래시 내성 확보	서버	api.retaindb.com
openviking	자체 호스팅	계층적 KB (viking://), L0/L1/L2 단계 취득. 커밋 (Commit) 시 6개 카테고리 자동 추출	자동 추출	127.0.0.1:1933 (기본값, ByteDance 계열)
byterover	로컬 CLI	brv CLI를 통한 계층 트리, LLM 큐레이션 (Curation). 프리페치 (Prefetch)는 동기 방식	LLM 큐레이션	로컬 ~/.brv-cli (선택적으로 클라우드 동기화)
hindsight	클라우드/로컬	지식 그래프 (Knowledge Graph) + 다각적 전략 검색 (의미/키워드/엔티티). 단일 라이터 큐 (Writer Queue)	reflect 합성	api.hindsight.vectorize.io / 임베딩 localhost:8888
holographic	완전 로컬	로컬 SQLite (facts + entity 해결 + 신뢰 점수). FTS5 + Jaccard + HRR (1024 차원, numpy 임의)	없음 (생사실 + trust 가중치)	없음 (memory_store.db)

축은 두 가지다. SaaS인가 로컬인가 (기억을 외부에 맡길 것인가 수중에 둘 것인가), 그리고 요약을 어디서 만드는가 (프로바이더 측에서 요약할 것인가, Hermes 측에서 전달할 것인가). 표를 세로로 훑어보면, 4개는 SaaS 기반의 얇은 래퍼 (서버에 통째로 맡김), holographic은 완전 오프라인의 본격적인 구현 (FTS5 + HRR을 로컬에서 구동), hindsight는 클라우드/임베딩 양쪽 대응, openviking은 자체 호스팅 전제—라고 성격이 명확히 갈린다. 프라이버시와 레이턴시 (Latency) 사이의 트레이드오프 (Trade-off)가 이 선택에 응축되어 있다. 로컬 LLM 파인인 나는 당연히 holographic과 같은 수중 완결형을 선택하지만, 요약 품질과의 줄다리기는 숙제로 남는다.

SaaS형 프로바이더의 내부 알고리즘이나 정확한 서버 URL은 로컬 코드만으로는 확정할 수 없다. 여기서는 Hermes 측의 인터페이스 (Interface)를 통해 읽어낼 수 있는 범위 내로 한정한다.

지금까지의 내용을 하나의 선으로 정리한다.

압축(제3회)은 인격의 동적 기반인 기억을 위협한다. 대화 컨텍스트 (Context)를 접을 때마다, 에이전트는 '그 사람다움'을 구성하던 문맥을 잃어버릴 뻔한다.

그것을 구하는 것이 바로 **재주입 (Re-injection)**이다. 중기 (MEMORY.md / USER.md) 및 장기 프로바이더로부터, 미리 읽어온 기억이 다음 턴의 시작 부분에서 <memory-context>로서 돌아온다. 접어서 잊고, 다시 펼쳐서 기억한다—이 왕복이야말로 휘발되는 컨텍스트 위에 연속된 인격을 세우는 과정이다.

인격 = 지능 × 기억. 지능 (모델)이 같더라도 기억의 계층 구조와 재주입 설계가 바뀌면 에이전트의 인격은 변한다. Hermes의 기억 아키텍처 (Architecture)는 이 등식을 구현으로 옮긴 하나의 해답이다.

다음부터는 후반전이다. 에이전트의 '능력'—tools/의 자기 등록 레지스트리 (Registry)와, 실제로 호출 가능한 전 71개 도구 (Tool) 카탈로그를 생략 없이 나열한다.

대응 맵 장: §13, §18 / 행 번호는 hermes update 시 어긋날 수 있음