블로그

Hermes Agent를 서버에서 24시간 내내 실행하는 방법

Markdown

Hermes Agent를 서버에서 24시간 내내 실행하는 방법: 브라우저 없이 VPS에 설치하고, 게이트웨이를 시스템 서비스로 실행하며, 재부팅 후 자동으로 시작되도록 설정하고, linger와 Docker를 사용하는 방법.

전체 글 읽기

노트북에 Hermes Agent를 설치하고 나면 이런 질문이 떠오릅니다. 노트북을 닫았을 때 Telegram에서 누가 답하고 아침 요약을 준비할까요? 책상 앞에서는 컴퓨터가 켜져 있는 동안에만 에이전트가 작동합니다. 봇을 항상 온라인 상태로 유지하고 예약 작업이 저절로 실행되게 하려면 에이전트를 서버로 옮겨야 합니다.

아래에서는 일반 Linux 서버에 Hermes를 설치하고, 게이트웨이를 계속 실행되며 재부팅 후 자동으로 시작되는 서비스로 전환하고, 낯선 사람이 터미널에 접근하지 못하도록 제한하는 방법을 설명합니다. 이 가이드는 공식 문서를 바탕으로 합니다.

아직 Hermes를 전혀 설치하지 않았다면, 먼저 이 에이전트가 무엇이며 어떻게 설치하는지에 관한 별도의 개요를 읽어 보세요. 이 가이드는 이미 자신의 컴퓨터에서 Hermes를 실행 중이라고 가정하고 서버로 옮기는 방법만 다룹니다.

Ailoot 사용 방법은 문서에서 확인할 수 있습니다.

Hermes Agent를 노트북에서 서버로 옮기는 이유는 무엇인가요?

핵심 내용

개인용 컴퓨터는 사용자가 곁에 있고 전원이 켜져 있는 동안 작동합니다. 24시간 운영하려면 서버가 필요합니다. 컴퓨터가 꺼져 있어도 Telegram 봇이 답하고 예약 작업이 저절로 실행됩니다. 이런 용도로만 서버가 필요하며, 에이전트를 일반적으로 사용하는 데는 노트북이면 충분합니다.

노트북에서는 덮개가 열려 있고 사용자가 곁에 있을 때만 Hermes가 작동합니다. 덮개를 닫으면 봇은 조용해지고 아침 요약도 도착하지 않습니다. “메신저에서 사람들에게 답하고 일정에 따라 일을 처리하는” 작업에는 적합하지 않습니다.

서버는 다릅니다. 서버는 절전 상태가 되지 않고 다른 것에 의존하지 않습니다. 같은 Hermes를 설치하면 사용자가 없어도 작동합니다. 새벽 세 시에 Telegram에서 답하고, 매일 아침 관심 주제의 뉴스를 모으며, 실행 사이에도 세션을 유지합니다.

에이전트가 계속 수행할 작업이 있다면 서버로 옮길 만합니다. 자신이나 팀을 위한 봇, 아침 요약, 자동 응답, 정기적인 문서 작업 등이 이에 해당합니다. 특정 프로젝트에서 Hermes를 시험해 보면서 곁에 있을 뿐이라면 아직 서버가 필요하지 않습니다. 한 단계를 더 거칠 뿐입니다.

VPS에 Hermes를 설치하기 전에 무엇을 준비해야 하나요?

핵심 내용

SSH로 접속할 수 있는 Linux 서버(공식 팀은 새 Ubuntu 설치 환경에서 테스트합니다), 미리 선택한 모델, 그리고 서버에서 에이전트가 대개 브라우저를 필요로 하지 않는다는 이해가 필요합니다. 무인 운영에는 Nous Portal을 통해 모델에 접속하는 방법이 가장 편리합니다. OAuth 로그인이 자동으로 갱신되므로 토큰이 만료되어도 밤사이 서비스가 중단되지 않습니다.

설치 전에 세 가지를 준비하세요.

