내가 Hermes Agent를 처음 알아차렸을 때는, 이미 "일찍 왔다"고 말하기엔 한참 늦은 뒤였다.
그날은 목요일이었다 — 2026년 3월 12일. 기조연설도, 카운트다운도, X에 올라온 론칭 스레드도 없었다. Nous Research는 그냥 git tag를 하나 찍고, GitHub 저장소를 public으로 전환한 다음, 자기네 Discord에 한 줄만 남겼다. "this exists now." 금요일 아침이 되자 저장소는 이미 별을 1,000개 넘게 받았고, 20개 타임존에 흩어진 사람들이 "설치는 어떤 경로로 하는 게 맞냐"를 두고 서로 따지고 있었다.
그 태그가 찍히기 전 두 주 동안, 한 번도 직접 만난 적 없는 63명의 컨트리뷰터가 프로젝트에 PR 216개를 밀어 넣었고, 이슈 119개를 닫았고, 테스트 스위트를 거의 0에서 3,289개까지 키워 놓았다. 그중 누구도 Nous Research 직원이 아니다. 이들은 GitHub 코멘트 창을 통해 서로 입씨름을 했고, 14일째 되던 날 진짜로 돌아가는 물건을 내놓았다.
그래서, 상자 안에는 대체 뭐가 있었느냐.
프로세스 하나, 정문 일곱 개
v0.2.0의 간판은 멀티플랫폼 메시징 게이트웨이다. 단 하나의 Hermes 프로세스가 Telegram, Discord, Slack, WhatsApp, Signal, IMAP/SMTP 이메일, 그리고 Home Assistant를 동시에 듣고 있다. 세션 매니저도 하나, 메모리도 하나, 툴 레지스트리도 하나다. 플랫폼마다 어떤 스킬을 쓸 수 있게 할지, 첨부 파일을 어떻게 처리할지는 따로 설정할 수 있지만, 반대편에 있는 에이전트는 언제나 같은 한 명의 에이전트다.
이게 말보다 훨씬 흥미로운 건, 일반적으로 쓰는 대안 — 봇을 일곱 개 따로 세우고, 각자 자기 상태를 들고 있게 하는 것 — 이 끔찍하기 때문이다. 기억이 갈라진다. 도구 상태가 어긋난다. Hermes는 게이트웨이 그 자체를 통합 지점으로 삼고, 에이전트는 하나로 유지한다. 5달러짜리 VPS에 한 번만 깔아 두면, 지금 손에 들고 있는 앱이 뭐든 거기서 그 에이전트한테 닿는다.
외장 아닌 네이티브 MCP
게이트웨이 바로 옆에 앉아 있는 건 완전한 Model Context Protocol 클라이언트다. stdio와 HTTP 두 전송을 모두 지원하고, 재접속, 리소스·프롬프트 탐색, 서버가 먼저 시작하는 sampling까지 갖췄다. 에이전트 생태계에 깊이 발 담그지 않은 독자를 위해 한 줄 배경: MCP는 Anthropic이 내놓은 오픈 표준이고, LLM이 외부 도구와 일관된 방식으로 대화할 수 있게 하기 위한 규약이다. 대부분의 프레임워크는 MCP를 한참 뒤에 기존 툴 호출 시스템 위에 어댑터처럼 얹었다. Hermes는 첫날부터 MCP를 코어에 곧장 배선해 놓았다 — MCP를 말할 줄 아는 도구라면 래퍼 없이 그대로 붙는다.
스킬은 일급 시민
v0.2.0에는 15개 이상의 카테고리에 걸친 70개가 넘는 번들 스킬이 들어 있고, 그 뒤를 Skills Hub라는 것이 받치고 있다. 조건부 활성화(전제 조건이 갖춰져야만 스킬이 로드됨), 전제 조건 검증, 커뮤니티 기반 탐색이 전부 여기 담겨 있다. 이 Hub는 나중에 agentskills.io가 된다. 첫날부터 제공되는 스킬에는 이미지 분석, 샌드박스 안에서 돌아가는 Python 실행, 파일 검색, 웹 가져오기, 그리고 이외에 스무 개 이상이 포함된다.
여기서의 기술적 결정은 스킬을 "import 시점에 등록되는 Python 함수"가 아니라, 매니페스트·의존성·활성화 조건을 가진 선언적 단위로 다룬다는 것이다. 이게 바로 에이전트 하나가 스킬 70개를 한꺼번에 짊어지고 있어도 프롬프트가 터지지 않는 이유다.
프로바이더 라우터와 안전망
v0.2.0에는 이후의 거의 모든 것을 형태 짓는 아키텍처 판단이 두 개 더 들어 있다.
첫 번째는 중앙 집중식 프로바이더 라우터다. 단일한 call_llm() / async_call_llm() API가 비전, 요약, 컨텍스트 압축, 궤적 저장 곳곳에 흩어져 있던 프로바이더 로직을 한 곳으로 걷어 모은다. 보조 호출자들은 전부 같은 코드 경로를 타고, 자격 증명 해석도 자동이다. 말로만 들으면 지루하지만, 진짜로 프로바이더를 갈아치우려는 순간 느낌이 바뀐다 — 그때 당신이 고치는 파일은 11개가 아니라 1개다.
두 번째는 안전을 위한 이중 장치다. git worktree 격리(hermes -w로 띄우면 각 세션이 격리된 worktree 안에서 돌아가기 때문에, 에이전트가 진짜 코드에 실수로 손대는 일이 없다), 그리고 롤백 가능한 파일시스템 체크포인트(파괴적인 작업 전에 스냅숏을 떠 두고 /rollback으로 되돌린다). 에이전트가 과감하게 움직여도 괜찮은 건, 실제로 되돌릴 수 있기 때문이다. "조심스럽게 움직이는 AI 어시스턴트"와 "시스템이 대신 조심해 주기 때문에 과감하게 움직이는 AI 어시스턴트" 사이의 차이가 바로 여기에 있다.
그리고 에디터 쪽 얘기
릴리스 노트 안에 묻혀 있지만 꽤 중요한 마지막 한 가지 — ACP 서버 지원이다. Agent Communication Protocol을 통해 Hermes는 VS Code, Zed, JetBrains와 네이티브로 붙는다. 더 이상 "터미널 안에 사는 무언가"가 아니라, 당신이 실제로 매일 쓰는 그 에디터 안에서 살기 시작한다.
---
나는 3월의 그 목요일을 자꾸 떠올린다. 공지도, 슬라이드도, 투자자 콜도 없었고, 있었던 건 git tag 하나, public으로 한 번의 전환, 그리고 문이 열린 그 순간 마침 안에 있던 63명뿐이었다. 이 블로그 뒤쪽의 글들에 굳이 하나의 주제가 있다면, 그건 이것이다 — Hermes를 만드는 사람들의 속도가, 어떤 단일 기능의 속도보다 결과적으로 훨씬 더 중요했다는 것.