노트북은 조종석, 일은 서버가 합니다 — Hermes Desktop 앱을 24시간 VPS에 원격 연결하는 법

들어가며 — 데스크톱 앱이 생겼는데, 왜 로컬만으로는 아쉬울까

노트북 뚜껑을 닫으면 하던 일이 멈춥니다. 회의하러 자리를 비운 사이 돌려두고 싶던 리서치도, 밤사이 정리돼 있으면 좋겠는 자료도, 결국 내가 노트북 앞에 앉아 있어야만 돌아갑니다.

Hermes Agent에 최근 데스크톱 앱이 생기면서 이 그림이 한 번 바뀌었습니다. 터미널이 아니라 익숙한 앱 화면에서 대화하고, 여러 세션을 띄우고, 만들어진 파일을 바로 열어 볼 수 있게 됐죠. 처음 켜면 앱이 내 컴퓨터에서 쓸 로컬 백엔드를 자동으로 띄웁니다. 그래서 서버를 따로 만들지 않아도 곧바로 대화해 볼 수 있습니다. 여기까지만 보면 클로드코드나 코덱스처럼 "앱 하나 깔고 쓰는" 도구와 비슷합니다.

그런데 Hermes를 쓰는 이유가 24시간 켜두고 직원처럼 맡기는 것이었다면, 로컬 PC 한 대만으로는 금방 아쉬워집니다. 노트북은 자고, 들고 다니고, 무거운 작업을 시키면 정작 내 작업용 컴퓨터가 버벅이니까요. 그래서 많은 사람이 택하는 구조가 이겁니다. 앱은 노트북에 두고, 실제로 일하는 엔진은 24시간 켜진 다른 컴퓨터에 올려서 원격으로 붙이는 방식. 이 글이 바탕으로 삼은 영상에서는 그 엔진을 Hostinger VPS에 올렸습니다.

📌 이 글이 바탕으로 삼은 영상은 Hostinger의 지원을 받아 제작되었습니다. 아래에 나오는 Hostinger 링크와 쿠폰은 제휴 안내이며, 가격·할인·플랜 같은 숫자는 시점에 따라 바뀌니 실제 값은 현재 페이지에서 확인하세요.

한 장으로 보는 구조 — 노트북=조종석, VPS=엔진, Tailscale=전용 통로

먼저 오늘 만들 그림을 세 덩어리로 나눠 보겠습니다. 이 셋만 머릿속에 넣어 두면 나머지는 다 이 그림의 세부 사항입니다.

그림으로 그리면 이렇게 됩니다.

[내 노트북]
  Hermes Desktop 앱  ← 화면과 조작만
        │
        │  Tailscale 사설망 (내 기기끼리만)
        ▼
[Hostinger VPS · 24시간]
  Hermes 백엔드  ← 실제 실행·기억·도구·파일

비유하자면 24시간 켜진 서버룸에 상주하는 직원 한 명을 두고, 제 노트북 화면은 그 직원을 지켜보는 관제 화면인 셈입니다. 화면은 노트북에서 보고, 일은 서버가 하고, 둘 사이는 아무나 못 들어오는 전용 통로로 잇습니다.

내 PC로 충분할 때 vs 24시간 서버가 필요할 때

"굳이 서버까지? 내 컴퓨터에서 돌리면 안 되나?" — 당연히 드는 질문입니다. 답부터 말하면, 가볍게 써볼 거라면 로컬로 충분하고, 직원처럼 맡길 거라면 24시간 켜진 머신이 낫습니다.

로컬 자체가 위험하다는 얘기가 아닙니다. 로컬은 언제든 써볼 수 있고 시작하기도 제일 쉽습니다. 다만 밖에서 접속하겠다고 내 노트북 백엔드를 공개 인터넷에 직접 열어버리면 그때부터 보안과 관리가 골치 아파집니다. 그래서 아예 처음부터 24시간 켜진 서버에 엔진을 두는 쪽이 깔끔합니다.

