Hermes Agent SKILL.md를 Git Tap으로 중앙화하면 멀티 인스턴스가 동일한 스킬 베이스를 공유한다

AI 에이전트를 팀 단위로 운영하다 보면 어느 순간 이런 상황을 맞닥뜨리게 됩니다. 내 로컬 Hermes가 지난주에 완벽하게 처리한 배포 체크리스트 작업을, 옆자리 동료 머신에서 돌아가는 인스턴스는 처음 보는 것처럼 똑같이 처음부터 다시 파악합니다. 각자 에이전트가 독자적으로 경험을 쌓지만, 그 경험이 팀 자산으로 쌓이지 않는 거죠. 이게 단순히 비효율 문제가 아닌 이유는, 에이전트 수가 늘어날수록 "누가 무엇을 알고 있는가"의 격차가 기하급수적으로 커지기 때문입니다. 저도 인스턴스 세 개쯤 굴리기 시작했을 때 "이 스킬 저 인스턴스는 모르는구나"를 반복하면서 결국 수동으로 파일을 복붙하고 다녔는데, 그게 얼마나 오래가지 않는 방식인지는 금방 느끼게 됩니다.

Hermes Agent의 SKILL.md 자동 생성과 Git Tap 시스템을 결합하면 이 문제를 상당 부분 해결할 수 있습니다. 에이전트가 복잡한 작업을 수행하며 쌓은 경험을 표준 포맷의 문서로 자동 추출하고, 그걸 팀 Git 저장소에 올려두면 다른 인스턴스들이 명령 한 줄로 동기화합니다. Git이 단일 진실 공급원이 되는 거예요. 이 글을 읽고 나면 Hermes의 스킬 자동 생성 메커니즘부터 팀 Tap 저장소 구성, 멀티 인스턴스 병렬 운영까지 실제 팀에 적용할 수 있는 멀티에이전트 GitOps 패턴을 직접 구성할 수 있습니다.

핵심 개념

SKILL.md가 생성되는 시점과 구조

Hermes Agent는 도구 호출이 5번 이상 이어지는 복잡한 작업을 완료하면 해당 경험을 SKILL.md 파일로 자동 추출합니다. 저장 경로는 ~/.hermes/skills/<category>/<skill-name>/SKILL.md 형태인데, 카테고리와 스킬명은 작업의 맥락에서 자동으로 추론됩니다.

yaml

# ~/.hermes/skills/deployment/deploy-checklist/SKILL.md
---
name: deploy-checklist
description: 스테이징 → 프로덕션 배포 전 확인 절차 자동화
metadata:
  type: workflow
  tools: [bash, github, slack]
  created: 2026-05-16
  version: 1.2.0
---
 
## 배포 전 확인 절차
 
이 스킬은 배포 전 다음 단계를 순서대로 처리합니다...

SKILL.md 포맷이란 Hermes, Claude Code, Codex 등 여러 에이전트 플랫폼이 공통으로 인식하도록 설계된 에이전트 경험 공유 문서 포맷입니다. frontmatter(name, description, metadata)에 스킬 메타데이터를 담고, 본문에 절차를 기술하는 구조입니다. 플랫폼마다 지원 필드가 미묘하게 다를 수 있어서, 팀 공용 템플릿을 사전에 정의해두면 나중에 파싱이나 검색이 훨씬 수월합니다.

v0.14.0 기준으로 셀프-이볼빙(self-evolving) 메커니즘도 내장되어 있습니다. 이미 존재하는 스킬이 실제 사용 중에 오래되거나 불완전한 것으로 감지되면 에이전트가 자동으로 해당 내용을 패치합니다. 처음엔 꽤 편리해 보이는데, 솔직히 이건 양날의 검입니다. 에이전트가 품질 지표를 왜곡하는 방향으로 스킬을 수정하거나, PR 없이 main에 직접 커밋하도록 설정된 경우 스킬이 어느 순간 알 수 없는 방향으로 변질될 수 있거든요. 셀프-이볼빙 설정을 켤 때는 자동 패치 범위를 제한하고 반드시 PR 경유로만 머지되도록 브랜치 보호 규칙을 걸어두는 것이 스킬 품질을 지키는 데 훨씬 안전했습니다.

Tap 시스템: Git 저장소를 스킬 레지스트리로

