AI/Hermes

Hermes Agent(2) : 보조 모델(Auxiliary Model) 분리 - 비싼 메인 모델 대신 보조 모델 따로 쓰는 법

안녕하세요! 갓대희 입니다.

Hermes를 며칠 굴려보면 한 번쯤 이 질문이 걸린다. "이미지 한 장 분석하거나 세션 제목 붙이는 일도 메인 모델이 하나?" 지금 공식 문서 기준의 답은 대체로 "그렇다"에 가깝다. Hermes는 이미지 분석, 웹 페이지 요약, 컨텍스트 압축 같은 부가 작업을 위해 별도의 보조 모델 슬롯을 두지만, auxiliary.*.provider: "auto"는 기본적으로 사용자가 고른 메인 채팅 모델로 흘러간다.

이번에는 Hermes의 보조 모델이 어떤 작업을 처리하는지, hermes model CLI와 config.yaml로 그 슬롯을 어떻게 분리해 비용을 낮출 수 있는지, 그리고 Curator 스킬 리뷰처럼 별도 보조 슬롯으로 빠진 항목은 어디서 손대는지를 살펴보려 한다.

이 가이드, 나한테도 해당될까?

보조 슬롯 분리의 비용 효과는 메인 모델의 과금 구조에 따라 크게 달라진다. 아래 표로 본인 상황을 먼저 짚어보자.

사용 패턴	분리 효과	이유
API 직접 과금 (OpenRouter, Anthropic API 등)	효과 큼	호출마다 토큰 비용 발생 → Flash 계열로 전환 시 즉시 절감
구독형 (ChatGPT Plus / Codex OAuth)	효과 제한적	월정액 내 소비 → 보조 슬롯 호출의 한계비용 ≈ 0. 분리보다 그냥 쓰는 게 나을 수 있다.
특수 플랜 (GLM 코딩 플랜, z.ai 등)	플랜 조건에 따라 다름	플랜에 포함된 모델이라면 분리 불필요. 초과 시 별도 과금 구조라면 분리가 유효하다.
로컬 모델 (Ollama, vLLM 등)	비용보다 전문화	메인 모델 자체가 무료 → 분리 목적은 절감보다 작업별 모델 전문화 또는 응답 속도.

한 줄 요약: API 직접 과금 사용자라면 이 가이드가 바로 써먹힌다. 구독형이나 특수 플랜 사용자는 먼저 보조 호출이 플랜 안에 포함되는지, 초과분이 별도 과금인지를 확인하는 게 먼저다.

왜 보조 모델 설정이 비용 문제와 직결되는가
시작하기 — 현재 설정 확인과 첫 분리 시도
설정 방법 1: hermes model CLI로 인터랙티브 구성
설정 방법 2: config.yaml 직접 편집
주요 설정 키 — provider / model / base_url / timeout
Curator 별도 슬롯 설정
비용 절감 전략 — 작업별 모델 매칭 가이드
트러블슈팅 — 흔한 오류와 진단 명령

1. 왜 보조 모델 설정이 비용 문제와 직결되는가

Hermes는 본 채팅과는 별개로 부가 작업용 모델 슬롯을 둔다.

공식 문서는 이를 다음과 같이 정의한다.

"Hermes는 이미지 분석, 웹 페이지 요약, 컨텍스트 압축 등 부가 작업에 '보조' 모델을 사용합니다."

즉, "메인 모델 = 대화", "보조 모델 = 잡일"이라는 역할 분리가 처음부터 설계 차원에 들어가 있다는 뜻이다. 그런데 같은 문서가 곧바로 못 박는 한 줄이 있다.

"기본값(auxiliary.*.provider: "auto")으로는 주 채팅 모델을 사용하지만, 비용 절감을 위해 별도 모델로 라우팅할 수 있습니다."

다시 말해, 슬롯은 분리되어 있지만 기본값으로는 같은 모델이 들어간다. 사용자가 명시적으로 보조 모델을 지정하지 않으면 비싼 메인 모델이 이미지 한 장 보는 작업까지 떠맡는 구조다. 비용 측면에서 이 기본값은 사실상 함정에 가깝다.

