Hermes Agent v0.14.0은 어떻게 콜드 스타트에서 19초를 깎고 browser 동작을 180배 빠르게 했는가

v0.14.0이 한 묶음의 성능 작업을 출하했다. 묶어서 보면 Hermes Agent가 다른 프로그램처럼 느껴질 정도다. 릴리스 노트의 헤드라인 셋:

• •콜드 스타트에서 약 19초 깎임. import 그래프, doctor 검사, 모델 카탈로그 조회, 환영 배너 — 그 사이 여기저기에 흩어져 있다.
• •browser_console이 180배 빠르게. 호출마다 새 DevTools 세션을 여는 대신, 영구 CDP 연결 하나를 든다.
• •세션 가로지르는 1시간 Claude prompt 캐시. /new로도 따뜻한 prefix 캐시를 안 잃는다.

이 중 어느 것도 "처음부터 다시 짜기"가 아니다. 각각 특정 핫 패스를 노린, 작고 자리매김 된 PR의 사슬이다. 이 글은 PR 단위 분해다 — 무엇이 느렸고, 무엇을 바꿨고, 에이전트를 짜는 사람한테 일반화되는 교훈이 무엇인지.

출발점

2026년 5월 초에 hermes를 돌렸다면, 콜드 스타트 경로는 이런 모양이었다:

1. 1.Python 인터프리터 시작 (약 100 ms)
2. 2.import hermes가 나머지 import 그래프를 끌어올림 (약 5–10 s)
3. 3.hermes 플러그인 탐색이 설치된 플러그인을 훑음 (약 2–3 s)
4. 4.hermes doctor가 API 연결 검사를 순차로 돌림 (약 3–5 s)
5. 5.skills 인덱스 로드, 종종 네트워크에서 다시 가져옴 (약 2–4 s)
6. 6.환영 배너 렌더 (약 1 s)
7. 7.프롬프트가 뜬다

타이핑을 시작할 수 있기 전에 15–25초. 흐름을 깨기에 충분한 길이다. v0.14.0의 성능 물결은 그 단계들을 하나씩 친다.

콜드 스타트 물결 (10+ PR)

