Hermes Agent 0.12, AI 에이전트 운영의 초점이 자기 관리로 이동했다

이번 릴리스의 핵심은 기능 수가 아니라 운영 부채 관리다

NousResearch가 2026년 4월 30일 공개한 Hermes Agent v0.12.0은 단순한 기능 추가 릴리스가 아니다. 공식 릴리스 노트 기준으로 v0.11.0 이후 1,096개 커밋, 550개 병합 PR, 1,270개 파일 변경이 쌓였고, 213명의 커뮤니티 기여가 들어간 대형 업데이트다. 그러나 숫자보다 중요한 변화는 방향이다. Hermes는 이제 “AI에게 한 번 일을 시키는 도구”에서 “계속 일하는 에이전트를 어떻게 관리할 것인가”라는 운영 문제로 중심을 옮기고 있다.

이번 릴리스의 제목은 Curator release다. Curator는 Hermes가 사용하는 스킬 라이브러리를 주기적으로 평가하고, 겹치는 스킬을 통합하고, 오래된 스킬을 정리 후보로 올리는 기능이다. 여기에 더 엄격해진 self-improvement loop, 새 추론 provider, 플러그인형 gateway, Teams·Yuanbao·Spotify·Google Meet 같은 채널 확장, TUI 성능 개선, 보안 기본값 변경이 함께 묶였다. 겉으로 보면 기능 목록이 많지만, 실제 메시지는 하나다. 에이전트가 오래 일할수록 쌓이는 운영 부채를 제품 레벨에서 다루겠다는 것이다.

AI 에이전트 도구는 보통 “어떤 모델을 붙였나”, “어떤 도구를 호출하나”, “어떤 메신저에서 쓸 수 있나”로 평가된다. Hermes Agent v0.12.0에도 그런 항목은 많다. LM Studio가 first-class provider가 됐고, GMI Cloud, Azure AI Foundry, MiniMax OAuth, Tencent Tokenhub가 추가됐다. gateway는 플러그인 호스트가 됐고, Microsoft Teams가 플러그인형 플랫폼으로 들어왔으며, Tencent Yuanbao도 새 메시징 플랫폼으로 추가됐다. Spotify와 Google Meet도 native plugin 흐름에 들어왔다.

하지만 이 릴리스의 더 깊은 변화는 “많이 연결된 에이전트가 오래 망가지지 않게 하는 구조”다. 에이전트는 한 번 쓰면 편하지만, 오래 쓰면 다른 종류의 문제가 생긴다. 스킬이 너무 많아져 어떤 지침을 따라야 할지 흐려지고, 예전 배포 절차가 남아 새 운영 방식과 충돌하고, 어떤 기억은 계속 남아야 하는데 어떤 기억은 지워져야 한다. 단발 작업에서는 보이지 않던 문제가 장기 운영에서는 품질을 갉아먹는다.

Curator는 바로 이 지점을 겨냥한다. 공식 릴리스에 따르면 hermes curator는 gateway cron ticker 위에서 기본 7일 주기로 돌며 스킬 라이브러리를 평가한다. 실행 결과는 run.json과 REPORT.md로 남고, 사용 빈도를 기준으로 많이 쓰인 스킬과 거의 쓰이지 않은 스킬을 보여준다. 정리된 스킬이 단순 삭제인지, 다른 스킬로 통합된 것인지도 모델과 휴리스틱으로 분류한다. 즉 Curator는 “스킬 폴더 청소”가 아니라 에이전트의 운영 기억을 주기적으로 감사하는 장치다.

Curator가 바꾸는 것은 스킬 목록이 아니라 에이전트의 습관이다

Hermes의 스킬은 단순 문서가 아니다. 특정 작업을 어떻게 해야 하는지, 어떤 검증을 먼저 해야 하는지, 어떤 위험을 피해야 하는지를 담은 실행 습관에 가깝다. 그래서 스킬이 좋아지면 에이전트의 반복 작업 품질이 올라가지만, 스킬이 낡으면 같은 실수가 자동화된다.

예를 들어 사이트 운영 에이전트가 예전에는 “콘텐츠를 코드 파일에 추가하고 배포한다”는 방식으로 일했다고 하자. 나중에 운영 구조가 바뀌어 “로컬 JSON을 원본으로 두고 DB에 업로드한 뒤 revalidate한다”가 표준이 됐다면, 예전 스킬은 더 이상 작은 문서 오류가 아니다. 에이전트가 불필요한 배포를 만들고, 자동 배포를 유발하고, 운영자가 원하지 않는 변경을 push할 수 있는 위험이 된다. Curator는 이런 오래된 습관을 발견하고 정리 후보로 올릴 수 있다.

