[발표자료 다운로드] Hermes Agent 소개 — 구조, 기능, 도입 로드맵

Hermes Agent는 경험에서 스킬과 기억을 키우는 에이전트 실행 기반이다. 범용 상담역이 아니라 좁은 업무 하나에서 오래 돌며 판단을 쌓도록 설계됐다.

전체 121장, PDF로 121쪽이다. 여덟 파트는 스물두 편으로 나뉜다. 앞의 네 파트는 Hermes의 구조와 기능을, 뒤의 네 파트는 로컬 LLM 구성, 제품 비교, 사례, 보안과 도입 순서를 다룬다.

Profile이 샌드박스가 아니라는 점, 실패 알림이 묻히는 설정처럼 도입 뒤에 드러나는 부담도 같은 비중으로 담았다.

사내 검토 자료나 팀 스터디 자료로 바로 쓸 수 있도록 121쪽 원본 구성 그대로 PDF로 공개한다.

발표자료의 셋째 파트와 여덟째 파트는 Hermes가 무엇으로 나뉘고 기업이 요구하는 기능을 어디까지 채우는지를 다룬다.

아래 영상은 설치 전제에서 출발해 여덟 가지 기능 요구 대조표까지 Hermes Agent의 구성 요소를 짧게 설명한다.

영상에서 다루는 순서는 다음과 같다.

• 설치 전제 세 가지와 공개되지 않은 정량 사양
• 고정된 코어와 교체 가능한 모델, 채널, 검색 백엔드
• 여덟 가지 기능 요구 가운데 근거가 없는 한 항목

AI 에이전트의 정의를 먼저 정리하려면 AI 에이전트란 무엇인가를 함께 보면 된다.

Hermes Agent 도입을 검토하는 조직에서 반복해서 나오는 질문을 기준으로 슬라이드를 배치했다.

1. Hermes Agent는 일반 챗봇이나 다른 에이전트와 무엇이 다른가
2. Hermes는 어떻게 쓸수록 업무에 맞게 정교해지는가
3. 여러 업무 에이전트는 어떻게 나눠 운영하는가
4. 사내망 안에서 로컬 LLM으로 돌릴 수 있는가
5. 다른 오픈소스 에이전트와는 어떻게 함께 쓰는가
6. 보안 기능은 어디까지 제품이 맡는가
7. 도입은 어떤 순서와 기준으로 진행하는가

챗봇은 요청 하나에 응답 하나로 끝나고 다음 단계는 사람이 정한다. 에이전트는 목표를 받아 도구 선택과 중단 시점까지 스스로 판단한다. 그래서 에이전트의 출력은 파일 변경, 외부 호출, 메시지 발송처럼 시스템에 이미 남은 상태다.

잘못된 판단이 실행된 뒤에 발견된다는 점이 핵심 차이다. 에이전트를 권한을 가진 자동화로 보고 가드레일을 함께 설계해야 하는 이유다.

에이전트 설계와 운영 전반의 판단 기준은 AI Agent 업무 적용 판단 기준 발표자료에 따로 정리했다.

▲ 에이전트는 파일 변경, 외부 호출, 메시지 발송처럼 시스템에 남는 실행을 함 (발표자료 5쪽)

Hermes Agent는 Nous Research가 공개한 오픈소스 자율 AI 에이전트로, 쓸수록 자기 업무에 맞게 정교해지는 것을 목표로 한다. 서버나 사내 장비에 24시간 상주하며 자기 개선 루프를 이어 간다.

2026년 3월 첫 릴리스 뒤 10월 23일 v0.22.5까지 44회 릴리스를 냈고, 10월 31일 기준 GitHub 스타는 약 25만 9천 개다. 추론 제공자 43개와 메시징 플랫폼 20개 이상을 지원한다. 라이선스는 MIT라 수정본 비공개와 상업 이용이 모두 허용되지만, 변화가 빠른 만큼 업그레이드 전 검증 부담도 커진다.