서버. 일반 Linux VPS면 됩니다. 문서에서 1차 지원 대상으로 안내하는 환경은 Linux와 WSL2이며, 테스트는 최신 Ubuntu에서 진행합니다. 시스템에 glibc, systemd, 익숙한 디렉터리 구조가 있으면 Hermes가 제대로 설치됩니다. 아래의 자동 시작 단계는 모두 Ubuntu와 Debian에 기본으로 포함된 systemd를 사용하므로 서버에서는 이 점이 중요합니다.

SSH 접속. SSH를 통해 터미널로 서버에 연결합니다. 서버에서는 마우스를 사용하지 않습니다. 아래의 모든 명령은 이 SSH 세션에서 실행합니다. 바이브 코딩을 하지만 아직 터미널이 익숙하지 않더라도 걱정하지 마세요. 명령은 몇 개뿐이고 각각 전체를 복사해 실행하면 됩니다.

선택한 모델. 에이전트는 스스로 생각하지 않고 모델을 호출합니다. 사용자 없이 작동하는 서버에서는 모델 접속이 만료되지 않는 것이 중요합니다. 가장 간단한 방법은 hermes setup --portal을 통한 Nous Portal 구독입니다. 로그인에 OAuth를 사용하고 토큰이 자동으로 갱신됩니다. 직접 보유한 API 키도 사용할 수 있지만 계정에 잔액이 있는지 확인하세요. 잔액이 없는 헤드리스 에이전트는 작동을 멈춥니다. 모델의 컨텍스트 윈도우는 최소 64,000 토큰이어야 합니다. 그렇지 않으면 Hermes가 해당 모델로 시작하기를 거부합니다. 목록에 있는 모든 클라우드 모델은 이 요구 사항을 충족합니다.

참고

공식 문서에는 VPS 선택이나 최소 리소스에 관한 정확한 수치가 나와 있지 않으므로 여기에도 구체적인 수치를 제시하지 않습니다. 설명된 경험을 바탕으로 보면, 무거운 계산은 모델 측에서 이루어지므로 봇과 일정이 있는 게이트웨이에는 사양이 낮은 기기로 충분합니다. 서버 자체의 부하는 매우 적습니다. 브라우저 자동화가 가장 무거운 부분이지만 서버에서는 대개 필요하지 않습니다(바로 아래에서 더 설명합니다).

명령 하나로 서버에 Hermes Agent를 설치하려면 어떻게 하나요?

핵심 내용

SSH로 서버에 접속한 뒤 서버에서 브라우저를 제외하는 플래그를 사용해 설치 프로그램을 실행하세요: curl -fsSL https://hermes-agent.nousresearch.com/install.sh | bash -s -- --skip-browser. 그런 다음 터미널 셸을 다시 시작하고 hermes setup --portal로 모델을 선택하세요. hermes doctor로 설치를 확인합니다.

서버 설치는 노트북 설치와 거의 같지만, 한 가지 차이가 있습니다. 서버에서 에이전트는 대개 브라우저가 필요하지 않습니다. 브라우저 자동화에는 용량이 큰 Chromium도 포함됩니다. 그래서 --skip-browser 플래그를 사용합니다.

  1. SSH로 서버에 접속하기

    ssh root@your-server-address
    

    다음 명령은 모두 서버 자체의 이 세션 안에서 실행합니다.

  2. 브라우저 없이 설치 프로그램 실행하기

    curl -fsSL https://hermes-agent.nousresearch.com/install.sh | bash -s -- --skip-browser
    

    스크립트가 필요한 환경을 다운로드하고 hermes 명령을 설치합니다. --skip-browser 플래그는 브라우저 자동화 설치를 건너뜁니다. 그래픽 인터페이스가 없는 서버에서는 공간만 차지하기 때문입니다. 나중에 브라우저가 필요해지면 별도로 설치할 수 있습니다.

  3. 셸을 다시 시작하고 모델 선택하기

    source ~/.bashrc
    hermes setup --portal
    

    첫 번째 줄은 새 PATH를 적용해 hermes 명령을 찾을 수 있게 합니다. 두 번째 줄은 Nous Portal 로그인을 엽니다. 로그인을 확인하면 에이전트에 모델과 서비스가 설정되므로 서비스마다 별도의 키를 준비할 필요가 없습니다.

  4. 설치 확인하기

    hermes doctor
    

    이 명령은 설치된 항목, 누락된 항목, 문제 해결 방법을 보여 줍니다. 초록색 표시가 있으면 모든 것이 준비된 것입니다.

