LightVela 문서
요약
Hermes Agent가 사용자를 기억하는 이유는 컨텍스트 창이 커서가 아니라, 네 개의 레이어가 함께 작동하는 장기 메모리 시스템을 갖추고 있기 때문입니다. USER.md(1,375자 / 약 500토큰)는 "사용자가 누구인지"를, MEMORY.md(2,200자 / 약 800토큰)는 "함께 무엇을 했는지"를 기록합니다. SQLite + FTS5 세션 아카이브는 몇 주 전 문장도 정확히 검색할 수 있게 하고, 스킬은 "이런 작업을 어떻게 처리할지"를 담습니다. 에이전트는 압축, 체크포인트, 넛지, 명시적인 사용자 지시라는 네 시점에 메모리를 선별해 기록합니다. 회상할 때는 구조화된 기본 로딩, FTS5 정확 일치, LLM 의미 요약을 함께 사용합니다. 이 구조가 "사용자를 기억한다"는 개념을 실제 엔지니어링 기능으로 만듭니다.
대부분의 AI 비서가 당신을 실망시키는 순간
대답이 틀릴 때가 아닙니다. 다음과 같은 말을 또 해야 할 때입니다.
"지난번에 나한테 말하지 않았어?"
컨텍스트 창은 8,000토큰에서 20만, 100만 토큰까지 커졌지만, 토큰을 더 많이 넣는 것만으로는 장기 기억 문제를 해결할 수 없습니다. 한 세션에 담긴 20만 토큰의 맥락도 세션이 끝나면 사라집니다. 에이전트가 사용자를 오래 기억하려면 세 가지 질문에 답해야 합니다.
- 장기 메모리에 무엇을 쓸 가치가 있습니까? (쓰기 게이트는 어디에 있나요?)
- 메모리를 어떤 형태로 보관해야 몇 주가 지나도 찾을 수 있나요?
- 무언가를 찾아야 할 때 에이전트는 벡터 유사성에 의존합니까, 아니면 다른 것에 의존합니까?
Hermes는 완전한 장기 메모리 시스템으로 세 가지 모두에 답합니다. 아래 섹션에서는 이를 5개의 레이어로 나눕니다.
1. 먼저 '기억한다'는 의미를 정의하기
인간의 용어로 말하면, "당신을 기억하는 것"에는 적어도 세 가지가 포함됩니다.
- 사용자가 누구인지 알기 — 이름, 역할, 선호도, 자주 쓰는 도구.
- 함께 무엇을 했는지 알기 — 논의한 프로젝트, 내린 결론, 겪었던 문제.
- 사용자를 어떻게 응대할지 알기 — 짧은 답변과 자세한 답변 중 무엇을 선호하는지, 결론과 추론 중 무엇을 먼저 제시할지.
큰 컨텍스트 창만 있는 모델은 단일 대화 내에서 세 가지 작업을 모두 수행할 수 있지만 세션이 종료되는 순간 포인트 1과 3이 재설정됩니다.
Hermes의 방식은 세 정보를 각각 알맞은 영구 저장 레이어에 나누어 관리하는 것입니다. 사용자 정보는 USER.md에, 함께 수행한 작업은 MEMORY.md에 저장합니다. 사용자를 응대하는 방식은 USER.md의 선호도 필드와 Honcho의 사용자 모델링이 함께 관리합니다.
2. 쓰기: 모든 내용을 기록하지 않고 의도적으로 선별하기
Hermes의 장기 메모리는 "문장당 하나의 항목"이 아닙니다. 에이전트는 4가지 명시적인 순간에 메모리를 구성하고 유지합니다.
| 트리거 | 목적 |
|---|---|
| 압축 | 컨텍스트가 한계에 도달하면 현재 세션에서 장기 보관할 내용을 먼저 추출한 뒤 컨텍스트를 압축 |
| 체크포인트 | 하위 작업 완료나 주제 전환 같은 중요한 시점에 의도적으로 기록 |
| 넛지 | 시스템이 주기적으로 "장기 메모리에 남길 내용이 있는가?"라고 에이전트에 상기시켜 긴 세션의 정보 누락을 방지 |
| 명시적 사용자 지시 | 사용자가 "프로젝트 X에서 Y를 사용한다는 점을 기억해 줘"라고 말하면 우선순위가 높은 메모리 쓰기를 수행 |
핵심은 에이전트가 모든 내용을 저장하지 않고 무엇을 장기 메모리에 넣을지 직접 결정한다는 점입니다. 이 필터가 메모리 품질의 첫 관문이며, 모든 문장을 보관하는 채팅 기록과 구분되는 가장 근본적인 차이입니다.
구체적인 비용 계산: 해당 필터가 없으면 하루에 50번의 상호 작용을 하는 사용자는 1년 안에 약 1,800만 개의 토큰 원시 대화를 장기 메모리에 쏟아부을 것입니다. Hermes의 접근 방식은 거의 모든 주요 사실을 유지하면서 이를 1% 미만으로 압축합니다.
3. 저장: 서로 다른 역할을 맡는 네 개의 레이어
Hermes는 장기 메모리를 4가지 종류로 나눕니다. 각각은 명시적인 용량 한도를 사용하여 서로 다른 위치에 저장됩니다.
| 레이어 | 저장 위치 | 일반 용량 | 로드 시점 | 역할 |
|---|---|---|---|---|
| 사용자 프로필 | USER.md | 약 1,375자 / 500토큰 | 모든 세션 | 사용자 정체성, 역할, 선호도, 자주 쓰는 기술 스택, 소통 방식 |
| 사실 메모리 | MEMORY.md + memories/ | 약 2,200자 / 800토큰 | 모든 세션 | 세션을 넘어 재사용할 사건, 결정, 결론, 사실 |
| 세션 아카이브 | SQLite + FTS5 전문 검색 인덱스 | 제한 없음(수개월의 이력) | 쿼리가 일치할 때 | 몇 주 뒤에도 원문 문장을 정확히 검색 |
| 절차적 메모리 | skills/ 디렉터리(SKILL.md) | 파일당 KB 단위 | 상황이 일치할 때 높은 우선순위로 로드 | "이 상황에서 어떻게 해야 하는가?"를 정의 |
그 외에도 Hermes는 에이전트의 성격 설명인 SOUL.md도 유지합니다. 사용자 메모리가 아닌 에이전트의 자체 모델에 속하지만 사용자 메모리와 함께 컨텍스트 기반을 형성합니다.
각 레이어에 명확한 용량 한도가 필요한 이유
컨텍스트 창이 이렇게 큰데 왜 USER.md는 500토큰으로 제한되는지 의문이 들 수 있습니다.
세 가지 이유:
- 시스템 프롬프트에 추가로 1,000개의 토큰이 추가될 때마다 하루 50번의 호출로 연간 1,800만 개의 토큰이 낭비됩니다 - 심각한 비용 압박입니다.
- 모든 세션에 로드되는 모든 항목을 신중하게 선택해야 합니다. 이는 시스템 프롬프트의 일부이며 부풀려지면 실제 작업 컨텍스트가 압착됩니다.
- 한도는 상충 관계를 강제합니다 — 용량이 가득 차면 아무 것도 자동으로 삭제되지 않습니다. 에이전트는 강제로 통합됩니다(섹션 5 참조).
이것이 Hermes의 핵심 철학입니다. '기억'은 '저장'이 아니라 '의도적으로 선택하여 저장'하는 것입니다.
놓치기 쉬운 구성 요소: Honcho
Hermes는 변증법적 사용자 모델링을 수행하는 Honcho도 사용합니다. Honcho는 대화에서 사용자에 관한 재사용 가능한 설명을 계속 추출하고, 그 결과를 USER.md 관리에 반영합니다.
구조화된 파일이 제대로 처리하지 못하는 암시적 선호도(예: "이 사용자는 오후 3시 이후에 참을성이 없어집니다." 또는 "이 사용자는 필러 단어에 유난히 민감합니다.")는 이 순전히 LLM 기반 추론 레이어에 의해 채워집니다.
4. 회상: 구조화 로딩, 전문 검색, 의미 요약의 세 축
일반적인 RAG 구성은 벡터 유사도에 크게 의존합니다. 하지만 벡터 검색만으로는 두 가지 고질적인 문제가 생깁니다. 중요한 정보가 반드시 질문과 비슷한 표현을 쓰는 것은 아니며, 긴 문단 안에서는 세부 정보가 묻힐 수 있습니다.
Hermes의 회수 전략은 하이브리드 검색과 유사합니다.
| 검색 방법 | 트리거 시나리오 | 일반적인 대기 시간 |
|---|---|---|
| 구조화된 기본 로딩 | 모든 대화 시작 | 거의 0(시스템 프롬프트의 일부) |
| FTS5 전문 검색 | "그 오류가 뭐였죠?"처럼 특정 사실을 질문할 때 | 일치 항목 검색 약 20ms, 페이지 조회 약 1ms |
| LLM 의미 요약 | 여러 항목을 종합해야 하는 질문 | 수초, 저비용 모델(예: Gemini Flash)에서 실행 |
세 방식을 함께 사용하면 단순히 "벡터가 비슷하다"는 수준을 넘어 실제로 사용자를 기억할 수 있습니다. 결과적으로 **"사용자가 전에 말한 내용을 정확히 알고 있다"**는 경험을 제공합니다.
스티커 메모에 비유하면 이해하기 쉽습니다. USER.md는 모니터 가장자리에 붙인 메모처럼 항상 보이고, MEMORY.md는 책상 위의 일지처럼 더 많은 내용을 담습니다. SQLite+FTS5는 서랍 속 보관함처럼 평소에는 닫혀 있지만 필요할 때 검색할 수 있고, 스킬은 상황이 오면 수행 방법을 떠올리는 근육 메모리에 해당합니다.
5. 업데이트: 메모리는 고정 원장이 아니라 살아 있는 기록입니다
흔히 놓치는 점이 있습니다. 메모리는 쓰기만 하는 저장소가 아니라 수정하고 삭제할 수 있는 기록이어야 합니다. Hermes는 이를 위해 세 가지 전략을 사용합니다.
전략 1: 충돌 시 병렬로 추가하는 대신 업데이트
이 방식은 서로 모순되는 사용자 정보가 나란히 남는 일을 막습니다. "Vue 선호 / React로 전환 / 다시 Vue로 복귀"를 모두 현재 선호도처럼 보관해서는 안 됩니다. Hermes는 선호도 필드의 기존 값을 덮어쓰고, 사실 항목은 이력을 유지하되 "현재 상태" 필드를 갱신합니다.
전략 2: 오래 참조되지 않은 항목의 중요도를 낮춥니다
MEMORY.md에는 단단한 천장(2,200자)이 있습니다. 가득 차면 응답은 다음과 같습니다.
{
"success": false,
"error": "Memory at 2,100/2,200 chars. Consolidate now...",
"current_entries": [...],
"usage": "2,100/2,200"
}이는 오류가 아니라 게이트 신호입니다. 에이전트는 다시 쓰기 전에 절충안을 적용하고 오래되고 가치가 낮은 항목을 병합하거나 삭제해야 합니다.
전략 3: 사용자가 명시적으로 거부하는 정보는 즉시 삭제됩니다.
반대되는 내용을 새로 기록하는 것이 아니라 해당 정보를 실제로 삭제하여 모델이 사용하는 정보의 일관성을 지킵니다.
즉, Hermes는 일기장에 붙이는 것보다 살아있는 아카이브 편집에 더 가깝습니다.
6. 실제로 작동하기 위한 마지막 조건
메모리 메커니즘이 아무리 뛰어나도 한 가지 전제 조건이 있습니다. 에이전트가 계속 실행 중이어야 합니다.
자신의 노트북에 Hermes를 설치하면 덮개를 닫을 때마다 낮잠이 들고 배경 자체 반사 루프(넛지)가 멈춥니다. 기계를 바꾸거나 OS를 재설치한다는 것은 ~/.hermes/를 손으로 옮기는 것을 의미하며 FTS5 인덱스는 매번 처음부터 다시 작성해야 합니다.
클라우드 호스팅이 정말 유용해지는 곳이 바로 여기입니다. LightVela는 클라우드 호스팅 Hermes Agent 서비스입니다.
MEMORY.md/USER.md/ SQLite 세션 아카이브가 영구적으로 존재하는 전용 클라우드 인스턴스가 연중무휴 24시간 온라인으로 제공됩니다.- 배경 너지 루프가 계속 실행되므로 에이전트는 사용하지 않을 때에도 실제로 성장합니다.
- 데이터는 전용 서버에만 유지됩니다.
- 전화, 노트북, Telegram, Slack, Lark — 모든 채널은 당신을 아는 동일한 에이전트에 도달합니다.
Hermes는 "당신을 기억하는 것"을 실제 엔지니어링 설계로 전환했습니다. LightVela를 사용하면 매일, 바로 옆에서 그 디자인이 적용됩니다.
핵심 요약
- Hermes는 더 큰 컨텍스트 창이 아니라 의도적인 큐레이션, 계층형 스토리지, 하이브리드 리콜, 지속적인 업데이트를 통해 사용자를 기억합니다.
- 모든 레이어에는 명시적인 용량이 있습니다:
USER.md의 경우 토큰 500개,MEMORY.md의 경우 토큰 800개, SQLite의 경우 상한선 없음, 스킬의 경우 시나리오 기반 로딩. - 좋은 에이전트 메모리 시스템은 일기에 추가하는 대신 아카이브를 편집합니다. 천장은 절충을 강제합니다.
- LightVela의 목표는 이 기능을 명령줄에서 제품으로 가져와 기억되는 것이 기본 경험이 되도록 하는 것입니다.
마지막 업데이트: 2026-08-31
LightVela 문서
Hermes Agent와 OpenClaw의 근본적인 차이는 "축적"과 "연결"에 있습니다. Nous Research가 만든 Hermes Agent는 시간이 지날수록 사용자를 더 잘 이해하도록 설계된 자기 진화형 에이전트입니다. 장기 메모리(USER.md / MEMORY.
LightVela 문서
USER.md와 MEMORY.md는 Hermes Agent의 장기 메모리를 구성하는 두 개의 개인 기록이며, 세 가지 이유로 하나로 합칠 수 없습니다. 첫째, 용량이 독립적이어서(USER.md 약 1,375자/500토큰, MEMORY.md 약 2,200자/800토큰) 서로의 공간을 침범하지 않습니다.