11. 배포와 운영: Docker, VPS, 원격 백엔드

로컬에서 Hermes를 처음 띄우는 순간은 꽤 짜릿합니다. 바로 말을 걸 수 있고, 파일도 읽히고, 명령도 시킬 수 있으니까요. 그런데 진짜 실사용은 그다음부터 시작됩니다. 노트북 뚜껑을 닫아도 살아 있어야 하고, 새벽에 예약 작업을 처리해야 하고, 텔레그램으로 말을 걸었을 때 바로 응답해야 합니다. 이 단계에서 중요한 질문은 더 이상 "설치됐나?"가 아닙니다.

"Hermes를 어디서, 어떤 방식으로, 얼마나 오래 안정적으로 돌릴 것인가?"

이 장에서는 그 질문에 답합니다. Docker 컨테이너에 넣어 돌리는 방법, VPS에 상주시켜 운영하는 방법, 그리고 Hermes 본체는 한곳에 두되 실제 명령 실행은 SSH·Modal·Daytona 같은 원격 백엔드로 보내는 전략까지 한 흐름으로 정리해 보겠습니다.¹²³

운영 관점에서 먼저 봐야 할 두 가지

배포 이야기를 시작할 때 가장 많이 헷갈리는 부분이 있습니다. Hermes가 사는 곳과 Hermes가 명령을 실행하는 곳은 같을 수도 있고 다를 수도 있다는 점입니다.

예를 들어 이런 구성이 가능합니다.

Hermes 본체는 작은 VPS에서 24시간 돌아갑니다. 그런데 terminal.backend는 ssh로 설정해서 실제 셸 명령은 더 큰 개발 서버에서 실행합니다. 또는 Hermes는 Docker 컨테이너 안에 살고, 무거운 작업만 Modal이나 Daytona 같은 클라우드 샌드박스에서 처리하게 만들 수도 있습니다.¹²

이 구분을 이해하면 배포 판단이 훨씬 쉬워집니다.

즉, Docker는 배포 방식일 수도 있고 터미널 백엔드일 수도 있습니다. 이름은 같아 보여도 역할은 다릅니다. 이 차이를 놓치면 설정이 꼬이기 쉽습니다.¹²

Docker: 가장 현실적인 첫 운영 환경

Hermes를 "항상 켜 두는 서비스"처럼 다루고 싶다면, Docker는 가장 무난한 출발점입니다. 이유는 간단합니다. 설치 환경이 깔끔하게 분리되고, 업그레이드가 쉽고, 무엇보다 재현성이 좋습니다. 어제는 되던 게 오늘은 왜 안 되지, 같은 종류의 고통이 줄어듭니다.¹

공식 Docker 이미지는 상태를 컨테이너 이미지 안에 저장하지 않습니다. 대신 모든 사용자 데이터가 호스트의 한 디렉터리에 모입니다. 컨테이너 내부에서는 /opt/data, 보통 호스트에서는 ~/.hermes를 붙여 쓰는 방식입니다. 그래서 이미지는 갈아 끼워도 세션, 메모리, 스킬, 설정, API 키는 그대로 남습니다.¹

처음 한 번은 대화형으로 설정을 마치는 편이 좋습니다.

mkdir -p ~/.hermes

docker run -it --rm \
  -v ~/.hermes:/opt/data \
  nousresearch/hermes-agent setup

이 과정에서 API 키와 기본 설정이 ~/.hermes/.env, config.yaml 같은 파일에 저장됩니다. 한 번만 해 두면 됩니다.¹

그다음부터는 백그라운드에서 게이트웨이를 상시 실행하면 됩니다.

docker run -d \
  --name hermes \
  --restart unless-stopped \
  -v ~/.hermes:/opt/data \
  -p 8642:8642 \
  nousresearch/hermes-agent gateway run

여기서 --restart unless-stopped가 꽤 중요합니다. 서버가 재부팅되거나 일시적으로 프로세스가 죽어도 자동 복구를 기대할 수 있기 때문입니다. 운영 환경에서는 이런 "작은 끈질김"이 체감 품질을 크게 바꿉니다.¹

Docker에서 꼭 기억할 데이터 원칙

Docker 운영에서 가장 중요한 폴더는 사실상 하나입니다. /opt/data, 즉 호스트의 ~/.hermes입니다. 이 안에 Hermes의 정체성이 거의 다 들어 있습니다.¹⁴

