「이거, 전에도 부탁했을 텐데 말이야」——AI를 향해 그렇게 생각한 순간은 없으신가요? ChatGPT도 Claude도, 물어보면 똑똑하게 대답해 줍니다. 하지만 내일이 되면 모든 것을 잊어버리고, 다시 처음부터 사정을 설명해야 합니다. 어제 가르쳐준 방식을 오늘 또 다시 알려줘야 합니다. 똑똑할 텐데도, 나의 방식은 도무지 기억해주지 않습니다. 게다가 컴퓨터를 닫으면 멈춰버리고, 외출 중인 스마트폰으로는 끊어서밖에 부탁할 수 없습니다. 만약, 부탁할수록 자신의 절차를 기억하여 자신만의 전용 AI로 성장해 나가고, 컴퓨터를 닫아도 멈추지 않으며, 아침이면 결과를 전달해 주는 AI가 있다면 어떨까요.

이 연재는 그것을 월 1,800엔 정도의 렌탈 서버 1대로 만드는 기록입니다. 터미널(Terminal)에 익숙하지 않더라도, 실제 화면을 하나씩 확인하며 진행할 수 있도록 작성했습니다. 제1회는 첫 번째 서버를 빌려서 안전하게 로그인할 수 있는 단계까지 진행합니다.

목차

• 이번 회의 도달점
• 애초에 Hermes Agent란 무엇인가
• 왜 지금 Hermes Agent인가
• 제1회 종료 시점의 구성도
• XServer VPS 6GB를 계약하기
• Linux에서 헤매지 않기 위한 최소한의 지식
• 관리 사용자를 만들어 안전하게 로그인하기
• 자주 발생하는 에러와 대처법
• 요약 및 제2회 예고
• 참고 링크

이번 회의 도달점

자율형 AI 에이전트(Autonomous AI Agent)인 Hermes Agent를 VPS에 상주시킨 기록입니다. XServer VPS 6GB(Ubuntu 26.04)를 계약하고, 로그인이 가능한 상태로 만든 뒤, 관리 사용자(admin)를 생성하고, SSH 키 인증(SSH Key Authentication)으로 전환하며, root의 SSH 로그인을 차단하는 부분까지 다룹니다.

실제 기기에서 직접 입력하며 작성한 메모이므로, 깔끔한 매뉴얼은 아닙니다. 막혔던 부분까지 포함해서 읽어주셨으면 합니다.

먼저 이 기사에서 여러 번 등장하는 세 가지 용어만 설명해 두겠습니다.

VPS(Virtual Private Server): 클라우드 사업자로부터 빌리는 자신만의 전용 Linux 머신. 전원이나 네트워크 회선 관리는 사업자가 해주므로, 빌린 순간부터 24시간 작동하는 서버를 얻을 수 있습니다.
SSH(Secure Shell): 내 PC에서 멀리 떨어진 서버에 로그인하여, 문자로 명령어를 입력해 조작하는 메커니즘. 화면 공유가 아니라 명령을 입력하여 움직입니다.
root: 해당 서버에서 무엇이든 할 수 있는 최고 권한을 가진 사용자. 편리하지만, 오타 하나가 시스템 전체의 파괴로 이어질 수 있기 때문에 평소 사용에는 적합하지 않습니다.

애초에 Hermes Agent란 무엇인가

Hermes Agent는 Nous Research가 공개한 오픈 소스(Open Source) 자율형 AI 에이전트입니다. 영구적인 메모리와 자기 생성 기술을 가지고 있으며, Telegram 등의 메시징 서비스를 통해 말을 걸어 사용할 수 있습니다.

구성을 역할별로 나누면 세 명의 등장인물이 있습니다.

