Hermes Agent는 Nous Research가 만든 MIT 라이선스 오픈소스 에이전트다. 공식 문서는 hermes-agent.nousresearch.com/docs다. 본체는 세션, 스킬, 도구 루프와 터미널 백엔드다. CLI와 Desktop, 메시징 게이트웨이는 같은 에이전트 루프로 모인다. 게이트웨이는 백그라운드 프로세스 하나가 Telegram, Discord, Slack, WhatsApp, Signal을 받고, 세션을 다루며, 크론을 60초마다 틱한다. 터미널 백엔드는 Local, Docker, SSH 등 명령이 실제로 도는 위치를 고른다.
OpenClaw는 셀프호스팅 멀티채널 게이트웨이다. 공식 허브 docs.openclaw.ai는 채팅 앱을 코딩 에이전트에 연결하는 한 Gateway로 적는다. 한 프로세스가 Discord, Google Chat, iMessage, Matrix, Microsoft Teams, Signal, Slack, Telegram, WhatsApp, Zalo와 WebChat, 모바일 노드를 받는다. 라이선스는 MIT다. 권장 런타임은 Node 26이며, Node 22.22.3 이상도 문서에 적혀 있다. 텔레그램 입구는 BotFather 토큰과 기본 dmPolicy pairing이다.
둘 다 오픈소스이고 모델 중립이며 메신저로 에이전트에 닿는다. 갈리는 지점은 기능 개수가 아니라 코드를 어디에 맡기고, 비밀이 어느 파일에 살며, 실패했을 때 무엇을 끊는지다. Hermes는 실행 루프가 앞에 있고, OpenClaw는 채널 입구가 앞에 있다. 입구와 실행을 한 제품에 몰면 사고면이 그 제품의 로그와 메모리, 채널 백업에 같이 남는다.
원문과 Quickstart는 Hermes에 최소 64,000 토큰 컨텍스트를 요구한다고 적는다. 시스템 프롬프트와 도구 스키마가 기본 공간을 많이 먹기 때문이다. OpenClaw 쪽의 대응 숫자는 컨텍스트 하한이 아니라 텔레그램 pairing과 페어링 코드 1시간 만료다. 두 숫자를 같은 칸에 넣으면 층이 섞인다.
Hermes 본체
Hermes의 본체는 작업 실행이다. 사용자가 CLI에 한 줄을 치거나 Desktop에서 대화를 열거나 게이트웨이가 채널 메시지를 받아도, 그 입력이 가는 곳은 같은 에이전트 루프다. 루프는 모델을 호출하고, 도구를 고르고, 터미널 백엔드에서 명령을 돌리고, 결과를 다시 모델에 넣는다. 채널 이름이 달라도 도구 권한은 한 실행 층을 공유한다. 텔레그램에서 막힌 쓰기가 CLI에서는 열려 있을 수 있고, 그 반대도 있다.
Linux, macOS, WSL2, Android(Termux)에서 CLI를 올리는 공식 경로는 설치 스크립트다. 스크립트가 PATH에 hermes를 넣고, 이어서 hermes setup이 모드를 고른다.
curl -fsSL https://hermes-agent.nousresearch.com/install.sh | bash
source ~/.zshrcWindows 네이티브 PowerShell은 iex (irm https://hermes-agent.nousresearch.com/install.ps1) 형태다. macOS나 Windows에서 Desktop을 쓰면 같은 에이전트 루프가 GUI로 열린다. 설치 후 hermes setup이 내놓는 세 모드는 Quick Setup(Nous Portal), Full Setup, Blank Slate다. Portal은 OAuth로 300+ 모델과 Tool Gateway를 붙인다. Full Setup은 프로바이더와 도구를 직접 고른다. Blank Slate는 프로바이더, File Operations, Terminal만 남기고 웹, 브라우저, 코드 실행, 비전, 메모리, 위임, cron, skills, 플러그인, MCP를 설정 파일에 명시적으로 끈다.
비밀값은 ~/.hermes/.env, 일반 설정은 ~/.hermes/config.yaml로 나뉜다. 모델과 터미널 백엔드, 압축은 yaml 쪽이고, API 키와 OAuth 자격증명은 env와 auth.json 쪽이다. hermes config set terminal.backend docker는 yaml의 백엔드 키만 바꾼다. 키를 yaml에 넣으면 설정과 시크릿이 한 파일에 섞인다.
대화형 게이트웨이 설정은 hermes gateway setup이다. hermes gateway status는 그 프로세스가 살아 있는지를 본다. 게이트웨이가 죽어 있으면 페어링이 되어 있어도 메시지가 쌓이지 않거나 늦게 도착한다. 공식 Quickstart는 Hermes가 평범한 대화를 못 끝내면 기능을 더 얹지 말라고 적는다. 게이트웨이는 본체 다음이다.
| 층 | Hermes가 하는 일 |
|---|---|
| 실행 | 세션, 스킬, 도구 루프, 터미널 백엔드 |
| 입구 | CLI, Desktop, 메시징 게이트웨이 |
| 스케줄 | 게이트웨이 안 크론, 60초 틱 |
| 최소 잠금 | Blank Slate가 파일과 터미널만 남김 |
OpenClaw 본체
OpenClaw의 본체는 채널에서 온 메시지를 에이전트에 넘기고, 응답을 다시 채널로 보내는 게이트웨이다. 코딩 에이전트의 도구 사용, 세션, 메모리, 멀티에이전트 라우팅을 전제로 설계되어 있다. 전제가 있다고 해서 설치 직후 실행 범위가 읽기만인 것은 아니다. 기능 표를 전부 켜면 봇 토큰을 가진 사람과 그룹 멤버가 셸, 파일, 외부 전송에 같이 닿는다.
권장 런타임 Node 26과 Node 22.22.3 이상은 게이트웨이 프로세스를 띄우는 조건이다. 런타임이 맞아도 기본 도구 세트가 읽기만 하지는 않는다. MIT와 셀프호스트는 코드를 직접 돌린다는 위치이지, 오늘 허용의 상한이 아니다.
텔레그램은 BotFather로 봇을 만든 뒤 토큰을 설정에 넣고 게이트웨이를 시작한다. openclaw channels login telegram은 쓰지 않는다. 기본 전송은 롱 폴링이고, 웹훅은 선택이다. Control UI 기본은 127.0.0.1:18789 루프백이다. 그 주소는 그 컴퓨터 안에서만 통한다. 원격 대시보드는 Tailscale serve/funnel 같은 별 경로다.
게이트웨이 기동과 첫 DM 승인은 서버 콘솔에서 돈다.
openclaw gateway
openclaw pairing list telegram
openclaw pairing approve telegram <CODE>openclaw gateway는 채널 플러그인을 받는 프로세스를 띄운다. pairing list는 대기 중인 코드를 보여 준다. pairing approve는 그 발신자에게 DM 접근을 연다. 코드는 문서 기준 1시간 만료다. 승인은 「이 사람이 모든 곳에서 관리자」가 아니다. DM 접근과 그룹 allowlist, owner 부트스트랩은 따로 적혀 있다.
공식 한 줄의 채널 목록은 입구의 폭이다. Discord부터 Zalo까지 같은 Gateway 프로세스에 붙으면, 페어링 정책이 채널마다 달라도 실행 층은 한 에이전트다. 기능 개수로 고르면 채널 수가 많은 쪽이 이긴다. 실행 위치와 시크릿 저장, 실패 때 끊는 조건은 그 표에 나타나지 않는다.
터미널 백엔드
Hermes에서 코드를 맡기는 위치는 터미널 백엔드다. Local이면 호스트에서 명령이 바로 돈다. 실패의 디스크와 네트워크가 그 기계다. Docker로 두면 실패가 컨테이너 안에서 멈추기 쉽다. SSH는 원격 호스트의 셸이 실행 위치가 된다. 백엔드 이름은 편의 옵션이 아니라 사고의 경계다. 같은 스킬과 같은 모델이라도 Local과 Docker는 남는 경로가 다르다.
백엔드를 Docker로 바꾸는 설정은 yaml의 terminal.backend다.
hermes config set terminal.backend dockerDocker를 쓰는 경우에는 egress 프록시가 있다. hermes egress setup과 hermes egress start가 하는 일은 샌드박스가 진짜 API 키를 직접 보지 못하게 만드는 것이다. 불투명한 프록시 토큰만 받고, 실제 키는 로컬 TLS 인터셉트 데몬 뒤에서만 사용된다. 컨테이너가 탈취되거나 잘못된 경로로 데이터를 보내려 해도 키 자체 유출을 줄이는 방향이다. 현재 Docker에만 연결되어 있다. SSH로 바꾸면 egress의 지원 범위가 같이 바뀐다.
Docker가 모든 사고를 삼키지는 않는다. 컨테이너가 마운트한 경로와 전달된 환경 변수가 넓으면, 실패의 경계만 옮겨 갈 뿐이다. docker_forward_env 화이트리스트가 넓으면 시크릿이 컨테이너 안으로 그대로 들어간다.
OpenClaw 쪽은 실행 위치가 게이트웨이 뒤의 에이전트다. 채널 메시지가 입구이고, 게이트웨이 프로세스가 그 메시지를 에이전트에 넘긴다. 입구가 편할수록 실행 범위를 따로 적지 않으면 쓰기와 외부 전송이 같이 열린다. OpenClaw에는 Hermes식 터미널 백엔드 이름이 앞에 있지 않다. 실행 범위를 가리는 것은 페어링이 아니라, 디렉터리와 명령과 외부 전송 세 문장이다.
SSH 백엔드는 Local이 호스트 디스크를 바로 만지는 일을 다른 기계로 옮긴 형태다. 사고의 경계가 집 서버에서 원격 서버로 바뀔 뿐, 채널 입구와 실행 층을 나누는 문제는 그대로다.
메시징 입구
Hermes 메시징 문서는 게이트웨이가 설정된 플랫폼에 연결하고, 세션을 다루고, 크론 작업을 돌리고, 음성 메시지를 전달한다고 적는다. 기본 보안은 allowlist나 DM 페어링에 없는 사용자를 거부한다. 환경 변수 예는 TELEGRAM_ALLOWED_USERS에 숫자 ID를 넣는 형태다. 대안이 DM 페어링이고, hermes pairing approve telegram XKGH5N7P처럼 승인한다. 페어링 코드는 1시간 만료, 속도 제한, 암호학적 난수를 쓴다고 문서가 적는다.
OpenClaw 텔레그램 설정 키는 channels.telegram.enabled, botToken, dmPolicy: pairing이다. 그룹은 requireMention: true가 기본에 가깝다. 환경 변수 폴백은 TELEGRAM_BOT_TOKEN(기본 계정만)이다. named account는 botToken 또는 tokenFile을 쓴다. 토큰 해석 순서는 tokenFile이 botToken보다, 설정이 env보다 앞선다. 기동 후 봇 identity를 최대 24시간 캐시하므로, 토큰을 바꾸거나 지우면 그 캐시도 비운다.
아래 표는 브랜드 우열이 아니라 이번 주 과제에 맞는 층을 가리키기 위한 것이다.
| 필요한 일 | 먼저 보는 쪽 | 이유 |
|---|---|---|
| 깊은 코드와 문서, 검증 루프 | Hermes | 세션, 스킬, 도구 루프와 터미널 백엔드가 실행에 가깝다 |
| 메시징과 승인, 알림 입구 | OpenClaw | 채널과 게이트웨이 이벤트가 입구가 되기 쉽다 |
| 둘을 같이 쓰는 운영 | 입구와 실행을 나눈다 | 한쪽에 모든 권한을 몰지 않는다 |
| 관측·온콜이 없음 | 제품 선택 보류 | 자동화 범위를 먼저 줄인다 |
핵심 포인트: 비교표의 「기능 있음」보다 기본 권한이 읽기인지 쓰기인지가 앞선다. 기본이 쓰기면 데모 과제의 경로도 읽기 전용으로 남는 편이 사고면을 줄인다.
모바일 알림이 필요해서 OpenClaw를 골라도, 실행 권한이 없는 채널만 열리는 구성이 가능하다. 반대로 Hermes로 깊은 작업을 하더라도 외부 알림은 읽기 전용 봇으로 분리할 수 있다. 입구와 실행을 한 제품에 몰면 채널 한 줄이 저장소를 바꾼다.
Hermes 메시징의 슬래시 명령은 원격 입구에서 범위가 크다. /status는 세션 정보, /stop은 하드 스톱, /approve와 /deny는 위험한 명령의 허가와 거절이다. /new 또는 /reset은 대화를 새로 시작한다. 그룹에서 에이전트가 대답할 필요가 없으면 침묵 토큰([SILENT], SILENT, NO_REPLY)이 최종 응답 전체일 때 전송을 억제한다. 실패 턴은 침묵으로 숨기지 않는 편이 관측에 유리하다.
시크릿 파일
시크릿이 채팅 로그와 메모리에 복사되지 않게 하는 차단 규칙이 제품 선택보다 앞선다. env, 토큰, DB URL은 메모리, 스킬, 채널 메시지에 남기지 않는 구성이 사고면을 줄인다. 채널 텍스트는 메신저 백업과 알림 미리보기라는 두 번째 저장소다. 잠금 화면 미리보기에 경로와 키가 남는 일은 제품 기능이 아니라 메시지의 내용에서 생긴다.
Hermes 홈 디렉터리의 역할은 파일마다 다르다.
~/.hermes/
├── config.yaml
├── .env
├── auth.json
└── logs/config.yaml에는 모델, 터미널 백엔드, 압축 같은 비밀이 아닌 설정이 들어간다. .env와 auth.json에는 API 키와 OAuth 자격증명이 들어간다. 회사 키와 개인 키가 한 파일에 섞이면 감사 대응이 어려워지고, Docker로 넘기는 환경 변수 목록까지 헷갈리기 시작한다.
OpenClaw 텔레그램은 TELEGRAM_BOT_TOKEN 또는 설정 파일의 botToken, 그보다 앞서는 tokenFile이다. tokenFile은 일반 파일이어야 하고, 심볼릭 링크는 거절된다고 문서가 적는다. 토큰을 가진 사람과 그룹 멤버가 같은 실행면을 공유하면, 입구의 pairing과 실행 범위가 한 덩어리로 보인다. 실제로는 토큰은 봇의 신원이고, allowFrom은 누가 말하는지를 가르며, 도구 권한은 그 다음이다. 세 값이 한 채팅에 붙어 있으면 유출 한 번에 입구와 실행이 같이 열린다.
채널 메시지에 env 조각이 남는 사고는 제품 버그와 별개다. 메신저 백업과 잠금 화면 미리보기는 게이트웨이 로그가 지워져도 남는다. 파일 위치가 맞아도 승인 메시지에 키를 붙이면 두 번째 저장소가 생긴다.
페어링
페어링은 누가 말할 수 있는지를 가른다. 말한 뒤에 에이전트가 어떤 디렉터리를 읽고 어떤 명령을 실행하는지는 별도 문장이다.
Hermes는 allowlist 또는 DM 페어링에 없는 사용자를 거부한다. 승인 예는 hermes pairing approve telegram XKGH5N7P다. 코드 만료는 문서상 1시간이다.
OpenClaw 텔레그램 기본 dmPolicy는 pairing이다. 봇에 처음 메시지를 보내면 페어링 코드가 나온다. 코드는 8자 대문자이고, 혼동 문자(0O1I)를 빼며, 채널 계정당 대기 요청은 3개로 막힌다. 추가 요청은 하나가 만료되거나 승인될 때까지 무시된다. 봇은 발신자당 대략 한 시간에 한 번 페어링 메시지를 보낸다. 첫 승인에서 아직 command owner가 없으면 commands.ownerAllowFrom을 그 발신자로 부트스트랩한다. 이후 승인은 DM 접근만 주고 owner를 넓히지 않는다. 그룹 권한은 별도 allowlist다. 그룹 발신자 인증은 페어링 저장소를 상속하지 않는다. 문서가 보안 경계로 적은 시점 표기는 2026.2.25다.
그룹에 봇을 넣은 뒤 필요한 값은 자신의 텔레그램 사용자 ID(allowFrom / groupAllowFrom)와 그룹 채팅 ID(channels.telegram.groups 키)다. 슈퍼그룹 ID는 -100으로 시작하는 음수다. 그 값은 groupAllowFrom이 아니라 groups 아래 키로 간다. 텔레그램 봇 기본 Privacy Mode는 그룹 메시지 수신을 제한한다. 모든 그룹 메시지를 보려면 BotFather /setprivacy로 끄거나 봇을 그룹 관리자로 둔다. 토글 뒤에는 그룹에서 봇을 뺐다가 다시 넣어야 적용된다.
dmPolicy: open에 allowFrom: ['*']를 넣으면 봇 사용자 이름을 아는 모든 텔레그램 계정이 명령을 보낸다. allowlist인데 allowFrom이 비면 모든 DM이 거부되고 설정 검증이 거절한다. 예전 @username 항목은 openclaw doctor --fix가 숫자 ID로 바꾸려 시도한다.
페어링 1시간과 쓰기 승인 만료는 다른 시계다. 전자는 DM 입장, 후자는 저장소 변경이다. Hermes 페어링 1시간도 DM 입장 시계다.
키를 양쪽에 주지 않는 이유
두 도구에 같은 프로덕션 키와 같은 저장소 쓰기 권한이 동시에 있으면, 사고 원인이 섞인다. 키가 두 로그에 동시에 나타나면, 어느 게이트웨이가 외부로 나갔는지를 나중에 가리지 못한다. 실험은 실험 키와 읽기 전용 경로로 남는 편이 사후 분석에 유리하다.
기능이 많은 쪽에 프로덕션 키를 먼저 주는 절충은 시크릿 저장을 제품 선호에 종속시킨다. OpenClaw는 승인 요청만 보내는 읽기 전용 봇으로 두고, Hermes는 Docker 백엔드에서 코드를 돌리는 구성이 입구와 실행을 나눈다. 반대로 Hermes 게이트웨이로 알림만 받고 OpenClaw는 켜지 않을 수도 있다. 중요한 것은 제품 두 개를 켜는 일이 아니라, 프로덕션 키가 한 실행 층에만 있게 하는 일이다.
문서 다이어그램은 이상적인 연결을 그린다. 설치 직후의 기본 권한과 같은 그림이 아닐 수 있다. 읽기와 쓰기 기본값, 시크릿 주입 경로가 한 페이지에 남지 않으면, 기능 투어를 해도 운영 준비가 안 된 상태다. 그 페이지가 비어 있는 채로 양쪽을 설치하면, 나중에 사고 원인을 제품 이름 사이에서 가리지 못한다.
OWASP LLM Top 10과 OpenAI Agents 가이드가 출처 목록에 있는 이유는, 시크릿과 도구 권한을 제품 기능 표와 같은 층으로 읽지 말라는 쪽에 가깝다.
Blank Slate와 기본 권한
Blank Slate는 프로바이더와 파일, 터미널만 남기고 나머지를 명시적으로 끄는 경로로 원문에 적혀 있다. 끄는 상태가 설정 파일에 기록되면, 업데이트 뒤에 선택하지 않은 기능이 조용히 다시 켜지는 일이 줄어든다. 회사 저장소를 만질 때 Blank Slate가 빠른 Portal보다 앞서는 이유는 이 기록 방식에 있다.
필요한 것을 나중에 여는 명령은 hermes tools, hermes skills opt-in --sync, hermes setup agent다. hermes tools는 플랫폼별 도구 접근을 따로 둔다. CLI에서 터미널을 허용하더라도 텔레그램에서는 막는 식이다.
OpenClaw의 대응 최소 잠금은 dmPolicy pairing이 미승인 DM을 막는 것이다. 그 잠금은 입구의 최소값이지, 디렉터리 읽기나 명령 실행의 상한이 아니다. 입구를 잠근 뒤에도 승인된 사용자에게 쓰기와 임의 셸이 열려 있으면, 폰 알림 한 줄이 저장소를 바꾼다.
| 층 | Hermes | OpenClaw |
|---|---|---|
| 앞선 관심 | 세션, 스킬, 도구 루프 | 채널 플러그인, 페어링 |
| 실행이 도는 곳 | 터미널 백엔드(Local, Docker, SSH) | 게이트웨이 뒤의 에이전트 |
| 입구 | CLI, Desktop, 메시징 게이트웨이 | 멀티채널 Gateway 한 프로세스 |
| 최소 잠금의 예 | Blank Slate가 파일과 터미널만 남김 | dmPolicy pairing이 미승인 DM을 막음 |
| 잠금이 가리지 않는 것 | 백엔드가 Local이면 호스트 셸 | 승인된 발신자의 실행 범위 |
다이어그램에 샌드박스가 그려져 있어도, 설치 직후 Local 백엔드와 열린 쓰기가 기본이면 그림과 런타임이 다르다. 실패 때 끊는 조건은 그림이 아니라 런타임의 기본 권한을 대상으로 한다.
실패 때 끊는 조건
제품 선택보다 먼저 사람에게 넘길 조건이 한 줄로 남는 편이 운영에 유리하다. 연속 실패, 일일 예산 초과, 프로덕션 경로 쓰기 시도가 예다. 조건이 없으면 알림이 와도 행동이 없다. 온콜이 없으면 밤에 끊을 사람이 없다. 쓰기와 외부 채널을 끊는 순서가 같은 페이지 상단에 있으면, 장애 순간에 제품 비교를 다시 하지 않아도 된다.
메신저 승인이 있어도 관측 알림은 따로 필요하다. 메신저는 편의 채널이다. 실패율, 비용, 인증 실패 알림이 없으면 승인 버튼만으로 운영이 되지 않는다. 채널이 살아 있어도 서버 게이트웨이가 죽어 있으면 승인은 공허하다.
끊는 순서는 쓰기, 외부 채널, 그다음 읽기인 경우가 많다. 읽기까지 끊으면 상태 조회도 사라지므로, 장애 중에 서버 콘솔만 남는다. 그 콘솔에서 같은 작업을 중단할 수 있는지가 채널 연결보다 앞선다. 채널만 살고 실행 층이 죽으면 원격은 장식이다.
로그에 남길 최소 필드는 시각, 실행 주체(사람, 스케줄, 채널), 모델과 provider, 호출한 도구 이름, 허용 범위 요약, 성공과 실패, 중단 사유다. 일곱이 없으면 사후 분석이 「모델이 이상했다」로 끝난다. 주체가 스케줄인데 사람 승인으로 기록되면, 야간 루프와 주간 대화를 나중에 가리지 못한다. 도구 이름 없이 실패만 남으면, 권한 문제와 모델 문제를 같은 칸에 넣게 된다.
읽기 전용 비교
양쪽을 설치한 뒤의 비교는 기능 투어보다 동일한 읽기 전용 과제와 의도적 실패 한 번을 같은 표에 남기는 쪽에 가깝다. 쓰기는 읽기가 안정된 뒤 한쪽만 열린다. 승자 칸이 있으면 데이터가 오기 전에 팀이 결론을 박는다. 「이번 주 과제에 맞는 쪽」과 「보류 이유」만 남는다. 보류 이유가 관측 부재라면 제품이 아니라 운영 준비가 문제다.
| 단계 | 내용 |
|---|---|
| 1 | 같은 읽기 전용 과제(예: 테스트 실패 요약)를 양쪽에서 실행 |
| 2 | 소요 시간, 토큰·비용, 사람이 수정한 비율을 같은 표에 기록 |
| 3 | 잘못된 경로·권한 거부로 알림이 오는지 확인 |
| 4 | 쓰기는 읽기가 안정된 뒤 한 경로만 개방 |
사람이 수정한 비율은 체감 문장보다 교체 근거에 가깝다. 되돌림이 높으면 입력이 부족하거나 범위가 넓은 경우가 많다. 토큰과 비용만 보고 모델을 바꾸면, 보조 작업이 메인을 무는 구조는 그대로 남는다. Hermes 쪽은 그 구조가 보조 슬롯과 압축에 있고, OpenClaw 쪽은 채널 한 줄이 도구 세트를 부르는 쪽에 있다.
의도적 실패는 잘못된 경로와 권한 거부에서 알림이 오는지다. 성공 로그만 보이면 감시가 죽은 줄 모른다. 알림이 채널에만 있고 서버 로그에 최소 필드가 없으면, 실패를 「모델이 이상했다」로 닫는 분석이 다시 나온다.
마이그레이션을 염두에 두면 모델 ID와 프롬프트, 도구 정의를 제품 UI 밖에 둔다. UI에만 있으면 비교가 끝나도 이전이 두려워 도구가 고정된다. 설정 파일과 환경 변수에 모아 둔 구성일수록 교체가 쉽다.
자주 하는 잘못된 절충은 네 줄이다. 기능이 많은 쪽에 프로덕션 키를 먼저 준다. 관측 없이 메신저 승인만 켠다. 문서 다이어그램을 기본 권한으로 착각한다. UI 취향으로 고르고 마이그레이션 비용을 무시한다. 네 줄 모두 승자 칸을 미리 그리는 일과 같다.
비교가 필요한 주가 아니어도 입구와 실행을 나누는 구성은 남는다. 모바일 알림만 필요하면 OpenClaw 채널을 읽기 전용으로 두고 Hermes는 켜지 않을 수 있다. 깊은 코드 루프만 필요하면 Hermes Docker 백엔드만 두고 채널은 닫을 수 있다. 둘을 같이 쓰는 운영의 이유는 한쪽에 모든 권한을 몰지 않기 위해서다.
세션과 도구 루프
Hermes 세션은 한 대화의 컨텍스트와 도구 호출 이력을 묶는다. 사용자 한 줄이 들어오면 메인이 도구를 고르고, 터미널 백엔드가 명령을 돌리고, 결과가 다시 모델에 들어간다. 이 루프가 64K 하한 안에서 돈다. 스킬은 평소에 짧은 요약만 읽히다가 그 작업이 필요할 때 SKILL.md 전체가 로드된다. 서브에이전트는 별도의 대화와 터미널을 띄워 한 세션의 컨텍스트가 터지는 폭을 줄인다.
hermes sessions list는 저장된 세션 목록을 보여 준다. hermes --continue는 마지막 세션을 이어 받는다. 프로필이 바뀌었거나 저장이 안 되면 continue가 세션을 못 찾는다. hermes doctor는 인증, 모델, 설정 경로를 한 번에 본다. 응답이 비었거나 깨지면 hermes model을 다시 도는 쪽이 원인 분리에 가깝다.
OpenClaw 쪽의 대응 루프는 게이트웨이가 채널 이벤트를 받아 에이전트에 넘기는 것이다. 텔레그램 기본 전송은 롱 폴링이다. 게이트웨이 프로세스가 텔레그램 서버에 새 업데이트를 묻고, 메시지가 있으면 에이전트 루프로 넣는다. 웹훅은 공개 URL이 추가로 생긴다. 전송 방식은 지연과 방화벽의 문제이고, pairing의 대체재가 아니다.
Hermes 게이트웨이의 크론은 같은 프로세스 안에서 60초마다 만기 작업을 실행한다. OpenClaw의 스케줄은 게이트웨이 이벤트와 별 경로일 수 있다. 크론이 사람 없이 쓰기를 열면, 온콜이 없는 밤에 끊을 사람이 없다. 그래서 비교 표의 「관측·온콜이 없음」 줄은 제품 결함이 아니라 운영 준비의 칸이다.
모델 ID와 프롬프트, 도구 정의를 제품 UI 밖에 두면 이전이 두렵지 않다. Hermes는 yaml과 env, OpenClaw는 채널 설정 파일과 tokenFile이 그 바깥이다. UI에만 있으면 일주일 실험이 끝나도 도구가 고정된다.
로그 필드가 가리는 층
사후 분석이 「모델이 이상했다」로 닫히는 이유는 필드가 부족해서다. 시각이 없으면 야간 크론과 주간 대화를 가리지 못한다. 실행 주체가 없으면 사람 승인과 스케줄과 채널 한 줄을 같은 칸에 넣게 된다. 모델과 provider가 없으면 폴백이 캐시를 깨서 비용이 오른 것인지, 메인이 실패한 것인지 모른다. 도구 이름이 없으면 권한 거부와 형식 오류가 섞인다. 허용 범위 요약이 없으면 읽기 과제가 쓰기로 번진 경로를 나중에 못 본다. 성공과 실패, 중단 사유가 없으면 알림만 있고 행동이 없는 상태가 반복된다.
Hermes 쪽 로그는 ~/.hermes/logs/에 산다. OpenClaw는 openclaw logs --follow가 채널 이벤트를 따라간다. 그룹 채팅 ID를 얻는 경로 중 하나가 그 follow다. 두 제품의 로그를 한 파일에 섞어 두면, 키가 양쪽에 있을 때와 같은 원인 섞임이 난다.
의도적 실패 한 번은 잘못된 경로와 권한 거부가 알림으로 오는지다. 성공 로그만 보이면 감시가 죽은 줄 모른다. 메신저 승인과 관측 알림은 별도 열이다. 채널에만 알림이 있고 서버 로그에 일곱 필드가 없으면, 어제 승인을 오늘 누르는 사고와 게이트웨이 사망을 같은 증상으로 읽게 된다.
Hermes 설치 스크립트는 curl -fsSL https://hermes-agent.nousresearch.com/install.sh | bash다. Windows는 iex (irm https://hermes-agent.nousresearch.com/install.ps1)다. hermes setup의 Blank Slate는 파일과 터미널만 남기고 웹, 브라우저, 크론, 스킬, MCP를 yaml에 명시적으로 끈다. hermes config set terminal.backend docker와 hermes egress setup, hermes egress start는 실패가 컨테이너와 프록시 뒤에서 멈추게 한다. OpenClaw는 openclaw gateway가 채널 프로세스를 띄우고, openclaw pairing list telegram과 openclaw pairing approve telegram <CODE>가 DM 입구를 연다. tokenFile이 botToken보다, 설정이 TELEGRAM_BOT_TOKEN보다 앞선다.
64,000 토큰 하한은 Hermes 원문과 Quickstart 주장이다. OpenClaw의 1시간 페어링 만료와 Node 26 권장은 다른 층의 숫자다. 컨텍스트와 입구 정책을 한 칸에 넣으면 비교 표가 다시 기능 개수 싸움이 된다.
메뉴 라벨은 버전마다 바뀐다. 설정 직전 양쪽 공식 문서가 화면의 기준이다. Hermes messaging과 OpenClaw Telegram 채널 문서가 입구 키의 정본이다.
Hermes 설치 스크립트 install.sh는 바이너리와 PATH만 넣는다. OpenClaw는 Node 런타임 위에서 openclaw gateway가 프로세스를 띄운다. 둘 다 키가 본체 파일에 있고 채널은 페어링된 입구다. 같은 키를 yaml과 채팅과 양쪽 제품에 복사하면 유출 한 번에 실행 층이 같이 열린다. hermes pairing approve와 openclaw pairing approve는 코드에 적힌 발신자에게 DM을 여는 일이고, 도구 세트를 여는 일이 아니다.
마무리
앞에서 다룬 Hermes와 OpenClaw 층의 핵심만 짧게 정리한다.
- 둘 다 셀프호스트 오픈소스이고 메신저로 에이전트에 닿는다.
- Hermes 본체는 실행 루프와 터미널 백엔드, OpenClaw 본체는 채널 Gateway 한 프로세스다.
- Local, Docker, SSH는 명령이 도는 위치이고, pairing은 누가 말하는지를 가른다.
- 시크릿은 Hermes
~/.hermes/.env와 OpenClawtokenFile/botToken에 산다. - 같은 프로덕션 키가 양쪽에 동시에 있으면 사고 원인이 섞인다.
- 관측과 중지 문장이 없으면 제품 선택이 보류된다.
- 읽기 전용 비교 표의 되돌림 비율과 비용이 교체 근거가 된다.
「어느 쪽이 더 AI인가가 아니라, 코드를 어디에 두고 실패 때 무엇을 끊는지가 선택 기준이다.」 고른 쪽과 보류 이유, 중지 조건이 네 줄로 남으면 한 달 뒤 같은 논쟁이 반복되는 폭이 줄어든다. 기록이 없으면 기능 표가 다시 승자 칸을 만든다.
출처와 링크
- Hermes Agent 문서: https://hermes-agent.nousresearch.com/docs/
- Hermes 메시징 게이트웨이: https://hermes-agent.nousresearch.com/docs/user-guide/messaging/
- OpenClaw 공식 허브: https://docs.openclaw.ai/
- OpenClaw 텔레그램 채널: https://docs.openclaw.ai/channels/telegram
- OWASP Top 10 for LLM Apps: https://owasp.org/www-project-top-10-for-large-language-model-applications/
- OpenAI Agents 가이드: https://platform.openai.com/docs/guides/agents
조사 기준: 2026년 8월. 권한 기본값과 페어링 정책은 설정 직전 공식 문서가 기준이다.