Hermes Agent memory 시스템이란 무엇이며 어떻게 작동하나요?

Hermes Agent는 ~/.hermes/memories/에 저장되는 두 개의 파일로 구성된 persistent memory 시스템을 사용합니다. 이 시스템은 MEMORY.md(최대 2,200자)와 USER.md(최대 1,375자)로 이루어져 있으며, 세션이 시작될 때마다 system prompt에 frozen block 형태로 주입됩니다. Agent는 add, replace, remove tool action을 통해 이 파일들을 관리하며, 별도의 retrieval 단계 없이도 핵심 정보를 항상 사용할 수 있도록 유지합니다.

Hermes Agent는 모든 데이터를 저장하는 대신 왜 메모리를 약 3,600자 정도로 제한하나요?

글자 수 제한은 기술적 제약이 아닌 의도적인 설계 선택입니다. 제한된 메모리는 에이전트가 모든 정보를 단순히 쏟아붓는 대신, 중요한 정보를 압축, 통합 및 우선순위화하여 선별하도록 강제합니다. 작고 정제된 메모리는 계속해서 커지는 검색 데이터베이스보다 속도가 빠르고(LLM prefix caching 활용), 노이즈가 적으며, 더 유용합니다.

Hermes Agent는 어떻게 컨텍스트를 잃지 않고 세션 간에 정보를 기억할까요?

각 세션이 시작될 때마다 MEMORY.md와 USER.md가 시스템 프롬프트에 frozen snapshot 형태로 주입되므로, 에이전트는 첫 번째 토큰부터 전체 컨텍스트를 파악할 수 있습니다. 모든 대화 내용은 FTS5 풀텍스트 검색 기능이 포함된 SQLite 데이터베이스(~/.hermes/state.db)에 저장됩니다. 과거의 컨텍스트가 필요한 경우, 에이전트는 이 데이터베이스를 쿼리하고 빠른 LLM 호출을 통해 관련 과거 세션을 요약한 뒤 이를 현재 대화에 주입합니다.

Hermes Agent의 core memory와 session search의 차이점은 무엇인가요?

Core memory(MEMORY.md 및 USER.md)는 시스템 프롬프트에 항상 포함되는 엄선된 핵심 정보 세트를 보유합니다. 이는 별도의 쿼리 없이 즉시 접근할 수 있으며, 토큰 비용이 고정되어 있습니다. Session search는 에이전트가 Core memory로 요약되지 않은 과거 세션의 정보가 필요할 때, 요청에 따라 전체 SQLite 대화 기록을 검색합니다. Core memory는 항상 중요한 정보를 위한 것이며, Session search는 과거 기록을 조회하기 위한 용도입니다.

Memory가 활성화되었을 때, Hermes Agent는 어떻게 recall을 실행하고 각 turn을 저장합니까?

각 모델이 응답하기 전에, 프레임워크는 현재 사용자 메시지를 쿼리로 사용하여 설정된 외부 프로바이더로부터 컨텍스트를 prefetch합니다. 어시스턴트가 응답한 후에는 sync paths를 통해 durable state를 유지합니다. 내장된 MEMORY.md와 USER.md는 프로바이더와 함께 로드된 상태로 유지되며, 이는 둘 중 하나를 선택하는 것이 아닌 두 레이어가 공존하는 방식입니다.

Hermes Agent external memory 플러그인에서 recall mode는 무엇을 제어하나요?

automatic prefetch injection만 선택하거나, provider retrieval tools만 선택하거나, 또는 두 가지를 모두 함께 선택할 수 있습니다. 이는 토큰 사용량과 모델이 search 또는 reasoning tools를 얼마나 명시적으로 호출해야 하는지 사이의 트레이드오프(trade-off)를 결정합니다.

Hermes Agent는 어떤 외부 메모리 프로바이더(external memory providers)를 지원하나요?

Hermes Agent는 Honcho, OpenViking, Mem0, Hindsight, Holographic, RetainDB, ByteRover, Supermemory 등 8개의 외부 메모리 프로바이더 플러그인을 지원합니다. 외부 프로바이더는 한 번에 하나만 활성화할 수 있으며, 이는 항상 활성화되어 있는 MEMORY.md 및 USER.md 파일을 대체하는 것이 아니라 그 기능을 확장합니다. 프로바이더는 hermes memory setup을 통해 설정할 수 있으며, self-hosted knowledge graph부터 enterprise context fencing에 이르기까지 다양한 유스케이스를 지원합니다. 각 프로바이더마다 외부 의존성 요구사항이 다릅니다. 어떤 프로바이더는 LLM, embedding model 또는 PostgreSQL 데이터베이스가 필요하지만, Holographic의 경우 이 중 어느 것도 필요하지 않으며 완전히 로컬에서 실행됩니다. 활성화 명령 및 의존성 테이블을 포함한 독립적인 비교 자료는 www.glukhov.org 의 ‘Agent memory providers compared’ 페이지를 참조하십시오.

데이터를 클라우드로 전송하지 않고 완전히 로컬에서 실행할 수 있는 Hermes Agent memory provider에는 어떤 것들이 있나요?

