헤르메스 가이드
Hermes vs OpenClaw 구조 비교
헤르메스 가이드

Hermes vs OpenClaw 구조 비교

핵심 판단

Hermes Agent와 OpenClaw의 차이는 채널 수나 설치 명령어가 아니라 아키텍처 철학에서 갈립니다.

  • 아래 목차에서 필요한 절차만 골라 읽으면 됩니다.

겉으로는 둘 다 텔레그램으로 원격 개발을 시키는 AI 에이전트처럼 보이지만, 내부 구조는 완전히 다릅니다. Hermes는 학습하는 에이전트 런타임이고, OpenClaw는 게이트웨이 중심 제품이며 그 안에 Pi 에이전트 코어를 품은 구조입니다.

결론 먼저 — 둘은 무엇이 결정적으로 다른가

Hermes Agent와 OpenClaw는 겉으로 보면 비슷합니다. 둘 다 텔레그램이나 다른 메신저에서 AI에게 일을 시킬 수 있고, 파일을 읽고 쓰고, 명령을 실행하고, 코드를 고치고, 원격 개발을 가능하게 합니다. 그래서 처음 보는 사람은 둘을 같은 카테고리의 경쟁 도구로 이해하기 쉽습니다.

하지만 내부로 들어가면 방향이 완전히 다릅니다.

Hermes Agent는 에이전트 자체가 중심입니다. 에이전트가 어떻게 생각하고, 어떻게 도구를 호출하고, 어떻게 경험을 스킬로 저장하고, 어떻게 사용자를 기억하고, 어떻게 서브에이전트에게 일을 나눠 주는지가 핵심입니다. 메시징 게이트웨이는 그 에이전트를 텔레그램, 디스코드, 슬랙 같은 채널에서 쓰기 위한 입구에 가깝습니다.

OpenClaw는 게이트웨이가 중심입니다. 여러 메시징 채널, 여러 디바이스, 여러 워크스페이스, 여러 에이전트를 하나의 허브로 연결하는 것이 핵심입니다. 그 내부에서 코딩 에이전트 역할을 수행하는 핵심 엔진으로 Pi 계열의 미니멀 코딩 에이전트 철학을 품고 있습니다.

한 줄로 정리하면 다음입니다.

Hermes는 "시간이 지날수록 나를 배우는 에이전트 런타임"이고, OpenClaw는 "내가 쓰는 모든 채널에 AI 실행 능력을 붙이는 게이트웨이 제품"입니다.

이 차이가 메모리, 스킬, 보안, 비용, 자동화, 운영 방식까지 전부 갈라 놓습니다.


비교 전에 알아야 할 전제

둘 다 아직 빠르게 변하는 프로젝트다

AI 에이전트 프레임워크는 변화 속도가 빠릅니다. 기능 수, 지원 채널, 스킬 생태계, 모델 지원, 보안 정책은 몇 주 단위로 바뀔 수 있습니다. 따라서 이 글은 특정 시점의 스냅샷으로 읽어야 합니다. 핵심은 숫자 하나하나보다 설계 방향입니다.

예를 들어 지원 채널이 15개냐 25개냐는 시간이 지나면 바뀔 수 있습니다. 하지만 Hermes가 에이전트 루프와 학습 구조를 중심에 두고, OpenClaw가 게이트웨이와 채널 연결을 중심에 둔다는 점은 훨씬 오래 유지될 구조적 차이입니다.

좋고 나쁨이 아니라 설계 방향이 다르다는 점이 핵심이다

Hermes가 더 낫다, OpenClaw가 더 낫다 식으로 보면 판단이 흐려집니다. 둘은 목표가 다릅니다.

질문Hermes에 가까운 답OpenClaw에 가까운 답
핵심 목표에이전트가 나를 배우고 절차를 축적여러 채널에서 실제 일을 하는 AI 허브
주된 사용자개인 개발자, 연구자, 자동화 운영자다채널 사용자, 팀, 생활 자동화 사용자
강점메모리, 스킬, 서브에이전트, Cron, 연구 루프채널 연결, 게이트웨이, 컴패니언 앱, 라우팅
위험토큰 소비, 복잡도, 공격적 자율성설정 복잡도, 채널별 권한, 게이트웨이 운영

