Hermes Agent로 배포 파이프라인 자동화하기
git-ops, docker-build Skill 작성부터 Cron 스케줄링까지
Jenkins 파이프라인을 짜다가 YAML 지옥에 빠졌던 경험이 있으신가요? 저는 있습니다. 그것도 꽤 깊이. 스테이지마다 들여쓰기를 맞추고, 환경변수 참조 방식을 두 번 확인하고, 겨우 파이프라인이 돌아가면 다음 날 또 다른 설정이 어긋나는 식이었죠. 그때 "AI 에이전트가 이 파이프라인을 이해하고 스스로 실행해줄 수 있다면?"이라고 생각했었는데, 2026년에 그게 현실이 됐습니다. Hermes Agent는 NousResearch가 만든 오픈소스 자율 에이전트 프레임워크로, 단순히 명령을 받아 실행하는 것에서 그치지 않고 스스로 학습하며 같은 작업을 점점 더 잘해나가는 구조가 핵심입니다.
이 글에서는 git-ops, docker-build 같은 커스텀 Skill을 직접 작성하고, 이를 Cron 잡에 연결해 야간 빌드·배포 파이프라인을 무인 운영하는 전 과정을 다룹니다. 이 글을 끝까지 읽으면 오늘 밤부터 혼자 돌아가는 배포 파이프라인 하나를 손에 쥘 수 있습니다. DevOps 경험이 없어도 따라올 수 있도록, 처음 접하는 개념에는 간단한 설명을 함께 붙여두었습니다.
핵심 개념
시작하기 전에: 설치와 초기화
Hermes Agent는 pip로 설치할 수 있습니다.
pip install hermes-agent
# 초기화 — LLM API 키를 입력하는 인터랙티브 프롬프트가 뜹니다
hermes init
# 설치 확인
hermes --version # v0.14.0hermes init을 실행하면 어떤 LLM API(OpenAI, Anthropic, OpenRouter 등)를 쓸지 선택하고 키를 등록하게 됩니다. 한 번 설정해두면 이후 모든 명령에서 자동으로 사용됩니다.
Hermes는 최소 64K 토큰 컨텍스트를 지원하는 모델에서만 작동합니다. Claude Sonnet, GPT-4o처럼 대형 컨텍스트 모델을 쓰는 것을 권장합니다.
Skills 시스템의 구조
Skills는 에이전트의 기능을 확장하는 모듈 단위입니다. 파일 하나가 하나의 도구를 정의한다고 생각하면 됩니다. ~/.hermes/skills/<카테고리>/<스킬명>/ 디렉터리 아래에 SKILL.md 파일을 두는 형식으로 작성합니다.
~/.hermes/skills/
devops/
git-ops/
SKILL.md # 필수: 핵심 지시사항
scripts/ # 헬퍼 스크립트 (bash, python)
references/ # 참조 문서
templates/ # 출력 형식 템플릿
docker-build/
SKILL.md
scripts/
build.shSKILL.md는 두 부분으로 나뉩니다. 상단의 YAML 프론트매터에는 이름, 버전, 필요한 환경변수 같은 메타데이터가 들어가고, 본문 마크다운에는 에이전트가 따라야 할 절차와 검증 방법을 서술합니다.
agentskills.io 표준: Hermes가 채택한 사실상(de facto)의 오픈 표준입니다. NousResearch가 주도하고 Claude Code·Cursor 등이 동일한 규격을 채택하면서 자리를 잡았습니다. 이 규격에 맞게 작성된 Skill은 호환 플랫폼 간에 그대로 이식할 수 있어서, 한 번 작성한 Skill이 여러 에이전트 환경에서 재사용 가능한 "이식 가능한 에이전트 코드"가 됩니다.
본문에서 When to Use / Procedure / Verification 구조는 권장 포맷입니다. 반드시 이 세 섹션을 가져야 하는 건 아니지만, 이 구조를 따르는 Skill이 에이전트의 의도 파악 성공률이 훨씬 높다는 게 커뮤니티에서 검증된 패턴이라 웬만하면 따르는 게 좋습니다.
Cron 시스템의 작동 방식
Hermes의 게이트웨이 데몬이 스케줄러를 주기적으로 폴링하면서 예약된 작업을 격리된 에이전트 세션에서 실행하는 구조입니다. 각 크론 잡은 네 가지 요소로 구성됩니다.
| 구성 요소 | 역할 |
|---|---|
--prompt |
에이전트에게 전달할 작업 지시사항 |
--schedule |
표준 cron 표현식 또는 자연어 스케줄 |
--skill |
로드할 Skills 목록 (복수 지정 가능) |
--deliver |
결과 전달 채널 (Slack, 이메일 등) |
v0.10 이후로는 자연어 스케줄링도 가능합니다. "매일 밤 12시에 GitHub에 변경사항 push해줘" 같은 명령 한 줄로 Skill과 Cron 잡을 동시에 생성할 수 있어서, cron 표현식이 낯선 분들에게 특히 편리합니다.
context_from으로 잡 간 데이터 흐름 연결
저도 처음에 헷갈렸던 부분인데, context_from 파라미터를 쓰면 외부 오케스트레이터(Jenkins, GitHub Actions 등) 없이도 크론 잡 간 출력을 다음 잡의 컨텍스트로 연결할 수 있습니다. 이전 잡의 출력 텍스트가 그대로 다음 잡의 컨텍스트 창에 주입되는 방식입니다. 테스트 결과 텍스트를 다음 잡이 읽고 "통과했는지" 판단하는 식으로 동작합니다.
실전 적용
예시 1~4는 누적 의존 관계가 있습니다. git-ops(예시 1)와 docker-build(예시 2) Skill을 먼저 작성해야 이후 Cron 연결(예시 3)과 멀티스테이지 파이프라인(예시 4)을 구성할 수 있습니다.
예시 1: git-ops Skill 작성
가장 기본적인 DevOps Skill입니다. 야간 자동 커밋·푸시나 원격 저장소 백업에 쓸 수 있습니다. 솔직히 이 Skill 하나만 잘 만들어도 "매일 밤 내 코드베이스가 자동으로 저장된다"는 안도감이 생깁니다.
---
name: git-ops
description: Git 저장소 동기화, 커밋, 푸시 자동화
version: "1.2"
required_environment_variables:
- name: GITHUB_TOKEN
prompt: "GitHub Personal Access Token을 입력하세요"
required_for: [push]
---
## When to Use
원격 저장소 동기화, 야간 백업, 자동 커밋이 필요할 때.
## Procedure
1. `git status`로 변경사항 확인, 변경 없으면 종료
2. 변경 파일을 스테이징: `git add -A`
3. `git diff --staged --stat`로 변경 요약을 읽고
"auto: [변경된 파일 목록 요약]" 형식의 커밋 메시지를 생성 후 커밋
4. `GITHUB_TOKEN`을 사용해 원격 저장소에 push:
`git push https://$GITHUB_TOKEN@github.com/<owner>/<repo>.git`
## Verification
`git log -1`로 최신 커밋 확인, 원격 브랜치와 동기화 상태 점검required_environment_variables 필드가 중요한 이유가 있습니다. 환경변수로 시크릿을 분리하면 토큰이 SKILL.md 본문에 직접 노출되지 않습니다. SKILL.md가 Git에 올라가는 순간 토큰이 유출되는 사고를 막는 가장 기본적인 안전장치입니다.
GITHUB_TOKEN은 GitHub → Settings → Developer settings → Personal access tokens에서 발급받을 수 있습니다. repo 권한만 체크하면 충분합니다.
예시 2: docker-build Skill 작성
앞서 만든 git-ops에 이어, 빌드·태깅·레지스트리 푸시를 한 번에 처리하는 Skill입니다. 참고로 Docker 레지스트리는 빌드된 이미지를 저장하고 배포하는 저장소입니다(Docker Hub, AWS ECR 같은 서비스가 여기 해당합니다). 실무에서 자주 맞닥뜨리는 상황인데, 빌드가 실패했을 때 어디서 터졌는지 추적하기 어려운 경우가 많아서 references/build-errors.md에 실패 로그를 기록하도록 절차에 명시해두면 디버깅이 훨씬 수월해집니다.
---
name: docker-build
description: Docker 이미지 빌드, 태깅, 레지스트리 푸시 자동화
version: "1.0"
required_environment_variables:
- name: DOCKER_REGISTRY_TOKEN
prompt: "Docker 레지스트리 토큰을 입력하세요"
required_for: [push]
- name: IMAGE_TAG
prompt: "이미지 태그 (예: latest, v1.2.3)"
required_for: [build, push]
---
## When to Use
CI/CD 파이프라인의 빌드 단계, 스테이징 배포 전 이미지 생성 시.
## Procedure
1. `scripts/build.sh`를 실행해 이미지 빌드
2. 빌드 성공 시 `$DOCKER_REGISTRY_TOKEN`으로 인증 후 레지스트리에 push
3. 실패 시 오류 로그를 `references/build-errors.md`에 타임스탬프와 함께 기록
## Verification
`docker inspect <image>`로 이미지 레이어 확인헬퍼 스크립트는 scripts/ 디렉터리에 따로 두는 걸 권장합니다. SKILL.md 본문이 복잡해지는 걸 막고, 스크립트를 독립적으로 테스트할 수 있기 때문입니다. 최소한의 뼈대는 이렇게 잡을 수 있습니다.
#!/usr/bin/env bash
# scripts/build.sh
set -e
IMAGE_NAME="${IMAGE_NAME:-myapp}"
IMAGE_TAG="${IMAGE_TAG:-latest}"
REGISTRY="${REGISTRY:-registry.example.com}"
docker build -t "$REGISTRY/$IMAGE_NAME:$IMAGE_TAG" .
echo "Build succeeded: $REGISTRY/$IMAGE_NAME:$IMAGE_TAG"IMAGE_NAME, REGISTRY 같은 값은 환경에 맞게 수정해서 사용하면 됩니다.
예시 3: Cron 잡에 Skills 연결하기
두 Skill을 작성했다면, 이제 야간 크론 잡에 묶어볼 수 있습니다. CLI 명령 한 줄로 처리됩니다.
hermes cron add \
--schedule "0 2 * * *" \
--skill git-ops \
--skill docker-build \
--prompt "스테이징 브랜치를 빌드하고 레지스트리에 push한 뒤 배포 결과를 Slack으로 전송해줘" \
--deliver slack:#deploy-alerts0 2 * * *은 매일 새벽 2시를 의미합니다. --skill은 여러 번 지정할 수 있고, 지정된 Skills가 해당 크론 세션에 로드됩니다.
--deliver slack:#deploy-alerts 옵션을 쓰려면 사전에 Slack Webhook이 설정되어 있어야 합니다. hermes config slack-webhook https://hooks.slack.com/... 명령으로 먼저 등록해두면 이후 --deliver slack:#채널명 형태로 사용할 수 있습니다.
아침에 출근해서 Slack 채널에 쌓인 배포 결과를 확인하는 워크플로, 생각보다 꽤 인상적입니다. 처음 동작할 때 "진짜 된다고?" 싶은 순간이 있었습니다.
예시 4: context_from으로 멀티스테이지 파이프라인 구성
앞서 만든 Skill들에 더해, 별도로 작성한 run-tests와 deploy Skill이 있다면 테스트 → 빌드 → 배포로 이어지는 파이프라인을 외부 오케스트레이터 없이 Hermes 안에서 완성할 수 있습니다. 이 부분이 개인적으로 가장 흥미로웠던 지점입니다.
# Job 1: 테스트 실행 (매 시간 0분)
name: test-runner
schedule: "0 * * * *"
skill: run-tests
prompt: "테스트 스위트를 실행하고 결과 리포트를 텍스트로 생성해줘"
# Job 2: 테스트 통과 시 빌드 (매 시간 15분, test-runner 결과 참조)
name: docker-build-job
schedule: "15 * * * *"
skill: docker-build
context_from: ["test-runner"]
prompt: "테스트 리포트를 확인하고 통과된 경우에만 이미지를 빌드해줘"
# Job 3: 빌드 성공 시 스테이징 배포 (매 시간 30분, docker-build-job 결과 참조)
# 스테이징 서버: 프로덕션 배포 전 검증용 테스트 환경
name: deploy-staging
schedule: "30 * * * *"
skill: deploy # 별도로 작성한 deploy Skill이 필요합니다
context_from: ["docker-build-job"]
prompt: "빌드된 이미지 정보를 참조해 스테이징 서버에 배포해줘"
context_from: 이전 크론 잡의 출력 텍스트를 다음 잡의 컨텍스트 창에 그대로 주입해주는 파라미터입니다. 잡 A의 결과를 잡 B가 읽고 조건부 판단에 활용할 수 있어서, "테스트 통과 시에만 빌드" 같은 로직을 자연어 프롬프트로 표현할 수 있습니다.
위 예시에서 15분 간격을 선택한 건 각 잡(테스트, 빌드)이 15분 안에 완료된다는 가정 아래입니다. 프로젝트에 따라 빌드 시간이 더 길다면 간격을 넉넉하게 잡는 것을 권장합니다. 잡이 완료되기 전에 다음 잡이 시작되면 이전 실행의 오래된 컨텍스트를 읽게 되는 문제가 생깁니다.
장단점 분석
실무에서 가장 크게 체감했던 단점은 크론 프롬프트 오버헤드였습니다. 매 실행마다 프롬프트가 토큰을 소비하기 때문에, 처음에 "자주 실행하면 좋겠다"는 생각에 간격을 촘촘하게 잡았다가 월말 청구서를 받고 놀란 경험이 있습니다. 그 부분을 특히 주의해서 봐주시면 좋겠습니다.
장점
| 항목 | 내용 |
|---|---|
| 자기 학습 | 작업 성공 시 자동으로 SKILL.md를 생성·개선, 시간이 지날수록 같은 작업을 더 효율적으로 처리 |
| 이식성 | agentskills.io 표준 준수로 Claude Code, Cursor 등과 Skill 공유 가능 |
| 멀티백엔드 | Local, Docker, SSH, Modal, Vercel Sandbox 등 7종 실행 환경 지원 |
| 보안 | required_environment_variables로 시크릿을 모델 트랜스크립트에 노출하지 않음 |
| 모델 유연성 | OpenAI, Nous Portal, OpenRouter 등 어떤 LLM API든 교체 가능 |
| 비용 | 프레임워크 자체는 MIT 무료, VPS + 예산 모델 기준 월 $20~50 수준 |
단점 및 주의사항
| 항목 | 내용 | 대응 방안 |
|---|---|---|
| 최소 컨텍스트 요구 | 64K 토큰 미만 모델은 실행 자체가 거부됨 | Claude Sonnet, GPT-4o 등 64K+ 모델 사용 |
| 크론 프롬프트 오버헤드 | 매 실행마다 프롬프트가 토큰 소비, 고빈도 스케줄 시 비용 누적 | 스케줄 간격을 넉넉하게 잡고, 프롬프트를 간결하게 유지 |
| 스냅샷 지연 | Skills Hub 큐레이터가 주기적으로 동작해 최신 Skill 반영에 시차 발생 | 직접 작성한 로컬 Skill은 즉시 반영되므로 커스텀 개발로 해결 |
| 메모리 한계 | 매우 긴 작업 이력은 압축·손실될 수 있음 (LightRAG 레이어에서 발생) | 중요 결과는 Git 커밋이나 외부 스토리지에 별도 저장 |
| 생태계 규모 | Skills Hub에 약 118개로 타 플랫폼 대비 작음 | awesome-hermes-agent 커뮤니티 목록 참조, 직접 기여 가능 |
LightRAG: Hermes의 기본 메모리·지식 그래프 백엔드입니다. 에이전트가 이전 작업 결과를 기억하고 검색할 수 있게 해주는 컴포넌트로, 메모리 한계가 발생하면 이 레이어에서 압축이 일어납니다.
실무에서 가장 흔한 실수
-
SKILL.md본문에 시크릿을 직접 작성하는 경우 — 토큰, 패스워드는 반드시required_environment_variables로 분리해야 합니다. 마크다운 파일이 버전 관리에 올라가는 순간 토큰이 유출됩니다. -
Procedure섹션을 너무 모호하게 작성하는 경우 — "배포해줘"처럼 추상적으로 쓰면 에이전트가 상황마다 다르게 해석합니다. 단계별로 구체적인 명령어와 판단 기준을 명시하는 것이 훨씬 안정적입니다. -
context_from파이프라인에서 실행 시간을 겹치게 설정하는 경우 — Job 1이 완료되기 전에 Job 2가 시작되면 이전 실행의 오래된 컨텍스트를 읽게 됩니다. 잡 간 간격을 충분히 두는 것을 권장합니다.
마치며
Hermes Agent의 Skills와 Cron 시스템을 조합하면, 한 번 설계해둔 DevOps 파이프라인이 이후에는 스스로 학습하며 더 효율적으로 돌아가는 구조를 만들 수 있습니다.
지금 바로 시작해볼 수 있는 3단계:
-
~/.hermes/skills/devops/git-ops/SKILL.md를 만들고, 예시 코드를 복사해 저장소 경로와 브랜치명에 맞게 수정해보세요.GITHUB_TOKEN은 GitHub Settings → Developer settings → Personal access tokens에서 발급받을 수 있습니다. -
hermes cron add --schedule "0 2 * * *" --skill git-ops --prompt "변경사항을 커밋하고 원격 저장소에 push해줘"명령으로 첫 번째 야간 크론 잡을 등록해보세요. 다음 날 아침에git log로 자동 커밋이 쌓인 걸 확인하면 생각보다 뿌듯합니다. -
docker-buildSkill을 추가로 작성한 뒤context_from으로 두 잡을 연결해보세요. 테스트 통과 여부에 따라 빌드 여부를 스스로 판단하는 멀티스테이지 파이프라인을 경험해볼 수 있습니다.