그럼 그 "외부 머신"을 뭘로 하느냐. 크게 두 갈래입니다.

VPS는 쉽게 말해 하드웨어를 사지 않고, 데이터센터에 있는 24시간 켜진 컴퓨터 한 대를 빌리는 것입니다. 기계를 집에 두는 부담 없이 "항상 켜진 내 서버"를 하나 갖는 거죠. 이 글에서는 Hostinger VPS를 씁니다. Hermes 배포가 클릭 몇 번으로 되는 편이라 처음 하는 분에게 마찰이 적습니다.

Hostinger VPS에 Hermes를 올리는 큰 흐름

여기부터는 서버 쪽입니다. 세부 버튼 이름과 가격은 화면마다 다를 수 있으니, 각 단계가 뭘 하는지만 잡으면 됩니다.

플랜을 고를 때는 두 가지만 보면 됩니다. 하나는 사양 — 외부 모델을 주로 쓴다면 과하게 큰 사양은 필요 없지만, 서버에서 브라우저 자동화처럼 무거운 작업까지 돌릴 생각이면 넉넉히 잡는 게 좋습니다(공식 튜토리얼은 브라우저 작업까지 하려면 2 vCPU / 8GB RAM 정도를 권장합니다). 다른 하나는 기간 — 오래 켜두고 쓰는 서버라 계약 기간이 비용에 크게 작용합니다. 계속 쓸 계획이면 긴 기간이, 짧게 시험만 할 거면 짧은 기간이 맞습니다.

결제 화면에는 쿠폰 입력란이 있습니다. 이 글이 참고한 영상에는 시청자용 쿠폰 코드 CITIZENDEV9C가 준비돼 있습니다. 다만 할인 규모나 가격은 시점에 따라 바뀌니, 정확한 숫자는 결제 화면에서 직접 확인하세요. (제휴 링크·쿠폰은 이 글 맨 아래 출처 표에도 정리해 뒀습니다.)

결제가 끝나면 서버 위에 Hermes를 올릴 차례입니다. 여기가 제일 편한 부분인데, 터미널을 길게 칠 필요가 없습니다. Hostinger 관리 패널의 **Docker Manager(또는 Application Catalog)**에서 검색창에 Hermes를 치면 Hermes Agent가 뜹니다. 선택하고 배포를 누르면, 배포 도중 관리자 아이디와 비밀번호를 만들게 합니다. 이건 나중에 이 서버의 Hermes에 로그인할 때 쓰는 계정이니 잘 보관해 두세요. 배포가 끝나면 Docker가 뒤에서 컨테이너를 알아서 띄우고, 상태가 실행 중으로 바뀌면 준비가 된 겁니다.

💡 Hostinger에서 VPS를 살 때 nexos.ai 크레딧을 함께 넣으면 Claude·Gemini·GPT 같은 모델을 하나의 게이트웨이로 쓰도록 키가 자동으로 채워지고, Oxylabs 크레딧을 넣으면 웹 검색·수집이 붙습니다. 크레딧을 안 붙여도 배포는 되고, 그때는 본인이 쓰는 모델 제공자를 직접 연결하면 됩니다.

한 가지 기억해 둘 게 있습니다. Hermes Desktop 앱은 CLI로 쓰던 Hermes와 다른 별개 제품이 아닙니다. 공식 문서 표현대로 "CLI·게이트웨이와 같은 config, 같은 API 키, 같은 세션, 같은 스킬, 같은 메모리"를 그대로 쓰는, 같은 에이전트의 GUI입니다. 가벼운 복제품이 아니라 같은 직원을 화면으로 보는 창구라고 생각하면 됩니다.

Desktop 앱을 원격 백엔드에 붙이는 핵심 — Remote Gateway는 메신저 연결이 아닙니다

