Hermes vs OpenClaw 구조 차이 | AI 에이전트 아키텍처 비교 2026

핵심 판단 - 30초 결론

Hermes와 OpenClaw의 차이는 채널 수가 아니라 운영 중심축입니다. Hermes는 에이전트가 일을 어떻게 기억하고, 반복하고, 개선하는가에 초점이 있습니다. OpenClaw는 사용자가 이미 쓰는 채팅 앱과 디바이스에 AI 실행 능력을 어떻게 연결하는가에 초점이 있습니다.

처음 고를 때는 이렇게 보면 됩니다.

한 문장으로 줄이면 이렇습니다.

Hermes는 에이전트를 키우는 도구이고, OpenClaw는 에이전트를 연결하는 도구입니다.

이 글은 2026년 5월 15일 기준으로 Hermes 공식 문서, OpenClaw 공식 문서, Gateway·Hooks·Heartbeat 문서를 기준으로 다시 정리했습니다. 기능 숫자는 계속 바뀔 수 있지만, Hermes는 학습형 런타임, OpenClaw는 self-hosted gateway라는 방향은 구조적으로 오래 남을 차이입니다.

---

먼저 버려야 할 오해

둘 다 텔레그램 봇이라는 설명은 너무 얕다

겉으로 보면 둘 다 텔레그램이나 메신저에서 AI에게 일을 시키는 도구처럼 보입니다. 하지만 텔레그램은 본질이 아닙니다. 텔레그램은 입력 채널일 뿐입니다.

Hermes에서 중요한 질문은 이것입니다.

이 작업을 에이전트가 어떤 기억, 어떤 스킬, 어떤 도구, 어떤 실행 환경으로 끝낼 것인가?

OpenClaw에서 중요한 질문은 이것입니다.

이 메시지를 어느 채널, 어느 세션, 어느 워크스페이스, 어느 에이전트에게 보낼 것인가?

따라서 비교 기준을 "텔레그램 연결이 되냐"에 두면 글이 얕아집니다. 실제 차이는 작업 실행 구조와 운영 권한 구조에서 갈립니다.

승자 비교가 아니라 배치 비교다

Hermes가 더 좋다, OpenClaw가 더 좋다로 보면 판단이 흐립니다. 두 도구는 같은 층위에만 놓이지 않습니다.

Hermes는 깊이의 문제를 풀고, OpenClaw는 연결의 문제를 풉니다. 이 문장을 잡고 읽으면 뒤의 비교가 훨씬 명확해집니다.

---

전체 아키텍처 한눈에 보기

Hermes Agent는 실행 루프가 중심이다

Hermes 공식 문서는 Hermes를 self-improving AI agent로 설명합니다. 핵심은 "한 번 답하는 챗봇"이 아니라, 경험에서 스킬을 만들고, 메모리를 유지하고, 크론으로 다시 실행되고, 필요하면 서브에이전트에게 일을 나누는 런타임입니다.

Hermes를 단순화하면 다음 흐름입니다.

여기서 핵심은 채널이 아니라 에이전트 루프입니다. 텔레그램에서 들어오든 CLI에서 들어오든, 중요한 것은 Hermes가 같은 에이전트 런타임 안에서 일을 이해하고 끝낸다는 점입니다.

OpenClaw는 Gateway가 중심이다

OpenClaw 공식 문서는 OpenClaw를 self-hosted gateway로 설명합니다. Discord, Google Chat, iMessage, Matrix, Microsoft Teams, Signal, Slack, Telegram, WhatsApp, Zalo 같은 채널을 하나의 Gateway에 연결하고, 그 Gateway가 Pi 같은 AI coding agent로 요청을 넘기는 구조입니다.

OpenClaw를 단순화하면 다음 흐름입니다.

OpenClaw의 핵심은 AI가 어디에 연결되어 있는가입니다. 즉 "모델이 똑똑한가"보다 어느 채널에서 누가 보낸 요청을 어느 세션으로 보낼 것인가가 더 중요한 설계 질문입니다.

구조 비교표

---

요청 처리 방식의 차이

Hermes의 한 턴은 "실행 계획"에 가깝다

Hermes의 한 턴은 단순 답변보다 작업 실행에 가깝습니다. 요청이 들어오면 메모리와 스킬을 보고, 필요한 도구를 고르고, 파일을 읽고, 명령을 실행하고, 결과를 다시 판단합니다.

