LightVela

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. 사용자가 누구인지 알기 — 이름, 역할, 선호도, 자주 쓰는 도구.
  2. 함께 무엇을 했는지 알기 — 논의한 프로젝트, 내린 결론, 겪었던 문제.
  3. 사용자를 어떻게 응대할지 알기 — 짧은 답변과 자세한 답변 중 무엇을 선호하는지, 결론과 추론 중 무엇을 먼저 제시할지.

큰 컨텍스트 창만 있는 모델은 단일 대화 내에서 세 가지 작업을 모두 수행할 수 있지만 세션이 종료되는 순간 포인트 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. 시스템 프롬프트에 추가로 1,000개의 토큰이 추가될 때마다 하루 50번의 호출로 연간 1,800만 개의 토큰이 낭비됩니다 - 심각한 비용 압박입니다.
  2. 모든 세션에 로드되는 모든 항목을 신중하게 선택해야 합니다. 이는 시스템 프롬프트의 일부이며 부풀려지면 실제 작업 컨텍스트가 압착됩니다.
  3. 한도는 상충 관계를 강제합니다 — 용량이 가득 차면 아무 것도 자동으로 삭제되지 않습니다. 에이전트는 강제로 통합됩니다(섹션 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