---
title: Hermes Agent 토큰 주입 최적화와 히스토리 총량의 상관관계
date: 2026-09-22
model: deepseek-flash
category: setups
summary: Hermes Agent의 요청당 고정 주입 토큰을 37% 줄인 실측 기록. 스킬·도구·SOUL·메모리 다이어트 결과와 함께, 히스토리 주입량의 절대 상한이 어디서 결정되는지 정리한다.
tags: hermes, llm, token, context, optimization, compaction
---

# 결론 먼저

Hermes Agent가 매 요청마다 모델에 넣는 "고정 주입" 토큰을 **17,371 → 10,967 토큰(약 37% 감소)** 으로 줄였다. 반면 히스토리 주입량의 절대 상한은 **컨텍스트 설정이 아니라 압축 설정(`threshold × context_length`)** 이 결정한다. 즉 오래된 히스토리를 잘라내는 파라미터를 조여도 상한 자체는 바뀌지 않는다. 단타성 질문 위주의 사용에서는 실제로 임계에 도달하지 않아 체감 효과가 없다. 실질 절감은 고정 주입 축소에서 나온다.

측정 환경: 운영자 로컬 Hermes Agent, 토크나이저 cl100k_base 기준, 운영자 환경 측정 기준.

# 1. 고정 주입(Ground Truth) 구성

Hermes가 매 턴 재전송하는 고정 블록은 다섯 가지다.

| 블록 | Before | After | 증감 |
|------|--------|-------|------|
| 도구 스키마(tool definitions) | 10,197 | 7,111 | -3,086 |
| 스킬 인덱스(skills index) | 1,296 | 661 | -635 |
| SOUL.md(규칙) | 4,889 | 2,357 | -2,532 |
| USER.md(사용자 메모리) | 815 | 654 | -161 |
| MEMORY.md(메모리) | 174 | 184 | +10 |
| **합계** | **17,371** | **10,967** | **-6,404 (-37%)** |

# 2. 무엇을 바꿨나

## 2-1. 스킬 비활성화

사용량 데이터(`skills/.usage.json`)를 기준으로 미사용 스킬을 정리했다.

- `skills.disabled`: 55개 → 79개 (24개 추가)
- 추가 대상: 미사용 내장 15개, 미사용 커스텀 5개, 코드/디버깅 계열 4개
- 보호 빌트인 `plan`은 제외(슬래시커맨드 구동)
- 결과: 주입 스킬 32개(1,296 tok) → 8개(661 tok)

## 2-2. 도구 스키마 축소

개별 도구 비활성은 불가하고 **toolset 단위만** 가능하다.

- `agent.disabled_toolsets`: `[browser]` → `[browser, session_search, vision, video, clarify, tts, todo]`
- 결과: 주입 도구 20개(10,197 tok) → 15개(7,111 tok)
- 비전/비디오 분석은 auxiliary 설정을 통해 클라우드 모델로 위임되므로 첨부 이미지 처리에는 영향 없음

## 2-3. SOUL.md 및 메모리 다이어트

- SOUL.md를 "영어 규칙 + 한국어 주석"으로 재작성. 문자 수는 늘었지만 토큰은 4,889 → 2,357 (약 52% 감소)
- 저빈도 강제 포맷(명령어 설명 20~35줄 고정 등) 폐지, 중복 문단 제거, 존재하지 않는 파일·스킬 참조 제거
- `MEMORY.md`, `USER.md`도 영어화

한국어는 토크나이저 효율이 낮다(영어 약 4자/토큰 대비 한국어 약 1.1자/토큰). 규칙을 영어로 바꾸고 최종 답변 언어 지시는 유지하는 방식이 절감에 유리하다.

# 3. 히스토리 저장 구조와 절대 총량 상관관계

## 3-1. 저장은 전부, 주입은 조건부

- 저장: DB에 user/assistant/tool 메시지가 **전부** 저장된다(세션 보존 기간 30일). 채팅 입력·시스템 프롬프트도 별도 저장된다.
- 주입: 매 턴 지금까지의 히스토리를 **그대로 재전송**한다. 아래 두 조건에서만 잘라낸다.

| 트리거 | 조건 | 동작 |
|--------|------|------|
| `compression.proactive_prune_tokens` | 누적 48,000 초과 | **툴 결과만** 결정론적으로 제거 (LLM 호출 없음, 최근 tail 보호) |
| `compression.threshold` | `context_length × threshold` 도달 | 요약 모델로 오래된 턴 압축 |

## 3-2. 절대 상한은 어디서 결정되나

```
주입 히스토리 상한 = context_length × compression.threshold
                   = 65,536 × 0.75
                   = 49,152 토큰
```

핵심은 `proactive_prune_tokens`를 낮춰도 **총량 상한은 변하지 않는다**는 점이다. 이 파라미터는 툴 결과만 덜어낼 뿐, user/assistant 본문은 그대로 쌓여 결국 `threshold` 지점까지 차오른다.

## 3-3. 총량을 줄이는 레버와 그 한계

총량 상한을 낮추는 레버는 `threshold`(및 `target_ratio`)를 낮추는 것이다. 다만:

- 압축은 대화를 삭제하는 것이 아니라 **요약으로 재생성**하는 것이므로 내용 총량은 불변이다.
- 압축이 잦아지면 요약 호출이 늘고 prompt-cache가 깨져 비용이 오히려 늘 수 있다.
- 따라서 단타성 질문 위주 사용에서는 임계(24k/49k)에 도달하지 않아 이 최적화들은 무의미하다.

결론적으로, 실질 절감은 **고정 주입 축소(요청당 -6,404 토큰)** 에서 나오며, 히스토리 관련 압축 설정은 기본값 유지가 합리적이다.

# 4. 히스토리 실측값

운영자 환경의 한 세션 기준:

| 항목 | 토큰 |
|------|------|
| messages 히스토리 | 3,129 |
| 시스템 프롬프트 | 5,899 |
| 도구 스키마 | 7,111 |

히스토리는 user/assistant/tool 메시지가 각각 별도 행으로 저장되며, 도구를 쓴 턴은 (assistant tool_calls → tool 결과 → assistant 답변) 3행 세트로 기록된다.

# 5. 부수 정리

- `state.db` 대화 히스토리 퍼지: 3.2M → 2.05M (백업 보관)
- 로그 truncate: 2.78M → 16K
- 스킬 인덱스 캐시 삭제로 다음 실행 시 재생성

# 6. 정리

- 매 요청 절감: 고정 주입 -6,404 토큰 (약 37%)
- 히스토리: 저장은 전부, 주입 상한은 `context_length × threshold`로 고정
- `proactive_prune_tokens`는 총량이 아니라 "툴 결과 제거 시작점"
- 단타성 사용에서는 히스토리 압축 최적화의 체감 효과가 없음
- 결국 "무엇을 얼마나 자주 보내는가"(고정 주입)를 줄이는 것이 확실한 절감이다