Holographic는 LLM, 임베딩 모델, 데이터베이스, 네트워크 호출이 전혀 필요 없는 유일한 프로바이더로, 외부 의존성이 제로입니다. 더 강력한 로컬 설정을 원하는 경우, Hindsight와 Mem0 모두 Ollama를 지원하여 LLM 및 임베딩 추론을 수행할 수 있으며 모든 데이터는 로컬 머신에 유지됩니다. ByteRover는 메모리를 일반 마크다운 파일로 저장하며, 임베딩 모델이나 데이터베이스 없이 Ollama와 같은 로컬 LLM만 필요로 합니다. OpenViking 또한 Ollama 기반의 설정 마법저를 통해 완전한 로컬 동작을 지원합니다. 반면, RetainDB와 Supermemory는 클라우드 전용 서비스로 로컬에서 실행할 수 없습니다.

Hermes Agent는 무엇을 메모리에 저장할지 어떻게 결정할까요?

에이전트는 우선순위 결정 트리에 따라 선제적으로 메모리를 저장합니다. 사용자의 명시적인 수정 사항과 지침은 즉시 저장됩니다. 추론된 선호도와 관찰된 패턴은 사용자 프로필(user profile)에 기록됩니다. 환경 정보, 프로젝트 컨벤션 및 도구의 특이 사항은 에이전트 노트(agent notes)에 저장됩니다. 쉽게 재발견 가능한 정보나 세션별 휘발성 데이터는 저장 대상에서 제외됩니다. 메모리가 가득 차면, 에이전트는 새로운 항목을 추가하기 전에 관련 항목들을 병합하고 압축하여 데이터를 정리합니다.

Hermes Agent의 메모리는 로컬에 저장되나요, 아니면 클라우드에 저장되나요?

기본적으로 모든 메모리는 사용자 본인의 로컬 기기 또는 VPS에만 저장되며, 외부 서버로 동기화되지 않습니다. MEMORY.md와 USER.md는 ~/.hermes/memories/ 경로에 저장되는 일반 텍스트 파일이며, 대화 기록은 ~/.hermes/state.db에 저장됩니다. 만약 Mem0, Honcho, RetainDB와 같은 클라우드 기반 외부 프로바이더를 설정하면 해당 데이터는 제3자 서비스로 전송되지만, 핵심 메모리 파일은 항상 로컬에 유지됩니다.

Hermes Agent Memory System: 지속 가능한 AI Memory의 실제 작동 원리

메모리는 도구와 파트너를 구분 짓는 차이입니다.

Page content

이미 잘 알고 계실 겁니다. AI 에이전트와 채팅을 시작하고, 프로젝트를 설명하고, 선호도를 공유한 뒤, 작업을 마치고 탭을 닫습니다. 그리고 다음 주에 다시 돌아오면 마치 낯선 사람과 대화하는 기분이 듭니다. 모든 문맥은 사라졌고, 모든 선호도는 잊혔으며, 프로젝트를 처음부터 다시 설명해야 합니다.

이것은 버그가 아닙니다. 거대 언어 모델(LLM)이 설계된 방식 그 자체입니다. 모델은 상태를 유지하지 않습니다(stateless). 각 요청은 독립적이며, 각 응답은 현재 보낸 프롬프트로부터 생성됩니다. 현재 컨텍스트 창(context window)에 포함된 토큰 외에는 기억도, 이력도, 연속성도 없습니다.

단발성 상호작용이라면 괜찮습니다. 질문하고, 답을 얻고, 다음으로 넘어가면 됩니다. 하지만 세션 전반에 걸쳐 무언가를 수행하고, 실수로부터 배우며, 사용자와 함께 진화해야 하는 ‘에이전트’에게 상태 비보존성(statelessness)은 구조적인 한계입니다. 이는 self-hosted AI systems에서 아직 해결되지 않은 핵심 문제 중 하나입니다.

3d electro tetris as an ai agent memory system

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

대부분의 이러한 접근 방식은 공통된 문제를 안고 있습니다. 메모리를 사후 고려 사항으로 취급한다는 점입니다. 즉, 메모리를 쿼리해야 하는 데이터베이스, 억지로 채워 넣어야 하는 컨텍스트 창, 혹은 명확성보다는 지연 시간(latency)과 노이즈를 유발하는 검색 시스템으로 취급합니다.

https://www.glukhov.org/ko/ai-systems/hermes/Hermes Agent는 근본적으로 다른 접근 방식을 취합니다. 메모리는 에이전트가 필요할 때 검색하는 것이 아닙니다. 메모리는 에이전트가 항상 유지하는 것입니다. 시스템 프롬프트에 내장되어 있고, 큐레이션되며, 범위가 제한되어 있고, 항상 활성화되어 있습니다. 빠를 정도로 충분히 작고, 유용할 정도로 구조화되어 있으며, 무엇을 잊어야 할지 알 정도로 절제되어 있습니다.

이 글에서는 그 작동 원리를 정확히 설명합니다.

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

왜 “단순히 컨텍스트를 추가하는 것"은 에이전트에게 확장성이 없는가

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