봇과 일정을 추가하기 전에 서버에서 직접 간단한 대화가 제대로 이루어지는지 확인하세요. hermes를 실행하고 검증 가능한 답을 얻을 수 있는 간단한 작업을 지시하면 됩니다. 일반 대화가 작동하기 전에 기능을 더 쌓지 말라고 공식 문서는 명시적으로 권고합니다. 타당한 조언입니다.

Hermes를 24시간 계속 실행하려면 어떻게 하나요?

핵심 내용

먼저 hermes gateway setup으로 게이트웨이를 설정하고 Telegram을 연결하세요. 그런 다음 명령 하나로 게이트웨이를 서비스로 전환합니다. hermes gateway install은 사용자 서비스를 설치하고, sudo hermes gateway install --system은 서버가 부팅될 때 시작되는 시스템 서비스를 설치합니다. 사용자 서비스는 hermes gateway start, stop, status로 관리합니다. VPS 시스템 서비스는 모든 확인과 변경에서 명시적 --system 범위와 필요한 권한을 유지하세요.

게이트웨이는 모든 메신저 연결을 유지하고 세션을 관리하며 예약 작업을 실행하는 단일 백그라운드 Hermes 프로세스입니다. 24시간 운영의 모든 것이 이 프로세스를 중심으로 이루어집니다. 이 프로세스가 저절로 시작되어 계속 실행되도록 하는 것이 목표입니다.

먼저 게이트웨이를 설정하고 메신저를 연결합니다.

hermes gateway setup

설정 마법사가 플랫폼 설정을 안내하고 봇 토큰과 접근 허용 목록을 입력하도록 도와줍니다. Telegram 연결 단계(BotFather로 봇 만들기, ID 확인하기, 토큰 입력하기)는 기본 설치 가이드에 설명되어 있으므로 여기서는 반복하지 않겠습니다.

다음은 사람들이 가장 자주 잊는 함정입니다. hermes gateway를 단순히 실행하면 SSH 세션이 열려 있는 동안에만 프로세스가 작동합니다. 터미널을 닫으면 게이트웨이가 중지됩니다. 계속 실행하려면 시스템이 관리하도록 해야 합니다. 명령은 하나입니다.

hermes gateway install

게이트웨이를 서비스로 설치합니다. Linux에서는 사용자 systemd 서비스로, macOS에서는 launchd를 통해 설치합니다. 시스템이 프로세스를 감시하고 충돌하면 다시 시작합니다.

서버에서는 두 번째 옵션을 더 자주 사용합니다. 즉, 사용자가 로그인하기 전에 시스템 부팅 시 시작되는 시스템 서비스입니다.

sudo hermes gateway install --system

이것이 VPS에 필요한 설정입니다. 서버가 재부팅되면 서비스가 저절로 시작되고 봇도 다시 온라인 상태가 됩니다. 다음의 간단한 명령으로 관리하세요.

hermes gateway start     # 시작
hermes gateway stop      # 중지
hermes gateway status    # 상태 확인

시스템 서비스에는 이 명령에 sudo와 --system 플래그를 추가하세요. 그렇지 않으면 부팅 시 시작되는 서비스가 아니라 사용자 서비스를 대상으로 명령이 실행됩니다.

sudo hermes gateway start --system
sudo hermes gateway stop --system
sudo hermes gateway status --system

linger가 필요한 이유와 사용하지 않을 때 발생하는 문제는 무엇인가요?

