Sign In
Subscribe

Hermes Agent 토큰 사용량 최적화 사례 정리

1. 문제 정의

Hermes Agent를 Discord 링크 저장/인사이트 추출 워크플로우에 사용하면서, 단순히 URL 하나를 저장하고 요약하는 작업에도 세션당 수십만~백만 토큰 이상이 사용되는 현상이 있었다.
특히 링크 저장 채널의 목적은 단순했다.
•
사용자가 URL을 Discord에 보낸다.
•
Hermes가 링크 내용을 읽는다.
•
한국어 executive note로 요약한다.
•
Obsidian vault에 markdown으로 저장한다.
•
Discord에는 저장 경로와 짧은 요약만 답한다.
그런데 초기 구조에서는 이 단순 작업이 일반 에이전트 세션처럼 실행되면서 다음 비용 요인이 누적됐다.
•
Discord 과거 대화 history backfill
•
긴 system prompt와 모든 도구 schema
•
불필요한 toolset 노출
•
skills, memory, session_search, qmd/Obsidian 검색 등 부가 기능 유입
•
링크 1개 처리 중 여러 번의 LLM/tool 왕복
•
관련 노트 탐색, Wiki 반영, 깊은 리서치까지 한 세션에서 함께 수행
결과적으로 "링크 저장 + 인사이트 추출"이라는 작은 작업이 고비용 agentic workflow로 커졌다.

2. 최적화 목표

목표는 품질을 크게 떨어뜨리지 않으면서 토큰 사용량을 링크 1개당 백만 토큰급에서 10만 토큰 이하로 낮추는 것이었다.
핵심 방향은 다음과 같다.
1.
링크 수집 채널을 일반 대화 채널과 분리한다.
2.
이 채널은 stateless하게 운영한다.
3.
도구는 web/file/terminal 정도로 제한한다.
4.
과거 대화, 관련 노트, Wiki, session search를 기본적으로 차단한다.
5.
링크 본문 추출은 1회 원칙으로 제한한다.
6.
저장 검증도 최소화한다.
7.
깊은 리서치와 관련 링크 보강은 별도 배치 작업으로 분리한다.

3. 적용한 접근 방식

3.1 채널 분리: General Agent와 Link Inbox를 분리

기존에는 하나의 Hermes Discord 채널에서 대화, 리서치, 링크 저장, Obsidian 정리, 운영 관리가 섞일 수 있었다.
이를 목적별 채널로 분리했다.
•
일반 대화 채널
•
링크 수집 전용 채널
•
리서치 의뢰 채널
•
Obsidian 정리 채널
•
임원 보고/전략 문서 채널
•
Hermes 운영 관리 채널
•
Note Taking 채널
•
Debate 채널
이 중 링크 수집 전용 채널은 비용 절감을 최우선으로 하는 Budget Mode로 설계했다.

3.2 Stateless 채널 설정

링크 수집 채널에는 과거 Discord 대화가 컨텍스트로 다시 들어오지 않도록 설정했다.
discord:
  history_backfill: true
  history_backfill_limit: 10
  no_history_backfill_channels:
    - '1504850303479058633'
  no_history_channels:
    - '1504850303479058633'
의미:
•
전체 Discord는 필요 시 최근 대화를 가져올 수 있다.
•
그러나 링크 수집 채널은 예외적으로 history를 가져오지 않는다.
•
URL 하나가 들어오면 이전 URL 처리 기록을 끌고 오지 않는다.
•
대화가 누적될수록 토큰이 커지는 문제를 차단한다.

3.3 채널별 toolset 제한

링크 수집에는 모든 도구가 필요하지 않다.
따라서 링크 수집 채널에는 web, file, terminal만 허용했다.
discord:
  channel_toolsets:
    '1504850303479058633':
      - web
      - file
      - terminal
