14. 실전 활용 시나리오로 익히는 Hermes 워크플로

기능을 아는 것과 운영하는 것은 다르다

앞선 장들에서 우리는 Hermes Agent의 기능을 하나씩 배웠다. 설치하고, 모델을 고르고, CLI를 쓰고, 도구를 연결하고, 메모리와 스킬, 게이트웨이, 자동화까지 살펴봤다. 이제 남은 질문은 하나다. "그래서 이걸 내 일에 어떻게 붙이지?"

여기서부터가 진짜 시작이다. Hermes는 단순히 질문에 답하는 도구가 아니라, 기억하고, 반복 업무를 익히고, 여러 플랫폼에서 같은 맥락으로 움직이며, 예약 실행과 이벤트 기반 반응까지 처리하는 장기 실행형 에이전트다.¹ 그래서 Hermes를 잘 쓰는 사람은 기능 목록을 외우는 사람이 아니라, 자신의 일을 입력 → 판단 → 실행 → 전달 → 축적 흐름으로 설계하는 사람이다.

실전에서는 특히 세 가지 트리거를 먼저 생각하면 편하다. 정해진 시간에 도는 스케줄형, GitHub나 외부 시스템 이벤트에 반응하는 웹훅형, 다른 서비스가 JSON을 보내면 바로 움직이는 API 호출형이다. Hermes는 이 세 가지를 모두 다루고, 결과를 Telegram, Slack, Discord, GitHub 댓글, 이메일, 로컬 파일 같은 여러 채널로 보낼 수 있다.²

즉, 좋은 Hermes 워크플로는 대개 이런 질문에서 출발한다.

• 무엇이 일을 시작하게 만드는가?

• Hermes는 무엇을 읽고 무엇을 판단해야 하는가?

• 결과는 누구에게, 어떤 톤으로, 어디로 전달되어야 하는가?

• 다음 번에 더 빨라지도록 무엇을 기억하게 할 것인가?

이 장에서는 대표적인 다섯 가지 패턴으로 이 질문에 답해 보겠다.

개인 비서형 Hermes: 나 대신 챙기고, 내가 놓친 걸 메운다

Hermes를 가장 먼저 체감하기 쉬운 방식은 "똑똑한 개인 비서"로 운영하는 것이다. 이때 중요한 것은 기능을 많이 붙이는 것이 아니라, 내가 자주 들어오는 채널 하나를 본진으로 삼는 것이다. 보통은 Telegram DM이나 Slack 개인 채널이 가장 편하다. 책상 앞에서는 CLI로 깊게 작업하고, 이동 중에는 메시징으로 이어받는 식이다. Hermes의 강점은 바로 이 플랫폼 간 연속성에 있다.¹

개인 비서형 운영에서는 Hermes가 세 가지 역할을 맡는다. 첫째는 정리자다. 아침 브리핑, 오늘 할 일, 최근 대화 요약, 미뤄 둔 할 일 정리 같은 일을 맡긴다. 둘째는 기억 보조 장치다. 내가 자주 쓰는 표현, 자주 보는 프로젝트, 선호하는 출력 형식을 계속 쌓아 둔다. 셋째는 작은 심부름꾼이다. 웹 검색으로 정보 확인, 파일 정리, 간단한 명령 실행, 반복 체크를 대신한다.

예를 들어 이런 흐름이 잘 맞는다.

• 매일 오전 8시에 오늘 일정, 어제 미완료 항목, 중요한 메시지 요약을 보내기

• "이번 주에 내가 반복해서 물어본 주제"를 금요일 저녁에 정리해 주기

• 내가 남긴 음성 메모나 짧은 아이디어를 나중에 찾기 좋은 형태로 정리해 두기

개인 비서형에서 핵심은 모든 걸 시키지 말고, 자주 놓치는 것만 맡기는 것이다. 예를 들어 아침 브리핑은 사람이 직접 검색하는 것보다 Hermes가 더 낫고, 아주 민감한 최종 의사결정은 여전히 사람이 하는 편이 낫다. 이 선을 잘 그어야 비서가 되고, 선을 못 그으면 시끄러운 봇이 된다.