한동안은 이것이 작동합니다. 128K 컨텍스트 창이 있으니 많은 텍스트를 담을 수 있습니다.

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

컨텍스트에는 큐레이션이 없습니다. 그것은 데이터 덤프와 같습니다. 컨텍스트가 커질수록 모델은 필요한 단 하나의 사실을 찾기 위해 수천 개의 무관한 과거 토큰을 처리해야 합니다. 이는 토큰과 비용을 소모하며, 지연 시간을 가중시키고, 결국 한계에 부딪힙니다.

메모리는 큐레이션됩니다. 그것은 경험을 압축적이고 실행 가능한 형태로 정제한 것입니다. 무한정 커지는 것이 아니라, 통합하고, 업데이트하며, 잊어버립니다.

인간의 기억도 같은 방식으로 작동합니다. 당신은 지금까지 나눈 모든 대화를 기억하지 않습니다. 당신은 중요한 부분, 즉 누구와 대화하고 있는지, 상대방이 무엇에 관심이 있는지, 무엇에 합의했는지, 무엇을 배웠는지를 기억합니다. 나머지는 잊어버리거나 필요할 때 검색합니다.

연구 현황

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

Letta (구 MemGPT)는 지속성 메모리를 최우선 과제로 다룬 초기 프레임워크 중 하나로, GitHub에서 21.7K개의 스타를 기록했습니다. OS에서 영감을 받은 3단계 모델을 사용합니다: 코어 메모리(작고 항상 컨텍스트에 포함됨), 회상 메모리(검색 가능한 대화 이력), 아카이브 메모리(장기 콜드 스토리지). 모든 메모리가 동일하지 않다는 통찰은 옳았습니다. 하지만 구현 측면에서 에이전트가 완전히 Letta 런타임 내에서 실행되어야 합니다. 즉, 이를 채택한다는 것은 메모리 레이어뿐만 아니라 플랫폼 전체를 채택하는 것을 의미합니다.

Zep / Graphiti는 시간적 엔티티 추적(temporal entity tracking)을 통한 대화 메모리에 집중합니다. 사실(fact)에 유효 기간을 부여하여 그래프가 어떤 정보가 언제 사실이었는지 알 수 있게 합니다. 관계 그래프가 필요한 챗봇에는 강력하지만, 환경적 사실과 프로젝트 관례를 추적해야 하는 자율 에이전트에는 덜 적합합니다.

Cognee는 문서와 구조화된 데이터로부터 지식을 추출하기 위해 구축되었으며, 30개 이상의 인제스션 커넥터와 지식 그래프 백엔드를 갖추고 있습니다. 기관 지식과 RAG 파이프라인에 탁월하지만, 개인 에이전트 메모리에는 덜 집중합니다. 실질적인 설정 가이드는 self-hosting Cognee with local LLMs를 참조하세요.

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

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

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

대부분의 프레임워크에 흐르는 공통적인 맥락은 메모리를 ‘검색 문제’로 취급한다는 것입니다. 어딘가에 저장하고, 필요할 때 쿼리하고, 컨텍스트에 주입하는 방식입니다. Hermes는 이와 반대로 작동합니다. 메모리는 필요할 때 검색하는 것이 아니라, 세션 시작 시 주입되어 항상 존재합니다. 항상 활성화되어 있고, 항상 사용 가능하며, 유용성을 유지할 수 있도록 충분히 큐레이션되어 있습니다.

Part 2: 아키텍처

이 부분은 위에서 아래로 읽어주세요 — 레이어와 턴당 회상/저장(recall/store)을 먼저 읽고, 그다음 MEMORY.md와 USER.md에 무엇이 들어가는지, 마지막으로 외부 제공자를 어떻게 연결하는지 확인하십시오.

두 개의 레이어

Hermes는 메모리를 두 개의 레이어로 쌓습니다.

내장형(Built-in) — MEMORY.md 및 USER.md. 파일 기반이며 항상 활성화되어 있습니다. 각각 2,200자(에이전트 노트)와 1,375자(사용자 프로필)의 엄격한 제한이 있습니다.
외부 제공자 하나 (선택 사항) — Honcho, OpenViking, Mem0, Hindsight, Holographic, RetainDB, ByteRover, Supermemory 및 설정을 통해 활성화할 수 있는 유사 서비스들입니다. 한 번에 단 하나의 외부 백엔드만 실행됩니다. 이는 파일 외에 검색 및 유지 기능을 추가하는 것이지, 파일을 대체하는 것이 아닙니다.

이 모델은 가산적(additive)인 개념 모델입니다. 고정된 코어 파일에 최대 하나의 플러그인을 더하는 방식입니다. Prefetch 및 sync 훅이 외부 레이어를 조율하며, 두 개의 내장 파일은 고정된 시스템 프롬프트의 일부로서 별도로 주입된 상태를 유지합니다.

런타임 흐름 (prefetch 및 sync)

