Hermes Agent는 Nous Research가 만든 MIT 라이선스 셀프호스트 에이전트다. 메시징 게이트웨이는 백그라운드 프로세스 하나가 Telegram, Discord, Slack, WhatsApp, Signal 같은 채널을 받고, 세션을 다루며, 스케줄 작업을 돌린다. 공식 메시징 문서는 그 스케줄러가 60초마다 만기 작업을 실행한다고 적는다. 대화형 설정은 hermes gateway setup이고, 프로세스가 떠 있는지는 hermes gateway status로 본다.
OpenClaw는 채팅 앱을 코딩 에이전트에 연결하는 셀프호스트 Gateway다. 공식 허브 docs.openclaw.ai는 Discord, Slack, Telegram, WhatsApp 등을 한 프로세스가 받는다고 적는다. 권장 런타임은 Node 26이고, Node 22.22.3 이상도 문서에 있다. 띄우는 명령은 openclaw gateway다. Control UI 기본은 127.0.0.1:18789 루프백이다. 폰의 봇이 대답하는 것과, 집 서버에서 파일이 바뀌는 것은 같은 신호가 아니다. 게이트웨이 프로세스가 죽어 있으면 페어링이 되어 있어도 새 명령이 에이전트 루프로 들어가지 않는다.
24시간 운영은 그 프로세스를 밤새 켜 두는 일만 가리키지 않는다. 사람이 없는 구간에 파일 쓰기와 외부 전송이 열려 있으면, 남는 것은 청구와 저장소 변경이다. 절전으로 PC가 꺼져도 텔레그램 봇 토큰이 유효하면 폰에는 승인 버튼이 도착한다. 서버가 죽어 있으면 그 버튼은 빈 약속이다. 설치와 페어링은 Hermes Agent 도입, 텔레그램, OpenClaw 작업 범위가 다룬다. 아래는 밤새 켜 둔 뒤의 게이트웨이, 크론, 권한, 한도, 전원이다.
핵심 포인트: 24시간은 항상 최대 권한이 아니다. 사람이 응답할 수 없을 때 쓰기가 설정에서 닫히는지가 운영 정의다. 문서에만 있고 권한 기본값이 종일 쓰기면 강제되지 않는다.
Hermes 메시징 게이트웨이
Hermes 게이트웨이는 채널 연결과 세션과 크론이 한 프로세스 안에 있다. hermes gateway setup이 플랫폼과 토큰, allowlist를 대화형으로 받고, hermes gateway status가 그 프로세스가 떠 있는지를 본다. CLI에서 터미널을 허용하더라도 텔레그램 쪽 도구는 hermes tools로 따로 좁힐 수 있다. 채널에 봇이 들어가면 그 채널의 사람이 에이전트를 쓰게 되므로, 기본값은 allowlist나 DM 페어링에 없는 사용자를 거부한다. 환경 변수 예는 TELEGRAM_ALLOWED_USERS에 숫자 ID를 넣는 형태다. 승인 예는 hermes pairing approve telegram XKGH5N7P다. 코드 만료는 문서상 1시간이다.
게이트웨이를 끄면 채널만 남는 것이 아니다. 같은 프로세스 안의 크론도 같이 멈춘다. 봇 프로세스만 살리고 스케줄을 다른 머신에 두는 구성과 운영이 다르다. Hermes는 크론이 게이트웨이 안에 있다. 공식 Quickstart는 Hermes가 평범한 대화를 못 끝내면 기능을 더 얹지 말라고 적는다. 24시간 가동은 그 대화와 상태 검사가 안정된 다음이다.
슬래시 명령 /status는 세션 정보를 돌려준다. /approve와 /deny는 위험한 명령의 허가와 거절이다. /stop은 하드 스톱이다. /new와 /reset은 대화를 새로 시작한다. 그룹에서 에이전트가 대답할 필요가 없으면 침묵 토큰 [SILENT], SILENT, NO_REPLY가 최종 응답 전체일 때 전송을 억제한다. 실패 턴을 침묵으로 숨기면 관측이 죽는다. 밤새 켜 둔 게이트웨이에서 실패가 침묵이면, 아침에 남는 것은 청구와 바뀐 파일뿐이다.
비밀값은 ~/.hermes/.env, 일반 설정은 ~/.hermes/config.yaml로 나뉜다. 재부팅 뒤 이 파일이 마운트되지 않으면 프로세스는 떠 있고 인증은 빈다. 키를 yaml에 넣으면 설정과 시크릿이 한 파일에 섞인다.
크론 60초 틱
공식 메시징 문서는 스케줄러가 60초마다 만기 작업을 실행한다고 적는다. 매일 아침 어제 배포 로그 요약을 텔레그램으로 보내는 일이 그 틱에 걸린다. 자연어로 스케줄을 걸 수 있고, 사람 없이 도는 실행이 여기서 나온다. 해상도가 1분이므로 「지금 당장」보다 「다음 틱」에 가깝다. 「매일 아침 8시」는 8시 정각이 아니라 그 시각 이후 첫 만기 틱이다.
틱이 돈다는 것은 봇이 살아 있다는 뜻과 다르다. 게이트웨이를 끄면 요약도 멈춘다. 외부 클라우드 크론만 살리고 집 서버를 끄면, 알림은 오는데 읽을 로그 파일이 없는 상태가 된다. 사람 없이 도는 작업은 사고가 나도 늦게 발견되므로, 자는 동안 쓰기 금지 시간대를 크론보다 먼저 정한다.
크론이 게이트웨이 안에 있다는 말은, 채널 봇만 살리고 systemd timer를 다른 머신에 두는 구성과 실패 면이 다르다는 뜻이다. 게이트웨이가 죽으면 채널과 스케줄이 같이 멈춘다. 반대로 게이트웨이가 살아 있고 쓰기가 열려 있으면, 60초 틱마다 만기 작업이 저장소를 건드릴 수 있다. hermes tools로 텔레그램 경로의 터미널을 막아 두면, 크론이 채널로 요약을 보내도 셸은 CLI에만 남는다.
실패한 크론이 알림 없이 재시도하면 비용과 변경이 같이 쌓인다. 실패율과 예산 알림이 크론보다 앞선다. 야간 크론의 산출물은 요약과 실패 묶음이 맞다. 요약이 틀렸다고 파일을 고치게 시키는 순간, 사람 없는 구간의 쓰기가 열린다. 첫 작업이 읽기인 이유는 Hermes Agent 도입이 다룬다.
OpenClaw Gateway
OpenClaw도 한 Gateway 프로세스가 채널 플러그인과 WebChat, 모바일 노드를 받는다. openclaw gateway로 띄운다. openclaw channels login telegram은 쓰지 않는다. Control UI 기본은 127.0.0.1:18789 루프백이다. 그 주소는 그 컴퓨터 안에서만 통한다. 원격 대시보드는 Tailscale serve 또는 funnel 같은 별 경로다. Mini App /dashboard는 HTTPS 공개 URL과 숫자 사용자 ID owner 검사가 필요하고, 그룹이 아니라 DM에서만 버튼이 나온다.
Gateway가 내려가면 페어링 코드가 유효해도 새 DM이 에이전트 루프로 들어가지 않는다. 텔레그램 기본 dmPolicy는 pairing이다. 입구를 잠근 것과, 승인된 사용자에게 셸과 쓰기가 열려 있는 것은 다른 축이다. 기능 표를 전부 켜면 봇 토큰을 가진 사람과 그룹 멤버가 셸, 파일, 외부 전송에 같이 닿는다.
Discord 플러그인과 Telegram 플러그인이 같은 프로세스 안에 있으면, 한 쪽 채널의 쓰기 권한이 다른 쪽 입구로 새지 않게 채널별 정책이 필요하다. 정책이 없어도 실행 층은 하나다. WebChat은 브라우저 입구이고, 모바일 노드는 폰 입구다. 둘 다 같은 Gateway PID 뒤에 붙는다. PID가 죽으면 모든 입구가 같이 죽는다.
openclaw doctor는 설정 검증이다. allowlist인데 allowFrom이 비면 검증이 거절한다. Docker로 게이트웨이를 돌리는 구성에서 Mini App의 Serve/Funnel은 루프백 옆의 tailscaled이 필요하다. 브리지 네트워크에 포트만 열면 그 조건이 안 맞는다. 문서가 적는 패턴은 network_mode: host와 호스트 tailscaled 소켓(/var/run/tailscale) 마운트다.
서버 프로세스와 메신저 봇
서버 생존은 집 컴퓨터에서 게이트웨이와 에이전트와 터미널이 실제로 도는 상태다. 채널 생존은 봇 토큰이 유효하고 클라우드 쪽 Bot API가 응답하는 상태다. 둘은 동시에 죽을 수도 있고, 하나만 남을 수도 있다.
텔레그램 봇이 대답하면 폰에는 메시지가 도착한다. 집 서버가 절전이면 그 메시지의 승인 버튼은 파일을 바꾸지 못한다. 반대로 서버만 살아 있고 알림이 없으면, 쓰기가 열린 채 청구가 이어져도 밤에 아는 사람이 없다. 디스크가 가득 차면 에이전트는 대답하고 패치는 기록되지 않는다. 디스크 경고와 프로세스 생존을 같은 알림 채널에 두면 그 상태가 같은 화면에 보인다.
| 축 | 살아 있을 때 | 죽어 있을 때 |
|---|---|---|
| 서버 게이트웨이 | 파일과 명령이 실제로 돈다 | 채널 승인이 빈 약속이 된다 |
| 메신저 채널 | 알림과 승인 UI가 도착한다 | 서버만 살아 청구를 모른다 |
| 디스크 여유 | 로그와 패치가 기록된다 | 봇은 답하고 작업은 실패한다 |
Tailscale이 붙어 있어 100.x 주소로 SSH가 열려도, 게이트웨이 PID가 없으면 메신저 쪽 명령은 에이전트에 닿지 않는다. VPN은 네트워크 계층만 가깝게 만든다. 게이트웨이 생존 검사는 hermes gateway status와 OpenClaw 쪽 프로세스 확인이다. 둘을 SSH ping과 같은 칸에 두면, 네트워크만 살아 원격이 되는 척을 한다.
채널 텍스트는 두 번째 저장소다. 메신저 백업과 알림 미리보기에 승인 메시지가 남는다. API 키, env 조각, 고객 로그가 그 메시지에 있으면, 게이트웨이 로그와 별개의 복사본이 생긴다. 상태 질문의 답 칸을 PID, 마지막 성공 시각, 디스크 여유, 오늘 비용으로 제한하면 파일 원문이 채팅에 안 붙는다.
무인 구간이 가리키는 시간
무인 구간은 시계 숫자가 아니라, 사람이 저장소 변경을 감독할 수 없는 시간이다. 09-18만 쓰기를 허용하는 구성과, 주말 전체를 읽기 전용으로 두는 구성은 같은 원리다. 야간 기본이 읽기이면 스케줄 요약과 실패 알림은 남고 패치는 업무 시간으로 미뤄진다.
주말 크론이 요약만 보내지 않고 쓰기를 시도하면, 한도가 없어도 저장소가 바뀐다. 읽기 기본이 그 시도를 막는다. 데모에서 잘 된 도구 세트를 밤새 그대로 두면, 사람 옆에서 되돌리던 권한이 온콜 없이 남는다. 데모와 무인 구간의 권한은 같은 값이 아니다.
무인 구간의 시계는 팀마다 다르다. 어떤 팀은 점심시간에도 쓰기를 닫고, 어떤 팀은 평일 밤만 닫는다. 중요한 것은 숫자가 아니라 그 구간에 패치가 머지되지 않는가다. 시계만 적고 권한 기본값이 종일 쓰기면, 신규 멤버가 같은 규칙을 설정에서 다시 만들지 못한다.
절전 모드의 폰은 알림을 뭉친다. 업무 시간 밖 continue를 막는 규칙이 서버 쓰기 권한과 같은 방향을 보지 않으면, 폰만 잠기고 서버 쓰기는 열린 상태가 된다. 승인 요청에 만료 시각이 없으면 어제 알림을 오늘 눌러 쓰는 사고가 난다. 만료된 승인은 서버에서 거절되게 두고, 메신저에도 만료 안내가 남는 구성이 재현 가능한 거절이다.
쓰기 권한과 허용 세 문장
쓰기는 업무 시간과 사람 승인 뒤에만 열리는 구성이 사고면을 줄인다. 문서에 「야간 쓰기 금지」를 적어 두고 권한 기본값이 종일 쓰기면, 문장은 장식이다. 스케줄, 권한, 키 한도 중 어디에 야간 규칙이 있는지가 인수인계다.
허용 범위가 비어 있으면 무인 쓰기가 기본값이 된다. 오늘 읽을 경로, 실행 가능한 명령, 외부로 나갈 내용이 세 문장으로 없으면 도구 세트가 그대로 밤새 남는다. OpenClaw 쪽 세 문장 틀은 작업 범위 글에 있다. Hermes 쪽은 플랫폼별 hermes tools와 터미널 백엔드가 그 칸을 나눈다.
범위 문장 예시는 아래와 같다. 오늘 이 에이전트는 스테이징 로그 경로를 읽고, 테스트 러너만 실행하며, 텔레그램으로는 승인 요청만 보낸다. 금지 목록에는 삭제, 결제, 프로덕션 배포, PII 발송이 들어간다.
| 전제 | 비어 있을 때 |
|---|---|
| 전원·절전 | 채널만 살아 승인이 공허하다 |
| 변경 허용 범위 | 무인 쓰기가 기본값이 된다 |
| 장애 시 순서 | 알림만 있고 행동이 없다 |
읽기 작업으로 시작했는데 쓰기로 번지는 경로는 「요약이 틀려서 파일을 고치게 시킴」이다. 요약이 틀리면 입력을 보강하거나 사람이 고친다. 틀렸다고 쓰기 권한을 주는 순간 범위 문장은 의미가 없다. 권한으로 품질을 사지 않는 이유가 이 경로다.
Blank Slate는 프로바이더와 File Operations, Terminal만 남기고 웹, 브라우저, 코드 실행, 비전, 메모리, 위임, cron, skills, 플러그인, MCP를 설정 파일에 명시적으로 끈다. 끄는 도구가 yaml에 기록되므로, 업데이트 뒤에 선택하지 않은 기능이 다시 켜지는 일이 줄어든다. 24시간 가동 전에 cron을 연 상태인지를 그 파일에서 본다.
hermes tools와 채널별 잠금
CLI의 터미널 허용과 텔레그램의 차단이 공존하는 구성이 무인 구간에 맞다. hermes tools가 그 분리를 한다. 게이트웨이가 채널을 받는 것과, 그 채널에서 셸이 도는 것은 다른 스위치다. 둘을 한 번에 켜면 폰 한 줄이 호스트 명령을 부른다.
터미널 백엔드가 Local이면 실패의 디스크가 그 기계다. Docker로 두면 실패가 컨테이너 안에서 멈추기 쉽다. hermes config set terminal.backend docker는 yaml의 백엔드 키만 바꾼다. hermes egress setup과 hermes egress start는 샌드박스가 진짜 API 키를 직접 보지 못하게 프록시 데몬을 구성하고 띄운다. 현재 Docker에만 연결되어 있다. 백엔드를 SSH로 바꾸면 지원 범위를 같이 본다.
docker_forward_env 화이트리스트가 넓으면 시크릿이 컨테이너 안으로 그대로 들어간다. 마운트한 경로가 넓으면 실패의 경계만 옮겨 갈 뿐이다. 무인 구간에서 Docker를 켜 두고 마운트가 홈 디렉터리 전체면, 컨테이너 격리는 이름만 남는다.
서브에이전트도 같은 시크릿 파일과 같은 터미널 백엔드를 쓸 수 있다. 대화가 나뉘어도 키가 나뉘는 것은 아니다. 위임 도구는 Blank Slate에서 초기에 꺼진다. 밤새 위임이 열려 있으면 긴 작업의 컨텍스트는 나뉘어도 사고 경계는 나뉘지 않는다.
hard limit과 80% 경고
모델이 알아서 멈출 것이라는 기대는 한도가 아니다. 일일 hard limit과 80% 경고가 한 세트다. 80%에서 경고가 오고 100%에서 쓰기와 외부 채널이 닫히지 않으면 잠든 사이 청구가 이어진다. 알림만 있고 hard limit이 없는 구성이 그 경우다.
작업별 토큰 상한, 비용 상한, 반복 횟수 상한이 있으면 루프가 한도를 먼저 친다. Anthropic OAuth는 Claude Max 플랜과 별도 구매한 extra usage credits 조건이 문서에 있다. 실험 키와 운영 키를 나누고 콘솔 상한을 먼저 두는 구성이 야간 크론과 같이 간다. 로컬 yaml에만 한도를 적고 프로바이더 콘솔은 열어 두면, 에이전트가 다른 경로로 같은 키를 쓸 때 로컬 숫자만 지킨다.
한도가 발동한 뒤 누가 열쇠를 다시 여는지도 운영 문서에 있다. 한도만 있고 해제 절차가 없으면 업무 시간에 대기열이 다시 쌓인다. 공식 화면의 버튼 이름은 제품마다 다르고, 의미는 경고와 차단이 같은 세트인지다. 비용 한도의 숫자 자체는 팀 예산이다. 공식 문서가 80% 경고와 100% 차단의 UI 이름을 고정하지는 않는다.
한도 발동이 잦으면 범위가 넓거나 루프가 있다. 되돌림 비율이 높으면 통합을 더 사지 않는 편이 범위 유지에 가깝다. 입력 패킷(로그, 재현 단계, 관련 파일)이 부족한 경우가 많다.
알림이 가리는 것과 가리지 않는 것
채널 알림은 실패와 예산, 쓰기 시도만 남기는 편이 장애를 놓치지 않는다. 성공 스팸이 많으면 진짜 장애가 묻힌다. 의도적 실패 한 번에 알림이 오지 않으면, 감시가 죽은 줄 모른다. 주 1회 재시작 뒤에도 그 실패 알림이 다시 오는지를 본다.
성공 로그만 보이면 감시가 죽은 줄 모른다. 최소 관측은 실패율, 지연, 비용, 인증 실패다. /status의 답에 파일 원문이 붙으면 승인 채널이 로그의 두 번째 저장소가 된다. 허용 답 칸은 PID, 마지막 성공 시각, 디스크 여유, 오늘 비용이다. 그 밖의 내용은 서버 콘솔 링크나 티켓 번호로 대체된다.
봇이 응답하는 명령 집합을 화이트리스트로 적어 두면, 문서에 없는 명령이 동작할 때 권한 drift를 가린다. 주 1회 명령 목록과 실제 핸들러를 대조하는 점검이 drift를 늦게 발견하지 않게 한다.
알림 채널과 게이트웨이 생존 검사가 같은 목록에 없으면, 채널만 살아 원격이 되는 척을 한다. 온콜 문장 한 줄은 누가 쓰기와 채널을 끊는지다. 그 줄이 없으면 장애 순서 표는 장식이다.
전원과 절전
노트북 덮개를 닫거나 Windows 절전에 들어가면 게이트웨이가 멈춘다. 어댑터만 꽂고 덮개를 닫는 구성이 흔히 그렇게 된다. 미니PC를 켜 두더라도 OS 「절전」이 일정 시간 뒤 디스크를 내리면 크론 틱이 빈다. 서버 OS의 절전 예외와 메신저 앱의 절전은 같은 스위치가 아니다.
집 서버에는 UPS가 전원 전제에 들어간다. 정전 후 복구에서 자주 빠지는 것은 시크릿 마운트와 스케줄 등록이다. 프로세스가 떠 있어도 크론 목록이 비어 있으면 24시간 운영이 아니다. 하이브리드 절전은 메모리만 살리고 디스크를 내리는 경우가 있어, PID는 보이는데 파일이 안 열리는 상태가 난다.
Windows 「덮개를 닫을 때」가 절전이면, 외출용 노트북을 집 서버로 쓰는 구성이 밤에 게이트웨이를 죽인다. 미니PC나 NAS에 게이트웨이를 두고 노트북은 페어링만 하는 쪽이 전원 축이 짧다. 절전 예외를 앱 단위로만 켜 두고 OS 절전은 그대로 두면, 앱만 살아 있고 디스크는 내려간 상태가 된다.
Linux에서 systemd sleep inhibitor를 켜 두지 않으면, 뚜껑을 닫지 않아도 idle 절전이 게이트웨이를 내린다. systemctl status에 게이트웨이 유닛이 active여도, 디스크가 suspend면 크론이 만기를 못 읽는다. 유닛의 Restart=on-failure는 크래시 뒤에만 다시 올리고, 절전으로 멈춘 프로세스는 실패로 안 본다. 절전 예외와 서비스 재시작이 같은 페이지에 있어야 하는 이유다. macOS App Nap과 디스플레이 잠금은 터미널 세션을 죽일 수 있어, launchd plist 또는 별도 미니PC가 노트북보다 맞다.
디스크와 시크릿 마운트
에이전트만 살리고 디스크가 가득 찬 상태가 흔하다. 로그와 패치와 모델 캐시가 같은 볼륨을 채운다. 디스크 경고가 프로세스 생존과 다른 채널이면, 봇은 답하는데 작업은 실패하는 상태를 늦게 본다.
OpenClaw 텔레그램은 tokenFile이 botToken보다 앞선다. tokenFile은 일반 파일이어야 하고 심볼릭 링크는 거절된다. 기동 후 봇 identity를 최대 24시간 캐시하므로, 토큰을 바꾸면 그 캐시도 비운다. 재부팅 뒤 토큰 파일이 안 붙으면 getMe returned 401이 폴링 시작 전에 난다. 웹훅 정리 실패로 보이지 않는다.
로그 로테이션이 없으면 24시간 가동이 디스크를 먼저 채운다. 모델 캐시와 세션 파일이 같은 파티션이면, 세션 재개와 패치 기록이 같이 멈춘다. 볼륨을 나누는 구성이 운영 문서에 있으면, 재부팅 뒤 어느 마운트가 비었는지를 같은 점검에서 본다.
재부팅 뒤 스케줄
주 1회 재시작 뒤의 항목은 시크릿이 살아나는지, 볼륨이 붙는지, 스케줄이 도는지, 알림이 다시 오는지다. 의도적 실패 알림이 다시 오는지를 보면 감시가 죽은 줄 모른다. 「프로세스가 떠 있음」만으로는 부족하다.
| 점검 | 설정에 있을 때 | 문서에만 있을 때 |
|---|---|---|
| 야간 읽기 기본 | 권한 기본값 | 밤에 쓰기가 열린다 |
| 일일 한도 100% | 키·과금 한도 | 알림만 오고 청구는 계속 |
| 재부팅 후 스케줄 | 크론 목록 | 프로세스는 떠 있고 작업은 없음 |
복구 순서는 제품마다 명령이 다르다. Hermes 쪽이 권하는 순서는 hermes doctor, hermes model, hermes setup, hermes sessions list, hermes --continue, hermes gateway status다. doctor는 인증과 모델과 설정 경로를 본다. 게이트웨이 생존은 gateway status다. 둘이 한 화면에 섞이면 모델 오류를 채널 오류로 오인한다.
OpenClaw는 openclaw doctor가 설정 검증이다. 게이트웨이 PID와 Control UI 루프백이 살아 있는지가 재부팅 뒤의 첫 화면이다. Mini App URL이 Tailscale serve에 묶여 있으면, 재부팅 뒤 tailscaled이 안 떠도 봇은 대답하고 대시보드는 빈다.
systemd나 Windows 서비스로 게이트웨이를 올리는 구성은, 로그인 세션이 없어도 프로세스가 살아 있게 하려는 쪽이다. 로그인에만 묶인 터미널에서 openclaw gateway를 띄우면, RDP를 끊는 순간 24시간 가동이 끝난다. 서비스 유닛의 Restart=와 절전 예외가 같은 페이지에 없으면, 크래시 뒤에만 재시작하고 절전 뒤에는 빈다.
페어링 1시간과 쓰기 승인 만료
Hermes와 OpenClaw 텔레그램 모두 페어링 코드 만료는 문서상 1시간이다. OpenClaw 코드는 8자 대문자이고, 혼동 문자(0O1I)를 빼며, 채널 계정당 대기 요청은 3개로 막힌다. 그 1시간은 DM 입장 시계다. 저장소 쓰기 승인의 만료는 그와 다른 시계다.
잠든 사이에 페어링 요청이 오면, 아침에 코드가 만료되어 있다. 만료된 코드를 승인하려고 서버 콘솔을 두드리는 시간과, 만료된 쓰기 승인을 폰에서 누르는 사고는 증상이 다르다. 전자는 입구가 닫힌 것이고, 후자는 입구가 열린 채 변경만 거절되어야 한다. 쓰기 승인이 만료돼도 서버가 거절하지 않으면 어제 알림이 오늘 패치가 된다.
페어링이 유효해도 쓰기 승인이 만료된 상태와, 쓰기 승인이 유효해도 게이트웨이가 죽은 상태는 폰에서 비슷해 보일 수 있다. 로그 최소 필드에 시각과 실행 주체, 중단 사유가 있으면 두 시계를 가린다. 승인 메시지 칸은 저장소 이름, 변경 요약 한 줄, 위험도(읽기/쓰기), 만료 시각이다. 긴 로그를 붙이면 미리보기와 백업에 남는다.
기동과 승인 예는 서버 콘솔에서 돈다.
openclaw gateway
openclaw pairing list telegram
openclaw pairing approve telegram <CODE>pairing list는 대기 중인 코드를 보여 준다. pairing approve는 그 발신자에게 DM 접근을 연다. 첫 승인에서 아직 command owner가 없으면 commands.ownerAllowFrom을 그 발신자로 부트스트랩한다. 이후 승인은 DM 접근만 주고 owner를 넓히지 않는다. 그룹 권한은 별도 allowlist다. pairing 승인은 「이 사람이 모든 곳에서 관리자」가 아니다.
Hermes 쪽 승인은 hermes pairing approve telegram XKGH5N7P 형태다. XKGH5N7P는 문서 예시 코드다. 실제 코드는 그때마다 난수로 나온다. 채팅에 코드만 남기고 서버 콘솔에서 승인하는 흐름이, 폰에 토큰 파일을 두지 않는 이유와 같다.
장애 때 끊는 순서
장애가 보이면 쓰기 권한과 외부 채널을 먼저 끊는다. 그다음 키 한도와 최근 비용 급증을 보고, 마지막 변경(모델, 스킬, 권한)을 타임라인에 남긴다. 재개는 읽기 전용부터다. 원인 없이 쓰기를 다시 열면 같은 루프가 한도만 다시 채운다.
| 순서 | 행동 |
|---|---|
| 1 | 쓰기 권한과 외부 채널을 끊는다 |
| 2 | 키 한도와 최근 비용 급증을 본다 |
| 3 | 마지막 변경(모델, 스킬, 권한)을 타임라인에 남긴다 |
| 4 | 읽기 전용으로만 재개할지 결정한다 |
OWASP Top 10 for LLM Apps는 과도한 에이전트 권한과 공급망, 민감 정보 노출을 같은 목록에 둔다. 24시간 쓰기는 그 권한 축을 밤새 열어 두는 일과 같다. 제품 이름이 Hermes인지 OpenClaw인지는 그다음이다.
채널에 붙이기 전에 서버 콘솔에서 같은 작업을 중단할 수 있는지가 앞선다. Hermes /stop은 하드 스톱이다. 에이전트가 엉뚱한 길로 가고 있으면 새 메시지를 넣는 쪽이 현재 턴을 리다이렉트한다. Ctrl+C도 된다. 콘솔 중단 경로가 메신저 /stop만 있고 서버 권한이 열려 있으면, 폰이 꺼진 밤에 중단이 없다.
주간 리뷰 지표
주간 리뷰에서는 에이전트가 만든 변경 중 사람이 되돌린 비율과, 한도가 발동한 횟수를 같이 본다. 되돌림이 높으면 권한이 아니라 입력과 검증이 부족한 경우가 많다. 같은 과제를 다시 실행했을 때 결과 변동, 도구 호출 형식 오류 횟수, 예산 대비 유용한 완료 작업 수가 네 번째 칸이다. 메뉴 라벨은 버전마다 바뀐다. 네 숫자는 통합 이름보다 오래간다.
결과 변동이 크면 같은 읽기 과제를 두 번 돌리는 비교가 먼저다. 변동의 원인이 모델인지, 도구 스키마인지, 입력 패킷인지는 쓰기 개방 전에 갈린다. 한도 발동이 잦은데 되돌림이 낮으면, 루프가 비용을 태우고 산출은 작은 상태다. 그 반대면 권한이 넓고 검수가 늦은 상태다.
오늘 확인하면 충분한 상태는 범위 문장이 팀 채널에 있고, 실험 키에 hard limit이 걸려 있으며, 의도적 실패 알림이 한 번이라도 왔고, 금지 목록에 삭제와 결제가 명시된 경우다. 네 조건은 기능 표의 체크와 다르다. 기능 표는 가능한 일을 나열하고, 네 조건은 오늘 허용이 운영 가능한지를 가른다.
팀 채널에 구성 한 줄, 중단 방법, 키 위치, 오늘 허용 범위만 고정해도 인수인계가 된다. 스크린샷보다 목적을 적은 문장이 오래간다. 이득과 중지 조건과 담당자가 한 문장에 있으면 승인 문장이 된다. 이득만 있으면 제안이 아니라 희망이다. 일일 예산 초과 2회 또는 승인 없는 프로덕션 변경 1회가 실험 키 회수 조건인 문장이 그 예다.
온콜
온콜이 없는 구성에서 24시간 쓰기를 열면, 알림이 와도 밤에 끊을 사람이 없다. 업무 시간 자동화만으로도 대기열은 줄어든다. 무인 구간이 필요해지는 시점이 온콜과 한도를 만들 타이밍이다.
온콜이 있어도 쓰기와 채널을 끊는 권한이 그 사람에게 없으면, 알림만 받고 설정은 못 고친다. 한도 해제 권한과 장애 시 끊는 권한이 같은 사람일 필요는 없다. 끊는 쪽이 더 넓게 배포되고, 여는 쪽이 더 좁다. 여는 권한이 온콜 전원에 있으면 밤에 한도를 풀어 루프를 다시 돌리게 된다.
Gartner는 2027년까지 에이전틱 AI 프로젝트의 40%가 취소될 수 있다고 2025년 6월에 발표했다. 이유는 기술 한계보다 비용, 불명확한 가치, 미흡한 리스크 통제다. 주 3회 이상 반복되고, 결과가 맞았는지 테스트나 로그로 검증되며, 틀렸을 때 5분 안에 롤백되면 후보가 된다. 하나라도 없으면 지금은 후보가 아니다. 24시간 쓰기는 그 세 조건이 있는 팀의 다음 단계다.
마무리
앞에서 다룬 24시간 에이전트 운영의 핵심만 짧게 정리한다.
- 목표는 항상 켜 두기가 아니라, 무인 구간에 쓰기가 닫히는가다.
- Hermes 크론은 게이트웨이 안에서 60초마다 틱한다. OpenClaw도 Gateway가 전제다.
- 서버 생존과 채널 생존은 다른 축이다. Tailscale만 살아 있으면 원격이 되는 척을 한다.
- 알림과 hard limit은 같이 둔다. 알림만으로는 청구가 멈추지 않는다.
- 재부팅 뒤 시크릿 마운트와 크론 목록이 비면 프로세스는 떠 있어도 작업은 없다.
- 페어링 1시간과 쓰기 승인 만료는 다른 시계다.
- 온콜이 없으면 24시간 쓰기는 밤에 끊을 사람이 없다.
「사람이 없을 때 쓰기가 닫히지 않으면 24시간 운영이 아니다.」 규칙은 문서가 아니라 권한 기본값과 키 한도 경로에 있어야 한다.
출처와 링크
조사 기준: 2026년 8월. 한도와 크론 간격의 화면 라벨은 설정 직전 공식 문서가 기준이다.
- Hermes Agent 문서: https://hermes-agent.nousresearch.com/docs/
- Hermes 메시징(크론 틱): https://hermes-agent.nousresearch.com/docs/user-guide/messaging/
- OpenClaw 공식 허브: https://docs.openclaw.ai/
- OWASP Top 10 for LLM Apps: https://owasp.org/www-project-top-10-for-large-language-model-applications/