봇을 안 죽게 만드는 두 갈래 — OpenClaw는 프로세스 하나로, Hermes는 감독관을 세워

개인 AI 어시스턴트 OpenClaw를 다룰 때, 그 봇은 게이트웨이 프로세스 하나가 채널·브라우저·미디어를 전부 끌어안고 도는 구조였다. "봇이 24시간 안 죽고 떠 있게 하는" 문제도 그 한 프로세스를 잘 살려 두는 문제로 좁혀졌다 — 설정이 바뀌면 재시작 없이 핫 리로드로 흡수하고, 외부 요청 실패는 타임아웃·폴백으로 삼키는 식이다.

또 다른 오픈소스 AI 에이전트 Hermes Agent를 같은 집 서버에 올려 내부를 뜯어보니, 정확히 반대편에서 같은 문제를 풀고 있었다. Hermes는 프로세스를 하나로 모으지 않는다. 오히려 게이트웨이·대시보드·예약작업(cron)을 여러 개의 오래 사는 프로세스로 쪼개 한 컨테이너에 욱여넣고, 그 위에 전담 감독관을 한 명 앉힌다. 이 글은 딱 그 한 가지 갈림길 — "생존을 앱 한 프로세스에서 풀 것인가, 아니면 OS 감독 계층에서 풀 것인가" — 만 따라간다. 나머지 차이는 전부 여기서 파생된다.

같은 목표, 갈라지는 첫 결정 — 프로세스가 하나인가 여럿인가

두 봇 다 목표는 똑같다. "사람이 안 지켜봐도 알아서 살아 있어라." 그런데 그 목표에 도달하는 첫 결정에서 갈린다. OpenClaw는 단일 게이트웨이를 중심에 두고 그 하나를 오래 살리는 데 집중한다. Hermes는 애초에 여러 프로세스가 동시에 떠 있어야 하는 구조를 전제로 깔고 시작한다.

▲ OpenClaw — 게이트웨이 한 프로세스가 전부

위 다이어그램은 앞서 다룬 OpenClaw의 뼈대를 한 칸으로 요약한 것이다. 게이트웨이 프로세스 하나가 메신저 채널, 브라우저 조작, 미디어 처리를 모두 자기 안에서 끌어안는다. 여기서 "생존"은 곧 "이 한 프로세스를 어떻게 오래, 재시작 없이 유지하느냐"로 환원된다 — 프로세스가 하나뿐이니 감독이라는 개념 자체가 필요 없고, 대신 설정을 어떻게 바꿔 끼우느냐가 핵심 난이도가 된다.

▲ Hermes — 한 컨테이너 안에 오래 사는 프로세스가 여럿

위 다이어그램은 Hermes가 전제로 까는 구조다. 컨테이너 하나 안에 메시지 수신 게이트웨이, 예약 작업 실행기, 웹 대시보드가 나란히 떠 있고, 게이트웨이는 일을 하려고 git·ssh·npm·브라우저 같은 자식 프로세스를 수시로 낳는다. OpenClaw와의 결정적 차이가 여기서 이미 드러난다 — 프로세스가 하나가 아니므로, "그중 하나가 쓰러지면 나머지를 누가 지키느냐"라는, OpenClaw에는 아예 없던 질문이 생긴다. 흔한 오해가 "컨테이너 하나면 프로세스도 하나"라는 가정인데, Hermes는 그 반대를 택했고 그 대가로 감독 문제를 떠안았다.

여럿을 택한 대가 — 단일 프로세스 모델의 세 가지 사고

Hermes가 만약 OpenClaw처럼 "게이트웨이 하나를 컨테이너의 메인으로" 띄웠다면 어떻게 될까? 컨테이너는 메인 프로세스가 죽으면 같이 종료된다(이게 컨테이너의 기본 규약이다). 여러 프로세스를 이 단순 모델에 억지로 담으면 세 가지 사고가 터진다.

위 다이어그램은 여러 프로세스를 단일 메인 모델에 담을 때 갈라지는 세 실패를 보여준다. 첫째, 메신저 연결이 잠깐 끊겨 게이트웨이가 죽으면 컨테이너가 통째로 내려가 봇이 먹통이 된다. 둘째, 에이전트가 작업하려고 띄운 자식 프로세스는 일을 마치면 좀비 프로세스(종료됐지만 부모가 회수하지 않아 프로세스 표에 남는 죽은 항목)가 되는데, 메인이 이걸 거둬들이지 않으면 시간이 갈수록 쌓인다. 셋째가 가장 고약하다 — 토큰 하나를 잘못 넣었을 뿐인데 게이트웨이가 즉시 종료되고, 재시작 정책이 다시 띄우고, 또 같은 이유로 죽는 무한 재시작 루프에 빠진다. 주목할 점은, OpenClaw는 프로세스가 하나뿐이라 둘째(자식 회수)와 크래시 전파 문제를 애초에 이런 형태로 겪지 않는다는 것이다. 이 세 사고는 "여럿을 한 컨테이너에 담기로 한" Hermes가 스스로 떠안은 숙제다.

Hermes의 답 — PID 1에 전담 감독관(s6-overlay)을 앉힌다

