Hermes Agent 사용 사례와 Claude Code + Codex 조합 전략

들어가며

요즘 AI 코딩 도구를 쓰다 보면 선택지가 너무 많다. Cursor, Claude Code, Codex, Gemini CLI, Devin류 서비스까지 각자 장점이 다르다. 그런데 실제 업무에서는 "어떤 모델이 더 똑똑한가"보다 더 중요한 문제가 있다.

내가 쓰는 채팅창, 터미널, GitHub, 로컬 파일, 서버 작업을 하나의 흐름으로 묶을 수 있는가?

Hermes Agent는 이 지점에 초점을 둔 오픈소스 AI 에이전트 프레임워크다. 단순한 챗봇이나 IDE 플러그인이 아니라, 터미널·메신저·스케줄러·MCP·파일 시스템·브라우저·GitHub 워크플로우를 연결해 "일을 끝내는" 쪽에 가깝다.

이 글에서는 Hermes Agent의 대표 사용 사례를 정리하고, 특히 Hermes를 Codex 메인 모델로 연결해서 쓰는 것과 Codex CLI를 그냥 쓰는 것의 차이를 따로 짚는다. 처음엔 나도 Hermes, Codex, Claude Code를 서로 다른 코딩 도구처럼만 나눠서 생각했는데, 실제로는 층위가 다르다. Hermes가 작업 실행 레이어를 맡고, Codex나 Claude는 그 안에 꽂아 쓰는 모델 또는 하위 도구 역할을 한다.

Hermes Agent 한 줄 요약

Hermes Agent는 Nous Research가 만든 자기 개선형(self-improving) AI 에이전트다. 공식 문서에서는 Hermes를 "경험으로부터 스킬을 만들고, 사용 중 스킬을 개선하며, 세션을 넘어 사용자를 이해하는 에이전트"로 설명한다.

핵심은 다음 네 가지다.

1. 어디서나 실행: 로컬 터미널뿐 아니라 Slack, Telegram, Discord, WhatsApp, Email 등 메시징 플랫폼에서 호출 가능
2. 도구 실행: 파일 편집, 터미널 명령, 웹 검색, 브라우저 자동화, 이미지/음성 도구, GitHub 작업 등을 도구로 수행
3. 지속 기억: 사용자 선호, 프로젝트 구조, 반복되는 워크플로우를 메모리와 스킬로 보존
4. 모델 독립성: OpenAI Codex, Anthropic, OpenRouter, Gemini, GitHub Copilot, 로컬 OpenAI 호환 엔드포인트 등 다양한 provider를 선택 가능

즉 Hermes는 하나의 모델이 아니라 여러 모델과 도구를 엮어 작업을 운영하는 층이다.

Hermes에 Codex를 연결한다는 뜻

여기서 헷갈리기 쉬운 부분이 있다.

"Hermes를 Codex로 쓴다"는 말은 보통 Hermes의 메인 LLM provider를 OpenAI/Codex 계열로 둔다는 뜻이다. 이 경우 실제 추론은 GPT-5.5나 Codex 계열 모델이 하지만, 작업을 받는 입구와 도구 실행 방식은 Hermes가 관리한다.

반대로 "Codex를 그냥 쓴다"는 말은 보통 Codex CLI를 터미널에서 직접 실행한다는 뜻이다.

그래서 둘은 서로 경쟁한다기보다 계층이 다르다. Codex CLI가 코딩을 실행하는 도구라면, Hermes는 그 실행기를 포함해 여러 도구를 호출하면서 작업 전체를 관리한다.

내가 Slack에서 "블로그 글 만들고 PR 올려줘"라고 시키는 상황을 생각하면 차이가 확실하다. Codex CLI 단독이면 터미널을 열고 레포 안에서 직접 실행해야 한다. Hermes + Codex provider라면 Slack 메시지를 입구로 삼고, 레포 위치 기억, 문서 조사, 파일 수정, 빌드, 커밋, PR 생성까지 한 번에 이어갈 수 있다.

어떻게 연결되는가: 3가지 API mode와 인증 경로

"Hermes를 Codex로 쓴다"의 실제 메커니즘은 Hermes가 내부적으로 세 가지 API mode 중 하나를 골라 호출한다는 데 있다.