Tap은 Hermes에서 스킬을 배포하는 단위입니다. 핵심은 별도 레지스트리 서버가 필요 없다는 겁니다. GitHub 저장소 하나에 정해진 디렉터리 구조만 맞춰두면 그게 곧 팀 스킬 레지스트리가 됩니다.

my-org/hermes-skills
├── skills/
│   ├── code-review/
│   │   └── SKILL.md
│   ├── deploy-checklist/
│   │   └── SKILL.md
│   └── incident-response/
│       ├── SKILL.md
│       └── references/
│           └── runbook.md
└── README.md

루트 아래 skills/ 디렉터리가 핵심이고, 그 안에서 스킬명 폴더 → SKILL.md 구조만 지키면 됩니다. 참조 문서(런북, 설정 파일 등)는 references/ 서브 디렉터리로 함께 두면 스킬 문서에서 상대 경로로 참조할 수 있습니다.

단일 진실 공급원(Single Source of Truth) Git 저장소 하나를 스킬의 공식 출처로 삼으면, 어떤 인스턴스가 어떤 버전의 스킬을 쓰고 있는지 추적하고 롤백하는 것이 일반적인 Git 워크플로로 자연스럽게 처리됩니다.

Profile Distribution: 스킬을 넘어 팀 설정 전체를 패키징

v0.14.0에 추가된 Profile Distribution은 스킬뿐 아니라 퍼스낼리티 설정, cron 작업, MCP 연결 설정 전체를 Git 저장소 하나로 패키징해 배포하는 기능입니다. 팀 신규 입사자가 에이전트 환경을 맞추는 데 걸리는 시간이 수 시간에서 몇 분으로 줄어드는 효과가 있습니다. 팀원이 hermes profile update <name> 명령 하나로 최신 팀 설정으로 동기화됩니다.

실전 적용

기본 구성 — 처음 시작하는 팀

예시 1: 팀 Tap 저장소 초기 구성

가장 기본적인 시작 방법입니다. 빈 GitHub 저장소에 구조를 잡고, 팀원들이 Tap으로 추가하는 흐름입니다.

bash

# 0. 먼저 GitHub에서 빈 프라이빗 저장소를 만들어야 합니다
#    github.com/new → 저장소 이름: hermes-skills, Private 선택 후 생성
 
# 1. 로컬에서 스킬 저장소 초기화
mkdir hermes-skills && cd hermes-skills
git init
mkdir -p skills/code-review skills/deploy-checklist
 
# 2. 기존 로컬 스킬을 저장소로 복사
cp ~/.hermes/skills/deployment/deploy-checklist/SKILL.md \
   skills/deploy-checklist/SKILL.md
 
# 3. GitHub에 푸시
git add . && git commit -m "init: 팀 스킬 베이스 초기 구성"
git remote add origin https://github.com/my-org/hermes-skills.git
git push -u origin main

팀원 온보딩은 이게 전부입니다:

bash

# 프라이빗 저장소 접근을 위한 GitHub Personal Access Token 설정
# GitHub → Settings → Developer settings → Personal access tokens (Classic)
# 필요한 권한: repo (Read access to code and metadata)
export GITHUB_TOKEN=ghp_xxxxxxxxxxxxxxxxxxxx
# 영구 등록은 ~/.zshrc 또는 ~/.bashrc에 위 줄을 추가하면 됩니다
 
# 팀원 머신에서 Tap 추가
hermes skills tap add my-org/hermes-skills
 
# 전체 스킬 동기화
hermes skills sync
 
# 동기화된 스킬 확인
hermes skills list

명령어	역할
`tap add`	GitHub 저장소를 스킬 소스로 등록
`skills sync`	등록된 Tap에서 최신 스킬을 로컬에 동기화
`skills list`	현재 사용 가능한 스킬 목록 조회
`skills tap remove`	Tap 등록 해제

예시 2: hermes-skill-factory로 스킬 자동 캡처 → Git 기여

매번 수동으로 스킬을 복사하는 건 금방 귀찮아집니다. hermes-skill-factory 플러그인을 붙이면 워크플로 수행 중에 패턴을 감지해서 SKILL.md를 자동 생성하고 PR까지 열어줍니다.

bash

# hermes-skill-factory 플러그인 설치
hermes plugins install hermes-skill-factory
 
# 플러그인이 감시할 Tap 저장소 경로 설정
hermes config set skill-factory.tap-repo my-org/hermes-skills
hermes config set skill-factory.auto-pr true