OpenClaw가 "게이트웨이를 어떻게 안 죽게 유지하느냐"를 애플리케이션 계층에서 풀었다면, Hermes는 같은 문제를 한 층 아래 OS 감독 계층으로 내려 푼다. 컨테이너의 1번 프로세스(PID 1) 자리에 게이트웨이가 아니라 s6-overlay라는 감독관을 앉히는 것이다. s6-overlay는 여러 프로세스를 감독(supervise)하는 경량 도구 모음으로, 리눅스에서 PID 1이 원래 져야 하는 책임 — 자식 프로세스 회수, 신호 전달, 자식 감시 — 을 대신 진다. 비유하자면 건물 관리실을 따로 두는 것과 같다. 입주자(게이트웨이·대시보드)가 하나 쓰러져도 관리실은 안 쓰러지고, 쓰러진 입주자만 다시 일으켜 세운다.

위 다이어그램은 감독관 모델의 핵심 구조를 보여준다. PID 1 자리에 s6-overlay가 앉고, 게이트웨이·대시보드·프로필별 게이트웨이가 감독 대상으로 매달린다. 점선 두 개가 중요하다 — 하나는 끝난 자식 프로세스를 PID 1이 즉시 거둬들여 좀비가 안 쌓이게 하는 흐름이고, 다른 하나는 게이트웨이가 크래시했을 때 감독관이 약 1초 뒤 같은 자리에 다시 띄우는 흐름이다. OpenClaw의 단일 프로세스 모델이 "메인이 죽으면 컨테이너가 죽는다"였다면, Hermes는 "관리실(PID 1)은 절대 안 죽고, 죽은 입주자만 골라 되살린다"로 뒤집었다. 앞서 본 좀비 누적과 크래시 전멸이 이 한 장으로 동시에 풀린다.

무한 재시작 루프를 끊는 법 — "죽지 말고 degrade 하라"

그런데 세 번째 사고(설정 오류 → 무한 재시작)는 감독관을 둔다고 저절로 풀리지 않는다. 오히려 감독관이 부지런히 재시작하니 더 빨리 폭주할 수도 있다. 여기서 Hermes의 선택이 OpenClaw의 정신과 의외로 겹친다 — 실패를 종료가 아니라 축소 운영으로 흡수하는 것이다. OpenClaw가 외부 요청 실패를 타임아웃·폴백으로 삼켰듯, Hermes는 연결할 플랫폼이 하나도 없어도 게이트웨이를 종료시키지 않고 "degraded(축소 운영)" 상태로 계속 살려 둔다. 종료(exit)가 없으면 재시작 루프도 없다.

▲ 순진한 방식 — 실패하면 종료 → 폭주

위 다이어그램은 고치기 전의 폭주 고리를 보여준다. 토큰 오류 같은 한 가지 실패가 곧장 프로세스 종료로 이어지고, 종료를 감지한 재시작 장치가 다시 띄우고, 같은 실패가 또 종료를 부르며 같은 자리를 끝없이 돈다. 이 고리의 함정은 "재시작은 회복 수단"이라는 통념이다 — 일시적 장애엔 맞지만, 원인이 그대로인 설정 오류에는 재시작이 오히려 CPU만 태우는 폭주를 만든다. 감독관을 세운 대가로, Hermes는 이 함정을 반드시 따로 막아야 했다.

▲ Hermes의 방식 — 실패해도 살아서 축소 운영

위 다이어그램은 Hermes가 택한 해법이다. 플랫폼 하나가 연결에 실패해도 게이트웨이는 종료하지 않고, 실패한 그 플랫폼만 빼고 나머지(예약 작업, 정상 연결된 다른 메신저)는 계속 돌린다. 별도 감시 흐름이 주기적으로 재연결을 시도하다가, 사용자가 토큰을 고치는 순간 그 플랫폼만 조용히 되살아난다. 두 그림을 같은 축에서 비교하면 차이가 분명하다 — 순진한 방식은 한 부분의 실패를 전체 종료로 키우고, Hermes의 방식은 실패를 한 부분의 일시 정지로 가둔다.

정리 — 난이도를 어느 층으로 옮겼나

결국 두 봇은 "알아서 살아 있어라"라는 같은 목표를, 첫 결정 하나로 전혀 다른 층에서 푼다. OpenClaw는 프로세스를 하나로 모아 생존을 설정 관리 문제로 바꿨고, Hermes는 프로세스를 여럿으로 쪼갠 대신 생존을 OS 감독 문제로 바꿨다.

	OpenClaw	Hermes
프로세스 구성	게이트웨이 하나가 전부 통합	게이트웨이·대시보드·cron 여러 프로세스 상주
"생존"이 푸는 층	앱 계층 — 설정 핫 리로드로 재시작 최소화	OS 계층 — PID 1 감독관이 죽은 프로세스만 되살림

어느 쪽이 옳다기보다, 떠안는 숙제의 종류가 다르다. Hermes의 s6 감독 트리는 여러 프로세스가 한 컨테이너에 동거하는 복잡한 환경에서 강하지만 그만큼 감독·부팅 순서·degrade 처리라는 숙제를 진다. OpenClaw의 단일 게이트웨이는 감독이라는 개념 자체가 없어 단순하지만, 대신 모든 걸 한 프로세스에 담은 만큼 설정 관리가 핵심 난이도가 된다. "알아서 살아 있는" 자율 에이전트의 전제 조건은 같지만, 그 전제를 어디에 세우느냐 — 애플리케이션이냐 운영체제냐 — 가 이 두 봇을 가르는 첫 갈림길이었다.

---

이 글은 생성형 AI의 도움을 받아 작성되었습니다. 원본 자료를 기반으로 AI가 초안을 생성하고, 작성자가 검토·편집하였습니다.