skills 캐시 + 어댑터 lazy import (#22138)

단독으로 제일 큰 승리. 평행한 두 변경:

1. 1.skills 인덱스를 디스크에 캐시. 이전 동작: 매 hermes 호출마다 skills 디렉터리를 다시 읽고 가벼운 인덱싱을 돌렸음. 새 동작: 인덱스는 캐시 파일에 살고, 디렉터리가 바뀔 때만(mtime 체크) 다시 만든다.
2. 2.무거운 어댑터 SDK는 lazy로. 이전: hermes를 import 하면 Feishu SDK, WhatsApp SDK, 모든 voice/TTS 프로바이더, 모든 이미지 생성 SDK의 import가 같이 트리거됐다. 새: 각각 첫 사용까지 지연된다. Feishu를 안 쓴다면 Feishu SDK는 영영 안 올라온다.

두 변경 다 #22138 안에 있고, 약 5–8초를 깎았다. lazy-import 패턴은 잘 안 알려진 영웅이다 — 코드베이스 전반에 기계적으로 적용되지만, 단일 드라마틱 PR로는 안 보인다.

알려진 서브커맨드에서 즉시 플러그인 탐색 스킵 (#22120)

hermes config set X Y를 돌리는데 플러그인 탐색이 필요할 리 없다. hermes tools, hermes model, hermes doctor도 마찬가지. 디스패처가 명령이 알려진 내장이면 플러그인 탐색을 단락(short-circuit)시키게 됐다. 대부분의 CLI 호출에서 약 2초 절약.

models.dev 캐시 우선 조회 (#22808)

Hermes는 정통 모델 카탈로그를 위해 models.dev를 친다. v0.14.0 이전엔 매 hermes 시작마다 HTTP 호출. 새 동작: 먼저 디스크 캐시에서 읽고, 묵을 때만(24시간 초과) 다시 가져온다. 캐시 히트는 약 5 ms — 네트워크 왕복 약 200–500 ms 대신.

hermes doctor의 API 연결 검사 병렬화 (#22766)

hermes doctor는 "Nous Portal, OpenRouter, Anthropic, OpenAI에 닿는가"를 순차로 검사했다. 새: asyncio.gather로 모아서 던지고, 클라우드 외 머신에서 자주 타임아웃 나던 IMDS(인스턴스 메타데이터 서비스) 검사를 뺐다. 일반적인 경우 doctor에서 약 3–5초 깎임.

chat -q가 환영 배너 스킵 (#22904)

단발 쿼리 모드(hermes chat -q "what's the time")에선 환영 배너가 노이즈다. v0.14.0이 그 케이스에서 렌더를 스킵한다. 스크립트/자동화 용도에서 약 1초 회수.

그래프 전체에 흩어진 지연 import

긴 꼬리의 PR들이 각각 무거운 import 하나씩을 지연시킨다:

• •google_chat 어댑터의 google-cloud — google chat을 처음 쓸 때만 로드 (#22681)
• •QQAdapter, YuanbaoAdapter — PEP 562로 모듈 레벨 지연 (#22790)
• •teams 어댑터의 httpx — 첫 webhook 호출 때만 (#22831)
• •fal_client — 첫 이미지 생성 때만 (#22859)

각 PR은 작다. 묶이면 또 2–4초.

Nous 인증과 .env 로드 캐시 (#25341)

hermes tools All-Platforms 화면은 예전엔 플랫폼별로 인증 검사를 동기로 돌렸다. 캐시가 들어가니까 14초에서 1.5초 미만으로 떨어졌다. 화면은 똑같이 동작한다 — 그저 매 호출마다 14초의 네트워크 시간을 태우지 않을 뿐이다.

정리 효과

승리들을 다 더하면 헤드라인의 19초가 된다. 따로 보면 드라마틱한 건 없지만, 묶이면 프로그램이 반응이 빠른 체감으로 바뀐다.

browser_console 180× 이야기 (#23226)

Hermes의 browser 도구는 Chrome DevTools Protocol(CDP)로 headless Chrome을 구동한다. v0.14.0 이전엔 매 browser_console 평가가 이런 흐름이었다:

1. 1.Chrome에 새 CDP WebSocket 연결
2. 2.핸드셰이크 대기 (약 1–2 s)
3. 3.평가할 JavaScript 전송
4. 4.결과 읽기
5. 5.WebSocket 닫기

연속 평가 체인 — 가령 에이전트가 페이지를 단계별로 검사 — 에선 평가당 약 1.5초가 들었다. 전형적인 "이 페이지 보고 알려줘" 흐름이 고통스러울 만큼 느렸다.

v0.14.0의 변경: supervisor당 영구 WebSocket 하나, 모든 browser 도구 호출이 공유. CDP 핸드셰이크는 세션당 한 번만 일어나고, 후속 평가는 1–2 단계를 통째로 스킵하고 페이로드만 보낸다.

결과: 호출당 지연이 약 1.5초에서 약 8 ms로. 그게 약 180×.

교훈은 일반적이다. 에이전트가 N번 도구 호출을 하고 매번 새 연결을 여는 자리는 어디서든: 채팅 페이스의 워크로드에선 연결 풀링이 병렬보다 이긴다. 일의 총량은 연결 설정에 살지, 일 자체엔 안 산다.

세션 가로지르는 1시간 Claude prompt 캐시 (#23828, #25434, #24778)

Claude의 prompt 캐시(Anthropic API 기능)는 컨텍스트의 한 덩어리를 캐시 가능으로 표시할 수 있게 해준다. TTL 안의 후속 요청 — 역사적으론 5분 — 이 그 캐시된 prefix를 훨씬 낮은 비용과 지연으로 재사용한다.

v0.14.0 이전, Hermes는 이걸 세션 안에서 썼다: 시스템 prompt + 활성 skill이 캐시되고, 같은 대화 안의 히트가 더 빠르고 더 쌌다. 그런데 /new를 돌리면 캐시가 무효화돼서, 다음 대화가 차가운 상태에서 시작했다.

v0.14.0의 작업은 3개 PR에 걸쳐서, 캐시 TTL을 1시간으로 늘리고 캐시 key가 /new를 건너 살아남게 했다. 새 세션의 첫 응답이 직전 세션이 남긴 따뜻한 캐시의 혜택을 본다. 하루에 짧은 대화를 여러 번 하는 사람한텐 의미 있는 비용·지연 승리다.

캐시는 백그라운드 memory 리뷰 갈래(#25434)에도 적용된다 — memory 파일을 주기적으로 다시 보고 정리하는 그 프로세스가 이제 매 반복마다 풀가격을 내는 대신 같은 prompt 캐시에 올라탄다.

이 영역의 부수 수정: prompt 캐시 key가 날짜만 들어간 타임스탬프를 쓰게 돼서, 시간대 가로지를 때 캐시가 깨지지 않는다. 시끄러웠던 gateway-DB 왕복 로그도 같이 정리됐다 — 관측성도 같이 올랐다.

이 승리들을 어떻게 찾았는가

저자들이 이 특정 핫 패스를 어떻게 찾았는가? 답 두 개:

• •실제 설치에서 콜드 스타트 프로파일링. hermes를 시간 재면서 돌리고, 어느 import가 제일 오래 걸리는지를 추적. 그다음 하나씩 친다.
• •"Hermes가 느린 것 같다"는 사용자 보고. hermes tools All-Platforms 화면이 느리다는 건 구체적인 버그 보고였다 — 일단 떠오르면 수정은 직관적이었다.

마법은 없다. 이 승리들은 python -X importtime, cProfile, 그리고 사람들이 불평하는 걸 듣는 것 — 그걸로 찾을 수 있다.

에이전트 짜는 사람을 위한 교훈

자기 에이전트를 짓고 있다면, v0.14.0 물결은 몇 가지 규칙으로 일반화된다:

1. 1.안 쓰는 건 import 하지 마라. 모든 어댑터와 프로바이더 SDK를 lazy import 해라. import 그래프가 네 콜드 스타트다.
2. 2.안정된 건 다 캐시해라. skills 인덱스, 모델 카탈로그, 인증 토큰. 묵었다고 알려질 때만 다시 가져와라.
3. 3.연결을 풀링해라. 같은 API나 CDP 서버를 세션 안에서 한 번 넘게 호출한다면, 연결을 들고 있어라.
4. 4.독립적인 검사는 병렬로 돌려라. doctor 검사, 헬스 체크, 순서가 안 중요한 거 뭐든.
5. 5.필요 없는 UI는 렌더하지 마라. 환영 배너, 장식적인 출력 — 비대화형 경로에선 스킵해라.

이 중 어느 것도 새로운 게 아니다. 모든 CLI에 적용되는 표준 성능 플레이북이다. v0.14.0의 흥미로운 점은 그 플레이북을 한 릴리스 창 안에 전부 적용했고, 사용자가 업데이트한 순간에 결과가 느껴졌다는 거다.

5월 초에 네 Hermes가 헛돌게 느껴졌다면, v0.14.0이 그 차가운 경로가 사라진 릴리스다.

더 읽기

• •v0.14.0 릴리스 노트 — 성능 섹션
• •PR #22138 — skills 캐시 + 어댑터 lazy import
• •PR #23226 — 180× browser_console
• •PR #23828 — 세션 가로지르는 prompt 캐시
• •Hermes Agent 리포지토리