이제 노트북으로 넘어옵니다. Hermes 공식 사이트에서 데스크톱 앱을 받아 실행하면, 로컬 백엔드가 자동으로 떠서 바로 대화해 볼 수 있습니다. 프로필을 만들고, 성격과 업무 기준을 적고, 모델을 고르고, 채팅창에 바로 말을 거는 것까지 로컬에서 다 됩니다.

그런데 우리가 원한 건 24시간 서버에서 도는 엔진이었죠. 그래서 연결 대상을 로컬에서 원격 백엔드로 바꿔야 합니다. 여기서 딱 하나, 헷갈리기 쉬운 지점을 먼저 정리하고 가겠습니다.

⚠ Remote Gateway는 Telegram/Slack 같은 메신저를 붙이는 게 아닙니다. 이름이 비슷해서 헷갈리는데, 둘은 역할이 다릅니다.

• Remote Gateway = 내 Desktop 앱이 원격 Hermes 백엔드(서버 엔진)의 웹 주소에 붙는 설정. 오늘의 주인공.
• Telegram/Slack 게이트웨이 = 메신저로 Hermes에게 말 걸고 보고받는 채널 연결. 이건 서버에서 계속 켜두는 별도 프로세스입니다.

이 구분이 중요한 이유가 있습니다. 원격 연결이 되려면 Desktop이 붙을 백엔드가 서버에서 실제로 켜져 있어야 합니다. 공식 문서도 "원격 백엔드는 서버에서 돌고 있는 hermes serve 프로세스이고, Desktop 앱이 그걸 대신 켜주지는 않는다. 사람이(또는 자동 실행 설정이) 서버에서 그 백엔드를 계속 띄워 둬야 앱이 거기에 붙는다"고 못을 박습니다. Hostinger 템플릿에서는 이 백엔드(대시보드)가 컨테이너 안에서 자동으로 함께 떠 있고, 직접 다른 서버에 올릴 때는 hermes serve를 켜 두면 됩니다.

여기서 중요한 건 주소의 정체입니다. Desktop에 넣는 값은 SSH 접속 주소도, Telegram/Slack 연결도 아닙니다. 서버에서 켜져 있는 Hermes 백엔드의 웹 주소입니다. 이제 이 주소를 Tailscale 안에서만 열리게 만들면 됩니다.

Tailscale 사설망 + Docker 포트 매핑 — {{TAILSCALE_IP}}:9119:4860의 뜻

노트북의 조종석을 서버의 엔진에 붙일 차례인데, 그냥 붙이면 안 되고 내 기기끼리만 통하는 길로 붙여야 합니다. 여기서 Tailscale을 씁니다.

Tailscale을 한 문장으로 하면, **"서버를 공개 인터넷에 여는 게 아니라, 내 기기끼리만 통하는 전용 통로를 까는 것"**입니다. 회사로 치면 아무나 못 들어오는 사내 전용망을 하나 만들고, 거기에 내 노트북과 서버만 넣는 거예요. 포트를 새로 열거나 고정 IP를 사거나 인증서를 만들 필요 없이, 양쪽에 Tailscale을 깔고 같은 계정으로 로그인하면 끝입니다.

1) 노트북과 서버를 같은 사설망에 넣기

여기서 한 가지만 정확히 짚겠습니다. 서버에 Tailscale을 까는 건 Hermes 컨테이너 안이 아니라, VPS라는 '건물 자체'의 관리실인 root 터미널입니다. Hostinger 관리 패널에서 그 VPS의 터미널을 열면 root@...로 시작하는 화면이 뜨는데, 거기서 아래 네 줄을 실행합니다.

curl -fsSL https://tailscale.com/install.sh | sh
tailscale up
tailscale status
tailscale ip -4