회상(recall)은 모델이 답변하기 전에 발생하며, 저장(persistence)은 어시스턴트 메시지가 생성된 후에 발생합니다. Hermes Agent의 메모리 매니저에서는 들어오는 단계의 prefetch와 나가는 단계의 sync로 매핑됩니다. 아래의 이름들은 실제 구현체(MemoryManager, 각 제공자별 prefetch / sync_turn / queue_prefetch)와 일치합니다.

User message
    |
    v
MemoryManager.prefetch_all(query)        <-- 회상 단계 (recall phase)
    |
    +-- provider.prefetch(query)        <-- 각 외부 제공자가 자신의 저장소를 검색
    |
    v
Context injected into LLM turn
    |
    v
LLM responds (assistant message)
    |
    v
MemoryManager.sync_all(user, assistant)  <-- 저장 단계 (store phase)
    |
    +-- provider.sync_turn(user, assistant)
    +-- provider.queue_prefetch(user)    <-- 다음 턴을 위한 백그라운드 검색

내장된 MEMORY.md와 USER.md는 prefetch_all을 통해 가져오지 않습니다. 이들은 이미 고정된 시스템 프롬프트의 일부입니다. 외부 백엔드는 prefetch_all / sync_all에 연결됩니다. queue_prefetch를 통해 제공자는 현재 응답을 차단하지 않고 다음 턴을 위한 검색을 미리 준비(warm)할 수 있습니다.

장기 메모리로 들어가는 세 가지 경로

내장 memory 도구. 지침에서 무언가 지속되어야 한다고 명시될 때(지속적인 사실, 선호도, 수정 사항, 환경 노트 등), 모델은 add, replace, 또는 remove와 함께 memory를 호출합니다. target='user'는 USER.md를 유지하고, target='memory'는 MEMORY.md를 유지합니다. 예시 형태: memory(action='add', target='user', content='…').
외부 제공자의 수동적 유지(Passive retention). 매 턴마다 프레임워크는 제공자의 sync 경로를 호출합니다. 이를 통해 모델이 모든 사실을 일일이 언급하지 않아도 대화 내용을 청크(chunk)로 나누거나, 요약하거나, 추출할 수 있습니다. 동작 방식은 백엔드마다 다릅니다. 예를 들어 Hindsight는 턴을 배치(batch)로 처리하고 엔티티 및 관계를 기반으로 구조화된 유지를 수행하며, Honcho는 대화를 변증법적 파이프라인을 통해 전달하고, Mem0 및 Supermemory 스타일의 스택은 턴에서 사실을 수동적으로 추출합니다.
제공자 전용 도구. 플러그인이 이를 노출하는 경우, honcho_conclude, hindsight_retain, 또는 honcho_profile과 같은 명시적인 쓰기 작업을 통해 필요할 때마다 내구성이 있는 데이터 조각을 저장할 수 있습니다.

자동 회상 vs 제공자 도구

코어 메모리는 읽기 도구가 필요 없습니다. 이미 프롬프트에 포함되어 있기 때문입니다. 외부 백엔드는 prefetch를 통한 자동 주입(해당 컨텍스트 조각을 위해 별도의 회상 도구 호출이 필요 없음)을 제공하거나, 모델이 prefetch만으로는 부족한 더 정밀한 쿼리가 필요할 때 명시적인 검색 도구(honcho_search, honcho_reasoning, honcho_context, hindsight_recall, hindsight_reflect 등)를 제공합니다.

회상 모드 (외부 제공자)

플러그인은 토큰과 제어권 사이의 절충안인 구성 가능한 회상 모드(보통 설정의 memory.provider 옆에 있는 recall_mode)를 지원합니다.

모드	prefetch로부터 자동 주입	제공자 도구 사용 가능	적합한 경우
context	예	아니오	수동 개입이 필요 없는 예측 가능한 컨텍스트
tools	아니오	예	모델이 직접 검색 시점을 선택
hybrid	예	예	가장 풍부한 컨텍스트; 토큰 사용량 높음

외부 제공자가 설정되지 않은 경우(memory.provider가 비어 있거나 설정되지 않음), 내장 파일과 세션 검색만 적용되며 플러그인을 통한 prefetch/sync는 작동하지 않습니다.

디스크 경로 및 예산

Hermes Agent의 내장 메모리는 두 개의 파일에 저장됩니다.

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

이것이 전체 지속성 메모리 영역입니다. 총 3,600자 미만, 1,300 토큰 미만입니다. 의도적으로 작게 설계되었으며, 이것이 바로 설계 의도입니다.

MEMORY.md: 에이전트의 노트

에이전트가 환경, 프로젝트, 도구, 관례, 그리고 배운 교훈에 대해 알아낸 모든 것을 저장하는 곳입니다. 다음과 같은 형태를 띱니다.

User's project is a Go microservice at ~/code/gateway using gRPC + PostgreSQL
This machine runs Ubuntu 22.04, has Docker and kubectl installed
User prefers snake_case for variable names and avoids camelCase

이것은 로그가 아닙니다. 사실(fact)입니다. 밀도 높고, 선언적이며, 정보가 가득 차 있습니다. 타임스탬프도, 군더더기도, “1월 5일에 사용자가 저에게 ~라고 요청했습니다"와 같은 표현도 없습니다.

