헤르메스(hermes) 설치기 1단계-운영 중인 서버에 AI 에이전트를 들였습니다.

2026-07-15 ·조회 1 ·약 13분

운영 중인 서버에 AI 에이전트를 들였습니다 — Hermes 설치기 1단계

카테고리: AI 기반 개발 / 서버 운영 태그: Hermes, AI에이전트, 서버설치, 리눅스, 자동화

잘 돌아가는 서버에 뭘 또 설치한다고?

블로그 서버는 멀쩡히 돌아가고 있었습니다. PHP에 MariaDB, 글도 잘 올라가고 방문자도 꾸준합니다.

그런데 욕심이 하나 생겼습니다.

"터미널 안에 AI 조수를 상주시키면, 글쓰기부터 서버 관리까지 말로 시킬 수 있지 않을까?"

그래서 Hermes라는 AI 에이전트를 설치하기로 했습니다. 단, 조건이 하나 있었습니다.

운영 중인 블로그 시스템은 절대 건드리지 않는다.

이 글은 그 조건을 지키면서 설치를 끝낸 실제 기록입니다. 따라할 수 있게 명령어도 전부 남깁니다.

설치 전에 서버부터 손봤습니다

원래 서버는 2GB RAM이었습니다. 그런데 확인해보니 문제가 있었습니다.

2GB 환경에서는 프로세스 격리 시 스왑(Swap)이 발생할 가능성이 있습니다. AI 에이전트가 돌다가 스왑이 터지면 멀쩡하던 블로그까지 느려집니다. 세입자 하나 들이려다 집주인이 쫓겨나는 상황이죠.

그래서 설치 전에 4GB RAM / 128GB NVMe로 먼저 올렸습니다.

내 경험상 이런 작업은 순서가 중요합니다. 소프트웨어부터 깔고 나서 "어, 느려지네?" 하며 사양을 올리면 원인 분리가 안 됩니다. 환경 먼저, 설치는 그다음.

핵심 설계: 본체는 1개, 명패는 여러 개

설치 방식을 정하는 데 고민이 하나 있었습니다. 사이트마다 Hermes를 따로 깔 것인가, 서버에 하나만 깔 것인가.

결론은 전역 설치 1개입니다. 구조는 이렇습니다.

┌─────────────────────────────────────────────────────┐
│                      서버 전체                        │
│                                                     │
│  /usr/local/lib/hermes-agent   ← Hermes 본체 (1개)   │
│  /usr/local/bin/hermes         ← 전역 실행 명령       │
│                                                     │
│  /root/.hermes                 ← 데이터/설정/메모리    │
│    └─ profiles/blog-system     ← 블로그용 프로필       │
│         └─ project: blog-maocafe-com (명패)          │
│                        │                            │
│                        ▼ 연결(참조)                   │
│  /home/cafe/web/blog.maocafe.com/public_html        │
│                                ← 실제 작업 웹루트      │
└─────────────────────────────────────────────────────┘

비유하자면 이렇습니다.

Hermes는 사무실에 1명만 있는 직원이고, 프로필은 업무 노트, 프로젝트는 "이 일은 저 건물에서 한다"는 명패입니다. 직원을 건물마다 채용하지 않습니다.

이 구조 덕분에 실제 블로그 파일은 원래 자리에 그대로 있고, Hermes 쪽에는 기억과 설정만 쌓입니다.

설치: 그런데 스크립트를 바로 실행하지 않았습니다

공식 설치법은 한 줄입니다.

curl -fsSL https://raw.githubusercontent.com/NousResearch/hermes-agent/main/scripts/install.sh | bash

편하죠. 그런데 저는 이렇게 했습니다.

curl -s -L -o /tmp/hermes-install.sh https://raw.githubusercontent.com/NousResearch/hermes-agent/main/scripts/install.sh
bash /tmp/hermes-install.sh --skip-setup

두 가지 이유가 있습니다.

첫째, 내려받아서 내용을 먼저 봤습니다. 인터넷의 셸 스크립트를 root 권한으로 바로 실행하는 건, 모르는 사람에게 집 열쇠를 주는 것과 같습니다. 운영 서버라면 한 번 열어보는 습관을 추천드려요.

둘째, --skip-setup으로 설치와 API 설정을 분리했습니다. 본체가 정상 설치되는지 먼저 확인하고, 모델/API 키는 나중에 넣습니다. 한 번에 하나씩 해야 문제가 생겼을 때 어디서 터졌는지 압니다.

참고로 설치 스크립트는 시스템 Node.js와 별개인 관리형 Node 22 LTS를 ~/.hermes/node/에 따로 설치합니다. 서버에서 돌고 있는 다른 웹 서비스와 버전 충돌이 원천 차단된다는 뜻이라, 운영자 입장에서 안심되는 설계였습니다.

설치 확인

command -v hermes
# /usr/local/bin/hermes

hermes --version

Hermes Agent v0.18.2 (2026.7.7.2)
Install directory: /usr/local/lib/hermes-agent
Install method: git
Python: 3.11.2
OpenAI SDK: 2.24.0
Up to date

여기까지는 순조로웠습니다. 진단도 돌립니다.

hermes doctor        # 상태 진단
hermes doctor --fix  # 자동 수정 가능한 항목 정리