인증 경로도 세 갈래로 정리된다. 첫째는 .env의 API key, 둘째는 hermes model로 등록하는 OAuth device code(자격증명은 auth.json에 저장), 셋째는 config.yaml의 Custom endpoint다. Custom endpoint는 OpenAI 호환이라면 무엇이든 받기 때문에 로컬 LLM 연결도 여기로 들어온다.

세션 중간에 모델을 바꾸고 싶으면 대화 기록을 유지한 채 전환할 수 있다.

/model zai:glm-5
/model openrouter:anthropic/claude-sonnet-4
/model custom:local:qwen-2.5

즉 "Hermes의 메인 모델이 Codex냐 Claude냐"는 고정 선택이 아니라 세션 안에서 갈아 끼우는 슬롯에 가깝다. 이 점이 Codex CLI 단독과의 운영상 차이를 가장 크게 만든다.

사용 사례 1. Slack/Telegram에서 바로 작업시키기

Hermes의 가장 체감되는 장점은 Messaging Gateway다. Gateway를 켜두면 Slack, Telegram, Discord 같은 메신저에서 Hermes에게 직접 일을 시킬 수 있다.

예를 들어 Slack에서 다음처럼 요청할 수 있다.

Hermes Agent 사용 사례 조사해서 내 블로그 레포에 글 만들고 PR 올려줘

그러면 Hermes는 대화창 안에서:

1. 레포 위치를 확인하고
2. 공식 문서를 조사하고
3. Markdown 글을 작성하고
4. 로컬 빌드를 검증하고
5. 브랜치를 만들고 커밋한 뒤
6. GitHub PR까지 생성한다.

이 흐름은 IDE 안에서만 동작하는 코딩 어시스턴트와 다르다. 사용자는 노트북을 열지 않아도 되고, 모바일 메신저에서 지시만 내려도 된다. Hermes 문서도 Gateway가 "하나의 백그라운드 프로세스"로 여러 플랫폼을 연결하고, 플랫폼별 세션과 cron job까지 관리한다고 설명한다.

언제 유용한가?

• 이동 중 Slack/Telegram으로 간단한 PR 요청
• 서버에서 돌고 있는 장기 작업 모니터링
• 배포 후 로그 확인 및 요약
• 블로그 초안, 리서치 노트, 이슈 정리 자동화
• 팀 채널에서 에이전트를 호출해 반복 업무 처리

사용 사례 2. 메모리와 스킬로 "다시 설명하지 않기"

Hermes에는 두 종류의 장기 기억이 있다.

• Memory: 사용자 선호, 프로젝트 위치, 환경 정보 같은 짧은 사실
• Skills: 반복 가능한 절차를 담은 Markdown 기반 워크플로우 문서

Persistent Memory 문서에 따르면 Hermes는 ~/.hermes/memories/ 아래의 메모리를 세션 시작 시 시스템 프롬프트에 주입한다. 예를 들면 "사용자는 GitHub 레포를 /Users/.../Desktop/... 아래에 둔다" 같은 정보가 다음 세션에도 살아 있다.

Skills System은 더 절차적이다. 예를 들어 "GitHub PR 만들기", "Claude Code 호출하기", "블로그 글 작성하기" 같은 반복 작업을 스킬로 만들면 Hermes가 필요할 때 해당 문서를 로드한다.

이게 중요한 이유는 간단하다.

AI 도구를 오래 쓰다 보면 성능 차이보다 "내 환경을 매번 다시 설명해야 하는 비용"이 더 크게 느껴진다.

Hermes의 메모리/스킬 구조는 이 비용을 줄인다. 단순히 대화 기록을 길게 유지하는 방식이 아니라, 필요한 사실과 절차를 압축해서 다음 작업의 기본 컨텍스트로 삼는다.

사용 사례 3. Cron으로 정기 작업 자동화하기

Hermes는 Scheduled Tasks(Cron) 기능을 제공한다. 자연어로 "매일 오전 9시에 뉴스 요약해서 보내줘"라고 요청하면 cron job으로 등록할 수 있다.

활용 예시는 다음과 같다.

• 매일 아침 AI 뉴스, Hacker News, arXiv 요약 받기
• 매주 블로그 소재 후보 수집하기
• 정해진 시간에 서버 상태 확인 후 Slack에 보고하기
• GitHub PR/CI 상태를 주기적으로 확인하기
• RSS 피드나 특정 웹페이지 변경 감지하기