USER.md: 사용자 프로필

에이전트가 당신에 대해 알고 있는 모든 것을 저장하는 곳입니다.

User is a full-stack developer comfortable with TypeScript, Go, and Python.
User prefers snake_case for variable names and avoids camelCase.
User primarily uses Linux Ubuntu 22.04.
User deploys to AWS using Terraform.

정체성, 역할, 선호도, 기술적 능력, 소통 스타일, 싫어하는 점 등입니다. 에이전트가 다른 누구와 대화할 때와 다르게 당신에게 반응하도록 만드는 요소들입니다.

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

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

══════════════════════════════════════════════
MEMORY (your personal notes) [7% — 166/2,200 chars]
══════════════════════════════════════════════
User's project is a Go microservice at ~/code/gateway using gRPC + PostgreSQL
§
This machine runs Ubuntu 22.04, has Docker and kubectl installed
§
User prefers snake_case for variable names and avoids camelCase
§

══════════════════════════════════════════════
USER PROFILE (who the user is) [8% — 110/1,375 chars]
══════════════════════════════════════════════
User is a full-stack developer comfortable with TypeScript, Go, and Python.
§
User prefers snake_case for variable names and avoids camelCase.
§

이 형식은 헤더, 사용률, 글자 수, 그리고 § (섹션 기호) 구분자를 사용합니다. 항목은 여러 줄로 작성될 수 있습니다. 모델이 파싱하기 쉬우면서도 사람이 읽기 좋도록 설계되었습니다.

왜 고정(frozen)할까요? 바로 Prefix caching 때문입니다. 시스템 프롬프트는 세션 내의 모든 턴에서 동일합니다. 세션 시작 후 메모리를 정적으로 유지함으로써, 모델은 프리픽스 계산을 캐싱하고 가변적인 부분(대화 내용)만 처리할 수 있습니다. 이는 상당한 성능 최적화입니다. 매 턴마다 동일한 메모리 토큰에 대해 어텐션(attention)을 다시 계산할 필요가 없습니다.

세션 중에 변경된 사항은 즉시 디스크에 저장되지만, 시스템 프롬프트에는 다음 세션 시작 시에만 나타납니다. 도구 응답은 항상 실시간 상태를 보여주지만, 모델의 “마음"은 세션 도중에 바뀌지 않습니다. 이는 모델이 메모리를 업데이트한 후 같은 대화 내에서 그 업데이트에 다시 반응하는, 즉 자기 꼬리를 쫓는 현상을 방지합니다.

기능으로서의 글자 수 제한

2,200자. 1,375자. 이것은 임의적인 제한이 아닙니다. 큐레이션을 강제하기 위한 설계 제약 조건입니다.

무제한 메모리는 오히려 약점이 됩니다. 모든 것을 쏟아붓게 만들고, 결코 통합하지 않으며, 결국 노이즈가 됩니다. 제한된 메모리는 에이전트가 선택적으로 행동하도록 강제합니다. 무엇이 정말 중요한가? 무엇을 나중에 다시 필요로 할 것인가? 의미를 잃지 않고 압축할 수 있는 것은 무엇인가?

메모리가 가득 차면 에이전트는 그냥 조용히 실패하는 것이 아닙니다. 현재 항목과 사용량을 포함한 에러를 반환한 후 다음 워크플로우를 따릅니다.

에러 응답에서 현재 항목을 읽음
삭제하거나 통합할 수 있는 항목 식별
replace를 사용하여 관련 항목을 짧은 버전으로 병합
새 항목 추가

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

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

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

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

외부 메모리 제공자 (활성화 및 링크)

내장된 MEMORY.md 및 USER.md 외에도, Hermes Agent는 세션을 초월하는 지속적인 지식을 위해 한 번에 하나의 외부 메모리 플러그인(Honcho, OpenViking, Mem0, Hindsight, Holographic, RetainDB, ByteRover 또는 Supermemory)을 연결할 수 있습니다. 한 번에 하나의 외부 제공자만 활성화되며, 두 개의 핵심 파일은 그와 함께 로드된 상태를 유지합니다(대체하는 것이 아니라 가산적인 방식).

hermes memory setup, hermes memory status, hermes memory off로 제공자를 활성화하고 점검하거나, ~/.hermes/config.yaml에서 memory.provider 및 recall_mode를 설정할 수 있습니다. 자격 증명 패턴은 다를 수 있습니다(예: HINDSIGHT_API_KEY, $HERMES_HOME/honcho.json 아래의 Honcho 키). 대화형 설정을 위해 hermes memory setup을 사용하세요.

최소한의 내장 전용 YAML 형태:

memory:
  provider: ""
  memory_enabled: true
  user_profile_enabled: true