포인트는 Hermes 본체는 '준비 담당자'이며, 사고 그 자체는 외부의 AI 모델에 맡기고 있다는 점입니다. 제 환경에서는 기존의 ChatGPT/Codex 구독을 OAuth로 연결하여, openai-codex 프로바이더(2026년 5월 기준 최신 Codex 모델)로 구동하고 있습니다. xAI의 최신 Grok으로 전환하고 싶다면 xai-oauth 프로바이더를 선택합니다. 구체적인 전환 명령어는 제5회(Grok OAuth 등록 회차)에서 다룹니다.

왜 지금 Hermes Agent인가

Hermes Agent는 2026년에 들어서며 급격히 존재감을 드러내고 있습니다. 수치로 말하자면, 2026년 2월 25일 출시 후 약 3개월 만에 GitHub 스타 17만 개 돌파·기여자 1,000명 가까이(2026년 5월 시점 약 171,000 스타)를 모았으며, 5월 10일 시점에는 OpenRouter의 모든 AI 에이전트 중 일일 토큰 소비량 1위(224B/일)를 차지했습니다. 전임자인 OpenClaw의 186B/일을 제쳤으며, 약 30%의 OpenClaw 사용자가 갈아탔다고 알려져 있습니다(Reddit 조사).

참고:

• OpenClaw vs Hermes Agent (MarkTechPost)
• Persistent AI Agents Compared (The New Stack)
• Hermes Agent 공식 GitHub README

다른 AI 도구와의 차이점은 무엇인가

「AI에게 말을 걸어 작업을 시키는 것」만 목적이라면, 이미 Claude Code, Codex CLI, Cursor, Continue.dev 등 유사한 도구는 산더미처럼 많다. Hermes Agent가 다른 점은, **도구가 아니라 상주형 에이전트 (Resident Agent)**로 설계되었다는 점이다. 비교표로 정리한다.

Claude Code와 Codex CLI는 「대화형 코딩 어시스턴트」이며, Hermes Agent는 「상주하는 범용 비서」라고 이해하면 틀리지 않는다.

그리고 이러한 에이전트의 우열을 마지막에 가르는 것은 모델의 똑똑함보다 **아키텍처 (Architecture)**다. 어떤 도구와 스킬을 갖추게 할지, 기억을 어떻게 남길지, 사용할수록 배우는 루프를 어떻게 돌릴지 말이다. 말하자면 9할이 아키텍처이고 1할이 AI다. 본 연재에서 일관되게 다루는 것은 바로 그 메커니즘이며, 제2회 이후를 단계별로 준비해 나갈 것이다.

Hermes Agent가 다른 점

공식 README와 운용 기사 양쪽에서 드러나는 설계 판단을 살펴보자.

자기 개선 루프 (Self-improving learning loop)

Hermes Agent의 최대 특징은, 5회 이상 도구를 호출한 태스크 후에 reflection(성찰)을 실행하여 재사용 가능한 스킬 파일을 자동 생성한다는 점이다. reflection은 되돌아본다는 의미다. 동일한 조사나 동일한 셋업을 다음에 반복하지 않는다. OpenClaw가 「통합의 폭」에 집중했다면, Hermes Agent는 「학습의 깊이」에 무게를 둔 설계상의 판단이 여기에 나타나 있다.

메시징에서 상주 조작으로

Telegram, Discord, Slack, WhatsApp, Signal, CLI의 6가지 입구를 지원한다 (지원 플랫폼 수만 따지면 OpenClaw의 20개보다 적지만, 핵심 기능은 모두 갖추고 있다). 스마트폰에서 LINE을 사용하는 듯한 감각으로 말을 걸어, VPS 상에서 장시간 태스크를 실행하는 운용이 가능하다. 음성 메모도 자동으로 텍스트로 변환(Transcription)된다.

어디에나 배치 가능 (7가지 백엔드)

local / Docker / SSH / Singularity / Modal / Daytona / Vercel Sandbox의 7가지 중 실행 대상을 선택할 수 있다. Modal이나 Daytona를 사용하면 사용하지 않을 때는 잠재워 두었다가, 요청이 오는 순간 깨우는 서버리스 (Serverless) 운용도 가능하다. 나는 XServer VPS 6GB에서 상주시키고 있는데, 이 또한 공식이 상정하는 패턴 중 하나다.