흥미로운 점은 cron job도 skill을 로드할 수 있다는 것이다. 예를 들어 blogwatcher 스킬과 maps 스킬을 함께 붙여 "동네 행사와 새 글을 합쳐 브리핑" 같은 작업을 만들 수 있다.

또한 no_agent 모드에서는 LLM 없이 스크립트 출력만 전달할 수 있다. 단순 모니터링에는 비용을 아끼고, 요약·판단이 필요한 작업에만 LLM을 쓰는 구조다.

사용 사례 4. MCP로 외부 도구 붙이기

Hermes는 MCP(Model Context Protocol)를 지원한다. MCP는 외부 도구 서버를 에이전트에 붙이는 표준 인터페이스다.

MCP로 연결할 수 있는 예시는 다음과 같다.

• GitHub
• 데이터베이스
• 파일 시스템
• 브라우저 자동화
• 사내 API
• 다른 MCP 호환 서비스

Hermes는 MCP 서버의 도구를 시작 시 자동 등록하고, mcp_<server>_<tool> 같은 이름으로 충돌을 피한다. 이 구조 덕분에 Hermes 자체에 모든 도구를 네이티브로 구현하지 않아도 된다. 이미 MCP 서버가 있는 도구라면 설정만 추가해서 Hermes의 작업 범위를 넓힐 수 있다.

사용 사례 5. 코딩 에이전트 오케스트레이션

Hermes는 직접 코드를 수정할 수도 있지만, 필요하면 다른 코딩 에이전트를 호출하는 오케스트레이터로도 쓸 수 있다.

대표 조합은 다음과 같다.

이때 Hermes는 모든 일을 직접 처리하지 않는다. 어떤 하위 에이전트에게 어떤 일을 맡길지 결정하고 그 결과를 검증하는 관리자 역할을 맡는다.

GPT-5.5와 Claude Opus 4.7 기준 역할 나누기

2026년 기준으로 보면 GPT-5.5와 Claude Opus 4.7은 둘 다 코딩을 잘한다. 다만 성향이 다르다. 공개 페이지 기준으로 GPT-5.5는 OpenRouter에서 1M급 컨텍스트, 텍스트+이미지 입력, 복잡한 전문 작업과 코딩을 강조한다. Anthropic은 Opus 4.7을 발표하면서 고난도 소프트웨어 엔지니어링, 긴 agentic task, 지시 이행, 고해상도 이미지 이해, 문서/슬라이드 같은 전문 산출물 품질을 강조했다.

내 기준의 결론은 이렇다.

즉 "Hermes에서 Codex로 코딩하고 Claude로 리뷰하는 게 가장 좋냐"에 대한 답은 대체로 좋은 기본값이지만 항상 최선은 아니다에 가깝다.

좋은 기본값인 이유는 간단하다. 구현자와 리뷰어를 분리하면 한 모델이 만든 실수를 다른 모델이 다른 관점에서 볼 가능성이 생긴다. Codex/GPT-5.5가 빠르게 수정하고, Claude Opus 4.7이 설계·리뷰·엣지 케이스를 보는 조합은 실전에서 꽤 안정적이다.

다만 다음 경우에는 바꾸는 게 낫다.

• 요구사항이 애매하고 설계가 더 중요하면: 먼저 Opus 4.7로 계획/리뷰를 받고, 구현을 GPT-5.5/Codex에 맡긴다.
• 단순 반복 수정이면: Claude 리뷰까지 돌리지 않고 GPT-5.5/Codex + 테스트로 끝낸다.
• UI/UX 설계나 글/문서 톤이 중요하면: Opus 4.7을 앞단에 둔다.
• 이미지 생성이 포함되면: Hermes에서 OpenAI 이미지 도구나 별도 이미지 생성 backend를 호출하고, Opus는 프롬프트/시안 비평에 쓴다.

추천 조합: Hermes는 관리자, Codex는 구현자, Claude는 리뷰어

내가 추천하는 기본 운영 방식은 다음과 같다.

사용자(Slack/CLI)
  ↓
