헤르메스 에이전트 자동화 워크플로우: 크론·서브에이전트·CI/CD 실전 [4편]

작성자:

TL;DR

  • 헤르메스의 자연어 크론 스케줄링으로 정기 리포트, 백업, 모니터링 알림을 코드 없이 자동화할 수 있다.
  • 서브에이전트 아키텍처를 활용하면 독립적인 작업을 병렬 실행해 대기 시간을 줄인다.
  • GitHub Actions·Jenkins 등 CI/CD 파이프라인에 헤르메스를 Slack 명령어로 트리거하면 배포 후 자동 검증 루프를 구성할 수 있다.

시리즈 목차

편 주제
1편 소개 — 무엇이 다른가
2편 설치 가이드
3편 스킬 시스템 완전 분해
4편 자동화 워크플로우 실전 (현재 글)
5편 실무 도입 결론

자연어 크론 스케줄링

헤르메스의 크론 설정은 crontab 문법이 아니다. 자연어로 작성한다.

# ~/.hermes/schedules.yml
schedules:
  - name: daily-error-report
    trigger: "매일 오전 9시"
    task: |
      지난 24시간 로그에서 ERROR 레벨 항목을 집계하고,
      가장 많이 발생한 상위 5개 에러와 스택 트레이스 요약을
      #ops-alert Slack 채널에 발송해줘
    
  - name: weekly-pr-summary
    trigger: "매주 금요일 오후 5시"
    task: |
      이번 주 머지된 PR 목록을 GitHub API로 가져와서
      변경 파일 수, 리뷰어, 주요 변경 내용을 요약해
      #dev-weekly 채널에 정리해줘
  - name: deploy-health-check
    trigger: "배포 완료 10분 후"     # 이벤트 기반 트리거
    task: |
      프로덕션 엔드포인트 /health 와 /api/v2/status를 확인하고
      p99 레이턴시가 200ms 초과 시 즉시 알림 발송

자연어로 스케줄을 정의하면 헤르메스가 내부적으로 cron expression으로 변환해 실행한다. 스케줄 수정도 자연어로 한다. “daily-error-report를 오전 8시로 앞당겨줘”라고 요청하면 된다.

서브에이전트 병렬 실행

헤르메스는 독립적인 작업을 서브에이전트로 분리해 병렬 처리한다. Docker나 SSH 백엔드를 사용하면 각 서브에이전트가 완전히 격리된 환경에서 실행된다.

# 사용자 요청
"우리 서비스의 API 성능 분석 보고서를 만들어줘.
 DB 쿼리 성능, 캐시 히트율, 외부 API 의존성을 각각 분석해서
 종합 리포트를 작성해줘"
# 헤르메스 내부 분해
메인 에이전트
├── 서브에이전트 A: DB 쿼리 성능 분석 (Prometheus 쿼리)
├── 서브에이전트 B: Redis 캐시 히트율 분석 (Redis INFO)
└── 서브에이전트 C: 외부 API 레이턴시 측정 (HTTP 프로브)
                 ↓ 병렬 실행
메인 에이전트: 세 결과 취합 → 종합 리포트 생성

서브에이전트 각각이 독립 터미널과 Python RPC 환경을 가지므로, A가 실패해도 B와 C는 계속 실행된다.

실전 패턴: 배포 후 자동 검증

CI/CD 파이프라인과 연동하는 패턴이다. GitHub Actions에서 배포 완료 후 Slack으로 헤르메스를 트리거한다.

# .github/workflows/deploy.yml

  • name: Notify Hermes for post-deploy verification
    • 

  if: success()
  run: |
    curl -X POST "$SLACK_WEBHOOK_URL" \
      -H "Content-Type: application/json" \
      -d '{
        "text": "@hermes 프로덕션 배포 완료됐어. v2.4.1 배포됨. 엔드포인트 헬스체크하고 에러율 기준 확인해줘"
      }'

헤르메스가 Slack 메시지를 받으면 자동으로 검증 작업을 시작하고, 결과를 같은 채널에 보고한다.

헤르메스 응답 (Slack):
✅ 배포 검증 완료 — v2.4.1
/health: 200 OK (응답 48ms)
/api/v2/status: 200 OK (응답 61ms)
에러율: 0.02% (임계값 0.1% 이내)
p99 레이턴시: 124ms (임계값 200ms 이내)
이전 버전 대비 p99 +12ms 증가. 정상 범위 내.

실전 패턴: 신규 팀원 온보딩 자동화

팀에서 헤르메스를 온보딩 도우미로 쓰는 패턴이다.

# 신규 팀원 Slack 메시지
@hermes 오늘 첫날인데, 개발 환경 세팅 도와줘
# 헤르메스 응답
안녕하세요. 온보딩 스킬을 로드했습니다.
다음 순서로 진행합니다:
1. Git 저장소 클론 및 브랜치 전략 설명
2. 로컬 DB 세팅 (팀 표준: PostgreSQL 15 + Docker)
3. 환경 변수 파일 (.env.local) 생성 안내
4. 첫 PR 생성 가이드
어느 단계부터 시작할까요?

온보딩 스킬이 축적될수록 팀 컨벤션과 내부 시스템 정보가 담긴 정교한 가이드를 제공한다.

실전 패턴: Grafana 알림 해석 자동화

모니터링 알림이 발생했을 때 헤르메스가 1차 분석을 수행하는 패턴이다.

# Grafana Alert 설정
contact_points:
  - name: hermes-alert
    type: webhook
    settings:
      url: "http://hermes-server:8080/webhook"
      
# 헤르메스 웹훅 수신 후 자동 수행:
# 1. 알림 메트릭 조회 (Prometheus API)
# 2. 최근 배포 이력 확인 (GitHub API)
# 3. 관련 스킬 파일 로드 (과거 동일 알림 대응 사례)
# 4. 초기 분석 + 대응 방안 Slack 발송

온콜 엔지니어가 알림을 받았을 때 이미 헤르메스의 초기 분석이 Slack에 올라와 있으면, 조사 시간을 크게 줄일 수 있다.

주의사항

샌드박싱 설정 확인. 서브에이전트가 실제 서버에서 코드를 실행한다면 Docker 격리를 반드시 적용한다. 기본 로컬 백엔드는 호스트 환경에 직접 접근한다.

크론 작업 중복 실행 방지. 헤르메스가 여러 인스턴스로 실행될 경우 같은 스케줄이 중복 실행될 수 있다. 분산 환경에서는 Redis 기반 분산 락을 적용한다.

API 키 노출 주의. Slack 메시지로 작업을 지시할 때 API 키나 비밀번호를 직접 입력하지 않는다. 헤르메스 config의 환경 변수 참조 방식을 사용한다.

다음 편 예고

마지막 5편에서는 실무 도입 결론을 다룬다.

  • 헤르메스를 쓰기 좋은 팀과 상황
  • 쓰지 말아야 할 상황 (규제, 보안, 감사)
  • OpenClaw·Cursor Agent·Claude Code와의 포지셔닝
  • 팀 도입 로드맵 제안

참고 자료

댓글 남기기