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

알다시피, AI 에이전트와 채팅을 열면 프로젝트를 설명하고 선호 사항을 공유하며 작업을 진행한 뒤 탭을 닫습니다. 다음 주에 다시 돌아와 보면 낯선 이와 대화하는 듯한 기분이 듭니다. 모든 컨텍스트가 사라지고, 모든 선호 사항은 잊혀졌으며, 프로젝트는 처음부터 다시 설명해야 합니다.

이는 버그가 아닙니다. 대규모 언어 모델(LLM)이 의도적으로 설계된 방식입니다. 이들은 상태가 없습니다(stateless). 각 요청은 독립적이며, 각 응답은 현재 컨텍스트 창(token window) 내에 있는 토큰을 제외하고는 메모리나 역사성, 연속성 없이 지금 보낸 프롬프트에 기반하여 생성됩니다.

단회(turn) 상호작용이라면 이 방식도 무방합니다. 질문을 하고 답변을 얻은 뒤 다음 단계로 넘어가면 됩니다. 하지만 세션 간에 작업을 수행하고, 실수로부터 학습하며, 사용자와 함께 진화해야 하는 에이전트 시스템에는 상태 부재(statelessness)는 심각한 아키텍처 한계입니다. 이는 셀프 호스팅 AI 시스템에서 해결되지 않은 핵심 문제 중 하나입니다.

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

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

Hermes Agent는 근본적으로 다른 접근 방식을 취합니다. 메모리는 에이전트가 필요할 때 검색하는 것이 아닙니다. 에이전트가 매 순간 가지고 있는 것입니다. 시스템 프롬프트에 구축되어 관리되고, 범위가 제한되며, 항상 활성화됩니다. 속도가 빠를 만큼 작고, 유용할 만큼 구조화되어 있으며, 무엇을 잊어야 하는지 알 만큼 분별력이 있습니다.

이 글에서는 AI 어시스턴트의 메모리 시스템의 크로스프레임워크 모델 내부에 있는 Hermes 전용 레이어와 AI 어시스턴트 아키텍처의 더 넓은 스택이 어떻게 작동하는지 정확히 설명합니다. 활성화 및 검사 명령어(hermes memory, hermes dump, 로그 테일링)는 Hermes Agent CLI 치트시트와 함께 사용하십시오. Hermes의 “장기 지식(long-term knowledge)” 측면, 즉 관리된 메모리 파일이 아닌 SKILL.md에 있는 재사용 가능한 절차에 대해서는 Hermes Agent 스킬 저작 — SKILL.md 구조 및 모범 사례를 참조하십시오.

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

에이전트에게 “컨텍스트만 추가하면” 되는 이유

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

일段时间 동안은 이 방법이 통합니다. 128K 컨텍스트 창을 가지고 있으므로 많은 텍스트를 넣을 수 있습니다.

하지만 컨텍스트는 메모리가 아닙니다. 둘 사이에는 실제적이고 중요한 차이가 있습니다. 컨텍스트는 지금 보여주고 있는 모든 것이며, 메모리는 능동적으로 유지하고 전달하는 것입니다.

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

메모리는 큐레이션된 것입니다. 경험의 응축물로, 작고 실행 가능한 형태입니다. 무한정 성장하지 않습니다. 통합되고, 업데이트되며, 잊혀집니다.

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

연구 현황

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

Letta(전 MemGPT)는 영속적 메모리를 1급 관심사항으로 취급한 초기 프레임워크 중 하나로, GitHub 스타 21.7K를 기록했습니다. 이는 OS에서 영감을 받은 3층 모델을 사용합니다: 핵심 메모리(작고, 항상 컨텍스트 내에 있음), 회상 메모리(검색 가능한 대화 기록), 아카이브 메모리(장기 냉각 저장소). 모든 메모리가 동일하지 않다는 통찰은 정확했습니다. 그러나 구현 측면에서 에이전트는 완전히 Letta 런타임 내부에서 실행되어야 합니다. 이를 채택한다는 것은 메모리 레이어가 아닌 전체 플랫폼을 채택한다는 것을 의미합니다.

Zep / Graphiti는 시간적 엔티티 추적을 갖춘 대화형 메모리에 초점을 맞춥니다. 사실에는 유효성 창(validity windows)이 있어 그래프가 특정 사실이 참이었던 시기를 알 수 있습니다. 이는 관계 그래프가 필요한 챗봇에는 강점이 있지만, 환경 사실과 프로젝트 관례를 추적하는 자율 에이전트에는 적합하지 않습니다.

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

Hindsight는 엔티티 관계와 교차 메모리 합성(cross-memory synthesis)을 수행하여 여러 메모리를 새로운 통찰력으로 결합하는 고유한 reflect 합성 도구를 갖춘 지식 그래프 기반 회상을 수행합니다. 에이전트 메모리 벤치마크에서 상위 퍼포머 중 하나이며, Hermes Agent의 메모리 프로바이더로 제공됩니다.

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

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