따라서 이 글은 승자를 고르는 글이 아니라, 어떤 상황에서 무엇을 선택해야 하는지를 판단하기 위한 비교입니다.


아키텍처 근본 구조

Hermes Agent — 단일 에이전트 루프 중심

Hermes Agent의 중심에는 하나의 에이전트 루프가 있습니다. CLI에서 호출하든, 텔레그램 게이트웨이에서 호출하든, 배치 작업으로 실행하든, 결국 동일한 에이전트 코어가 대화를 처리합니다.

구조를 단순화하면 다음과 같습니다.

순서Hermes 처리 흐름
1사용자 입력
2프롬프트 빌더
3모델 API 호출
4도구 호출 판단
5파일/터미널/브라우저/검색/메모리/스킬 도구 실행
6결과를 다시 모델에 전달
7최종 답변 저장 및 전달

Hermes에서 중요한 것은 "어떤 채널로 들어왔는가"가 아닙니다. 중요한 것은 이 입력이 에이전트 루프 안에서 어떻게 해석되고, 어떤 도구를 쓰고, 어떤 기억과 스킬을 남기는가입니다.

이 구조의 장점은 일관성입니다. 텔레그램에서 시키든 CLI에서 시키든 같은 에이전트가 같은 방식으로 일합니다. 단점은 코어가 커질수록 내부 복잡도가 높아지고, 토큰과 도구 체계가 무거워질 수 있다는 점입니다.

OpenClaw — 게이트웨이 중심

OpenClaw의 중심은 에이전트 루프라기보다 게이트웨이입니다. 게이트웨이는 여러 메시징 플랫폼을 연결하고, 메시지를 받아 어느 에이전트/세션/워크스페이스로 보낼지 결정합니다.

구조를 단순화하면 다음과 같습니다.

순서OpenClaw 처리 흐름
1Telegram / WhatsApp / Slack / Discord / iMessage / 기타 채널
2OpenClaw Gateway
3세션/워크스페이스/에이전트 라우팅
4내부 에이전트 실행(Pi 계열 코어)
5도구 실행 및 결과 스트리밍
6원래 채널로 응답 반환

OpenClaw에서 중요한 것은 "AI가 무엇을 생각하는가"만이 아닙니다. 더 중요한 것은 이 AI를 어떤 채널, 어떤 사용자, 어떤 워크스페이스, 어떤 권한으로 연결할 것인가입니다.

이 구조의 장점은 실사용 연결성입니다. 여러 채널과 디바이스를 묶는 데 강합니다. 단점은 게이트웨이, 세션, 채널, 권한 설정이 늘어나며 운영 복잡도가 올라갈 수 있다는 점입니다.

구조 비교표

항목Hermes AgentOpenClaw
중심축에이전트 루프게이트웨이
주 언어Python 중심TypeScript / Node.js 중심
진입점CLI, Gateway, API, Batch, ACP 등Gateway RPC, CLI, 채널 어댑터
내부 에이전트자체 에이전트 코어Pi 계열 미니멀 에이전트 코어 임베딩 철학
설계 감각에이전트 런타임AI 연결 인프라
잘 맞는 일반복 개발, 장기 운영, 자동화 루프다채널 비서, 팀/채널 라우팅, 생활 자동화

에이전트 루프 내부 동작

Hermes의 턴 처리 방식

Hermes의 한 턴은 비교적 엄격한 흐름을 따릅니다.

  1. 사용자 메시지를 받습니다.
  2. 시스템 프롬프트를 조립합니다.
  3. 메모리, 사용자 프로필, 스킬 목록, 프로젝트 컨텍스트를 주입합니다.
  4. 모델 API 형식에 맞게 메시지를 변환합니다.
  5. 모델이 도구 호출을 요청하면 도구를 실행합니다.
  6. 도구 결과를 다시 모델에 전달합니다.
  7. 최종 답변을 저장하고 사용자에게 보냅니다.

