🪽 Hermes 01. OpenClaw와 무엇이 다른가

Hermes 시리즈는 설치법부터 들어가지 않는다. 먼저 이 도구가 무엇을 중심에 두고 설계됐는지를 잡는 편이 이후 설정이 훨씬 쉬워지기 때문이다. 특히 Hermes를 OpenClaw와 같은 선상에서 볼 때, 둘은 겉보기보다 성격 차이가 크다.

공식 문서를 기준으로 보면, Hermes는 스스로 배우고 자라나는 에이전트 경험을 전면에 내세우고, OpenClaw는 여러 채널과 디바이스를 한 게이트웨이로 묶는 개인 비서 인프라에 더 가깝다. 이 차이를 먼저 잡아 두면, 이후 설치, 기본 사용, 텔레그램 연결, llm-wiki, Obsidian, Gboard 연동 흐름도 훨씬 선명해진다.

안내: 이 글은 공식 문서와 공식 저장소를 중심으로 작성했고, 커뮤니티·이슈 반응은 별도 보강 섹션에서 분리해 다뤘습니다. 구조화와 문장 정리에 생성형 AI를 보조적으로 활용했습니다.

이 시리즈를 어떻게 볼까

이 시리즈는 앞으로 아래 순서로 이어질 예정이다.

01 무엇이 다른가, 제품 성격 파악
02 설치와 첫 실행
03 모델 선택과 기본 설정
04 텔레그램 연결
05 llm-wiki와 지식 정리 흐름
06 Obsidian과 메모리 운용
07 Gboard를 활용한 Telegram 입력 루틴

즉, 이번 글은 단순 비교가 아니라 이후 실전 셋업의 기준점을 만드는 글이다.

한눈에 보는 결론

Hermes가 더 잘 맞는 경우: 메모리, 스킬 진화, 모델 교체, 원격/로컬 백엔드 유연성, 장기적으로 “학습하는 에이전트”를 키우는 경험이 중요할 때
OpenClaw가 더 잘 맞는 경우: Telegram, WhatsApp, Discord, Slack 같은 실제 채널 연결, 모바일 노드, Canvas, 채널 라우팅, 운영형 자동화가 중요할 때
가장 큰 차이 한 줄: Hermes는 에이전트 자체의 학습 루프, OpenClaw는 게이트웨이와 채널 운영 구조가 더 선명하다

flowchart LR
A[무엇을 원하나] --> B{중심이 학습형 agent인가\n채널형 assistant인가}
B -->|학습형 agent| C[Hermes]
B -->|채널형 assistant| D[OpenClaw]
C --> E[메모리 고도화]
C --> F[스킬 자동화]
C --> G[모델과 백엔드 유연성]
D --> H[멀티채널 게이트웨이]
D --> I[모바일 노드와 Canvas]
D --> J[세션 라우팅과 운영 자동화]

빠른 비교표

항목	Hermes Agent	OpenClaw
공식 한 줄 정의	self-improving AI agent	self-hosted gateway + personal AI assistant
핵심 중심축	학습 루프, 메모리, 스킬 진화	채널 게이트웨이, 노드, Canvas, 라우팅
시작 방식	원라인 설치 후 `hermes`, `hermes --tui`, `hermes gateway`	`npm install -g openclaw`, `openclaw onboard --install-daemon`
주요 인터페이스	CLI, TUI, 메시징 게이트웨이	채팅 앱, Web Control UI, macOS 앱, iOS/Android nodes
메모리 철학	bounded curated memory + session search + external memory providers	Markdown 파일 기반 메모리 + dreaming + memory search
스킬 철학	on-demand knowledge docs, agent-managed skills	AgentSkills 기반 skill folders + ClawHub + per-agent allowlist
자동화	unified cronjob tool, skill-backed scheduled jobs	Gateway 내장 cron, announce/webhook, isolated/custom sessions
멀티에이전트	서브에이전트와 병렬 실행 강조	gateway 차원의 multi-agent routing을 강하게 문서화
보안 관점	defense-in-depth, dangerous command approval, container isolation	personal assistant trust model, DM pairing, security audit, sandboxing
마이그레이션	`hermes claw migrate`로 OpenClaw 자산 가져오기 지원	공식 문서상 Hermes로의 역방향 마이그레이션 문구는 확인 못함

