---

🎧 Voice Briefing

📅 Generated: 2026. 5. 1. 오전 7:57:45

---

1,300토큰의 역설: 왜 똑똑한 AI 에이전트는 '적게' 기억하는가

---

프롤로그: 모두가 더 많이 기억하려 한다

요즘 AI 업계의 화두는 "긴 컨텍스트"다. 100만 토큰, 200만 토큰. 모두가 모델에게 더 많은 것을 기억시키려 안달이다.

그런데 나는 다른 생각이 든다.

2026년 2월 Nous Research가 공개한 오픈소스 에이전트 Hermes는 정확히 그 반대로 간다. 항상 프롬프트에 주입되는 메모리 크기가 단 1,300토큰.¹ 그게 전부다. 그리고 이 작은 숫자가, 지난 1년간 내가 본 에이전트 설계 중 가장 영리한 결정이다.

지난주 나는 Hermes의 GitHub 리포지토리와 공식 문서를 직접 읽었다.² 솔직히 한 가지 깨달음이 있었다. 에이전트의 지능은 '얼마나 많이 기억하는가'가 아니라 '무엇을 어디에 기억하는가'에 달려 있다.

---

I – 메모리는 단수가 아니다

대부분의 사람들이 "AI 메모리"를 하나의 거대한 저장소로 상상한다. 거대한 벡터 DB. 모든 대화 기록을 의미적으로 인덱싱한 노트북.

Hermes는 그렇게 하지 않는다.

"Hermes에는 메모리 시스템이 하나 있는 게 아니다. 네 개가 있다."

계층	역할	저장 방식
1. 프롬프트 메모리	환경, 선호, 규칙	MEMORY.md + USER.md (3,575자 한도)
2. 세션 검색	과거 대화 회상	SQLite + FTS5 인덱스
3. 스킬	반복 가능한 워크플로우	~/.hermes/skills/
4. Honcho (선택)	사용자 모델링	외부 서비스

이게 우연이 아니다. 인지과학자들이 인간 기억을 분류한 방식과 정확히 일치한다. 의미 기억(semantic), 일화 기억(episodic), 절차 기억(procedural).³ CoALA 프레임워크가 LLM 에이전트에게 필요하다고 정의한 네 가지 메모리 타입이다.

기억은 원래 복수형이다. Hermes는 그 사실을 부인하지 않을 뿐이다.

---

II – 캐시를 깨지 마라

여기서 핵심이 나온다. 왜 Hermes는 프롬프트 메모리를 1,300토큰으로 묶어두는가?

답은 한 단어다. 캐싱.

Anthropic의 프롬프트 캐싱은 긴 프롬프트에서 비용을 90% 줄이고, 첫 토큰 지연을 85% 단축한다.⁴ 캐시 읽기는 100만 토큰당 $0.30, 신규 처리는 $3.00. 정확히 10배 차이다.

"메모리는 에이전트가 유용해지도록 도와야 한다. 단, 프롬프트 안정성을 파괴하지 않는 선에서."

이게 Hermes 설계 철학의 한 줄 요약이다.

graph TD
    subgraph 안정 ["🟢 안정 영역 (캐시됨)"]
        A[기본 시스템 프롬프트] --> B[MEMORY.md 스냅샷]
        B --> C[USER.md 스냅샷]
        C --> D[Skills 인덱스]
    end

    subgraph 휘발 ["🔄 휘발 영역 (매 턴)"]
        E[대화 기록] --> F[현재 사용자 메시지]
        F --> G[Honcho 컨텍스트]
    end

    안정 --> 휘발

세션이 시작되면 Hermes는 MEMORY.md를 디스크에서 읽어 시스템 프롬프트에 주입한 뒤, 그 스냅샷을 세션 내내 동결한다. 디스크에는 즉시 쓰지만 프롬프트는 건드리지 않는다.

다시 말해, 메모리 업데이트와 프롬프트 캐시 사이에 명확한 선이 그어져 있다.

대부분의 에이전트는 이 둘을 섞는다. 그리고 캐시를 매 턴 깬다. 그 결과 비용은 폭증하고 응답은 느려진다.

Hermes는 그 함정을 피한다.

---

III – 압축 직전의 마지막 기회

Hermes에서 가장 영리한 패턴은 따로 있다. 메모리 플러시(Memory Flush) 라는 기법이다.

대화가 길어지면 결국 중간 부분을 요약해 컨텍스트 창을 비워야 한다. 그런데 요약은 손실 압축이다. 중요한 사실이 사라질 수 있다.

그래서 Hermes는 압축 직전에 멈춘다.

대화 길어짐

→ "지금 압축한다. 살아남을 가치 있는 것은 저장하라"는 합성 지시 주입

→ memory 도구만 사용 가능한 모델 호출 1회

→ 모델이 MEMORY.md/USER.md에 핵심 사실 기록

→ 그제야 중간 대화 압축

→ 프롬프트 재구축

이 한 단계가 모든 것을 바꾼다.

"압축이 일어나기 직전, 모델에게 '진짜 중요한 것이 뭐였지?'를 묻는다."

내가 직접 OpenAI Assistants와 LangGraph 메모리를 다뤄봤을 때, 가장 큰 좌절은 이거였다. 시스템이 "알아서" 요약해버리고 나면, 정작 다음 세션에 필요한 디테일은 사라져 있었다. 사용자 선호 같은 것들이.

