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.0

hermes 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.sh

SKILL.md는 두 부분으로 나뉩니다. 상단의 YAML 프론트매터에는 이름, 버전, 필요한 환경변수 같은 메타데이터가 들어가고, 본문 마크다운에는 에이전트가 따라야 할 절차와 검증 방법을 서술합니다.

agentskills.io 표준: Hermes가 채택한 사실상(de facto)의 오픈 표준입니다. NousResearch가 주도하고 Claude Code·Cursor 등이 동일한 규격을 채택하면서 자리를 잡았습니다. 이 규격에 맞게 작성된 Skill은 호환 플랫폼 간에 그대로 이식할 수 있어서, 한 번 작성한 Skill이 여러 에이전트 환경에서 재사용 가능한 "이식 가능한 에이전트 코드"가 됩니다.

본문에서 When to Use / Procedure / Verification 구조는 권장 포맷입니다. 반드시 이 세 섹션을 가져야 하는 건 아니지만, 이 구조를 따르는 Skill이 에이전트의 의도 파악 성공률이 훨씬 높다는 게 커뮤니티에서 검증된 패턴이라 웬만하면 따르는 게 좋습니다.

Cron 시스템의 작동 방식

Hermes의 게이트웨이 데몬이 스케줄러를 주기적으로 폴링하면서 예약된 작업을 격리된 에이전트 세션에서 실행하는 구조입니다. 각 크론 잡은 네 가지 요소로 구성됩니다.

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-alerts

0 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분 안에 완료된다는 가정 아래입니다. 프로젝트에 따라 빌드 시간이 더 길다면 간격을 넉넉하게 잡는 것을 권장합니다. 잡이 완료되기 전에 다음 잡이 시작되면 이전 실행의 오래된 컨텍스트를 읽게 되는 문제가 생깁니다.

장단점 분석

실무에서 가장 크게 체감했던 단점은 크론 프롬프트 오버헤드였습니다. 매 실행마다 프롬프트가 토큰을 소비하기 때문에, 처음에 "자주 실행하면 좋겠다"는 생각에 간격을 촘촘하게 잡았다가 월말 청구서를 받고 놀란 경험이 있습니다. 그 부분을 특히 주의해서 봐주시면 좋겠습니다.

장점

단점 및 주의사항

LightRAG: Hermes의 기본 메모리·지식 그래프 백엔드입니다. 에이전트가 이전 작업 결과를 기억하고 검색할 수 있게 해주는 컴포넌트로, 메모리 한계가 발생하면 이 레이어에서 압축이 일어납니다.

실무에서 가장 흔한 실수

1. SKILL.md 본문에 시크릿을 직접 작성하는 경우 — 토큰, 패스워드는 반드시 required_environment_variables로 분리해야 합니다. 마크다운 파일이 버전 관리에 올라가는 순간 토큰이 유출됩니다.

2. Procedure 섹션을 너무 모호하게 작성하는 경우 — "배포해줘"처럼 추상적으로 쓰면 에이전트가 상황마다 다르게 해석합니다. 단계별로 구체적인 명령어와 판단 기준을 명시하는 것이 훨씬 안정적입니다.

3. context_from 파이프라인에서 실행 시간을 겹치게 설정하는 경우 — Job 1이 완료되기 전에 Job 2가 시작되면 이전 실행의 오래된 컨텍스트를 읽게 됩니다. 잡 간 간격을 충분히 두는 것을 권장합니다.

마치며

Hermes Agent의 Skills와 Cron 시스템을 조합하면, 한 번 설계해둔 DevOps 파이프라인이 이후에는 스스로 학습하며 더 효율적으로 돌아가는 구조를 만들 수 있습니다.

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

1. ~/.hermes/skills/devops/git-ops/SKILL.md를 만들고, 예시 코드를 복사해 저장소 경로와 브랜치명에 맞게 수정해보세요. GITHUB_TOKEN은 GitHub Settings → Developer settings → Personal access tokens에서 발급받을 수 있습니다.

2. hermes cron add --schedule "0 2 * * *" --skill git-ops --prompt "변경사항을 커밋하고 원격 저장소에 push해줘" 명령으로 첫 번째 야간 크론 잡을 등록해보세요. 다음 날 아침에 git log로 자동 커밋이 쌓인 걸 확인하면 생각보다 뿌듯합니다.

3. docker-build Skill을 추가로 작성한 뒤 context_from으로 두 잡을 연결해보세요. 테스트 통과 여부에 따라 빌드 여부를 스스로 판단하는 멀티스테이지 파이프라인을 경험해볼 수 있습니다.

참고 자료

• Creating Skills | Hermes Agent
• Scheduled Tasks (Cron) | Hermes Agent
• GitHub - NousResearch/hermes-agent
• GitHub - 0xNyk/awesome-hermes-agent
• Hermes Agent Skill Authoring — SKILL.md Structure and Best Practices | Medium
• How to Build a Cron-Based AI Automation with Hermes Agent | MindStudio