1. 제품 정의부터 다르다

Hermes 공식 저장소는 스스로를 **“The self-improving AI agent”**로 소개한다. README와 문서에는 built-in learning loop, skills self-improve, persistent memory, cross-session recall, user modeling, cron scheduling, subagents가 핵심 축으로 반복된다. 즉, 사용하면서 더 나아지는 에이전트라는 이야기가 제품 소개의 중심이다.

Hermes 공식 저장소: https://github.com/nousresearch/hermes-agent
Hermes 문서 허브: https://hermes-agent.nousresearch.com/docs/

반대로 OpenClaw 공식 문서는 첫 페이지부터 **“self-hosted gateway”**라는 표현을 강하게 건다. 여러 채팅 앱과 채널 플러그인, Web Control UI, mobile nodes, Canvas, routing을 하나의 Gateway가 묶는 구조가 핵심이다. 여기서 중요한 건 “에이전트가 얼마나 진화하느냐”보다 “실제 생활 채널과 디바이스에 어떻게 붙느냐”다.

OpenClaw Docs 홈: https://docs.openclaw.ai
OpenClaw 저장소: https://github.com/openclaw/openclaw

이 차이 때문에 첫인상도 갈린다. Hermes는 하나의 똑똑한 agent operating system처럼 느껴지고, OpenClaw는 assistant control plane처럼 느껴진다.

2. 설치와 런타임도 보는 방향이 다르다

Hermes는 Quickstart에서 원라인 설치 스크립트를 먼저 제시한다. Linux, macOS, WSL2, Android Termux를 안내하고, Windows는 WSL2 사용을 권장한다. 또 모델 선택에서 최소 64K 컨텍스트를 요구하며, Nous Portal, OpenRouter, OpenAI, Anthropic, Gemini, Copilot, 커스텀 엔드포인트까지 넓은 provider 선택을 전면에 둔다.

OpenClaw는 Getting Started와 홈 문서에서 npm install -g openclaw@latest 뒤 openclaw onboard --install-daemon을 권장한다. 런타임은 Node 24 권장, Node 22 LTS 호환을 명시하고, 텔레그램 같은 채널 연결과 Gateway 구동을 빠르게 시작하는 흐름에 가깝다.

여기서 느껴지는 차이는 단순하다.

Hermes는 “어떤 모델·백엔드를 쓸지”가 시작점에 가깝고
OpenClaw는 “어떤 채널·게이트웨이 구조로 붙일지”가 시작점에 가깝다

3. 인터페이스 전략은 OpenClaw가 더 넓고, Hermes는 더 일관적이다

Hermes는 공식 문서 기준으로 CLI, TUI, 메시징 게이트웨이를 기본 축으로 잡는다. TUI는 멀티라인 입력, 대화 이력, 중단 후 재지시 같은 터미널 경험을 강조하고, 게이트웨이는 Telegram, Discord, Slack, WhatsApp, Signal, Email, Home Assistant 같은 표면으로 확장된다.

Hermes Quickstart: https://hermes-agent.nousresearch.com/docs/getting-started/quickstart

OpenClaw는 이보다 인터페이스 층이 더 넓다. Features와 홈 문서를 보면 채널 자체도 많고, 여기에 Web Control UI, macOS companion app, iOS/Android nodes, Canvas, camera, voice workflows가 붙는다. 즉, OpenClaw는 메시징 bot을 넘어서 디바이스와 시각 인터페이스까지 묶는 구조가 문서에서 선명하다.

OpenClaw Features: https://docs.openclaw.ai/concepts/features

실전 감각으로 풀면 이렇다.

“터미널과 게이트웨이에서 같은 에이전트를 키우고 싶다”면 Hermes 쪽 설명이 더 곧다.
“폰, 채팅앱, 웹 UI, 노드, Canvas를 한데 엮고 싶다”면 OpenClaw 쪽 그림이 훨씬 크다.

