【#9】Hermes Agent 분석하기

지난 회차까지 Hermes의 '있는 그대로'의 능력은 충분히 살펴보았다. 하지만 실제 운용에서는 자신의 환경에 맞춰 능력을 추가하고 싶어지기 마련이다. Hermes는 코어 본체를 개조하지 않고도 확장할 수 있는 여러 경로를 마련해 두었다——플러그인(Plugin), 스킬(Skill), 훅(Hook), 프로파일(Profile), Cron. 이번에는 이러한 확장 운용과, 마지막으로 '학습 데이터 제조기'로서의 일면을 살펴본다.

플러그인은 4가지 소스에서 읽어온다.

bundled— Hermes에 동봉됨 -
user— 사용자의 ~/.hermes/ 하위 -
project— 프로젝트 디렉토리 -
pip— pip로 설치된 패키지

각 플러그인은 plugin.yaml (메타 정보)과 register(ctx) (등록 함수)를 가진다. 로딩은 kind 별——모델 프로바이더(Model Provider), 플랫폼(Platform), 메모리(Memory), 툴(Tool) 등 종류별로 적절한 레지스트리(Registry)로 분류된다. 제1회에서 보았던 28개의 모델 프로바이더와 8개의 플랫폼도 이 메커니즘을 통해 삽입되어 있다.

register(ctx)의 ctx (PluginContext)가 삽입할 수 있는 것은 다채롭다 (hermes_cli/plugins.py). register_tool / register_platform / register_command (슬래시(/) 커맨드) / register_cli_command (hermes <sub>) / register_memory_provider / register_web_search_provider / register_image_gen_provider / register_video_gen_provider / register_browser_provider / register_tts_provider / register_transcription_provider / register_context_engine / register_skill / register_hook ——즉, 코어의 거의 모든 레이어(Layer)에 개조 없이 삽입할 수 있는 인터페이스가 존재한다.

특히 강력한 것이 hook이다. register_hook(name, callback)을 통해 VALID_HOOKS (plugins.py:128)에 정의된 라이프사이클(Lifecycle)의 주요 지점에 개입할 수 있다. 확인된 주요 훅(Hook): pre_tool_call / post_tool_call (툴 실행 전후. pre_tool_call에서는 툴을 차단할 수도 있음), transform_tool_result / transform_terminal_output / transform_llm_output (출력의 재작성), on_session_start (세션 시작), pre_approval_request (승인 요청에 대한 개입) 등. 동작을 '외부에서' 변경할 수 있는 정규 경로다.

**스킬(Skill)**은 플러그인과 달리 코드가 아닌 선언적(Declarative) 방식이다. Markdown + YAML 프론트매터(Frontmatter)로 작성된 절차서이며, ~/.hermes/skills에 배치한다. 제5회의 skills_list / skill_view / skill_manage를 통해 다룰 수 있다.

핵심은 **progressive disclosure (단계적 개시)**이다. 스킬의 전문을 처음부터 컨텍스트(Context)에 쌓는 것이 아니라, 먼저 목록(이름 + 설명)만 보여주고 필요할 때 skill_view로 본문을 읽어온다. 컨텍스트를 절약하면서도 방대한 스킬 군을 보유할 수 있다.

스킬이 너무 많아지면 curator가 자동으로 정리한다 (agent/curator.py). 구체적인 기본값은 다음과 같다:

• 실행 간격 DEFAULT_INTERVAL_HOURS = 24 * 7 (7일마다)
• DEFAULT_STALE_AFTER_DAYS = 30 (30일 동안 사용되지 않으면 stale 판정)
• DEFAULT_ARCHIVE_AFTER_DAYS = 90 (90일이면 archive 후보)
• 자동 삭제는 하지 않으며, archive 처리만 수행한다. archive는 복구가 가능하다 (curator.py:17)

） - 보조 클라이언트 (auxiliary)에서 동작하며, 메인 대화의 prompt cache에는 전혀 관여하지 않는다 (curator.py:19)

청소는 하지만 삭제는 하지 않는, 안전한 방향으로 설계된 것이다. 이에 더해 skills_guard가 부정한 스킬의 로딩을 방지한다. 이는 제10회의 보안과 연결되는 방어 기제다.

이 부분은 나 자신이 일상적으로 사용하고 있는 영역이기에 구체적으로 작성하겠다. Hermes에는 obsidian 스킬이 있으며, 범용 파일 도구(제5회의 read_file / write_file / search_files)와 조합하면 Obsidian vault를 PKM (Personal Knowledge Management) 기반으로 다룰 수 있다.

실전적인 구성은 다음과 같다. cron으로 일일 저널을 자동 생성한다——매일 아침, 전날의 대화 로그나 태스크 보드의 상태를 Hermes가 요약하게 하여 vault의 일일 노트에 추가한다. obsidian 스킬이 노트의 포맷 규약(frontmatter, 링크 표기법)을 알고 있기 때문에, 수작업으로 정리하는 수고가 필요 없다. 나의 Mac Studio 상의 로컬 LLM과 이 메커니즘을 구축하면, 외부로 아무것도 보내지 않고 수중에만 지식을 축적해 나갈 수 있다.

Hooks— 라이프사이클의 요점(세션 시작 / 종료, 도구 실행 전후 등)이나 쉘 명령에 훅(hook)을 삽입할 수 있다. 단, --accept-hooks는 주의가 필요하다——훅은 임의의 코드를 실행할 수 있으므로, 신뢰할 수 없는 훅 정의를 검증 없이 받아들이는 것은 위험하다 (제10회).

Profiles— HERMES_HOME을 전환함으로써 설정, 상태, 자격 증명 정보를 프로파일 단위로 분리할 수 있다. 업무용과 개인용, 운영과 검증과 같은 용도 구분(使い分け)에 효과적이다.

Cron— 스케줄러. §3의 일일 저널과 같은 정기 실행을 담당한다.

HERMES_HOME을 통한 프로파일 분리는 제10회의 'terminal 백엔드 격리'와도 관련이 있다. 프로파일을 나누면 자격 증명의 혼선도 방지할 수 있다.

마지막으로, 간과하기 쉬운 측면. Hermes는 단순한 실행 에이전트가 아니라, 학습 데이터 제조기이기도 하다.

batch_runner (1,321행) — 다수의 태스크를 배치 실행 (multiprocessing, 체크포인트 포함)
mini_swe_runner (731행) — SWE (Software Engineering) 태스크를 local/docker/modal에서 실행
trajectory_compressor (1,508행) — 에이전트의 행동 궤적 (trajectory)을 학습용으로 압축

합쳐서 약 3,560행이 '실행'이 아닌 '데이터 생성'을 위한 도구들이다.

이것들은 강화학습 (RL)이나 지도 학습(supervised learning)을 위한 **궤적 데이터 (trajectory data)**를 양산하기 위한 도구들이다. 제5회에서 "TOOLSETS가 배치용으로 확률 분포를 가진다"라고 썼던 것을 기억해 주길 바란다——다양한 도구 구성을 샘플링하면서 태스크를 대량으로 실행하고, 그 궤적을 모아 학습에 활용한다. Nous Research가 모델을 훈련하는 조직이라는 점을 고려하면, Hermes Agent가 '제품'인 동시에 '데이터 생성 기반'이기도 하다는 이면성이 보인다.