반대로 자주 쓰이지 않는 스킬이 항상 나쁜 것은 아니다. 장애 복구, 계정 이전, 백업 복원처럼 드물게 쓰이지만 반드시 살아 있어야 하는 스킬도 있다. 그래서 Curator의 가치는 자동 삭제보다 보고서에 있다. 운영자는 “최근 안 쓰인 스킬”을 보고 정말 불필요한지, 이름이 불명확해서 호출되지 않는지, 긴급 상황 전용이라 보존해야 하는지 판단해야 한다.

자기 개선 루프는 더 적극적이지만 더 좁아졌다

v0.12.0에서 self-improvement loop도 크게 바뀌었다. 공식 릴리스는 매 턴 이후 무엇을 기억하거나 스킬로 저장할지 판단하는 background review fork가 자유 서술형에서 rubric 기반 구조로 바뀌었다고 설명한다. 또 방금 로드한 스킬을 적극적으로 업데이트하는 편향을 갖고, references와 templates 같은 하위 파일도 다룰 수 있으며, 부모 런타임의 provider와 model 설정을 제대로 상속하도록 개선됐다고 밝힌다.

여기서 핵심은 “더 많이 배운다”가 아니라 “무엇을 배울지 더 좁게 판단한다”다. self-improvement loop는 memory와 skills 도구 영역으로 제한된다. 운영 관점에서 이것은 매우 중요하다. 에이전트가 작업 도중 마음대로 셸을 열거나 웹을 탐색하거나 파일을 대규모로 바꾸면서 자기 개선을 한다면, 배움과 부작용을 분리하기 어렵다. Hermes 0.12는 자기 개선을 더 강하게 만들면서도 영향 범위를 memory와 skill에 묶는 쪽으로 설계했다.

실무적으로는 다음 차이가 생긴다. 예전에는 “이 작업에서 배운 점이 있나”를 사람이 메모로 남기거나, 에이전트가 다소 느슨하게 요약했다면, 이제는 방금 사용한 스킬을 실제로 고칠 수 있는 방향이 강해진다. 테스트 순서가 빠졌다면 스킬에 보강하고, 렌더러가 싫어하는 포맷을 발견했다면 주의사항으로 넣고, 특정 provider 설정이 반복적으로 실패했다면 setup 절차를 고칠 수 있다. 반면 배포 권한, 데이터 삭제, 외부 계정 연결처럼 실패 비용이 큰 절차는 여전히 승인 경계가 필요하다.

provider 확장은 선택지를 늘렸고, 모델 운영의 난도를 높였다

이번 릴리스는 provider·model 영역에서도 넓게 움직였다. LM Studio는 custom endpoint alias 수준에서 벗어나 전용 인증, doctor checks, reasoning transport, live models listing을 갖춘 first-class provider가 됐다. 로컬 모델을 실험하던 사용자에게는 의미가 크다. 단순히 “로컬 서버 주소를 넣는다”가 아니라 Hermes의 provider 관리·진단·모델 목록 흐름 안에서 LM Studio를 다룰 수 있게 됐기 때문이다.

GMI Cloud, Azure AI Foundry, MiniMax OAuth, Tencent Tokenhub 추가도 방향성이 있다. Hermes는 특정 모델 하나에 묶이는 도구가 아니라 여러 추론 공급자를 상황에 맞게 바꾸는 운영 도구가 되고 있다. remote model catalog manifest도 같은 맥락이다. OpenRouter와 Nous Portal 모델 카탈로그를 원격 manifest로 가져오면 새 모델을 보기 위해 매번 Hermes 자체 릴리스를 기다릴 필요가 줄어든다.

좋아진 점은 명확하다. 사용자는 작업 성격에 따라 빠른 모델, 저렴한 모델, reasoning에 강한 모델, 로컬 모델, 기업 계정에 묶인 모델을 고를 수 있다. 그러나 운영 난도도 올라간다. provider가 많아질수록 “어떤 작업은 어떤 모델로 돌릴 것인가”, “보조 모델이 실패하면 main으로 fallback할 것인가”, “비용이 큰 작업은 어떤 TTL로 prompt cache를 쓸 것인가” 같은 정책이 필요해진다. Hermes 0.12의 Models dashboard tab과 in-browser model config는 이 복잡도를 화면에서 다루려는 시도다.