이후 에이전트가 5회 이상 도구 호출이 이어지는 복잡한 작업을 완료하면, 플러그인이 자동으로 다음 흐름을 처리합니다:

작업 완료
  → SKILL.md 자동 생성 (~/.hermes/skills/...)
  → Tap 저장소에 feature/skill-<name> 브랜치 생성
  → SKILL.md 커밋 & 푸시
  → PR 자동 오픈 (리뷰어 지정 가능)

이 패턴의 핵심은 에이전트가 PR을 여는 것이지 직접 main에 머지하지 않는다는 점입니다. 자동화와 인간 리뷰 사이의 경계를 Git PR 워크플로로 자연스럽게 유지할 수 있어서, 실무에서 가장 안전하게 쓸 수 있는 구성이었습니다.

고급 확장 — 이미 운영 중인 팀의 다음 단계

예시 3: Git Worktree를 활용한 멀티 인스턴스 병렬 실행

같은 저장소에서 여러 에이전트 인스턴스가 각자 다른 피처 브랜치를 작업하면서, 스킬 베이스만 공유하는 구성입니다. Git Worktree를 쓰면 체크아웃을 여러 개 유지할 수 있어서 인스턴스 격리가 깔끔하게 됩니다.

bash

# 메인 저장소 클론
git clone https://github.com/my-org/project.git
cd project
 
# 각 에이전트 인스턴스를 위한 별도 Worktree 생성
git worktree add ../agent-feature-a feature/a
git worktree add ../agent-feature-b feature/b
 
# 인스턴스 A 실행 (별도 터미널)
# hermes start: 현재 디렉터리를 컨텍스트로 Hermes 에이전트를 인터랙티브 세션으로 시작합니다
# 작업 지시를 직접 입력하거나 스크립트로 자동화할 수 있습니다
cd ../agent-feature-a && hermes start
 
# 인스턴스 B 실행 (또 다른 터미널)
cd ../agent-feature-b && hermes start
 
# 두 인스턴스 모두 ~/.hermes/skills/ 경로는 동일하게 공유됩니다
# Tap 동기화 한 번으로 모든 인스턴스에 스킬이 적용됩니다
hermes skills sync  # 어느 경로에서 실행해도 공유됩니다

Git Worktree 하나의 Git 저장소에서 여러 브랜치를 동시에 다른 디렉터리로 체크아웃할 수 있는 기능입니다. 인스턴스마다 저장소를 통째로 복제하는 것보다 디스크 공간을 절약하면서도 각 작업 환경을 격리할 수 있습니다.

예시 4: FluxCD 방식의 서명된 스킬 배포

Kubernetes/GitOps 환경에서는 FluxCD의 agent-skills 저장소 패턴을 참고해볼 수 있습니다. OCI 아티팩트로 패키징하고 cosign으로 서명하여 에이전트가 신뢰할 수 있는 스킬만 사용하도록 강제하는 방식입니다.

bash

# Flux Operator CLI가 서명 검증 후 스킬 추출
flux agent-skills pull \
  --source ghcr.io/fluxcd/agent-skills:latest \
  --verify-signature \
  --output .agents/skills/
 
# 추출된 스킬 구조
# .agents/skills/
# ├── gitops-knowledge/SKILL.md
# ├── gitops-repo-audit/SKILL.md
# └── gitops-cluster-debug/SKILL.md

OCI 아티팩트 & cosign 컨테이너 이미지 레지스트리(ghcr.io 등)에 파일을 패키징해 배포하는 방식입니다. cosign은 이 아티팩트에 디지털 서명을 붙여 변조 여부를 검증하는 오픈소스 도구입니다. 서명 없는 스킬은 에이전트가 아예 실행을 거부하므로 출처와 무결성을 엄격히 통제해야 하는 환경에 적합합니다. DevOps 경험이 없다면 진입 장벽이 있는 방식이어서, 앞의 GitHub 기반 Tap 구성에 먼저 익숙해진 다음 검토해보시면 좋습니다.

장단점 분석

장점