config.yaml에는 모델, 터미널 백엔드, 각종 동작 설정이 들어가고, .env에는 API 키와 비밀 값이 들어갑니다. sessions/는 대화 이력, memories/는 장기 기억, skills/는 익힌 스킬, cron/은 예약 작업, logs/는 운영 로그입니다. 쉽게 말해 이 디렉터리만 잘 보존하면 Hermes의 기억과 습관도 같이 살아남습니다.¹⁴

반대로 이 디렉터리를 안 붙이면 무슨 일이 생길까요? 컨테이너를 지우는 순간 Hermes도 기억상실이 옵니다. 어제의 세션, 학습한 스킬, 저장된 설정이 모두 날아갑니다. 운영에서는 컨테이너보다 볼륨이 더 중요하다는 말을 여기서 실감하게 됩니다.¹⁶

그리고 한 가지 더 조심할 점이 있습니다. 같은 데이터 디렉터리를 두 개의 Hermes 게이트웨이 컨테이너가 동시에 쓰면 안 됩니다. 세션 파일과 메모리 저장소가 동시 쓰기를 전제로 설계되지 않았기 때문입니다. 대시보드처럼 읽기 위주의 보조 컨테이너는 같이 둘 수 있지만, 게이트웨이 본체는 하나만 물려 두는 편이 안전합니다.¹

Docker Compose로 서비스처럼 다루기

테스트가 끝났다면, 실운영에서는 docker run보다 Compose가 더 편해집니다. 서비스 정의가 파일로 남고, 재시작과 로그 확인, 업데이트가 쉬워지기 때문입니다.¹

예를 들면 이런 식입니다.

services:
  hermes:
    image: nousresearch/hermes-agent:<version-tag>
    container_name: hermes
    restart: unless-stopped
    command: gateway run
    ports:
      - "8642:8642"
    volumes:
      - ~/.hermes:/opt/data

운영에서는 latest보다 버전 태그를 고정하는 편이 낫습니다. 갑자기 새 이미지가 내려와 동작이 바뀌는 일을 줄일 수 있기 때문입니다. "항상 최신"은 멋져 보이지만, "항상 예측 가능"이 운영에서는 더 멋집니다.⁶

로그도 훨씬 다루기 쉬워집니다.

docker compose up -d
docker compose logs -f

업데이트도 단순합니다. 새 이미지를 받고 컨테이너를 다시 띄우면 됩니다. 데이터는 볼륨에 남아 있으니, 본체만 갈아입는 셈입니다.¹

docker compose pull
docker compose up -d

Docker 운영에서 자주 부딪히는 문제들

Docker는 편하지만, 완전히 마법은 아닙니다. 몇 가지는 미리 알고 있으면 좋습니다.

첫째, 브라우저 자동화까지 켜면 메모리 사용량이 확 올라갑니다. 공식 권장치는 최소 1GB 메모리, 보통은 2~4GB 정도입니다. 특히 Playwright나 Chromium을 쓰면 적어도 2GB 이상을 염두에 두는 편이 좋습니다.¹

둘째, 브라우저 도구가 이상하게 죽는다면 --shm-size=1g가 필요할 수 있습니다. 브라우저 계열은 공유 메모리를 꽤 먹기 때문입니다.¹

셋째, 권한 문제는 대개 마운트한 호스트 디렉터리 쪽에서 터집니다. 읽기·쓰기 권한이 애매하면 Hermes는 설정 파일도 못 만들고 로그도 못 남깁니다. 컨테이너가 즉시 종료된다면 로그부터 보세요.

docker logs hermes
docker stats hermes

넷째, 포트를 열 때는 신중해야 합니다. 8642는 OpenAI 호환 API와 health endpoint를 노출할 때 쓰이는데, 외부 툴이나 대시보드가 붙어야 할 때만 정말 필요한 경우에만 여는 편이 좋습니다. 인터넷에 대놓고 열어 두는 순간, Hermes는 "편리한 개인 비서"이자 동시에 "매력적인 공격 대상"이 됩니다.¹

VPS: Hermes에게 '집'을 주는 방법

Docker가 방 하나짜리 깔끔한 원룸이라면, VPS는 Hermes에게 아예 주소를 하나 내주는 일에 가깝습니다. 24시간 켜져 있고, 네트워크가 안정적이고, 내 노트북 배터리와 무관하게 살아 있습니다. 텔레그램이나 디스코드 같은 메신저 게이트웨이를 제대로 쓰기 시작하면 VPS의 가치가 확실해집니다.³⁵

