지난 여름 한 달 동안 나는 LLM 프로바이더 계정 다섯 개를 열었다. OpenAI, Anthropic, OpenRouter, Fireworks, Together. 10월쯤 되니까 어느 카드가 어느 쪽으로 나가고 있는지 알 길이 없었다. 12월엔 그중 한 곳이 조용히 가격을 바꿨고, 나는 3주 뒤 청구서를 받고서야 알았다.
별로 멋지지 않은 진실이지만, 2026년에 LLM 위에서 뭔가를 굴린다는 건 이런 거다 — 프로바이더 동물원은 한 철 지나갈 일이 아니라 계속 지고 가야 할 조건이다. 매주 새 모델이 나온다. 가격이 움직인다. 무료 티어가 다시 섞인다. 3월에 최강이었던 모델이 5월에는 각주로 밀린다. 에이전트 프레임워크가 설치 시점에 프로바이더를 고정해 버리는 물건이라면, 당신은 몇 달에 한 번씩 세팅을 다시 쌓는 계약에 서명한 셈이다.
Hermes Agent는 첫날부터 정반대 방향에 베팅해 왔다. 프로바이더는 config 값이지, 아키텍처가 당신을 대신해서 내리는 결정이 아니다. 세 개의 기능이 겹겹이 쌓여야 이게 실전에서 굴러간다.
중앙 라우터 (v0.2.0)
바탕에 깔린 건 호출 지점 단 하나다. v0.2.0 런칭 때 이 프로젝트는 중앙 집중식 프로바이더 라우터를 들여왔다 — call_llm() / async_call_llm() 함수 하나, 그리고 에이전트의 모든 부분이 거길 통해 LLM에 닿는다. 비전, 요약, 압축, 트래젝토리 저장, 메인 채팅 루프 — 전부 같은 코드 경로를 탄다.
리팩터링 디테일처럼 들리는 얘기인데, 이런 구조가 없는 에이전트에서 프로바이더를 바꿔 보기 전까지는 그렇게 들린다. 대부분의 프레임워크에는 LLM을 찌르는 지점이 열한 군데쯤 흩어져 있고, 각 지점이 자격 증명을 읽는 방식이 미묘하게 다르다. 하나를 고치면 다른 하나를 잊고, 그렇게 생긴 버그는 눈에 띄지 않는 방식으로 터진다. Hermes는 "그 지점이 원래부터 하나뿐"이게 만들어서 이 문제를 뿌리에서 없앴다.
폴백 체인 (v0.6.0)
2주 뒤 v0.6.0이 그 위에 두 번째 층을 얹었다 — 순서가 있는 폴백 프로바이더 체인이다. config.yaml에 프로바이더를 나열해 두면, 1순위가 에러를 뱉을 때(429 레이트 리밋, 일시적인 500, 닿지 않는 엔드포인트 같은 것들) Hermes가 알아서 체인의 다음 놈으로 넘어간다.
중요한 건 이게 라운드로빈이 아니라 순서 기반이라는 점이다. 당신이 선호도와 백업을 직접 고른다. 전형적인 구성은 OpenRouter를 싼 기본값으로 두고, Anthropic 직결을 안정적인 백업으로, Nous Portal의 무료 티어를 최후의 비상 폴백으로 놓는 식이다. 체인 맨 위가 기분이 나쁜 날이어도 당신은 알아차리지 못한다. v0.6.0은 동시에 은근한 버그 하나도 잡았다 — hermes model로 프로바이더를 갈아탈 때 api_mode가 chat_completions로 박혀 있던 걸, 이제는 전환 시점에 오래된 값을 지워 주도록 바꿨다. 덕분에 Anthropic 호환 엔드포인트가 전환 후에 수수께끼의 404를 되돌려 주는 일이 사라졌다.
자격 증명 풀 (v0.7.0)
복원력에 초점을 맞춘 v0.7.0은 세 번째 층을 쌓았다 — 같은 프로바이더 내부의 자격 증명 풀이다. 여기서의 핵심 인식은 이렇다. "내가 쓰는 메인 프로바이더"와 "그 프로바이더에서 내가 들고 있는 특정 API 키"는 전혀 다른 이야기다. 당신에게 Anthropic 키가 세 개 있을 수 있다 — 개인용, 팀용, 그리고 두 번째 계정에 끼워 둔 백업 — 그리고 당신은 Hermes가 그 순간 제일 한가한 키를 쓰길 원한다.
세팅 마법사나 credential_pool 블록으로 이들을 선언해 두면, Hermes는 기본적으로 least_used 전략으로 키를 고른다. 어느 키가 401을 뱉으면 풀이 자동으로 다음 키로 돌아가고, 죽은 키에는 쿨다운 기간 플래그를 달아 둔다. 구현 자체가 스레드 세이프라서, CLI, 텔레그램 게이트웨이, cron 잡이 같은 풀을 공유해도 서로를 밟지 않는다. v0.7.0은 또 폴백 프로바이더 전환이 일어나도 풀의 상태가 살아남도록 했다 — 메인 프로바이더에서 429를 맞았다고 해서, "어느 키가 지쳐 있는가"에 대한 풀의 기억까지 같이 날려 먹지는 않는다.
이 계층이 왜 잘 통하는가
여기까지 나온 기능들은 각자 좁은 문제 하나씩만 푼다. 그런데 합쳐 놓으면 강력하게 느껴진다. 세 층이 서로 겹치지 않고 깔끔하게 쌓여 있기 때문이다.
- •라우터 덕분에 어떤 프로바이더를 쓸지를 한 곳에서 바꿀 수 있다.
- •폴백 체인 덕분에 재시작 없이 프로바이더 수준의 장애를 처리할 수 있다.
- •자격 증명 풀 덕분에 한 프로바이더 안에서 키 수준의 장애와 부하를 처리할 수 있다.
그리고 CLI에서는 hermes model 하나로 위 어느 계층이든 손으로 설정 파일을 건드리지 않고 다시 구성할 수 있다. 결과적으로 새 모델이 나왔을 때 — 누가 내놓든, 이름이 뭐든, 가격이 어떻든 — 갈아타는 비용은 "설정 한 줄 고치기"다. "내 어시스턴트를 다시 설계하기"가 아니다. 여러 세대의 모델을 건너며 살아남을 작정인 프로젝트에게, 이건 아마도 진짜로 중요한 유일한 아키텍처 결정이다.