릴리스 간격이 열흘 안팎이라 몇 달 뒤에는 기능 범위가 달라져 있을 수 있다. 기능을 인용할 때는 확인한 버전과 날짜를 함께 적어 두는 편이 안전하다.

▲ Hermes Agent 의 가치는 첫날 성능보다 운영 기간에 비례해 커짐 (발표자료 14쪽)

Hermes 설계의 첫 축은 자기 진화다. 한 번 성공한 절차를 Markdown 파일(SKILL.md)로 남기고 같은 상황이 오면 탐색 없이 재사용한다. 학습 비용은 첫 실행 한 번이고 효과는 운영 기간 내내 쌓인다.

둘째 축은 메모리다. 모든 세션은 SQLite에 저장돼 약 20ms 안에 검색되고, 프롬프트에는 MEMORY.md와 USER.md를 합쳐 약 3,600자만 싣는다. 24시간 상주해도 매 회차 문맥 비용이 늘지 않는다. 나머지 두 축은 바뀌지 않는 규칙을 앞에 두어 캐시를 살리는 프롬프트 배치와, 모델과 채널과 실행 위치를 고르는 선택의 자유다.

▲ 대화는 모두 SQLite 에 남고 프롬프트에는 작은 메모리만 실림 (발표자료 20쪽)

Hermes 구조의 출발점은 판단과 실행의 분리다. LLM은 어떤 도구를 어떤 인자로 부를지, 알릴 만한 변화인지를 결정만 한다. Hermes는 데이터 조회, 통지 송신, 루프 유지, 이력 저장을 수행만 한다.

경계가 분명하면 더 나은 모델이 나왔을 때 판단 쪽만 바꾸면 되고, 도구 실패의 원인은 실행 쪽에서 찾으면 된다. 다만 모델을 바꾼 직후 첫 요청은 프롬프트 캐시가 초기화돼 비용이 한 번 늘어난다.

▲ LLM 은 판단만, Hermes 는 실행만 맡아 모델을 바꿔도 루프와 도구 코드가 유지됨 (발표자료 25쪽)

SOUL.md는 에이전트가 어떻게 말할지를 정하는 인격 파일이다. 호칭, 어조, 금지 사항을 사람이 직접 편집한다. skills 파일은 무엇을 전할지를 담는 지식으로, 에이전트가 스스로 만들고 갱신한다. 도입 직후 1~2개였던 파일이 수 개월 뒤 20개 이상으로 늘어난다.

둘을 나눠 두면 학습이 쌓여도 말투와 금지 사항이 바뀌는 사고를 구조로 막는다. 사람이 읽고 고칠 수 있어 인수인계 문서 역할도 한다.

▲ 인격은 사람이 관리하는 고정값이고 지식은 에이전트가 갱신함 (발표자료 27쪽)

Gateway는 Slack, Microsoft Teams, Telegram 등 20개 이상 메시징 플랫폼을 백그라운드 프로세스 하나로 연결한다. 사용자 식별, 세션 연결, Profile 라우팅, 예약 작업 실행이 모두 여기서 일어난다. 직원은 새 콘솔을 배우지 않고 평소 쓰던 대화창에 요청한다.

허용 목록과 DM 페어링 밖의 사용자는 기본 거부된다. 페어링 코드는 8자이고 1시간 뒤 만료되며, 5회 연속 실패하면 1시간 잠긴다. 채널을 하나 여는 일은 접근 경로를 하나 여는 일과 같다.

▲ 요청 입구, 세션, 예약 실행이 Gateway 프로세스 하나로 모임 (발표자료 30쪽)

Profile은 독립된 Hermes 홈 디렉터리다. 설정, 비밀 값, 메모리, 스킬, 예약 작업, 세션 기록, 메신저 봇을 따로 갖는다. 역할을 가르는 것은 역할 문서, MCP 연결, 예약 작업 세 가지다.

다만 같은 컨테이너의 Profile은 서로의 파일과 공용 비밀에 닿을 수 있다. 완전한 격리가 필요한 역할은 컨테이너와 비밀을 따로 둬야 한다.