대부분의 프레임워크가 공유하는 공통점은 메모리를 검색 문제로 취급한다는 것입니다. 어딘가에 저장하고, 필요할 때 쿼리하며, 컨텍스트에 주입합니다. Hermes는 정반대를 추구합니다. 메모리는 온디맨드로 검색되지 않고, 세션 시작 시 주입되어 항상 존재합니다. 항상 활성화되어, 항상 사용 가능하며, 유용하게 유지되도록 큐레이션됩니다.

Part 2: 아키텍처

이 부분은 위에서 아래로 읽으십시오. 레이어 및 턴별 recall/store를 먼저, 그리고 MEMORY.md 및 USER.md에 무엇이 있는지를 다음으로, 마지막으로 외부 프로바이더를 연결하는 방법을 살펴보십시오.

두 개의 레이어

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

1. 내장(Built-in) — MEMORY.md와 USER.md, 파일 기반, 항상 활성화됨. 에이전트 메모리는 2,200자, 사용자 프로파일은 1,375자로 하드 캡(hard cap)이 설정되어 있습니다.
2. 외부 프로바이더 1개(선택 사항) — Honcho, OpenViking, Mem0, Hindsight, Holographic, RetainDB, ByteRover, Supermemory 및 구성을 통해 활성화하는 동료들. 외부 백엔드는 하나만 동시에 실행됩니다. 이는 파일들을 대체하지 않고 파일 옆에 검색과 지속성을 추가합니다.

정신적 모델(additive model)은 고정된 핵심 파일과 최대 하나의 플러그인의 조합입니다. 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
LLM 턴에 컨텍스트 주입
    |
    v
LLM 응답 (어시스턴트 메시지)
    |
    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)할 수 있게 해줍니다.

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

1. 내장 memory 도구. 모델이 지시사항에 따라 지속되어야 할 사항(견고한 사실, 선호 사항, 수정 사항, 환경 메모)이 있을 때 add, replace, 또는 remove와 함께 memory를 호출합니다. target='user'는 USER.md를 관리하고, target='memory'는 MEMORY.md를 관리합니다. 예제 형태: memory(action='add', target='user', content='…').

2. 외부 프로바이더의 수동 지속성(Passive retention). 프레임워크는 매 턴마다 프로바이더의 sync 경로를 호출하여 모델이 모든 사실을 명시하지 않아도 대화의 청크화, 요약, 또는 추출이 가능합니다. 동작은 백엔드에 따라 다릅니다. 예를 들어 Hindsight는 턴을 배치로 묶고 엔티티와 관계로 구조화된 지속성을 실행하며, Honcho는 대화를 그 논증 파이프라인(dialectic pipeline)을 통해 전송하고, Mem0 및 Supermemory 스타일의 스택은 턴에서 사실을 수동으로 추출합니다.

3. 프로바이더 전용 도구. 플러그인이 이를 노출할 때, honcho_conclude, hindsight_retain, 또는 honcho_profile과 같은 명시적 쓰기 작업은 온디맨드로 견고한 스lice를 저장합니다.

자동 recall과 프로바이더 도구

핵심 메모리에는 읽기 도구가 필요 없습니다. 이미 프롬프트에 있기 때문입니다. 외부 백엔드는 prefetch에서의 자동 주입(해당 컨텍스트 슬라이스에 대한 별도의 recall 도구 호출 없음) 또는 모델이 prefetch 단독보다 더 날카로운 쿼리가 필요할 때의 명시적 검색 도구(honcho_search, honcho_reasoning, honcho_context, hindsight_recall, hindsight_reflect 및 동료들)를 추가합니다.

Recall 모드(외부 프로바이더)

플러그인은 제어와 토큰을 트레이드오프하는 구성 가능한 recall 모드(일반적으로 config에서 memory.provider 옆에 있는 recall_mode)를 지원합니다.