제외한 도구 예:
•
browser
•
computer_use
•
code_execution
•
cronjob
•
delegation
•
image_gen
•
tts
•
vision
•
memory
•
session_search
•
todo
•
broad skills usage
효과:
•
매 LLM 호출마다 포함되는 tool schema가 줄어든다.
•
모델이 불필요한 도구를 호출할 가능성이 낮아진다.
•
링크 저장 작업이 "작은 실행 계획" 안에서 끝난다.

3.4 채널별 max turns 제한

링크 하나를 저장하는 데 agent loop가 과도하게 반복되지 않도록 제한했다.
discord:
  channel_max_turns:
    '1504850303479058633': 8
효과:
•
실패 시 무한히 검색/재시도하지 않는다.
•
작은 작업은 작은 loop 안에서 끝난다.
•
디버깅/리서치성 탐색으로 흐르는 것을 방지한다.

3.5 Budget Mode용 channel prompt 작성

링크 수집 채널의 역할을 매우 명확히 제한했다.
핵심 prompt 원칙:
이 채널은 링크 수집 전용 Budget Mode입니다.

목표:
사용자가 URL을 보내면 링크 내용을 1회만 추출해 한국어 executive note로 요약하고,
Thomas2026 Obsidian vault에 markdown으로 저장합니다.
Discord 답변은 저장 경로 + 4~5줄 요약만 제공합니다.

토큰/비용 원칙:
- 기본 처리에는 관련 노트/Wiki/qmd/세션 검색을 하지 않습니다.
- 사용자가 "관련 링크까지 연결", "Wiki 반영", "깊게 리서치"라고 명시할 때만 추가 검색합니다.
- 링크 하나당 primary page fetch/extract는 원칙적으로 1회입니다.
- 실패/차단/본문 부족일 때만 Jina Reader나 원문 링크 1회로 재시도합니다.
- 전체 HTML/JSON/댓글 원문을 모델 컨텍스트에 통째로 넣지 않습니다.
- 제목/본문/핵심 댓글 최대 5개/메타데이터만 선별합니다.
- todo, memory, session_search, skills, vision 등은 쓰지 않습니다.
- 저장 전후 검증은 최소화합니다.
핵심은 "무엇을 할지"보다 "무엇을 하지 않을지"를 명확히 적은 것이다.

3.6 Obsidian 저장 구조는 유지

토큰은 줄이되 결과물 품질은 유지하기 위해 저장 note 구조는 그대로 정의했다.
기본 저장 위치:
/Users/thomas/Obsidian/Thomas2026/30-Resources/AI/
노트 구조:
•
frontmatter
◦
title
◦
source
◦
source_type
◦
created
◦
tags
◦
category
•
한 줄 요약
•
핵심 내용
•
현재 회사와의 시사점
•
적용 아이디어
•
검토 리스크
•
관련 링크
즉, 줄인 것은 "작업 주변부의 컨텍스트와 탐색"이고, 유지한 것은 "최종 산출물의 의사결정 가치"다.

3.7 관련 노트 연결은 실시간에서 배치로 분리

초기에는 링크 저장 시점에 관련 Obsidian 노트, Wiki, 기존 자료까지 함께 찾아 연결하려는 흐름이 있었다.
이 접근은 토큰을 크게 증가시킨다.
개선 후에는 다음처럼 분리했다.
•
실시간 링크 저장: URL 읽기, 요약, 저장만 수행
•
관련 링크/노트 보강: 별도 배치 작업에서 처리
•
Wiki 반영: 별도 Wiki pipeline 또는 명시 요청 시 처리
•
깊은 리서치: 리서치 채널에서 별도 처리
이 분리가 가장 중요했다.

4. 효과