항목	내용
버전 관리 내재화	스킬 변경 이력, 롤백, 감사 추적이 git log 하나로 해결됩니다
온보딩 시간 단축	신규 팀원/인스턴스가 `tap add` + `skills sync` 두 명령으로 전체 스킬 베이스를 동기화할 수 있습니다
CI/CD 통합	스킬 품질 검증, 자동 배포, 실패 시 롤백을 기존 파이프라인에 그대로 얹을 수 있습니다
이기종 에이전트 지원	SKILL.md가 Claude Code, Codex, Hermes에서 공통으로 인식되어 플랫폼 간 지식 공유가 가능합니다
셀프-이볼빙 루프	에이전트가 실제 사용 중 스킬을 개선하고 PR로 기여하는 지속 개선 사이클이 자연스럽게 형성됩니다

단점 및 주의사항

항목	내용	대응 방안
리뷰 피로	에이전트 생성 PR이 대량 유입되면 인간 리뷰어 부담이 급증합니다	CI에 SKILL.md 포맷 검증, 민감 정보 스캐닝, 중복 감지 같은 품질 게이트를 구성해두면 리뷰어가 내용에만 집중할 수 있어서 훨씬 수월했습니다
인증 관리	프라이빗 Tap은 `GITHUB_TOKEN`이 필요하고, 이 토큰이 스킬 파일에 노출될 위험이 있습니다	CI에 secrets 스캐닝을 추가하고, SKILL.md에 자격증명이 포함되지 않도록 pre-commit 훅을 붙여두는 게 안전합니다. `detect-secrets` 플러그인과 함께 쓰면 커밋 직전에 자동으로 잡아줍니다
스킬 중복/충돌	여러 인스턴스가 독립적으로 스킬을 생성하면 유사한 스킬이 중복 누적됩니다	SkillClaw 같은 중복 제거 도구를 활용하거나, 팀 공용 명명 규칙(카테고리/스킬명 컨벤션)을 사전에 정의해두는 게 훨씬 효과적입니다
포맷 파편화	플랫폼별로 SKILL.md frontmatter 필드가 미묘하게 다릅니다	저장소 루트에 `SKILL_TEMPLATE.md`를 두고, 신규 스킬 생성 시 이를 기반으로 작성하도록 가이드해두면 나중에 일괄 파싱이나 검색이 훨씬 수월합니다
셀프-이볼빙 오염	품질 지표를 왜곡하는 방향으로 스킬이 자동 수정될 수 있습니다	자동 패치 범위를 명시적으로 제한하고 PR 경유 없이 main에 직접 커밋하지 않도록 브랜치 보호 규칙을 설정해두는 게 이 문제를 막는 가장 확실한 방법이었습니다

품질 게이트(Guardrail) CI 파이프라인에서 스킬 PR이 머지되기 전에 자동으로 검증하는 단계입니다. SKILL.md 포맷 유효성 검사, 민감 정보 스캐닝, 중복 스킬 감지 등을 포함시킬 수 있습니다.

실무에서 가장 흔한 실수

스킬 저장소를 public으로 열어두는 것 — 스킬에는 내부 시스템 구조, 도구 이름, 프로세스 절차가 상세히 담기기 때문에 민감 정보가 되는 경우가 많습니다. 프라이빗으로 시작해서 공개 범위를 신중하게 검토하는 것이 좋습니다.
셀프-이볼빙을 무제한으로 허용하는 것 — 에이전트가 스킬을 자동 패치할 수 있다는 건 편리하지만, PR 없이 main 브랜치에 직접 커밋하도록 설정하면 스킬이 어느 순간 알 수 없는 방향으로 변질될 수 있습니다. 자동 패치도 PR 경유가 이 문제를 막는 제일 확실한 방법이었습니다.
팀 공용 SKILL.md 템플릿 없이 시작하는 것 — 에이전트마다 frontmatter 필드를 다르게 생성하면 나중에 일괄 파싱이나 검색이 어려워집니다. 저장소 초기에 SKILL_TEMPLATE.md를 만들어두고 컨벤션을 고정해두는 시간이 결코 낭비가 아닙니다.

마치며