여기서 핵심은 도구가 매우 중요하게 설계되어 있다는 것입니다. Hermes는 파일 읽기/쓰기, 패치, 터미널, 브라우저, 세션 검색, 메모리, 스킬 관리, 크론, 메시지 전송, 이미지 분석 등 다양한 도구를 에이전트 루프 안에 넣습니다.

즉 Hermes의 LLM은 혼자 답하는 모델이 아니라, 도구 호출을 통해 실제 환경을 조작하는 운영자입니다.

도구 병렬 실행과 서브 작업

Hermes는 단일 도구 호출은 순차적으로 처리하고, 여러 도구 호출이나 독립 작업은 병렬화할 수 있습니다. 특히 delegate_task 같은 도구는 별도 에이전트 인스턴스를 만들어 조사나 코드 분석을 나눠 맡길 수 있습니다.

예를 들어 다음과 같은 작업이 가능합니다.

  • 한 서브에이전트는 프론트엔드 구조 분석
  • 다른 서브에이전트는 API 구조 분석
  • 또 다른 서브에이전트는 테스트 실패 원인 분석
  • 부모 에이전트는 결과 요약만 받아 최종 판단

이 구조는 복잡한 코드베이스 분석이나 긴 리서치에 강합니다.

OpenClaw의 턴 처리 방식

OpenClaw는 게이트웨이가 먼저 요청을 받습니다. 그리고 어떤 세션, 어떤 워크스페이스, 어떤 에이전트로 보낼지 결정합니다. 에이전트 실행은 즉시 완료되는 것이 아니라 runId를 만들고, 외부 클라이언트가 진행 상태를 기다리거나 스트리밍으로 받을 수 있는 형태에 가깝습니다.

OpenClaw의 핵심 포인트는 세션 직렬화입니다. 같은 세션 키에 대해 여러 작업이 동시에 엉키지 않도록 런을 순서대로 처리합니다. 파일 기반 워크스페이스와 여러 채널이 얽히는 구조에서는 이것이 중요합니다.

Hermes는 하나의 에이전트 루프 안에서 작업이 순차적으로 이어지는 감각이 강하고, OpenClaw는 게이트웨이가 여러 요청과 세션을 조율하는 감각이 강합니다.


Pi 에이전트 코어 — OpenClaw를 이해하는 핵심

OpenClaw를 제대로 이해하려면 Pi 계열 에이전트 철학을 이해해야 합니다. Pi는 미니멀한 코딩 에이전트로 알려져 있으며, 핵심 도구를 아주 적게 가져가는 방향을 택합니다.

Pi의 미니멀 도구 철학

Pi의 기본 발상은 단순합니다.

에이전트에게 수십 개의 특수 도구를 주기보다, 읽기·쓰기·수정·명령 실행 같은 기본 도구를 주고 필요하면 스스로 코드를 쓰게 한다.

이 철학에서는 많은 MCP나 복잡한 외부 도구보다, 에이전트가 직접 코드를 작성하고 실행하며 자신의 능력을 확장하는 것이 중요합니다.

대표적인 코어 도구는 다음처럼 이해할 수 있습니다.

도구역할
Read파일이나 정보를 읽음
Write새 파일을 작성
Edit기존 파일을 수정
Bash명령 실행

이 네 가지가 있으면 코딩 에이전트는 많은 일을 할 수 있습니다. 부족한 기능이 있으면 새 스크립트를 쓰고 실행하면 됩니다.

Hermes와 정반대인 지점

Hermes는 처음부터 많은 도구와 운영 기능을 갖춘 에이전트입니다. 메모리 도구, 스킬 도구, 브라우저 도구, 크론 도구, 메시지 도구 등 기능이 넓게 준비되어 있습니다.

Pi/OpenClaw 철학은 더 미니멀합니다. 기본 도구는 적게 두고, 에이전트가 필요하면 스스로 코드를 써서 해결하게 합니다.

둘의 차이는 이렇게 비유할 수 있습니다.

