Hermes Agent(3) : Hermes Desktop 설치와 기본 사용 - 터미널 없이 GUI로 시작하는 법
- -
안녕하세요! 갓대희 입니다.

1편에서는 Hermes Agent가 왜 "쓸수록 똑똑해지는" 에이전트인지, 2편에서는 비싼 메인 모델이 잡일까지 떠맡지 않도록 보조 모델 슬롯을 나누는 법을 다뤘다. 그런데 막상 설치 단계에서 막히는 사람이 있다. 터미널 한 줄이 편하다는 분도 있지만, "그냥 앱처럼 깔고 화면에서 쓰고 싶다"는 쪽도 꽤 많다.
그 대안이 Hermes Desktop이다.
Desktop은 CLI·게이트웨이와 같은 에이전트 코어를 쓰는 네이티브 앱이다.
같은 백엔드(같은 HERMES_HOME 또는 같은 Remote 엔진)를 보면 설정·API 키·세션·스킬·메모리까지 이어진다.
이번 글은 Desktop 설치부터 첫 채팅, 화면 구조, CLI랑 역할 나누기, Remote gateway(커스텀 도메인 포함)까지 같이 살펴보려 한다.
Hermes Agent 시리즈
Part 1: 시작하기 · 자가학습 | Part 2: 보조 모델 분리 | Part 3: Desktop (현재) | Part 4: Skills System (다음)
목차
- Hermes Desktop이 무엇인가
- 다운로드 경로 — 공식 vs 커뮤니티 vs 제3자
- 설치 방법 (macOS / Windows / Linux)
- 첫 실행 — 모델 연결까지
- 화면 구조와 기본 사용 (레이아웃·패널·Desktop 보강 기능)
- CLI와 Desktop, 언제 무엇을 쓰는가
- 주의사항 — YOLO, 승인 모드, 비용
- Remote gateway — 커스텀 도메인(HTTPS) / Tailscale
- 트러블슈팅 Q&A
- 결론 — 오늘 할 일 3가지
1. Hermes Desktop이 무엇인가
공식 문서의 정의를 그대로 옮기면 이렇다.
Desktop 앱은 CLI와 게이트웨이에서 쓰는 같은 에이전트를 중심으로 만든 네이티브 앱이다. 같은 설정, 같은 API 키, 같은 세션, 같은 스킬, 같은 메모리. 별도 제품이나 가벼운 복제본이 아니다. (출처: Desktop App)
Hermes front end 계층은 여러 종류가 있다.

| 앞면 | 진입 | 역할 |
|---|---|---|
| Desktop App | 설치 파일 / hermes desktop |
채팅·설정·관리용 네이티브 UI |
| CLI / TUI | hermes / hermes --tui |
터미널 인터페이스 |
| Web Dashboard | hermes dashboard |
브라우저 관리 패널(선택 Chat 탭) |
| 메시징 게이트웨이 | Telegram 등 | 메신저 채널 원격 제어 |
한 줄로 요약하면: 코어는 하나, 입구만 여러 개다.
Desktop·CLI·Telegram이 같은 엔진을 보면 세션이 이어지고, 로컬 Desktop과 원격 엔진을 섞어 쓰면 세션이 갈라진다.
1편이 다룬 스킬·메모리 구조도 "같은 엔진" 전제에서 살아 있다.
Desktop은 그 구조를 클릭으로 관리하게 만드는 층이다.
이름 비슷한 세 층 — 여기서 헷갈리면 Remote 설정이 꼬인다
- Desktop Remote gateway — Settings → Gateway. 노트북 UI가 원격
hermes serve엔진에 붙는 설정. - Web Dashboard —
hermes dashboard. 브라우저 관리 입구. Desktop Remote는 보통 대시보드 창 없이hermes serveAPI에 직접 붙는다. - Messaging gateway — Telegram/Discord 등 메신저 채널. Remote URL과 다른 프로세스다.
데이터는 어디에? CLI랑 같은 집이다. macOS/Linux ~/.hermes, Windows %LOCALAPPDATA%\hermes (HERMES_HOME으로 바꿀 수 있다). git 설치면 코드는 ~/.hermes/hermes-agent, 실행 파일 심링크는 보통 ~/.local/bin/hermes. “Desktop만 따로 설정이 있다”고 생각하면 헷갈린다. (출처: Desktop — How it works, Installation — Install Layout)
2. 다운로드 경로 — 공식 vs 커뮤니티 vs 제3자

| 출처 | 성격 | 이 글에서의 취급 |
|---|---|---|
| hermes-agent.nousresearch.com | Nous Research 공식 | 다운로드·설치 기준 |
| 공식 문서 (docs) | 공식 사용자/개발 문서 | 기능·플래그·보안 기준 |
| hermes-ai.net/desktop | 비공식 커뮤니티 가이드 | 참고만. 사이트 스스로 "unofficial, independent community guide"라고 명시 |
| 이랜서·GPTERS 등 한국어 가이드 | 2차 실습/해설 | UI 흐름·백업 팁 참고. 설치 URL은 공식과 충돌 시 공식 우선 |
| github.com/fathah/hermes-desktop 등 | 제3자 Desktop 프로젝트 | 공식 Nous Desktop과 동일 경로로 취급하지 않음 |
3. 설치 방법 (macOS / Windows / Linux)
3.1 macOS / Windows — 설치 파일 (권장)
- 공식 사이트에서 플랫폼별 설치 파일을 받는다.
- 설치 파일을 실행한다. CLI와 Desktop 앱을 같이 깔기 쉬운 경로다.
- 앱을 연다. 첫 화면에서 제공자/모델 연결로 넘어간다.
실제 파일은 hermes-assets.nousresearch.com 쪽으로 받는 형태다.
빌드 쿼리 문자열이 붙을 수 있다. 블로그에 고정 URL을 박아 두기보다 공식 사이트 버튼을 따라가는 쪽이 안전하다.
다운로드 기준 URL: https://hermes-agent.nousresearch.com/
- 사이트 다운로드 버튼을 누르거나, CLI가 이미 있으면 hermes desktop으로 실행한다.

- 다운로드한 Hermes 설치 파일 실행

- Install Hermes 클릭


- 설치 완료 후 Launch Hermes 클릭