에이전트 인스턴스가 늘어나기 시작하면 "이 스킬 저 인스턴스는 모르는구나"를 반복하면서 수동으로 파일을 복붙하는 시간이 생각보다 빠르게 찾아옵니다. SKILL.md를 Git으로 중앙화하고 나서 가장 크게 느낀 변화는, 새 인스턴스를 추가할 때 셋업 시간이 아니라 작업 자체에 집중할 수 있게 됐다는 점입니다. Git을 스킬의 단일 진실 공급원으로 삼는 이 구조는, 에이전트가 늘어날수록 더 확실하게 그 가치를 발휘합니다. Gartner는 2026년 말까지 엔터프라이즈 애플리케이션의 40%가 작업별 AI 에이전트를 내장할 것으로 예측하는데(2025년 기준 5% 미만), 지금 이 구조를 팀에서 작게 실험해두는 것과 나중에 규모가 커진 뒤 정리하려는 것은 꽤 다른 비용으로 돌아옵니다.

지금 바로 시작해볼 수 있는 3단계:

Tap 저장소 한 개 만들어보기 — GitHub에 <org>/hermes-skills 프라이빗 저장소를 만들고 skills/ 디렉터리를 초기화한 뒤, 로컬의 ~/.hermes/skills/ 중 가장 자주 쓰는 스킬 하나를 skills/<name>/SKILL.md로 복사해서 커밋해 보시면 됩니다.
팀원 한 명과 Tap 공유 테스트 — hermes skills tap add <org>/hermes-skills && hermes skills sync 명령으로 동기화가 잘 되는지 확인하고, 동료 인스턴스에서 공유한 스킬이 실제로 작동하는지 간단한 작업으로 검증해 보시면 좋습니다.
스킬 PR 워크플로 설정 — hermes-skill-factory를 설치하고 auto-pr: true 옵션을 켠 다음, 에이전트가 생성한 첫 번째 자동 PR을 리뷰하면서 품질 게이트 기준을 잡아보시면 됩니다. 첫 PR의 품질을 보면 어떤 검증이 필요한지 감이 바로 옵니다.

이 블로그의 시리즈 태그를 팔로우해 두시면 이어지는 내용을 놓치지 않고 확인해보실 수 있습니다.

참고 자료

#HermesAgent#GitOps#SKILL.md#멀티에이전트#GitWorktree#FluxCD#OCI아티팩트#AI에이전트#지식공유#CI-CD

Hermes Agent SKILL.md를 Git Tap으로 중앙화하면 멀티 인스턴스가 동일한 스킬 베이스를 공유한다 | DEV BAK - 기술블로그

Hermes Agent SKILL.md를 Git Tap으로 중앙화하면 멀티 인스턴스가 동일한 스킬 베이스를 공유한다

핵심 개념

SKILL.md가 생성되는 시점과 구조

yaml

# ~/.hermes/skills/deployment/deploy-checklist/SKILL.md
---
name: deploy-checklist
description: 스테이징 → 프로덕션 배포 전 확인 절차 자동화
metadata:
  type: workflow
  tools: [bash, github, slack]
  created: 2026-05-16
  version: 1.2.0
---
 
## 배포 전 확인 절차
 
이 스킬은 배포 전 다음 단계를 순서대로 처리합니다...

SKILL.md 포맷이란 Hermes, Claude Code, Codex 등 여러 에이전트 플랫폼이 공통으로 인식하도록 설계된 에이전트 경험 공유 문서 포맷입니다. frontmatter(name, description, metadata)에 스킬 메타데이터를 담고, 본문에 절차를 기술하는 구조입니다. 플랫폼마다 지원 필드가 미묘하게 다를 수 있어서, 팀 공용 템플릿을 사전에 정의해두면 나중에 파싱이나 검색이 훨씬 수월합니다.

Tap 시스템: Git 저장소를 스킬 레지스트리로

my-org/hermes-skills
├── skills/
│   ├── code-review/
│   │   └── SKILL.md
│   ├── deploy-checklist/
│   │   └── SKILL.md
│   └── incident-response/
│       ├── SKILL.md
│       └── references/
│           └── runbook.md
└── README.md

단일 진실 공급원(Single Source of Truth) Git 저장소 하나를 스킬의 공식 출처로 삼으면, 어떤 인스턴스가 어떤 버전의 스킬을 쓰고 있는지 추적하고 롤백하는 것이 일반적인 Git 워크플로로 자연스럽게 처리됩니다.

Profile Distribution: 스킬을 넘어 팀 설정 전체를 패키징

실전 적용

기본 구성 — 처음 시작하는 팀

예시 1: 팀 Tap 저장소 초기 구성

가장 기본적인 시작 방법입니다. 빈 GitHub 저장소에 구조를 잡고, 팀원들이 Tap으로 추가하는 흐름입니다.