Hermes Agent (GPT-5.5 또는 Codex provider)
  ├─ 레포/요구사항 파악
  ├─ 작업 계획 수립
  ├─ Codex/GPT-5.5로 구현
  ├─ Claude Opus 4.7/Claude Code로 리뷰·설계 검토
  ├─ 테스트/빌드 직접 실행
  └─ Git commit / push / PR 생성

중요한 점은 Hermes가 "또 하나의 코딩 모델"이 아니라는 것이다. Hermes가 Codex provider로 떠 있으면 답변을 만드는 두뇌는 GPT-5.5/Codex지만, 기억·도구·메신저·스케줄러·PR 흐름은 Hermes가 잡고 있다.

Codex나 Claude는 중요한 하위 실행기/리뷰어가 될 수 있지만, Slack 입구부터 memory, skill, tool routing, 검증, PR 생성까지 묶는 레이어는 Hermes다.

1단계. Hermes가 요구사항을 정리한다

사용자는 Slack에서 자연어로 요청한다.

이 이슈 보고 수정해서 PR 올려줘. 리뷰는 Claude Code로 한 번 돌려줘.

Hermes는 먼저 레포 상태를 확인한다.

git status --short --branch
git fetch origin
git checkout -b fix/some-issue

그리고 필요한 문서를 읽고 작업 범위를 좁힌다.

2단계. GPT-5.5/Codex가 구현한다

구현 범위가 명확하면 Codex 계열 모델에게 맡긴다. Hermes의 메인 모델이 GPT-5.5라면 Hermes가 직접 파일을 수정해도 되고, 별도 Codex CLI를 호출해도 된다.

codex exec --full-auto "Implement the fix described in ISSUE.md. Run tests and commit when done."

단, Codex 결과를 그대로 믿으면 안 된다. Hermes가 git diff, 테스트 결과, 변경 파일을 다시 확인해야 한다.

3단계. Claude Opus 4.7이 리뷰한다

구현 후에는 Claude Code에 diff 리뷰를 맡긴다.

git diff origin/main...HEAD | claude -p \
  "Review this diff for correctness, edge cases, security issues, and missing tests. Return actionable findings." \
  --max-turns 1

Claude는 구현 자체보다 "이 변경이 안전한가?", "설계가 어색하지 않은가?", "테스트가 빠지지 않았나?"를 보는 reviewer로 두면 좋다.

4단계. Hermes가 최종 검증하고 PR을 만든다

마지막은 Hermes가 직접 처리한다.

bun run build
git status --short
git add <changed-files>
git commit -m "docs: add Hermes Agent use cases"
git push -u origin HEAD
gh pr create --title "docs: add Hermes Agent use cases" --body "..."

여기서 중요한 원칙은 최종 책임자는 Hermes라는 점이다. Codex나 Claude Code가 "완료"라고 말해도, Hermes가 실제 파일과 테스트 결과, Git 상태를 확인한 뒤 PR을 올려야 한다.

Multi-Agent Kanban: v0.13.0의 협업 보드

위 4단계는 한 사람이 Slack에서 시키는 단일 흐름이다. 여러 agent가 동시에 작업하고 결과를 주고받아야 하면 v0.13.0+의 Multi-Agent Kanban 보드가 같은 패턴을 영속적으로 만들어준다. 핵심 메커니즘은 네 가지다.

특히 hallucination gate는 위 4단계의 구현자/리뷰어 분리를 보드 차원에서 강제한다. Codex가 만든 결과가 Claude 리뷰의 검증을 통과하지 못하면 카드가 그대로 보드로 돌아가고, 다음 worker나 사람이 재처리한다. 단일 흐름이라면 사람이 한 번 검토하고 끝나지만, 보드 위에서는 검증 실패가 자연스러운 재진입 신호가 된다.

이 보드 위에서 "Hermes가 관리자, Codex가 구현자, Claude가 리뷰어"라는 분담이 일회성 명령이 아니라 지속 가능한 워크플로우가 된다.

Hermes에 사람들이 많이 붙이는 것들

정확한 사용량 telemetry가 공개되어 있지는 않다. 다만 공식 문서, OpenRouter 연동 문서, 설치 가이드류에서 반복적으로 등장하는 조합은 꽤 뚜렷하다.