처음 시작할 때는 이런 식의 요청이 좋다.

매일 아침 8시에 오늘 일정, 어제 끝내지 못한 일, 읽어야 할 중요 링크 3개만 간단히 요약해서 보내줘. 없으면 억지로 채우지 말고 조용히 있어.

여기서 마지막 문장이 중요하다. Hermes 워크플로는 "항상 무언가 말하라"보다 "변화가 있을 때만 알려라"가 훨씬 실용적이다. 알림이 적을수록, 중요한 알림이 더 잘 보인다.

또 하나의 팁은 모델 전략이다. 개인 비서형은 늘 최고 성능 모델이 필요한 게 아니다. 일상 정리, 분류, 초안 생성은 빠르고 저렴한 모델로 돌리고, 여행 계획이나 중요한 문서 초안처럼 생각이 많이 필요한 순간에만 상위 모델로 바꾸는 편이 효율적이다. Hermes는 이런 모델 전환 구조와 잘 어울린다.¹

개발 자동화형 Hermes: 코딩 도우미가 아니라 개발 흐름 관리자

개발자가 Hermes를 쓸 때 가장 흔한 실수는 "코드도 쓰고, 리서치도 하고, 서버도 보고, 개인 일정도 관리하는 만능 에이전트 하나"를 만들려는 것이다. 보기에는 멋있지만, 실제로는 맥락이 자꾸 섞인다. 개발 워크플로에서는 보통 프로젝트별 Hermes가 더 잘 맞는다.

예를 들어 블로그 프로젝트용, 서비스 백엔드용, 문서 전용 에이전트를 나누면 각 에이전트가 기억해야 할 디렉터리 구조, 빌드 명령, 리뷰 기준, 배포 방식이 명확해진다. 그러면 Hermes가 "이 프로젝트에서는 수정 전에 기존 파일을 먼저 읽고, Tailwind class는 재사용하고, 마지막에는 빌드 확인을 한다" 같은 습관을 더 잘 익힌다.

개발 자동화에서 효과가 큰 패턴은 네 가지다.

• PR 코드 리뷰 자동화

• 이슈/백로그 정리

• 문서 드리프트 탐지

• 의존성 보안 점검

공식 자동화 템플릿에도 비슷한 예시가 잘 정리되어 있다. GitHub 웹훅으로 PR이 열릴 때마다 diff를 읽고 보안, 성능, 코드 품질, 테스트 누락을 짧게 점검하게 하거나, 밤마다 새 이슈를 분류해서 팀 채널로 보내게 하거나, 최근 머지된 PR을 보고 코드 변경은 있었는데 문서가 안 바뀐 부분을 찾게 할 수 있다.²

이 흐름에서 Hermes는 "대신 코딩해 주는 존재"보다 "개발 리듬을 자동으로 유지해 주는 존재"에 가깝다. 예를 들어 리뷰를 시킬 때 단순히 "리뷰해 줘"라고 하면 사소한 취향 지적이 늘어난다. 대신 이렇게 좁혀 주면 훨씬 좋아진다.

src/auth/ 아래 변경만 검토해 줘. 인증 우회 가능성, 예외 처리 누락, 테스트 빠진 부분만 봐. 네이밍 취향은 무시해.

또 복잡한 작업에서는 멀티 에이전트가 쓸 만하다. 메인 에이전트가 큰 목표를 잡고, 서브에이전트가 조사나 검증을 병렬로 맡는 방식이다. 예를 들어 한 에이전트는 구현안을 만들고, 다른 에이전트는 검증만 맡길 수 있다. 다만 서브에이전트는 각각 별도의 대화와 비용을 쓰므로, "진짜 병렬로 나눌 가치가 있는가"를 따져야 한다.³