VPS 운영의 핵심은 화려한 설치 기술이 아닙니다. 오히려 아주 고전적인 세 가지가 중요합니다.

• 루트 대신 별도 사용자로 실행하기

• SSH와 방화벽을 먼저 잠그기

• Hermes를 서비스처럼 자동 시작되게 만들기

예를 들어 새 서버에서는 hermes 같은 전용 사용자를 만들고, 공개키 기반 SSH를 붙이고, 방화벽은 기본 차단으로 두는 식이 정석에 가깝습니다. 텔레그램 같은 메시징 게이트웨이는 보통 바깥으로 나가는 연결만 있으면 동작하므로, 굳이 추가 inbound 포트를 열지 않아도 되는 경우가 많습니다.⁵

이 운영 감각은 꽤 중요합니다. Hermes는 똑똑하지만, 서버 보안까지 대신 책임져 주지는 않습니다. 문을 잠그는 일은 결국 운영자의 몫입니다.

VPS에 직접 설치할까, Docker를 올릴까

VPS에서는 두 갈래가 있습니다. 하나는 Hermes를 서버에 직접 설치하는 방식이고, 다른 하나는 VPS 위에 Docker를 올리고 그 안에서 Hermes를 실행하는 방식입니다.

직접 설치 방식은 단순합니다. 서버의 파일 구조가 바로 보이고, systemd와 잘 어울립니다. CLI를 자주 다루고, 서버 자체를 익숙하게 관리하는 사람에게는 꽤 편합니다. 반면 Docker 방식은 재현성과 업그레이드가 좋고, 다른 서비스와 충돌을 줄이기 쉽습니다. 여러 앱을 한 VPS에 같이 올리는 사람은 보통 이쪽을 선호합니다.

간단히 정리하면 이렇습니다.

처음 운영이라면 보통 VPS + Docker가 마음 편합니다. 이미 Linux 서비스 운영에 익숙하다면 직접 설치 + systemd도 아주 좋은 선택입니다.¹⁵

VPS 직접 설치 뒤에는 서비스화가 핵심

VPS에 Hermes를 직접 설치했다면, 다음 단계는 반드시 "백그라운드 서비스화"입니다. SSH 세션 하나 열어 두고 hermes gateway를 띄운 채 살아가는 방식은 오래 못 갑니다.

실전에서는 사용자 단위 systemd 서비스로 등록하는 흐름이 자주 쓰입니다.

hermes gateway install
loginctl enable-linger hermes
systemctl --user enable --now hermes-gateway
journalctl --user -u hermes-gateway -f

여기서 enable-linger는 꽤 자주 놓치는 부분입니다. 이 설정이 없으면 로그아웃할 때 사용자 서비스가 같이 죽어 버릴 수 있습니다. 봇이 "왜 아침마다 멈춰 있지?" 싶은 날이 생긴다면, 범인은 의외로 여기 있는 경우가 많습니다.⁷

이 방식의 장점은 분명합니다. 서버가 재부팅돼도 Hermes가 자동으로 올라오고, 로그 확인도 익숙한 Linux 도구로 처리할 수 있습니다. 즉, Hermes가 "터미널 프로그램"에서 "운영 서비스"로 승격되는 순간입니다.⁵⁷

SSH 백엔드: Hermes는 여기 있고, 손은 저기 있는 전략

이제부터는 조금 더 재미있는 이야기입니다. Hermes 자체는 한 서버에 두되, 실제 명령 실행은 다른 머신에서 하게 만들 수 있습니다. 이때 쓰는 대표 방식이 terminal.backend: ssh입니다.²

이 구성은 특히 이런 상황에 잘 맞습니다.

• Hermes 본체는 작은 VPS에 두고 싶다

• 실제 개발 작업은 더 큰 빌드 서버에서 하고 싶다

• 에이전트가 자기 자신이 설치된 서버를 함부로 건드리지 않게 분리하고 싶다

공식 설정은 대략 이런 식입니다.

terminal:
  backend: ssh
  persistent_shell: true

그리고 비밀 값은 .env 쪽에 둡니다.

TERMINAL_SSH_HOST=my-server.example.com
TERMINAL_SSH_USER=ubuntu
TERMINAL_SSH_KEY=~/.ssh/id_ed25519