에이전트를 따로 저장하는 레지스트리는 없다. 에이전트는 Profile 아래에서 잠깐 도는 실행 인스턴스이므로, 옮기고 백업하는 대상은 언제나 Profile이다. 역할별 팀 구성은 Agentic AI 멀티에이전트 프로필과 역할 기반 팀 구성에서 함께 볼 수 있다.

▲ 같은 컨테이너의 Profile 은 서로의 파일과 비밀에 닿을 수 있음 (발표자료 37쪽)

Kanban은 Profile 사이에 일을 넘기는 기본 경로다. 카드는 triage부터 archived까지 여덟 상태를 오가고, 기록은 SQLite 파일 하나에 남는다.

선행 작업만 선언하면 순서는 자동으로 이어진다. 영업 Profile의 카드가 done이 되면 견적 Profile의 카드가 ready로 바뀌고, 디스패처가 60초마다 담당 Profile을 깨운다. 인계마다 사람이 보고 고칠 수 있는 기록이 남는 점이 함수 호출식 위임과 다르다.

언제 할지가 정해진 일은 Cron, 누가 이어받을지가 정해진 일은 Kanban이 맡는다. Kanban 작업에 목표를 주지 않으면 한 턴만 실행된다.

▲ 앞 작업이 done 이 되면 다음 작업이 ready 로 바뀌어 담당 Profile 이 이어받음 (발표자료 39쪽)

Hermes Skill은 세 단계로 로딩된다. 평소에는 목록(약 3천 토큰)만 싣고, 작업이 설명과 맞을 때 SKILL.md 본문을, 절차가 요구할 때 참고 파일을 연다. 절차를 계속 쌓아도 실행 부담이 함께 늘지 않는다.

그래서 설명 한 줄의 품질이 맞는 스킬을 고르는 정확도를 좌우한다. 스킬은 약 10턴마다 도는 백그라운드 리뷰가 만들고, Curator가 7일마다 30일 미사용 스킬을 archive로 옮긴다. 자동 삭제는 하지 않아 언제든 되돌릴 수 있다.

▲ 평소에는 스킬 목록만 싣고 본문과 참고 파일은 필요할 때만 실음 (발표자료 41쪽)

Hermes는 두 표준의 클라이언트로만 동작한다. 모델은 LiteLLM Proxy의 OpenAI 호환 주소 하나로 부르고, 위키나 CRM 같은 도구는 MCP 서버로 붙인다. 포함과 제외 목록으로 쓸 수 있는 도구를 좁힌다.

통로가 하나면 통제 지점도 하나다. 예산과 호출 한도, 모델 접근 제한, 장애 시 폴백을 LiteLLM Proxy가 맡는다. 웹 검색 백엔드는 지정하지 않으면 등록된 API 키를 보고 자동으로 골라지므로 따로 점검해야 한다.

▲ 모델은 LiteLLM 으로, 도구는 MCP 로 나눠 Hermes 는 두 표준의 클라이언트로만 동작함 (발표자료 59쪽)

기밀 데이터와 상한 없는 종량 과금 때문에 클라우드 LLM을 못 쓰는 업무가 있다. 로컬 LLM은 그런 업무에 한정할 때 효과가 가장 크다. Ollama와 vLLM이 OpenAI 호환 API를 제공하므로 주소만 바꾸면 된다.

Hermes는 컨텍스트 65,536 토큰 미만 모델을 시작 단계에서 거부한다. Ollama 기본 컨텍스트는 작아 늘려야 하고, Qwen3 4B 이하는 32K라 조건에 못 미친다. GPU 메모리는 4bit 기준 10억 파라미터당 약 0.6~0.7GB로 어림하고 가중치의 1.2배를 하한으로 잡는다. Gemma 4 26B MoE는 추론 때 3.8B만 써서 소비자 GPU 한 대로 상주 에이전트를 돌리는 후보가 된다.