개발 자동화형 Hermes를 설계할 때는 다음 순서가 안정적이다.

1. 프로젝트별 작업공간과 기본 규칙을 먼저 정한다.

2. 읽기 위주의 자동화부터 붙인다. 예를 들면 리뷰, 문서 비교, 이슈 요약이 좋다.

3. 그다음에 제한된 쓰기 작업을 붙인다. 예를 들면 changelog 초안 작성이나 PR 댓글 게시 정도다.

4. 마지막에만 위험 작업을 고려한다. 자동 커밋, 배포 트리거, 운영 브랜치 수정은 검토 후에 붙여도 늦지 않다.

한마디로 요약하면, 개발에서 Hermes는 "코드 생성기"보다 "개발 운영 비서"로 둘 때 오래 간다.

리서치 요약형 Hermes: 많이 읽는 것이 아니라, 엮어서 이해한다

리서치 업무에서 Hermes의 진짜 가치는 자료를 많이 모으는 데 있지 않다. 서로 다른 출처를 엮어 읽는 데 있다. 기사 열 개를 각각 3줄 요약하는 것은 누구나 할 수 있다. 하지만 서로 충돌하는 주장, 빠진 맥락, 공통 패턴을 뽑아내는 일은 워크플로 설계가 좋아야 가능하다.

이때 리서치형 Hermes는 대개 다음과 같이 움직인다. 먼저 웹 검색이나 문서 읽기로 자료를 모은다. 다음으로 자료를 유형별로 정리한다. 그다음 핵심 주장, 숫자, 날짜, 제한 사항을 뽑아 서로 비교한다. 마지막으로 "무엇이 합의되고, 무엇이 충돌하며, 무엇이 비어 있는가"를 요약한다.

문서가 아주 길거나 소스 수가 많다면 긴 컨텍스트 모델이 유리하다. 예를 들어 Gemini 2.5 Pro는 1M 토큰 컨텍스트를 앞세워 대형 문서 묶음, 긴 회의록, 큰 코드베이스, 다수의 자료 종합 작업에 적합한 선택지로 자주 언급된다.⁴ 반대로 민감한 자료이거나 토큰 비용을 줄이고 싶다면 로컬 모델 조합이 잘 맞는다. Gemma 4는 구조화된 출력과 범용 작업에서 안정적이고, Qwen 3.5는 코딩과 긴 문맥 추론, 한국어·중국어·일본어 처리에서 강점을 보인다.⁵

그래서 리서치형 Hermes는 모델 선택까지 포함해 설계해야 한다. 예를 들면 이렇다.

• 내부 문서와 민감 자료 요약: 로컬 모델

• 대량 공개 자료 종합: 긴 컨텍스트 클라우드 모델

• 빠른 초벌 분류: 저비용 고속 모델

• 최종 보고서 초안: 상위 모델

이 패턴은 특히 다음 같은 업무에서 강하다.

• 경쟁사 기능 변화 추적

• 논문, 기사, 릴리스 노트 묶음 요약

• 긴 회의록에서 쟁점과 결정 사항 추출

• 시장 조사 자료를 읽고 공통 결론과 반론 정리

중요한 건 프롬프트도 "각 자료를 요약하라"보다 "자료 사이 관계를 밝혀라"에 맞춰야 한다는 점이다. 예를 들어 이렇게 요청하면 좋다.

여러 자료를 따로따로 요약하지 말고, 공통 주장과 충돌하는 주장만 묶어서 보여줘. 숫자와 날짜는 빠뜨리지 말고, 어떤 자료도 답하지 않은 공백이 있으면 따로 적어줘.

이런 식으로 반복하다 보면 Hermes는 점점 당신이 원하는 요약 톤을 배운다. 어떤 사람은 짧은 임원용 메모를 원하고, 어떤 사람은 출처 충돌을 먼저 보는 분석 메모를 원한다. 이 차이를 Hermes의 메모리와 스킬이 흡수해 준다.¹