4. 메모리 철학은 둘 다 강하지만 방법이 다르다

Hermes의 Persistent Memory 문서는 메모리를 아주 명시적으로 관리한다. MEMORY.md와 USER.md 두 파일을 두고, 글자 수 한도까지 공개한다. 메모리는 세션 시작 시 시스템 프롬프트에 frozen snapshot으로 들어가며, 세션 중 변경은 디스크에 즉시 반영되지만 다음 세션부터 다시 프롬프트에 반영된다. 여기에 session search와 external memory providers 연결까지 이어진다.

OpenClaw의 Memory Overview는 정반대로 **“숨은 상태는 없고, 기억은 디스크의 Markdown 파일에 적힌 것뿐”**이라는 점을 전면에 둔다. MEMORY.md, memory/YYYY-MM-DD.md, 선택적 DREAMS.md가 기본이고, memory_search, memory_get, dreaming, grounded backfill, memory wiki 같은 구조가 이어진다. 특히 Dreaming은 background memory consolidation을 문서로 자세히 설명한다.

둘 다 강력하지만 느낌이 다르다.

Hermes는 제한된 curated memory + live search 확장에 가깝고
OpenClaw는 파일로 보이는 기억 + 후처리/승격 시스템에 가깝다

미니 사례 1, 메모리를 “제품 기능”으로 볼지 “운영 파일”로 볼지

예를 들어 사용자의 말투, 프로젝트 규칙, 서버 습관을 오래 기억시키고 싶다면 Hermes는 memory limits와 tool actions이 명확해서 운영 규칙을 잡기 쉽다. 반대로 “기억을 사람이 직접 열어 보고, markdown으로 관리하고, 꿈꾸기(dreaming) 같은 후처리도 검토하고 싶다”면 OpenClaw가 더 잘 맞는다.

검증 기준도 다르다.

Hermes: memory entry가 시스템 프롬프트 스냅샷에 어떻게 들어가는지, session search가 어떻게 보강하는지 확인
OpenClaw: 실제 MEMORY.md, memory/YYYY-MM-DD.md, DREAMS.md가 어떻게 쌓이는지 확인

5. 스킬 시스템은 Hermes가 절약형 로딩, OpenClaw가 배치형 운영에 가깝다

Hermes의 Skills System은 progressive disclosure를 핵심으로 둔다. 필요할 때만 skill을 더 깊게 불러오고, ~/.hermes/skills/를 단일 source of truth로 본다. 또 agent-managed skills, 즉 에이전트가 작업 후 스스로 skill을 만들고 고칠 수 있다는 이야기를 크게 건다.

OpenClaw의 Skills는 AgentSkills 호환 skill folders, 로딩 우선순위, per-agent skill allowlists, ClawHub, plugin skills, sandbox 주의사항을 아주 운영적으로 설명한다. 즉, skills를 agent 학습 산출물이라기보다 워크스페이스와 에이전트별로 배치하고 통제하는 자산으로 다루는 느낌이 강하다.

Hermes Skills: https://hermes-agent.nousresearch.com/docs/user-guide/features/skills
OpenClaw Skills: https://docs.openclaw.ai/tools/skills

이 차이는 실제 운영에서도 크게 느껴진다.

Hermes는 skill이 agent의 절차 기억처럼 느껴지고
OpenClaw는 skill이 workspace 기반 운영 구성품처럼 느껴진다

6. 자동화는 둘 다 강하지만, OpenClaw가 운영 옵션을 더 세세하게 깐다

Hermes의 Scheduled Tasks는 cronjob tool 하나로 create, edit, pause, resume, run, remove를 다루고, job에 여러 skill을 붙일 수 있다고 설명한다. fresh session, gateway daemon, delivery target, silent suppression 같은 흐름도 잘 정리돼 있다.

OpenClaw의 Scheduled Tasks는 Gateway 내부 scheduler, jobs.json persistence, main/current/isolated/custom session 스타일, announce/webhook/none delivery, failure destination, model override, stale acknowledgement guard 같은 운영 디테일을 더 촘촘히 문서화한다.

