올해 2월, Nous Research가 공개한 Hermes Agent는 7주 만에 GitHub 스타 10만 개를 돌파했다. 2026년 5월 기준, OpenRouter에서 하루 2,240억 토큰을 처리하며 가장 활발하게 사용되는 에이전트 프레임워크 중 하나가 됐다.
이 확산 속도의 핵심은 자가개선 메커니즘이다. 5번 이상의 툴 호출이 포함된 작업을 마치면, 에이전트가 그 흐름을 분석해 스킬 파일로 자동 저장한다. 따로 요청하지 않아도 생성되고, 기존 스킬도 새로운 맥락에 맞게 스스로 업데이트된다. 쓰면 쓸수록 그 사람의 방식을 학습한다는 것, 이 경험의 차이가 입소문을 만들었다.
많은 이들이 Hermes Agent를 개인 비서 에이전트로 사용하게 되면서, 다음의 질문이 나타났다. 팀 전체에 도입하면 생산성이 더 향상되지 않을까.
Self-Improving, 강점이 그대로 리스크가 되는 이유
McKinsey의 2025 AI 현황 보고서에 따르면, 에이전틱 AI를 실제 운영 환경으로 확장한 기업은 전체의 23%에 불과하다. 실패 원인은 바로 거버넌스에 있다. 조직이 에이전트를 통제할 수 있는 거버넌스를 갖추지 못한 채 도입했기 때문이다.
스스로 진화하는 에이전트일수록, 이 거버넌스 문제는 더 선명하게 드러난다. 무엇을 통제해야 하는지 자체가 계속 바뀌기 때문이다. Hermes Agent는 개인이 쓸 때 강력하다. 그런데 팀 레이어에 올리는 순간, 이 에이전트의 강점이 그대로 리스크로 바뀐다. Enhans의 어느 한 엔지니어가 Hermes Agent를 직접 운용하면서 도달한 결론이다.
에이전트가 어떻게 바뀔지 예측할 수 없다
Hermes의 자가개선은 대부분 더 나은 방향으로 일어난다. 그런데 "더 낫다"는 기준이 에이전트 자신의 판단이다.
팀 전체가 같은 에이전트를 쓰는 환경에서는, 한 사람의 사용 맥락이 다른 사람의 스킬에 영향을 줄 수 있다. 비개발 직군 팀원이 자동 생성된 스킬의 동작 방식을 이해하지 못한 채 쓰게 된다면, 에이전트가 어떤 방향으로 진화하는지 파악하는 것 자체가 어렵다.
결정적으로, 현재 Hermes Agent는 엔터프라이즈 환경에 적합한 역할 기반 접근 제어(RBAC, Role-Based Access Control)가 탑재되어 있지 않다. Allowlist나 Admin/User 구분 같은 기본적인 접근 제어는 존재한다. 그러나 이는 명령어 수준의 제한에 가깝고, 스킬 생성·메모리 저장·도구 실행 전반을 역할별로 세밀하게 통제하는 엔터프라이즈 RBAC라고 보기는 어렵다.
특히 문제가 되는 것은 자가개선 과정이다. 에이전트가 자동으로 스킬을 만들고 업데이트하는 행위가 팀 레이어에서 추적되지 않는다. 누가 어떤 스킬을 생성했는지, 메모리에 무엇이 언제 저장됐는지 확인할 방법이 없다. 조직 입장에서는 내부에서 무슨 일이 일어나는지 알 수 없는 블랙박스가 된다. 제어되지 않는 변화는 그 자체로 리스크다.
비용을 예측할 수 없다
Hermes의 자가개선 과정은 배경에서 추가 연산을 수행한다. 에이전트가 작업 흐름을 분석하고 스킬을 생성하고 업데이트하는 과정 전체가 토큰을 소비하기 때문이다.
개인이 사용할 때는 이 비용을 직접 체감하면서 조절할 수 있다. 그런데 팀 단위로 배포되면 여러 사람의 사용이 동시에 일어나고, 각 개인의 자가개선 루프가 병렬로 돌아간다. 외부 API 키를 사용하는 환경이라면 비용을 예측하기 어려운 상황이 만들어진다.
비용 예측이 불가능한 인프라는, 예산을 가진 팀 리더에게 도입을 승인받기 어렵다. 토큰 사용량을 극대화하는 방향(Tokenmaxxing)으로 에이전트를 운용했던 여러 조직이 예상치 못한 청구서를 받고 사용을 중단한 이유가 여기에 있다.
감사 추적이 어렵다
에이전트가 어떤 작업을 수행했는지, 어떤 툴을 호출했는지, 그 결과가 어디에 저장됐는지. 이것을 사후에 확인할 수 있는가.
개인 레이어에서는 이 질문이 크게 중요하지 않다. 스스로 쓰고 스스로 확인하면 된다. 그런데 조직 레이어에서는 다르다. 에이전트가 수행한 작업에 대한 감사 로그(audit log)가 없다면, 문제가 생겼을 때 원인 추적이 불가능하다. 누가 어떤 지시를 내렸고, 에이전트가 어떻게 실행했는지 기록이 없다면, 그 에이전트는 조직의 책임 구조 밖에 있는 셈이다.
Hermes와 OpenClaw, 무엇이 더 나은 에이전트인가
이 시점에서 자연스럽게 떠오르는 비교가 있다. Hermes Agent와 OpenClaw다.
두 에이전트 모두 에이전트 생태계에서 함께 거론되는 오픈소스 프레임워크다. 개발자 커뮤니티에서 함께 거론되고, 실제 업무에서도 활발하게 쓰인다. 그래서 "둘 중 무엇을 써야 하나"는 질문이 자연스럽게 나온다.
결론부터 말하면, 하나가 다른 하나보다 낫다고 평가하기 어렵다. 두 에이전트는 설계 철학이 다르고, 최적화된 환경이 다르다. 실제로 Enhans의 엔지니어가 두 에이전트를 모두 사용해 본 결과, 각 에이전트가 적합한 환경은 다음과 같다.
엔터프라이즈 환경에서는 레이어를 나눈다
Enhans의 어느 한 엔지니어 팀은 두 에이전트를 레이어를 달리해 운용하고 있다.
OpenClaw (팀 에이전트): 사내 온보딩 Q&A와 개발·운영 서포트에 활용한다. 조직에서 승인한 내부 운영 가이드와 정책, FAQ를 기반으로 일관된 답변을 제공한다. PM, QA, CS 등 비개발 직군도 자연어로 인프라 상태나 데이터 현황을 질의할 수 있어, 특정 개발자에게 질문이 몰리는 병목을 줄여준다. 예측 가능하고, 변하지 않으며, 접근 권한을 조직이 관리할 수 있다.
Hermes Agent (개인 에이전트): 공용 에이전트로 제공할 필요가 없는 개인 업무에 활용한다. 디버깅 가설 정리, 장애 원인 후보 도출, 개인 작업 로그 관리가 주요 활용 영역이다. Hermes가 문제 상황과 가능성을 정리한 뒤, 발견한 원인을 Codex나 Claude 같은 코드 작성 도구로 넘기는 흐름이 자연스럽게 만들어진다. 스킬이 자동으로 생성되더라도, 엔지니어가 직접 파악하고 이해한 뒤 사용하기 때문에 리스크 없이 활용할 수 있다.
Hermes Agent 팀 도입 전, 확인할 세 가지
에이전트가 스스로 업데이트할 때, 팀 전체가 그 변화를 추적하고 승인할 수 있는가. 자동 생성된 스킬이 어떤 방향으로 진화하는지 비개발 직군도 파악할 수 있어야 한다. 그렇지 않다면, 변화를 감지할 수 없는 상태로 에이전트를 운용하게 된다.
토큰 비용을 예측하고 상한을 설정할 수 있는 환경인가. 자체 모델로 운용하거나, 사용량 상한을 별도로 설정할 수 있는 구조가 준비되어 있지 않다면 팀 단위 배포는 예산 리스크로 이어진다.
에이전트의 작업 이력을 사후에 확인할 수 있는가. 팀에서 공용으로 쓰는 에이전트가 무엇을 했는지 추적할 방법이 없다면, 그 에이전트는 조직의 책임 체계 안에 있지 않다.
세 가지 모두에 "예"라고 답할 수 있을 때, 팀 도입을 검토할 수 있다.
도입 여부보다 배치 설계가 먼저
Hermes Agent는 개인 레이어에서 쓸 때 강력하다. 그 강점을 그대로 팀 레이어에 올리려 할 때는 여러 사항을 먼저 고려해야 한다.
AI 에이전트 도입을 결정하는 기준은 하나다. 우리 조직이 이것을 통제할 수 있는가. 이 질문에 답할 수 있는 구조를 먼저 설계하는 것이 순서다. 어떤 업무에 어떤 에이전트를 두어야 하는지, 팀 레이어와 개인 레이어의 경계를 어떻게 그어야 하는지.
in solving your problems with Enhans!
We'll contact you shortly!