--fix로 설정 파일 버전 마이그레이션과 실행 링크 정리가 자동으로 끝났고, Python 환경, SSL, 브라우저 도구, Skills Hub까지 전부 정상.

물론 전부 깔끔하진 않았습니다

솔직하게 적습니다. 설치 중 ffmpeg가 apt 의존성 문제로 설치되지 않았습니다. 경고도 몇 개 나왔습니다.

php8.3-redis -> php8.3-igbinary 의존성 문제
Sury 저장소 서명 만료 경고
일부 Playwright 의존성 설치 경고

처음엔 뭔가 잘못됐나 싶었는데, 확인해보니 판단 기준이 명확하더라고요.

ffmpeg 없음 = TTS, 음성, 비디오 기능 제한. Hermes 본체 동작에는 영향 없음.

운영 서버에 뭘 설치하면 잔경고는 늘 나옵니다. 중요한 건 경고 개수가 아니라 "본체가 도는가" 입니다. hermes doctor 기준으로 정상이면 넘어가고, 나중에 해당 기능이 필요할 때 처리하면 됩니다.

프로필과 프로젝트 연결

이제 블로그 전용 방을 만듭니다.

hermes profile create blog-system --clone --description "Profile for evaluating Hermes against the production blog system and isolating related memory, skills, and settings."

생성하면 래퍼 명령까지 만들어져서, 아래 셋이 전부 같은 프로필을 가리킵니다.

hermes --profile blog-system
hermes -p blog-system
blog-system

그리고 실제 웹루트를 프로젝트로 등록합니다.

blog-system project create "maocafe-blog-system" /home/cafe/web/blog.maocafe.com/public_html \
  --slug maocafe-blog-system \
  --primary /home/cafe/web/blog.maocafe.com/public_html \
  --use

여기서 사소한 삽질 하나

처음에 slug를 maocafe-blog-system으로 지었다가, 나중에 보니 도메인 기준이 훨씬 직관적이겠더라고요. 그래서 도메인으로 바꾸려는데...

Hermes는 slug에 점(.)을 허용하지 않습니다. blog.maocafe.com을 그대로 못 씁니다.

그래서 최종적으로 이렇게 정리했습니다.

Hermes profile:      blog-system
Hermes project slug: blog-maocafe-com   (점 대신 하이픈)
Hermes project name: blog.maocafe.com   (표시 이름은 점 가능)
실제 작업 경로:       /home/cafe/web/blog.maocafe.com/public_html

확인:

blog-system project list
# * blog-maocafe-com    blog.maocafe.com  [1 folder(s)]

이름 짓기는 처음부터 규칙을 정하고 시작하세요. 저처럼 중간에 바꾸면 한 번 더 손이 갑니다.

완성된 사용 방식

이제 블로그 작업은 이 두 줄이면 됩니다.

cd /home/cafe/web/blog.maocafe.com/public_html
blog-system chat

파일 수정은 항상 원래 웹루트에서 일어나고, Hermes에는 작업 기억과 설정만 쌓입니다. 처음 세운 조건 — "운영 시스템은 건드리지 않는다" — 이 지켜진 겁니다.

⚠️ 백업 한 줄 추가하세요

Hermes의 모든 데이터는 /root/.hermes에 모입니다. 웹루트만 백업하던 기존 스크립트라면 이 경로를 반드시 추가해야 작업 이력과 메모리가 보존됩니다. 이거 빼먹으면 서버 복구 후에 AI가 기억상실에 걸립니다.

검증 체크리스트

"설치된 것 같은데?"로 끝내지 않고 하나씩 확인했습니다.

확인 항목	결과
`hermes` 전역 명령 인식	✅ /usr/local/bin/hermes
버전/설치 경로 확인	✅ v0.18.2, git 설치
`hermes doctor --fix`	✅ 전 항목 정상
`blog-system` 프로필 생성	✅ 래퍼 명령 포함
프로젝트 → 실제 웹루트 연결	✅ project show로 경로 확인
기존 블로그 정상 동작	✅ 영향 없음
ffmpeg	⚠️ 미설치 (본체 무관, 보류)

이번 단계에서 배운 것

첫째, 환경 먼저 소프트웨어는 나중. RAM 증설을 설치 전에 끝냈기 때문에 이후 문제가 생겨도 원인을 분리할 수 있습니다.

둘째, 설치와 설정은 분리한다. --skip-setup 한 옵션이 "어디서 터졌는지 모르겠다"를 예방했습니다.

셋째, 경고의 개수가 아니라 본체 동작으로 판단한다. 잔경고에 하나하나 반응하면 운영 서버에서는 아무것도 설치 못합니다.

다음 편 예고

2단계 "왜 기존 서버에 Hermes를 붙였는가"는 일부러 아직 안 씁니다. 검증 전이거든요.

API/모델 설정 → 프로젝트 경로 읽기 확인 → 기존 마크다운 글쓰기 자료 이해 테스트 → 실제 글 초안 1개 품질 비교, 이 순서로 직접 돌려본 뒤에 씁니다. 잘된 것만 아니라 실패하고 불편했던 것까지 그대로 기록할 예정입니다.

계획서는 누구나 씁니다. 검증 기록은 해본 사람만 씁니다.

이 글은 실제 운영 서버에서 진행한 설치 기록입니다. 검증: hermes doctor 통과 · 프로젝트 경로 연결 확인 · 기존 서비스 영향 없음 확인