X에서 자주 보이는 반응

X(구 Twitter) 및 개발자 커뮤니티에서 빈출되는 반응은 다음 세 가지로 집약된다.

• 「OpenClaw에서 갈아탔는데, 초기 설정의 번거로움이 줄었다」 (Reddit/Medium 다수)
• 「LLM의 모델 선택지가 넓다 (Nous Portal 경유 시 300개 이상, OpenRouter 경유 시 200개 이상). 구독 하나로 여러 모델을 전환할 수 있다」
• 「자기 생성 스킬이 은근히 효과적이다. 같은 조사를 두 번 할 필요가 없다」

OpenClaw가 2026년 초 보안 문제와 리더의 이탈로 흔들리던 시기와 Hermes Agent의 부상이 겹친 타이밍의 요소도 크지만, 기술적인 승인은 학습 루프의 설계에 있다고 여겨진다 (Turing Post 해설).

제1회 종료 시점의 구성도

내가 정착한 구성은 다음과 같다.

제1회에서 하는 것은 위 그림의 왼쪽 상단 「VPS (클라우드 상)」 중, 계약을 완료하고 admin 사용자로 안전하게 로그인할 수 있는 상태를 만드는 것까지다. 제1회 종료 시점에서 보이는 범위는 다음과 같다.

• VPS (클라우드 상) = 사령탑: Hermes 본체를 상주시킨다. 24시간 깨어 있는 저렴한 접수원
• 자택 데스크톱 = 손발: 무거운 처리나 GPU를 사용하는 태스크만 필요할 때 맡는다
• Tailscale = 전용 통로: VPS와 자택 머신을 인터넷에 노출하지 않고 연결하는 비공개 터널
• 1Password = 보관고 (영어 UI에서는 Vault): API 키, bot 토큰, SSH 키 등의 비밀 정보를 평문으로 노출하지 않고 보관
• Telegram = 창구: 손안의 스마트폰/PC에서 Hermes에게 말을 걸어 응답을 받는다
• 생각하는 역할 = Codex (gpt-5.5): Hermes가 사고를 위임하는 외부 AI 모델. OAuth로 접속

VPS는 상시 가동 비용이 저렴하지만 성능이 낮고, 자택 기기는 성능은 좋지만 24시간 켜두면 전기세와 발열이 부담된다. 역할 분담으로서 '항상 깨어 있는 접수'는 VPS에, '무거운 처리'는 자택 기기에 두는 구성이다. 자택 측은 Lenovo ThinkStation P2 (i7-14700K + RTX 4070, 메모리 16GB)를 사용한다. 이는 현역 고성능 기기이지만, 메인 작업은 노트북 (Windows)으로 처리한다는 전제하에 이 데스크톱은 AI 추론 전용기로 사용하기 위해 Windows를 지우고 Linux를 새로 설치해 두었다.

참고로, 반드시 이 기종이어야만 작동하는 것은 아니다. 자택에서 손발로 사용할 머신은 집에 잠자고 있는 오래된 Windows 노트북이나, 사용하지 않는 Mac (Intel 기반 MacBook이라도 Mac mini라도)으로 충분히 감당할 수 있다. Linux는 가볍기 때문에 최신 Windows를 돌리기에는 너무 무거운 세대의 기기에서도 쾌적하게 작동한다. 이미지 생성이나 로컬 AI 추론까지 본격적으로 할 경우에만 RTX 30 시리즈 이상의 GPU가 필요하지만, 'VPS의 Hermes에서 호출하여 가벼운 처리를 맡기는 상대'로서만 사용한다면 CPU만 있는 오래된 머신이라도 실용적이다. 애초에 자택 기기는 제10회에서 추가하는 임의의 확장 요소이므로, 제1회부터 제9회까지는 VPS만으로 완결된다.