미니 사례 2, 매일 아침 AI 뉴스 보내기를 만든다면

매일 아침 9시에 AI 뉴스를 요약해 Telegram으로 보내는 작업을 생각해 보자.

Hermes에서는 자연어 혹은 /cron add, hermes cron create 중심으로, skill-backed cron을 붙여 빠르게 만들 수 있다. 사용감은 “에이전트에게 예약 업무를 시킨다”에 가깝다.

OpenClaw에서는 isolated session, target channel, webhook, failure notification, model override까지 세밀하게 만질 수 있다. 사용감은 “운영 잡을 하나 설계한다”에 더 가깝다.

둘 중 누가 무조건 낫다기보다, 단순함과 운영 세밀함의 무게중심이 다르다.

7. 멀티에이전트는 OpenClaw가 더 공식적으로 선명하다

OpenClaw의 Multi-Agent Routing는 agent를 workspace, agentDir, session store까지 분리된 독립 단위로 설명한다. 여러 채널 계정과 바인딩을 통해 어느 메시지가 어느 agent로 갈지까지 문서화한다. 즉, 멀티에이전트가 기능이 아니라 게이트웨이 아키텍처의 일부다.

Hermes는 공식 저장소 README에서 subagents와 parallel workstreams를 강조한다. 다만 공식 문서의 중심축은 OpenClaw처럼 gateway routing architecture보다는 하나의 agent 경험과 그 확장 기능에 더 가깝다.

이 차이 때문에 여러 사람, 여러 성격, 여러 채널 계정을 한 서버에서 분리 운영하려면 OpenClaw 문서 쪽이 훨씬 직접적이다. 반면 한 명의 agent가 서브에이전트를 써서 일을 병렬화하는 상상은 Hermes 쪽이 더 자연스럽다.

8. 보안 철학도 다르다

Hermes의 Security는 defense-in-depth 7계층 모델을 제시한다. dangerous command approval, container isolation, MCP credential filtering, context file scanning, cross-session isolation, input sanitization, DM pairing과 allowlist를 명확하게 설명한다.

OpenClaw의 Security는 먼저 trust model을 분명히 한다. OpenClaw는 personal assistant trust model, 즉 한 명의 trusted operator boundary를 전제로 하며 hostile multi-tenant security boundary가 아니라고 못 박는다. 그 위에서 pairing, allowlist, openclaw security audit, sandboxing, gateway/node trust concept를 설명한다.

이건 중요하다. OpenClaw는 “무엇을 지켜주나”보다 “어디까지를 보안 경계로 보나”를 먼저 명시한다. 반면 Hermes는 “어떤 방어층이 쌓여 있나”를 먼저 보여준다.

9. 마이그레이션은 Hermes가 먼저 손을 내민다

Hermes 공식 저장소와 문서는 hermes claw migrate를 명시한다. 첫 설치 때도 ~/.openclaw를 감지해 설정, 메모리, 스킬, API 키를 가져오는 경로를 안내한다. 즉, Hermes는 OpenClaw 사용자를 끌어오는 전환 시나리오를 공식적으로 준비했다.

반대로 이번 조사에서 OpenClaw 공식 문서 안에서는 Hermes로부터 가져오기 같은 역방향 설명은 확인하지 못했다. 이 점은 생태계 포지셔닝을 읽는 힌트가 된다. Hermes는 스스로를 OpenClaw 다음 단계 후보로도 제시하고 있는 셈이다.

장점과 약점, 공식 문서 기준으로 다시 정리

Hermes 장점

learning loop, persistent memory, session search를 제품 핵심 가치로 분명히 설명한다
모델·백엔드 선택 폭이 넓고, 터미널 백엔드와 외부 memory providers 연결이 유연하다
스킬을 on-demand로 불러오고 agent-managed skill로 확장하는 그림이 선명하다
OpenClaw에서 넘어오는 migration 경로가 공식 문서에 있다

Hermes 아쉬운 점

