셀프호스트 에이전트를 누군가에게 한 번이라도 세팅해 줬다면, 다음 장면을 슬로모션으로 본 적이 있을 거다.
친구가 "Hermes로 web search 어떻게 해?"라고 물어본다. 너는 설명한다: Firecrawl 가입하고, 콘솔에서 API key 꺼내서, .env에 붙이고, hermes tools 돌리고, 체크 박스 켜. 친구가 그대로 한다. 된다. 이틀 뒤 친구는 이미지 생성을 원한다. 너는 설명한다: FAL 가입하고, 콘솔에서 API key 꺼내서, .env에 붙이고, hermes tools 돌리고, 체크 박스 켜. 친구 얼굴이 좀 피곤해진다. 그 다음에 TTS가 필요해질 때, 친구는 더 안 묻는다.
셀프호스트 에이전트의 마찰세는 에이전트 자체랑은 상관이 없다. 툴 단위의 key 춤, 툴 단위의 콘솔, 툴 단위의 갱신 캘린더다. 2026년 4월 16일, v0.9.0에서 사흘 뒤, v0.10.0이 Nous Portal 구독을 가진 모든 사람한테서 그 세금의 한 덩어리를 떼어냈다.
코드 줄 수로 보면 이 릴리스는 작다—사흘에 약 180건의 commit. 그런데 이 사흘에 안착한 그 한 가지 기능 때문에, v0.10은 기억 속에서 단 한 가지와 등호로 묶이게 된다: Nous Tool Gateway.
"매니지드 툴"이 결국 뭔데
Nous Tool Gateway는 서버 측 멀티플렉서다. 네 기계 위의 에이전트는 여전히 예전과 똑같이 web_search나 generate_image를 부른다—부르는 방식은 그대로다. 바뀌는 건, 그 호출이 이제 Nous의 게이트웨이로 떨어진다는 점이다. 게이트웨이가 상위 API key를 들고, 네가 아니라 네 포털 구독에 청구한다.
첫 번째 물결은 네 가지 툴이다. 릴리스 노트에서 그대로:
- •Web search, Firecrawl
- •이미지 생성, FAL의 FLUX 2 Pro
- •TTS, OpenAI TTS
- •브라우저 자동화, Browser Use
이건 새 툴이 아니다. 너는 늘 직접 연결할 수 있던 툴이다—계정 네 개와 .env 네 줄로. v0.10.0이 바꾼 건, 더는 그럴 필요가 없다는 것뿐이다.
게이트웨이 사용 여부는 툴 단위로 옵트인이다. 스위치는 hermes model이 노출하는 use_gateway 설정에 달려 있다. 어떤 툴에 직결 API key가 이미 있으면, 런타임은 여전히 직결을 우선한다—게이트웨이는 백업이지, 인수가 아니다. 선택의 단위는 개별 툴이지, 설치 전체가 아니다.
문을 나가다 죽은 그 환경 변수
v0.8/v0.9 라인을 돌렸다면 아마 HERMES_ENABLE_NOUS_MANAGED_TOOLS를 기억할 거다. v0.10.0이 그걸 지웠다. 이제 구독 그 자체가 신호다: 포털에 로그인하면 게이트웨이가 켜지고, 툴이 동작한다. 기억할 토글도 없고, 머신 사이에 동기화할 .env 줄도 없다.
hermes tools와 hermes status 둘 다 이 릴리스에서 게이트웨이를 알아보게 됐다. 앞엣것은 어떤 툴이 직결이고 어떤 게 매니지드고 어떤 게 꺼져 있는지 한눈에 보여준다. 뒤엣것은 게이트웨이 연결 자체를 확인한다. 작은 커맨드 두 개지만, "지금 어떤 key가 일하고 있더라"라는 질문을 한 줄짜리 출력으로 줄여놨다.
이게 들리는 것보다 큰 이유
내가 위에서 말한 그 마찰세는 어떤 벤치마크에도 안 잡힌다. "친구한테 Firecrawl 세팅해주느라 날린 분(分)" 그래프 같은 건 누구도 그리지 않는다. 그런데 셀프호스트로 에이전트 돌리는 사람은 다들 이 세금을 내고 있고, 대부분은 다섯 번째나 여섯 번째 툴쯤에서 더 안 더한다. 한계 귀찮음이 한계 편익을 넘기 때문이다.
취미로 굴리는 사람한테 이 세금은 짜증나는 정도다. 공유 VPS에서 Hermes를 굴리는 작은 팀한테 이 세금은 소유의 문제로 바뀐다: Firecrawl 청구서를 짊어진 사람은 누구야? 걔가 회사 그만두면 web search는 어떻게 돼?
게이트웨이는 그 표면을 통째로 거둬간다. 구독 하나, 툴 네 개, 청구 관리 한 곳. 데이터베이스를 매니지드 서비스에 맡기는 날 네가 맺는 거래와 같은 모양—제어를 조금 내주고, 일요일 오후를 되돌려받는 거래다.
대가도 있고, 릴리스 노트는 그걸 덮지 않는다. 게이트웨이를 거친다는 건 Nous를 거친다는 거고, Nous가 전에는 못 보던 쿼리 메타데이터를 본다는 뜻이다. 게이트웨이가 굳이 툴 단위로 옵트인인 건 정확히 그 이유 때문이다—이 거래는 무조건적이지 않다. 어떤 툴에서 게이트웨이를 원하지 않으면, 네 직결 API key는 그 자리에 있고 런타임이 그걸 계속 쓴다. 핵심은, 이게 이제 네가 내리는 선택이 됐다는 것이다—그 선택을 시작하기 위해 먼저 뛰어넘어야 하는 고리가 아니라.
나머지는, 짧게
v0.10.0은 tool gateway 중심의 릴리스다. 이 버전에 TUI 재작성은 없다—그건 v0.11.0의 일이다. 새 채팅 플랫폼도 없다—그 물결은 v0.12.0부터 다시 시작한다. 그래도 에이전트 코어, 게이트웨이, CLI, tool 기반에 180건이 넘는 commit이 깔려 있다. v2026.4.13에서 v2026.4.16 사이의 풀 diff는 GitHub에 있다. 한 줄 한 줄 읽고 싶다면.
케이던스는 계속 간다. 직전 릴리스에서 사흘 뒤, 메이저 신기능 하나, 그리고 아무도 안 볼 때 슬쩍 청소된 deprecation 하나.
---
v0.10.0이 흥미로운 지점은, 코드 줄 수로 이렇게 작은데도 바꿔놓은 게—"누가 Hermes를 돌릴 수 있나"—이렇게 크다는 데 있다. v0.9.0은 플랫폼을 세 개 추가했다. v0.10.0은 하나도 안 추가했지만, 이미 가지고 있는 툴을 돌리는 비용을 임계 아래로 끌어내렸다. "key 관리가 너무 귀찮아서 포기했어요" 카테고리 한 무리가 통째로 돌아온다.
이 시기의 릴리스 캘린더를 펼쳐 놓고 보면, 한 가지 패턴이 떠오른다: 절반의 릴리스는 능력을 쌓고, 나머지 절반은 마찰을 깎는다. v0.10.0은 명백히 후자다. 2주 뒤 v0.12.0도 같은 종류—그때 Autonomous Curator가 등장해서, 네가 자는 사이에 skill 라이브러리를 가지치기한다. 케이던스가 이 프로젝트를 빨라 보이게 만든다. 모양—능력 주, 마찰 주, 능력 주—이 이 프로젝트를 지속 가능해 보이게 만든다.