자택 기기의 구성 판단 (Linux 전용기로 운용하는 선택 · GPU 드라이버 · BIOS 설정의 함정)에 대한 상세 내용은 제10회 (집의 PC를 Linux 상주 GPU 서버로 만드는 회차)에서 다룬다. 제1회에서는 '자택 기기 = AI 추론 전용 Linux 기기'라고만 기억해 두면 된다.

이 시리즈에서는 그림 속의 각 요소를 회차마다 구현한다. 제1회는 VPS를 계약하여 admin으로 안전하게 로그인할 수 있는 단계까지 끝낸다.

XServer VPS 6GB 계약하기

이제부터 실제 구축에 들어간다. 프로바이더는 XServer VPS의 6GB 플랜을 선택했다 (4코어 / 6GB / SSD 150GB / 월 1,800엔 전후). 참고로 본 연재에 게시된 링크는 공식 페이지를 가리키는 것이며, 어필리에이트(Affiliate) 링크가 아니다.

플랜 선정 경위도 적어둔다. 초기 설계에서는 ConoHa VPS의 4GB 플랜을 후보로 두었다. Docker가 적용된 이미지로 즉시 구동할 수 있고, 스냅샷(Snapshot)을 통해 시행착오를 겪기 쉽다는 점이 이유였다. 하지만 자세히 따져보니 ConoHa 4GB (갱신 시 월 2,000엔대)보다 XServer VPS 6GB (갱신 시 월 1,800엔 전후)가 오히려 더 저렴하고 용량도 많다는 것을 알게 되었다. Hermes는 상주시키면 은근히 메모리를 사용하기 때문에, 4GB보다는 6GB의 여유가 큰 도움이 된다. 구성 자체는 어떤 프로바이더를 사용하든 다르지 않으므로 (프로바이더 독립적), 갈아타는 데 따른 데미리트도 없다. 게다가 원래 XServer에 휴면 상태의 계약이 있었던 인연도 있어, 새로 6GB 플랜으로 다시 계약하여 XServer 6GB로 결정했다.

해외 VPS (Vultr나 Hetzner 등)에는 더 저렴한 플랜도 있다. 다만 이번에는 처음부터 국내 VPS로 한정했다. 엔화로 결제된다, 관리 화면과 서포트가 일본어다, 국내 데이터 센터라 응답이 빠르다, 트러블 발생 시 일본어로 문의할 수 있다라는 안심감을 비엔지니어(Non-engineer)가 첫 번째 서버를 가질 때의 우선순위로 두었기 때문이다. 익숙해진 뒤 비용을 아끼고 싶다면 해외 VPS로 옮기면 된다. 구성은 프로바이더에 독립적이므로 그 이행 또한 어렵지 않다.

신청부터 대시보드에 도달하기까지의 실제 화면을 순서대로 올려둔다.

1. 플랜 선택 (6GB)

2. 신청 폼에 필요 사항 입력

3. 신청 내용 확인

4. 결제 방법 선택

5. 대시보드에서 서버가 구동 중인지 확인

OS는 Ubuntu 26.04 LTS를 선택했다 (XServer는 2026년 4월에 26.04 대응 완료). 「Docker 앱 이미지」와 같은 구축 완료된 템플릿은 선택하지 않고, 순수한 Ubuntu로 설정한다. Docker는 이후 회차에서 수동으로 설치할 방침이다.

왜 Ubuntu 26.04 LTS를 선택했는지는 다음 절에서 기술한다.

Linux에서 헤매지 않기 위한 최소한의 지식

「VPS를 빌렸는데, 이제 뭘 해야 하지?」라고 생각하는 사람들을 위해, 이 글을 읽어 나가는 데 있어 최소한 알고 있어야 할 Linux 지식을 정리한다. 이미 알고 있는 사람은 건너뛰어도 상관없다.