예를 들어 "이 포스팅 SEO를 고치고 배포해"라고 하면 Hermes식 처리 흐름은 다음에 가깝습니다.

1. 프로젝트 규칙과 운영 문서를 확인합니다.
2. 관련 파일을 찾습니다.
3. 기존 글 구조를 읽습니다.
4. 제목, excerpt, markdown, 테스트를 수정합니다.
5. targeted test와 build를 돌립니다.
6. 커밋과 푸시를 진행합니다.
7. 라이브 페이지를 확인하고 증거를 남깁니다.

즉 Hermes는 작업의 처음부터 끝까지를 하나의 실행 루프로 잡기 좋습니다.

OpenClaw의 한 턴은 "라우팅된 채널 이벤트"에 가깝다

OpenClaw의 한 턴은 Gateway가 받은 메시지를 적절한 세션과 에이전트로 보내는 흐름에 가깝습니다. 같은 "배포 확인해"라는 요청이라도 누가 보냈는지, 어느 채널인지, 어느 workspace인지, 현재 session key가 무엇인지가 중요합니다.

예를 들어 팀 Slack 채널에서 요청이 들어오면 OpenClaw는 다음을 봐야 합니다.

• 이 채널의 사용자는 누구인가?
• 이 사용자는 어떤 작업을 요청할 권한이 있는가?
• 이 메시지는 기존 session에 붙일 것인가, 새 session으로 열 것인가?
• 어떤 workspace의 agent에게 보낼 것인가?
• 결과를 DM으로 줄 것인가, 채널로 공개할 것인가?

그래서 OpenClaw는 현실 채널과 권한을 다루는 운영에 강합니다.

같은 요청도 다르게 설계된다

---

메모리 구조 비교

Hermes 메모리는 작고 강하게 주입된다

Hermes 공식 문서 기준으로 Hermes의 persistent memory는 MEMORY.md와 USER.md를 중심으로 동작합니다. 이 파일들은 ~/.hermes/memories/ 아래에 저장되고, 세션 시작 시 시스템 프롬프트에 주입됩니다.

중요한 특징은 다음입니다.

여기서 중요한 것은 항상 필요한 기억과 검색해서 찾을 과거 기록을 분리한다는 점입니다. 매번 필요한 규칙은 MEMORY.md에 넣고, 지난 대화의 세부 내용은 session search로 찾는 구조가 비용과 품질을 동시에 잡습니다.

OpenClaw 메모리는 파일과 workspace가 중심이다

OpenClaw는 workspace 파일을 중심으로 에이전트의 행동을 잡습니다. Hooks 문서 기준으로 bootstrap에 쓰이는 파일 이름에는 AGENTS.md, SOUL.md, TOOLS.md, IDENTITY.md, USER.md, HEARTBEAT.md, BOOTSTRAP.md, MEMORY.md 같은 파일이 포함됩니다.

또한 session-memory hook은 최근 대화를 workspace의 memory 폴더에 저장하는 방식으로 동작합니다. 이 방식은 Hermes보다 더 파일 중심이고 사람이 직접 검토하기 쉬운 구조입니다.

따라서 OpenClaw의 메모리는 숨은 지능이라기보다 파일로 관리되는 운영 맥락에 가깝습니다. 팀원이 Git으로 보고 리뷰하기 쉬운 장점이 있습니다.

메모리 선택 기준

---

스킬과 확장 방식

Hermes 스킬은 절차적 기억이다

Hermes의 skills system은 on-demand knowledge documents입니다. 모든 스킬 전문을 매번 프롬프트에 넣는 것이 아니라, 먼저 목록을 보고 필요할 때만 깊게 로드하는 progressive disclosure 구조를 씁니다.

Hermes 스킬이 강한 이유는 다음입니다.

• 반복 절차를 SKILL.md로 고정할 수 있습니다.
• 실행 조건, procedure, pitfalls, verification을 한 문서에 담을 수 있습니다.
• 에이전트가 경험에서 스킬을 만들거나 수정할 수 있습니다.
• 스킬은 slash command나 자연어 요청으로 불러 쓸 수 있습니다.
• 토큰을 줄이기 위해 Level 0, Level 1, Level 2 식으로 필요한 만큼만 엽니다.