SSH 백엔드의 매력은 네트워크 경계가 생긴다는 점입니다. Hermes가 명령을 실행해도 그 대상은 원격 서버입니다. 즉, 에이전트 본체와 작업 대상이 자연스럽게 분리됩니다. 보안 감각으로 보면 꽤 좋은 구조입니다.²

또한 기본적으로 지속 셸을 유지할 수 있어서, 작업 디렉터리나 환경 상태가 명령 사이에 이어지기 쉽습니다. 한 번 cd 해 둔 위치가 다음 명령에서도 이어지는 감각이라고 생각하면 됩니다.²

단, SSH는 공짜 편의성이 아닙니다. 키 관리, 원격 서버 권한, 네트워크 안정성, 원격 머신의 패키지 상태까지 함께 운영해야 합니다. Hermes가 똑똑해질수록, 운영자는 "원격 셸 관리자"도 된다는 뜻입니다.

Modal과 Daytona: 서버리스처럼 쓰는 원격 작업장

SSH가 "내가 가진 다른 서버를 빌려 쓰는 방식"이라면, Modal과 Daytona는 "원격 샌드박스나 워크스페이스를 필요할 때 깨워 쓰는 방식"에 가깝습니다. Hermes 공식 문서가 이 둘을 강조하는 이유도 여기에 있습니다. Hermes는 꼭 내 노트북 위에서만 살 필요가 없고, 작업 공간 역시 항상 켜져 있을 필요가 없기 때문입니다.²³

Modal

Modal 백엔드는 격리된 클라우드 샌드박스에서 명령을 실행합니다. CPU, 메모리, 디스크를 비교적 명확하게 설정할 수 있고, container_persistent: true로 두면 세션 종료 시 파일시스템 스냅샷을 저장했다가 다음에 복원할 수 있습니다. 다만 여기서 중요한 건 파일시스템 상태가 이어진다는 뜻이지, 살아 있던 프로세스까지 그대로 이어진다는 뜻은 아니라는 점입니다.²

즉, 패키지를 설치해 둔 흔적이나 작업 파일은 이어질 수 있지만, 백그라운드 서버 프로세스가 영원히 살아 있는 것은 아닙니다. 이 차이를 모르면 "왜 어제 띄운 데몬이 오늘 없지?" 하고 당황하게 됩니다.²

Daytona

Daytona는 관리형 개발 워크스페이스에 더 가깝습니다. container_persistent: true일 때는 삭제 대신 stop/resume 개념으로 다뤄져, 개발 환경을 이어서 쓰는 감각이 좋습니다. 다만 디스크 한도가 있고, 공식 문서 기준 최대 10GiB 제한을 염두에 둬야 합니다.²

이 백엔드는 "Hermes가 클라우드 개발 환경 안에서 계속 이어서 일하게 하고 싶다"는 사람에게 잘 맞습니다. 특히 여러 프로젝트를 원격 워크스페이스 기준으로 굴리는 팀이라면 매력적입니다.²

원격 백엔드에서 알아두면 좋은 동작들

Hermes의 원격 백엔드는 단순히 빈 셸만 띄우는 구조가 아닙니다. 스킬 디렉터리와 필요한 자격 증명 파일을 같이 전달해, 원격 환경에서도 에이전트가 원래 알던 스킬과 인증 정보를 사용할 수 있게 돕습니다. Docker에서는 바인드 마운트로, SSH와 Modal 같은 환경에서는 동기화 방식으로 이 흐름이 이어집니다.¹²

이 말은 곧 이런 뜻이기도 합니다. 로컬에서만 되던 스킬이 원격 백엔드에서도 비교적 자연스럽게 이어질 수 있습니다. 에이전트가 "나는 이 스킬을 안다"는 감각을 환경을 바꿔도 유지하는 셈이죠.¹²

다만 원격 백엔드는 초기 동기화 비용이 있습니다. 파일이 많을수록 첫 준비가 느려질 수 있고, 네트워크 상태에 따라 체감도 달라집니다. 그래서 운영에서는 자주 쓰는 스킬과 워크스페이스를 정리해 두는 습관이 은근히 도움이 됩니다.

어떤 운영 조합이 현실적인가

이쯤 되면 선택지가 많아 보여 오히려 더 헷갈릴 수 있습니다. 그래서 실제로 많이 쓰일 만한 조합을 몇 가지로 줄여 보겠습니다.

