헤르메스 에이전트 메모리 시스템: 지속적 AI 메모리의 실제 작동 원리

우리는 다 알고 있습니다. AI 에이전트와 채팅 창을 열고 프로젝트를 설명하며 선호 사항을 공유하고 작업을 진행한 후 탭을 닫습니다. 다음 주에 다시 돌아오면 마치 낯선 사람과 대화하는 것과 같습니다. 모든 맥락이 사라지고, 모든 선호 사항이 잊혀졌으며, 프로젝트를 처음부터 다시 설명해야 합니다.

이는 버그가 아닙니다. 대규모 언어 모델(LLM)이 설계된 방식의 본질입니다. 이들은 상태(state)를 유지하지 않습니다(stateless). 각 요청은 독립적이며, 각 응답은 현재 컨텍스트 윈도우의 토큰을 넘어선 기억, 역사, 연속성 없이 당신이 지금 보낸 프롬프트만 바탕으로 생성됩니다.

단일 턴(single-turn) 상호작용이라면 괜찮습니다. 질문하고, 답을 받고, 넘어가는 것이죠. 하지만 세션 간에 작업을 수행하고, 실수에서 배우며, 사용자와 함께 진화해야 하는 에이전트 시스템에는 상태 유지의 부재가 견고한 아키텍처적 한계가 됩니다. 이는 셀프 호스팅 AI 시스템의 핵심적인 미해결 문제 중 하나입니다.

업계는 이를 해결하기 위해 시도해 왔습니다. LangChain은 메모리 모듈을 추가했고, OpenAI는 스레드가 있는 어시스턴트를 도입했습니다. Letta, Zep, Cognee와 같은 프레임워크는 지속적인 메모리를 중심으로 전체 아키텍처를 구축했습니다. Databricks는 “메모리 스케일링(memory scaling)“에 대해 발표했는데, 이는 에이전트의 성능이 축적된 경험과 함께 향상된다는 개념입니다. 2024년 이후 에이전티브 AI의 핵심 미해결 문제로 인식되는 이 문제를 해결하기 위해 전용 벤치마크 논문, 에피소드적 메모리 조사, 그리고 급속히 성장하는 도구 생태계가 등장했습니다.

이러한 접근 방식의 대부분은 공통된 문제를 공유합니다. 메모리를 사후thought(사후적 고려사항)로 취급한다는 점입니다. 즉, 쿼리하는 데이터베이스, 채워 넣는 컨텍스트 윈도우, 명확성보다는 지연 시간과 노이즈를 추가하는 검색 시스템으로 여깁니다.

Hermes Agent는 근본적으로 다른 접근 방식을 취합니다. 메모리는 에이전트가 필요할 때 *검색(retrieve)*하는 것이 아닙니다. 에이전트가 항상 가지고 있는 것입니다. 시스템 프롬프트에 구축되고, 큐레이션되며, 경계가 설정되고, 항상 활성화되어 있습니다. 빠르기 위해 충분히 작고, 유용하기 위해 충분히 구조화되며, 무엇을 잊어야 하는지 알기 위해 충분히 절제되어 있습니다.

이 글에서는 이것이 어떻게 작동하는지 정확히 설명합니다.

Part 1: AI 에이전트 메모리 문제

에이전트에게 “단순히 컨텍스트 추가"가 확장되지 않는 이유

상태 없는(stateless) AI에 대한 명백한 해결책은 컨텍스트를 추가하는 것입니다. 이전 대화를 첨부하고, 프로젝트 문서를 포함하며, 전체 기록을 전송합니다.

그동안 그것은 작동했습니다. 128K 컨텍스트 윈도우가 있습니다. 그곳에는 많은 텍스트를 넣을 수 있습니다.

하지만 컨텍스트는 메모리가 아닙니다. 둘 사이에는 실재하고 중요한 차이가 있습니다. 컨텍스트는 지금 당신에게 보이는 모든 것인 반면, 메모리는 당신이 능동적으로 유지하고 앞으로 가져가는 것입니다.

컨텍스트에는 큐레이션이 없습니다. 그것은 덤프(dump)입니다: 컨텍스트가 커짐에 따라 모델은 필요한 하나의 사실을 찾기 위해 수천 개의 관련 없는 토큰의 역사를 처리해야 합니다. 이는 토큰과 비용을 소모하고, 지연 시간을 가중시키며, 결국 한계에 부딪힙니다.

메모리는 큐레이션됩니다. 그것은 경험의 응축된 형태이며, 컴팩트하고 실행 가능한 것입니다. 무한정 커지지 않습니다 — 통합되고, 업데이트되며, 잊혀집니다.