bash

# 0. 먼저 GitHub에서 빈 프라이빗 저장소를 만들어야 합니다
#    github.com/new → 저장소 이름: hermes-skills, Private 선택 후 생성
 
# 1. 로컬에서 스킬 저장소 초기화
mkdir hermes-skills && cd hermes-skills
git init
mkdir -p skills/code-review skills/deploy-checklist
 
# 2. 기존 로컬 스킬을 저장소로 복사
cp ~/.hermes/skills/deployment/deploy-checklist/SKILL.md \
   skills/deploy-checklist/SKILL.md
 
# 3. GitHub에 푸시
git add . && git commit -m "init: 팀 스킬 베이스 초기 구성"
git remote add origin https://github.com/my-org/hermes-skills.git
git push -u origin main

팀원 온보딩은 이게 전부입니다:

bash

# 프라이빗 저장소 접근을 위한 GitHub Personal Access Token 설정
# GitHub → Settings → Developer settings → Personal access tokens (Classic)
# 필요한 권한: repo (Read access to code and metadata)
export GITHUB_TOKEN=ghp_xxxxxxxxxxxxxxxxxxxx
# 영구 등록은 ~/.zshrc 또는 ~/.bashrc에 위 줄을 추가하면 됩니다
 
# 팀원 머신에서 Tap 추가
hermes skills tap add my-org/hermes-skills
 
# 전체 스킬 동기화
hermes skills sync
 
# 동기화된 스킬 확인
hermes skills list

명령어	역할
`tap add`	GitHub 저장소를 스킬 소스로 등록
`skills sync`	등록된 Tap에서 최신 스킬을 로컬에 동기화
`skills list`	현재 사용 가능한 스킬 목록 조회
`skills tap remove`	Tap 등록 해제

예시 2: hermes-skill-factory로 스킬 자동 캡처 → Git 기여

bash

# hermes-skill-factory 플러그인 설치
hermes plugins install hermes-skill-factory
 
# 플러그인이 감시할 Tap 저장소 경로 설정
hermes config set skill-factory.tap-repo my-org/hermes-skills
hermes config set skill-factory.auto-pr true

이후 에이전트가 5회 이상 도구 호출이 이어지는 복잡한 작업을 완료하면, 플러그인이 자동으로 다음 흐름을 처리합니다:

작업 완료
  → SKILL.md 자동 생성 (~/.hermes/skills/...)
  → Tap 저장소에 feature/skill-<name> 브랜치 생성
  → SKILL.md 커밋 & 푸시
  → PR 자동 오픈 (리뷰어 지정 가능)

고급 확장 — 이미 운영 중인 팀의 다음 단계

예시 3: Git Worktree를 활용한 멀티 인스턴스 병렬 실행

bash

# 메인 저장소 클론
git clone https://github.com/my-org/project.git
cd project
 
# 각 에이전트 인스턴스를 위한 별도 Worktree 생성
git worktree add ../agent-feature-a feature/a
git worktree add ../agent-feature-b feature/b
 
# 인스턴스 A 실행 (별도 터미널)
# hermes start: 현재 디렉터리를 컨텍스트로 Hermes 에이전트를 인터랙티브 세션으로 시작합니다
# 작업 지시를 직접 입력하거나 스크립트로 자동화할 수 있습니다
cd ../agent-feature-a && hermes start
 
# 인스턴스 B 실행 (또 다른 터미널)
cd ../agent-feature-b && hermes start
 
# 두 인스턴스 모두 ~/.hermes/skills/ 경로는 동일하게 공유됩니다
# Tap 동기화 한 번으로 모든 인스턴스에 스킬이 적용됩니다
hermes skills sync  # 어느 경로에서 실행해도 공유됩니다

Git Worktree 하나의 Git 저장소에서 여러 브랜치를 동시에 다른 디렉터리로 체크아웃할 수 있는 기능입니다. 인스턴스마다 저장소를 통째로 복제하는 것보다 디스크 공간을 절약하면서도 각 작업 환경을 격리할 수 있습니다.

예시 4: FluxCD 방식의 서명된 스킬 배포

bash

# Flux Operator CLI가 서명 검증 후 스킬 추출
flux agent-skills pull \
  --source ghcr.io/fluxcd/agent-skills:latest \
  --verify-signature \
  --output .agents/skills/
 