외부 프로바이더가 설정되지 않은 경우(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

이것들은 로그가 아닙니다. 사실입니다. 밀도 높고, 선언적이며, 정보가 풍부한. 타임스탬프도, 불필요한 내용도, “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.

정체성, 역할, 선호 사항, 기술적 기술, 커뮤니케이션 스타일, 싫어하는 것들(pet peeves). 에이전트가 당신에게 다른 누구에게 반응하는 것과 다르게 반응하게 만드는 것들입니다.

고정 스냅샷 패턴(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.
§

이 형식은 헤더, 사용률, 문자 수 및 §(section sign) 구분자를 사용합니다. 엔트리는 다중 라인일 수 있습니다. 모델에서 파싱 가능하면서도 사람이 읽을 수 있도록 설계되었습니다.

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

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

기능으로서의 문자 제한

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

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

메모리가 가득 차면 에이전트는 침묵으로 실패하지 않습니다. 현재 엔트리와 사용량과 함께 오류를 받으며, 다음과 같은 워크플로우를 따릅니다:

1. 오류 응답에서 현재 엔트리 읽기
2. 제거하거나 통합할 수 있는 엔트리 식별
3. replace를 사용하여 관련 엔트리를 더 짧은 버전으로 병합
4. 새 엔트리 추가

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

보안: 프롬프트 인젝션 스캔

각 메모리 엔트리는 수용 전에 스캔됩니다. 시스템은 프롬프트 인젝션 시도, 자격 증명 유출, 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 키); 대화식 와이링(wiring)에 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개 이상의 도구 호출이 걸린 작업을 완료한 후, 에이전트는 접근 방식을 스킬로 저장하거나 작동한 것을 기록하는 것을 고려합니다.

도구의 특이점과 우회책. 에이전트가 도구, API, 또는 시스템에 대해 직관적이지 않은 것(제한, 우회책, 관례)을 발견하면 저장합니다.

건너뛰는 것:

• 사소하거나 명확한 정보
• 쉽게 다시 발견할 수 있는 것
• 원시 데이터 덤프
• 세션 전용 에피메라(ephemera)
• 컨텍스트 파일(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에 따라 자동 주입, 도구, 또는 둘 다 활성화될 수 있습니다.

결정 트리

에이전트가 “이것은 기억할 가치가 있는가?“를 가중하는 방법:

Is this a correction or explicit instruction?
  YES → Save to memory
  NO → Is this a preference or pattern?
    YES → Save to user profile
    NO → Is this an environment fact or convention?
      YES → Save to memory
      NO → Is this easily re-discovered?
        YES → Skip
        NO → Is this session-specific?
          YES → Skip
          NO → Save to memory

에이전트는 이를 과도하게 생각하지 않습니다. 능동적으로 저장하고, 가득 차면 통합하며, 문자 제한이 내용을 간결하게 유지하도록 신뢰합니다.

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

혼란이 자주 발생하는 곳입니다. Hermes Agent는 내부 메모리(MEMORY.md, USER.md, 외부 프로바이더)와 외부 지식 베이스(LLM Wiki, Obsidian, Notion, ArXiv, 파일시스템)를 가지고 있으며, 이들은 완전히 다른 역할을 수행합니다. 이는 검색 강화 생성(retrieval-augmented generation) 파이프라인과 에이전트 작업 메모리 사이의 구분에類似합니다. 외부 검색은 깊은 지식 조회에는 좋지만, 정체성과 선호 사항을 운반하는 데는 적합하지 않습니다. 내부 메모리는 에이전트의 뇌입니다 — 항상 활성화되고, 큐레이션되며, 모든 세션에 휴대됩니다. 외부 지식 베이스는 그 도서관입니다 — 필요할 때 참조하는 방대한 참조 자원.

구별

내부 메모리(뇌):

• 작고, 영속적이며, 시스템 프롬프트에 주입됨
• 포함: 사용자 선호 사항, 에이전트 관례, 즉각적인 교훈
• 대화 중 항상 “마음에” 있음
• 큐레이션되고, 제한되며, 능동적으로 관리됨
• 예제: 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: 학술 논문 저장소. 에이전트는 주제를 연구할 때 논문을 검색하고 추출합니다.

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

증류 패턴(Distillation Pattern)

여기 핵심 통찰이 있습니다: 외부 베이스에서 중요한 통찰은 내부 메모리로 증류될 수 있습니다.

예제: 에이전트는 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 — 서브스트링 매칭을 사용하여 기존 엔트리를 대체합니다.

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")

서브스트링 매칭

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.

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

세션 검색 대 영속적 메모리

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

일반 규칙: 컨텍스트에 항상 있어야 하는 중요한 사실에는 메모리를 사용하십시오. 역사적 조회에는 세션 검색을 사용하십시오.

Part 6: 철학

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

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

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

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

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

노이즈가 성능을 저하시킵니다. 더 많은 메모리가 더 나은 메모리가 아닙니다. 더 노이즈 많은 메모리입니다. 모델은 노이즈에서 신호를 구별해야 하며, 이는 실제 작업에 사용해야 할 어텐션을 소모합니다.

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

“잊는” 문제

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

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

• remove 동작: 더 이상 관련 없는 엔트리를 삭제합니다.
• replace 동작: 새로운 정보로 엔트리를 업데이트합니다.
• 용량 압력: 메모리가 가득 차면, 에이전트는 통합하고 오래된 엔트리를 제거합니다.
• 보안 스캔: 악의적이거나 손상된 엔트리를 차단합니다.

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

메모리 스케일링

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

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

1. 품질 추출: 모든 상호작용이 기억할 가치가 있는 것은 아닙니다. 에이전트는 로그가 아닌 통찰력을 추출해야 합니다.
2. 효과적 검색: 검색된 메모리는 관련성이 있어야 합니다. 노이즈는 성능을 저하시킵니다.
3. 일반화: 메모리는 특정 사항이 아닌 패턴이어야 합니다. “User prefers Python"은 확장됩니다. “User ran command X at timestamp Y"는 확장되지 않습니다.

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

이것이 미래에 의미하는 것

메모리는 에이전틱 AI에서 경쟁적 요새가 되고 있습니다 — 모델 자체가 아니라, 모델이 세션 간에 운반하는 것입니다. 동일한 기반 모델을 가진 두 에이전트는 매우 다르게 수행할 수 있습니다: 하나는 당신의 선호 사항, 환경, 과거 실수를 기억하고; 다른 하나는 매번 차가운 시작을 합니다.

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

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

결론

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

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

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

그리고 외부 지식 베이스 — 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를 참조하십시오.