내가 보기엔 Hermes의 강점은 "어떤 모델이 제일 똑똑한가"보다 "어디에 붙여두면 귀찮은 일을 실제로 끝내는가"에서 나온다. 그래서 많이 쓰는 연결도 모델 하나가 아니라 메신저, OpenRouter, MCP, cron 쪽으로 몰린다.

자동 티키타카: 사람은 decision gate에 집중하기

Claude, Codex, 다른 모델을 "티키타카"하게 만드는 핵심은 모델을 많이 부르는 것이 아니라 역할과 승인 지점을 분리하는 것이다. Atlassian HULA 사례처럼 좋은 human-in-the-loop 구조는 agent가 Jira/GitHub issue를 읽고 plan, code, PR까지 만들지만, 사람은 plan 승인과 중요한 trade-off 결정에 남는다. GitHub Agentic Workflows도 같은 방향이다. agent는 GitHub Actions 안에서 실행되고, repo owner가 permissions, logs, review boundary를 정한다.

내가 보기에 Hermes 기반으로 최적화하려면 다음 6단계가 좋다.

여기서 중요한 건 자동화율을 100%로 올리는 게 아니다. low-risk loop는 자동화하고, irreversible decision은 사람에게 올리는 것이 성능 대비 비용이 좋다.

Decision gate 기준

사람에게 물어봐야 하는 경우를 명확히 정해두면 agent가 쓸데없이 멈추지도 않고, 위험한 결정을 혼자 하지도 않는다.

즉 사람은 "어떤 안을 택할지"만 결정하고, agent는 그 결정을 실행 가능한 문서와 PR로 바꾼다.

PR comment는 트리거일 뿐, 지식 저장소는 아니다

PR이나 issue comment는 좋은 communication 수단이다. 하지만 모든 레포에서 생긴 decision과 insight를 장기 자산으로 쌓고 싶다면, PR comment를 지식의 source of truth로 두면 안 된다. 댓글은 맥락이 흩어지고, 레포마다 포맷이 다르고, merge 이후에는 다시 찾기 어렵다.

더 나은 구조는 중앙 knowledge inbox를 두는 것이다.

이렇게 하면 PR comment는 여러 입력 중 하나가 된다. 중요한 건 comment 자체가 아니라, comment에서 나온 결정과 이유가 ADR 또는 wiki로 승격되는 기준이다.

이 레포에는 우선 작은 검증 트리거만 붙였다. PR에서 content/wiki/**, content/**/*.md, scripts/verify-wiki.py, .github/workflows/wiki-verify.yml이 바뀌면 GitHub Actions가 scripts/verify-wiki.py를 실행한다. 이 검사는 wiki frontmatter, wikilink 해석, index 누락, 비공개 레포명/조직명 같은 금지어 노출을 막는다. 아직 "모든 레포 → 중앙 inbox → 자산 선별 → wiki PR" 자동화까지는 아니다. 그건 이 블로그 레포 안의 PR comment workflow가 아니라, Hermes cron/webhook이 여러 레포를 읽고 중앙 wiki에 PR을 여는 별도 파이프라인으로 가는 편이 맞다.

Wiki로 들어가야 지식이 된다

프로젝트가 굴러가며 생긴 decision은 PR 안에만 있으면 금방 사라진다. 진짜 지식으로 남기려면 세 층으로 저장하는 게 좋다.

ADR은 Microsoft ADR 가이드처럼 append-only로 두고, 결정이 바뀌면 기존 ADR을 수정하지 말고 새 ADR이 supersede하게 둔다. Wiki는 반대로 최신 상태를 반영하는 mutable 문서다. 그래서 ADR은 왜를 보존하고, wiki는 지금 무엇인지를 설명한다고 나누면 된다.

팀 decision을 wiki에 넣을 때도 단순 결론만 쓰면 지식이 아니다. 최소한 다음을 포함해야 한다.

## Decision summary
무엇을 결정했는가
 
## Context
어떤 문제, 제약, 요구사항 때문에 결정이 필요했는가
 
## Options considered
검토한 대안과 버린 이유
 
## Decision drivers
성능, 비용, 보안, 운영, 개발 속도 중 무엇을 우선했는가
 
## Consequences
좋아지는 점, 나빠지는 점, 나중에 다시 볼 조건
 
## Links
관련 ADR, issue, PR, 코드 경로

