Hermes Agent는 Nous Research의 오픈 소스 (MIT) 자율 에이전트 런타임 (runtime)입니다. 이는 재시작 후에도 기억을 유지하고, 스스로 기술을 작성 및 재사용하며, 자신의 작업을 스케줄링하고, 샌드박스화된 터미널 (terminal) 및 파일 시스템 (file system)을 통해 동작하는 셀프 호스팅 (self-hosted) 방식의 상시 가동 데몬 (daemon)입니다. 이것은 언어 모델 (language model)도 아니고 챗봇 (chatbot)도 아닙니다. 본질적으로 위험한 것은 아니지만, 무심코 배포할 경우 위험성이 높습니다. 터미널, 파일, 메시징에 지속적으로 접근할 수 있는 자율 프로세스는 폭발 반경 (blast radius)이 매우 크기 때문입니다. 이를 안전하게 실행하려면 최소 권한 원칙 (least-privilege access), 되돌릴 수 없는 작업에 대한 인간의 승인 게이트 (human approval gates), 강화된 샌드박스 (hardened sandbox), 관리되는 비밀 정보 (managed secrets), 그리고 완전한 관찰 가능성 (full observability)이 필요합니다. 설치는 오후 한때면 끝나지만, 안전하게 운영하는 것이 진짜 과업입니다.

오픈 웨이트 (open-weight) Hermes 언어 모델의 개발팀인 Nous Research는 이전과는 다른 것을 출시했습니다. 바로 여러분의 기기에서 직접 실행할 수 있는 오픈 소스 (MIT) 자율 에이전트인 Hermes Agent입니다. 이것은 모델도 아니고 챗봇도 아닙니다. 이것은 깨어나서 학습한 내용을 기억하고, 도구를 선택하며, 여러분이 자리를 비운 사이 업무를 수행하는 장기 실행 에이전트 런타임 (agent runtime)입니다.

이는 흥미로운 일이지만, 동시에 많은 팀이 피해를 입을 수 있는 지점이기도 합니다. 파일을 읽고, 터미널 명령을 실행하며, 메시지를 보내고, 새벽 3시에 스스로 작업을 스케줄링할 수 있는 에이전트는 바로 그 폭발 반경 (blast radius)이 크기 때문에 강력한 것입니다. 이 글에서는 Hermes Agent가 실제로 무엇인지 설명하고, 혼동하기 쉬운 Hermes 모델들과 구분하며, OpenClaw 및 에이전트 프레임워크 (agent frameworks) 사이에서 어떤 위치를 차지하는지 보여줍니다. 또한, 스크립트에 시스템에 대한 광범위한 권한을 부여하고 요행을 바는 대신, 자율 에이전트를 프로덕션 (production) 환경에 배치하기 위해 우리가 사용하는 참조 아키텍처 (reference architecture)를 살펴봅니다. 만약 이것이 실제 구축에 어떻게 적용될지 고민 중이라면, 이는 우리가 매일 수행하는 AI 에이전트 개발 (AI agent development) 작업의 핵심 영역에 정확히 위치합니다.

Hermes Agent는 안전한가?

Hermes Agent는 안전한가?

Hermes Agent가 프로덕션 환경에서 안전하려면 런타임이 제공하지 않는 제어 장치를 추가해야 합니다. 지속적인 터미널, 파일 및 메시징 접근 권한을 가지고 있기 때문에 최소 권한(least-privilege) 설정, 되돌릴 수 없는 작업에 대한 인간 승인, 강화된 샌드박스(hardened sandbox), 관리되는 비밀 정보(managed secrets), 그리고 전체 감사 로깅(full audit logging)이 필요합니다. 아무렇게나 설치하면 위험도가 높습니다.

그것이 바로 이 가이드가 존재하는 이유입니다. 런타임 자체는 정말 유용하지만, 그 안전성은 도구의 속성이 아니라 배포하는 방식의 속성입니다. 본문의 나머지 부분에서는 위험이 정확히 어디에 존재하며, 그것을 담고 있는 계층적 아키텍처를 자세히 설명합니다.

