최근 온라인 모각을 하다가 Hermes Agent의 도움말에서 hermes bundles라는 명령을 발견했습니다.
설명은 짧았습니다. 여러 Skill을 하나의 슬래시 명령으로 불러올 수 있다는 기능이었습니다.
처음 든 생각은 에이전트하네스 스터디 2주차에 만든 Umbrella였습니다. 큰 Skill을 작은 책임으로 나누고, 상위 Umbrella 아래에서 필요한 Skill을 연결하는 구조입니다. Hermes가 제품 기능으로 같은 것을 제공하기 시작한 걸까? 그렇다면 우리가 만든 Tree와 Circuit은 어디까지 필요할까?
이 질문은 문서 한 페이지만 읽어서는 정리되지 않았습니다. 기능이 처음 들어온 커밋과 릴리스, 실제 로더 코드와 테스트를 확인했습니다. OpenClaw, Claude Code, Codex의 현재 문서와 설치된 CLI도 같은 기준으로 비교했습니다.
기능은 5월에 먼저 들어와 있었습니다
Hermes Skill Bundle의 첫 구현은 2026년 5월 18일 오후 9시 38분(PDT) 커밋에서 확인됐습니다. 한국 시간으로는 5월 19일 오후 1시 38분입니다.
커밋 제목은 이랬습니다.
feat(skills): add skill bundles — alias /<name> loads multiple skills
이 커밋에서 agent/skill_bundles.py, CLI와 gateway 연결부, 문서, 테스트가 함께 추가됐습니다. 코드만 먼저 들어오고 문서가 나중에 붙은 형태는 아니었습니다.
이 구현을 포함한 첫 정식 태그는 v2026.5.28입니다. 5월 28일 공개된 Hermes Agent v0.15.0 릴리스 노트에도 Skill Bundle이 주요 기능으로 소개됐습니다. 릴리스 노트의 표현은 “하나의 슬래시 명령으로 전체 workflow를 불러온다”였습니다. 다만 구현에서 이 workflow는 단계 실행기나 상태 머신이 아니라, 여러 Skill 지침을 함께 펼친 하나의 context preset이었습니다.
제가 기능을 발견한 건 8월 초였지만, 저장소에는 약 두 달 반 전부터 들어와 있었습니다.
현재 설치된 Hermes는 v0.19.1입니다. Bundle 관련 테스트 세 파일을 다시 실행하니 21개가 모두 통과했습니다. 다만 현재 사용 중인 프로필에는 아직 Bundle을 하나도 등록하지 않았습니다. 지금 단계는 도입 사례가 아니라 기능을 발견하고 구조를 확인한 기록입니다.
Bundle이 실제로 하는 일
Bundle은 작은 YAML 파일입니다. 이름과 설명, 함께 불러올 Skill 목록, 선택적인 공통 지시를 저장합니다.
name: public-safe
description: 공개 글에 동시에 적용할 독립 지침 조합
skills:
- source-citation
- privacy-redaction
instruction: 출처 표기와 개인정보 보호 기준을 함께 적용한다.
이 파일을 등록하고 /public-safe를 입력하면 Hermes가 고정 목록을 읽기 시작합니다.
/public-safe
→ YAML에서 고정된 Skill 목록 확인
→ 각 Skill의 SKILL.md 읽기
→ Bundle 공통 지시와 Skill 본문 결합
→ 하나의 사용자 메시지로 구성
→ 실제 요청과 함께 일반 agent loop에 전달
Bundle이 고르는 것은 “어떤 Skill을 항상 같이 펼칠 것인가”입니다. 호출할 때마다 Skill 이름을 다시 나열하지 않아도 됩니다. 자주 반복되는 조합에 이름을 붙여두는 단축키에 가깝습니다.
반대로 Bundle 자체는 현재 요청을 읽고 Skill 일부만 고르지 않습니다. 첫 Skill의 결과에 따라 다음 Skill을 바꾸지도 않습니다. 결과가 기준을 통과했는지 검사하거나, 실패한 지점만 고쳐 다시 호출하는 규칙도 없습니다.
Bundle 안에 Workflow Skill이나 Router Skill을 넣을 수는 있습니다. 그때 분기와 재호출을 만드는 주체는 Bundle이 아니라, Bundle이 불러온 Skill의 지시 와 실행기입니다.
우리가 만든 Umbrella는 Skill 목록부터 정하지 않았습니다
2주차에는 큰 Skill을 먼저 여러 조각으로 나누지 않았습니다. 처음 입력부터 최종 출력, 전달, 검증, 실패 수리까지 전체 절차를 펼쳤습니다. 그다음 각 절차의 입력과 출력, 실패 책임자, 검증 방법, 수리 방법, 사용하는 도구와 변경 주기를 비교했습니다.
경계가 독립적일 때 작은 Skill로 분리했습니다. 앞뒤 절차와 실패 원인, 검증 방식이 같으면 부모 Skill 안에 남겼습니다. 반복 가능하지만 스스로 사용자 의도와 완료 조건을 책임지지 않는 부분은 script나 template으로 분류했습니다.
이 과정을 거친 뒤에야 Umbrella Tree가 생겼습니다.
- Tree는 어떤 Skill이 어느 Umbrella에 속하는지 보여줍니다.
- Circuit은 입력, 호출, 전달, 검증 반환, 실패 반환의 순서를 보여줍니다.
- Navigator는 현재 요청과 문맥에 맞는 경로를 고릅니다.
- Harness는 완료 기준과 Proof를 확인하고, Gate 실패 시 수리와 재판정을 통제합니다.
여기에도 경계가 있습니다. Umbrella와 화살표를 문서에 그렸다고 자동 실행이 생기지는 않습니다. Router, Workflow, Verifier, Repair 규칙이 실제 지시나 코드로 구현되어야 동적인 Circuit이 됩니다.
예를 들어 source-citation과 privacy-redaction을 public-safe Bundle로 묶으면 두 지침은 한 작업에서 동시에 참고됩니다. 이것은 출처 표기 → 개인정보 제거라는 실행 순서를 만든다는 뜻이 아닙니다.
작업에 조사 → 작성 → 검증 순서가 필요하다면 Navigator가 그 Circuit을 선택하고, Workflow와 Harness가 각 단계의 입력·출력 전달과 실패 반환을 집행해야 합니다. Bundle은 이 실행 경로를 만들지 않습니다.
같은 능력 집합을 다루더라도 Bundle은 고정 컨텍스트를 펼치고, Umbrella·Circuit·Harness는 현재 상태에 맞는 경로와 실행 계약을 담당합니다.
OpenClaw에는 복수 Skill 명시 호출이 있었습니다
현재 설치된 OpenClaw는 2026.7.1입니다.
공식 Skill 문서에는 한 프롬프트에서 여러 Skill을 직접 지정하는 방법이 있습니다. $github와 $release_notes를 함께 적으면 OpenClaw가 두 Skill의 SKILL.md를 각각 읽어 Skill directive로 추가합니다.
$github $release_notes 이번 배포 변경점을 정리해줘
Hermes Bundle과 가장 가까운 동작입니다. 차이는 조합의 저장 여부입니다. OpenClaw에서는 프롬프트에 Skill 이름을 다시 적습니다. 2026년 8월 3일 현재 공식 Skill 문서와 CLI 도움말에서는 이 조합을 별도 이름으로 저장해 한 명령으로 다시 펼치는 기능을 확인하지 못했습니다.
OpenClaw 문서에도 “bundled skills”와 “Plugin bundles”라는 표현이 나옵니다. 앞의 bundled skills는 설치본에 포함된 내장 Skill을 뜻합니다. Plugin bundles는 다른 생태계의 Plugin 묶음을 가져와 배포하는 기능입니다. 둘 다 Hermes Skill Bundle의 저장된 activation alias와는 다른 용도입니다.
Claude Code는 여러 Skill을 한 메시지에 쌓을 수 있었습니다
현재 설치된 Claude Code는 2.1.216입니다.
Claude Code 공식 문서는 메시지 시작 부분에 여러 Skill을 연달아 쓰는 stacked skills를 지원합니다.
/write-tests /fix-issue 123
이 입력은 두 Skill을 모두 로드하고 123을 각 Skill의 인수로 전달합니다. 중요한 점은 여러 Skill을 한 메시지에 쌓을 수 있다는 것이고, 매번 각 Skill 이름을 적어야 하므로 저장된 조합 별칭은 아니라는 것입니다. 공식 문서에는 2.1.199 이전에는 첫 Skill만 로드됐다고 적혀 있습니다.
Claude Code Plugin은 Skill뿐 아니라 Agent, Hook, MCP server를 한 패키지로 배포할 수 있습니다. 다만 Plugin 안의 Skill은 /plugin-name:skill-name처럼 각각의 이름으로 호출됩니다. Plugin 설치가 그 안의 모든 Skill을 한 요청에 펼친다는 뜻은 아닙니다.
Claude Code에는 수동 복수 적재와 배포 패키지가 모두 있습니다. 공식 문서와 현재 CLI에서 Hermes처럼 자주 쓰는 Skill 조합을 하나의 새 별칭으로 저장하는 기능은 확인하지 못했습니다.
Codex의 Plugin은 묶어서 배포하고, Skill은 필요할 때 고릅니다
현재 설치된 Codex CLI는 0.144.1입니다.
Codex는 $skill-name으로 Skill을 직접 선택하거나, 요청과 Skill 설명이 맞을 때 자동으로 선택합니다. 처음부터 모든 Skill 본문을 읽지 않고 이름과 설명을 먼저 본 뒤, 선택한 SKILL.md를 읽는 progressive disclosure 방식입니다.
Codex 공식 문서는 두 개 이상의 Skill을 함께 배포하려면 Plugin으로 패키징하라고 안내합니다. Plugin에는 여러 Skill과 MCP server 설정, 화면 자산을 함께 넣을 수 있습니다.
현재 설치본의 sites Plugin도 Skill 두 개와 MCP server, App 설정을 함께 담고 있습니다. 하지만 Plugin manifest는 Skill 디렉터리를 등록할 뿐, 두 Skill을 매 요청마다 모두 펼치는 별칭을 만들지 않습니다. sites-building Skill이 작업 뒤 sites-hosting을 사용하라고 지시하는 부분은 Plugin의 자동 activation이 아니라 Skill 안에 작성된 Workflow입니다.
Codex에도 Skill 묶음은 있습니다. 다만 그 묶음은 설치와 배포의 단위이고, 실행 시에는 필요한 Skill을 직접 지정하거나 모델이 선택합니다.
같은 단어보다 동작을 기준으로 비교했습니다
/<bundle>$skill-a $skill-b/skill-a /skill-b$skill, 자동 선택, Plugin이 표에서 Plugin과 Bundle을 같은 뜻으로 읽으면 다시 섞입니다. Plugin은 여러 능력을 설치하고 배포하는 포장입니다. Hermes Bundle은 이미 설치된 여러 Skill을 한 요청에 펼치는 activation preset입니다. Umbrella는 현재 요청을 어느 책임과 Circuit으로 보낼지 결정하는 구조입니다.
Bundle로 Circuit을 만들 수는 없었습니다
초안을 다시 검토하다가 첫 실험안에도 문제가 있다는 걸 발견했습니다. 조사, 작성, 검증 Skill을 한 Bundle에 넣으면 실행 경로 하나가 될 것 같았지만, Bundle은 단계와 순서를 정의하지 않습니다.
구현에서는 YAML의 Skill 목록을 차례로 읽어 각 SKILL.md 본문을 하나의 user message에 이어 붙입니다. 이 순서는 메시지 안에서 Skill 블록이 놓이는 순서일 뿐, 조사 결과를 작성에 전달하고 작성 결과를 검증한다는 실행 순서가 아닙니다. 선택적인 Bundle instruction에 순서를 문장으로 적을 수는 있지만, 그것도 프롬프트 지시입니다. 단계별 상태, 중간 산출물 전달, Gate, 실패 반환을 강제하지는 않습니다.
설명만으로 끝내지 않고 격리된 임시 HERMES_HOME에서 실제 shadow test를 돌렸습니다. A, B, C라는 합성 Skill 세 개와 Bundle 두 개를 만들었습니다.
# shadow-abc
skills: [A, B, C]
instruction: A 다음 B, 그다음 C를 실행하고 산출물을 전달하라
# shadow-cba
skills: [C, B, A]
instruction: A 다음 B, 그다음 C를 실행하고 산출물을 전달하라
두 Bundle의 자연어 instruction은 같게 두고 Skill 목록 순서만 반대로 만들었습니다. 실제 Hermes CLI에서 두 Bundle을 각각 호출하고, 로컬 OpenAI 호환 기록 서버로 provider 요청 payload를 캡처했습니다.
shadow-abc Skill 블록 직렬화shadow-cba Skill 블록 직렬화Hermes가 세션 제목을 만들기 위해 보낸 보조 호출 2회는 stage 실행과 분리해 집계했습니다. 목록을 뒤집자 바뀐 것은 한 user message 안에서 Skill 문서가 놓인 순서뿐이었습니다. 두 요청 모두 “A 다음 B, 그다음 C”라는 instruction을 포함했지만, A의 출력 객체, B의 입력 상태, C의 검증 Gate는 생기지 않았습니다.
이 shadow test는 실제 모델의 순응률을 재는 실험이 아니라 Bundle 런타임의 실행 계약을 확인하는 실험입니다. 실제 LLM이 자연어 지시를 보고 우연히 A → B → C를 따라갈 수는 있습니다. 하지만 그것은 모델의 프롬프트 순응이지 Bundle이 순서를 집행했다는 증거가 아닙니다.
따라서 우리 구조에서 역할은 이렇게 나뉘어야 합니다.
Bundle
→ 한 user message에 여러 Skill 지침을 함께 준비
Umbrella · Navigator
→ 현재 요청이 갈 Circuit을 선택
Workflow · Circuit
→ 단계 순서와 Skill 사이의 입력·출력 전달을 정의
Harness
→ 선택된 단계를 실행하고 Proof · Gate · Repair · Retry · Stop을 통제
Bundle에 조사, 작성, 검증을 나란히 넣는 것만으로는 조사 → 작성 → 검증 Circuit이 생기지 않습니다. 그 순서는 Workflow나 Circuit이 소유해야 하고, 실제로 순서가 지켜졌는지와 실패 시 어디로 돌아갈지는 Harness가 확인해야 합니다.
그렇다면 우리 구조에서 Bundle을 시험할 자리는 실행 경로가 아닙니다. 서로 다른 책임을 유지하면서도 한 작업 내내 동시에 참고해야 하는 독립 지침 조합이 실제로 있는지부터 확인해야 합니다. 그런 조합이 없다면 Bundle을 억지로 붙이지 않는 편이 맞습니다.
현재 우리 Hermes에는 등록된 Bundle이 없습니다. 이 0개 상태를 기준선으로 남겨두고, 실행 순서가 필요 없는 독립 지침 조합이 발견될 때만 Bundle 호출 전후의 컨텍스트 크기, 지침 충돌, 누락, 결과 품질을 비교할 수 있습니다.
온라인 모각에서 처음 명령을 봤을 때는 “Hermes가 Umbrella를 제품 기능으로 만든 건가?”라고 생각했습니다. 코드를 확인하고 shadow test까지 돌리면서 질문이 두 번 바뀌었습니다. Bundle은 Umbrella가 아니고, Circuit을 대신하지도 않습니다.