서버 운영형 Hermes: 늘 고치는 사람보다, 먼저 알아차리는 동료

운영 환경에서 Hermes를 가장 유용하게 쓰는 방법은 처음부터 "자동 복구 로봇"으로 만드는 것이 아니다. 그보다 먼저 알림을 읽고, 맥락을 붙이고, 첫 대응안을 정리하는 동료로 두는 편이 훨씬 안정적이다.

예를 들어 배포가 끝났을 때 CI/CD가 웹훅을 보내면 Hermes가 헬스 체크와 버전 확인을 해 보고, 상태를 healthy, degraded, failed로 나눠 팀 채널에 알려줄 수 있다. 모니터링 경보가 오면 최근 변경과 연관 지어 원인 후보를 좁히고, 첫 대응 단계를 초안으로 적어 줄 수도 있다. 또 30분마다 엔드포인트를 점검하다가 실제 장애가 있을 때만 알리는 조용한 업타임 감시도 만들 수 있다.⁶

이 패턴이 좋은 이유는 운영자가 새벽 3시에 받는 메시지의 질이 달라지기 때문이다. 단순히 "500 에러 발생"만 오는 것과, "방금 배포된 버전 이후 API 응답이 500으로 바뀌었고, 최근 로그 패턴상 DB 연결 실패가 유력하며, 우선 롤백 또는 연결 풀 점검이 필요함"이 같이 오는 것은 완전히 다른 경험이다.

서버 운영형 Hermes의 기본 설계는 보통 이렇다.

• 입력: 배포 웹훅, 경보 시스템, 주기 점검 스크립트

• 판단: 헬스 체크, 버전 조회, 최근 변경 상관관계, 알려진 오류 패턴 조사

• 전달: 온콜용 Telegram, 팀용 Slack, 기록용 파일 또는 이메일

• 축적: 자주 반복되는 장애 패턴을 스킬이나 메모로 남기기

여기서 특히 중요한 것은 "행동 권한"을 단계별로 나누는 일이다. 처음에는 읽기와 요약만 하게 하고, 그 다음 승인 후 재시작 정도를 붙이고, 정말 익숙해진 뒤에만 제한적 복구 작업을 고려하는 편이 좋다. 장애 대응은 똑똑함보다 안전성이 먼저이기 때문이다.

운영 업무에 Hermes를 붙일 때는 작은 승리부터 쌓는 것이 좋다. 예를 들어 첫 주에는 배포 확인만, 둘째 주에는 경보 요약까지, 셋째 주에는 업타임 감시까지 붙인다. 그러면 "운영 자동화"가 거대한 프로젝트가 아니라, 잘 작동하는 습관 세트가 된다.

멀티채널 알림 허브형 Hermes: 같은 내용을 everywhere가 아니라, 맞는 채널에 맞는 형태로

Hermes의 게이트웨이를 처음 쓰면 자꾸 "같은 메시지를 여러 곳에 보내는 봇"으로 상상하게 된다. 하지만 진짜 잘 쓰는 방식은 한 사건을 채널마다 다르게 번역하는 허브로 두는 것이다.

예를 들어 같은 PR 리뷰 결과라도 GitHub에는 짧고 구체적인 댓글이 어울리고, Slack에는 팀 전체 요약이 어울리며, Telegram에는 담당자에게만 오는 긴급 알림이 어울린다. Hermes는 이런 전달 계층을 설계하기에 좋은 구조를 갖고 있다.²

채널을 나눌 때는 역할이 분명해야 한다.

• Telegram: 나 개인에게 오는 즉시 알림, 온콜, 확인 요청

• Slack: 팀 공유용 요약, 토론 시작점, 일일·주간 다이제스트

• GitHub 댓글: PR이나 이슈에 직접 붙는 실행 가능한 피드백

• 로컬 파일·이메일: 보관, 감사 기록, 나중에 다시 찾을 아카이브

