자동화의 두 층 — OpenClaw는 '언제 깨울지', Hermes는 '깨어난 여럿이 어떻게 나눌지'

개인 AI 어시스턴트 OpenClaw를 다룰 때, 그 자동화(Automation)의 핵심은 "에이전트를 언제 깨우느냐"였다. 정해진 시각에 깨우는 cron(예약 실행), 외부 이벤트가 찌르면 깨우는 webhook(외부 요청 수신), 특정 순간에 끼어드는 hook(개입 지점), 그리고 "이건 알아서 해도 된다"를 상시로 정의해 두는 standing orders(상시 명령) — 이 네 가지 트리거로 봇을 자동으로 깨운다. 그리고 대체로 거기서 멈춘다. 깨어난 에이전트는 대개 혼자 일을 하고 끝낸다.

또 다른 오픈소스 AI 에이전트 Hermes Agent를 같은 집 서버에 올려 kanban(칸반) 도구를 뜯어보니, 정확히 그다음 층의 문제를 풀고 있었다. 자동화에는 서로 다른 층이 있다 — "언제 깨우나"라는 트리거 층 위에, "깨어난 여럿이 한 작업을 어떻게 나누나"라는 오케스트레이션(orchestration, 여러 에이전트의 협업 조율) 층이 얹힌다. OpenClaw의 자동화가 앞 층에서 단일 에이전트를 깨우는 데 집중한다면, Hermes의 칸반은 뒷 층에서 깨어난 여러 에이전트가 큰 일을 분담하게 만든다. 둘은 직접 대응하는 경쟁 기능이 아니라 자동화의 다른 층이다 — 이 글은 그 갈림길 하나만 따라간다.

같은 문제, 갈라지는 결정 — 자동화의 어느 층에서 멈추고 어디서 시작하나

두 시스템 다 "사람이 안 붙어 있어도 일이 돌아가게" 하려는 자동화다. 그런데 그 자동화가 다루는 층이 다르다. 한쪽은 실행의 시작점(언제)을 관리하고, 다른 쪽은 실행된 뒤의 분업(어떻게 나누나)을 관리한다.

▲ OpenClaw — 단일 에이전트를 '언제' 깨울지의 층

위 다이어그램은 OpenClaw 자동화가 서는 층을 한 칸으로 요약한 것이다. 예약 시각·외부 요청·개입 지점·상시 명령이라는 네 가지 트리거가 에이전트를 깨우는 조건을 관리하고, 깨어난 에이전트는 대체로 혼자 일을 처리한다. 여기서 자동화의 난이도는 "무엇을, 언제, 무슨 사건에 반응해 시작할 것인가"에 몰린다 — 여러 에이전트가 한 작업을 어떻게 나눠 맡느냐 하는 물음은 이 층에 아예 등장하지 않는다.

▲ Hermes — 깨어난 '여럿이 어떻게 나눌지'의 층

위 다이어그램은 Hermes 칸반이 서는 층을 보여준다. 여기서는 트리거가 아니라, 이미 일을 시작한 여러 에이전트가 하나의 공유 작업판을 가운데 두고 큰 작업을 잘게 쪼개 나눠 맡는다. OpenClaw 자동화가 "언제 깨울까"에서 멈춘 바로 그 지점 뒤에 이 층이 붙는다 — 깨어난 에이전트가 하나가 아니라 여럿일 때, "누가 무엇을 맡고 어떤 순서로 진행하느냐"라는, 트리거 층에는 없던 물음이 새로 생긴다. 흔한 오해가 두 도구를 나란히 놓고 "어느 쪽이 더 나은 자동화냐"를 묻는 것인데, 애초에 겨루는 층이 다르다.

깨어난 다음의 문제 — 한 작업을 여럿이 어떻게 쪼개나

"리서치하고, 분석하고, 보고서를 써 줘" 같은 요청을 생각해 보자. 트리거 층의 관심사는 "이 요청을 언제 시작하느냐"까지다. 하지만 이건 성격이 다른 세 가지 일이다 — 자료를 찾는 일, 찾은 걸 종합·판단하는 일, 사람이 읽을 글로 다듬는 일. 한 에이전트에게 통째로 맡기면 세 가지를 한 맥락(context, 모델이 한 번에 들고 있는 대화·메모리) 안에서 섞어 처리하느라 길을 잃기 쉽고, 중간에 프로세스가 죽으면 처음부터 다시 해야 한다. Hermes 칸반이 다루는 건 정확히 이 "깨어난 다음"의 분업이다.

위 다이어그램은 하나의 요청이 어떻게 보드 위의 여러 카드로 흩어지는지 보여준다. 한 문장짜리 요청이 공유 작업판으로 들어가면, 성격이 다른 세 가지 일이 각각 별도 카드가 되고 카드마다 담당 프로필(profile, 서로 다른 성격·모델·도구·기억을 가진 독립 에이전트 설정)이 붙는다. 핵심은 "한 모델이 다 한다"가 아니라 "작업판이 진실의 원천이고, 카드 단위로 전문가에게 배분된다"는 점이다. 이건 OpenClaw 자동화가 손대지 않는 결정이다 — 트리거 층은 "이 일을 시작하라"까지만 말하지, "이 일을 셋으로 나눠 각기 다른 전문가에게 맡기라"는 지시는 하지 않기 때문이다. 지금은 "큰 일이 카드로 쪼개진다"까지만 잡으면 된다.