이 구조가 있어야 나중에 agent가 wiki를 읽고 "그때 왜 그렇게 했는지"까지 이해한다. 그냥 최신 결론만 있으면 다음 agent가 같은 논쟁을 반복한다.

작업 유형별 분업표

기호는 개인적인 추천이다. ◎는 주 담당, ○는 보조, △는 상황에 따라 가능, ×는 직접 담당하기 어렵다는 뜻이다.

실전 프롬프트 예시

Hermes에게 전체 작업 요청

이 레포에서 로그인 실패 버그를 조사해줘.
1. 새 브랜치를 만들고
2. Codex로 수정안을 구현한 뒤
3. Claude Code로 diff 리뷰를 받고
4. 테스트 통과하면 PR을 올려줘.
리뷰에서 지적된 내용은 반영하고, 최종 요약도 남겨줘.

Codex에게 구현만 맡기기

Implement the minimal fix for the login redirect bug.
Do not change unrelated files.
Run the relevant tests.
Leave a concise commit message suggestion.

Claude Code에게 리뷰만 맡기기

Review this diff as a senior engineer.
Focus on correctness, missing tests, security, and maintainability.
Do not rewrite the code unless necessary.
Return findings in priority order.

Hermes가 Claude/Codex 결과를 검증할 때

Compare Codex's changes with Claude Code's review findings.
Apply only high-confidence fixes.
Run the project's build/test command.
If anything is uncertain, report it instead of guessing.

주의할 점

1. 하위 에이전트의 말을 그대로 믿지 않기

Codex나 Claude Code가 "테스트 통과"라고 말해도 실제로는 실패했거나, 다른 디렉터리에서 실행했을 수 있다. Hermes가 직접 테스트 명령과 git diff를 확인해야 한다.

2. 권한을 과하게 열지 않기

Claude Code에는 --dangerously-skip-permissions, Codex에는 --yolo 같은 강력한 옵션이 있다. 빠르지만 위험하다. 개인 실험 레포가 아니라면 최소 권한 원칙을 지키는 편이 좋다.

3. 역할을 섞지 않기

한 에이전트에게 구현, 리뷰, PR 생성, 배포까지 모두 맡기면 검증 지점이 사라진다. 구현은 Codex, 리뷰는 Claude Code, 최종 검증과 PR은 Hermes처럼 역할을 나누면 품질 관리가 쉬워진다.

4. 프로젝트 컨텍스트 파일을 관리하기

Hermes는 AGENTS.md, CLAUDE.md, .cursorrules 같은 프로젝트 컨텍스트 파일을 읽을 수 있다. Claude Code는 CLAUDE.md와 .claude/settings.json을 활용한다. Codex도 레포의 작업 가이드를 참고할 수 있다.

따라서 프로젝트 루트에는 다음 정보를 명확히 적어두는 것이 좋다.

• 수정 가능한 디렉터리와 금지된 디렉터리
• 테스트/빌드 명령
• 커밋 메시지 규칙
• 배포 주의사항
• 비밀키/환경파일 접근 금지 규칙

Self-host 운영에서 자주 깨지는 지점들

Hermes를 본격적으로 자기 환경에 띄우면 모델 선택보다 인프라 쪽에서 막히는 경우가 잦다. docs와 실무자 가이드에서 반복적으로 등장하는 함정을 묶어두면 디버깅 시간이 크게 줄어든다.

1. Local LLM의 기본 context length

Ollama나 llama.cpp 같은 로컬 서버는 기본 context length가 4K 수준으로 낮은 경우가 많다. 그대로 띄우면 "Context limit: 2048 tokens" 같은 에러를 본다.

# Ollama: 서버 기동 시 환경변수
OLLAMA_CONTEXT_LENGTH=32768 ollama serve
 
# 또는 Hermes config.yaml에서 명시
model:
  context_length: 32768

vLLM은 --max-model-len 65536, llama.cpp는 -c 32768을 명시한다.

2. Tool call이 그냥 텍스트로 출력되는 경우

로컬 서버가 tool calling을 활성화하지 않으면 agent가 호출했어야 할 도구 이름이 일반 텍스트로 흘러나온다. 서버별로 켜는 옵션이 다르다.

3. Auxiliary model이 조용히 실패하는 경우