# 추출된 스킬 구조
# .agents/skills/
# ├── gitops-knowledge/SKILL.md
# ├── gitops-repo-audit/SKILL.md
# └── gitops-cluster-debug/SKILL.md

OCI 아티팩트 & cosign 컨테이너 이미지 레지스트리(ghcr.io 등)에 파일을 패키징해 배포하는 방식입니다. cosign은 이 아티팩트에 디지털 서명을 붙여 변조 여부를 검증하는 오픈소스 도구입니다. 서명 없는 스킬은 에이전트가 아예 실행을 거부하므로 출처와 무결성을 엄격히 통제해야 하는 환경에 적합합니다. DevOps 경험이 없다면 진입 장벽이 있는 방식이어서, 앞의 GitHub 기반 Tap 구성에 먼저 익숙해진 다음 검토해보시면 좋습니다.

장단점 분석

장점

항목	내용
버전 관리 내재화	스킬 변경 이력, 롤백, 감사 추적이 git log 하나로 해결됩니다
온보딩 시간 단축	신규 팀원/인스턴스가 `tap add` + `skills sync` 두 명령으로 전체 스킬 베이스를 동기화할 수 있습니다
CI/CD 통합	스킬 품질 검증, 자동 배포, 실패 시 롤백을 기존 파이프라인에 그대로 얹을 수 있습니다
이기종 에이전트 지원	SKILL.md가 Claude Code, Codex, Hermes에서 공통으로 인식되어 플랫폼 간 지식 공유가 가능합니다
셀프-이볼빙 루프	에이전트가 실제 사용 중 스킬을 개선하고 PR로 기여하는 지속 개선 사이클이 자연스럽게 형성됩니다

단점 및 주의사항

항목	내용	대응 방안
리뷰 피로	에이전트 생성 PR이 대량 유입되면 인간 리뷰어 부담이 급증합니다	CI에 SKILL.md 포맷 검증, 민감 정보 스캐닝, 중복 감지 같은 품질 게이트를 구성해두면 리뷰어가 내용에만 집중할 수 있어서 훨씬 수월했습니다
인증 관리	프라이빗 Tap은 `GITHUB_TOKEN`이 필요하고, 이 토큰이 스킬 파일에 노출될 위험이 있습니다	CI에 secrets 스캐닝을 추가하고, SKILL.md에 자격증명이 포함되지 않도록 pre-commit 훅을 붙여두는 게 안전합니다. `detect-secrets` 플러그인과 함께 쓰면 커밋 직전에 자동으로 잡아줍니다
스킬 중복/충돌	여러 인스턴스가 독립적으로 스킬을 생성하면 유사한 스킬이 중복 누적됩니다	SkillClaw 같은 중복 제거 도구를 활용하거나, 팀 공용 명명 규칙(카테고리/스킬명 컨벤션)을 사전에 정의해두는 게 훨씬 효과적입니다
포맷 파편화	플랫폼별로 SKILL.md frontmatter 필드가 미묘하게 다릅니다	저장소 루트에 `SKILL_TEMPLATE.md`를 두고, 신규 스킬 생성 시 이를 기반으로 작성하도록 가이드해두면 나중에 일괄 파싱이나 검색이 훨씬 수월합니다
셀프-이볼빙 오염	품질 지표를 왜곡하는 방향으로 스킬이 자동 수정될 수 있습니다	자동 패치 범위를 명시적으로 제한하고 PR 경유 없이 main에 직접 커밋하지 않도록 브랜치 보호 규칙을 설정해두는 게 이 문제를 막는 가장 확실한 방법이었습니다

품질 게이트(Guardrail) CI 파이프라인에서 스킬 PR이 머지되기 전에 자동으로 검증하는 단계입니다. SKILL.md 포맷 유효성 검사, 민감 정보 스캐닝, 중복 스킬 감지 등을 포함시킬 수 있습니다.

실무에서 가장 흔한 실수