인간의 메모리도 같은 방식으로 작동합니다. 당신이 가진 모든 대화를 기억하지 않습니다. 중요한 부분만 기억합니다: 누구와 대화하고 있는지, 그들이 무엇을 중요하게 여기는지, 무엇을 합의했는지, 무엇을 배웠는지. 나머지는 잊히거나 필요할 때 검색 가능합니다.

연구 현황

AI 에이전트 메모리 분야는 2024년 이후 폭발적으로 성장했으며, 전용 벤치마크 스위트, 성장하는 연구 문헌, 그리고 다양한 아키텍처 접근 방식 사이의 측정 가능한 성능 격차가 존재합니다. 현재 상황은 다음과 같습니다.

Letta(구 MemGPT)는 지속적인 메모리를 일급 시민(first-class concern)으로 취급한 초기 프레임워크 중 하나로, GitHub 별 21,700개를 달성했습니다. OS에서 영감을 받은 3층 모델을 사용합니다: 핵심 메모리(작고 항상 컨텍스트 내에 있음), 회상 메모리(검색 가능한 대화 기록), 아카이브 메모리(장기 냉각 저장소). 모든 메모리가 동등하지 않다는 통찰은 옳았습니다. 그러나 구현은 에이전트가 Letta 런타임 내부에서 완전히 실행되도록 요구합니다 — 이를 채택한다는 것은 메모리 레이어가 아닌 전체 플랫폼을 채택한다는 것을 의미합니다.

Zep / Graphiti는 시간적 엔티티 추적을 가진 대화형 메모리에 초점을 맞춥니다 — 사실에는 유효성 윈도우가 있어서 그래프가 무언가가 진실이었음을 알 수 있습니다. 관계 그래프가 필요한 챗봇에는 강점이 있지만, 환경 사실과 프로젝트 관례를 추적하는 자율 에이전트에는 덜 적합합니다.

Cognee는 문서와 구조화된 데이터에서 지식 추출을 위해 구축되었으며, 30개 이상의 수집 커넥터와 지식 그래프 백엔드를 갖추고 있습니다. 기관 지식과 RAG 파이프라인에서 뛰어나지만 개인 에이전트 메모리에는 덜 집중되어 있습니다. 로컬 LLM로 Cognee 셀프 호스팅에 대한 실용적인 설정 가이드를 참조하십시오.

Hindsight는 엔티티 관계와 고유한 reflect 합성 도구를 사용한 지식 그래프 기반 회상을 제공합니다. 이 도구는 여러 메모리를 새로운 통찰력으로 결합하는 크로스 메모리 합성을 수행합니다. 에이전트 메모리 벤치마크에서 상위 성능을 보이며, Hermes Agent의 메모리 제공자로서 사용할 수 있습니다.

Mem0은 서버 측 LLM 분석을 통해 메모리 추출을 처리하며, 최소한의 구성이 필요합니다. ECAI 2025에 발표된 Mem0 연구 논문(arXiv:2504.19413)은 AI 메모리의 10가지 다른 접근 방식을 벤치마킹하고 선택적 추출 접근 방식 — 이산 사실 저장, 중복 제거, 관련성 있는 것만 검색 — 을 검증했습니다. Mem0은 약 48,000개의 GitHub 별을 얻었으며 21개 프레임워크 통합을 지원합니다. 단점은 클라우드 의존성과 비용입니다.

Databricks의 메모리 스케일링 연구는 축적된 경험과 함께 에이전트 성능이 향상된다는 개념을 도입했습니다. 그들의 아키텍처는 조직 및 사용자 수준에서 범위가 설정된 시스템 프롬프트, 기업 자산, 에피소드/의미적 메모리를 보유하며, 메모리 품질이 모델 기능만큼 중요하다는 아이디어를 검증합니다.

대부분의 프레임워크를 가로지르는 공통점은 메모리를 검색 문제로 취급한다는 것입니다: 어딘가에 저장하고, 필요할 때 쿼리하며, 컨텍스트에 주입합니다. Hermes는 반대입니다 — 메모리는 필요에 따라 검색되지 않으며, 세션 시작 시 주입되어 항상 존재합니다. 항상 활성이며, 항상 사용 가능하며, 유용함을 유지하기 위해 큐레이션됩니다.

Part 2: 아키텍처 — 두 개의 파일, 하나의 뇌

Hermes Agent의 내장 메모리 시스템은 두 개의 파일에 있습니다.

• ~/.hermes/memories/MEMORY.md — 에이전트의 개인 메모 (2,200자, ~800 토큰)
• ~/.hermes/memories/USER.md — 사용자 프로필 (1,375자, ~500 토큰)

이것이 전체 지속적 메모리 표면입니다: 두 개의 파일, 총 3,600자 미만, 1,300 토큰 미만. 의도적으로 작아 보이는 것은 실제로 그렇기 때문이며, 바로 이것이 디자인 의도입니다.

MEMORY.md: 에이전트의 메모

