나는 한 달에 5달러를 내고 대부분의 시간 동안 아무 일도 하지 않는 VPS 한 대를 돌리고 있다. 램 1기가, 공유 CPU 한 개, SSD 20기가, 퍼블릭 IPv4 주소 하나. 어느 VPS 업체에서든 대략 이 사양의 머신을 팔고 있고, 개인 프로젝트 하나라도 돌려 본 적이 있다면 아마 어디쯤에 여유 자원이 남아 있는 이런 박스 한 대가 이미 놀고 있을 거다.
지난달에 나는 그걸 Hermes Agent 게이트웨이로 바꿔 버렸다. 지금 그 머신은 텔레그램에서 내게 답을 해 주고, cron 스케줄에 맞춰 친구들과 공유하는 디스코드 채널에 요약을 올려 주고, IMAP 수신함을 지켜보고 있다. 그리고 이 문장을 쓰고 있는 이 순간 — 램 약 320메가, CPU 2% 미만을 먹고 있다. 커피 한 잔 값으로, 꺼지지 않는 어시스턴트가 한 명 생긴 셈이다.
이 글은 그 세팅에 대한 실전 가이드이자, 작은 머신 위에서 실제로 체감을 좌우하는 몇 안 되는 결정들에 대한 이야기다.
진짜로 필요한 건 뭔가
Hermes를 돌리는 데는 평판 괜찮은 어느 업체든(Hetzner, DigitalOcean, Vultr, Linode, Contabo, OVH — 다들 비슷한 사양을 비슷한 값에 판다) 5달러 티어 VPS면 충분하다. 봐야 할 숫자는 이거다.
- •램 최소 1기가. Hermes의 파이썬 프로세스 자체가 기동 직후에 200~300메가 근처에 앉는다. 텔레그램, 디스코드, 슬랙 같은 게이트웨이 스레드마다 소소한 추가 오버헤드가 붙는다. 여기에 언어 모델 API 라이브러리가 응답을 버퍼링할 여유, 가끔씩 큼직한 데이터를 불러오는 툴이 쓸 여유도 남겨 둬야 한다.
- •디스크 최소 10기가. Hermes 본체, 의존 패키지 전부, 세션 DB, cron 이력, 로그 파일을 다 합쳐도 5기가 아래로 넉넉하게 들어간다. 나머지는 전부 여유분이다.
- •아웃바운드 HTTPS. 네트워크 요구 사항은 이거 하나뿐이다. 선택 사항인 OpenAI 호환 API 서버를 띄우거나, 텔레그램 어댑터를 폴링 대신 웹훅 모드로 돌리는 게 아니라면 인바운드 포트를 열 필요가 없다.
- •systemd가 있는 최신 리눅스 배포판. Ubuntu 22.04나 24.04가 가장 무난한 기본값이다. Debian 12도 된다. 게이트웨이 서비스 마법사는 systemd를 써서 Hermes를 상시 시스템 서비스나 사용자 서비스로 등록한다.
이 목록에서 눈에 띄게 빠져 있는 것들: GPU, 특정한 CPU 아키텍처(AMD, Intel, ARM64 VPS 전부에서 Hermes는 잘 돈다), 도메인, 리버스 프록시, 그 밖에 뭐든. 게이트웨이는 기본적으로 아웃바운드만 쓴다.
설치, 그리고 그게 무슨 일을 하는가
첫 번째 명령은 hermes setup이다. 이게 마법사인데, 어떤 프로바이더를 쓸지(OpenRouter, Nous Portal, Anthropic, OpenAI, Hugging Face, 또는 로컬/커스텀 엔드포인트) 물어보고, API 키 붙여 넣는 걸 거들어 주고, 기본 모델을 고르게 한 다음 그 결과를 ~/.hermes/config.yaml에 써 넣는다.
작은 머신에서 두 번째로 중요한 건 hermes gateway install이다. 이 명령이 Hermes를 systemd 서비스로 만들어 주기 때문에, 재부팅에도 살아남고 크래시가 나도 알아서 되살아난다. 범위는 user(서비스가 네 로그인 사용자로 돌고, sudo가 필요 없다)와 system(서비스가 로그인 이전에 시작된다, 헤드리스 박스에 유용)에서 고를 수 있다. 5달러 VPS라면 대체로 user 범위가 맞다. 헤드리스 환경에서 Hermes는 systemd linger를 자동으로 켜 주기 때문에, 네가 연결을 끊고 나가도 서비스는 계속 돌아간다.
그 다음은 hermes gateway enable telegram(또는 discord, slack, signal, matrix 등등)으로 플랫폼을 하나씩 붙여 나가면 된다. 각 어댑터는 플러그인이라서, 플랫폼 하나만 돌려도 되고 여덟 개를 한꺼번에 돌려도 된다. 플랫폼을 하나 더 붙일 때의 메모리 비용은 아주 작다 — 파이썬 오브젝트 몇 메가에, 그 플랫폼 SDK가 내부적으로 먹는 버퍼만큼이다.
작은 박스에서 진짜로 중요한 결정
싸구려 VPS에서 체감을 결정짓는 건 결국 세 가지 선택이다.
모델 선택. VPS 위 에이전트의 메모리 발자국은 모델 크기에 달려 있지 않다. 추론은 이 박스에서 벌어지지 않기 때문이다. 하지만 응답 하나하나의 레이턴시와 비용은 모델에 달려 있다. 개인 게이트웨이의 스위트 스팟은 보통 중간 크기의 빠른 모델(Claude Sonnet, GPT-4.1 mini, Gemini Flash, 또는 보조 작업용으로는 Nous Portal의 무료 티어 MiMo v2 Pro)을 기본값으로 두고, 필요할 때 /model 커맨드로 더 큰 모델로 올려 쓰는 쪽이다. 라이브 모델 전환 덕분에 이걸 대화 도중에, 뭐 하나 재시작하지 않고 그냥 할 수 있다.
컨텍스트 압축. 기본값으로 충분하다. Hermes는 컨텍스트 윈도우가 차오르면 알아서 대화 이력을 먼저 압축하고, 압축된 요약은 캐시에 올라간다. 작은 VPS에서 이게 중요한 이유는 컨텍스트 압축이 로컬에서 돌면서 CPU를 쓰기 때문이다 — 압축을 켜 두면 긴 대화도 여전히 빠르게 돌아가고, 한 턴에 토큰 예산을 통째로 태워 먹을 일도 줄어든다.
자격 증명 풀. API 키를 여러 개 들고 있는 사람(친구와 프로바이더 계정을 나눠 쓰거나, 여러 무료 티어를 돌려 쓰는 사람이 흔히 그렇다)을 위해, Hermes에는 같은 프로바이더 내 자격 증명 풀 기능이 있다. 레이트 리밋이나 401 에러가 뜨면 자동으로 다음 키로 돌려 준다. 작은 VPS 위에서 이건 사실상 N개의 무료 티어를 "언제나 쓸 수 있는 한 개의 키"로 묶어 주는 장치이고, 상시 대기 어시스턴트라면 정확히 원하는 그림이다.
이게 왜 굴러가는가
5달러짜리 VPS가 진짜 AI 어시스턴트를 품을 수 있는 이유는, Hermes가 영웅적으로 최적화돼서가 아니다. 이 아키텍처가 제일 무거운 부분 — 언어 모델 — 을 남한테 맡기고, 조율, 기억, 툴 실행 로직만 로컬에 남긴다는 설계 덕분이다. 이 한 번의 분리가 월 비용을 납득할 수 있는 수준으로 내려 주고, 아주 작은 머신 한 대면 충분하게 만든다.
예전에는 어시스턴트를 자기 손으로 호스팅한다는 말이 곧 모델을 직접 돌린다는 뜻이었다. 지금은 아니다. 지금 그건 모델에게 "뭘 할지" 일러 주는 쪽을 돌린다는 뜻이다.