- Hermes Desktop이 정상적으로 뜬다.
예시) 이미 Hermes가 연동된 PC에서는 바로 메인 화면으로 들어간다.

예시) 설정이 깨져 있으면 아래처럼 오류 화면이 나올 수 있다.
- 모델은 나중에 잡아도 된다. Recommended로 가거나, 좌측 하단 I'll choose a provider later로 일단 앱에 들어가자.


3.2 이미 CLI만 설치한 경우
터미널 설치를 이미 끝냈다면 Desktop 설치 파일을 다시 받을 필요 없다. 아래 한 줄이면 된다.
hermes desktop
예시) hermes desktop 실행 직후


설정, 키, 세션, 스킬은 그대로 사용가능하다.
작업 폴더를 지정하려면 --cwd나 환경 변수 HERMES_DESKTOP_CWD.
(출처: CLI reference: hermes desktop)
# 프로젝트 폴더를 초기 작업 디렉터리로
hermes desktop --cwd /path/to/project
# 이미 빌드된 앱만 실행 (재빌드 스킵)
hermes desktop --skip-build
3.3 Linux / 터미널 우선 설치
Linux는 공식 사이트도 터미널 설치를 앞세운다. 문서에 나온 한 줄은 아래.
# Linux / macOS / WSL2 / Termux
curl -fsSL https://hermes-agent.nousresearch.com/install.sh | bash
# Windows (native PowerShell)
iex (irm https://hermes-agent.nousresearch.com/install.ps1)
# 셸 재로드 후
source ~/.bashrc # 또는 ~/.zshrc
hermes # CLI 채팅
hermes desktop # Desktop 실행
설치기가 알아서 맞추는 의존성: uv, Python 3.11(uv 경유), Node.js v22, ripgrep, ffmpeg. 비-Windows에서는 보통 Git만 있으면 되고, Linux는 curl·xz-utils가 필요할 수 있다. Desktop 네이티브 모듈 빌드에는 Linux에서 g++ 또는 build-essential이 더 필요하다고 문서에 나온다. Python/Node를 미리 깔 필요는 없다. (출처: Installation — Prerequisites)
모델을 빨리 붙이려면. 숏컷은 hermes setup --portal. Nous Portal 로그인으로 프로바이더와 Tool Gateway를 한 번에 잡는다. Desktop 온보딩에도 비슷한 선택지가 있다.
4. 첫 실행 — 모델 연결까지

첫 실행 온보딩은 모델만 잡으면 바로 채팅까지 가게 되어 있다.
Provider(제공자)를 미루려면 Choose provider later 같은 옵션이 있다. 다만 모델을 연결하기 전까진 대화는 안 된다.
예시) 이미 Hermes를 쓰던 PC라 모델이 미리 잡혀 있었다. 완전 첫 설치 PC에서는 온보딩에서 제공자를 고르는 화면이 먼저 뜬다.

온보딩 선택지는 크게는 세 갈래이다.
| 선택 | 의미 | 언제 고르나 |
|---|---|---|
| Nous Portal 연결 | Portal 계정으로 모델·Tool Gateway 이용 | 키 여러 개를 직접 관리하기 싫을 때 |
| API Key 직접 등록 | OpenAI, Anthropic, Gemini, OpenRouter 등 | 이미 쓰는 공급자 키가 있을 때 |
| 나중에 설정 / 스킵 | UI만 먼저 확인 | 화면 구조만 보고 싶을 때 (대화는 보류) |
모델 피커는 채팅 작성창(composer) 옆에 있다.
여기서 고른 모델은 프로필 기본값을 안 건드린다. sticky UI 상태라 기기/앱에 기억되고, 새 채팅에도 따라온다.
프로필 전역 기본 모델은 Settings → Model에서 정한다.
진행 중인 채팅에서 모델을 바꾸면 프롬프트 캐시가 리셋된다. 긴 대화면 비용이 튈 수 있다.
5. 화면 구조와 기본 사용
앱은 채팅이 가운데인 창이다. 별거 없다.
큰 그림은 좌측 내비·세션 / 중앙 채팅 / 우측 파일·셸(토글) / 하단 composer다. 처음 보면 아래쪽에 상태 바가 아니라 composer(모델 피커 포함)가 있다. Git 저장소 세션이면 composer 위에 coding row(브랜치명·+/- diff)가 붙는다.
창 맨 아래 상태 바는 기본 OFF다. Cmd/Ctrl+Shift+S나 커맨드 팔레트 Toggle status bar로 켠다.
| 영역 | 위치 | 역할 |
|---|---|---|
| ① 좌측 내비 | 왼쪽 아이콘 | New session, Capabilities, Messaging, Artifacts |
| ② 세션 목록 | 내비 아래 | Desktop·CLI·Telegram 세션이 한 목록에 모인다(같은 엔진일 때) |
| ③ 중앙 채팅 | 가운데 | 스트리밍, 도구 요약, 드래그앤드롭 첨부, 타임라인 레일 |
| ④ 우측 패널 | 오른쪽 | 작업 디렉터리 트리 + 하단 TERMINAL. Cmd/Ctrl+J로 패널 토글 |
| ⑤ 하단 상태 바 | 창 맨 아래 (기본 OFF) | Cmd/Ctrl+Shift+S로 켬. 예: Gateway ready, 작업 폴더, 버전. 우클릭으로 칩 추가(context, Approvals 등). YOLO는 /yolo나 Cmd/Ctrl+K(Toggle yolo). 모델 피커는 composer |
| ⑥ 상단 | 우측 | Command Center, Profiles, Settings |
예시) 기본 화면

5.1 채팅 (중앙)
- 스트리밍 응답과 도구 호출 요약
- CLI/TUI와 같은 대화 이력 공유
- 채팅 영역 어디든 파일 드래그앤드롭 첨부 가능
- 우측 미리보기 레일(웹·파일·도구 출력) — 닫혀 있으면 Cmd/Ctrl+J로 열 수 있다
- 긴 대화용 타임라인 레일(턴이 쌓이면 등장), Cmd/Ctrl+F 찾기
- 빈 composer에서 ↑/↓로 이전 프롬프트 불러오기, 큐에 쌓인 메시지 편집
모델 피커는 하단 composer(마이크 왼쪽)에 있다. 여기서 고른 값은 프로필 기본을 안 건드린다. 전역 기본은 Settings → Model.
예시) composer 모델 피커