첫 줄은 Tailscale 공식 설치 명령, 둘째 줄은 이 서버를 사설망에 올리는 명령입니다. tailscale up을 치면 로그인 링크가 뜨는데, 노트북에서 로그인했던 것과 똑같은 계정으로 승인해야 합니다. 계정이 다르면 노트북과 서버가 서로 다른 사설망에 들어가 만나지 못합니다. 셋째 줄로 둘이 같은 망에 보이는지 확인하고, 넷째 줄로 이 서버가 사설망 안에서 받은 주소를 확인합니다. 보통 100.으로 시작하는 값 하나가 나오는데, 이걸 잘 적어 두세요. 아래 예시에서는 실제 주소 대신 {{TAILSCALE_IP}}라고 쓰겠습니다. 여러분 화면에서는 tailscale ip -4로 나온 값을 넣으면 됩니다.

2) 그 통로 위에 Desktop이 들어올 '문' 만들기

사설망은 깔렸습니다. 이제 그 길 위에서 Desktop 앱이 Hermes 컨테이너 안으로 들어올 수 있게 문패를 붙여야 합니다. Hostinger Docker Manager의 YAML Editor에서 ports 항목에 한 줄을 더합니다.

ports:
  - "{{TAILSCALE_IP}}:9119:4860"

어렵게 보이지만 세 덩어리로 읽으면 됩니다.

그러니까 이 한 줄은 **"내 노트북이 {{TAILSCALE_IP}}의 9119번 문으로 들어오면, 그 요청을 컨테이너 안 4860번 자리로 넘겨줘"**라는 안내판입니다. 개발자들은 이걸 "포트를 매핑한다"고 부르는데, 비개발자 입장에서는 그냥 바깥 주소와 안쪽 직원 자리를 이어주는 문패라고 보면 됩니다.

💡 9119는 Hermes 대시보드/hermes serve가 기본으로 쓰는 포트입니다. 다만 바깥과 안쪽 번호를 어떻게 잇는지는 환경마다 다릅니다. Hostinger의 Docker 템플릿과 실제 설치 화면에서는 바깥 9119를 컨테이너 안쪽 4860에 잇는 방식이 쓰였습니다. 템플릿이 바뀌면 내부 포트가 달라질 수 있으니, Docker Manager에 이미 표시된 ports 값을 보고 같은 방식으로 맞추면 됩니다. {{TAILSCALE_IP}} 자리에는 tailscale ip -4로 나온 값을 넣습니다.

YAML을 저장하고 프로젝트를 다시 배포(Redeploy)하면, Desktop에 넣을 주소가 완성됩니다.

http://{{TAILSCALE_IP}}:9119

3) Desktop에 원격 주소 넣기

이제 노트북 Hermes Desktop으로 돌아와 Settings → Gateway → Remote gateway를 찾습니다. Remote URL 칸에 방금 만든 http://{{TAILSCALE_IP}}:9119를 그대로 붙여넣습니다. 주소를 넣으면 앱이 그 백엔드가 어떤 로그인 방식을 쓰는지 감지해서 로그인 버튼을 띄우는데, 여기에 배포할 때 만든 관리자 아이디·비밀번호로 로그인하고, 연결을 테스트한 뒤 저장하면 조종석이 서버 엔진으로 넘어갑니다.

한 서버에 Hermes 컨테이너를 여러 개 띄웠다면, 바깥쪽 문 번호만 다르게 잡아 골라 붙을 수 있습니다. 예를 들어 첫 번째는 9119, 두 번째는 9220처럼요. 컨테이너 안쪽 자리(4860)는 각자 공간이 따로라 같아도 되지만, VPS 바깥에서 보이는 문 번호는 겹치면 안 됩니다. 결국 Remote URL이 "어느 서버 직원 방으로 들어갈지 고르는 스위치" 역할을 합니다.

보안 기준 — 내 기기끼리면 비밀번호, 공개하면 OAuth, 무인증 공개는 금지

연결까지 됐으니 로그인 방식을 고릅니다. Hermes 공식 문서 기준은 꽤 분명합니다.

Tailscale처럼 내 기기끼리만 닿는 길이면 아이디·비밀번호로 시작할 수 있고, 공개 인터넷에서 바로 닿는 주소라면 OAuth를 써야 합니다.