이 구조는 반복 운영에 매우 강합니다. 예를 들어 "콘텐츠 수정 후 DB 반영, revalidate, live smoke" 같은 작업은 한 번 잘 정리해 두면 다음부터 품질이 안정됩니다.

OpenClaw 확장은 hook과 workspace가 중심이다

OpenClaw는 hooks가 강합니다. Hooks 문서 기준으로 message received, message sent, agent bootstrap, session patch, gateway startup, tool execution 같은 지점에 개입할 수 있습니다.

OpenClaw식 확장은 다음에 가깝습니다.

• 특정 채널에서 들어온 메시지를 전처리합니다.
• workspace별 bootstrap file을 추가합니다.
• gateway startup 때 BOOT.md를 실행합니다.
• command log를 남깁니다.
• session-memory hook으로 대화 요약을 memory 폴더에 저장합니다.
• plugin hook으로 tool call, model resolution, agent lifecycle에 개입합니다.

즉 Hermes 스킬이 에이전트가 일을 잘하게 만드는 절차 지식이라면, OpenClaw hook은 게이트웨이가 요청을 안전하게 받고 흘려보내는 운영 배관에 가깝습니다.

스킬과 hook의 차이

---

자동화 구조 - Cron과 Heartbeat

Hermes Cron은 새 에이전트 세션을 여는 예약 실행이다

Hermes Cron 문서의 중요한 문장은 이것입니다. Cron jobs run in a completely fresh agent session. 즉 Hermes Cron은 기존 대화 맥락을 대충 이어받는 것이 아니라, 작업마다 새 세션으로 실행됩니다.

운영 관점에서는 장점과 주의점이 동시에 있습니다.

따라서 Hermes Cron은 정해진 절차를 정해진 시간에 실행하는 데 좋습니다. 사이트 상태 점검, Q&A 실패 job 확인, RSS 수집, 빌드 스모크, 리포트 작성 같은 작업에 맞습니다.

OpenClaw Heartbeat는 main session을 주기적으로 깨운다

OpenClaw Heartbeat는 cron과 성격이 다릅니다. 공식 문서 기준으로 Heartbeat는 periodic main-session turn입니다. 기본값은 30분 간격이고, HEARTBEAT.md가 있으면 그 작은 체크리스트를 읽고 확인합니다.

중요한 포인트는 다음입니다.

• Heartbeat는 main session 맥락을 가지고 움직입니다.
• 아무 일도 없으면 HEARTBEAT_OK로 조용히 지나갈 수 있습니다.
• HEARTBEAT.md는 작고 안정적인 체크리스트로 유지해야 합니다.
• activeHours로 활동 시간을 제한할 수 있습니다.
• target을 none 또는 last 등으로 조정해 알림을 제어할 수 있습니다.

OpenClaw Heartbeat는 생활형 감시, inbox check, calendar check, notification check처럼 "무언가 있으면 알려줘"에 잘 맞습니다.

자동화 선택표

---

서브에이전트와 멀티에이전트

Hermes subagent delegation은 작업 분할용이다

Hermes의 delegate_task는 child agent를 만듭니다. 공식 문서 기준으로 child agent는 isolated context, restricted toolsets, own terminal sessions를 갖고 독립적으로 일합니다. 부모 대화 전체를 자동으로 아는 것이 아니라, goal과 context로 받은 내용만 알고 일한 뒤 final summary만 부모에게 돌아옵니다.

이 구조는 다음에 강합니다.

• 대형 코드베이스를 영역별로 나눠 조사
• 프론트엔드, API, DB, 테스트를 병렬 분석
• 긴 리서치를 여러 관점으로 분할
• 고난도 작업은 고성능 모델, 단순 조사에는 저렴한 모델 사용
• 부모 컨텍스트를 불필요하게 오염시키지 않음

하지만 중요한 운영 기준이 있습니다. 부모가 context를 잘못 주면 자식은 아무것도 모릅니다. 그래서 "이거 고쳐"가 아니라 파일, 에러, 목표, 금지 범위, 검증 기준을 함께 넘겨야 합니다.

OpenClaw multi-agent routing은 채널 분리용이다

OpenClaw의 멀티에이전트 감각은 Hermes와 다릅니다. OpenClaw는 Gateway가 중심이기 때문에 agent, workspace, sender, channel, session 기준으로 라우팅하는 쪽이 자연스럽습니다.

예를 들면 다음이 가능합니다.