composer 위 coding row(Git 저장소 세션일 때)에는 브랜치명(예: main)과 +N -M diff 요약이 붙는다. 상태 바가 아니라 Git review로 들어가는 줄이다.
상태 바는 창 맨 아래 얇은 줄이다.

기본값이 OFF였다. 켜려면 Cmd/Ctrl+Shift+S나 커맨드 팔레트 Toggle status bar. 켜면 아래처럼 보인다.
예시) 상태 바

우클릭 > Show in status bar로 context meter 같은 칩을 더 켠다. 진단 칩 상당수는 기본 숨김.
예시) 상태 바 > 우클릭 > Context meter


미터를 켠 뒤 클릭하면 Context Usage가 열린다. 시스템 프롬프트, tools, skills, memory, rules, MCP, subagents, 대화 본문 — 항목별 토큰 비중이 보인다.
예시) 같은 메뉴에서 Approvals도 켜 두자.

YOLO / Approval 바꾸는 법
- composer
/yolo(슬래시: Toggle YOLO — auto-approve dangerous commands) - Cmd/Ctrl+K(또는 P) → Toggle yolo (on/off 표시)
- CLI:
hermes --yolo/HERMES_YOLO_MODE=1
approval mode(smart/manual/off)는 YOLO와 다른 개념이다.
YOLO는 위험 셸 승인 프롬프트를 세션 단위로 건너뛴다(Claude Code의 --dangerously-skip-permissions와 비슷하다). YOLO를 꺼 둬도 기본 approvals.mode: smart는 저위험 셸을 자동 승인할 수 있다.
예시) 상태 바에서 Approvals를 켜 두면 우측 하단 칩으로 모드를 바꿀 수 있다.

예시) /yolo

5.2 파일 브라우저 · 터미널 · Artifacts

- File browser — 우측 레일 프로젝트 트리. 초기 경로는
hermes desktop --cwd또는 세션 워크스페이스.

- Terminal — 파일 트리 아래 TERMINAL 영역. 패널을 숨겨도 셸은 유지되고, 출력 일부를 채팅에 붙일 수 있다.

- Artifacts — 좌측 내비. 필터 All / Images / Files / Links + 검색. 카드에서 해당 Chat 세션으로 점프.

5.3 관리 패널 — Capabilities / Messaging / Profiles / Settings

터미널에서 YAML 안 만져도 설정·채널·프로필을 만질 수 있다.
Desktop이 쓸모 있는 지점이 여기다.
| 패널 | 하는 일 | 시리즈 연결 |
|---|---|---|
| Capabilities | 탭: Skills / Tools / MCP / Browse Hub. 스킬·도구 ON/OFF. Changes apply to new sessions | 1편 스킬 + 도구 GUI |
| Messaging | Telegram 등 채널 + Bot token·Allowed user IDs | 메신저 원격 제어 |
| Profiles | 모달: 프로필 + SOUL.md 편집·Save | 업무·개인 환경 분리 |
| Settings → Model | Auxiliary models(Vision, Web extract, Compression, Skills hub, Approval 등) | 2편 보조 모델 |
| Command Center | 문서상 멀티 에이전트 조율 표면(이번 글 캡처 범위 밖) | 운영 가시성(문서) |
| Cron | 예약 작업 (이번 글에서는 입구만) | 자율 실행 입구 |
Capabilities — Skills / Tools / MCP / Browse Hub
Skills 예시 :
스킬을 너무 많이 켜 두지 않도록 하자.. 블로그 쓰느라 추가한 Skills는 나도 제거를 좀 해야 될겠다.

Messaging — 플랫폼 목록 + Telegram 설정(토큰 마스킹)
Telegram: Bot token(REQUIRED), Allowed Telegram user IDs(RECOMMENDED).

Artifacts — All / Images / Files / Links
카드에 Chat 세션 링크. 클릭하면 해당 세션으로 이동 가능하다.

Profiles 모달 — SOUL.md + Save
좌측 하단의 ... 클릭

Profiles를 이용해 여러 페르소나를 주입하여 사용 한다.
초기엔 한가지 Profile만 존재 한다.

5.4 단축키 (입문용 최소 세트)
단축키는 Settings → Keyboard Shortcuts에서 보고 바꿀수도 있는데, 기본값은 몇가지 아래 참고.
| 동작 (Shortcuts 라벨) | 기본 키 (macOS) |
|---|---|
| Focus composer | / 또는 Enter |
| Open model picker | Cmd+Shift+M |
| Slash command palette | / |
| Send message / Insert newline | Enter / Shift+Enter |
| Queue message / Send next queued | Cmd+Enter / Cmd+Shift+K |
| Send terminal selection to composer | Cmd+L |
| 커맨드 팔레트 (앱 전역) | Cmd/Ctrl+K 또는 P |
| 상태 바 토글 | Cmd/Ctrl+Shift+S |
| 좌/우 사이드 패널 | Cmd/Ctrl+B / Cmd/Ctrl+J (문서) |
| Git review 패널 | Cmd/Ctrl+G (문서) |
| New worktree | Cmd/Ctrl+Shift+B (문서) |
| Quick Entry (전역) | Cmd/Ctrl+Shift+Space (Settings에서 켬) |
| 터미널 표시 / 추가 셸 | Ctrl+` / Ctrl+Shift+` (문서) |
5.5 Desktop에서 바로 써 볼 만한 기능 (입문 보강)

Quick Entry — 앱 창 안 띄우고 한 줄 지시 던지는 전역 입력창. Settings → Advanced → Quick Entry에서 켠다.
기본 단축키는 Cmd/Ctrl+Shift+Space이다. 다른 앱이 이미 쓰고 있다면 설정시 충돌 할 것이다.
ex)