이번 글의 경로는 첫 번째입니다. Desktop은 http://{{TAILSCALE_IP}}:9119를 Remote Gateway 주소로 사용합니다. Docker 포트를 {{TAILSCALE_IP}}에 묶어 두면, 이 주소는 Tailscale 안의 기기에서만 닿습니다. 그래서 이 구조에서는 관리자 아이디·비밀번호로 시작해도 됩니다.

공개 주소로 열 때는 흐름이 달라집니다. hermes dashboard register는 https://hermes.example.com 같은 주소를 만들어 주는 명령이 아니라, 그 주소 뒤의 Hermes 백엔드에 OAuth 로그인 문을 붙이는 등록입니다. 실제 Remote Gateway URL은 도메인, HTTPS, 리버스 프록시로 따로 만들어야 하고, 로그인 후 돌아올 /auth/callback 주소가 맞도록 HERMES_DASHBOARD_PUBLIC_URL 또는 프록시 헤더를 맞춰야 합니다. 공개 주소로 열면 Desktop은 그 URL에 붙고, 로그인 버튼은 OAuth 방식으로 바뀝니다. 처음 세팅이라면 이 길부터 가지 말고, 사설망 경로로 먼저 붙여 보세요.

그리고 절대 하지 말아야 할 것 하나. 인증을 아예 꺼서 서버를 무인증으로 공개하는 옵션(흔히 --insecure)은 쓰지 마세요. 실제로 무인증으로 열어둔 관리 화면이 침해의 진입점이 됐던 사례가 공식 문서에 나옵니다. 스캐너가 인터넷에 노출된 대시보드를 찾아 들어와 에이전트에 백도어를 심게 만든 사건이었고, 그 뒤로 이 옵션은 아예 동작하지 않게 막혔습니다. 편하다고 열어두면 남이 내 서버를 조종할 수 있습니다.

마지막으로 포트 하나만 짚겠습니다. Hermes를 채팅으로만 쓰는 가이드에서는 "9119 포트를 닫아라"라고 안내하기도 합니다. 하지만 오늘 구조에서는 그대로 닫으면 안 됩니다. 우리 Desktop이 9119(또는 9220) 같은 바깥 문으로 컨테이너를 골라 붙거든요. 그러니 이 포트는 아무 데나 공개하는 게 아니라, Tailscale 사설망과 로그인 뒤에 두는 게 맞습니다.

연결한 다음 — 화면은 노트북, 실행과 결과는 서버

원격 연결이 되고 나면, 아까 노트북에 깔렸던 로컬 엔진은 그냥 쉬는 상태가 됩니다. 실제 실행과 기억, 도구 사용은 전부 서버 엔진에서 일어나고, 내 노트북은 화면과 조작만 담당합니다. 여기서 Desktop의 진가가 나옵니다.

• 과정이 눈앞에 보입니다. 에이전트가 웹을 여는 것도, 기사를 읽는 것도, 요약을 쓰는 것도 옆에서 실시간으로 지나갑니다. 메신저로만 시켰다면 "다 됐어요" 한 줄만 왔을 텐데, 여기선 이상하면 바로 잡을 수 있습니다.
• 결과 파일은 서버에 생깁니다. Desktop의 파일 브라우저로 보면 방금 만든 결과가 서버 안에 생긴 게 보입니다. 내 노트북에는 없습니다.
• 한 번 한 일은 스킬로 남습니다. "이 작업 흐름을 스킬로 저장해줘"라고 해두면, 다음엔 값만 바꿔 한 줄로 다시 부를 수 있습니다. 한 번 가르치면 그다음부터 알아서 하는, "쌓이는 직원"의 의미가 이겁니다.

그리고 이동 중에 텔레그램이나 슬랙으로 "이거 좀 해둬"라고 던져둔 작업을, 자리에 앉았을 때 이 Desktop에서 그 세션을 그대로 열어 이어볼 수 있습니다. 나갈 땐 메신저로 시켜두고, 앉으면 큰 화면으로 넘겨받는 거죠. (다시 말하지만 이 메신저 연결은 앞의 Remote Gateway와는 별개입니다. 서버에 붙고 나면 그 서버의 채널 설정까지 한 화면에서 보인다, 이 정도로 이해하면 됩니다.)