여기서 에이전트는 환경, 프로젝트, 도구, 관례, 그리고 배운 교훈에 대해 배운 모든 것을 저장합니다. 다음과 같이 보입니다:

사용자의 프로젝트는 ~/code/gateway의 Go 마이크로서비스이며 gRPC + PostgreSQL을 사용합니다
이 머신은 Ubuntu 22.04를 실행하며, Docker와 kubectl이 설치되어 있습니다
사용자는 변수 이름에 snake_case를 선호하고 camelCase를 피합니다

이것들은 로그가 아닙니다. 사실들입니다. 밀도 높고, 선언적이며, 정보가 가득합니다. 타임스탬프, 불필요한 내용, “1월 5일에 사용자가 나에게 …하라고 요청했다"와 같은 내용이 없습니다.

USER.md: 사용자 프로필

여기서 에이전트는 당신에 대해 알고 있는 모든 것을 저장합니다.

사용자는 TypeScript, Go, Python에 익숙한 풀스택 개발자입니다.
사용자는 변수 이름에 snake_case를 선호하고 camelCase를 피합니다.
사용자는 주로 Linux Ubuntu 22.04를 사용합니다.
사용자는 Terraform을 사용하여 AWS로 배포합니다.

정체성, 역할, 선호도, 기술적 기술, 의사소통 스타일, 불쾌한 점. 에이전트가 당신에게 다른任何人보다 다르게 응답하게 만드는 것들입니다.

고정 스냅샷 패턴(Frozen Snapshot Pattern)

세션 시작 시, 두 파일 모두 디스크에서 로드되어 시스템 프롬프트에 고정된 블록으로 주입됩니다. 다음과 같이 보입니다:

══════════════════════════════════════════════
MEMORY (your personal notes) [7% — 166/2,200 chars]

사용자의 프로젝트는 ~/code/gateway의 Go 마이크로서비스이며 gRPC + PostgreSQL을 사용합니다 § 이 머신은 Ubuntu 22.04를 실행하며, Docker와 kubectl이 설치되어 있습니다 § 사용자는 변수 이름에 snake_case를 선호하고 camelCase를 피합니다 §

══════════════════════════════════════════════ USER PROFILE (who the user is) [8% — 110/1,375 chars] ══════════════════════════════════════════════ 사용자는 TypeScript, Go, Python에 익숙한 풀스택 개발자입니다. § 사용자는 변수 이름에 snake_case를 선호하고 camelCase를 피합니다. §

이 형식은 헤더, 사용량 퍼센트, 문자 수, 그리고 `§`(섹션 기호) 구분자를 사용합니다. 항목은 다중 라인일 수 있습니다. 모델이 파싱할 수 있으면서도 사람이 읽을 수 있도록 설계되었습니다.