스킬 저장소를 public으로 열어두는 것 — 스킬에는 내부 시스템 구조, 도구 이름, 프로세스 절차가 상세히 담기기 때문에 민감 정보가 되는 경우가 많습니다. 프라이빗으로 시작해서 공개 범위를 신중하게 검토하는 것이 좋습니다.
셀프-이볼빙을 무제한으로 허용하는 것 — 에이전트가 스킬을 자동 패치할 수 있다는 건 편리하지만, PR 없이 main 브랜치에 직접 커밋하도록 설정하면 스킬이 어느 순간 알 수 없는 방향으로 변질될 수 있습니다. 자동 패치도 PR 경유가 이 문제를 막는 제일 확실한 방법이었습니다.
팀 공용 SKILL.md 템플릿 없이 시작하는 것 — 에이전트마다 frontmatter 필드를 다르게 생성하면 나중에 일괄 파싱이나 검색이 어려워집니다. 저장소 초기에 SKILL_TEMPLATE.md를 만들어두고 컨벤션을 고정해두는 시간이 결코 낭비가 아닙니다.

마치며

지금 바로 시작해볼 수 있는 3단계:

Tap 저장소 한 개 만들어보기 — GitHub에 <org>/hermes-skills 프라이빗 저장소를 만들고 skills/ 디렉터리를 초기화한 뒤, 로컬의 ~/.hermes/skills/ 중 가장 자주 쓰는 스킬 하나를 skills/<name>/SKILL.md로 복사해서 커밋해 보시면 됩니다.
팀원 한 명과 Tap 공유 테스트 — hermes skills tap add <org>/hermes-skills && hermes skills sync 명령으로 동기화가 잘 되는지 확인하고, 동료 인스턴스에서 공유한 스킬이 실제로 작동하는지 간단한 작업으로 검증해 보시면 좋습니다.
스킬 PR 워크플로 설정 — hermes-skill-factory를 설치하고 auto-pr: true 옵션을 켠 다음, 에이전트가 생성한 첫 번째 자동 PR을 리뷰하면서 품질 게이트 기준을 잡아보시면 됩니다. 첫 PR의 품질을 보면 어떤 검증이 필요한지 감이 바로 옵니다.

이 블로그의 시리즈 태그를 팔로우해 두시면 이어지는 내용을 놓치지 않고 확인해보실 수 있습니다.

참고 자료

#HermesAgent#GitOps#SKILL.md#멀티에이전트#GitWorktree#FluxCD#OCI아티팩트#AI에이전트#지식공유#CI-CD

핵심 개념

SKILL.md가 생성되는 시점과 구조

Tap 시스템: Git 저장소를 스킬 레지스트리로

Profile Distribution: 스킬을 넘어 팀 설정 전체를 패키징

실전 적용

기본 구성 — 처음 시작하는 팀

예시 1: 팀 Tap 저장소 초기 구성

예시 2: hermes-skill-factory로 스킬 자동 캡처 → Git 기여

고급 확장 — 이미 운영 중인 팀의 다음 단계

예시 3: Git Worktree를 활용한 멀티 인스턴스 병렬 실행

예시 4: FluxCD 방식의 서명된 스킬 배포

장단점 분석

장점

단점 및 주의사항

실무에서 가장 흔한 실수

마치며

참고 자료

핵심 개념

SKILL.md가 생성되는 시점과 구조

Tap 시스템: Git 저장소를 스킬 레지스트리로

Profile Distribution: 스킬을 넘어 팀 설정 전체를 패키징

실전 적용

기본 구성 — 처음 시작하는 팀

예시 1: 팀 Tap 저장소 초기 구성

예시 2: hermes-skill-factory로 스킬 자동 캡처 → Git 기여

고급 확장 — 이미 운영 중인 팀의 다음 단계

예시 3: Git Worktree를 활용한 멀티 인스턴스 병렬 실행

예시 4: FluxCD 방식의 서명된 스킬 배포

장단점 분석

장점

단점 및 주의사항

실무에서 가장 흔한 실수

마치며

참고 자료

추천 포스트

Ollama + Hermes로 로컬 LLM 인프라 구축하기 — API 비용 0원, 데이터 외부 유출 없음

OpenCode vs Claude Code: 터미널 AI 에이전트 비교와 팀 상황별 선택 기준

OpenCode로 구성하는 TypeScript LSP 자기수정 루프 — AI가 타입 에러를 스스로 잡는다

Hermes Agent로 배포 파이프라인 자동화하기

AI 에이전트 기반 CI/CD 자동화 — Hermes Agent Crons의 state.db 구조와 격리 실행 동작 원리

Hermes Agent SOUL.md와 5-Pillar 아키텍처 — Tier 3 스킬 자동 생성 메커니즘 내부 해부