공식 문서에서 확인되는 보조 작업 슬롯

공식 Configuration 문서는 auxiliary 아래에서 vision, web_extract, approval, compression, session_search, skills_hub, mcp를 직접 보여준다.

모델 설정 문서에는 title_generation까지 포함한 8개 보조 슬롯이 보이고, Curator 문서는 Curator 리뷰용 슬롯을 auxiliary.curator로 따로 설명한다.

작업명(설정 키)	하는 일	직접 확인 출처
vision	이미지 분석	공식 문서
web_extract	웹 페이지 요약	공식 문서
compression	긴 대화 컨텍스트 압축	공식 문서
session_search	과거 세션 검색	공식 문서
title_generation	새 세션 제목 자동 작성	공식 문서
approval	위험 명령 승인 판단	공식 문서
skills_hub	스킬 검색과 매칭	공식 문서
mcp	MCP 툴 라우팅	공식 문서
curator	Curator의 스킬 검토	공식 Curator 문서

한 줄로 요약하면, 이제 "공식 문서가 보장하는 건 4종뿐"이라고 쓰면 틀린다.

다만 슬롯마다 중요도는 다르다. 비용 절감 효과가 바로 체감되는 쪽은 보통 vision, web_extract, compression, session_search이고, title_generation, approval, skills_hub, mcp, curator는 사용 패턴에 따라 우선순위가 갈린다.

2. 시작하기 — 현재 설정 확인과 첫 분리 시도

보조 모델 설정에 손대기 전에, 지금 내 Hermes가 어떤 상태인지부터 확인하는 게 빠르다.

CLI 레퍼런스에 따르면 hermes config 명령은 구성값을 표시·편집·변경하는 통합 명령으로, show, edit, set, path, env-path, check, migrate 같은 부분 명령을 지원한다.

# 현재 설정 전체 보기
hermes config show

# 보조 모델 설정만 좁혀 보기 (셸 grep)
hermes config show | grep -A 2 auxiliary

provider가 auto로 잔뜩 떠 있다면, 지금 사용자의 비싼 메인 모델이 잡일까지 처리하고 있다는 신호다. 여기서부터가 비용 절감의 시작점이다.

첫 분리 시도는 hermes model 인터랙티브 모드를 추천한다. config.yaml을 직접 다루기 전에 어떤 프로바이더 옵션이 살아 있는지, 어떤 모델 ID가 유효한지 한눈에 보기 좋다. 익숙해지면 그때 yaml 편집이나 hermes config set으로 자동화하면 된다.

3. 설정 방법 1: hermes model CLI로 인터랙티브 구성

가장 간단한 진입점은 hermes model 명령이다. 공식 사용자 가이드는 다음 흐름을 제시한다.

hermes model
# → "Configure auxiliary models" 선택
# → 작업별로 프로바이더/모델 선택

CLI 레퍼런스는 hermes model을 "인터랙티브 provider + model 선택기"로 정의하며, 새 제공자 추가, API 키 입력, OAuth 흐름 실행에도 같은 명령을 쓰도록 안내한다.

즉, 보조 모델 라우팅 외에도 신규 프로바이더 등록까지 같은 진입점으로 묶여 있다.

실제 화면 흐름을 텍스트로 옮기면 다음과 같이 정리된다.

hermes model을 실행한다.
메뉴에서 "Configure auxiliary models"를 선택한다.
vision, compression, session_search 등 작업 단위로 들어간다.
각 작업마다 프로바이더(auto, openrouter, nous, main 등)와 모델 ID를 고른다.

인터랙티브 모드의 장점은 잘못된 모델 슬러그를 입력했을 때 그 자리에서 바로 거부된다는 점이다. 다만 옵션이 많아질수록 클릭 수가 늘어나고, 같은 설정을 여러 머신에 복제하기 어렵다. 팀 단위 표준화가 필요하다면 다음 절의 yaml 편집이 더 깔끔하다.

ex)

4. 설정 방법 2: config.yaml 직접 편집