창·탭·패널 — 몇개만 살펴보면
Cmd/Ctrl+T : 새 세션 탭 열기
Ctrl+Tab / Ctrl+Shift+Tab : 세션 순환
Cmd/Ctrl+W : 탭 닫기
Cmd/Ctrl+Shift+T : 방금 닫은 탭 복구 단축키.
Cmd/Ctrl+Shift+N : 새 창(세션 팝아웃)을 열 수 있고, 긴 작업을 다른 모니터에 두고 메인 창은 다른 채팅을 이어 갈 때 쓸모 있다. Cmd/Ctrl+B, Cmd/Ctrl+J : 좌/우 사이드
Cmd/Ctrl+\\. : 좌우 스왑
Git review · worktrees — 세션이 Git 저장소 안이면 Cmd/Ctrl+G로 git과 관련하여 작업을 할 수 있는 패널이 열리게 된다.
WorkTree 작업 방식으로 병렬로 작업도 가능한데, Cmd/Ctrl+Shift+B(또는 사이드바 New worktree)로 worktree를 만들어 작업할수도 있다.
ex) 현재는 메인 브랜치 이다.

- Cmd + Shift + B 입력

- 신규 WorkTree에서 별도의 작업을 가능하다.

Memory Graph / Learning Journey — 학습된 스킬·기억을 지도처럼 보는 화면.

커맨드 팔레트에서 Memory Graph를 찾거나, 채팅에 /journey(별칭 /learning, /memory-graph)를 치면 된다.
All / Used / Learned 필터와 타임라인 스크러버가 있다.
노드에서 편집·삭제(스킬은 아카이브, 기억 제거)도 가능하다. "쓸수록 똑똑해진다"를 눈으로 확인할 수 있는 부분 이기도 하다.
ex) 나의 경우 초기 상태의 PC에서 별 내용이 없다.


Keep computer awake — Settings → Advanced. 밤새 로컬 엔진 작업을 돌릴 때 절전으로 끊기는 걸 막는 컴퓨터 단위 설정이다. 디스플레이 디밍까지 막는 건 아닐 수 있다.
테마·언어·Voice — Appearance에서 빌트인 테마 외에 VS Code Marketplace 색 테마를 검색·설치할 수 있다.
UI 언어 전환(간체 중국어 등)도 문서에 있다. Voice는 다른 Hermes 표면과 같은 voice mode 경로다. macOS는 마이크 권한을 한 번 묻는다.
Projects — 사이드바 프로젝트 목록은 홈 디렉터리를 제한 깊이로 스캔한다.
ex) 특정 프로젝트를 탐색 한 후 New sessions 를 클릭하여 사용할 수 있고, 관련 프로젝트 파일과 git 패널을 볼 수 있다.



6. CLI와 Desktop, 언제 무엇을 쓰는가
그때그때 용도에 편한 방식을 사용하자.
| 상황 | 유리한 쪽 | 이유 |
|---|---|---|
| 파일·이미지 첨부가 잦다 | Desktop | 드래그앤드롭, 미리보기 레일 |
| 스킬·크론·메신저를 한 화면에서 본다 | Desktop | 관리 패널 UI |
| 서버·SSH·스크립트·CI | CLI | headless·자동화에 적합 |
| 로그 tail, 빠른 진단 | CLI | hermes logs gui -f, hermes doctor |
| VPS에서 에이전트 돌리고 로컬은 UI만 | 둘 다 | Remote gateway로 Desktop 연결 |
7. 주의사항 — YOLO, 승인 모드, 비용

7.1 승인 모드 (approvals.mode) — YOLO랑 다른 설정
위에서 잠깐 다뤘지만 한번 더 짚고 넘어가자.
위험도가 높은 Shell 명령인지 아닌지, 막을지 말지는 Approval Mode에서 정한다. 설정 키는 ~/.hermes/config.yaml의 approvals.mode다.
헷갈리기 쉬운 지점. Approval Mode랑 세션 YOLO(/yolo, 또는 Cmd/Ctrl+K → Toggle yolo)는 별개다. 공식 기본값은 smart다. (출처: Security — Approval Modes)
| 모드 | 동작 | 처음 쓸 때 |
|---|---|---|
smart (기본) |
보조 LLM이 위험도를 본다. 덜 위험한 명령은 자동 승인, 확실한 위험 명령은 자동 거부, 애매하면 사용자에게 물어본다 | “파일 지웠는데 승인 창이 안 떴다”가 흔하다. YOLO를 꺼 둬도 덜 위험한 rm 같은 건 창 없이 갈 수 있다 |
manual |
위험 패턴에 걸리는 명령은 매번 사용자 승인 | 위험한 Shell 명령을 하나하나 확인하고 싶을 때 |
off |
승인 검사를 끈다 (--yolo에 가깝다) |
CI·컨테이너처럼 믿을 수 있는 환경용. 처음 쓰는 분께는 비추천 |
7.2 YOLO 모드
세션 YOLO는 Desktop에서 /yolo, 또는 Cmd/Ctrl+K → Toggle yolo로 켠다.
상태 바는 기본이 OFF다. 상태 바 칩부터 찾으면 헤매기 쉽다. 문서에 상태 바 YOLO가 나와도, 슬래시 명령이나 커맨드 팔레트가 더 확실하다.
YOLO를 켜면 위험한 Shell 승인 창을 그 세션 동안 건너뛴다. 처음 쓰거나 중요한 데이터 근처에서는 OFF로 두자.
YOLO를 껐다고 모든 명령에 확인 창이 뜨는 건 아니다. 기본값 smart가 덜 위험한 명령을 그냥 통과시키기도 한다. 반대로 YOLO를 켜도 hardline blocklist(무조건 막는 목록)와 approvals.deny는 우회되지 않는다. (출처: Security / YOLO Mode)
8. Remote gateway — 커스텀 도메인(HTTPS) / Tailscale
로컬만으로도 Desktop은 충분하다.
다만 노트북 뚜껑을 닫아도 에이전트가 계속 돌게 하려면 Remote가 필요하다. 그림으로 보면 이렇게다.