디스트리뷰션 (Distribution) 선택 방법

Linux에는 「디스트리뷰션 (Distribution)」이라 불리는 파생 버전이 여러 개 있다. Windows로 치면 「Windows 11 Home / Pro」와 같은 차이가 아니라, 조금 더 본격적인 분기이며 각각의 사상과 용도가 다르다.

내가 Ubuntu 26.04 LTS를 선택한 이유는 세 가지다.

• 정보량: 무언가에 막혔을 때, 일본어·영어 모두 해결 정보가 가장 많다. NVIDIA 드라이버나 CUDA, Docker의 공식 대응도 우선 Ubuntu부터 시작된다.
• 장기 지원 (LTS): 26.04 LTS는 2031년 4월까지 지원된다. 상시 가동되는 서버 기기에는 「대규모 업데이트에 휘둘리지 않는 안심」이 필요하다.
• VPS와 자택 기기의 통일: 나중에 나올 자택 기기 (P2)에도 동일한 Ubuntu 26.04를 설치할 예정이다. 두 종류의 Linux를 익힐 필요가 없다.

「일단 서버를 세우고 싶다」는 목적이라면, Ubuntu LTS를 선택해서 틀릴 일은 거의 없다.

명령어와 용어 미니 사전

이 글의 후반부(및 시리즈의 다음 회차)에 등장하는 명령어를 초급자 관점에서 나열해 둔다.

sudo와 apt update && apt upgrade -y만은 반드시 등장하므로, 이것만큼은 의미를 기억하고 다음으로 넘어간다.

관리 사용자를 만들어 안전하게 로그인하기

여기서부터는 구축 중에 추가해 나가겠다. 시리얼 콘솔 (Serial Console)을 통해 root로 접속한 직후의 작업이다.

시리얼 콘솔은 XServer의 관리 화면에서 브라우저를 통해 직접 서버에 로그인할 수 있는 긴급용 입구다. 아직 SSH를 설정하지 않은 지금은 이곳이 유일한 입구가 된다. 나중에 SSH 설정을 실수하여 접속할 수 없게 되었을 때도, 이 입구를 통해 들어와서 고칠 수 있으므로 마지막까지 의지할 수 있는 생명줄이다.

이후에 물어보는 비밀번호를 정리하기

각 상황에서 "지금 묻고 있는 것이 어떤 비밀번호인가"를 혼동하는 것이 가장 흔한 실수다. 나 자신도 구분을 못 해서 몇 번이나 실수했다. 미리 대응표를 정리해 둔다.

요점은 3가지다:

• 시리얼 콘솔 (Serial Console)을 통한 비밀번호 입력은 화면에 아무것도 표시되지 않는다 (마스킹 처리조차 되지 않는다). 오타를 알아차리기 어렵다. 붙여넣기는 우클릭 메뉴를 사용해야 하며, Ctrl+V는 작동하지 않는다.
• "키의 패스프레이즈 (Passphrase)"와 "사용자의 로그인 비밀번호"는 별개다. 키의 패스프레이즈는 SSH 접속 시, 사용자 비밀번호는 sudo 실행 시나 시리얼 콘솔 직접 로그인 시에 사용된다.

시리얼 콘솔 (Serial Console) 여는 법

애초에 관리 화면 어디에서 시리얼 콘솔에 접속하는지 나도 처음에는 헤맸다. XServer VPS 패널의 "VPS 관리" 페이지를 열고, 오른쪽 상단의 "콘솔 (Console)" 버튼을 클릭하면 드롭다운에 "시리얼 콘솔 (Serial Console)", "VNC 콘솔 (VNC Console)" 두 가지가 나타난다. 이번에 사용할 것은 "시리얼 콘솔 (Serial Console)"이다.

VNC 콘솔은 GUI 화면을 원격으로 표시하는 방식이라, CUI로만 운용할 Hermes에는 불필요하다. 시리얼 콘솔이 브라우저만으로 완결되어 더 경쾌하다.