공식 가이드는 auxiliary 섹션을 yaml로 직접 작성하는 예시를 제공한다.

핵심은 작업명별로 한 블록씩 적고, 그 아래에 provider, model, timeout 등을 명시하는 형태다.

auxiliary:
  vision:
    provider: openrouter
    model: google/gemini-2.5-flash
    timeout: 120
  compression:
    provider: openrouter
    model: google/gemini-2.5-flash
    timeout: 120
  session_search:
    provider: main
    model: glm-4.5-air
    timeout: 60

즉, vision과 compression은 OpenRouter 경유 Gemini 2.5 Flash로 라우팅하고, session_search는 main 프로바이더(주 에이전트 프로바이더 상속) 위에서 가벼운 모델을 쓰는 식이다.

다만 provider와 model ID는 항상 한 쌍으로 생각해야 한다. 같은 GLM 모델이라도 어떤 provider를 쓰느냐에 따라 model ID 형식이 달라진다.

시나리오	provider	model
메인이 z.ai(GLM)이고 보조도 GLM으로 상속	`main`	`glm-4.5-air`
z.ai를 보조 슬롯에서 직접 지정	`zai`	`glm-4.5-air`
OpenRouter 경유 GLM	`openrouter`	`z-ai/glm-4.5-air` (네임스페이스 포함)

위 예시 yaml은 메인 provider가 z.ai(GLM)로 이미 설정된 상황을 전제로 한다. OpenRouter를 메인으로 쓰는 독자라면 session_search의 model도 z-ai/glm-4.5-air로 바꿔야 한다.

4.1 timeout 키와 동시성 제어

공식 가이드의 다른 예시는 web_extract와 session_search에 별도의 timeout/동시성 설정을 권장한다.

auxiliary:
  vision:
    provider: "auto"
    timeout: 120
    download_timeout: 30
  web_extract:
    timeout: 360  # 6분 권장
  approval:
    timeout: 30
  compression:
    timeout: 120
  session_search:
    timeout: 30
    max_concurrency: 3

같은 출처에 따르면 현재 예시값은 vision timeout: 120과 download_timeout: 30, web_extract timeout: 360, approval timeout: 30, compression timeout: 120, session_search timeout: 30과 max_concurrency: 3이다.

또한 extra_body: {}를 통해 enable_thinking: false 같은 프로바이더 특화 필드를 전달할 수 있다. 보조 슬롯은 단순히 모델 이름만 갈아끼우는 곳이 아니라 호출 시간, 다운로드 시간, 병렬 처리 한도까지 같이 손대는 공간이다.

4.2 hermes config set — 한 키씩 안전하게 바꾸기

yaml 전체를 다시 쓰지 않고 한 키만 갱신하고 싶다면 hermes config set을 쓰는 편이 안전하다. 공식 가이드의 예시는 다음과 같다.

hermes config set auxiliary.vision.provider openrouter
hermes config set auxiliary.vision.model openai/gpt-4o
hermes config set auxiliary.vision.timeout 180

한 줄에 하나씩 키를 바꾸는 방식이라 변경 내역이 셸 히스토리에 그대로 남는다. CI 스크립트로 묶기에도 적합하다. 즉, 인터랙티브 모드는 탐색용, yaml 편집은 표준화용, config set은 운영용 도구로 역할을 나눠 보면 된다.

5. 주요 설정 키 — provider / model / base_url / timeout

공식 가이드는 보조 모델 슬롯의 주요 키를 다음과 같이 정의한다.

키	의미
`provider`	프로바이더 선택 (`auto`, `openrouter`, `nous`, `main` 등)
`model`	모델 ID 문자열
`base_url`	커스텀 OpenAI 호환 엔드포인트
`api_key`	base_url용 인증 키
`timeout`	API 호출 타임아웃(초)
`download_timeout`	vision 입력 파일 다운로드 제한 시간
`max_concurrency`	session_search 같은 일부 작업의 동시 실행 한도
`extra_body`	프로바이더별 추가 요청 필드