따라서 Hermes의 멀티에이전트는 한 문제를 나눠 푸는 내부 위임이고, OpenClaw의 멀티에이전트는 여러 현실 채널을 나눠 맡기는 외부 라우팅입니다.

---

보안 모델 비교

Hermes 보안은 실행 환경 격리가 핵심이다

Hermes는 실제 파일과 터미널을 만집니다. 그래서 보안 질문은 단순합니다.

AI가 명령을 실행하는 위치는 어디이며, 그 환경은 얼마나 격리되어 있는가?

Hermes 운영에서 중요한 경계는 다음입니다.

• 로컬 전체 권한 대신 Docker, SSH, Daytona, Modal 같은 실행 백엔드를 분리합니다.
• 민감한 폴더를 기본 작업 경로로 두지 않습니다.
• 위험 명령은 승인선을 둡니다.
• 스킬에는 secret, token, DB URL을 넣지 않습니다.
• 메모리는 prompt injection과 credential exfiltration 위험을 검사해야 합니다.
• Cron prompt는 자체적으로 충분히 구체적이어야 하며, secret을 포함하면 안 됩니다.

Hermes는 깊게 일할 수 있는 만큼 실행 권한 관리가 중요합니다.

OpenClaw 보안은 Gateway와 채널 권한이 핵심이다

OpenClaw는 여러 채널을 묶습니다. 그래서 보안 질문이 달라집니다.

이 메시지를 보낸 사람이 누구이며, 이 채널에서 어떤 권한을 줄 것인가?

OpenClaw 운영에서 중요한 경계는 다음입니다.

• Gateway를 인터넷에 그대로 노출하지 않습니다.
• token/password, pairing, bind mode, tailscale 같은 접근 경계를 분명히 합니다.
• channel별로 허용 작업을 다르게 둡니다.
• 그룹 채팅에는 내부 reasoning이나 민감 결과를 보내지 않습니다.
• HEARTBEAT.md에 secret을 넣지 않습니다.
• workspace별 AGENTS.md, TOOLS.md, MEMORY.md를 분리합니다.
• hooks는 실패 시 행동과 로그 위치를 명확히 둡니다.

OpenClaw는 넓게 연결되는 만큼 채널 인증과 라우팅 권한이 중요합니다.

공통 보안 원칙

---

비용과 토큰 감각

Hermes는 깊게 읽는 만큼 비용 상한이 필요하다

Hermes는 메모리, 스킬 목록, 프로젝트 컨텍스트, 도구 결과, 세션 검색, 서브에이전트 결과를 함께 다루기 쉽습니다. 이 구조는 성공률을 올리지만, 입력 토큰이 커질 수 있습니다.

비용을 줄이려면 다음 원칙이 필요합니다.

• 상시 운용은 종량제 API보다 비용 예측 가능한 provider를 먼저 봅니다.
• 스킬은 필요한 것만 로드합니다.
• Cron prompt는 길게 쓰기보다 self-contained하게 씁니다.
• 서브에이전트는 목표와 범위를 좁혀서 호출합니다.
• 단순 점검에는 저렴한 모델, 최종 판단에는 강한 모델을 씁니다.
• 과거 기록 전체를 붙이지 말고 session search 결과만 요약해 넣습니다.

Hermes는 "많이 넣으면 잘한다"가 아니라 필요한 정보만 정확히 넣어야 오래 굴릴 수 있습니다.

OpenClaw는 Heartbeat 크기와 채널 수가 비용을 만든다

OpenClaw는 Gateway 중심이라 비용이 다른 곳에서 생깁니다. Heartbeat가 자주 돌고, HEARTBEAT.md가 길고, 여러 채널 이벤트가 계속 들어오면 작은 호출이 누적됩니다.

비용을 줄이려면 다음이 중요합니다.

• HEARTBEAT.md를 짧게 유지합니다.
• 비슷한 확인은 여러 cron job으로 쪼개지 말고 heartbeat에 묶습니다.
• 알림 target을 신중히 정합니다.
• main session과 isolated session을 구분합니다.
• routine task는 저렴한 모델 또는 낮은 thinking setting을 씁니다.
• group chat에는 불필요한 reasoning delivery를 끕니다.

OpenClaw 비용 관리는 채널 이벤트와 주기 실행을 얼마나 조용하게 설계하느냐에 달립니다.

---

실제 운영 시나리오별 선택