채널, 노드, 시각 UI 전체를 묶는 플랫폼 그림은 OpenClaw보다 덜 두드러진다
gateway 차원의 다중 agent 라우팅 설명은 OpenClaw만큼 전면적이지 않다
메모리와 학습 루프의 강점이 문서에는 강하지만, 실제 기대치 조절은 사용자가 해야 한다

OpenClaw 장점

multi-channel gateway, nodes, Canvas, Web Control UI, routing이 한 제품 그림 안에서 잘 연결된다
cron, delivery, session types, security audit처럼 운영 기능 문서화가 아주 상세하다
memory를 markdown 파일과 dreaming 체계로 투명하게 드러낸다
multi-agent routing이 아키텍처 수준에서 정리돼 있어 팀/채널 분리 운영에 강하다

OpenClaw 아쉬운 점

trust model이 personal assistant 중심이라, 적대적 다중 사용자 환경의 보안 경계로 쓰기엔 부적합하다
학습 루프나 self-improving agent라는 메시지는 Hermes보다 약하다
구조가 큰 만큼, 처음 보는 사람에게는 무엇을 먼저 잡아야 하는지가 더 복잡하게 느껴질 수 있다

병렬 리서치 보강, 커뮤니티는 이렇게 느낀다

공식 문서만 보면 Hermes는 더 학습형, OpenClaw는 더 운영형으로 보인다. 병렬 리서치로 Reddit, GitHub 이슈, 비교 스레드까지 확인해 보면 체감 반응도 비슷한 방향으로 모인다.

Hermes는 더 빨리 돌아가는 느낌, 덜 골치 아프다, 같은 모델인데 더 안정적이다라는 인식이 반복됐다.
OpenClaw는 진짜 비동기형 개인 비서처럼 일한다, 이메일·메신저·크론·그룹채팅을 묶는 힘이 강하다는 평가가 많았다.
다만 Hermes는 과열 칭찬과 hype 의심을 주의해서 봐야 했고, OpenClaw는 GitHub 이슈가 실패 사례 위주라 실제보다 더 불안정하게 보일 수 있었다.

이 보강은 어디까지나 참고용이다. 제품 선택의 기준점은 여전히 공식 문서가 더 안전하다.

누가 무엇을 고르면 좋을까

Hermes를 고르면 좋은 사람

에이전트가 작업하면서 기억과 스킬을 더 잘 축적하길 바란다
모델, 제공자, 터미널 백엔드, 메모리 provider를 넓게 실험하고 싶다
CLI/TUI 중심으로 오래 쓰는 개인 agent를 키우고 싶다
OpenClaw를 써 봤고, 좀 더 학습형 agent 경험을 원한다

OpenClaw를 고르면 좋은 사람

Telegram, WhatsApp, Discord, Slack 같은 실채널에 assistant를 붙이고 싶다
Web UI, mobile node, Canvas, camera, voice 같은 디바이스 경험이 중요하다
여러 agent와 채널을 분리해 라우팅하는 구조가 필요하다
개인 assistant를 생활 흐름과 운영 자동화에 더 가깝게 붙이고 싶다

다음 편에서 이어질 질문

이제 비교는 끝났고, 다음 질문은 더 실전적이다.

Hermes는 실제로 어떻게 설치하나
첫 실행 뒤 어떤 모델과 도구를 먼저 붙여야 하나
Telegram으로 어떻게 안전하게 연결하나
그다음 llm-wiki, Obsidian, Gboard를 어떻게 이어 붙여 개인 지식 루프를 만들까

다음 글부터는 이 흐름을 하나씩 실제 셋업 관점에서 이어갈 예정이다.

3줄 결론

Hermes는 agent를 더 똑똑하게 키우는 방향이 강하다. 메모리, 스킬, 학습 루프, provider 유연성이 앞에 나온다.
OpenClaw는 assistant를 현실 채널에 더 넓게 붙이는 방향이 강하다. gateway, nodes, Canvas, routing, 운영형 cron이 앞에 나온다.
그래서 선택 기준은 성능 숫자가 아니라, 나는 하나의 학습형 agent를 키우고 싶은가, 아니면 생활형 gateway assistant를 굴리고 싶은가로 잡는 편이 맞다.

일하는 ai

탐색기