비유HermesOpenClaw / Pi
작업장이미 공구가 많이 갖춰진 정비소망치, 톱, 드릴을 들고 필요한 공구를 직접 만드는 작업자
학습 방식성공 절차를 스킬 문서로 축적필요한 기능을 코드로 작성해 확장
강점운영 안정성, 절차화, 재사용단순성, 투명성, 자기 확장성
위험시스템이 무거워질 수 있음구조화된 기억이 부족할 수 있음

스킬 시스템 — 구조화된 절차 기억 vs 코드로 자기 확장

Hermes의 스킬 시스템

Hermes의 스킬은 단순한 메모가 아닙니다. 에이전트가 필요할 때 로드하는 절차적 지식입니다.

스킬은 보통 이런 구조를 가집니다.

스킬 문서 구성설명
언제 사용할지이 스킬을 로드해야 하는 상황
필요 조건필요한 명령, 계정, 환경변수, 파일
실행 절차사람이 따라도 재현 가능한 단계
주의할 함정이전에 막혔던 지점과 우회법
검증 방법성공 여부를 확인하는 명령과 기준
관련 파일 또는 스크립트템플릿, 참고 자료, 자동화 스크립트

Hermes는 스킬을 단계적으로 로드합니다.

단계내용목적
Level 0스킬 이름과 설명 목록어떤 스킬이 있는지 파악
Level 1전체 SKILL.md실제 절차 확인
Level 2연결 파일, 템플릿, 스크립트필요한 세부 자료만 로드

이 방식은 토큰을 아끼기 위한 장치입니다. 모든 스킬 전문을 매번 넣으면 컨텍스트가 터집니다. 그래서 처음에는 목록만 보고, 필요할 때만 깊게 들어갑니다.

Hermes가 스스로 스킬을 만드는 이유

Hermes의 가장 중요한 특징 중 하나는 에이전트가 스킬을 직접 만들고 고칠 수 있다는 것입니다. 예를 들어 어떤 프로젝트에서 Vercel 배포 실패를 세 번 조사한 끝에 "Git author가 Vercel 팀 권한을 가져야 한다"는 교훈을 얻었다면, 이 절차를 스킬이나 실무 절차 기록으로 남길 수 있습니다.

이것이 Hermes가 "학습하는 에이전트"라고 불리는 이유입니다. 모델 가중치가 즉시 바뀌는 것은 아니지만, 절차적 기억이 축적됩니다. 다음에는 같은 실수를 덜 합니다.

OpenClaw의 스킬

OpenClaw도 스킬을 가질 수 있습니다. 하지만 철학은 Hermes와 다릅니다. OpenClaw의 스킬은 워크스페이스 안의 정적 마크다운에 가깝고, 사용자가 직접 작성하거나 설치하는 성격이 강합니다.

OpenClaw/Pi 쪽의 더 근본적인 발상은 "스킬 문서를 자동으로 축적하자"보다 "필요한 기능을 에이전트가 코드로 만들게 하자"에 가깝습니다.

따라서 반복 운영에는 Hermes의 스킬 축적 방식이 유리하고, 투명한 파일 기반 커스터마이징과 자기 확장 실험에는 OpenClaw/Pi 방식이 매력적입니다.


메모리 아키텍처

Hermes의 다층 메모리

Hermes의 메모리는 여러 층으로 나뉩니다.

첫째, 항상 주입되는 핵심 메모리입니다. 사용자의 선호, 환경 정보, 프로젝트 규칙처럼 매번 필요한 정보를 짧게 저장합니다.

둘째, 세션 검색입니다. 과거 대화 전체를 검색해서 "지난번에 이 문제 어떻게 해결했지?"에 답할 수 있습니다.

셋째, 외부 메모리 프로바이더입니다. Honcho 같은 시스템을 붙이면 사용자 모델링을 더 깊게 할 수 있습니다.

쉽게 말하면 Hermes는 다음을 동시에 하려 합니다.

  • 지금 꼭 필요한 사실은 항상 기억
  • 과거 대화는 검색 가능하게 보관
  • 사용자 성향과 반복 패턴은 장기적으로 모델링