공통 스키마의 중심은 provider, model, base_url이다. 여기에 api_key, timeout, download_timeout, max_concurrency, extra_body가 작업별로 붙는다. 즉, provider만 바꾸면 같은 슬롯이 다른 라우팅으로 흘러가고, base_url을 채우면 라우팅이 사용자 자체 호스트로 옮겨간다.

5.1 provider 옵션이 가진 의미

같은 문서의 provider 옵션 설명은 짧지만 밀도가 높다.

주요 provider — 대표 예시 (전체 목록은 공식 문서 기준)

auto — 기본값. 보조 작업도 메인 채팅 모델을 사용 / openrouter — OpenRouter 강제 라우팅 / nous — Nous Portal 강제 / zai — z.ai(GLM) 네이티브 / codex 또는 openai-codex — ChatGPT OAuth 계열 / main — 보조 슬롯 전용, 주 에이전트 프로바이더 상속 / minimax — API 키 기반 MiniMax / minimax-oauth — MiniMax OAuth / minimax-cn — 중국 리전 MiniMax (공식 가이드)

* 현재 공식 문서에는 openai, gemini, deepseek, qwen-oauth, kimi-coding, xai, ollama-cloud 등이 추가로 등록되어 있다. 위 목록은 2026-05-01 기준 대표 옵션이며, 최신 전체 목록은 공식 문서를 우선한다.

즉, "이미 OpenRouter 키가 있으면 openrouter", "z.ai(GLM)를 메인으로 쓰면 zai", "주 에이전트와 같은 프로바이더 위에서 다른 모델을 쓰고 싶으면 보조 슬롯에서 main", "ChatGPT OAuth를 쓰고 싶으면 문서 예시의 codex와 registry의 openai-codex 표기 차이를 확인한다"로 갈라진다. auto는 편하지만, 메인 모델이 비싼 추론 모델일수록 비용 면에서는 가장 느슨한 선택지다.

5.2 base_url로 로컬·커스텀 엔드포인트 붙이기

base_url을 채우면 OpenAI 호환 인터페이스를 가진 임의의 엔드포인트를 보조 모델로 쓸 수 있다. 공식 가이드의 예시를 그대로 옮기면 다음과 같다.

auxiliary:
  vision:
    base_url: "http://localhost:1234/v1"
    api_key: "local-key"
    model: "qwen2.5-vl"

다시 말해, Ollama나 사용자가 직접 띄운 vLLM 서버 같은 로컬 인프라를 vision 슬롯에 꽂을 수 있다. 이미지 데이터를 외부 API로 보내고 싶지 않을 때 특히 유용하다. 단, api_key 같은 비밀값을 yaml에 평문으로 두지 않고 환경변수 경유로 묶는 등 별도 운영 규칙은 사용자가 책임져야 한다.

6. Curator 별도 슬롯 설정

Curator 스킬 리뷰는 예전 자료와 현재 공식 문서가 갈리는 지점이다.

최신 Curator 문서는 리뷰 패스를 일반 보조 작업과 같은 auxiliary.curator 슬롯으로 다룬다.

curator:
  enabled: true

auxiliary:
  curator:
    provider: openrouter
    model: google/gemini-3-flash-preview
    timeout: 600

모델 안정성 주의: 예시의 google/gemini-3-flash-preview는 공식 문서에 등장하지만 Preview 상태다. Google이 사전 예고 없이 슬러그를 변경하거나 deprecated할 수 있어 장기 운영용으로 고정하기엔 리스크가 있다. 안정적인 대안으로 google/gemini-2.5-flash(Stable 릴리즈, $0.30/$2.50/M tokens)가 있다. 도입 시점에 OpenRouter 카탈로그에서 현재 상태를 직접 확인하는 것이 가장 안전하다.

여기서 헷갈리기 쉬운 부분이 있다. 과거에는 curator.auxiliary.{provider,model} 형태가 쓰였고, 현재 문서도 이 경로가 아직 동작한다고 설명한다. 다만 deprecation 로그가 남는 레거시 경로이므로 새로 설정한다면 auxiliary.curator로 옮기는 편이 맞다.