핵심 내용

게이트웨이를 사용자 서비스로 설치했다면(--system 없이 설치한 경우), SSH에서 로그아웃하는 즉시 systemd가 서비스를 중지하고 부팅 시 시작하지 않습니다. 다음 한 줄로 해결하세요: sudo loginctl enable-linger username. 그러면 사용자의 로그인과 로그아웃에 관계없이 서비스가 실행됩니다.

가장 흔히 겪는 문제입니다. 서비스를 설치했는데도 밤에 봇이 조용해집니다. 원인은 Linux 사용자 서비스의 작동 방식에 있습니다.

사용자 systemd 서비스는 기본적으로 사용자의 세션에 연결됩니다. SSH로 접속하면 사용자 관리자가 시작되고 서비스가 실행됩니다. 로그아웃하면 시스템은 사용자가 비활성 상태라고 판단해 게이트웨이를 비롯한 해당 사용자의 서비스를 종료합니다. 로그인과 로그아웃을 반복하는 서버에서는 문제가 됩니다. SSH에 접속해 있을 때만 봇이 온라인 상태이기 때문입니다.

linger 모드로 해결할 수 있습니다. 이 모드를 사용하면 사용자가 로그인하지 않은 동안에도 시스템이 사용자 관리자를 계속 실행합니다.

sudo loginctl enable-linger username

이 명령을 실행하면 사용자 서비스가 독립적으로 작동하고, 로그인을 기다리지 않은 채 서버 부팅 시 시작됩니다. linger를 사용하지 않으면 원래 동작으로 돌아갑니다. SSH에서 나가면 게이트웨이가 중지되고 부팅 시에도 시작되지 않습니다. 문서에서도 이를 명시하고 있습니다.

주의

이 사항은 시스템 서비스(sudo hermes gateway install --system으로 설치)에 해당하지 않습니다. 시스템 서비스는 이미 시스템 수준에서 실행되며 부팅 시 시작됩니다. linger는 사용자 서비스에만 필요합니다. 시스템 서비스 또는 linger를 사용하는 사용자 서비스 중 하나를 선택하세요.

자동 재시작을 설정해 Docker에서 서버용 Hermes를 실행하려면 어떻게 하나요?

핵심 내용

Docker를 선호한다면 컨테이너에서 Hermes를 상시 게이트웨이로 실행할 수 있습니다: docker run -d --name hermes --restart unless-stopped -v ~/.hermes:/opt/data -p 8642:8642 nousresearch/hermes-agent gateway run. --restart unless-stopped 플래그가 재부팅 후 컨테이너를 다시 실행하며, 이미지 내부의 게이트웨이 프로세스도 충돌하면 재시작됩니다.

Docker는 서버에서 에이전트를 계속 실행하는 또 다른 방법입니다. 특히 컨테이너 사용에 익숙하거나 에이전트를 주 시스템에서 격리하려는 경우에 적합합니다. docker run ... setup으로 한 번 설정한 다음 컨테이너를 백그라운드에서 시작합니다.

docker run -d \
  --name hermes \
  --restart unless-stopped \
  -v ~/.hermes:/opt/data \
  -p 8642:8642 \
  nousresearch/hermes-agent gateway run

24시간 운영을 담당하는 각 줄의 역할은 다음과 같습니다.

  • -d — 컨테이너가 백그라운드에서 실행되므로 터미널을 계속 열어 둘 필요가 없습니다.
  • --restart unless-stopped — 서버가 재부팅되거나 충돌한 뒤 Docker가 컨테이너를 다시 실행합니다. 수동으로 중지한 경우에만 재시작하지 않습니다.
  • -v ~/.hermes:/opt/data — 설정, 키, 세션, 메모리가 컨테이너 밖의 서버에 저장되어 컨테이너를 다시 만들어도 유지됩니다.