왜 고정(frozen)되었을까요? [접두사 캐싱(Prefix caching)](https://www.glukhov.org/ko/llm-performance/). 시스템 프롬프트는 세션 내 모든 턴에서 동일합니다. 세션 시작 후 메모리를 정적으로 유지함으로써, 모델은 접두사 계산을 캐시하고 변수 부분 — 즉 대화 — 만 처리할 수 있습니다. 이는 상당한 성능 최적화입니다. 매 턴마다 동일한 메모리 토큰에 대해 주의를 다시 계산하지 않습니다.

세션 동안 이루어진 변경 사항은 즉시 디스크에 지속되지만, 다음 세션 시작 시에만 시스템 프롬프트에 나타납니다. 도구 응답은 항상 실시간 상태를 보여주지만, 모델의 "마음"은 세션 중에는 변경되지 않습니다. 이는 모델이 자신의 꼬리를 쫓는 것을 방지합니다 — 메모리를 업데이트하고 같은 대화에서 자신의 업데이트에 반응하는 것을 방지합니다.

### 기능을 위한 문자 제한

2,200자. 1,375자. 이는 임의의 제한이 아닙니다. 큐레이션을 강제하는 디자인 제약입니다.

무제한 메모리는 부채입니다. 모든 것을 덤프하고, 결코 통합하지 않으며, 결국 노이즈가 되는 것을 장려합니다. 제한된 메모리는 에이전트가 선택적이 되게 합니다. 실제로 중요한 것은 무엇인가? 다시 필요한 것은 무엇인가? 의미를 잃지 않고 압축할 수 있는 것은 무엇인가?

메모리가 가득 차면, 에이전트는 침묵하고 실패하지 않습니다. 현재 항목과 사용량을 가진 오류를 받고, 워크플로우를 따릅니다:

1. 오류 응답에서 현재 항목 읽기
2. 제거 또는 통합 가능한 항목 식별
3. `replace`를 사용하여 관련 항목을 더 짧은 버전으로 병합
4. 새 항목 추가

이것이 메모리가 유용하게 유지되는 방식입니다. 그것은 데이터베이스가 아닙니다. 중요한 사실의 큐레이션된 컬렉션입니다.

### 보안: 프롬프트 인젝션 스캐닝

각 메모리 항목은 승인 전에 스캔됩니다. 시스템은 프롬프트 인젝션 시도, 자격 증명 유출, SSH 백도어, 보이지 않는 유니코드 문자를 차단합니다.

메모리 또한 중복 제거됩니다. 정확한 중복 항목은 자동으로 거부됩니다. 이는 공격자가 반복 제출을 통해 악성 콘텐츠를 주입하려는 시도를 방지합니다.

---

## Part 3: 메모리가 발동할 때 — 트리거 및 결정

Hermes Agent 메모리에 대한 가장 흔한 질문은 언제 실제로 무언가를 저장하느냐입니다.

답은: 끊임없이, 하지만 선택적으로입니다. 에이전트는 `memory` 도구를 통해 자신의 메모리를 관리하며, 저장 결정은 명시적 신호와 암시적 패턴의 조합에 의해 주도됩니다.

### 쓰기 트리거: 에이전트가 저장하기로 결정하는 시점

에이전트는 선제적으로 메모리를 저장합니다. 당신이 요청하기를 기다리지 않습니다. 다음은 그것을 트리거하는 것입니다.

**사용자 수정.** 에이전트를 수정할 때, 그것은 기억하라는 신호입니다. "다시那样하지 마." "이것을 대신 사용해." "이것을 기억해." 이는 메모리를 업데이트하라는 명시적 지시입니다.

예: 에이전트에게 Python 환경을 구성하라고 요청합니다. 에이전트는 `pip`를 제안합니다. 당신이 "나는 모든 것에 `poetry`를 사용한다"고 말합니다. 에이전트는 저장합니다: `사용자는 모든 Python 프로젝트에 'poetry' 패키지 관리자를 사용하는 것을 선호합니다.`

**발견된 선호도.** 에이전트는 패턴을 관찰하고 선호도를 추론합니다. 당신이 일관되게 특정 도구, 프레임워크, 또는 워크플로우를 사용하면, 그것은 저장됩니다.

예: 다른 프로젝트에서 여러 번 `poetry`를 사용하는 것을 본 후, 에이전트는 이를 선호도로 저장합니다.

**환경 사실.** 머신, 프로젝트, 설치된 도구에 대한 것들. 이는 탐색을 통해 발견되고 사실로 저장됩니다.

예: 에이전트는 설치된 것을 확인하고 저장합니다: `이 머신은 Ubuntu 22.04를 실행하며, Docker와 kubectl이 설치되어 있습니다.`

**프로젝트 관례.** 프로젝트가 어떻게 구조화되었는지, 어떤 도구를 사용하는지, 어떤 패턴을 따르는지. 이는 코드 검사를 통해 발견되고 저장됩니다.

예: `사용자의 프로젝트는 ~/code/gateway의 Go 마이크로서비스이며 gRPC + PostgreSQL을 사용합니다.`

**완료된 복잡한 워크플로우.** 5개 이상의 도구 호출이 걸린 작업을 완료한 후, 에이전트는 접근 방식을 기술로 저장하거나 적어도 무엇이 작동했는지 기록하는 것을 고려합니다.

**도구의 특이사항 및 우회 방법.** 에이전트가 도구, API, 또는 시스템에 대해 자명하지 않은 무언가를 발견할 때 — 제한, 우회 방법, 관례 — 그것은 저장됩니다.

**건너뛰는 것:**

- 사소하거나 자명한 정보
- 쉽게 재발견할 수 있는 것
- 원시 데이터 덤프
- 세션 특유의 일시적인 것
- 컨텍스트 파일(SOUL.md, AGENTS.md)에 이미 있는 정보

### 읽기 트리거: 에이전트가 회상하는 시점

메모리는 검색되지 않습니다 — 그것은 항상那里에 있습니다. 그러나 접근 수준은 다릅니다.

**세션 시작(자동).** MEMORY.md와 USER.md는 시스템 프롬프트에 주입됩니다. 에이전트는 첫 번째 토큰부터 그것들을 가지고 있습니다. 쿼리 불필요, 지연 시간 불필요, 도구 호출 불필요. 이것이 핵심 메모리입니다 — 항상 활성입니다.

**`session_search`(수요 기반).** 에이전트가 핵심 메모리에 없는 과거 대화에서 무언가를 찾아야 할 때, `session_search` 도구를 사용합니다. 이는 SQLite(`~/.hermes/state.db`)를 FTS5 전체 텍스트 검색과 Gemini Flash 요약으로 쿼리합니다.

예: 당신이 "지난주에 Docker 네트워킹에 대해 논의했나요?"라고 묻습니다. 에이전트는 세션 기록을 검색하고 관련 대화의 요약을 반환합니다.

**외부 제공자 도구(구성 시).** 외부 메모리 제공자가 활성화되면, 에이전트는 추가 도구(`honcho_search`, `hindsight_recall`, `mem0_search` 등)를 사용할 수 있습니다. 이는 에이전트가 외부 컨텍스트가 필요하다고 판단할 때 사용됩니다.

### 결정 트리

에이전트가 "이것은 기억할 가치가 있는가?"를 가늠하는 방식입니다:

이것이 수정이나 명시적 지시인가? 예 → 메모리에 저장 아니오 → 이것이 선호도나 패턴인가? 예 → 사용자 프로필에 저장 아니오 → 이것이 환경 사실이나 관례인가? 예 → 메모리에 저장 아니오 → 이것이 쉽게 재발견할 수 있는가? 예 → 건너뛰기 아니오 → 이것이 세션 특유의 것인가? 예 → 건너뛰기 아니오 → 메모리에 저장

에이전트는 이를 과민하게 생각하지 않습니다. 선제적으로 저장하고, 가득 차면 통합하며, 문자 제한이 타이트하게 유지되도록 신뢰합니다.

---

## Part 4: 내부 메모리 대 외부 지식 베이스

여기서 혼동이 자주 발생합니다. Hermes Agent는 *내부 메모리*(MEMORY.md, USER.md, 외부 제공자)와 *외부 지식 베이스*(LLM Wiki, Obsidian, Notion, ArXiv, 파일 시스템)를 가지고 있으며, 그것들은 완전히 다른 역할을 수행합니다. 이는 [검색 증강 생성(RAG)](https://www.glukhov.org/ko/rag/) 파이프라인과 에이전트 작업 메모리 사이의 구분에類似합니다 — 외부 검색은 깊은 지식 조회에는 좋지만, 정체성과 선호도를 전달하는 데는 적합하지 않습니다. 내부 메모리는 에이전트의 뇌입니다 — 항상 활성이며, 큐레이션되며, 모든 세션에 들어갑니다. 외부 지식 베이스는 그 라이브러리입니다 — 광범위한 참조 리소스로 필요시 상담됩니다.

### 구분

**내부 메모리(뇌):**

- 작고, 지속적이며, 시스템 프롬프트에 주입됨
- 포함: 사용자 선호도, 에이전트 관례, 즉각적 교훈
- 대화 중 항상 "마음에" 있음
- 큐레이션되고, 제한되며, 능동적으로 관리됨
- 예: MEMORY.md, USER.md, Honcho, Hindsight, Mem0

**외부 지식 베이스(라이브러리):**

- 광범위하며, 참조 전용, 수요 기반 접근
- 포함: 문서, 논문, 코드, 메모, 데이터베이스
- 필요시 도구를 통해 접근
- "기억"되지 않음 — 조회됨
- 예: LLM Wiki, Obsidian, Notion, ArXiv, 파일 시스템, GitHub

### 그것들이 어떻게 관련되는가

에이전트는 필요시 도구를 통해 외부 베이스에 *접근*합니다. 그것들을 "기억"하지 않습니다 — 조회합니다.

**LLM Wiki (llm-wiki):** Karpathy의 도메인 지식을 구축하고 쿼리하기 위한 상호 연결된 Markdown 지식 베이스. 에이전트는 `llm-wiki` 기술을 사용하여 읽기, 검색, 쿼리를 수행합니다. 그것은 메모리가 아닌 참조 리소스입니다.

**[Obsidian](https://www.glukhov.org/ko/knowledge-management/tools/obsidian-for-personal-knowledge-management/):** 양방향 링크가 있는 개인 메모 볼트. 에이전트는 `obsidian` 기술을 사용하여 읽기, 검색, 메모 생성을 수행합니다. Obsidian은 Hermes가 라이브러리 리소스로 활용할 수 있는 더 넓은 [개인 지식 관리](https://www.glukhov.org/ko/knowledge-management/) 생태계의 일부입니다.

**Notion/Airtable:** API를 통해 접근하는 구조화된 데이터베이스와 위키. 에이전트는 필요시 쿼리합니다.

**ArXiv:** 학술 논문 저장소. 에이전트는 주제를 연구할 때 논문을 검색하고 추출합니다.

**파일 시스템:** 프로젝트 코드, 문서, 구성. 에이전트는 프로젝트 작업을 할 때 파일을 읽습니다.

### 추출 패턴(Distillation Pattern)

핵심 통찰: 외부 베이스의 중요 통찰은 내부 메모리로 *추출*될 수 있습니다.

예: 에이전트는 AI 에이전트 메모리 스케일링에 대한 ArXiv의 논문을 읽습니다. 그것은 메모리에 전체 논문을 저장하지 않습니다. 핵심 요점을 저장합니다: `메모리 스케일링: 에이전트 성능은 메모리에 저장된 사용자 상호작용과 비즈니스 컨텍스트를 통해 축적된 경험과 함께 향상됩니다.`

외부 리소스는 광범위합니다. 내부 메모리는 추출된 것입니다.

### 언제 무엇을 사용할 것인가

**내부 메모리:**

- "나는 누구를 도와주고 있는가?"
- "그들은 무엇을 선호하는가?"
- "우리는 방금 무엇을 배웠는가?"
- "프로젝트 설정은 무엇인가?"
- "어떤 도구가 사용 가능한가?"

**외부 지식 베이스:**

- "X에 대한 최신 연구는 무엇인가?"
- "프로젝트 문서에 무엇이 있는가?"
- "지난달에 무엇을 논의했는가?"
- "이 서비스의 API는 무엇인가?"
- "코드 구조는 무엇인가?"

에이전트는 차이를 이해하고 적절하게 사용합니다 — 문서 조회를 당신과 당신의 환경에 대해 배운 것을 회상하는 것과 혼동하지 않습니다.

---

## Part 5: 실제로 어떻게 작동하는가

기계적 요소를 살펴보겠습니다.

### `memory` 도구

에이전트는 세 가지 작업을 가진 단일 도구를 통해 메모리를 관리합니다: `add`, `replace`, `remove`.

`read` 작업은 없습니다 — 메모리 콘텐츠는 시스템 프롬프트에 자동으로 주입됩니다. 에이전트는 항상那里에 있으므로 읽을 필요가 없습니다.

**`add`** — 새 항목 추가.

```python
memory(action="add", target="memory",
       content="사용자는 macOS 14 Sonoma를 실행하며, Homebrew와 Docker Desktop이 설치되어 있습니다.")

replace — 부분 일치(substring matching)를 사용하여 기존 항목 교체.

memory(action="replace", target="memory",
       old_text="dark mode",
       content="사용자는 VS Code에서는 light mode를 선호하고 터미널에서는 dark mode를 선호합니다")

remove — 부분 일치(substring matching)를 사용하여 항목 제거.

memory(action="remove", target="memory",
       old_text="temporary project fact")

부분 일치(Substrings Matching)

replace와 remove는 짧은 고유 부분 문자열을 old_text를 통해 사용합니다. 전체 항목 텍스트가 필요하지 않습니다. 이는 정확한 내용을 알지 못해도 수술적 편집을 가능하게 합니다.

부분 문자열이 여러 항목과 일치하면, 더 구체적인 일치를 요청하는 오류가 반환됩니다. 에이전트는 그 후 쿼리를 정교화합니다.

대상 저장소: memory 대 user

target 매개변수는 업데이트할 파일을 결정합니다.

• memory — 에이전트의 개인 메모. 환경 사실, 프로젝트 관례, 도구 특이사항, 배운 교훈.
• user — 사용자 프로필. 정체성, 역할, 시간대, 의사소통 선호도, 불쾌한 점, 워크플로우 습관.

용량 관리

메모리가 80% 이상 차면, 에이전트는 통합합니다. 관련 항목을 병합하고, 오래된 사실을 제거하며, 정보를 압축합니다.

좋은 메모리 항목은 컴팩트하고 정보 밀도가 높습니다:

사용자는 macOS 14 Sonoma를 실행하며, Homebrew와 Docker Desktop이 설치되어 있습니다. 쉘: oh-my-zsh가 있는 zsh. 에디터: Telescope 플러그인이 있는 Neovim.

나쁜 메모리 항목은 모호하거나 장황합니다:

사용자에게 프로젝트가 있습니다.
2026년 1월 5일, 사용자는 ~/code/gateway에 위치한 프로젝트를 살펴보라고 요청했으며, 이는 데이터베이스 레이어로 Go와 gRPC, PostgreSQL을 사용합니다.

첫 번째는 밀도 높고 유용합니다. 두 번째는 너무 모호하거나 너무 장황합니다.

세션 검색 대 지속적 메모리

session_search와 지속적 메모리는 다른 목적을 수행합니다.

대략적인 규칙: 컨텍스트에 항상 있어야 하는 핵심 사실에는 메모리를 사용하고, 역사적 조회에는 세션 검색을 사용하십시오.

Part 6: 외부 메모리 제공자 — 8가지 옵션 비교

내장 MEMORY.md와 USER.md 외에도, Hermes Agent는 지속적이고 세션 간 지식을 위한 8개의 외부 메모리 제공자 플러그인을 지원합니다.

한 번에 하나의 외부 제공자만 활성화할 수 있습니다. 내장 파일은 외부 제공자와 함께 항상 활성이며 — 대체가 아닌 추가입니다.

활성화

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는 추가적인 컨텍스트 레이어를 추가합니다. 대화는 메시지를 교환하는 동료(peer)로 모델링합니다 — 각 Hermes 프로필당 하나의 사용자 동료와 하나의 AI 동료, 모두 작업 공간을 공유합니다.

도구: 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은 계층적 로딩을 가진 파일 시스템 계층을 제공합니다. 무료이며, 셀프 호스팅되며, 메모리 저장소에 대한 전체 제어를 제공합니다.

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

설정:

pip install openviking
openviking-server
hermes memory setup  # "openviking" 선택
echo "OPENVIKING_ENDPOINT=http://localhost:1933" >> ~/.hermes/.env

Mem0

최적: 자동 추출이 있는 핸즈오프 메모리 관리.

Mem0은 서버 측 메모리 추출을 처리합니다. 아무것도 구성할 필요가 없습니다 — 그냥 작동합니다. 단점: 클라우드 의존성과 비용.

도구: 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 도구는 크로스 메모리 합성을 수행합니다 — 여러 메모리를 새로운 통찰력으로 결합합니다.

도구: 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) 대수를 사용하고, 메모리 신뢰도를 위해 신뢰 점수를 사용합니다. 클라우드 의존성 없음 — 모든 것이 자체 하드웨어에서 로컬로 실행됩니다.

도구: HRR 대수를 통한 2개의 메모리 연산 도구.

설정:

hermes memory setup  # "holographic" 선택

의존성 없음. 모든 것이 로컬로 실행됩니다.

RetainDB

최적: 델타 압축이 있는 고빈도 업데이트.

RetainDB는 메모리 업데이트를 효율적으로 저장하기 위해 델타 압축을 사용합니다. 클라우드 기반이며 월 $20 비용이지만, 압축은 데이터 전송을 줄이고 업데이트를 가속화합니다.

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

설정:

hermes memory setup  # "retaindb" 선택

ByteRover

최적: 대역폭이 제한된 환경에 대한 사전 압축 추출.

ByteRover는 추출 전에 메모리를 압축하여 대역폭 사용을 줄입니다. 로컬 또는 클라우드 모드에서 사용 가능합니다.

도구: 3개의 메모리 연산 도구.

설정:

hermes memory setup  # "byterover" 선택

Supermemory

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

Supermemory는 컨텍스트 펜싱(컨텍스트별 메모리 격리)과 세션 그래프 수집(전체 대화 기록 가져오기)을 제공합니다. 클라우드 기반이며 유료이지만, 엔터프라이즈 규모 메모리 관리를 위해 설계되었습니다.

도구: 4개의 메모리 연산 도구.

설정:

hermes memory setup  # "supermemory" 선택

어떻게 선택할 것인가

• 다중 에이전트 지원이 필요한가? Honcho
• 셀프 호스팅과 무료를 원하는가? OpenViking 또는 Holographic
• 제로 구성을 원하는가? Mem0
• 지식 그래프를 원하는가? Hindsight
• 델타 압축을 원하는가? RetainDB
• 대역폭 효율성을 원하는가? ByteRover
• 엔터프라이즈 기능을 원하는가? Supermemory
• 프라이버시(로컬만)를 원하는가? Holographic

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

Part 7: 철학

왜 제한된 메모리가 무제한 메모리를 이기는가

본능은 메모리를 최대한 크게 만드는 것입니다. 모든 것을 저장하고, 필요한 것을 검색합니다.

제한된 메모리가 더 잘 작동합니다. 그 이유는 다음과 같습니다.

큐레이션은 품질을 강제합니다. 제한된 공간이 있으면, 중요한 것만 저장합니다. 압축하고, 통합하며, 우선순위를 정합니다. 무제한 메모리는 모든 것을 덤프하고 결코 정리하지 않는 것을 장려합니다.

속도는 중요합니다. 시스템 프롬프트의 1,300 토큰은 빠릅니다. 데이터베이스에서 검색된 100,000 토큰은 느립니다. 메모리는 쿼리가 아닌 즉각적이어야 합니다.

노이즈는 성능을 저하시킵니다. 더 많은 메모리가 더 나은 메모리가 아닙니다. 그것은 더 노이즈가 많은 메모리입니다. 모델은 신호와 노이즈를 구별해야 하며, 이는 주의가 필요합니다 — 실제 작업에 사용해야 할 주의.

잊음은 기능입니다. 인간 메모리는 잊습니다. 그것은 버그가 아닙니다 — 우리가 우선순위를 정하는 방식입니다. 에이전트도 잊어야 합니다. 모든 것이 기억될 자격이 있는 것은 아닙니다.

“잊음” 문제

에이전트는 학습을 취소해야 합니다. 단순히 잊는 것이 아니라, 능동적으로 오래된 정보를 제거해야 합니다.

Hermes Agent가 이를 처리하는 방식:

• remove 작업: 더 이상 관련성이 없는 항목 삭제.
• replace 작업: 새로운 정보로 항목 업데이트.
• 용량 압력: 메모리가 가득 차면, 에이전트는 통합하고 오래된 항목을 제거합니다.
• 보안 스캐닝: 악성 또는 손상된 항목 차단.

잊음은 실패가 아닙니다 — 그것은 유지보수입니다. 학습을 취소할 수 없는 에이전트는 결국 신호만큼 많은 노이즈를 운반하게 될 것입니다.

메모리 스케일링

Databricks는 “메모리 스케일링” 개념을 도입했습니다: 수천 명의 사용자를 가진 에이전트가 단일 사용자를 가진 에이전트보다 더 잘 작동하는가?

그들의 연구는 그렇다고 제안하지만, 주의 사항이 있습니다. 메모리 스케일링에는 다음이 필요합니다:

1. 품질 추출: 모든 상호작용이 기억할 가치가 있는 것은 아닙니다. 에이전트는 로그가 아닌 통찰력을 추출해야 합니다.
2. 효과적인 검색: 검색된 메모리는 관련성이 있어야 합니다. 노이즈는 성능을 저하시킵니다.
3. 일반화: 메모리는 패턴이어야 하며, 구체적이어서는 안 됩니다. “사용자가 Python을 선호함"은 스케일링됩니다. “사용자가 타임스탬프 Y에서 명령 X를 실행함"은 그렇지 않습니다.

Hermes Agent의 제한된 메모리는 자연스럽게 메모리 스케일링을 지원합니다. 큐레이션을 강제함으로써, 메모리가 일반화 가능하고, 컴팩트하며, 유용하도록 보장합니다.

이것이 미래를 위해 의미하는 것

메모리는 에이전티브 AI에서 경쟁적 도랑이 되고 있습니다 — 모델 자체가 아니라, 모델이 세션 간에 운반하는 것입니다. 동일한 기본 모델을 가진 두 에이전트는 매우 다르게 작동할 수 있습니다: 하나는 당신의 선호도, 환경, 과거 실수를 기억하는 반면, 다른 하나는 매번 콜드 스타트합니다.

더 이상 에이전트가 지속적 메모리를 가져야 하는가는 아닌가가 아닙니다. 그것은 해결되었습니다: 가져야 합니다. 열린 질문은 그 메모리를 어떻게 잘 설계하느냐입니다 — 무엇을 유지하고, 무엇을 버리고, 어떻게 즉각적으로 만들며, 어떻게 노이즈가 되는 것을 방지하느냐.

Hermes Agent의 답은 메모리를 작고, 큐레이션되며, 항상 활성으로 유지하는 것입니다 — 쿼리하는 데이터베이스가 아닌, 에이전트가 모든 대화에 함께 운반하는 사용자의 작동 모델입니다.

결론

Hermes Agent의 메모리 시스템은 의도적으로 단순합니다: 두 개의 파일, 엄격한 문자 제한, 검색 파이프라인 없음, 벡터 데이터베이스 없음, 쿼리별 지연 시간 없음. 제약처럼 들리는 것이 바로 전체 포인트입니다.

그것은 뇌가 작동하는 방식처럼 메모리를 취급하기 때문에 작동합니다 — 데이터베이스가 작동하는 방식이 아니라 — 작고, 큐레이션되며, 항상 활성입니다. 에이전트는 필요할 때 메모리를 검색하지 않습니다; 메모리는 단순히 항상那里에 있으며, 모든 세션의 첫 번째 토큰부터 시스템 프롬프트에 짜여 있습니다.

외부 메모리 제공자는 더 필요한 사용자를 위해 이 시스템을 확장합니다: 지식 그래프, 다중 에이전트 지원, 셀프 호스팅 저장소, 엔터프라이즈 기능. 그러나 핵심은 동일합니다: 제한적이고, 큐레이션되며, 항상 사용 가능.

그리고 외부 지식 베이스 — LLM Wiki, Obsidian, Notion, ArXiv — 는 다른 역할을 수행합니다. 그것들은 뇌가 아닌 라이브러리입니다. 에이전트는 그것들을 기억하지 않고 조회합니다. 중요 통찰력은 내부 메모리로 추출되고; 나머지는 라이브러리에 남아 있습니다.

이것이 AI 에이전트가 당신을 기억하는 방식입니다. 모든 것을 저장하는 것이 아니라, 중요한 것을 기억함으로써.

Hermes Agent는 2026년 2월 Nous Research에 의해 출시되었으며, 2026년 4월까지 64,000개 이상의 GitHub 별(v0.9.0)을 달성했고, 242명 이상의 기여자가 있습니다. 오픈소스이며 github.com/NousResearch/hermes-agent에서 사용할 수 있습니다. 설치, 구성, 워크플로우 가이드에 대해서는 Hermes Agent 개요를 참조하십시오.