[노트북] Hermes Desktop = UI
│ Settings → Gateway → Remote URL
▼
[서버] hermes serve = 실제 엔진 (세션·스킬·메모리·도구 실행)
(예: https://hermes.example.com 또는 http://100.x.x.x:9119)
나의 경우도 지금 Remote gateway를 쓰고있긴 한데, 지금글에서 자세히 다루기에는 너무 오버 스펙인 듯하여
메모정도 수준으로 하고 넘어 가려고 한다.
( 나의 경우 AI에게 프롬프트를 통해 요청하여 모두 세팅 하였다. 하기 내용은 읽지 말고 가장 밑에 부분에 AI에게 복붙할 프롬프트를 작성해 두었으니 프롬프트 한방으로 요청 하자. 8.1~8.3은 데충 기록용으로 생각하고 빠르게 넘어가자.)
기본은 앱이 로컬에서 hermes serve를 띄우는 것이다.
Connection mode는 Local / Remote gateway / Hermes Cloud 정도가 있다.
Remote로 바꾸면 엔진이 바깥으로 옮겨 가니, 서버 쪽을 먼저 띄운 뒤 Desktop에서 붙는다.
(참고: Desktop — Connecting to a remote backend)
| 방법 | Remote URL 예 | 권장 인증 | 이럴 때 |
|---|---|---|---|
| 1) 커스텀 도메인 (공개 HTTPS) | https://example.com |
OAuth (Nous Portal) | 인터넷 어디서나, 도메인으로 붙고 싶을 때 |
| 2) Tailscale | http://100.x.x.x:9119 |
Username/password (basic) | 공개 포트 없이 내 tailnet만 쓸 때 |
8.1 방법 1 — 커스텀 도메인 (공개 HTTPS) 세팅

목표: VPS에 엔진을 두고, 노트북 Desktop에서 https://사용할 hermes 도메인 으로 로그인한다.
공개 인터넷 경로이므로 공식 권장은 Nous Portal OAuth다.
미리 준비할 것
- VPS (Ubuntu 등) + 공인 IP, SSH 접속
- 도메인 A 레코드:
example.com→ VPS IP (전파 확인:dig +short example.com) - 서버에 Hermes 설치 + 모델 프로바이더 로그인 (
hermes setup또는hermes setup --portal) - 방화벽: 80/443 열기. 가능하면 9119는 바깥에 직접 안 연다 (reverse proxy만 쓰거나 로컬만 허용)
전체 그림
인터넷
→ https://example.com (443, Nginx/Caddy TLS)
→ 127.0.0.1:9119 hermes serve (API + WebSocket /api/ws)
Desktop: Settings → Gateway → Remote URL = https://example.com
Sign in with Nous Research
Step 1. VPS에서 Hermes 준비
# VPS (예시)
hermes version
hermes setup # 또는 hermes setup --portal
# Nous 로그인이 안 되어 있으면 여기서 끝낸다. OAuth 등록에 필요.
Step 2. 공개 대시보드 OAuth 클라이언트 등록
공개 HTTPS 콜백 URL을 같이 넣는다. 등록이 끝나면 HERMES_DASHBOARD_OAUTH_CLIENT_ID가 ~/.hermes/.env에 쓰인다.
hermes dashboard register \
--name "vps-hermes" \
--redirect-uri https://example.com/auth/callback
# 확인
grep HERMES_DASHBOARD_OAUTH_CLIENT_ID ~/.hermes/.env
CLI 대신 브라우저에서 portal.nousresearch.com/local-dashboards 로 등록한 뒤, 나온 agent:... client ID를 ~/.hermes/.env에 넣어도 된다.
Step 3. 공개 URL 환경 변수
reverse proxy 뒤에 두면 OAuth 콜백이 꼬이기 쉽다. 공개 주소를 고정으로 박아 둔다.
# ~/.hermes/.env 에 추가 (도메인은 본인 것으로)
cat >> ~/.hermes/.env <<'EOF'
HERMES_DASHBOARD_PUBLIC_URL=https://hermes.example.com
EOF
chmod 600 ~/.hermes/.env
config.yaml이면 dashboard.public_url: "https://hermes.example.com" 도 같다.
path prefix를 쓰면 예: https://example.com/hermes (콜백은 .../auth/callback).
Step 4. 엔진 기동
Desktop이 붙는 쪽은 공식 문서 기준 hermes serve다.
non-loopback bind여야 OAuth 게이트가 켜진다.
루프백(127.0.0.1)만 쓰면 로컬 개발용처럼 auth가 꺼질 수 있다.
# OAuth 게이트 켜기 (공개 HTTPS 경로 권장)
hermes serve --host 0.0.0.0 --port 9119
# 방화벽: 80/443만 공개, 9119는 외부 차단 (같은 머신의 Nginx만 프록시)
# ufw 예:
# sudo ufw allow 80/tcp
# sudo ufw allow 443/tcp
# sudo ufw deny 9119/tcp
# sudo ufw enable
# 프로세스 유지: tmux / systemd
# systemd 힌트: EnvironmentFile=%h/.hermes/.env
# ExecStart=... hermes serve --host 0.0.0.0 --port 9119
bind + 방화벽. 공식은 non-loopback bind에서 인증 게이트를 켠다.
reverse proxy를 쓰더라도 ① OAuth 등록 + PUBLIC_URL, ② 0.0.0.0:9119(또는 사설 인터페이스) + OAuth, ③ 방화벽으로 9119 외부 차단 조합이 안전하다. 인증 없이 9119를 인터넷에 직접 열지 말자. --insecure는 no-op이다.
Step 5. Nginx reverse proxy (HTTPS + WebSocket)
Desktop 채팅은 HTTP 상태 확인(/api/status) 다음에 WebSocket(/api/ws 등)으로 붙는다.
Upgrade 헤더가 없으면 "상태는 ready인데 채팅이 안 된다"가 난다.
# /etc/nginx/sites-available/hermes 예시
# 인증은 Hermes OAuth가 담당. 여기선 TLS + 프록시만.
# 백엔드는 같은 머신의 9119. 바깥에서는 ufw 등으로 9119 차단.
upstream hermes_backend {
server 127.0.0.1:9119;
keepalive 32;
}
server {
listen 80;
listen [::]:80;
server_name hermes.example.com;
location /.well-known/acme-challenge/ {
root /var/www/letsencrypt;
}
location / {
return 301 https://$host$request_uri;
}
}
server {
listen 443 ssl http2;
listen [::]:443 ssl http2;
server_name hermes.example.com;
ssl_certificate /etc/letsencrypt/live/hermes.example.com/fullchain.pem;
ssl_certificate_key /etc/letsencrypt/live/hermes.example.com/privkey.pem;
location / {
proxy_pass http://hermes_backend;
proxy_http_version 1.1;
proxy_set_header Upgrade $http_upgrade;
proxy_set_header Connection "upgrade";
proxy_set_header Host $host;
proxy_set_header X-Real-IP $remote_addr;
proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
proxy_set_header X-Forwarded-Proto https;
proxy_read_timeout 3600s;
proxy_send_timeout 3600s;
proxy_buffering off;
}
}
# 인증서 (DNS A 레코드가 VPS를 가리킨 뒤)
sudo apt install -y nginx certbot python3-certbot-nginx
sudo ln -s /etc/nginx/sites-available/hermes /etc/nginx/sites-enabled/
sudo mkdir -p /var/www/letsencrypt
sudo nginx -t && sudo systemctl reload nginx
sudo certbot --nginx -d hermes.example.com
# 또는 certonly + 위 conf의 인증서 경로 수동 지정
sudo nginx -t && sudo systemctl reload nginx
Caddy를 쓰면 TLS가 더 짧다. 핵심은 같이다. HTTPS 종료 + WebSocket upgrade + 백엔드 127.0.0.1:9119.
# Caddyfile 스케치
hermes.example.com {
reverse_proxy 127.0.0.1:9119
}
Step 6. 서버에서 상태 확인
# 로컬 백엔드
curl -sS http://127.0.0.1:9119/api/status | jq '.auth_required, .auth_providers'
# 공개 HTTPS (노트북에서도)
curl -sS https://hermes.example.com/api/status | jq '.auth_required, .auth_providers'
# 기대: auth_required true, auth_providers 에 "nous" (OAuth 경로)
브라우저로 https://hermes.example.com 을 열어 Sign in with Nous가 보이면 서버 쪽 절반은 된 것이다. 랜딩 HTML만 되고 /api/status가 404면 proxy 경로를 고친다.
Step 7. Desktop에서 붙이기
- Settings → Gateway → Connection mode = Remote gateway
- Remote URL =
https://hermes.example.com(path prefix 쓰면 그 전체 경로) - Sign in with Nous Research → 브라우저 OAuth 완료
- Save and reconnect. 세션·프로필이 서버 쪽 기준으로 보이면 성공
Settings → Gateway — Local / Remote 전환
ex) Remote gateway 연결 성공한 모습