먼저, 명칭을 정리합시다

Nous Research는 'Hermes'라는 단어를 두 가지 다른 것에 사용하며, 이 둘을 혼동하는 것이 우리가 보는 가장 흔한 실수입니다.

• **Hermes 모델 (Hermes 3, Hermes 4)**은 오픈 웨이트(open-weight) 언어 모델입니다. 이것들은 에이전트가 아닙니다. 에이전트는 빠르고 반복적인 도구 호출을 위해 조정된 에이전틱 모델(agentic model) 위에서 실행되며, 이는 장문 추론과는 다른 작업입니다.

• Hermes Agent는 별도의 공식 오픈 소스 프로젝트입니다: 에이전틱 모델을 구동하는 자체 호스팅 자율 에이전트 런타임(self-hosted autonomous agent runtime)입니다. 이 글은 그 에이전트 런타임에 관한 것입니다.

만약 자율 작업에 대해 Hermes를 평가하고 있다면, 모델 가중치(model weights)가 아니라 Nous Research의 공식 GitHub에 있는 에이전트 런타임을 원해야 합니다. 그리고 이름 주변에 생겨난 유사 도메인들은 무시하십시오. 실제 프로젝트는 Nous Research 자체의 GitHub와 문서에서 운영됩니다.

Hermes Agent가 실제로 하는 일

Hermes Agent는 사용자가 직접 호스팅하는 24/7 데몬(daemon)입니다. 몇 가지 기능들이 일반적인 스크립트형 봇과 차별화되므로, 각 기능이 어떻게 작동하는지 이해할 가치가 있습니다. 왜냐하면 각각의 기능 역시 여러분이 운영해야 하는 것이기 때문입니다.

• 지속적이고 검색 가능한 메모리 (Persistent, searchable memory): 재시작 후에도 내용을 기억합니다. 세션이 저장되고 전체 텍스트 검색이 가능하며, 세션 전반에 걸쳐 요약된 회상 (summarized recall) 기능을 제공하므로, 에이전트가 매 실행마다 처음부터 시작하는 대신 관련 컨텍스트를 다시 구축합니다. 실제로 기능 팀들이 가장 먼저 반응하는 기능이기도 한데, 호출될 때마다 모든 것을 다시 학습해야 하는 상태 비저장 (stateless) 에이전트는 다루기가 매우 힘들기 때문입니다. 또한 이는 여러분이 관리해야 하는 기능이기도 합니다. 에이전트가 스스로 큐레이션하는 메모리는 편향 (drift)될 수 있습니다.

• 자기 개선 기술 (Self-improving skills): 문제를 해결하면서 재사용 가능한 기술 (agentskills.io 오픈 표준과 호환됨)을 작성하고 나중에 이를 검색하며, 이러한 기술은 사용함에 따라 개선됩니다. 시간이 지남에 따라 에이전트는 귀하의 환경에 특화된 '방법론 (how-tos)'에 대한 개인 라이브러리를 구축합니다. 장점은 역량이 복리로 쌓인다는 것이지만, 주의할 점은 기술이 에이전트가 작성한 텍스트일 뿐이라는 것입니다. 따라서 잘못된 교훈이 누군가 검토하기 전까지 자신 있게 반복 적용될 수 있습니다.

• 하위 에이전트 (Sub-agents) 및 내장 스케줄러 (built-in scheduler): 집중적이고 병렬적인 작업을 위해 격리된 하위 에이전트를 생성할 수 있으며, cron 스케줄러를 갖추고 있어 프롬프트가 있을 때뿐만 아니라 정해진 시간표에 따라 무인 작업 (unattended jobs)을 실행할 수 있습니다. 이것이 바로 에이전트를 단순히 호출하는 도구에서 귀하의 운영을 수행하는 작업자 (worker)로 변화시키는 지점입니다.