OpenClaw의 파일 기반 메모리

OpenClaw는 더 단순하고 투명한 방식입니다. 워크스페이스 안의 마크다운 파일이 기억의 중심입니다.

예를 들어 다음 같은 파일들이 쓰입니다.

파일 예시역할
AGENTS.md프로젝트 또는 워크스페이스 지시
SOUL.md에이전트 성격과 기본 행동
TOOLS.md사용 가능한 도구 설명
MEMORY.md장기 기억 또는 핵심 메모
memory/2026-04-26.md날짜별 작업 로그

이 방식의 장점은 분명합니다. 사람이 열어 보기 쉽고, Git으로 버전 관리하기 쉽고, 숨은 데이터베이스를 이해할 필요가 없습니다.

반면 단점도 있습니다. 자동 검색, 자동 요약, 사용자 모델링, 세션 리니지 추적 같은 기능은 Hermes보다 약할 수 있습니다.

메모리 비교표

차원HermesOpenClaw
저장 방식마크다운 + SQLite 검색 + 선택적 외부 메모리마크다운 파일 중심
강점장기 검색, 사용자 모델링, 자동 큐레이션투명성, 단순함, Git 관리
약점내부 구조가 복잡검색/요약/모델링은 수동 성격이 강함
잘 맞는 경우장기 프로젝트, 반복 업무, 세션 누적명시적 워크스페이스 관리, 팀이 파일로 검토

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

Hermes의 서브에이전트 위임

Hermes는 delegate_task를 통해 완전히 분리된 자식 에이전트를 만들 수 있습니다. 이 자식 에이전트는 부모 대화 전체를 그대로 받지 않습니다. 필요한 목표와 컨텍스트만 전달받고, 별도 세션에서 작업한 뒤 최종 요약만 돌려줍니다.

이 방식은 복잡한 작업에서 강합니다.

예를 들어 "프로젝트 전체 분석"을 한다면:

  • 에이전트 A: DB와 schema 분석
  • 에이전트 B: 프론트엔드 route 분석
  • 에이전트 C: 테스트와 배포 구조 분석
  • 부모 에이전트: 세 결과를 합쳐 운영 보고서 작성

이렇게 분할할 수 있습니다.

장점은 병렬성과 토큰 효율입니다. 단점은 부모가 컨텍스트를 잘 전달하지 않으면 자식이 엉뚱한 방향으로 갈 수 있다는 점입니다.

OpenClaw의 멀티에이전트 라우팅

OpenClaw의 멀티에이전트는 조금 다릅니다. 게이트웨이 레벨에서 채널, 계정, 상대방, 워크스페이스에 따라 다른 에이전트를 라우팅하는 데 강합니다.

예를 들어:

  • 텔레그램 개인 DM → 코딩 에이전트
  • 슬랙 팀 채널 → 업무 요약 에이전트
  • 이메일 → 일정/메일 정리 에이전트
  • iMessage → 개인 비서 에이전트

이런 구성이 자연스럽습니다.

Hermes의 멀티에이전트가 "작업을 쪼개는 내부 위임"에 가깝다면, OpenClaw의 멀티에이전트는 "실세계 채널을 나눠 맡기는 라우팅"에 가깝습니다.


프롬프트와 컨텍스트 관리

Hermes — 안정적인 시스템 프롬프트

Hermes는 시스템 프롬프트 안정성을 중요하게 봅니다. 성격, 메모리, 스킬 목록, 프로젝트 컨텍스트, 도구 가이드를 조립해 시스템 프롬프트를 만들고, 가능한 한 대화 중간에는 큰 구조를 흔들지 않습니다.

이유는 두 가지입니다.

첫째, 모델 행동을 예측하기 쉬워집니다. 둘째, 프롬프트 캐싱 같은 최적화에 유리합니다.

또한 Hermes는 컨텍스트가 커지면 압축을 시도합니다. 모든 과거 메시지를 계속 들고 가는 대신, 핵심 요약과 최근 메시지를 남기는 방식입니다.