gateway와 plugin 구조는 Hermes를 작업 공간 밖으로 밀어낸다

Microsoft Teams, Tencent Yuanbao, Spotify, Google Meet은 단순한 부가 통합처럼 보일 수 있다. 하지만 gateway가 plugin host가 됐다는 점을 함께 보면 의미가 달라진다. Hermes는 더 이상 한두 개의 메시징 어댑터를 직접 내장하는 구조가 아니라, 플랫폼이 외부 plugin으로 붙는 구조로 가고 있다. Teams가 첫 plugin-shipped platform으로 들어왔다는 점은 앞으로 조직별 채널, 사내 도구, 특수 업무 시스템과 연결될 여지를 넓힌다.

이 변화는 생산성 측면에서 매력적이다. 회의에 들어가 전사하고 후속 작업을 만들고, 메신저에서 이미지를 보내고, Spotify 큐를 조정하고, ComfyUI와 TouchDesigner로 창작 워크플로우를 이어갈 수 있다. 하지만 위험도 같이 커진다. 에이전트가 읽고 쓸 수 있는 채널이 늘어나면 정보 경계, 승인 경계, 공개 범위가 핵심 운영 문제가 된다.

예를 들어 Google Meet plugin으로 회의 내용을 전사한 뒤 Slack이나 Teams에 자동 요약을 보낸다고 하자. 편하지만, 고객 정보나 내부 의사결정 내용이 섞이면 바로 사고가 된다. Spotify는 가벼운 통합처럼 보이지만 개인 계정 OAuth 흐름이 들어간다. ComfyUI는 창작 자동화를 넓히지만 로컬 GPU와 파일 입출력, 이미지 결과물 공개 범위가 따라온다. Hermes가 강해질수록 운영자는 “무엇을 자동화할까”보다 “어디까지 자동화해도 되는가”를 먼저 정해야 한다.

TUI와 CLI 개선은 실제 사용 빈도를 높이는 변화다

v0.12.0의 성능 개선도 가볍게 볼 수 없다. 공식 릴리스는 visible TUI cold start가 약 57% 줄었다고 밝힌다. lazy agent init, OpenAI·Anthropic·Firecrawl·account usage lazy import, config load cache, tool definition memoization, dangerous pattern precompile 같은 내부 개선이 들어갔다. 이런 개선은 화려하지 않지만 매일 쓰는 도구에서는 체감이 크다.

AI 에이전트는 시작이 느리면 사용 빈도가 줄어든다. “잠깐 물어볼까”가 “켜는 동안 기다려야 하니 나중에 하자”로 바뀐다. 반대로 TUI 시작이 빨라지고, LaTeX 렌더링, auto-resume, session delete, mouse wheel scroll, mini help 같은 세부 UX가 좋아지면 사용자는 Hermes를 더 자주 열게 된다. 도구가 자주 열리면 기억과 스킬의 품질도 더 중요해진다. 결국 성능 개선과 Curator는 따로 떨어진 항목이 아니다. 자주 쓰는 에이전트일수록 자기 관리가 필요하다.

CLI 쪽에서는 hermes -z one-shot mode와 update preflight가 눈에 띈다. one-shot mode는 스크립트나 자동화에서 Hermes를 비대화형으로 호출할 수 있게 한다. update check와 opt-in home backup은 업데이트 전 위험을 줄인다. 운영 자동화 관점에서는 “대화형 도구”와 “자동 실행 도구” 사이의 경계가 더 유연해지는 변화다.

보안 변경에서 가장 논쟁적인 지점은 secret redaction 기본값이다

이번 릴리스에서 눈에 띄는 보안·신뢰성 변화는 secret redaction이 기본 off로 바뀐 점이다. 공식 릴리스는 fake secret-shaped substring이 tool output이나 patch를 망가뜨리던 문제를 막기 위한 변경이라고 설명한다. 필요하면 사용자가 redaction 설정을 켤 수 있다.

이 결정은 보안 기능을 약화한 것처럼 보일 수 있지만, 에이전트 운영에서는 정확성과 보안이 충돌할 때가 있다. 자동 redaction이 실제 비밀을 가리는 데 도움이 되더라도, 코드 패치나 로그 분석 중 가짜 비밀 패턴을 잘못 바꾸면 작업 결과가 깨진다. 특히 에이전트가 파일을 수정하고 diff를 만들고 다시 검증하는 흐름에서는 작은 문자열 변형이 큰 오류로 번질 수 있다.