검증된 최적화 후 링크 처리 세션 예시:
•
세션: 20260517_221509_dddd71e2
•
작업: Hermes Agent 한국어 문서 링크 저장
•
API call: 6회
•
Tool call: 6회
•
non-cache input: 20,886 tokens
•
cache read input: 50,688 tokens
•
output: 1,861 tokens
•
cache 포함 총 처리량: 73,435 tokens
초기 목표였던 "백만 토큰급 링크 처리"와 비교하면:
•
1,000,000 tokens → 73,435 tokens
•
약 92.7% 절감
•
약 13.6배 효율화
대략 70,000 tokens 기준으로 보면:
•
약 93.0% 절감
•
약 14.3배 효율화
기존 YouTube/link 처리형 세션 중 1,508,834 tokens 사례와 비교하면:
•
1,508,834 tokens → 73,435 tokens
•
약 95.1% 절감
•
약 20.5배 효율화

5. 핵심 인사이트

인사이트 1: Agent는 "도구가 많을수록 똑똑해지는 것"이 아니라 "비싸지는 것"일 수 있다

범용 에이전트에는 다양한 도구가 유용하다.
하지만 링크 저장 같은 반복 업무에는 너무 많은 도구가 오히려 비용과 복잡도를 증가시킨다.
고빈도 작업일수록 toolset을 좁혀야 한다.

인사이트 2: History backfill은 사용자 경험에는 좋지만 비용에는 치명적일 수 있다

Discord/Telegram 같은 gateway 환경에서는 과거 대화가 자동으로 컨텍스트에 들어오면 편리하다.
하지만 URL 저장 같은 one-shot 작업에서는 과거 대화가 거의 필요 없다.
링크 수집, 메모 수집, 클리핑 채널은 stateless가 기본값이어야 한다.

인사이트 3: "관련 노트 찾기"는 실시간 처리에서 분리해야 한다

Obsidian, Wiki, qmd 검색은 가치가 높지만 비용도 크다.
따라서 실시간 링크 저장 시점에는 하지 않고, 별도 배치로 후처리하는 것이 좋다.
이 구조가 비용과 품질의 균형이 가장 좋다.

인사이트 4: Prompt에는 Do보다 Do Not이 중요하다

"링크를 요약해서 저장하라"만 쓰면 에이전트는 좋은 결과를 위해 검색, 비교, 세션 검색, 관련 노트 탐색을 시도할 수 있다.
Budget Mode에서는 다음을 명시해야 한다.
•
session_search 하지 말 것
•
memory 쓰지 말 것
•
skills 불러오지 말 것
•
관련 노트 찾지 말 것
•
Wiki 반영하지 말 것
•
전체 HTML 넣지 말 것
•
실패 시 재시도 횟수 제한
비용 최적화 prompt의 핵심은 경계 설정이다.

인사이트 5: 캐시 토큰은 싸지만 무료는 아니다

오늘 DB 기준으로는 cache read token이 non-cache input보다 훨씬 컸다.
예:
•
non-cache input: 4,176,434
•
cache read input: 22,651,264
•
output: 238,101
•
총 처리량: 27,065,799 tokens
캐시 할인 과금이 적용되면 비용은 크게 낮아지지만, 캐시 토큰도 완전히 무시할 수는 없다.
따라서 최적화 방향은 다음 순서가 좋다.
1.
불필요한 LLM 호출 횟수 줄이기
2.
tool schema 줄이기
3.
history 제거
4.
큰 문서/HTML을 모델에 넣지 않기
5.
output을 짧게 제한하기
6.
cache는 보너스로 활용하기

6. 재사용 가능한 설정 패턴

패턴 A: Discord 링크 수집 전용 Budget Channel

discord:
  no_history_backfill_channels:
    - '<LINK_CHANNEL_ID>'
  no_history_channels:
    - '<LINK_CHANNEL_ID>'

  channel_toolsets:
    '<LINK_CHANNEL_ID>':
      - web
      - file
      - terminal

  channel_max_turns:
    '<LINK_CHANNEL_ID>': 8

  channel_prompts:
    '<LINK_CHANNEL_ID>': |
      이 채널은 링크 수집 전용 Budget Mode입니다.
      URL을 1회 추출해 요약하고 markdown으로 저장합니다.
      관련 노트/Wiki/session_search/memory/skills는 기본 사용하지 않습니다.
      깊은 리서치가 필요하면 사용자가 명시적으로 요청할 때만 수행합니다.
      답변은 저장 경로와 4~5줄 요약만 제공합니다.