Hermes 본체와 로컬 LLM, LiteLLM 프록시 세 구성 요소가 모두 사내망 경계 안에 있으면 사용자 요청은 경계를 벗어나지 않고 추론 결과까지 돌아온다.

▲ 컨텍스트 64K 미만 모델은 Hermes 시작 단계에서 거부됨 (발표자료 72쪽)

OpenClaw는 채널과 도구를 넓게 잇는 개인 비서이고, Hermes는 특정 업무의 판단을 오래 키우는 에이전트다. Paperclip은 기존 에이전트를 조직도와 예산으로 묶는 오케스트레이션 계층이며 Hermes를 직원으로 등록하는 어댑터를 지원한다.

나란히 놓으면 Hermes의 차이는 학습 루프와 지속 기억을 함께 내장했다는 점이다.

선택 기준은 반복성, 데이터 민감도, 성장 필요성이다. 대부분의 조직은 매일 부르는 손발형과 오래 키우는 두뇌형을 함께 배치한다.

Paperclip의 조직도와 예산 통제 방식은 Paperclip 실무 도입 가이드에서 자세히 다룬다.

▲ 학습 루프와 지속 기억을 함께 내장한 점이 Hermes 의 차이임 (발표자료 76쪽)

MSAP.ai는 2026년 6월부터 사내에서 Hermes를 운영한다. 컨테이너 하나에 Profile 12개와 상시 Gateway 9개를 두고, 모든 Profile이 LiteLLM을 거쳐 사내 GPU의 27B 모델 하나를 공유한다. 10월 31일 기준 누적 세션 3,614건, 활성 예약 작업 71건, 공용 스킬 137개다.

운영에서 확인한 주의점도 있다. Profile은 루트 설정을 물려받지 않고, 전달 대상이 파일인 예약 작업은 실패해도 알림이 가지 않는다. 시험용 Profile에서는 모델이 dry-run 설정을 스스로 바꿔 실제 문서를 덮어쓴 일도 있었다. 시험 격리는 설정값이 아니라 파일 위치와 접근 권한으로 막아야 한다.

이 운영 경험을 바탕으로 업무 담당자가 Hermes 에이전트를 직접 만들고 실행 상태를 살피는 콘솔을 AI Agent Studio(AAS)로 정리했다.

▲ 사내 Profile 12개가 LiteLLM 을 거쳐 사내 27B 모델 하나를 공유함 (발표자료 94쪽)

OWASP Agentic Top 10을 실행 단계로 묶으면 에이전트에 요구할 기능이 여덟 가지로 정리된다. Hermes는 절차 기억, 채널 통합, 무인 실행, 실행 격리, 데이터 처리 위치 공개, 권한 분리, 위험 명령 승인 일곱 가지를 공식 기능으로 제공한다.

비어 있는 하나가 실행 결과 검증이다. 기본값인 smart 승인 모드는 보조 LLM이 위험도를 판단해 애매한 명령만 사람에게 넘기고, 300초 안에 응답이 없으면 거부한다. 하지만 명령은 안전한데 내용이 틀린 보고서는 이 게이트를 통과한다. 결과 확인 절차는 조직이 설계하고, 스킬 쓰기 승인을 켜 잘못된 절차가 굳는 일을 막는다.

▲ 여덟 기능 요구 가운데 실행 결과 검증만 제품이 제공하지 않음 (발표자료 103쪽)

먼저 권한 허용 목록, 승인 대상 행위, 감사 로그 항목을 정해 경계를 설계한다. 다음으로 업무 하나와 채널 하나로 자율 루프를 돌리며 스킬이 자라는 모습을 관찰한다. 마지막으로 축적된 스킬을 사람이 검증한 뒤 인접 업무로 넓힌다.

게이트 KPI가 있으면 확대 여부를 측정값으로 정할 수 있다.

도입 단계별 준비 사항과 비용 변화는 AI Agent 도입 로드맵에서 함께 볼 수 있다.

▲ PoC 4주, 파일럿 3개월, 본격 운영의 게이트 KPI 가 다음 단계의 근거가 됨 (발표자료 117쪽)

