자가 진화인가, 제어 플레인인가 — Hermes와 OpenClaw를 가르는 진짜 질문
Kimi의 「Hermes vs OpenClaw」를 실제 운영 관점에서 다시 읽고
Hermes는 학습하는 에이전트이고 OpenClaw는 로컬 AI 제어 플레인이라는 비교는 어디까지 유효할까. 스킬, 메모리, 게이트웨이보다 먼저 정해야 할 운영 질문을 정리했다.
제일 먼저 든 생각
이 비교에서 가장 마음에 걸린 문장은 결론보다 질문 쪽이었다.
에이전트를 개발하고 싶은가, 아니면 제어 플레인을 운영하고 싶은가.
Hermes를 시간이 지나면서 일하는 법을 배우는 에이전트, OpenClaw를 여러 채널과 장치를 묶는 로컬 AI 운영 계층으로 나누면 차이가 빠르게 보인다. 원문의 비교축은 분명 유용하다.
다만 실제로 둘을 운영할 사람에게는 이 구분이 조금 너무 깔끔하다. Hermes에도 게이트웨이, 메시징 채널, 프로필 격리, 플러그인, 서브에이전트가 있다. OpenClaw에도 에이전트 런타임, 세션, 메모리와 스킬이 있다. 한쪽은 에이전트이고 다른 쪽은 플랫폼이라고 잘라 말하기보다, 어느 층을 제품의 중심에 두었는가에 가까운 차이다.
‘자가 진화’는 모델이 혼자 다시 학습한다는 뜻이 아니다
Hermes의 자기 개선을 이해할 때 먼저 떼어내야 할 오해가 있다. 여기서 진화는 모델 가중치가 밤마다 새로 학습된다는 뜻이 아니다.
Hermes의 공식 문서에서 스킬은 필요할 때 불러오는 지식 문서이자 재사용 가능한 작업 절차다. 에이전트는 복잡한 일을 끝냈거나, 실패를 복구했거나, 사용자의 교정을 받은 뒤 그 방법을 스킬로 남길 수 있다. 세션을 넘겨 유지되는 메모리와 과거 대화 검색도 다음 작업의 맥락을 이어준다.
즉 변화하는 것은 모델 자체보다 모델 주변의 작업 시스템이다.
- 어떤 상황에서 어떤 절차를 불러오는가
- 실패했을 때 무엇을 점검하는가
- 사용자가 반복해서 강조한 기준을 어떻게 보존하는가
- 다음에는 어느 단계를 자동화할 수 있는가
그래서 ‘자가 진화형’이라는 말은 매력적이지만, 실무에서는 절차 기억(procedural memory)을 스스로 관리할 수 있는 에이전트라고 읽는 편이 더 정확하다.
여기에는 위험도 함께 있다. 잘못 배운 절차가 스킬로 굳어지면 다음 작업에서도 반복된다. 중요한 운영 환경이라면 스킬 생성·수정 이력, 검토 기준, 되돌리기, 권한 범위를 함께 설계해야 한다. 학습 능력만 있고 통제가 없으면 개선이 아니라 드리프트가 된다.
‘제어 플레인’도 OpenClaw만의 전유물은 아니다
원문이 설명하는 OpenClaw의 중심은 장기 실행되는 Gateway다. 채널, 노드, 세션, 플러그인, 워크스페이스와 제어 클라이언트가 이 Gateway를 중심으로 연결된다. 여러 디바이스와 계정, 에이전트를 운영해야 하는 사람에게는 이해하기 좋은 구조다.
왼쪽은 사용자·메모리·스킬·도구가 순환하는 Hermes, 오른쪽은 Gateway를 중심으로 채널·노드·워크스페이스·플러그인·세션이 연결되는 OpenClaw다. 이미지: Kimi Resources.
그렇다고 Hermes에 운영 계층이 없는 것은 아니다. 공식 기능 문서를 보면 Hermes도 Telegram·Discord 같은 메시징 표면, 독립 프로필, 플랫폼별 도구 권한, 플러그인, 예약 작업, 서브에이전트, API 서버를 함께 다룬다. 실제 사용에서는 하나의 개인 에이전트만 훈련시키는 도구보다 훨씬 넓다.
따라서 차이는 기능표의 체크 개수보다 기본적으로 무엇을 먼저 최적화했는가에서 찾는 편이 낫다.
| 먼저 해결하려는 문제 | 더 자연스러운 출발점 |
|---|---|
| 같은 일을 할수록 방법이 좋아져야 한다 | 스킬·메모리 중심의 Hermes |
| 여러 채널·장치·워크스페이스를 한 런타임에서 통제해야 한다 | Gateway 중심의 OpenClaw |
| 개인과 소규모 팀의 반복 업무를 깊게 자동화한다 | Hermes의 강점이 잘 드러남 |
| 다수 에이전트와 디바이스의 연결 관계가 제품의 핵심이다 | OpenClaw의 강점이 잘 드러남 |
이 표도 절대적인 경계는 아니다. 선택의 시작점을 보여주는 지도에 가깝다.
실제 조직에서는 둘 중 하나만 고르는 질문이 아니다
Deciflow에서 Hermes를 운영하며 더 크게 느끼는 문제는 ‘학습형인가, 제어형인가’의 양자택일이 아니다. 오히려 다음 두 요구가 동시에 나타난다.
첫째, 에이전트는 사용자와 조직의 작업 방식을 배워야 한다. 같은 오류를 반복하지 않고, 검증 절차와 문서 규칙을 다음 작업에 재사용해야 한다.
둘째, 운영자는 그 학습의 범위를 통제해야 한다. 직원별 프로필은 분리되어야 하고, 드라이브와 고객 자료 접근 권한은 섞이면 안 된다. 모델·도구·메시징 채널·예약 작업은 중앙에서 끊거나 교체할 수 있어야 한다.
여기서 더 중요한 질문이 나온다.
무엇은 에이전트가 스스로 개선해도 되고, 무엇은 운영자가 승인해야 하는가?
예를 들어 글쓰기 표현이나 반복 업무의 점검 순서는 스킬로 진화해도 좋다. 반면 파일 접근 경계, 외부 전송, 자격 증명, 직원별 권한은 에이전트가 경험을 근거로 넓혀서는 안 된다. 학습과 통제를 같은 설정 묶음으로 다루면 편리해 보이지만, 사고가 생겼을 때 원인을 분리하기 어렵다.
도입 전에 확인할 다섯 가지
제품 이름을 고르기 전에 아래 질문에 답하면 선택이 훨씬 선명해진다.
-
무엇이 나아져야 하는가
답변 품질인지, 반복 절차인지, 채널 연결인지, 디바이스 운영인지 구분한다. -
상태의 주인은 누구인가
메모리, 스킬, 세션, 워크스페이스, 인증 정보가 어디에 저장되고 누가 수정하는지 확인한다. -
학습과 권한이 분리되어 있는가
에이전트가 일을 더 잘 배우는 것과 더 많은 자료에 접근하는 것은 다른 문제다. -
잘못 배웠을 때 되돌릴 수 있는가
스킬·설정·플러그인의 변경 내역과 검토·복구 경로가 필요하다. -
운영자가 보고 싶은 투명성은 무엇인가
에이전트의 판단 과정이 중요한지, 채널·노드·세션의 운영 상태가 중요한지 정한다.
결국 선택해야 하는 것은 운영 철학이다
Kimi의 비교는 Hermes와 OpenClaw를 기능 목록이 아니라 운영 모델로 바라보게 한다는 점에서 좋다. 다만 Hermes는 에이전트일 뿐이고 OpenClaw만 제어 플레인이라는 식으로 받아들이면 현재 두 프로젝트의 폭을 놓치기 쉽다.
내가 가져갈 결론은 조금 다르다.
- Hermes의 중심 질문은 이 에이전트가 다음번에는 어떻게 더 잘 일하게 할 것인가에 가깝다.
- OpenClaw의 중심 질문은 여러 AI 실행 표면을 어떤 런타임에서 연결하고 통제할 것인가에 가깝다.
- 실제 조직의 질문은 학습 가능한 영역과 중앙 통제해야 할 영역의 경계를 어디에 그을 것인가다.
자가 진화와 제어 플레인은 경쟁 개념이 아니다. 신뢰할 수 있는 업무 에이전트를 만들려면 결국 둘 다 필요하다. 차이는 어느 쪽에서 시작하고, 어느 경계를 더 명시적으로 설계하느냐에 있다.
원문과 함께 확인한 문서
- 원문: Hermes vs OpenClaw: 자가 진화형 코딩 에이전트인가, 로컬 AI 제어 플레인인가?
- Hermes 공식 문서: Skills System
- Hermes 공식 문서: Features Overview
- OpenClaw 공식 문서: Gateway architecture