개인 개발자 24시간 운영

개인 개발자가 사이트, 블로그, Q&A, 배포, 콘텐츠를 계속 운영한다면 Hermes를 먼저 잡는 것이 자연스럽습니다.

추천 흐름은 다음입니다.

1. Hermes를 Docker 또는 격리된 작업 폴더에서 실행합니다.
2. 프로젝트별 운영 규칙을 문서화합니다.
3. 반복 절차를 스킬로 정리합니다.
4. Cron으로 낮은 위험의 점검만 자동화합니다.
5. 배포, 삭제, secret, 결제 작업은 승인선을 둡니다.
6. 결과는 짧은 증거 패킷으로 남깁니다.

여기서 OpenClaw는 나중에 붙여도 됩니다. 여러 채널에서 같은 Hermes 운영자에게 지시하고 싶을 때 Gateway 역할로 검토하면 됩니다.

팀·채널 중심 운영

팀이 Slack, Discord, Telegram, iMessage, WebChat을 같이 쓰고, 여러 사람이 AI에게 요청을 보낸다면 OpenClaw를 먼저 설계하는 것이 자연스럽습니다.

추천 흐름은 다음입니다.

1. Gateway를 self-host로 올립니다.
2. channel별 권한과 target을 정합니다.
3. workspace별 AGENTS.md, TOOLS.md, MEMORY.md를 분리합니다.
4. 팀 채널에는 읽기·요약·승인 요청 위주로 둡니다.
5. 실제 코드 변경이나 배포는 별도 agent 또는 Hermes로 넘깁니다.
6. hooks와 command log로 감사 가능성을 확보합니다.

OpenClaw는 팀의 AI 접수창구 역할을 맡기 좋습니다.

연구·문서·코드베이스 분석

논문, 코드베이스, 로그, 테스트, 배포를 길게 다루는 작업은 Hermes가 유리합니다. 이유는 단순합니다. 깊게 읽고, 도구를 쓰고, 결과를 기억하고, 다음 절차로 고정하는 구조가 더 직접적입니다.

특히 다음 작업은 Hermes 쪽으로 기울어집니다.

• 대규모 리팩터링 계획
• 테스트 실패 원인 분석
• API와 DB 스키마 영향 범위 조사
• 운영 문서 갱신
• 주기적 배포 점검
• 반복 작업 스킬화

생활형 비서와 모바일 접점

개인 일정, 가족 알림, inbox, calendar, 메시지 요약, 모바일 원격 승인은 OpenClaw가 더 자연스럽습니다. Gateway가 채널과 디바이스를 중심으로 설계되어 있기 때문입니다.

하지만 생활형 비서도 권한을 열어 두면 위험합니다. OpenClaw를 쓰더라도 첫 설정은 다음처럼 좁혀야 합니다.

• 읽기 중심
• 승인 요청 중심
• 외부 발송 제한
• 결제·삭제·권한 변경 금지
• HEARTBEAT.md는 짧게
• 그룹 채널에는 민감 정보 금지

---

둘을 같이 쓰는 아키텍처

가장 현실적인 조합

둘을 같이 쓴다면 가장 깔끔한 조합은 다음입니다.

즉 OpenClaw가 앞단에서 요청을 받고, Hermes가 뒤에서 무거운 실행을 맡는 구조입니다.

같이 쓸 때 반드시 분리할 것

둘을 연결할수록 권한 분리가 중요합니다.

OpenClaw와 Hermes를 같은 토큰, 같은 폴더, 같은 권한으로 묶으면 안 됩니다. 편해 보이지만 사고 반경이 커집니다.

연결 패턴 예시

---

실패 사례로 보는 차이

Hermes에서 자주 생기는 실패

Hermes는 깊게 일하는 만큼 다음 문제가 자주 생깁니다.

• 메모리가 낡은 규칙을 계속 주입합니다.
• 스킬이 오래되어 현재 코드와 맞지 않습니다.
• Cron prompt가 애매해서 매번 다른 작업을 합니다.
• 서브에이전트에게 context를 덜 줘서 결과가 빗나갑니다.
• 도구 결과가 길어져 토큰 비용이 급증합니다.
• 작업 권한이 넓어져 실수의 피해가 커집니다.

대응은 간단합니다. 기억은 짧게, 스킬은 검증 포함, Cron은 self-contained, 권한은 좁게입니다.