1. 가장 무난한 개인용 상시 운영

작은 VPS 하나에 Docker로 Hermes를 띄우고, 게이트웨이를 24시간 켜 둡니다. 텔레그램이나 디스코드에서 말을 걸고, API 서버는 꼭 필요할 때만 엽니다. 이 방식은 단순하고 유지비도 낮습니다.¹⁵

2. 안전한 개발 보조 환경

Hermes 본체는 VPS에 두고, terminal.backend는 docker 또는 ssh로 둡니다. 이렇게 하면 Hermes가 자기 집을 직접 마구 건드리는 일을 줄일 수 있습니다. 코드를 만지는 작업이 많다면 특히 좋은 습관입니다.²

3. 저비용 탄력형 작업 환경

Hermes는 상시 실행하되, 무거운 명령이나 프로젝트 작업은 Modal 또는 Daytona로 넘깁니다. 유휴 시간에는 비용을 줄이고, 필요할 때만 작업 공간을 깨워 쓰는 구조입니다. "항상 켜진 두뇌 + 필요할 때만 켜지는 손"이라고 생각하면 감이 옵니다.²³

4. 팀 운영형 구조

VPS 또는 Docker 호스트에 Hermes를 올리고, 외부 접속은 리버스 프록시나 터널을 통해 제한합니다. 작업 실행은 SSH나 Daytona로 분리해 팀의 실제 개발 환경과 연결합니다. 이 구성은 조금 더 손이 가지만, 역할 분리가 예쁘게 됩니다.

운영에서 진짜 중요한 습관들

배포는 한 번 하지만 운영은 계속합니다. 그래서 마지막으로는 설정값보다 습관이 더 중요합니다.

첫째, 백업입니다. ~/.hermes 또는 Docker의 /opt/data를 정기적으로 백업하세요. 이 안에는 기억, 스킬, 세션, 설정이 다 들어 있습니다. Hermes의 "성장"도 결국 파일로 저장됩니다.¹⁴

둘째, 로그 확인입니다. 뭔가 안 되면 추측보다 로그가 먼저입니다. Docker라면 docker logs, 직접 설치라면 journalctl이 기본 출발점입니다.¹⁷

셋째, 버전 관리입니다. 운영에서는 이미지나 패키지 버전을 함부로 흔들지 않는 편이 좋습니다. 새 버전을 쓰고 싶다면 백업 후 점진적으로 올리세요.¹⁶

넷째, 비밀 값 관리입니다. API 키와 봇 토큰은 .env에 두고 권한을 조여야 합니다. 필요하면 컨테이너 실행 시 -e로 주입해 디스크 저장을 줄일 수도 있습니다.¹⁴

다섯째, 포트 최소화입니다. 메시징 게이트웨이만 쓴다면 외부에 포트를 굳이 열지 않아도 되는 경우가 많습니다. 열어야 할 포트만 열고, 나머지는 닫아 두는 편이 정답에 가깝습니다.¹⁵

마무리: Hermes 운영의 본질은 '계속 살아 있게 하는 것'

Hermes를 잘 쓰는 사람은 설치 명령을 많이 아는 사람이 아닙니다. Hermes가 어디에 살아야 하는지, 어떤 경계 안에서 일해야 하는지, 죽어도 어떻게 다시 살아나게 할지를 아는 사람입니다.

로컬 실행은 출발선입니다. Docker는 가장 쉬운 상시 운영의 문이고, VPS는 Hermes에게 진짜 집을 주는 방법입니다. SSH는 손과 몸을 분리하는 전략이고, Modal과 Daytona는 필요할 때만 깨어나는 원격 작업장을 붙이는 방식입니다.

결국 좋은 운영 구조란 복잡한 구조가 아닙니다. 내가 감당할 수 있을 만큼 단순하면서도, Hermes가 계속 기억하고 계속 일할 수 있는 구조입니다.

Hermes는 한 번 켜는 도구가 아니라, 오래 같이 사는 시스템이니까요.

참고

¹Docker  Hermes Agent

²Configuration  Hermes Agent

³Hermes Agent Documentation  Hermes Agent

⁴Configuration  Hermes Agent

⁵Self-Host Hermes Agent on a VPS

⁶Run Hermes Agent with Docker Compose

⁷Hermes Agent Setup on a Hostinger VPS 8Ubuntu 24.049