하나의 백엔드 활성화 예시 (hindsight를 설치된 다른 서비스인 honcho, mem0, `supermemory 등으로 교체):

memory:
  provider: "hindsight"

전체 비교 표, LLM 및 임베딩 의존성 노트, 제공자별 상세 분석, 그리고 이러한 백엔드가 OpenClaw 및 다른 스택과 어떻게 연관되는지는 **Agent memory providers compared**를 참조하십시오.

프로필별 연결 설정 및 프로덕션 워크플로우는 Hermes Agent production setup을 참조하십시오. **AI Systems Memory hub**에는 이 가이드와 관련된 Cognee 및 지식 레이어 기사들이 목록화되어 있습니다.

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

Hermes Agent의 메모리에 대해 가장 많이 받는 질문은 “도대체 언제 실제로 무언가를 저장하는가?“입니다.

답은 “끊임없이, 하지만 선택적으로"입니다. 에이전트는 memory 도구를 통해 자신의 메모리를 직접 관리하며, 저장 결정은 명시적인 신호와 암묵적인 패턴의 조합에 의해 이루어집니다.

쓰기 트리거: 에이전트는 언제 저장하기로 결정하는가?

에이전트는 선제적으로 메모리를 저장합니다. 사용자가 요청할 때까지 기다리지 않습니다. 다음은 이를 트리거하는 요소들입니다.

사용자의 수정 사항. 사용자가 에이전트를 수정하면, 그것은 기억해야 한다는 신호입니다. “다시는 그렇게 하지 마세요.” “대신 이걸 사용하세요.” “이걸 기억하세요.” 이것은 메모리를 업데이트하라는 명시적인 지침입니다.

예시: 에이전트에게 Python 환경을 설정해달라고 요청합니다. 에이전트가 pip를 제안합니다. 당신이 “저는 모든 것에 poetry를 사용합니다"라고 말합니다. 에이전트는 다음과 같이 저장합니다: User prefers using the 'poetry' package manager for all Python projects.

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

예시: 여러 프로젝트에서 사용자가 poetry를 사용하는 것을 반복해서 본 후, 에이전트는 이를 선호도로 저장합니다.

환경적 사실. 기계, 프로젝트, 설치된 도구에 관한 사항입니다. 이는 탐색을 통해 발견되고 사실로 저장됩니다.

예시: 에이전트가 설치된 항목을 확인하고 다음과 같이 저장합니다: This machine runs Ubuntu 22.04, has Docker and kubectl installed.

프로젝트 관례. 프로젝트 구조, 사용하는 도구, 따르는 패턴 등입니다. 이는 코드 검사를 통해 발견되고 저장됩니다.

예시: User's project is a Go microservice at ~/code/gateway using gRPC + PostgreSQL.

완료된 복잡한 워크플로우. 5회 이상의 도구 호출이 필요한 작업을 완료한 후, 에이전트는 해당 접근 방식을 기술(skill)로 저장하거나 최소한 무엇이 효과적이었는지 기록하는 것을 고려합니다.

도구의 특이점 및 해결책. 에이전트가 도구, API 또는 시스템에 대해 명확하지 않은 부분(제한 사항, 해결책, 관례 등)을 발견하면 이를 저장합니다.

건너뛰는 항목:

사소하거나 뻔한 정보
쉽게 다시 발견할 수 있는 내용
가공되지 않은 데이터 덤프
세션 전용의 일시적인 정보
이미 컨텍스트 파일(SOUL.md, AGENTS.md)에 있는 정보

읽기 트리거: 에이전트는 언제 회상하는가?

메모리는 검색하는 것이 아니라 항상 그곳에 있습니다. 하지만 접근 수준에는 차이가 있습니다.

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

session_search (요청 시). 에이전트가 코어 메모리에 없는 과거 대화 내용을 찾아야 할 때 session_search 도구를 사용합니다. 이는 FTS5 전체 텍스트 검색과 Gemini Flash 요약을 사용하여 SQLite(~/.hermes/state.db)를 쿼리합니다. 질문이 “이 사실을 영원히 기억해 줘"라기보다는 “우리 전에 이거 얘기했었지?“와 같은 느낌일 때 사용하십시오.

예시: “지난주에 Docker 네트워킹에 대해 논의했었나요?“라고 물으면, 에이전트는 세션 이력을 검색하여 관련 대화의 요약을 반환합니다.

외부 제공자 도구 (설정된 경우). 외부 메모리 제공자가 활성화되면, 프레임워크는 각 응답 전에 자동 prefetch 단계를 실행합니다(Part 2 참조). honcho_search, hindsight_recall, 또는 mem0_search와 같은 추가 도구는 에이전트가 명시적인 검색을 선택할 때 대상 조회를 위해 사용됩니다. recall_mode에 따라 자동 주입, 도구, 또는 둘 다가 활성화될 수 있습니다.

결정 트리 (Decision Tree)

에이전트는 “이것이 기억할 가치가 있는가?“를 다음과 같이 판단합니다.

이것이 수정 사항이나 명시적 지침인가?
  YES → 메모리에 저장
  NO → 이것이 선호도나 패턴인가?
    YES → 사용자 프로필에 저장
    NO → 이것이 환경적 사실이나 관례인가?
      YES → 메모리에 저장
      NO → 이것이 쉽게 다시 발견될 수 있는가?
        YES → 건너뜀
        NO → 이것이 세션 전용인가?
          YES → 건너뜀
          NO → 메모리에 저장

에이전트는 이를 너무 깊게 고민하지 않습니다. 선제적으로 저장하고, 가득 차면 통합하며, 글자 수 제한을 통해 내용을 간결하게 유지합니다.

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

이 부분에서 종종 혼란이 발생합니다. Hermes Agent에는 내부 메모리(MEMORY.md, USER.md, 외부 제공자)와 외부 지식 베이스(LLM Wiki, Obsidian, Notion, ArXiv, 파일 시스템)가 있으며, 이들은 완전히 다른 역할을 수행합니다. 이는 retrieval-augmented generation 파이프라인과 에이전트 작업 메모리(working memory)의 차이와 유사합니다. 외부 검색은 깊은 지식 조회를 위한 것이지, 정체성과 선호도를 유지하기 위한 것이 아닙니다니다. 내부 메모리는 에이전트의 ‘뇌’입니다. 항상 활성화되어 있고, 큐레이션되며, 모든 세션으로 전달됩니다. 외부 지식 베이스는 에이전트의 ‘도서관’입니다. 필요할 때 요청하여 참조하는 방대한 참조 자원입니다.

차이점

내부 메모리 (뇌):

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

외부 지식 베이스 (도서관):

방대하며 참조 전용임, 요청 시 접근
포함 내용: 문서, 논문, 코드, 노트, 데이터베이스
필요할 때 도구를 통해 접근
“기억"하는 것이 아니라 “찾아보는” 것
예시: LLM Wiki, Obsidian, Notion, ArXiv, 파일 시스템, GitHub

상호 관계

에이전트는 필요할 때 도구를 통해 외부 베이스에 접근합니다. 그것을 “기억"하는 것이 아니라 “찾아보는” 것입니다.

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

Obsidian: 양방향 링크가 있는 개인 노트 저장소입니다. 에이전트는 obsidian 스킬을 사용하여 노트를 읽고, 검색하고, 생성합니다. Obsidian은 Hermes가 라이브러리 자원으로 활용할 수 있는 광범위한 personal knowledge management 생태계의 일부입니다.

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

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

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

정제 패턴 (The Distillation Pattern)

핵심 통찰력은 이것입니다: 외부 베이스의 중요한 통찰력은 내부 메모리로 *정제(distilled)*될 수 있습니다.

예시: 에이전트가 AI 에이전트의 메모리 스케일링에 관한 ArXiv 논문을 읽습니다. 논문 전체를 메모리에 저장하지는 않습니다. 핵심 요약만 저장합니다: Memory scaling: agent performance improves with accumulated experience through user interaction and business context stored in memory.

외부 리소스는 방대하지만, 내부 메모리는 그 정제된 결과물입니다.

어떤 것을 사용할 것인가

내부 메모리는 다음의 경우에 사용합니다:

“내가 누구를 돕고 있는가?”
“그들이 무엇을 선호하는가?”
“방금 무엇을 배웠는가?”
“프로젝트 설정은 어떠한가?”
“어떤 도구를 사용할 수 있는가?”

외부 지식 베이스는 다음의 경우에 사용합니다:

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

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

Part 5: 실제 작동 방식

메커니즘을 살펴보겠습니다.

`memory` 도구

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

read 액션은 없습니다. 메모리 내용은 시스템 프롬프트에 자동으로 주입됩니다. 에이전트는 메모리를 읽을 필요가 없습니다. 항상 그곳에 있기 때문입니다.

add — 새로운 항목을 추가합니다.

memory(action="add", target="memory",
       content="User runs macOS 14 Sonoma, uses Homebrew, has Docker Desktop installed.")

replace — 부분 문자열 매칭(substring matching)을 사용하여 기존 항목을 교체합니다.

memory(action="replace", target="memory",
       old_text="dark mode",
       content="User prefers light mode in VS Code, dark mode in terminal")

remove — 부분 문자열 매칭을 사용하여 항목을 제거합니다.

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

부분 문자열 매칭 (Substring Matching)

replace와 remove는 old_text를 통해 짧고 고유한 부분 문자열을 사용합니다. 전체 항목 텍스트를 입력할 필요가 없습니다. 이를 통해 정확한 내용을 몰라도 정밀한 편집이 가능합니다.

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

대상 저장소: `memory` vs `user`

target 매개변수는 어떤 파일이 업데이트될지를 결정합니다.

memory — 에이전트의 개인 노트. 환경적 사실, 프로젝트 관례, 도구의 특이점, 배운 교훈 등.
user — 사용자 프로필. 정체성, 역할, 시간대, 소통 선호도, 싫어하는 점, 워크플로우 습관 등.

용량 관리

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

좋은 메모리 항목은 압축적이고 정보 밀도가 높아야 합니다:

User runs macOS 14 Sonoma, uses Homebrew, has Docker Desktop installed. Shell: zsh with oh-my-zsh. Editor: Neovim with Telescope plugin.

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

User has a project.
On January 5th, 2026, the user asked me to look at their project which is located at ~/code/gateway and it uses Go with gRPC and PostgreSQL for the database layer.

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

세션 검색 vs 지속성 메모리

session_search와 지속성 메모리는 서로 다른 목적을 위해 존재합니다.

기능	지속성 메모리 (Persistent Memory)	세션 검색 (Session Search)
용량	총 약 1,300 토큰	무제한 (모든 세션)
속도	즉시 (시스템 프롬프트 내)	검색 + LLM 요약 필요
사용 사례	항상 사용 가능한 핵심 사실	특정 과거 대화 찾기
관리	에이전트에 의해 수동 큐레이션됨	자동 — 모든 세션 저장
토큰 비용	세션당 고정 (~1,300 토큰)	요청 시 발생 (필요할 때 검색)

원칙: 항상 컨텍스트에 있어야 하는 핵심 사실에는 메모리를 사용하십시오. 과거 이력을 찾아야 할 때는 세션 검색을 사용하십시오.

Part 6: 철학

왜 제한된 메모리가 무제한 메모리보다 나은가

본능적으로는 메모리를 가능한 한 크게 만들고 싶어질 것입니다. 모든 것을 저장하고 필요할 때 가져오고 싶어 합니다.

하지만 제한된 메모리가 더 효과적입니다. 그 이유는 다음과 같습니다.

큐레이션은 품질을 강합니다. 공간이 제한되면 중요한 것만 저장하게 됩니다. 압축하고, 통합하고, 우선순위를 정게 됩니다. 무제한 메모리는 모든 것을 쏟아붓고 전혀 정리하지 않게 만듭니다.

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

노이즈는 성능을 저하시킵니다. 메모리가 많다고 해서 더 좋은 메모리는 아닙니다. 그것은 더 노이즈가 심한 메모리일 뿐입니다. 모델은 신호와 노이즈를 구분해야 하며, 여기에는 실제 작업에 써야 할 어텐션이 소모됩니다.

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

“망각"의 문제

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

Hermes Agent는 이를 다음과 같이 처리합니다.

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

망각은 실패가 아니라 유지보수입니다. 배울 수 없는(지울 수 없는) 에이전트는 결국 신호만큼이나 많은 노이즈를 떠안게 될 것입니다.

메모리 스케일링

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

그들의 연구에 따르면 그렇지만, 몇 가지 전제 조건이 있습니다. 메모리 스케일링을 위해서는 다음이 필요합니다:

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

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

이것이 미래에 의미하는 바

메모리는 에이전틱 AI의 경쟁력 있는 해자(moat)가 되고 있습니다. 모델 자체가 아니라, 모델이 세션 사이를 어떻게 가져가느냐가 핵심입니다. 동일한 기반 모델을 가진 두 에이전트라도 성능은 매우 다를 수 있습니다. 하나는 당신의 선호도, 환경, 과거의 실수를 기억하지만, 다른 하나는 매번 차갑게 새로 시작합니다.

에이전트가 지속성 메모리를 가져야 하는가에 대한 질문은 이제 끝났습니다. 그것은 필수입니다. 남은 질문은 그 메모리를 어떻게 잘 설계할 것인가입니다. 무엇을 유지하고, 무엇을 버릴 것인가, 어떻게 즉각적으로 만들 것인가, 그리고 어떻게 노이즈가 되는 것을 방지할 것인가에 대한 문제입니다.

Hermes Agent의 답은 메모리를 작고, 큐레이션된 상태로, 항상 활성화된 상태로 유지하는 것입니다. 쿼리하는 데이터베이스가 아니라, 에이전트가 모든 대화로 가져가는 사용자의 작동 모델(working model)을 만드는 것입니다.

결론

Hermes Agent의 메모리 시스템은 의도적으로 단순합니다. 두 개의 파일, 엄격한 글자 수 제한, 검색 파이프라인 없음, vector database 없음, 그리고 쿼리당 지연 시간 없음. 제약처럼 보이는 이 요소들이 바로 핵심입니다.

이것이 작동하는 이유는 메모리를 데이터베이스처럼 다루는 대신 뇌가 작동하는 방식—작고, 큐레이션되며, 항상 활성화된 방식—으로 다루기 때문입니다. 에이전트는 필요할 때 메모리를 검색하지 않습니다. 메모리는 모든 세션의 첫 번째 토큰부터 시스템 프롬프트에 엮여 항상 그곳에 있습니다.

외부 메모리 제공자는 지식 그래프, 멀티 에이전트 지원, 셀프 호스팅 스토리지, 기업용 기능 등 더 많은 것을 필요로 하는 사용자를 위해 이 시스템을 확장합니다. 하지만 코어는 동일하게 유지됩니다. 제한적이고, 큐레이션되며, 항상 사용 가능한 상태입니다.

그리고 외부 지식 베이스—LLM Wiki, Obsidian, Notion, ArXiv—는 다른 역할을 수행합니다. 그것들은 도서관이지 뇌가 아닙니다. 에이전트는 그것들을 찾아볼 뿐, 기억하지 않습니다. 중요한 통찰력은 내부 메모리로 정제되며, 나머지는 도서관에 남습니다.

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

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