소개
최근에 “24시간 켜져 있는 개인 AI 비서”를 만들어보고 싶다는 생각이 들었습니다. 처음에는 맥미니 M4 같은 로컬 장비를 사서 에이전트를 돌리는 방법을 고민했습니다. 그런데 곰곰이 생각해보니, 제가 진짜 원하는 것은 고성능 컴퓨터 자체가 아니라 언제든 접속할 수 있고, 메시지를 보내면 응답하는 자동화 비서였습니다.
그래서 방향을 바꿨습니다.
“맥미니를 사지 않고도 클라우드에서 24시간 돌아가는 에이전트를 만들 수 있지 않을까?”
이번 실험은 이 질문에서 출발했습니다. 목표는 단순했습니다.
클라우드 서버에서 24시간 작동하는 에이전트 구축하기
텔레그램으로 어디서든 명령을 보내기
Hermes Agent를 설치해 에이전트 프레임워크로 활용하기
모델 Provider는 OpenAI Codex / GPT-5.5 계열로 연결하기
이후 웹페이지, 앱 개발, 업무 자동화로 확장 가능한 구조 만들기
처음에는 “Hermes 모델을 설치한다”는 생각으로 시작했지만, 진행하다 보니 제가 실제로 원한 것은 Hermes Agent라는 에이전트 프레임워크를 설치하고, 외부 모델을 두뇌로 연결하는 것에 가까웠습니다. 이 차이를 이해하는 데 꽤 많은 시행착오가 있었습니다. 😅
진행 방법
1. 먼저 로컬 장비 대신 VPS를 선택했다
처음 고민한 선택지는 크게 세 가지였습니다.
맥미니 같은 로컬 장비를 사서 직접 운영하기
GPU 서버를 빌려 모델을 직접 돌리기
저가형 VPS에 에이전트 프레임워크를 올리고, 모델은 외부 Provider로 연결하기
최종적으로는 DigitalOcean Droplet을 선택했습니다.
선택 이유는 이랬습니다.
사용량에 따라 유연하게 비용 관리 가능
서버 생성과 삭제가 비교적 쉬움
문서와 커뮤니티 자료가 많음
향후 웹, 앱, API 서버로 확장하기 좋음
싱가포르 리전으로 한국에서도 비교적 안정적인 접속 가능
Vultr 서울 리전도 마지막까지 고민했지만, 이번 실험에서는 관리 편의성과 확장성을 더 중요하게 보고 DigitalOcean을 선택했습니다.
[캡처 위치: DigitalOcean Droplet 생성 화면]
2. SSH Key 기반으로 서버에 접속했다
윈도우 PowerShell에서 SSH 키를 생성했습니다.
ssh-keygen -t ******* -C "my_agent_key"처음에는 서버 접속 시 비밀번호를 요구하는 문제가 있었습니다.
root@서버IP's password:
Permission denied, please try again.원인은 SSH 키를 자동으로 찾지 못하거나, Droplet 생성 시 SSH Key가 제대로 연결되지 않은 것이었습니다. 이후에는 키 경로를 직접 지정해서 접속했습니다.
ssh -i C:\Users\사용자명\.ssh\id_******* root@서버IP접속에 성공하자 이런 화면이 나왔습니다.
Welcome to Ubuntu 24.04 LTS
root@Hermes-Agents1:~#이 순간부터 “진짜 내 클라우드 컴퓨터에 들어왔다”는 느낌이 들었습니다. 😊
3. 서버 기본 세팅을 진행했다
서버에 접속한 뒤에는 운영체제를 업데이트하고, Python과 필요한 도구를 설치했습니다.
apt update && apt upgrade -y
apt install python3-pip python3-venv git nano -y업데이트 중에는 openssh-server 설정 파일을 새 버전으로 바꿀지 묻는 화면이 나왔습니다. 여기서는 SSH 접속 설정이 꼬이지 않도록 기존 설정 유지 옵션을 선택했습니다.
keep the local version currently installed이후 커널 업데이트 안내가 나와 서버를 재부팅했습니다.
reboot다시 접속한 뒤 에이전트 전용 폴더와 Python 가상환경을 만들었습니다.
mkdir ~/my_agent && cd ~/my_agent
python3 -m venv venv
source venv/bin/activate가상환경이 활성화되면 터미널 앞에 (venv)가 표시됩니다.
(venv) root@Hermes-Agents1:~/my_agent#4. Hermes “모델”이 아니라 Hermes “Agent”를 설치했다
처음에는 openhermes 같은 모델을 직접 서버에 설치하려는 방향으로 생각했습니다. 하지만 VPS 사양이 2GB RAM 수준이라 7B급 모델을 직접 구동하기에는 무리가 있었습니다.
여기서 중요한 전환이 있었습니다.
내가 필요한 것은 로컬 모델 구동이 아니라, 24시간 작동하는 에이전트 프레임워크였다.
그래서 Nous Research의 Hermes Agent를 설치하는 방향으로 바꿨습니다.
curl -fsSL https://raw.githubusercontent.com/NousResearch/hermes-agent/main/scripts/install.sh | bash설치 후에는 다음 명령어들을 사용할 수 있게 되었습니다.
hermes
hermes setup
hermes setup model
hermes setup gateway
hermes gateway start
hermes gateway stop
hermes doctor[캡처 위치: Hermes Agent 설치 완료 화면]
5. 모델 Provider 설정에서 가장 많이 헷갈렸다
가장 큰 혼란은 “Hermes”, “Claude”, “OpenAI”, “Codex”, “GPT-5.5”의 관계를 구분하는 일이었습니다.
정리하면 이렇습니다.
Hermes Agent: 에이전트 프레임워크
Provider: 실제 모델을 호출하는 연결 방식
Model: 에이전트가 실제로 사용하는 두뇌
Gateway: Telegram 같은 외부 메시징 플랫폼과 연결해주는 통로
제가 원한 최종 구조는 아래와 같았습니다.
Telegram
↓
Hermes Gateway
↓
Hermes Agent
↓
OpenAI Codex / GPT-5.5 계열 모델중간에 Claude Pro OAuth도 시도했고, OpenRouter 설정 오류도 만났고, openai-codex와 openai Provider 이름 사이에서도 헷갈렸습니다.
특히 아래와 같은 오류가 반복되었습니다.
Provider authentication failed.
The model provider failed after retries.
HTTP 401: Missing Authentication header
HTTP 401: invalid x-api-key이때 알게 된 점은 간단했습니다.
에이전트 본체에서 잘 동작해도, Gateway 서비스가 같은 인증 정보를 읽는다는 보장은 없다.
즉, 터미널에서 직접 hermes를 실행했을 때는 정상 작동해도, 텔레그램 Gateway에서는 별도의 환경 변수나 설정 파일을 읽기 때문에 실패할 수 있었습니다.
6. Telegram Gateway를 연결했다
텔레그램에서는 BotFather로 봇을 만들고 토큰을 발급받았습니다.
BotFather → /newbot → 봇 이름 설정 → 봇 토큰 발급Hermes Agent에서는 Gateway 설정을 통해 Telegram을 연결했습니다.
hermes setup gateway설정 과정에서 입력한 값은 다음과 같습니다.
TELEGRAM_BOT_TOKEN="텔레그램 봇 토큰"
TELEGRAM_CHAT_ID="내 텔레그램 숫자 ID"여기서 중요한 점은 TELEGRAM_CHAT_ID에는 @아이디가 아니라 숫자 ID가 들어가야 한다는 것입니다.
숫자 ID는 텔레그램의 @userinfobot 또는 @myidbot을 통해 확인할 수 있었습니다.
Allowed user IDs: *********
Home channel: *********이후 Gateway를 재시작했습니다.
hermes gateway stop
hermes gateway start텔레그램에서 /start를 눌렀을 때는 다음과 같은 메시지가 나왔습니다.
Unknown command /start. Type /commands to see what's available.처음에는 실패라고 생각했지만, 사실 Hermes Agent는 /start 명령을 사용하지 않았습니다. 슬래시 없이 그냥 일반 메시지를 보내야 했습니다.
안녕 헤르메스그제야 봇이 반응하기 시작했습니다.
7. 실제로 사용한 대표 질문들
이번 실험에서 ChatGPT / Gemini와 나눈 질문들은 대부분 “선택지를 좁히는 질문”과 “오류를 해결하는 질문”이었습니다.
Hermes나 OpenClaw를 이용해서 24시간 돌아가는 에이전트 비서를 만들고 싶어.
보통 맥미니를 구매해서 돌리던데, 클라우드나 웹상에서 에이전트를 구축하는 방법은 없을까?DigitalOcean과 Vultr 중 나에게 더 적합한 건 뭘까?
사용하기 편리하고, 초기 세팅이 어렵지 않고, 문제가 발생했을 때 바로 대응 가능하면 좋겠어.DigitalOcean 싱가포르 리전을 선택했어.
계정 생성부터 보안이 강화된 첫 서버 개설까지 과정을 알려줘.Hermes Agent를 설치하려고 하는 거야.
지금 (venv) root@Hermes-Agents1:~/my_agent# 다음 단계에서 Hermes 설치하는 방법 알려줘.텔레그램 봇 채팅방에서 /start해도 반응이 없어.클로드가 아니라 OpenAI Codex GPT-5.5를 쓰고 싶어.이 질문들을 돌아보면, 단순히 명령어를 복사해서 실행한 것이 아니라, 내가 진짜 만들고 싶은 구조를 계속 재정의하는 과정에 가까웠습니다.
결과와 배운 점
1. 반은 서버 구축, 반은 개념 정리였다
이번 자동화의 핵심은 단순히 서버를 만드는 것이 아니었습니다. 오히려 더 어려웠던 것은 각 구성요소의 역할을 구분하는 일이었습니다.
VPS는 24시간 켜져 있는 몸통
Hermes Agent는 행동하는 에이전트 프레임워크
Provider는 모델 연결 방식
GPT-5.5 / Codex는 실제 두뇌
Telegram Gateway는 외부에서 대화하는 입구
이 구조가 머릿속에 정리되자, 오류 메시지도 훨씬 덜 무섭게 보였습니다.
2. “CLI에서 됨”과 “Gateway에서 됨”은 다르다
가장 큰 시행착오는 이것이었습니다.
터미널에서
hermes로 직접 실행했을 때는 작동하는데, 텔레그램에서는 실패한다.
처음에는 모델 인증이 아예 안 된 줄 알았습니다. 하지만 로그와 설정 파일을 확인하면서 원인이 더 구체화되었습니다.
CLI 세션은 현재 터미널의 인증 정보를 읽을 수 있음
Gateway 서비스는 별도로 실행되며,
.env와config.yaml을 기준으로 동작함따라서 CLI와 Gateway의 환경 변수가 다르면 한쪽만 성공할 수 있음
앞으로는 새로운 Provider를 연결할 때 반드시 아래 세 가지를 확인하려고 합니다.
head -n 25 ~/.hermes/config.yaml
cat ~/.hermes/.env | grep -E "OPENAI|ANTHROPIC|TELEGRAM"
hermes gateway restart단, 실제 키값을 출력하거나 공유할 때는 반드시 마스킹해야 합니다.
3. 보안은 “나중에”가 아니라 “처음부터” 챙겨야 한다
이번 과정에서 API Key와 Telegram Bot Token이 얼마나 민감한 정보인지 다시 느꼈습니다.
앞으로 비슷한 작업을 할 때는 아래 원칙을 지키려고 합니다.
API Key와 Bot Token은 코드에 직접 적지 않기
.env파일에 저장하고 외부에 공유하지 않기스크린샷이나 게시글에 키가 노출되지 않았는지 확인하기
실수로 노출했다면 즉시 폐기하고 재발급하기
SSH 접속은 비밀번호가 아니라 SSH Key 기반으로 설정하기
특히 이번 사례글에 포함된 모든 키와 토큰은 실제 값이 아니라 아래처럼 마스킹해서 공유해야 합니다.
OPENAI_API_KEY="sk-...마스킹..."
TELEGRAM_BOT_TOKEN="123456789:...마스킹..."
TELEGRAM_CHAT_ID="숫자_ID"4. 자동화는 한 번에 완성되는 게 아니라, 디버깅하면서 자란다
처음에는 “24시간 AI 비서 하나 만들기” 정도로 생각했습니다. 그런데 실제로 해보니 선택해야 할 것이 많았습니다.
어떤 VPS를 쓸 것인가?
어떤 리전을 선택할 것인가?
로컬 모델을 돌릴 것인가, 외부 Provider를 쓸 것인가?
API 종량제를 쓸 것인가, 구독 기반 CLI를 쓸 것인가?
텔레그램에서 누구에게만 응답하게 할 것인가?
CLI와 Gateway 환경을 어떻게 맞출 것인가?
이 과정에서 느낀 가장 큰 교훈은 이것입니다.
자동화는 “완성된 정답”을 복사하는 일이 아니라, 내 상황에 맞는 구조를 계속 조립하고 검증하는 일이다.
5. 다음에 해보고 싶은 것
이번 실험은 “텔레그램으로 말을 걸 수 있는 24시간 에이전트”를 만드는 데 초점을 맞췄습니다. 다음 단계에서는 이 비서를 더 실용적인 업무 자동화 도구로 발전시켜보고 싶습니다.
해보고 싶은 확장 방향은 다음과 같습니다.
매일 아침 업무 브리핑 자동 전송
서버 로그나 프로젝트 진행 상황 요약
식물 데이터, GIS 데이터, 드론 촬영 데이터 정리 보조
웹페이지나 앱 개발 보조 에이전트로 활용
정기 작업 예약과 결과 보고 자동화
자주 쓰는 작업을 Hermes Skill로 축적하기
궁극적으로는 텔레그램에서 한 줄로 요청하면, 서버 안에서 코드를 만들고 실행하고 결과까지 정리해주는 개인 자동화 비서로 키워보고 싶습니다. 🚀
도움 받은 글 (옵션)
Nous Research Hermes Agent GitHub: https://github.com/NousResearch/hermes-agent
Hermes Agent Quickstart 문서: https://github.com/NousResearch/hermes-agent/blob/main/website/docs/getting-started/quickstart.md
DigitalOcean Droplets SSH 접속 문서: https://docs.digitalocean.com/products/droplets/how-to/connect-with-ssh/
DigitalOcean SSH Key 추가 문서: https://docs.digitalocean.com/products/droplets/how-to/add-ssh-keys/
Telegram Bot Tutorial: https://core.telegram.org/bots/tutorial
OpenAI GPT-5.5 모델 문서: https://developers.openai.com/api/docs/models/gpt-5.5
OpenAI Codex 문서: https://openai.com/codex/
마무리 메시지
이번 실험을 통해 느낀 것은, AI 자동화는 거창한 시스템부터 시작하지 않아도 된다는 점입니다.
처음에는 “텔레그램에서 내 서버에 있는 AI 비서에게 말을 걸어본다” 정도의 작은 목표로 시작해도 충분합니다. 그 과정에서 SSH, VPS, Provider, Gateway, 토큰, 로그, 환경 변수 같은 개념들이 자연스럽게 연결됩니다.
저처럼 중간에 여러 번 헷갈리더라도 괜찮습니다. 오히려 그 과정이 자동화 시스템을 이해하는 가장 좋은 학습 경로였습니다. 😊
작은 자동화 하나가 결국 나만의 업무 운영체제로 자랄 수 있다.
이번 Hermes Agent 실험은 그 가능성을 확인한 첫 번째 삽질기였습니다