그래서 이 변경은 “보안을 끈다”라기보다 “자동 마스킹이 작업물을 망가뜨리는 위험을 기본값에서 제거한다”에 가깝다. 대신 운영자는 공개 글, 로그 공유, 메신저 전송, 외부 도구 호출에서 별도의 공개 안전 스캔과 권한 경계를 세워야 한다. Hermes 0.12가 강해질수록 보안은 하나의 toggle이 아니라 운영 절차가 된다.

VIBE 코딩 관점에서 달라지는 실무 판단

VIBE 코딩 관점에서 Hermes Agent v0.12.0은 “프롬프트를 잘 쓰면 된다”는 단계를 넘어선다. 이제 중요한 것은 에이전트에게 어떤 반복 습관을 줄 것인지, 어떤 작업은 자동으로 맡기고 어떤 작업은 승인 대기시킬 것인지, 어떤 모델과 채널을 어떤 범위에서 쓸 것인지다.

개인 개발자라면 Curator를 통해 오래된 스킬을 정리하고, hermes -z로 반복 작업을 자동화하고, LM Studio나 OpenRouter 계열 모델을 비용·속도에 맞게 바꾸는 식으로 활용할 수 있다. 작은 팀이라면 Teams나 Slack 같은 gateway를 업무 채널에 붙이되, 승인 경계와 공개 범위를 먼저 정해야 한다. 사이트 운영자라면 Hermes의 self-improvement loop가 배포·콘텐츠·검증 스킬을 마음대로 바꾸지 않도록 핵심 절차는 보호하고, 낮은 위험도의 문서 보강만 자동화하는 전략이 필요하다.

이번 릴리스의 좋은 점은 Hermes가 실제 운영에서 부딪히는 문제를 정면으로 다룬다는 것이다. 부족한 점도 같은 곳에 있다. 기능이 많아진 만큼 설정·권한·스킬 품질을 관리하지 않으면 사용자는 오히려 혼란스러워질 수 있다. Hermes 0.12는 초보자에게 더 간단해졌다기보다, 진지하게 오래 쓰려는 사용자에게 더 많은 운영 도구를 제공한 릴리스다.

결론: Hermes는 에이전트 실행기에서 에이전트 운영체제로 이동 중이다

Hermes Agent v0.12.0의 핵심은 Curator 하나가 아니다. Curator, self-improvement loop, provider 확장, plugin gateway, model dashboard, TUI 성능 개선, 보안 기본값 변경이 한 방향을 가리킨다. AI 에이전트는 이제 “질문에 답하는 프로그램”이 아니라 기억을 쌓고, 도구를 고르고, 채널을 넘나들고, 자기 작업 방식을 고치는 운영 주체가 되고 있다.

그만큼 책임도 커진다. 좋은 Hermes 운영은 기능을 모두 켜는 것이 아니다. 어떤 스킬을 보호할지, 어떤 변경을 보고서로만 받을지, 어떤 provider를 어떤 작업에 쓸지, 어떤 gateway 채널에는 읽기만 허용할지, 어떤 자동화에는 사람 승인을 요구할지 정하는 일이다. v0.12.0은 Hermes를 더 강하게 만들었지만, 동시에 운영자의 설계 능력을 더 중요하게 만들었다.

독자가 먼저 확인할 지점

이 소식은 기능 이름보다 운영 조건을 먼저 봐야 한다. 어떤 권한이 필요한지, 어떤 경로로 데이터가 이동하는지, 실패했을 때 사람이 확인할 수 있는 로그가 남는지가 실제 도입 판단의 기준이다.

팀 적용 시나리오

작은 팀은 한두 개의 대표 업무에만 적용해 응답 품질과 검증 비용을 비교하는 편이 안전하다. 큰 조직은 권한 경계, 감사 로그, 네트워크 분리, 비용 상한을 먼저 설계한 뒤 제한된 부서에서 파일럿을 시작해야 한다.

확인 체크리스트

공식 문서의 지원 범위, 가격과 사용량 제한, 권한 모델, 실패 시 되돌리기 방법, 공개 서비스에 미치는 영향을 순서대로 확인해야 한다. 이 다섯 가지가 불명확하면 발표 내용이 좋아 보여도 운영 도입은 늦추는 편이 낫다.

참고한 공식 출처

• Hermes Agent v0.12.0 release
• Hermes releases
• Hermes repo