🎯 제일 중요한 건 마지막입니다. 결과는 사람이 열어서 확인하고 판단합니다. 자동으로 돌긴 하지만, 메일 발송이나 공개 발행처럼 되돌리기 어려운 일은 에이전트에게 초안까지만 시키고 마지막 버튼은 사람이 누릅니다. 그래서 작업을 시킬 때부터 "발송은 하지 말고 초안까지만"이라고 못을 박아 두는 게 좋습니다.

시작 전 체크리스트와 자주 막히는 지점

처음 붙여 본다면 아래 순서대로 확인하면 됩니다.

자주 막히는 지점도 함께 정리했습니다.

Q. Remote URL을 넣었는데 연결이 안 됩니다. 노트북과 VPS가 같은 Tailscale 계정인지(tailscale status에 둘 다 보이는지), Remote URL에 넣은 IP가 VPS의 사설망 IP가 맞는지, Docker YAML이 {{TAILSCALE_IP}}:9119:4860 형식인지, 저장 후 Redeploy를 했는지, 관리자 아이디·비밀번호가 맞는지 차례로 확인하세요. "연결은 됐다는데 채팅이 안 된다"면, 서버의 백엔드가 로그인 인증까지 통과해 실제로 떠 있는지 다시 보는 게 좋습니다. (준비됐다는 표시만으로는 채팅까지 되는 게 아닙니다.)

Q. 그냥 로컬로만 쓰면 안 되나요? 됩니다. 가볍게 써볼 거라면 앱 하나만 깔면 충분합니다. 다만 노트북을 꺼도 작업이 계속되게 하거나, 여러 기기에서 붙고 싶다면 VPS 원격 연결이 더 맞습니다.

Q. 공개 도메인으로 접속하고 싶으면요? 그건 사설망 경로가 아니라 공개 인터넷 경로가 됩니다. 이때 hermes dashboard register는 공개 주소를 만들어 주는 명령이 아니라, 그 주소 뒤의 Hermes 백엔드가 OAuth(Nous Portal) 로그인을 받을 수 있게 등록하는 단계입니다. https://hermes.example.com 같은 Remote Gateway URL은 도메인, HTTPS, 리버스 프록시로 따로 열고, OAuth 콜백이 /auth/callback으로 돌아오도록 public URL 또는 프록시 헤더를 맞춰야 합니다. 처음이라면 사설망+아이디·비밀번호로 먼저 붙여 보는 편을 권합니다.

Q. 이미 다른 곳에서 Hermes를 돌리고 있어요. 집에 있는 맥미니든 다른 VPS든, 오늘처럼 Hostinger에 새로 까는 과정은 건너뛰어도 됩니다. 그 기기의 Hermes 백엔드를 켜서 접속 URL을 받은 다음, Desktop의 Remote gateway에 그 URL을 넣어주기만 하면 됩니다. 붙는 방식은 똑같습니다.

💡 Hermes 같은 도구는 업데이트가 빠릅니다. 메뉴 이름, 버튼 위치, 기본 포트, 템플릿의 포트 배선 같은 세부는 버전에 따라 달라질 수 있으니, 정확한 값은 항상 현재 화면과 공식 문서를 기준으로 확인하는 편이 좋습니다.

참고 자료 및 출처

공식 문서는 대부분 영어로 제공됩니다. 원문 링크를 Claude나 ChatGPT에 붙여넣고 "한국어로 요약해줘"라고 요청하면 핵심을 빠르게 확인할 수 있습니다. 가격·할인·플랜 같은 숫자와 화면 속 버튼 이름은 시점에 따라 바뀌니, 실제 값은 현재 화면을 기준으로 확인하세요.