# 레거시. 새 설정에는 권장하지 않음.
curator:
  auxiliary:
    provider: openrouter
    model: google/gemini-3-flash-preview

Curator 문서의 위치도 바뀌었다. docs/user-guide/curator가 아니라 docs/user-guide/features/curator 아래에 있다. 이전 URL을 보고 404라고 판단하면, 기능이 없는 게 아니라 문서 경로를 잘못 잡은 것이다.

예시에 등장한 google/gemini-3-flash-preview는 공식 문서 예시에도 나온다. 그래도 이름에 preview가 붙어 있다는 점은 무시하면 안 된다. 장기 운영용 표준 모델로 박아두기보다는, 실제 도입 시점에 OpenRouter나 사용 중인 프로바이더의 카탈로그에서 가격·지원 상태를 다시 확인하는 편이 안전하다.

정리하면, Curator는 일반 보조 슬롯과 같은 패턴(provider, model, 필요하면 base_url/api_key/timeout)을 따른다. 위치만 auxiliary.curator다. 기존 설정에 curator.auxiliary가 남아 있다면 당장 깨질 가능성은 낮지만, 새 글이나 새 설정 예시에서는 레거시 경로를 앞세우지 않는 게 맞다.

7. 비용 절감 전략 — 작업별 모델 매칭 가이드

공식 모델 설정 문서는 보조 슬롯을 값싼 모델로 분리할 만한 대표 사례를 꽤 노골적으로 든다. 세션 제목 생성, compression, approval, web_extract처럼 짧거나 요약 중심인 작업은 비싼 추론 모델을 계속 태울 이유가 약하다는 취지다.

공식 문서의 핵심은 단순하다. 모든 보조 슬롯은 기본적으로 auto, 즉 메인 모델을 쓰지만, 작업 성격이 가벼운 슬롯은 Flash 계열이나 mini 계열로 분리할 수 있다.

즉, 공식 문서 자체가 비용 측면에서 auto보다 작업별 분리를 더 실용적인 선택지로 본다는 뜻이다. 단, 구체적인 절감률은 사용량, 프로바이더 가격, 메인 모델 가격에 따라 달라진다. 그래서 이 글에서도 "X% 절약"처럼 숫자를 박아 넣지 않는다.

7.1 작업 성격에 따른 권장 패턴

공식 가이드의 추천을 작업 성격에 맞춰 정리하면 다음과 같다.

작업	특성	권장 방향
vision (이미지 분석)	멀티모달, 짧은 호출	OpenRouter 경유 멀티모달 Flash 계열
compression (대화 압축)	긴 입력, 빠른 응답	OpenRouter 경유 가벼운 Flash 계열
web_extract (웹 요약)	외부 호출 + 긴 timeout	timeout 360초 + 가벼운 요약 모델
session_search (세션 검색)	빈번 호출, 짧은 텍스트	`main` 프로바이더 위 경량 모델, max_concurrency 제한

한 줄로 종합하면, "긴 입력에는 빠른 Flash 계열을, 짧고 잦은 호출에는 경량 모델 + 동시성 제한을" 붙이는 게 공식 가이드의 기본 발상에 가깝다. 절대 수치보다는 이 매칭 패턴 자체가 의사결정의 출발점이다.

7.2 언제 auto로 두는 것이 합리적인가

모든 슬롯을 분리해야 하는 건 아니다. 다음 두 가지 경우에는 auto를 그대로 두는 편이 나을 수 있다.

호출 빈도가 매우 낮은 슬롯(예: 위험 명령어 판단을 거의 트리거하지 않는 사용 패턴): 분리 작업에 드는 시간 대비 절감 효과가 작다.
보조 모델용 외부 API 키를 별도로 발급하기 어려운 환경: OpenRouter 키 등록까지 가야 분리가 가능하다면, 운영 부담이 절감폭을 넘어설 수 있다.

다시 말해, "비싼 슬롯부터 잘라낸다"가 첫 번째 원칙이고, "잘 안 쓰는 슬롯은 나중에"가 두 번째 원칙이다. vision과 compression은 보통 호출량이 가장 많은 슬롯에 속하므로 가장 먼저 분리할 후보다.