OpenClaw — 워크스페이스 부트스트랩

OpenClaw는 워크스페이스 파일과 훅을 통해 컨텍스트를 구성하는 성격이 강합니다. AGENTS.md, SOUL.md, 스킬 파일, 부트스트랩 훅이 에이전트 행동에 영향을 줍니다.

이 방식은 투명합니다. 사람이 파일을 열어 "이 에이전트가 왜 이렇게 행동하는지" 확인하기 쉽습니다. 다만 많은 채널과 에이전트를 운영하면 각 워크스페이스의 지시가 어떻게 섞이는지 관리가 필요합니다.


보안 모델

Hermes의 보안 감각

Hermes는 실행 환경 격리에 강하게 투자합니다. Docker, SSH, Modal, Daytona 같은 여러 백엔드에서 작업을 분리할 수 있고, 위험 명령 승인, 스킬 보안 검사, 컨텍스트 파일 인젝션 방어 같은 장치가 있습니다.

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

이 에이전트가 실제 명령을 어디에서 실행하고, 그 환경은 얼마나 격리되어 있는가?

그래서 Docker나 별도 작업 폴더 전략이 중요합니다. AI가 실수해도 피해가 작업 공간 안에 갇히도록 설계해야 합니다.

OpenClaw의 보안 감각

OpenClaw는 게이트웨이와 채널이 많기 때문에 다른 보안 문제가 중요합니다.

  • 이 메시지를 보낸 사람이 누구인가?
  • 이 채널에서 어떤 권한을 줄 것인가?
  • 이 디바이스가 할 수 있는 일은 어디까지인가?
  • 어떤 작업은 사람 승인을 받아야 하는가?
  • 세션과 워크스페이스가 서로 섞이지 않는가?

즉 OpenClaw의 보안은 채널, 권한, 라우팅, 세션 격리의 문제입니다.

보안 비교표

보안 질문HermesOpenClaw
실행 환경 격리강함, 여러 백엔드Docker/SSH/OpenShell 중심
채널 권한지원하나 핵심은 에이전트게이트웨이 중심이라 매우 중요
위험 명령 승인중요중요
스킬 설치 보안스캐닝 강조before_install 등 훅/정책 중심
추천 운영작업 폴더 최소화, Docker 우선채널별 권한, 페어링, 워크스페이스 분리

확장성과 플러그인

Hermes의 확장 방식

Hermes의 확장은 크게 세 방향입니다.

  1. 스킬 추가
  2. 플러그인 추가
  3. 외부 메모리/컨텍스트 프로바이더 교체

스킬은 절차 지식입니다. 플러그인은 기능 확장입니다. 메모리 프로바이더는 기억 방식을 바꿉니다.

Hermes는 특히 스킬 생태계와 자동 스킬 생성이 중요합니다. 오래 쓸수록 내 작업 방식에 맞는 절차 라이브러리가 쌓입니다.

OpenClaw의 확장 방식

OpenClaw는 훅과 워크스페이스, 채널 어댑터, Pi 확장 철학이 중요합니다. 요청이 들어오기 전, 모델을 고르기 전, 프롬프트를 만들기 전, 도구 호출 전후, 응답 반환 전 등 다양한 지점에서 훅을 걸 수 있습니다.

이 구조는 제품 통합에 강합니다. 특정 채널에서 들어온 메시지는 특정 정책을 적용하고, 특정 도구 결과는 저장 전에 변환하고, 특정 사용자에게는 다른 모델을 쓰게 하는 식의 확장이 가능합니다.


프로액티브 자동화 — Cron vs Heartbeat

Hermes Cron

Hermes의 Cron은 예약된 에이전트 작업입니다. 단순히 shell script를 주기 실행하는 것이 아니라, 정해진 시간에 새 에이전트 세션을 열고 작업을 수행합니다.

예:

  • 매일 아침 프로젝트 상태 점검
  • 30분마다 RSS 새 글 확인
  • 4시간마다 실패한 Q&A job 확인
  • 밤 12시에 운영 리포트 작성
  • 특정 스킬을 로드하고 정해진 작업 실행