Discord처럼 여러 사람이 함께 쓰는 공간은 더 섬세하게 설계해야 한다. 기본적으로 Hermes는 DM에서는 매 메시지에 응답하고, 서버 채널에서는 보통 멘션이 있을 때만 반응한다. 또한 같은 공유 채널에서도 사용자별 세션을 분리해 맥락이 섞이지 않게 운영할 수 있다.⁷ 이 특성을 이해하면 공용 방에서 봇이 갑자기 끼어드는 사고를 줄일 수 있다.

멀티채널 허브형에서 기억할 원칙은 단순하다. 작업 채널과 결과 채널을 분리하라. 사람이 Hermes에게 지시하는 곳과, Hermes가 자동 결과를 보내는 곳을 분리하면 훨씬 덜 시끄럽다. 예를 들어 개발팀은 Slack의 #build-alerts에서 결과만 받고, 실제 상세 조정은 DM이나 CLI에서 한다. 그러면 채널이 작업실이 아니라 전광판이 된다.

이 패턴은 개인보다 팀에서 특히 강력하다. 팀원마다 Hermes를 직접 다루는 숙련도가 달라도, 결과를 받아보는 방식은 통일할 수 있기 때문이다.

내 업무에 맞는 Hermes 운영 방식 고르기

이제 중요한 건 "어떤 기능을 쓸까?"가 아니라 "어떤 운영 모드를 기본값으로 둘까?"다. 보통은 아래 세 축으로 정하면 된다.

첫째, 트리거를 정한다. 내 일은 시간이 되면 시작되는가, 이벤트가 오면 시작되는가, 내가 직접 지시할 때만 시작되는가?

둘째, 작업 성격을 정한다. 정리와 요약이 중심인가, 코드와 파일 수정이 중심인가, 외부 시스템 반응이 중심인가?

셋째, 도착 채널을 정한다. 결과가 나만 보면 되는가, 팀이 같이 봐야 하는가, 시스템 기록으로 남아야 하는가?

이 세 축으로 보면 대표적인 운영 조합은 금방 나온다.

혼자 일하는 사람이라면 개인 비서형 Hermes 하나와 프로젝트별 개발 Hermes 하나면 충분한 경우가 많다. 팀에서 운영한다면 개발 자동화형과 서버 운영형을 분리하는 편이 안정적이다. 리서치가 많은 조직이라면 리서치 요약형 Hermes를 별도로 두고, 결과만 멀티채널 허브를 통해 배포하면 된다.

처음부터 거대한 체계를 만들 필요는 없다. 오히려 다음 순서가 가장 현실적이다.

1. 매일 반복되는 귀찮은 일 하나를 고른다.

2. 그 일을 시작시키는 트리거 하나를 정한다.

3. 결과를 받을 채널 하나를 정한다.

4. Hermes가 참고할 기본 규칙 세 줄만 적는다.

5. 일주일 돌려 보고, 불필요한 알림부터 줄인다.

Hermes는 많이 붙인다고 똑똑해지는 도구가 아니다. 잘 나눈 흐름 위에 올릴수록 똑똑해지는 도구다. 기능은 이미 충분하다. 이제 필요한 것은 당신의 일에 맞는 리듬을 만드는 일이다.

그 리듬이 생기면, Hermes는 더 이상 "가끔 켜 보는 AI"가 아니다. 눈앞의 일을 대신하는 비서이자, 반복 업무를 외워 가는 동료이자, 당신이 자리를 비운 사이에도 조용히 일하는 운영 파트너가 된다.

참고

¹Hermes Agent Documentation

²Automation Templates | Hermes Agent

³Hermes Agent Multi-Agent — Parallel Agents That Work Together

⁴Gemini Models for Hermes Agent — Long-Context Workflows

⁵Hermes Agent + Gemma 4 & Qwen 3.5: Local AI Agent Guide

⁶Automation Templates | Hermes Agent

⁷Discord | Hermes Agent