패턴 B: 고빈도 자동화는 no-agent/script-first로 전환

반복 cron이나 변화 감지 작업은 매번 LLM을 호출하지 않는 것이 좋다.
권장 구조:
1.
script가 변경 여부를 먼저 확인한다.
2.
변경이 없으면 stdout 없이 종료한다.
3.
변경이 있을 때만 제한된 Hermes agent를 호출한다.
4.
agent 호출 시 toolset, 파일 범위, changed_files를 명시한다.
이 구조는 "아무 일도 없는 날"의 LLM 비용을 거의 0으로 만든다.

패턴 C: 리서치와 저장을 분리

링크 저장 채널:
•
빠른 캡처
•
요약
•
저장
•
낮은 비용
리서치 채널:
•
웹 검색
•
출처 비교
•
심층 분석
•
높은 품질
•
상대적으로 높은 비용 허용
Obsidian 정리 채널:
•
관련 노트 연결
•
태그 정리
•
MOC/Wiki 반영
•
배치성 작업
이렇게 역할을 나누면 각 채널의 토큰 예산을 다르게 설계할 수 있다.

7. 추가 개선 여지

현재 최적화 후에도 링크 1개 처리에 약 7만 tokens가 사용됐다.
이는 일반 agent loop 기준으로는 많이 줄어든 수치지만, 더 줄일 여지가 있다.
다음 단계는 script-first extraction이다.
예상 구조:
1.
Python/Node script가 URL 본문을 가져온다.
2.
HTML boilerplate를 제거한다.
3.
제목, 본문 일부, 메타데이터만 추린다.
4.
중복 파일명과 저장 경로를 deterministic하게 만든다.
5.
LLM에는 정제된 본문만 넘긴다.
6.
LLM은 요약/인사이트 생성만 한다.
7.
저장은 script가 수행한다.
이렇게 하면 LLM 호출을 6회에서 1~2회로 줄일 수 있다.
예상 효과:
•
현재: 링크 1개 약 70k tokens
•
script-first 목표: 링크 1개 약 10k~20k tokens
•
추가 절감 가능성: 70~85%

8. 공유용 한 줄 요약

Hermes Agent의 토큰 비용은 모델 자체보다 "얼마나 많은 컨텍스트, 도구, 과거 대화, 검색 흐름을 한 작업에 같이 태우는가"에서 결정된다. 링크 저장처럼 반복되는 업무는 stateless 채널, 제한된 toolset, 명확한 Budget Mode prompt, 실시간/배치 분리를 적용하면 백만 토큰급 작업을 7만 토큰 수준까지 줄일 수 있다.

9. 실무 적용 체크리스트

고빈도 Hermes workflow를 만들 때는 다음을 먼저 확인한다.
•
이 작업에 과거 대화가 정말 필요한가?
•
이 작업에 모든 도구가 필요한가?
•
memory/session_search/skills가 기본으로 필요한가?
•
관련 노트 검색은 실시간이어야 하는가, 배치로 충분한가?
•
실패 시 재시도 횟수는 제한되어 있는가?
•
전체 HTML/JSON/문서를 모델에 넣고 있지 않은가?
•
output을 짧게 제한했는가?
•
script-first 또는 no-agent cron으로 바꿀 수 있는가?
•
채널별 max_turns를 설정했는가?
•
비용 측정은 input, cache_read, output을 분리해서 보고 있는가?
이 체크리스트만 적용해도 대부분의 Hermes 고비용 workflow는 크게 줄일 수 있다.
Made with Slashpage