Hermes는 vision, web extract, compression 같은 보조 작업에 별도 모델을 쓴다. Anthropic API key만 설정해두면 이 보조 모델들이 기본 fallback 체인을 따라가다 조용히 실패한다. 메인 모델로 흡수하려면 config.yaml에 한 줄을 추가한다.

auxiliary:
  vision: { provider: "main" }
  web_extract: { provider: "main" }

4. WSL2에서 Windows 호스트 모델 접근

WSL2는 기본적으로 Windows와 다른 서브넷에 있어서 127.0.0.1로 호스트 모델 서버를 부르면 "Connection refused"가 난다. Windows 11 22H2+에서는 %USERPROFILE%\.wslconfig에 [wsl2] networkingMode=mirrored를 켜는 게 가장 간단하다. 구형 Windows라면 default gateway IP를 알아내 모델 서버를 0.0.0.0에 바인딩해야 한다.

5. "지금 설정이 어디서 오는 거지?"

자주 막히는 순간은 "이 모델/도구/auth가 어디서 읽혀 오는지 모르겠다"이다. 진단 명령 네 개를 외워두면 대부분 즉시 풀린다.

hermes doctor          # 설정과 의존성 문제 진단
hermes status          # 현재 설정 + auth 상태
hermes dump            # 복붙용 setup 요약(secret 마스킹)
hermes logs list       # 모든 로그 파일 경로

이 다섯 가지가 self-host 도입 첫 주에 가장 많은 시간을 빼앗는 함정이다.

결론

Hermes Agent의 강점은 단순히 "답변을 잘하는 모델"이 아니라, 여러 도구와 모델을 하나의 작업 흐름으로 묶는 능력에 있다.

Hermes를 GPT-5.5/Codex provider로 쓴다고 해서 Codex CLI 단독 사용과 같아지는 것은 아니다. 추론 엔진은 같거나 비슷할 수 있지만, Hermes에는 Slack 입구, 장기 기억, 스킬, cron, MCP, GitHub PR 흐름이 붙는다. 이 차이가 실사용에서는 꽤 크다.

내 기본값은 이렇다.

• Hermes 메인 모델: GPT-5.5 또는 Codex provider
• 빠른 구현: Hermes 내부 도구 실행 또는 Codex CLI
• 설계/리뷰: Claude Opus 4.7 / Claude Code
• 이미지 생성: OpenAI 이미지 계열 또는 전용 이미지 모델
• 최종 검증/PR 관리: Hermes Agent

다만 이건 고정 공식이 아니다. 단순 구현은 GPT-5.5/Codex만으로 충분하고, 설계가 어려운 작업은 Opus 4.7을 먼저 쓰는 편이 낫다. 이미지 생성은 Claude가 아니라 OpenAI 쪽이나 전용 이미지 모델을 붙이는 게 자연스럽다.

그동안 써 보니 AI 에이전트는 하나의 만능 모델을 찾기보다 작업의 성격에 맞춰 모델과 도구를 나누고 검증 루프를 만들 때 더 잘 굴러갔다. Hermes Agent는 그 오케스트레이션 레이어로 꽤 좋은 위치에 있다.

참고 자료

• Hermes Agent Documentation
• Hermes Agent - Integrations
• Hermes Agent - AI Providers
• Hermes Agent - Messaging Gateway
• Hermes Agent - Persistent Memory
• Hermes Agent - Skills System
• Hermes Agent - Scheduled Tasks
• Hermes Agent - MCP
• OpenRouter - Hermes Agent Integration
• Anthropic - Introducing Claude Opus 4.7
• OpenRouter - GPT-5.5 model page
• Atlassian - Human in the Loop Software Development Agents
• GitHub Blog - Automate repository tasks with GitHub Agentic Workflows
• MSR 2026 - How AI Coding Agents Communicate
• AWS Architecture Blog - ADR best practices
• Microsoft - Maintain an architecture decision record
• Architectural Decision Records
• Claude Code GitHub Actions
• OpenAI Cookbook - Build Code Review with the Codex SDK
• OpenAI Codex GitHub Repository
• Claude Code Overview
• Claude Code CLI Reference
• Claude Code Settings
• Hermes Agent 실무자 레퍼런스 종합 정리 (Blake Crosley)