Hermes Cron은 "예약된 작업"에 강합니다.

OpenClaw Heartbeat

OpenClaw의 Heartbeat는 "일정 간격으로 깨어나서 확인할 것이 있는지 본다"는 패턴에 가깝습니다. 이메일, 캘린더, 메시지, 알림처럼 실생활 이벤트가 바뀌었을 때 사용자에게 알려주는 데 잘 맞습니다.

둘의 차이는 이렇게 정리할 수 있습니다.

기능Hermes CronOpenClaw Heartbeat
핵심 질문정해진 작업을 언제 실행할까?지금 사용자에게 알려야 할 변화가 있나?
잘 맞는 일개발 점검, 리포트, 배치 작업이메일/일정/알림/생활형 감시
실행 성격새 에이전트 작업주기적 깨어남과 판단

실사용 관점의 장단점

Hermes가 편한 순간

Hermes는 이런 순간에 강합니다.

  • "이 프로젝트 운영 담당으로 계속 기억해 줘"
  • "지난번처럼 lint/test/build 돌리고 push해"
  • "비슷한 작업을 스킬로 저장해"
  • "서브에이전트 여러 개로 나눠서 조사해"
  • "정해진 시간마다 상태 점검해"
  • "내가 이전에 말한 선호와 프로젝트 규칙을 기억해"

즉 장기 운영과 반복 작업에 강합니다.

OpenClaw가 편한 순간

OpenClaw는 이런 순간에 강합니다.

  • "텔레그램뿐 아니라 WhatsApp, Slack, iMessage까지 연결하고 싶어"
  • "채널마다 다른 에이전트를 붙이고 싶어"
  • "팀이 함께 쓰는 게이트웨이를 만들고 싶어"
  • "모바일/데스크톱 컴패니언 앱이 필요해"
  • "생활 비서와 코딩 비서를 한 허브에서 운영하고 싶어"

즉 실생활 채널 연결과 게이트웨이 운영에 강합니다.

토큰과 비용 감각

Hermes는 더 많은 컨텍스트를 앞에 싣는 경향이 있습니다. 그래서 한 번에 잘 처리하는 확률이 올라가지만, 토큰 비용이 커질 수 있습니다.

OpenClaw는 기본적으로 더 조심스럽고, 채널 중심으로 일을 나눠 처리하는 감각이 강합니다. 확인 질문이 많을 수 있지만 비용과 권한 통제에는 유리할 수 있습니다.

실전에서는 둘 다 설정에 따라 달라집니다. Hermes도 가볍게 만들 수 있고, OpenClaw도 공격적으로 만들 수 있습니다. 다만 기본 철학은 다릅니다.


선택 기준 — 어떤 사람에게 무엇이 맞나

Hermes를 먼저 선택할 사람

다음에 해당하면 Hermes가 더 맞습니다.

  • 코딩, 리서치, 문서, 배포 점검을 한 에이전트에게 계속 맡기고 싶다
  • 에이전트가 내 프로젝트를 기억하고 성장했으면 좋겠다
  • 반복 작업을 스킬로 쌓아 재사용하고 싶다
  • 서브에이전트 병렬 조사와 작업 분할이 필요하다
  • Cron으로 주기적인 운영 점검을 돌리고 싶다
  • Python 기반 도구와 연구/평가 파이프라인에 관심이 있다

한 문장으로:

"내 개인 AI 운영자를 키우고 싶다"면 Hermes가 맞습니다.

OpenClaw를 먼저 선택할 사람

다음에 해당하면 OpenClaw가 더 맞습니다.

  • 여러 메신저와 디바이스를 하나의 AI 허브로 묶고 싶다
  • WhatsApp, iMessage, Slack, Discord, Telegram 등 채널 연결이 중요하다
  • 팀/채널/워크스페이스별로 에이전트를 나누고 싶다
  • 파일 기반 워크스페이스와 명시적 설정을 선호한다
  • 컴패니언 앱, Live Canvas, 게이트웨이 중심 제품 경험이 필요하다
  • 생활형 비서와 코딩 자동화를 같이 묶고 싶다