Hermes는 그 결정권을 모델 자신에게 돌려준다. 사라지기 직전, 모델이 직접 골라 옮긴다.

ACE(Agentic Context Engineering) 연구는 이런 "진화하는 컨텍스트" 패턴이 에이전트 성능을 +10.6%, 금융 벤치마크에서 +8.6% 끌어올린다고 보고했다.⁵

---

IV – 잊혀진 차원: 절차적 기억

대부분의 메모리 시스템은 무엇을 기억할지에 집착한다. 이름, 선호, 사실, 요약.

하지만 인간은 다르게도 기억한다. 어떻게 하는지를 기억한다. 자전거 타기. 키보드 단축키. 특정 버그를 고치는 손버릇.

이걸 절차적 기억(procedural memory)이라 부른다. 그리고 대부분의 AI 에이전트가 통째로 빠뜨린 차원이다.⁶

Hermes는 이걸 스킬(Skills) 이라는 이름으로 복원한다.

~/.hermes/skills/ 디렉토리에 저장되는 재사용 가능한 워크플로우 문서들. 까다로운 이슈를 해결했거나, 더 나은 방법을 발견했을 때 모델이 직접 저장하고 다음에 다시 꺼내 쓴다.

토큰 절약 기법

전통적 방식	Hermes 방식
❌ 모든 스킬을 매 턴 프롬프트에 주입	✅ 스킬 인덱스만 주입
❌ 사용 안 해도 토큰 비용 발생	✅ 필요 시점에만 풀 콘텐츠 로드
❌ 프롬프트가 무제한 부풀음	✅ 인덱스는 작게 유지

이건 단순한 최적화가 아니다. 에이전트가 스스로 학습한 노하우를 저장하는 메커니즘의 본격적 등장이다.

"에이전트는 무엇이 있었는지뿐 아니라, 어떻게 했는지도 기억해야 한다."

---

V – OpenClaw와의 분기점

같은 분야에 OpenClaw라는 에이전트가 있다. 둘 다 메모리 지속성을 추구한다. 하지만 철학이 정반대다.

구분	OpenClaw	Hermes
저장 철학	마크다운 우선, 검색 가능한 노트	작은 핫 메모리 + 콜드 검색 계층
일일 로그	Append-only(추가만)	큐레이션된 상태
회상 방식	노트 하이브리드 검색	SQLite FTS5 + 요약
캐시 인식	약함	1급 제약 조건

OpenClaw는 "기억은 검색 가능한 지식 저장소"라고 본다. Hermes는 "기억은 핫 워킹셋과 콜드 회상 계층의 조합"이라고 본다.

역설적이게도, 덜 저장하는 쪽이 더 실용적이다. 모든 것을 시스템 프롬프트에 살게 하면 안 된다. 어떤 것은 검색에 양보해야 한다.

---

💭 이 글을 읽고 생각해볼 질문

1. 압축 직전 보조 모델의 요약 전략을, 일화/절차/의미 기억 계층마다 어떻게 다르게 설계해야 프롬프트 변형 비용을 최소화하면서 핵심 사실 보존을 극대화할 수 있을까?

2. Append-only 일일 로그 저장에서 플러시 트리거 기반 보조 요약 모델로 전환했을 때, 장기적 비용 효율과 메모리 일관성은 어떻게 변할까?

3. 프롬프트 캐싱의 비용-변형 트레이드오프는, 에이전트가 일화 기억을 영구 저장소로 "플러시"하는 시점 vs 일일 로그에 추가하는 시점을 결정하는 최적 전략을 어떻게 바꿀까?

댓글로 당신의 생각을 공유해주세요.

---

결론: 무엇을 기억할 것인가

Hermes의 메모리 시스템을 깊이 들여다본 뒤 내게 남은 것은 한 줄이었다.

더 많이 기억하는 것이 아니라, 올바른 것을 올바른 계층에 올바른 비용으로 기억하는 것.

이건 AI 에이전트만의 문제가 아니다. 당신의 메모도, 당신의 노트앱도, 당신의 머릿속도 마찬가지다. 모든 것을 한 곳에 쌓아둔다고 똑똑해지지 않는다.

선택해야 한다. 무엇이 항상 곁에 있어야 하고, 무엇은 검색으로 충분하며, 무엇은 절차로 자동화되어야 하는지.

"기억의 진짜 기술은 더 많이 담는 것이 아니다. 중요한 것을 잃지 않는 구조를 만드는 것이다."

---

Sources

---

이 글이 도움이 되셨다면, 한 명의 친구에게 공유해주세요.

Footnotes

1. I Read Hermes Agent's Memory System | manthanguptaa.in ↩

2. Hermes Agent GitHub Repository | NousResearch ↩

3. Types of AI Agent Memory: Episodic, Semantic, Procedural | Atlan ↩

4. Prompt Caching: The Optimization That Cuts LLM Costs by 90% | TianPan.co ↩

5. Agentic Context Engineering: Evolving Contexts for Self-Improving Language Models | arXiv ↩

6. Beyond Short-term Memory: The 3 Types of Long-term Memory AI Agents Need | MachineLearningMastery ↩