이미지는 또 하나의 안전장치를 제공합니다. 게이트웨이 프로세스는 s6 감독자 아래에서 실행됩니다. 게이트웨이가 충돌하면 컨테이너 자체는 그대로 유지된 채 몇 초 안에 프로세스가 재시작됩니다. 이중 보호 기능입니다. Docker는 외부에서 컨테이너를 실행 상태로 유지하고 s6는 내부 프로세스를 감시합니다.

Docker 방식에서는 한 가지 차이를 기억하세요. 이 설치 환경은 hermes update 명령으로 업데이트되지 않습니다. Docker에서 업데이트하려면 새 이미지로 교체해야 합니다. 최신 이미지를 다운로드하고 컨테이너를 다시 만드세요.

모든 것이 작동하고 재부팅 후에도 유지되는지 어떻게 확인하나요?

핵심 내용

systemctl로 서비스 상태를 확인하고 실시간 로그를 살펴보세요. 그런 다음 서버에서 가장 중요한 테스트를 합니다. 기기를 재부팅한 뒤 봇이 저절로 다시 온라인 상태가 되는지 확인하세요. Hermes의 세션과 응답은 재시작 후에도 유지되며, 완료되지 않은 응답은 복구 후 전달됩니다.

사용자 서비스의 상태와 로그는 다음과 같이 확인합니다.

hermes gateway status
journalctl --user -u hermes-gateway -f

VPS에 권장하는 시스템 서비스는 다음 범위를 사용하세요.

sudo hermes gateway status --system
sudo journalctl -u hermes-gateway -f

첫 명령은 선택한 서비스를 확인하고 둘째는 그 범위 로그를 따릅니다. 단위명은 기본 ~/.hermes 설치에 적용됩니다. 다른 Hermes 홈에는 접미사가 붙을 수 있으므로 status의 정확한 단위명을 쓰세요. 시스템 설치를 시험하며 사용자 단위를 감시하지 마세요. Hermes 로그는 ~/.hermes/logs/에 저장되며 비밀 정보는 자동으로 가려지므로 지원팀에 안전하게 보낼 수 있습니다.

이제 서버를 재부팅하고 에이전트가 저절로 다시 실행되는지 확인하세요. 서버에서 가장 중요한 테스트이며, 사람들이 흔히 잊는 단계이기도 합니다.

sudo reboot

서버에 다시 접근 가능하면 SSH로 접속하세요. 시스템 설치는 sudo hermes gateway status --system과 시스템 journal을, linger를 쓰는 사용자 설치는 hermes gateway status와 사용자 journal을 확인한 뒤 Telegram으로 메시지를 보내세요. 사용자가 개입하지 않아도 답한다면 자동 시작이 올바르게 설정된 것입니다. 이것이 바로 이 설정의 목적입니다.

대화가 사라질까 걱정할 필요는 없습니다. Hermes는 세션을 디스크에 기록하므로 게이트웨이를 재시작해도 유지됩니다. 또한 게이트웨이가 응답을 보내는 순간 충돌하더라도 작업을 다시 실행하는 대신 복구 후 해당 응답을 전달합니다. 24시간 운영하는 봇에서는 중요한 점입니다. 예기치 않은 재시작이 대화를 끊지 않습니다.

서버에서 터미널에 접근하는 에이전트를 어떻게 보호하나요?

핵심 내용

주요 보호 조치는 세 가지입니다. 기본적으로 봇 접근을 차단해 목록에 있는 사람에게만 응답하고, 위험한 명령을 실행하기 전에 에이전트가 확인을 요청하며, 완전한 격리가 필요하면 서버의 Docker 샌드박스에서 에이전트를 실행합니다. 서버에서 확인을 생략하는 모드(YOLO)는 활성화하지 않는 편이 좋습니다.

서버의 에이전트는 사용자의 감독 없이 실행되며 터미널에 접근할 수 있는 프로그램입니다. 먼저 다음 세 설정을 확인하세요.