Remote 연결 성공 후 — 서버 세션이 목록에 보임
ex) 세션 목록이 로컬에서 사용하던 세션이 아닌 원격서버에서 사용하던 세션 리스트로 변경 되었다.

커스텀 도메인 트러블슈팅
- ready인데 채팅 안 됨 — Nginx WebSocket Upgrade/Connection 헤더, 긴 timeout 확인. Desktop 로그에서
/api/wsclose code (4401=인증 티켓, 4403=Host/peer 가드)를 본다. - OAuth 콜백 실패 —
HERMES_DASHBOARD_PUBLIC_URL과 register 시--redirect-uri가 실제 공개 URL과 같은지 본다. - connection refused — 서버 프로세스 죽음, 방화벽, DNS.
curl /api/status부터. - Sign in 대신 session token 칸만 — OAuth/basic 프로바이더가 안 올라온 상태.
auth_providers확인. - Cloudflare Access 등 추가 로그인 레이어 — HTTP는 되고 WebSocket이 끊길 수 있다. 공식·커뮤니티 모두 "Desktop 쿠키/WS와 안 맞을 수 있음"을 경고한다.
- Telegram Messaging 게이트웨이와 Remote URL은 별개 프로세스다.
8.2 방법 2 — Tailscale (사설망, 더 단순한 경로)