쪼개는 것보다 어려운 건 순서다. 어떤 카드는 앞 카드가 끝나야 시작할 수 있고, 어떤 카드는 동시에 해도 된다. Hermes는 이 순서를 프롬프트의 말이 아니라 데이터 구조로 강제한다. 카드를 만들 때 "이 카드들이 부모"라고 지정하면, 그 카드는 부모가 전부 완료될 때까지 대기 상태에 머물다가 부모가 다 끝나는 순간 자동으로 진행 가능 상태로 올라간다.

위 다이어그램은 여러 갈래로 퍼졌다가(팬아웃) 다시 한 점으로 모이는(팬인) 작업 그래프를 보여준다. 비용 비교와 성능 비교 두 리서치 카드는 서로 의존하지 않아 부모 없이 만들어지고, 분배기가 둘을 동시에 병렬로 띄운다. 종합 카드는 그 두 리서치 카드를 부모로 지정했기 때문에 둘 다 끝나기 전에는 진행 가능 상태가 되지 않는다. 메모 작성 카드는 다시 종합 카드를 부모로 둔다. 이 패턴의 가치는 병렬화와 순서 보장을 동시에 얻는다는 것이다 — 독립적인 일은 동시에 빨리 처리하고, 진짜 의존 관계만 순서로 묶는다. 바로 이 대목이 OpenClaw 자동화와 가장 선명하게 갈리는 지점이다. 트리거 층에는 여러 카드를 병렬로 분배하거나 카드 사이의 선후 관계를 자동으로 푸는 개념 자체가 없다 — 그 층의 일은 "언제 깨우나"까지이고, "깨어난 여럿을 어떤 순서로 엮나"는 온전히 이 오케스트레이션 층의 몫이기 때문이다.

접점은 하나 — 죽어도 살아남는 작업 상태

서로 다른 층을 다루지만, 두 시스템이 손을 맞대는 접점이 딱 하나 있다. 바로 작업 상태의 영속화(persistence)다. OpenClaw의 예약 트리거는 SQLite(파일 기반 관계형 데이터베이스)에 저장돼 봇을 재시작해도 예약과 실행 기록이 남고, Hermes의 칸반 카드도 하나의 SQLite 파일(~/.hermes/kanban.db)에 저장돼 프로세스가 죽어도 카드와 진행 상태가 디스크에 그대로 남는다.

위 다이어그램은 다른 층을 다루는 두 시스템이 어떻게 같은 뿌리로 모이는지 보여준다. 한쪽은 "언제 깨울지"의 예약 정보를, 다른 쪽은 "누가 무엇을 어디까지 했는지"의 분업 상태를 저장하지만, 둘 다 그 상태를 메모리가 아니라 디스크의 관계형 데이터베이스에 두었다는 점에서 만난다. 그래서 두 시스템 모두 프로세스가 갑자기 죽어도 예약이나 진행 중인 카드를 잃지 않고, 다시 떠오른 뒤 회수하거나 재시도할 수 있다. 정직하게 말하면 이건 기능의 직접 대응이 아니다 — 다른 층의 서로 다른 대상을 저장할 뿐이다. 다만 "자동화가 신뢰받으려면 프로세스의 생사와 무관하게 작업이 살아남아야 한다"는 요구가 층을 가리지 않고 똑같이 작동한다는 것, 그 하나가 겹친다.

정리 — 자동화의 서로 다른 층

결국 두 시스템은 자동화라는 한 단어 안에서 서로 다른 층을 맡는다. OpenClaw는 "혼자 일하는 에이전트를 언제 깨울까"라는 앞 층을 트리거로 풀고, Hermes 칸반은 "깨어난 여럿이 한 일을 어떻게 나눌까"라는 뒷 층을 보드로 푼다.

	OpenClaw Automation	Hermes kanban
다루는 층	트리거 — 단일 에이전트를 '언제' 깨우나	오케스트레이션 — 깨어난 '여럿이 어떻게' 나누나
공통 접점	예약 트리거를 SQLite에 영속화	카드·진행 상태를 SQLite에 영속화

어느 쪽이 더 낫다기보다, 자동화 파이프라인에서 맡는 자리가 다르다. OpenClaw의 트리거는 "혼자서도 알아서 시작하는" 에이전트를 만드는 데 강하고 — 정해진 때·외부 사건에 봇을 깨우는 일이라면 이 층이 딱 맞다. Hermes의 칸반은 "깨어난 여럿이 큰 일을 안전하게 나눠 맡는" 데 강하고 — 성격이 다른 전문가가 여럿 필요하거나, 크래시·재시작을 견디며 이어져야 하거나, 사람이 중간에 끼어들 수 있어야 하는 작업이라면 이 층이 필요하다. 자동화를 끝까지 밀어 보면 결국 두 층이 다 필요해진다 — "언제 깨우나"를 앞에서 풀고, 깨어난 다음 "여럿이 어떻게 나누나"를 뒤에서 잇는 식으로.

---

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