• 샌드박스화된 머신 액세스 (Sandboxed machine access): 컨테이너 강화 (container hardening) 기술을 적용한 다양한 샌드박스 백엔드를 통해 실제 터미널과 파일 시스템을 사용할 수 있습니다. 범위가 중요합니다. "로컬 (local)"은 편리하지만 위험하며, Docker 또는 원격 백엔드가 프로덕션 작업에 적합한 환경입니다.

• 모델 불가지론적 (Model-agnostic) 및 프라이버시 보호: 코드 변경 없이 다양한 제공업체 (OpenRouter, NVIDIA NIM, OpenAI, Nous Portal 또는 로컬 모델 서버를 포함한 자체 엔드포인트)와 함께 작동하며, 데이터가 귀하의 기기에 머물 수 있도록 로컬에서 실행되도록 설계되었습니다. 규제 대상 팀에게는 "데이터가 인프라를 벗어나지 않는다"는 특성이 이 솔루션을 검토해야 하는 결정적인 이유가 되곤 합니다.

이 모든 것을 종합하면 그것이 바로 매력 포인트입니다. 즉, 항상 작동하며(always-on), 스스로 학습하고, 자체 인프라에서 실행되며, 데이터를 내부(in-house)에 유지하고, 특정 모델 벤더에 종속되지 않는 에이전트입니다.

Hermes Agent의 위치: 런타임(runtimes) vs 프레임워크(frameworks)

가장 먼저 명확히 짚고 넘어가야 할 가장 유용한 점은 카테고리입니다. Hermes Agent는 여러분이 구축하는 라이브러리(library)가 아니라, 여러분이 운영하는 런타임(runtime)입니다. 이는 LangGraph와 CrewAI 사이에서 무엇을 선택할지 고민하는 것과는 다른 차원의 결정이며, 아래 표가 이를 가장 빠르게 확인할 수 있는 방법입니다.

Hermes Agent vs other frameworks

Hermes Agent를 실행하는 데 필요한 사항

흔히 던지는 첫 번째 질문은 Hermes Agent가 얼마나 많은 하드웨어를 필요로 하는가입니다. 솔직한 답변은 런타임(runtime)은 가볍다는 것입니다. 비용은 거의 항상 에이전트가 아니라 에이전트가 구동하는 모델에서 발생합니다.

• 런타임은 경량 데몬(lightweight daemon)입니다: Hermes Agent는 메모리(memory)와 기술(skills)을 위한 저장소를 포함한 장기 실행 프로세스(long-running process)입니다. 그 자체로는 GPU나 무거운 서버가 필요하지 않으며, 에이전트, 스케줄러(scheduler), 세션 저장소(session store)를 계속 실행하기에는 적당한 수준의 상시 가동 Linux 호스트면 충분합니다.

• 모델이 실제 요구 사항입니다: Hermes Agent는 모델 불가지론적(model-agnostic)이기 때문에, 모델이 어디에서 실행되느냐가 하드웨어를 결정합니다. 호스팅된 API(OpenRouter, OpenAI 또는 Nous Portal)를 사용하면 로컬 점유율(local footprint)을 작게 유지할 수 있습니다. 개인정보 보호나 데이터 거주성(data residency)을 위해 모델을 직접 실행하려면 GPU 용량이 필요하며, 이 경우 Modal, NVIDIA NIM 또는 RunPod과 같은 GPU 호스트가 대안이 됩니다.

• 실행 백엔드(execution backend)를 실행 위치에 맞추세요: Hermes Agent는 로컬(local), Docker, SSH, Singularity, Modal, Daytona와 같은 여러 샌드박스(sandbox) 백엔드를 통해 작동할 수 있습니다. 로컬은 자신의 컴퓨터에서 빠르게 살펴보기에는 좋지만, 실제 환경에서는 에이전트의 터미널 및 파일 접근이 격리될 수 있도록 컨테이너(container)나 원격 백엔드(remote backend)를 사용해야 합니다.

• 지속 가능한 저장소(persistent storage) 계획: 메모리(Memory)와 직접 작성한 기술(skills)이 축적되므로, 재시작 후에도 유지되는 내구성이 있는 저장소가 필요합니다. 또한, 에이전트가 보관한 내용을 검사하고 롤백(roll back)할 수 있도록 백업 및 검토 경로가 마련되어야 합니다.