공개 포트·도메인·인증서가 부담되면 Tailscale이 편하다.
노트북과 VPS가 같은 tailnet에 있으면, http://<tailscale-ip>:9119 로 붙인다.
공식도 trusted network용으로 basic auth + Tailscale bind를 안내한다.
서버
# Tailscale 설치 후 tailscale ip -4 로 100.x.x.x 확인
cat >> ~/.hermes/.env <<'EOF'
HERMES_DASHBOARD_BASIC_AUTH_USERNAME=admin
HERMES_DASHBOARD_BASIC_AUTH_PASSWORD=choose-a-strong-password
# 재시작해도 로그인 유지
HERMES_DASHBOARD_BASIC_AUTH_SECRET=$(openssl rand -base64 32)
EOF
chmod 600 ~/.hermes/.env
# tailnet IP에만 바인드 (공식 예시)
hermes serve --host <tailscale-ip> --port 9119
# 또는
# hermes serve --host 0.0.0.0 --port 9119 # 방화벽·tailnet 정책으로 제한
curl -sS http://<tailscale-ip>:9119/api/status | jq '.auth_required, .auth_providers'
# 기대: true, ["basic"]
Desktop
- Settings → Gateway → Remote gateway
- Remote URL =
http://<tailscale-ip>:9119 - Sign in → 위에서 넣은 username/password
- Save and reconnect
SECRET을 안 두면 서버 재시작마다 로그아웃된다. basic은 공개 인터넷 직접 노출용 아님. Tailscale·LAN 전제다.
8.3 Desktop 쪽 공통 팁
- 환경 변수
HERMES_DESKTOP_REMOTE_URL로 URL을 미리 박아 둘 수 있다. 로그인 자체는 Gateway 패널에서 한다. - Remote 호스트는 프로필마다 다르게 둘 수 있다. 예: 업무=VPS 도메인, 개인=로컬.
- 구버전/일부 영상은 dashboard URL + session token 경로를 말하기도 한다. 지금 문서 기준은 Remote gateway + hermes serve + Sign in이다.
- 데이터(세션·스킬·메모리)는 엔진이 있는 서버의
HERMES_HOME에 쌓인다. 노트북 로컬과 자동 합쳐지지 않는다.
보안 한 줄. 원격 엔진은 API 키와 에이전트 실행 권한을 바깥에 내놓는 셈이다. 공개면 OAuth + HTTPS, 사설망이면 Tailscale + basic. 인증 없이 9119를 인터넷에 열지 말자.
참고 자료 (공식 우선, 나머지는 reverse proxy 실습용)
- Desktop — Connecting to a remote backend
- Web Dashboard — Connecting Hermes Desktop
- Web Dashboard — Nous OAuth / dashboard register
- Nous Portal — Local Dashboards
- 커뮤니티: Nginx HTTPS·WebSocket 예시 (Upgrade 헤더 참고용) — LumaDock 등 2차 가이드. 공개 인증은 공식 OAuth 경로를 우선한다.
8.4 Hermes에게 시키기 (복붙 프롬프트)
엔진이 돌아가는 Ubuntu에서 Hermes 채팅에 아래를 붙여 넣으면 된다. sudo 는 승인 후에만 하게 시켜 두었다. 엔진이 이미 죽어 있으면 SSH로 systemctl --user start hermes-serve 한 뒤 시킨다.
✏️ 바꿀 곳 = 딱 1줄
프롬프트 안의 이 한 줄만 본인 도메인으로 바꾼다.
- 도메인: https://본인이 사용하는 hermes 도메인
전체 프롬프트 (위 1줄 수정 후 통째로 복사)
너는 지금 이 Ubuntu 머신에서 돌아가는 Hermes 에이전트다. 아래 작업을 순서대로 수행해라.
민감 정보(비밀번호, 토큰, API 키, .env 값)는 절대 출력·로그·파일로 남기지 마라. 키 이름 존재 여부만 확인한다.
## 목표
다른 PC의 Hermes Desktop이 Remote gateway로 이 서버에 붙을 수 있게 한다.
- 도메인: https://hermes.example.com
- 백엔드: hermes serve (Desktop Remote용). dashboard와 혼동하지 말 것.
- 포트: 9119
- 인증: /api/status 기준. basic이면 username/password, nous면 Sign in with Nous.
(Grok OAuth는 모델용이지 Remote 로그인용이 아님)
- reverse proxy: Nginx가 있으면 읽기 위주. 수정은 제안 후 내 승인.
- 상시 기동: systemd --user 유닛 hermes-serve.service
## 제약
1. sudo 작업은 실행 전 명령을 보여주고 승인을 받는다.
2. .env에 BASIC_AUTH 가 있으면 비밀번호를 임의로 바꾸지 않는다. 없을 때만 생성 절차를 제안하고 비번은 내가 정한다.
3. 9119에는 serve 하나만 남긴다. dashboard와 포트 충돌이면 serve --stop 후 정리.
4. 추측으로 우회하지 말고, 막히면 출력과 함께 멈춘다.
## 작업 순서
A. 진단: hermes version, which hermes, hermes serve --status,
ss -tlnp | grep 9119, systemctl --user status hermes-serve.service,
curl -sS http://127.0.0.1:9119/api/status ,
curl -sS https://(도메인)/api/status (auth_required, auth_providers만),
.env 키 존재만: BASIC_AUTH_USERNAME/PASSWORD|PASSWORD_HASH/SECRET, PUBLIC_URL, OAUTH_CLIENT_ID
B. 포트 충돌: hermes serve --stop, 남은 hermes dashboard/serve PID만 종료, 9119 free 확인
C. ~/.config/systemd/user/hermes-serve.service
ExecStart=(which hermes) serve --host 0.0.0.0 --port 9119 --skip-build
EnvironmentFile=%h/.hermes/.env, Restart=on-failure
daemon-reload → enable --now → reset-failed → status/journal 확인
address already in use 면 B 재시도 (최대 2회)
D. Linger=no 이면 sudo loginctl enable-linger $USER 제안 후 승인 시 실행
E. PUBLIC_URL 이 도메인과 다르면 https://도메인 으로 맞추기 제안 (기존 비번 유지)
F. Nginx: proxy_pass·WebSocket Upgrade 헤더 확인. 부족하면 패치 제안 후 승인
G. ufw: 80/443 허용, 9119 외부 차단 제안 (승인 후)
H. 최종: is-active active, 9119 단일 PID, localhost+공개 /api/status OK, journal에 bind 오류 없음
## 보고 형식
READY 또는 BLOCKED 한 줄 + 한 일 + Desktop 연결 4줄:
Settings → Gateway → Remote gateway
URL: https://(도메인)
Sign in: basic이면 id/pw, OAuth면 Sign in with Nous
Save and reconnect
지금 A부터 시작해라.
짧은 버전 (유닛은 이미 있고 포트 충돌만 날 때)
9119 address already in use 로 hermes-serve.service가 실패 중이다.
9119 점유 프로세스 확인 → hermes dashboard/serve만 중지 → 포트 free 확인 →
systemctl --user reset-failed hermes-serve && restart →
status + journal + curl localhost·https://hermes.example.com /api/status.
.env 값은 출력하지 말고 READY/BLOCKED로 요약.
짧은 버전도 도메인 한 곳(hermes.example.com)만 바꾸면 된다.
9. 트러블슈팅 Q&A
Q1: hermes: command not found
셸 PATH에 설치 경로가 안 잡힌 경우가 많다. source ~/.bashrc 또는 source ~/.zshrc 후에 다시 시도해 보자. 그래도 안 되면 설치 경로(~/.local/bin/hermes 등)를 확인하고, hermes doctor부터 돌린다.
Q2: Desktop 부팅이 실패한다
부팅 로그는 HERMES_HOME/logs/desktop.log에 있다. 실시간으로 보려면:
hermes logs gui -f
macOS/Linux에서 첫 실행을 리셋하려면 bootstrap 마커를 지우고 venv를 다시 만든다. (출처: Desktop Troubleshooting)
rm "$HOME/.hermes/hermes-agent/.hermes-bootstrap-complete"
rm -rf "$HOME/.hermes/hermes-agent/venv"
Q3: "Build desktop app"이 Electron 다운로드에서 멈춘다
Electron 런타임을 받다 네트워크에서 막히는 경우가 많다. 필요하면 ELECTRON_MIRROR를 지정하고, 캐시가 깨졌으면 Electron zip 캐시를 지운다. 문서에도 자동 재시도와 미러 폴백이 적혀 있다. (출처: Desktop Troubleshooting — Electron download)
Q4: 다른 PC의 CLI 데이터를 Desktop으로 옮기고 싶다
같은 머신에서는 상태 공유가 기본이다. CLI에 백업·가져오기 계열 명령이 있을 수 있다. 다만 Desktop UI에 "전체 ZIP 원클릭 복원"이 항상 있는 건 아니다. PC 간 이전은 현재 버전 CLI 도움말·공식 문서와 커뮤니티 실습을 같이 보자. (참고: 이랜서 백업 실습)
Q5: hermes-ai.net에서 받은 파일과 공식 파일이 다른가?
hermes-ai.net은 커뮤니티 가이드다. 다운로드는 공식 사이트에서 하자. 커뮤니티가 공식으로 링크를 넘겨 주기도 하지만, 최종 확인은 항상 hermes-agent.nousresearch.com이다.
Q6: Desktop만 지우고 에이전트 데이터는 남기고 싶다
Settings → About → Danger zone에 단계별 제거 옵션이 있다. GUI만 지우려면 hermes uninstall --gui 계열, 데이터까지 완전 삭제는 hermes uninstall --full 계열이다. 실행 전에 무엇을 남길지 고르자. (출처: Desktop — Uninstalling)
Q7: 이미 VPS/커스텀 도메인에 Hermes를 올려 두었다. Desktop에 어떻게 붙이나?
Settings → Gateway → Remote gateway에 그 URL을 넣는다. 서버 쪽에는 hermes serve(또는 같은 API를 열어 둔 Docker 포트)가 떠 있어야 한다. 공개 도메인이면 OAuth와 HTTPS reverse proxy를 맞춰 둔다. 브라우저로 예쁜 랜딩 페이지만 열리고 Desktop이 거부하면 /api/status와 WebSocket 프록시를 의심해 보자. (§8)
Q8: Remote gateway와 Telegram 연결은 같은가?
아니다. Remote gateway는 Desktop UI가 원격 엔진에 붙는 설정이다. Telegram/Discord는 Messaging 패널의 메시징 게이트웨이다. 둘 다 같은 엔진을 보면 메모리·세션을 공유하지만, 설정 메뉴와 프로세스는 다르다.
Q9: 로컬 Desktop과 원격 엔진을 동시에 쓰면 데이터가 어디에 쌓이나?
Remote로 붙인 프로필의 작업 결과(세션·스킬·메모리)는 서버의 HERMES_HOME에 쌓인다. 노트북 로컬 ~/.hermes와 자동으로 합쳐지지 않는다. 백업·이전도 서버 쪽 기준이다.
Q10: Remote URL을 넣었는데 connection refused / Sign-in 401이 난다
connection refused는 서버가 루프백에만 붙어 있거나, 방화벽·포트 매핑 문제인 경우가 많다. 바깥에서 닿는 주소에 바인드했는지, /api/status가 외부에서 되는지 본다. 401은 username/password가 안 맞을 때다. Sign in 대신 session token 필드만 보이면 basic 인증이 꺼져 있는 상태일 수 있다 — 서버 인증 설정을 확인하자. 재시작할 때마다 로그아웃되면 signing secret을 안정적으로 뒀는지 본다. (출처: Desktop Remote Troubleshooting)
Q11: 파일 삭제·셸 명령을 시켰는데 승인 창이 안 뜬다. YOLO도 꺼 둔 것 같은데?
YOLO만 꺼 둔 걸로는 부족할 수 있다. 기본값 approvals.mode: smart는 덜 위험한 Shell 명령을 자동 승인한다. YOLO 상태는 /yolo 또는 Cmd/Ctrl+K → Toggle yolo로 확인하는 편이 안전하다. 상태 바는 기본이 OFF다. 위험한 Shell 명령을 매번 확인하려면 hermes config set approvals.mode manual 후 새 세션을 연다. write_file/patch는 denylist·safe-root 경로다. (§7.1–7.2)
Q12: 앱 업데이트는 어떻게 하나?
Desktop은 백그라운드 업데이트 알림과 원클릭 업데이트를 띄운다. CLI로 설치한 경로라면 hermes update도 같은 길이다. 설치만 하고 끝내지 말고, 큰 UI 변경 전에 버전을 맞춰 두자. (출처: Desktop — Updating)
10. 결론 — 오늘 할 일 3가지
3편은 Desktop 입구를 여는 법이다. Desktop은 새 에이전트가 아니다. 같은 코어를 화면으로 다루는 문이다.
오늘부터 이렇게
- 오늘: 공식 설치 또는
hermes desktop→ 모델 연결 → 파일 1개 드래그해서 요약. 화면 ①~⑥ 위치만 익힌다. 여유 있으면 Quick Entry 단축키도 한 번 켜 본다. - 이번 주: Capabilities(Skills/Tools) 토글 정리, Messaging Allowed user IDs 채우기, Settings → Model → Auxiliary 점검. YOLO는 OFF, 필요하면
approvals.mode manual. Git 저장소면 Cmd/Ctrl+G로 리뷰 패널도 한 번. VPS/도메인이 있으면 §8 Remote를 테스트한다. - 운영: 프로필로 로컬/원격 분리, Cron 1개, 공개 도메인이면 OAuth·HTTPS. 데이터는 엔진이 있는 쪽
HERMES_HOME기준으로 백업. 학습된 스킬·기억은/journey로 한 번 훑어 보면 4편 예습이 된다.
다음 편(4편)에서는 Desktop Skills 패널 뒤에서 돌아가는 스킬 시스템·자가생성 SKILL.md를 본다. GUI 입구를 연 뒤에는, 1편에서 말한 "학습된 방식이 파일로 남는다"를 화면과 파일 양쪽에서 확인하기 쉽다.
시리즈 이어보기
Part 1 시작하기 · Part 2 보조 모델 · Part 3 Desktop (현재) · Part 4 Skills System (다음)
참고자료
공식 문서
'AI > Hermes' 카테고리의 다른 글
| Hermes Agent(2) : 보조 모델(Auxiliary Model) 분리 - 비싼 메인 모델 대신 보조 모델 따로 쓰는 법 (4) | 2026.05.02 |
|---|---|
| Hermes Agent(1) 시작하기 : 쓸수록 똑똑해지는 AI 에이전트(자가학습 메커니즘) - Hermes Agent로 반복 업무 자동화하기 (4) | 2026.04.09 |
소중한 공감 감사합니다