8. 트러블슈팅 — 흔한 오류와 진단 명령

보조 모델 설정에서 자주 발생하는 패턴은 셋이다.

첫째, provider 이름 오타.

둘째, base_url 누락이나 잘못된 스킴.

셋째, timeout이 짧아 외부 호출이 잘려 나가는 케이스. 셋 다 진단 명령으로 빠르게 좁힐 수 있다.

# 1) 현재 보조 모델 설정 확인
hermes config

# 2) 누락된 옵션 자동 추가/마이그레이션
hermes config migrate

# 3) 특정 값을 강제 검증하면서 설정
hermes config set auxiliary.vision.model openai/gpt-4o

공식 가이드는 hermes config로 현재 보조 모델 설정을 확인하고, hermes config migrate로 누락 옵션을 보충하며, hermes config set으로 특정 값을 검증하면서 갱신하라고 안내한다. 즉, "show → migrate → set"이 보조 모델 트러블슈팅의 기본 순서다.

8.1 "내 설정이 왜 무시되지?" 패턴

yaml을 고쳤는데도 변화가 보이지 않을 때 가장 먼저 의심할 곳은 두 가지다.

첫째, 편집한 yaml이 Hermes가 실제 읽는 경로와 다른 곳에 있는 경우. hermes config path 또는 env-path 부분 명령으로 현재 사용 중인 경로를 확인하면 된다(CLI 레퍼런스).

둘째, 키 계층 오류. auxiliary.vision.provider가 아니라 auxiliary.vision: openrouter처럼 한 단계가 빠진 경우다. 후자는 hermes config check로 잡아내는 게 빠르다.

8.2 timeout과 max_concurrency가 보내는 신호

session_search나 web_extract가 잦게 실패한다면 timeout 자체를 의심할 시점이다.

현재 공식 예시 기준으로 web_extract는 360초(6분), vision과 compression은 120초, approval과 session_search는 30초를 쓴다. vision에는 입력 파일을 가져오는 download_timeout: 30도 따로 있다. web_extract를 60~90초처럼 짧게 깎아두면 외부 페이지 응답을 기다리는 도중 호출이 잘리기 쉽고, session_search는 max_concurrency 값이 너무 크면 단기 부하가 튄다. 이 키들은 비용보다 안정성과 직결된다.

결론 — 비용 절감을 위한 도입 가이드

Hermes의 보조 모델 슬롯은 세 단계로 다듬으면 된다.

현황 파악: hermes config show로 모든 auxiliary.*.provider가 auto인지 확인한다. auto가 많을수록 메인 모델이 잡일을 떠맡고 있다는 뜻이다.
고비용 슬롯부터 분리: vision과 compression처럼 호출량이 많고 비용 영향이 큰 슬롯을 OpenRouter 경유 Flash 계열로 옮긴다. 인터랙티브 모드 한 번이면 충분하다.
세부 슬롯과 Curator 정리: web_extract의 timeout, session_search의 max_concurrency, 그리고 Curator(auxiliary.curator)까지 작업 성격에 맞춰 손본다. 운영 환경에서 키 이름이 다르다면 공식 문서와 hermes config show 출력을 우선한다.

한 가지만 기억한다면 충분하다. Hermes는 보조 슬롯을 분리해 비용을 줄이도록 설계되었지만, 기본값은 그 분리를 하지 않는다. 그 한 줄짜리 격차를 메우는 게 이 글이 다룬 전부다.

참고자료

저작자표시 비영리 변경금지 (새창열림)

'AI > Hermes' 카테고리의 다른 글

Hermes Agent(1) 시작하기 : 쓸수록 똑똑해지는 AI 에이전트(자가학습 메커니즘) - Hermes Agent로 반복 업무 자동화하기 (4)	2026.04.09

Contents

당신이 좋아할만한 콘텐츠

Hermes Agent(1) 시작하기 : 쓸수록 똑똑해지는 AI 에이전트(자가학습 메커니즘) - Hermes Agent로 반복 업무 자동화하기 2026.04.09

새소식