에이전트를 호스팅하는 것은 어려운 부분이 아닙니다. 모델의 크기(Sizing)를 결정하고, 백엔드(backend)를 격리하며, 메모리 저장소를 내구성이 있고 검토 가능한 상태로 유지하는 것이 실제 배포(deployment) 계획에서 고려해야 할 핵심 사항입니다.

Hermes Agent 활용 사례

Hermes Agent는 사용자가 제어하는 인프라 상에서 장시간 실행되는 무인 작업(unattended work)에 적합합니다:

• 예약된 운영 작업 (Scheduled operational jobs): 내장된 cron 스케줄러(scheduler)를 통해 보고서 생성, 동기화(syncs), 모니터링 등을 실행할 수 있습니다.

• 다단계 연구 및 데이터 작업 (Multi-step research and data tasks): 세션 간 지속되는 메모리(Persistent memory) 덕분에 에이전트가 컨텍스트(context)를 처음부터 다시 구축할 필요 없이 작업을 계속할 수 있습니다.

• 환경 및 DevOps 자동화 (Environment and DevOps automation): 작업에 실제 머신 접근이 필요한 경우, 에이전트는 샌드박스화된 터미널(sandboxed terminal)을 통해 작업할 수 있습니다.

• 복합 워크플로 (Compounding workflows): 직접 작성한 기술(Self-written skills)이 검토되고 관리될 때, 반복되는 작업을 시간이 지남에 따라 개선할 수 있습니다.

머신 접근이 필요 없는 단일 제한적 작업(single bounded task)의 경우에는 Hermes Agent가 적합하지 않습니다. 이러한 경우에는 스크립트 기반의 워크플로(scripted workflow)나 LangGraph와 같은 프레임워크(framework)를 사용하는 것이 더 간단하고, 저렴하며, 안전합니다.

프로덕션 환경에서 Hermes Agent가 위험해지는 지점

Hermes Agent를 유용하게 만드는 모든 요소는, 만약 주의 없이 배포할 경우 심각한 보안 및 운영 문제를 일으키는 원인이 되기도 합니다. 이는 가설이 아닙니다. 자율 에이전트(autonomous agent)가 실제 환경에 접촉하기 전에 우리가 방어하도록 설계해야 하는 실패 모드(failure modes)들입니다.

• 폭발 반경 (Blast radius): 터미널, 파일 및 메시징 액세스 권한을 가지고 지속적으로 실행되는 에이전트는 단 한 번의 잘못된 결정으로도 실질적인 피해를 입힐 수 있습니다. 질문은

예산 상한선(budget ceiling)과 루프 탐지(loop detection)가 없다면, 첫 번째 문제의 징후는 청구서로 나타날 수 있습니다.

• 감사 가능성 (Auditability): 에이전트가 몇 시간 동안 스스로 행동할 때, 에이전트가 무엇을, 왜, 어떤 입력값으로 수행했는지에 대한 신뢰할 수 있는 기록이 필요합니다. 추적(tracing)이 없다면, 사고는 해결해야 할 문제가 아니라 미스터리가 되어버립니다.

이 중 어느 것도 Hermes Agent를 피해야 할 이유는 아닙니다. 오히려 배포를 단순한 설치가 아닌 엔지니어링(engineering)으로 다뤄야 하는 이유입니다.

Hermes Agent를 안전하게 실행하기 위한 참조 아키텍처 (reference architecture)

Hermes Agent를 설치하는 것은 오후 한나절이면 충분합니다. 하지만 진정으로 안전하게 실행하는 것은 본격적인 작업입니다. 이것은 Hermes Agent를 포함하여 자율 에이전트(autonomous agents)에 적용하는 계층화된 패턴(layered pattern)입니다. 각 계층은 위 섹션에서 언급된 특정 실패 모드(failure mode)를 억제하기 위해 존재합니다.

Hermes Agent Architecture