Hermes Agent는 오래 운영할수록 업무에 맞게 자라는 에이전트다. 판단과 실행을 나누고, 절차는 스킬로, 사실은 작은 메모리로 남기며, Gateway와 Profile과 Kanban으로 역할별 에이전트를 운영한다. 실행 결과 검증은 제품 밖에 있으므로 결과 확인 절차를 조직이 갖춰야 한다.

검토를 시작한다면 다음 순서를 권한다.

1. 권한 허용 목록, 승인 대상 행위, 감사 로그 항목을 먼저 정해야 한다.
2. 위험이 낮은 업무 하나와 채널 하나로 PoC 범위를 좁혀야 한다.
3. 로컬 모델은 컨텍스트 64K 이상 후보를 업무 과제로 비교해야 한다.
4. 완전 격리가 필요한 역할은 컨테이너 단위로 나눠야 한다.
5. 스킬 쓰기 승인을 켠 뒤 축적된 스킬을 읽고 범위를 넓혀야 한다.

Hermes Agent는 어떤 에이전트인가

Nous Research가 MIT 라이선스로 공개한 자기 개선형 오픈소스 AI 에이전트다. 성공한 절차를 스킬 파일로 남겨 쓸수록 자기 업무에 맞게 정교해진다.

Hermes Agent의 메모리와 스킬은 무엇이 다른가

메모리에는 사실을, 스킬에는 절차를 둔다. 메모리는 약 3,600자로 작고 세션 시작 때 실리며, 스킬은 목록만 싣고 본문은 필요할 때 연다.

Profile만으로 업무 에이전트를 완전히 격리할 수 있는가

없다. 같은 컨테이너의 Profile은 파일 시스템과 공용 비밀 파일에 서로 닿을 수 있어, 완전한 격리가 필요하면 컨테이너를 나눠야 한다.

Hermes Agent를 로컬 LLM으로 사내망 안에서 돌릴 수 있는가

있다. LiteLLM Proxy로 로컬 모델을 연결하면 모델 호출 경로가 사내망 안에 머문다. 컨텍스트 64K 미만 모델은 거부되고, 웹 검색 경로는 따로 확인해야 한다.

Hermes Agent와 OpenClaw는 어떻게 다른가

OpenClaw는 채널과 도구를 넓게 잇는 개인 비서이고, Hermes는 특정 업무의 판단을 오래 키운다. 대체재보다 함께 배치하는 보완재로 쓰는 경우가 많다.

Hermes Agent의 보안 기능은 어디까지인가

사용자 인가, 위험 명령 승인, 컨테이너 격리 등 8계층을 공식 기능으로 둔다. 실행 결과가 맞는지 확인하는 기능은 없어 도입 조직이 절차를 설계해야 한다.

Hermes Agent 도입은 어떤 순서로 진행하는가

경계 설계, 좁은 파일럿, 확대 세 단계다. 4주 PoC의 게이트 KPI를 넘으면 3~5개 부서 파일럿으로 넓힌다.

MSAP.ai 자료

• AI 에이전트란 무엇인가
• Hermes Agent 도입 점검 기준과 보안 지침
• AI Agent 필수 기능 여덟 가지
• 오픈소스 Hermes 에이전트와 Gemma 4 도입 가이드
• 에이전트 런타임 구조 분석
• 에이전트 컨테이너 격리 검증 항목
• OWASP 위험 분류와 에이전트 필수 기능
• LiteLLM 제품 소개

외부 공개 자료

• Hermes Agent GitHub 저장소
• Hermes Agent 공식 문서
• Agent Skills 공개 명세

챗봇과 에이전트 비교부터 Hermes 설계의 네 축, Gateway와 Profile과 Kanban, 로컬 LLM 연결 조건, 사내 운영 지표, 보안과 도입 로드맵까지 여덟 파트 전체가 PDF 한 파일에 들어 있다. 아래 버튼에서 같은 121쪽 PDF를 다시 내려받을 수 있다.