Hermes Agent를 깔면 어디든 sandbox 설정이 따라온다. 이 설정이 shell 명령이 실제로 어디서 실행되는지를 정한다. 무게가 가볍지 않은 선택이다: 잘못된 명령의 폭발 반경, 에이전트의 체감 속도, 활성 시간당 지불할 돈 — 다 여기서 갈린다.
Hermes는 7개의 백엔드를 출하한다. README가 줄세워 놓은 게 local, docker, ssh, singularity, modal, daytona, vercel이다. v0.14.0이 Vercel Sandbox를 더해서 라인업이 채워졌다. 의사결정 트리를 본다.
7개 백엔드, 한 표로 한눈에
| 백엔드 | 격리 | 지연 | 비용 | 영속성 | 잘 어울리는 곳 |
|---|---|---|---|---|---|
| local | 없음 | <10 ms | 무료 | 있음 (네 디스크) | 버려도 되는 VM에서 혼자 작업 |
| Docker | 컨테이너 | 약 50 ms | 무료 | 컨테이너 단위 | 개발 박스의 기본값 |
| SSH | 원격이 하는 만큼 | 원격 지연 | 원격 비용 | 있음 | 남의 박스에서 도는 에이전트 |
| Singularity | HPC 컨테이너 | 약 100 ms | 무료 | 컨테이너 단위 | HPC 클러스터, 과학 계산 |
| Modal | 서버리스 컨테이너 | 콜드 약 200 ms | 활성 초당 과금 | snapshot 가능 | 버스트형 계산, GPU 작업 |
| Daytona | 서버리스 워크스페이스 | 콜드 약 300 ms | 활성 초당 과금 | 아이들이면 동면 | 오래 살아 있는 에이전트 환경, 아이들 비용 거의 0 |
| Vercel Sandbox | 서버리스 컨테이너 | 콜드 약 200 ms | 활성 초당 과금 | 임시 | 웹 툴링, JS 비중 큰 워크플로우 |
local과 docker는 무료고 네 머신에서 돈다. 나머지 5개는 다른 곳에서 돈다 — 지연도 돈도 내고 있지만, 대신 뭔가를 사오는 거다.
하나씩 — 언제 어느 걸 고를까
local — "이 머신에서 이 에이전트를 신뢰한다"
에이전트가 네 사용자 권한으로, 네 파일시스템 위에서 명령을 직접 돌린다. 격리 0. 에이전트가 rm -rf ~/code를 결심하면 진짜 그렇게 된다. 프롬프트 인젝션이 도구 출력으로 따라 들어오면, 그 주입된 명령도 그대로 실행된다.
이게 맞는 자리: 버려도 되는 VM에서 작업 중이고, 에이전트가 하는 일의 폭발 반경이 어차피 네가 손으로 했어도 같은 수준이고, 안전 마진보다 지연 0이 더 중요할 때.
이게 틀린 자리: 거의 그 외 전부.
docker — 맞는 기본값
네 머신 위의 컨테이너, Linux 네임스페이스로 격리. 에이전트가 보는 파일시스템은 컨테이너의 그것이고, 진짜 /home은 네가 마운트하지 않는 한 안 보인다.
hermes config set sandbox docker와 hermes setup이 이미지를 끌어와서 구성한다. 그 뒤로 shell 도구 호출은 다 컨테이너를 거친다.
사용자의 80%한테 맞는 기본값이다. 지연 오버헤드(명령당 약 50 ms)는 채팅 체감엔 보이지 않는다. 격리가 충분히 세서, 에이전트가 rm -rf /를 돌려도 컨테이너의 뷰만 날린다, 그리고 컨테이너 자체가 일회용이다. 디버그가 필요하면 docker exec로 들어갈 수 있다.
ssh — "에이전트는 다른 박스에 산다"
에이전트의 shell 도구가 SSH로 원격 호스트에서 실행된다. 로컬의 Hermes 프로세스는 클라이언트고, 작업은 원격에서 일어난다.
이게 맞는 경우: 에이전트의 일이 원격에 속하는 인프라 작업일 때 — 서버에 배포, 운영 로그 디버그, 마이그레이션 실행. 로컬 샌드박스는 필요 없다, 호스트 자체가 샌드박스니까.
원격은 에이전트한테 shell 접근을 줘도 괜찮은 호스트여야 한다. SSH 자격증명을 운영 자격증명처럼 다뤄라 — 사실 같으니까.
singularity — HPC 클러스터
Singularity(지금은 Apptainer)는 HPC 클러스터가 실제로 쓰는 컨테이너 런타임이다 — Docker는 호스트에서 root를 요구하고, HPC 환경은 그걸 안 준다. Hermes를 연구 클러스터에서 돌리는 거라면 — SLURM 스케줄, Docker 없음, GPU 잔뜩 — 여기가 맞다.
"HPC"나 "Singularity"가 무슨 말인지 모르겠으면 이 항목은 건너뛰어라.
modal — 버스트형 계산, 특히 GPU
Modal은 서버리스 컨테이너 플랫폼이다. Hermes는 명령마다(혹은 세션마다 재사용해서) Modal 컨테이너를 띄우고, 명령을 돌리고, 정리한다. 활성 계산 초당 과금. GPU 티어도 있다.
Docker를 이기는 자리: 에이전트가 GPU를, 혹은 로컬 박스의 한계를 넘는 계산 자원을 필요로 할 때. 다른 서버리스를 이기는 자리: 콜드 스타트가 약 200 ms로 채팅 페이스의 도구 사용엔 받아들일 만하고, 스냅샷팅도 괜찮아서 세션 중간 상태가 적당히 살아남는다.
daytona — 오래 살고, 아이들에 거의 0
Daytona의 결정타는 동면이다. 네 에이전트 환경은 아무 일도 없을 때 잠들고, 요청이 오면 수백 ms 안에 깬다. 활성 초만 내고, 아이들 초엔 안 낸다.
실용적 효과는: 네 dotfile, 네 skill, 진행 중인 작업을 그대로 안고 있는 "내 Hermes" 환경을, 거의 0 비용으로 수개월 살려둘 수 있다 — 쓸 때만 내니까.
이게 맞는 자리: 노트북에 얹지 않고도 "어딘가에 사는" 에이전트가 갖고 싶을 때. 긴 아이들 뒤 첫 요청은 약 300 ms로 깨우고, 그 뒤 요청은 컨테이너 속도다.
vercel — Vercel Sandbox (v0.14.0)
가장 새 백엔드, v0.14.0에 추가. Modal과 같은 서버리스 컨테이너 모델인데 Vercel 인프라 위에서 돈다. 배포 타깃이 이미 Vercel이면, 에이전트 샌드박스를 같은 프로바이더로 두는 게 마찰이 가장 적다.
잘 어울리는 곳: 에이전트 환경이 운영 배포 환경과 거울처럼 똑같길 원하는 JS 비중 큰 워크플로우.
갈아타는 법
hermes config set sandbox docker
# 또는: local, ssh, singularity, modal, daytona, vercel
자격증명이 필요한 백엔드(ssh / modal / daytona / vercel)는 hermes setup이 물어본다. 또는 문서에 맞게 hermes config set으로 직접 설정해도 된다.
세션별로 임시 오버라이드도 된다: hermes --sandbox modal로 GPU가 필요한 단일 실행을 돌리고, 그 뒤엔 기본 sandbox로 돌아온다.
그냥 샌드박스 없이 가도?
샌드박스를 통째로 끌 수도 있다(local 백엔드). 그래도 Hermes는 그 위에 명령 승인 워크플로우 한 겹을 덧붙인다: 위험한 명령들 — rm -rf, curl | sh, /etc 건드리는 거 — 은 실행 전에 명시적으로 승인을 묻는다. v0.14.0이 이 층을 강화했다 — dangerous-command 우회 3건을 막고 sudo 무차별 대입 차단을 추가했다(#23736, #26829). 그래서 local도 "아무것도 없는" 건 아니다 — "더 가벼운 격리지만 진짜 프롬프트는 있는" 상태다. 층별 분해는 보안 모델 글을 봐라.
실제 추천
대부분의 사람한테, 대부분의 경우: Docker.
에이전트가 네 노트북이 아닌 서버에서 살았으면 좋겠다: Daytona (아이들 때 동면 속성이 진짜 마법 같고, 비용 계산도 맞다).
GPU 워크로드가 있거나 에이전트가 진짜 계산을 한다: Modal.
연구원이 클러스터에서 굴린다: Singularity.
local은 트레이드오프를 이해할 때만. SSH는 일이 원격에 속할 때만. Vercel은 이미 Vercel 위에 있다면.