OpenClaw에서 자주 생기는 실패

OpenClaw는 넓게 연결되는 만큼 다음 문제가 자주 생깁니다.

• 어떤 채널에서 들어온 요청인지 추적이 어렵습니다.
• group chat에서 민감한 답변이 공개됩니다.
• HEARTBEAT.md가 길어져 비용이 커집니다.
• hook이 많아져 실행 순서가 불투명해집니다.
• Gateway 접근 경계가 약합니다.
• workspace와 session이 섞여 엉뚱한 agent가 반응합니다.

대응은 채널별 권한, target 정책, 짧은 HEARTBEAT.md, hook 문서화, Gateway 인증입니다.

공통 실패

둘 다 AI 에이전트이기 때문에 공통 실패도 있습니다.

---

최종 선택 매트릭스

Hermes를 먼저 선택할 사람

다음에 해당하면 Hermes부터 시작하세요.

• 개인 AI 운영자를 키우고 싶다.
• 한 프로젝트를 오래 기억하게 하고 싶다.
• 반복 작업을 스킬로 축적하고 싶다.
• 코드 수정, 테스트, 빌드, 배포 검증을 맡기고 싶다.
• Cron으로 정기 점검을 돌리고 싶다.
• 서브에이전트로 복잡한 분석을 나누고 싶다.
• 연구, MLOps, 문서, 브라우저, 터미널 작업이 많다.

한 문장 결론은 이렇습니다.

내 프로젝트를 오래 맡길 실행형 AI 운영자가 필요하면 Hermes가 먼저입니다.

OpenClaw를 먼저 선택할 사람

다음에 해당하면 OpenClaw부터 시작하세요.

• 여러 메신저와 디바이스를 하나의 AI 허브로 묶고 싶다.
• Telegram, WhatsApp, Slack, Discord, iMessage 같은 채널 접점이 중요하다.
• 팀이나 가족이 각자 다른 채널에서 AI를 호출해야 한다.
• Gateway, session, workspace, hook을 중심으로 운영하고 싶다.
• 모바일에서 상태 확인과 승인 요청을 받고 싶다.
• 생활형 비서와 코딩 비서를 하나의 접점으로 묶고 싶다.

한 문장 결론은 이렇습니다.

내 모든 채팅 채널에 AI 실행 능력을 붙이고 싶으면 OpenClaw가 먼저입니다.

초보자용 선택 기준

아직 잘 모르겠다면 아래처럼 시작하면 됩니다.

---

최종 요약

Hermes와 OpenClaw는 같은 문제를 다른 방향에서 풉니다.

Hermes의 질문은 이것입니다.

AI 에이전트가 어떻게 나를 기억하고, 작업 절차를 배우고, 다음 실행에서 더 잘하게 만들 것인가?

OpenClaw의 질문은 이것입니다.

AI 에이전트를 내가 이미 쓰는 채팅 앱, 디바이스, 팀 채널에 어떻게 안전하게 연결할 것인가?

그래서 결론은 단순합니다.

Hermes는 깊이입니다. 메모리, 스킬, 크론, 서브에이전트, 도구 실행, 검증 루프가 강합니다.

OpenClaw는 연결성입니다. Gateway, channel, session, workspace, hooks, heartbeat가 강합니다.

개인 개발자라면 먼저 Hermes로 프로젝트 운영 루프를 만들고, 필요할 때 OpenClaw를 채널 게이트웨이로 검토하는 순서가 현실적입니다. 반대로 팀 채널, 모바일, 가족/생활형 자동화가 먼저라면 OpenClaw에서 시작하는 편이 자연스럽습니다.

마지막 기준은 이것입니다.

24시간 AI 에이전트의 성패는 모델 성능보다 운영 구조에서 갈립니다. 무엇을 기억하게 할지, 어떤 권한을 줄지, 어디까지 자동화할지, 실패했을 때 어떻게 멈출지를 정한 사람이 더 강한 에이전트를 갖습니다.

---

참고 링크와 업데이트 기준

이 글은 아래 공개 문서를 기준으로 2026년 5월 15일에 다시 정리했습니다.

기능 수, 기본값, 지원 채널은 계속 바뀔 수 있습니다. 하지만 Hermes는 학습형 실행 런타임, OpenClaw는 다채널 게이트웨이라는 큰 차이는 이 글의 핵심 업데이트 기준입니다.