한 문장으로:

"내 모든 채팅 채널에 실제 일을 하는 AI를 붙이고 싶다"면 OpenClaw가 맞습니다.

둘 다 쓰는 전략

둘을 꼭 하나만 골라야 하는 것은 아닙니다. 고급 사용자는 역할을 나눌 수 있습니다.

추천 조합:

역할추천
개인 개발 운영자Hermes
다채널 메시징 허브OpenClaw
반복 작업 절차 축적Hermes
생활형 알림/채널 라우팅OpenClaw
장기 프로젝트 기억Hermes
팀/가족/여러 채널 연결OpenClaw

초보자라면 하나만 시작하세요. 개인 개발 자동화가 목표면 Hermes, 채널 통합 비서가 목표면 OpenClaw가 출발점입니다.


최종 요약표

차원Hermes AgentOpenClaw
핵심 정체성학습하는 에이전트 런타임메시징 게이트웨이 기반 AI 어시스턴트
설계 중심에이전트 루프Gateway
내부 철학경험을 스킬과 메모리로 축적채널과 워크스페이스에 AI 실행 능력 연결
에이전트 코어자체 Python 에이전트 루프Pi 계열 미니멀 코딩 에이전트 철학 임베딩
기본 도구 감각많은 도구와 툴셋적은 코어 도구 + 확장
스킬자동 생성/수정 가능한 절차 기억정적 파일/허브 설치 중심
메모리마크다운 + SQLite 검색 + 외부 메모리 가능파일 기반 워크스페이스 메모리
서브에이전트격리된 자식 에이전트 병렬 위임게이트웨이 라우팅 + 세션/워크스페이스 분리
자동화Cron 기반 예약 에이전트 작업Heartbeat 기반 주기적 깨어남
보안 초점실행 환경 격리, 도구 승인, 스킬 스캔채널 권한, 페어링, 워크스페이스 격리
강한 영역장기 개인 운영, 반복 개발, 자동 스킬화다채널 비서, 팀/채널 라우팅, 실생활 연결
약한 영역토큰 비용과 내부 복잡도장기 학습/절차 기억 자동화

운영자 관점 결론

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

Hermes는 이렇게 묻습니다.

에이전트가 어떻게 하면 나를 기억하고, 작업 절차를 배우고, 시간이 지날수록 더 잘할 수 있을까?

OpenClaw는 이렇게 묻습니다.

AI가 어떻게 하면 내가 이미 쓰는 모든 채팅 앱과 디바이스에서 실제 일을 할 수 있을까?

그래서 결정적 차이는 기능표가 아니라 철학입니다.

Hermes는 에이전트를 키우는 도구입니다. OpenClaw는 에이전트를 연결하는 도구입니다. Hermes는 깊이를 추구하고, OpenClaw는 연결성을 추구합니다. Hermes는 장기 기억과 절차적 성장에 강하고, OpenClaw는 다채널 게이트웨이와 실생활 통합에 강합니다.

개인 개발자에게 가장 현실적인 결론은 다음입니다.

  1. 먼저 Hermes로 내 프로젝트 운영 루프를 만든다.
  2. Telegram으로 원격 지시, Git, 테스트, 빌드, 배포 점검을 안정화한다.
  3. 반복되는 작업을 스킬과 실무 절차 기록으로 축적한다.
  4. 이후 여러 채널과 생활 자동화가 필요해지면 OpenClaw를 게이트웨이로 검토한다.

반대로 팀, 가족, 여러 메신저, 모바일 앱, 생활형 자동화가 먼저라면 OpenClaw에서 시작하는 것이 더 자연스럽습니다.

마지막으로 가장 중요한 운영 원칙은 이것입니다.

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

Hermes와 OpenClaw의 차이는 바로 그 운영 구조를 어느 방향에서 설계하느냐의 차이입니다.

Hermes vs OpenClaw 구조 비교 | VibeCoding 365