시리얼 콘솔이 새 탭으로 열리면, 처음에는 검은 빈 화면이 표시된다. 여기서 ENTER 키를 한 번 누르면, 그제야 <호스트명> login: 프롬프트가 나타난다. 나는 이것을 몰라서 한동안 새카만 화면만 바라보며 굳어 있었다.

ENTER를 누른 후 프롬프트가 표시되면, root를 입력하고 ENTER.

여기서 비밀번호(XServer에서 발행한 초기 비밀번호)를 묻는다. 시리얼 콘솔은 Ctrl+V가 작동하지 않으므로, 붙여넣기는 우클릭 메뉴를 이용한다. 비밀번호 입력 중에는 화면에 아무것도 표시되지 않으므로(마스킹 처리조차 되지 않음), 잘못 입력했는지 알아차리기 어렵다.

1. 패키지를 최신 상태로 만들기

apt update && apt upgrade -y

이 명령어는 "apt update (카탈로그 업데이트)"와 "apt upgrade -y (내용물 교체 · 전부 yes)"를 &&로 연결한 것이다. 서버를 빌린 직후에 반드시 한 번은 실행해야 하는 명령어다.

실행하면 먼저 카탈로그 취득(hit:1 http://...의 반복)이 진행되고, 업그레이드 대상이 표시된다.

내 VPS에서는 업그레이드 대상이 3개 패키지(base-files / distro-info-data / motd-news-config), 다운로드 크기는 86.4 kB라고 표시되었다.

완료되었을 때 커널 업데이트가 포함되어 있었다면 "Pending kernel upgrade!"라는 재부팅 권장 메시지가 나온다.

커널이 업데이트된 경우에는 reboot로 재부팅해 둔다. 재부팅 후에는 시리얼 콘솔로 다시 접속한다.

2. 비(非) root 사용자 만들기

root 상태로 운용하는 것은 위험하다. 잘못된 명령어가 즉시 전체 시스템 파괴로 이어진다. 평소 사용하는 사용자로 admin을 만들고, 필요할 때만 sudo로 관리자 권한을 빌려 쓰는 것이 Linux의 관례다.

adduser admin
usermod -aG sudo admin
mkdir -p /home/admin/.ssh
...

무엇을 하고 있는지 한 줄씩 짧게 해설한다.

adduser admin
── admin 사용자를 대화형으로 생성한다. 대화 형식으로 비밀번호를 묻는다.

usermod -aG sudo admin
── admin에게 sudo를 사용할 권한을 부여한다.

mkdir -p /home/admin/.ssh
── admin의 SSH 관련 폴더를 생성한다.

cp /root/.ssh/authorized_keys /home/admin/.ssh/authorized_keys
── root에 등록되어 있는 공개키를 admin에게도 복사한다.

chown -R admin:admin /home/admin/.ssh
── 소유자를 admin으로 변경한다 (root 상태 그대로 두면 admin이 읽을 수 없다).

chmod 700 /home/admin/.ssh 와 chmod 600 파일
── 본인 이외에는 읽기/쓰기를 금지한다. SSH는 권한이 느슨하면 거부하는 사양이다.

chmod 755 /home/admin
── 홈 폴더 자체는 "본인은 읽기/쓰기/실행, 타인은 읽기/실행만" 가능하도록 설정한다. adduser가 동일한 권한을 자동으로 부여하므로, 여기서는 확인 차원에서 실행한다.

adduser를 실행하면 먼저 비밀번호 설정 대화가 시작된다.

여기서 설정하는 admin의 비밀번호는 나중에 sudo 명령어를 사용할 때마다 필요하게 된다. 1Password와 같은 패스워드 매니저(Password Manager)로 20자 이상의 랜덤 문자열을 생성하여 사용하는 것이 안전하다. 시리얼 콘솔은 Ctrl+V