Hermes Agent 정의와 구조
Hermes는 Nous Research가 개발한 오픈소스 AI 에이전트 실행 플랫폼인 Hermes Agent 이다. 단순히 질문에 답하는 챗봇이 아니라, 대규모 언어 모델(LLM)에 파일 처리, 터미널 명령, 웹 검색, 브라우저, 메모리, 자동화, 메시징 채널 같은 도구를 연결해 실제 작업을 수행하게 만드는 에이전트 프로그램이다.
1. Hermes의 기본 구조
Hermes 자체가 GPT나 Claude 같은 AI 모델은 아니다. 사용자가 선택한 AI 모델을 호출하고, 그 모델이 여러 도구를 사용해 작업하도록 연결하고 관리하는 에이전트 하네스(Agent Harness)에 가깝다.
2. Hermes로 할 수 있는 일
Hermes에 다음과 같은 요청을 내릴 수 있다.
- 서버의 디스크 사용량을 확인하고 가장 큰 디렉터리 5개를 알려줘.
- 매일 오전 9시에 AI 뉴스를 조사해서 Telegram으로 요약해줘.
- GitHub 저장소를 분석하고 오류를 수정한 다음 테스트를 실행해줘.
- 이 서버의 Docker 컨테이너 상태를 확인하고 문제가 있으면 원인을 분석해줘.
Hermes는 요청을 해석한 다음 필요에 따라 터미널 명령을 실행하거나 파일을 읽고 수정한다. 공식 문서에서는 로컬 컴퓨터, Docker, SSH 원격 서버, Modal, Daytona, Vercel Sandbox 등을 명령 실행 환경으로 지원한다.
3. Hermes Agent 와 Codex 와의 차이
| 구분 | Hermes Agent | OpenAI Codex |
|---|---|---|
| 개발사 | Nous Research | OpenAI |
| 핵심 목적 | 범용·상시 AI 에이전트 운영 | 소프트웨어 개발과 코딩 |
| 모델 | 여러 제공자 선택 가능 | OpenAI Codex 모델 중심 |
| 주요 인터페이스 | CLI, 웹, 메시징 앱 | CLI, IDE, 웹·앱 |
| 장기 실행 | Gateway와 cron 지원 | 개발 작업과 자동화 중심 |
| 메모리 | 세션·메모리·SOUL 지원 | 프로젝트와 세션 중심 |
| 메시징 연결 | Telegram, Slack 등 | 기본 목적이 아님 |
| 대표 용도 | 개인 AI 비서, 봇, 서버 에이전트 | 코드 작성, 수정, 테스트, 리뷰 |
4. Hermes Agent 와 Github Pages, Actions 차이점
| 구분 | Hermes Agent | GitHub Pages | GitHub Actions |
|---|---|---|---|
| 정체 | AI 에이전트 플랫폼 | 정적 웹 호스팅 | CI/CD 자동화 플랫폼 |
| 주요 목적 | 사용자 지시를 이해하고 작업 수행 | HTML·CSS·JavaScript 공개 | 빌드·테스트·배포 자동화 |
| AI 판단 | 가능 | 불가능 | 기본적으로 불가능 |
| 장기 실행 | 가능 | 서버 실행 불가 | 작업이 끝나면 종료 |
| 대화 기능 | CLI·웹·메신저 지원 | 직접 구현해야 함 | 사용자 대화용이 아님 |
| 터미널 실행 | 가능 | 불가능 | 워크플로 실행 중 가능 |
| 파일 수정 | 가능 | 불가능 | 저장소 파일 처리 가능 |
| Docker 실행 | 가능 | 불가능 | 작업 중 일시적으로 가능 |
| 영구 메모리 | 세션·메모리 지원 | 없음 | 실행기 상태는 보통 임시 |
| 스케줄 실행 | cron·자동화 지원 | 없음 | 예약 워크플로 가능 |
| 외부 메시징 | Telegram·Slack 등 | 없음 | 별도 API 연동 필요 |
| 서버 관리 | 가능하지만 권한 통제 필요 | 불가능 | 배포 자동화에 적합 |
| 대표 사용처 | AI 비서·봇·운영 에이전트 | 블로그·문서·소개 사이트 | 테스트·빌드·정적 사이트 배포 |
5. Codex 와의 조합
| 구분 | Codex + Hermes Agent | Codex + GitHub Actions |
|---|---|---|
| 기본 성격 | AI 에이전트 협업 | AI가 포함된 CI/CD 파이프라인 |
| 실행 계기 | 자연어 요청, 메시지, 일정, 이벤트 | Push, PR, Issue, 스케줄, 수동 실행 |
| 작업 방식 | 상황을 판단해 실행 순서를 결정 | YAML에 정의된 순서대로 실행 |
| 사용자 인터페이스 | CLI, 웹 대시보드, Telegram·Slack 등 | GitHub PR, Actions 화면, 로그 |
| 장기 실행 | 서버에서 상시 실행 가능 | 워크플로 단위로 실행 후 종료 |
| 대화 연속성 | 세션·메모리·성격 유지 가능 | 실행마다 새로운 작업 환경이 일반적 |
| 예외 대응 | 원인을 조사하고 다른 방법을 시도할 수 있음 | 사전에 작성한 조건과 재시도 정책에 의존 |
| 코드 실행 환경 | 로컬, Docker, SSH, 클라우드 샌드박스 | GitHub-hosted 또는 self-hosted runner |
| 배포 자동화 | 가능하지만 별도 도구와 권한 설정 필요 | 핵심 용도 |
| 결과 검증 | 에이전트 판단과 명령 실행 | 테스트·린트·빌드 결과로 검증 |
| 재현성 | 요청과 에이전트 판단에 따라 달라질 수 있음 | 동일 워크플로로 재현하기 쉬움 |
| 보안 통제 | 에이전트 도구 권한을 세밀하게 제한해야 함 | 저장소 권한, Secrets, Environment로 관리 |
| 운영 부담 | Hermes 서버와 상태 데이터 운영 필요 | GitHub가 실행 인프라를 제공 |
| 대표 용도 | AI 비서, 조사, 운영, 복합 작업 | PR 검토, 테스트, 빌드, Pages 배포 |
6. Codex 와 Hermes Agent 결합
예를 들어, 사용자가 “내 블로그의 최근 배포 실패 원인을 조사하고 수정 계획을 알려줘.”라고 요청한다면, Hermes는 다음과 같이 동적으로 행동할 수 있다.
- GitHub 저장소와 배포 상태를 확인한다.
- 로그를 조사한다.
- 코드 문제라면 Codex에 분석이나 수정을 맡긴다.
- 테스트를 실행한다.
- 필요하면 사용자에게 승인을 요청한다.
- 결과를 기억하거나 메신저로 전달한다.
6-1. 장점
- 자연어로 복잡한 목표를 전달할 수 있다.
- 여러 단계의 조사와 실행을 연결하기 쉽다.
- 이전 대화와 작업 상태를 기억할 수 있다.
- 서버 운영, 자료 조사, 콘텐츠 작성 등 코드 밖의 작업도 처리할 수 있다.
- Telegram이나 Slack에서 원격으로 지시할 수 있다.
6-2. 단점
- Hermes를 실행할 Ubuntu·Docker 서버가 필요하다.
- 에이전트가 사용할 명령과 파일 권한을 제한해야 한다.
- 모델 호출 비용과 서버 운영 비용이 발생한다.
- AI의 동적 판단 때문에 실행 결과의 재현성이 상대적으로 낮다.
- 저장소 쓰기, 배포, 서버 명령은 승인 절차가 필요하다.
7.Codex와 GitHub Actions 결합
예를 들어, PR이 생성될 때 다음 작업을 수행하도록 정의할 수 있습니다.
- 저장소를 체크아웃한다.
- 의존성을 설치한다.
- Codex로 변경 사항을 분석한다.
- 테스트와 링크 검사를 실행한다.
- 결과를 PR 댓글이나 Actions 로그로 남긴다.
- 승인된 변경을 GitHub Pages에 배포한다.
7-1. 장점
- Push, PR, 배포 이벤트와 자연스럽게 연결된다.
- 동일한 YAML과 입력으로 반복 실행하기 쉽다.
- 테스트·빌드·배포 성공 여부가 명확하다.
- 별도의 상시 Hermes 서버가 필요하지 않다.
- GitHub Secrets와 Environment 승인 규칙을 사용할 수 있다.
- synabreu.github.io 와 같은 웹사이트에 배포 자동화에 적합하다.
7-2. 단점
- 대화형 AI 비서처럼 계속 대화하기 어렵다.
- 워크플로가 끝나면 실행 환경도 종료된다.
- 장기 메모리와 지속적인 에이전트 상태가 없다.
- 예상하지 못한 문제에 대응하려면 워크플로를 수정해야 한다.
- 복잡한 운영 작업에는 self-hosted runner나 외부 서버가 필요할 수 있다.
댓글남기기