봇 접근 제한. 기본적으로 게이트웨이는 접근 목록에 있는 사람이나 다이렉트 메시지에서 코드 기반 연결을 완료한 사람에게만 응답합니다. 터미널에 접근하는 봇에는 적절한 동작입니다. 무작위로 봇에게 메시지를 보내는 사람은 아무것도 할 수 없습니다. 목록은 숫자 ID를 사용해 설정합니다. 예를 들어 Telegram에서는 다음과 같습니다.

TELEGRAM_ALLOWED_USERS=123456789,987654321

위험한 명령에 대한 확인. 파괴적인 작업을 하기 전에 에이전트가 허락을 요청합니다. 확인을 비활성화하는 YOLO 모드가 있지만 사용자가 없는 상태로 실행하는 서버에서는 켜지 않는 편이 좋습니다. 확인은 사용자가 모르는 사이에 되돌릴 수 없는 일이 발생하지 않도록 마련된 장치입니다.

완전한 격리를 위한 샌드박스. 에이전트가 서버의 주 시스템을 물리적으로 볼 수 없게 하려면 Docker 컨테이너 안에서 명령을 실행하세요.

hermes config set terminal.backend docker

그러면 에이전트가 터미널에서 수행하는 모든 작업이 격리된 샌드박스 안에서 이루어져 실제 서버에 접근할 수 없습니다. 에이전트가 스스로 행동하도록 자유를 줄 때 유용한 보호 조치입니다.

봇이 응답하지 않거나 게이트웨이가 충돌하면 어떻게 해야 하나요?

핵심 내용

먼저 서비스 상태와 로그를 확인하세요. 원인은 대개 봇 토큰, 접근 목록 또는 모델에 있습니다. 전체 프로세스가 완전히 멈추면 systemd 서비스의 watchdog 타이머가 작동해 프로세스가 정상 동작을 보이지 않을 때 게이트웨이를 재시작합니다.

봇이 응답하지 않으면 다음 순서로 확인하세요. 먼저 설치 범위를 확인하세요. 시스템은 sudo hermes gateway status --system과 시스템 journal, 사용자는 hermes gateway status와 사용자 journal입니다. 게이트웨이는 실행 중인데 메시지가 전달되지 않는다면 거의 항상 플랫폼 설정 문제입니다. 봇 토큰이 잘못되었거나 사용자가 접근 목록에 없습니다. 같은 Hermes 홈에서 hermes gateway setup을 다시 실행하고 시스템은 hermes gateway status --system, 사용자는 hermes gateway status로 확인하세요. 설정 성공이 올바른 게이트웨이 실행의 증거는 아닙니다.

모델이 비어 있거나 이상한 응답을 반환하면 hermes model로 확인하고 공급자와 로그인을 점검하세요. “모든 것이 고장 난” 상태에서 정상 작동 상태로 돌아가기 위한 일반적인 복구 순서는 다음과 같습니다. hermes doctor, hermes model, hermes setup을 실행하고 시스템 설치는 hermes gateway status --system, 사용자 설치는 hermes gateway status로 확인하세요.

전체 프로세스가 실제로 충돌하지 않고 멈추는 드물지만 곤란한 경우도 있습니다. systemd 서비스에는 watchdog 타이머가 있습니다. ~/.hermes/config.yaml에 다음 줄을 추가하고 서비스를 다시 설치하세요.

gateway:
  systemd_watchdog_seconds: 120
# VPS 시스템 서비스: 원래 설치와 같은 Hermes 홈 사용
sudo hermes gateway install --system --force
sudo hermes gateway status --system

사용자 서비스라면 hermes gateway install --force로 그 범위만 다시 만들고 hermes gateway status를 확인하세요. 한 게이트웨이를 고치려고 두 범위를 모두 설치하지 마세요.

이후 게이트웨이는 시스템에 “작동 중”이라고 정기적으로 신호를 보냅니다. 신호가 끊기면 systemd가 프로세스를 자동으로 재시작합니다. 이 기능은 systemd를 사용하는 Linux에서만 작동하며 프로세스 정지에만 적용됩니다. 서버와 메신저 사이의 일반적인 네트워크 중단에는 watchdog 타이머가 영향을 주지 않습니다.

서버에서 Hermes Agent에 관해 자주 묻는 다른 질문은 무엇인가요?

핵심 내용

VPS가 꼭 필요한지, 한 서버에서 봇을 여러 개 운영할 수 있는지, 서버에 그래픽 인터페이스가 필요한지, 에이전트가 서버에서 실행될 때 예약 작업은 어떻게 되는지 등 자주 묻는 질문에 간단히 답합니다.

자주 묻는 질문

VPS를 꼭 구해야 하나요, 아니면 내 컴퓨터를 사용해도 되나요?

24시간 운영하려면 항상 켜져 있는 기기가 필요합니다. 컴퓨터를 절대 끄지 않을 생각이라면 자신의 컴퓨터도 쓸 수 있습니다. VPS가 더 편리합니다. 항상 켜져 있고 사용자가 일하거나 자는지에 영향을 받지 않습니다. 일반 Linux 서버면 됩니다. 문서에서 1차 지원 대상으로 안내하는 환경은 Linux이며, 새 Ubuntu 설치 환경에서 테스트합니다.

한 서버에서 봇을 여러 개 실행할 수 있나요?

예. Hermes에는 프로필이 있으며 프로필마다 자체 서비스가 있습니다. \<profile\> gateway install과 같은 명령은 hermes-gateway-\<profile\>이라는 별도의 서비스를 만들고 각각 독립적으로 작동합니다. 프로필마다 설정, 봇 토큰, 메모리가 따로 있습니다.

서버에 모니터와 그래픽이 필요한가요?

아니요. 서버는 화면 없이 실행되며 터미널에서 SSH로 관리합니다. 이런 서버에서 실행하는 에이전트는 대개 브라우저 자동화가 필요하지 않습니다. 따라서 설치 프로그램을 --skip-browser 플래그와 함께 실행하면 그래픽이 필요한 유일한 대용량 구성 요소를 제거할 수 있습니다.

자리를 비운 동안에도 예약 작업이 실행되나요?

예. 서버로 옮기는 이유가 바로 그것입니다. 같은 게이트웨이가 예약 작업을 실행합니다. 1분마다 일정을 확인해 실행 시각이 된 작업을 실행한 다음 결과를 같은 채팅으로 보냅니다. 게이트웨이가 서비스로 24시간 작동하므로 일정이 사용자 개입 없이 실행됩니다.

업데이트와 서버 재부팅 후에도 봇이 계속 실행되나요?

예. 설정, 세션, 메모리는 ~/.hermes 폴더에 저장되어 사라지지 않습니다. 재부팅 후 시스템 서비스(또는 --restart unless-stopped를 설정한 Docker)가 게이트웨이를 저절로 시작합니다. 완료되지 않은 응답은 재시작 후 전달되며 아무것도 잃지 않습니다. 다만 충돌 시점에 응답 전송이 이미 중간까지 진행됐다면 중복 가능성 알림과 함께 다시 도착할 수 있습니다.

Ailoot에 대해 알아보세요.

자세히 보기

Hermes Agent를 서버에서 24시간 내내 실행하는 방법: 자주 묻는 질문

시스템 서비스로 설치했는데 게이트웨이가 중지로 보이는 이유는 무엇인가요?

범위 없는 확인이 다른 서비스를 볼 수 있습니다. 시스템 설치에는 hermes gateway status --system과 시스템 journal을 쓰고 사용자 설치에만 범위 없는 status와 사용자 journal을 쓰세요. 같은 Hermes 홈을 유지하세요.

VPS 시스템 서비스에도 loginctl linger가 필요한가요?

아닙니다. linger는 로그아웃 후 유지되고 부팅 시 시작해야 하는 사용자 systemd 서비스용입니다. 시스템 서비스는 부팅 시 시작합니다. 범위 하나를 선택하고 재부팅 후 상태와 봇 응답을 다시 확인하세요.

모든 글