2026년 5월 29일 기준 공식 문서와 GitHub 저장소 확인
Hermes, OpenClaw, NanoClaw 비교
세 도구는 모두 “내가 직접 운영하는 개인 AI 에이전트”를 지향하지만, 출발점은 꽤 다릅니다. OpenClaw는 여러 메신저와 기기를 묶는 게이트웨이, Hermes는 학습 루프와 멀티 모델 실행 환경, NanoClaw는 작고 읽히는 코드와 컨테이너 격리를 앞세웁니다.
왜 이 3개를 함께 비교했나
Hermes, OpenClaw, NanoClaw를 함께 보는 이유는 단순히 이름이 비슷해서가 아닙니다. 세 프로젝트는 모두 사용자가 직접 운영하는 에이전트를 목표로 하며, 채팅 인터페이스, 도구 실행, 장기 기억, 스케줄 작업, 원격 또는 로컬 실행이라는 공통 문제를 다룹니다. 즉 사용자는 “내 메신저에서 부르면 파일을 읽고, 웹을 검색하고, 주기적으로 일을 처리하고, 필요하면 코드를 수정하는 개인 비서”를 만들고 싶을 때 자연스럽게 이 3개를 후보로 보게 됩니다.
하지만 비교가 의미 있는 더 큰 이유는 세 도구가 서로 다른 철학을 대표하기 때문입니다. OpenClaw는 수많은 채널을 하나의 Gateway로 묶는 쪽에 강합니다. Hermes는 에이전트가 경험을 통해 스킬을 만들고 개선하며, 여러 모델과 실행 백엔드를 오가는 쪽에 강합니다. NanoClaw는 기능을 많이 싣기보다 코드를 작게 유지하고, 컨테이너 격리와 사용자별 커스터마이징을 중심에 둡니다. 그래서 이 3개를 비교하면 “무엇을 설치할까”뿐 아니라 “개인 AI 에이전트를 어떤 구조로 운영할까”라는 판단 기준도 선명해집니다.
또 하나의 이유는 보안입니다. 개인 에이전트는 단순 챗봇이 아닙니다. 파일 시스템, 셸, 브라우저, 메신저, API 키, 일정, 이메일 같은 민감한 표면을 만질 수 있습니다. 따라서 기능 목록만 비교하면 위험을 놓치기 쉽습니다. OpenClaw의 공식 보안 문서는 신뢰된 단일 사용자 환경에서 host exec가 기본적으로 허용될 수 있음을 설명하고, Hermes의 보안 정책은 적대적 LLM에 대한 실제 경계는 OS 수준 격리라고 못 박습니다. NanoClaw는 애초에 “애플리케이션 권한 체크가 아니라 컨테이너 격리”를 철학으로 내세웁니다. 세 도구의 차이는 결국 편의성, 학습 능력, 격리 수준 사이의 선택입니다.
빠른 결론
결론부터 말하면, “어디서든 메시지로 부르는 개인 비서”가 필요하면 OpenClaw가 가장 넓습니다. “에이전트가 일을 하면서 스킬과 기억을 개선하는 학습형 작업자”를 원하면 Hermes가 가장 흥미롭습니다. “내가 이해할 수 있는 작은 코드베이스와 강한 격리”가 최우선이면 NanoClaw가 가장 설득력 있습니다.
| 구분 | Hermes Agent | OpenClaw | NanoClaw |
|---|---|---|---|
| 한 줄 요약 | 자기 개선과 멀티 모델을 강조한 학습형 에이전트 | 메신저, 앱, 노드, 도구를 묶는 로컬 Gateway | 작고 읽히는 코드와 컨테이너 격리를 강조한 개인 에이전트 |
| 가장 잘 맞는 사용자 | 반복 작업, 연구, 개발, 장기 기억을 한 에이전트에 맡기려는 사용자 | WhatsApp, Telegram, Slack, Discord 등 여러 채널에서 같은 비서를 쓰려는 사용자 | 복잡한 플랫폼보다 직접 이해하고 고쳐 쓰는 self-hosted 에이전트를 원하는 사용자 |
| 핵심 강점 | 학습 루프, 스킬 생성과 개선, 다양한 모델·백엔드, TUI와 게이트웨이 | 채널 폭, Gateway 중심 운영, 모바일·데스크톱 노드, Control UI, 풍부한 기능 | 컨테이너 격리, 작은 코드베이스, per-agent workspace, 스킬 기반 커스터마이징 |
| 핵심 약점 | 학습형 시스템이라 운영 설계와 격리 구성이 중요함 | 기능이 많은 만큼 설정과 보안 표면이 큼 | 생태계와 기본 UI는 상대적으로 작고, 커스터마이징이 코드 변경에 가깝다 |
▲ Hermes Agent 공식 GitHub 저장소. 학습 루프, 멀티 모델, 터미널 인터페이스를 전면에 내세운다. 출처: NousResearch/hermes-agent
▲ OpenClaw 공식 문서. 여러 채팅 앱과 채널을 하나의 Gateway로 묶는 구조가 핵심이다. 출처: OpenClaw Docs
▲ NanoClaw 공식 GitHub 저장소. 작은 코드베이스, 컨테이너 격리, 사용자별 fork 커스터마이징을 강조한다. 출처: nanocoai/nanoclaw
핵심 기능 비교
세 도구는 모두 에이전트가 실제 작업을 수행하게 만든다는 점에서 비슷하지만, 기능을 배치하는 방식은 다릅니다. Hermes는 에이전트 내부의 학습과 실행 능력을 키우는 쪽입니다. OpenClaw는 사용자가 이미 쓰는 채널과 기기를 연결하는 쪽입니다. NanoClaw는 작은 host process와 컨테이너 실행 단위로 기능을 쪼개고, 필요한 채널과 provider를 스킬로 추가하는 쪽입니다.
| 항목 | Hermes Agent | OpenClaw | NanoClaw |
|---|---|---|---|
| 주요 언어 | Python 중심, 일부 웹·게이트웨이 구성 포함 | TypeScript / Node.js Gateway 중심 | TypeScript host process와 컨테이너 agent runner |
| 실행 인터페이스 | TUI, CLI, Telegram, Discord, Slack, WhatsApp, Signal, Email 등 | Control UI, CLI, WhatsApp, Telegram, Slack, Discord, Signal, iMessage, Matrix 등 다수 채널 | 채널 어댑터를 스킬로 설치, Telegram, Discord, WhatsApp 등 온디맨드 구성 |
| 모델 전략 | Nous Portal, OpenRouter, Hugging Face, OpenAI, NVIDIA NIM 등 다양한 provider 전환 | 사용자가 선택한 provider와 모델을 Gateway가 연결 | 기본은 Claude Code / Claude Agent SDK, Codex·OpenCode·Ollama 등은 스킬로 추가 |
| 기억과 맥락 | 에이전트 curated memory, 세션 검색, 사용자 모델링, context files | 세션, workspace, memory, agent routing 중심 | per-agent workspace, CLAUDE.md, SQLite 기반 메시지와 상태 저장 |
| 스킬과 확장 | 경험 기반 스킬 생성·개선, MCP, 도구 세트 | workspace skills, ClawHub, bundled/managed skills, plugin channels | 기능을 trunk에 쌓지 않고 /add-<channel>, /add-<provider> 형태의 스킬로 fork에 복사 |
| 자동화 | cron scheduler와 플랫폼 delivery | cron, sessions, gateway events, channel actions | recurring jobs, due-message wake, host sweep |
| 보안 방향 | OS 수준 격리를 실제 경계로 보고 Docker, SSH, Modal, Daytona 등 backend 선택 | pairing, allowlist, sandbox mode, 위험 스캔, gateway 보안 설정 | 컨테이너 격리와 명시적 mount, OneCLI Agent Vault, per-agent boundary |
사용 시나리오로 다시 보면
기능표만 보면 OpenClaw가 가장 커 보이고, NanoClaw가 가장 작아 보이며, Hermes는 중간 어딘가에 있는 것처럼 보일 수 있습니다. 하지만 실제 선택은 규모순이 아니라 사용 시나리오순으로 해야 합니다. 예를 들어 “아침에 Telegram으로 오늘 할 일을 묻고, 회사 Slack에서는 회의록 요약을 받고, 집에서는 모바일 노드로 음성 명령을 쓰고 싶다”면 핵심 문제는 모델 성능이 아니라 channel routing입니다. 이 경우 OpenClaw처럼 Gateway가 중심인 구조가 맞습니다.
반대로 “매주 같은 형식의 시장 조사, 코드 리뷰, 문서 정리, 회고 보고서를 시키는데 매번 배경 설명을 반복하고 싶지 않다”면 핵심 문제는 연결 채널보다 누적 맥락입니다. Hermes가 강조하는 기억, 스킬 생성, 세션 검색, cron, provider 전환은 이런 반복 업무에서 힘을 냅니다. 특히 터미널에서 긴 작업을 하다가 중간에 방향을 바꾸거나, subagent를 띄워 병렬로 조사시키는 흐름은 일반 메신저형 에이전트보다 개발 작업에 가깝습니다.
또 다른 시나리오는 “내 가족 채팅이나 개인 파일에 접근시키고 싶지만, 거대한 플랫폼을 그대로 믿기는 부담스럽다”는 경우입니다. 이때는 기능이 적어도 NanoClaw의 작고 읽히는 구조가 장점이 됩니다. 어떤 파일을 mount했는지, 어떤 agent group이 어떤 container를 쓰는지, 어떤 channel adapter를 fork에 복사했는지 확인할 수 있기 때문입니다. 다만 이 방식은 사용자가 자기 설치본을 프로젝트처럼 다루는 태도를 요구합니다.
| 시나리오 | 중요한 기준 | 가장 자연스러운 후보 |
|---|---|---|
| 메신저 여러 개에서 같은 AI를 호출 | 채널 수, pairing, routing, session 관리 | OpenClaw |
| 반복 리서치와 개발 작업 자동화 | 기억, 스킬 개선, 터미널 UX, provider 전환 | Hermes Agent |
| 가족·개인 파일에 제한적으로 접근 | 컨테이너 격리, mount 범위, 코드 이해 가능성 | NanoClaw |
| 작은 VPS에서 항상 켜둘 개인 비서 | 운영 단순성, 백그라운드 작업, 비용 | Hermes 또는 NanoClaw |
| 모바일과 데스크톱 노드를 함께 운영 | 기기 통합, Control UI, media support | OpenClaw |
따라서 이 비교의 핵심 질문은 “가장 유명한 것이 무엇인가”가 아닙니다. 내 에이전트가 주로 어디에서 호출되는지, 어떤 파일과 계정에 접근해야 하는지, 실패했을 때 피해 범위가 어디까지인지, 그리고 내가 어느 정도까지 직접 고쳐 쓸 생각이 있는지를 먼저 정해야 합니다. 이 질문에 답하면 세 도구의 우열보다 적합도가 더 또렷해집니다.
도입 전 체크리스트도 간단합니다. 먼저 에이전트가 읽어도 되는 폴더와 절대 읽으면 안 되는 폴더를 나눕니다. 다음으로 메신저별 호출 주체를 정하고, 공개 채널이나 단체 채팅에서는 자동 실행 권한을 낮춥니다. 마지막으로 스케줄 작업은 처음부터 자동 수정이나 삭제를 허용하지 말고, 보고서 생성처럼 되돌리기 쉬운 작업부터 시작하는 편이 좋습니다. 이 3가지만 지켜도 어떤 도구를 고르든 초기 사고 가능성을 크게 줄일 수 있습니다. 특히 첫 설치 후 1주일은 모든 자동화 결과를 사람이 확인하는 관찰 기간으로 두는 것이 안전합니다. 작은 성공을 확인한 뒤 권한을 넓히는 순서가 가장 현실적입니다.
Hermes Agent 기능과 장단점
Hermes Agent는 Nous Research가 만든 self-improving AI agent입니다. 공식 README는 Hermes를 “경험에서 스킬을 만들고, 사용 중 스킬을 개선하고, 기억을 지속하도록 스스로 유도하며, 과거 대화를 검색하고, 세션을 거치며 사용자 모델을 깊게 만든다”고 설명합니다. 그래서 Hermes의 핵심은 “에이전트가 단순히 도구를 호출하는가”가 아니라 “에이전트가 사용자의 반복 패턴을 배워 다음 작업 품질을 높이는가”입니다.
기능 면에서는 터미널 TUI가 강합니다. 멀티라인 편집, slash-command 자동완성, 대화 이력, interrupt-and-redirect, streaming tool output 같은 기능은 개발자와 연구자에게 직접적입니다. 동시에 Telegram, Discord, Slack, WhatsApp, Signal, Email 같은 메시징 게이트웨이도 제공하므로 반드시 터미널에 붙어 있을 필요는 없습니다. 모델 provider도 넓습니다. Nous Portal, OpenRouter, Hugging Face, OpenAI, NVIDIA NIM, Kimi, MiniMax, 자체 endpoint 등을 바꿔 쓸 수 있고, hermes model로 전환하는 흐름을 문서화하고 있습니다.
장점은 3가지입니다. 첫째, 학습 루프가 명확합니다. 반복 업무를 처리할 때 매번 같은 지시를 다시 설명하는 비용을 줄일 수 있습니다. 둘째, 실행 환경 선택지가 넓습니다. 로컬, Docker, SSH, Singularity, Modal, Daytona 같은 backend를 상황별로 고를 수 있습니다. 셋째, OpenClaw migration이 공식 README에 포함되어 있어 OpenClaw 사용자도 기억, 스킬, API 키, 메시징 설정 등을 옮기는 경로를 검토할 수 있습니다.
단점도 분명합니다. 학습형 에이전트는 좋아 보이지만, 잘못 설계하면 오래된 기억, 과도한 자동화, 과신한 스킬이 누적될 수 있습니다. 또한 여러 provider와 backend를 지원한다는 것은 설정 표면도 넓다는 뜻입니다. 보안 정책 역시 “애플리케이션 내부의 허가 버튼이나 redaction은 진짜 격리가 아니다”라는 강한 관점을 취합니다. 즉 Hermes를 제대로 쓰려면 어떤 입력을 신뢰할지, 어떤 작업을 host에서 실행할지, 언제 전체 프로세스를 컨테이너나 원격 sandbox로 감쌀지 정해야 합니다.
OpenClaw 기능과 장단점
OpenClaw는 “사용자가 이미 쓰는 채팅 앱과 채널 표면을 AI coding agent에 연결하는 self-hosted Gateway”에 가깝습니다. 공식 문서는 Discord, Google Chat, iMessage, Matrix, Microsoft Teams, Signal, Slack, Telegram, WhatsApp, Zalo 등 여러 채널을 단일 Gateway 프로세스로 연결한다고 설명합니다. 한마디로 OpenClaw는 에이전트 자체의 지능보다 “에이전트를 어디서나 부를 수 있게 하는 운영면”이 강합니다.
주요 기능은 매우 넓습니다. Gateway는 세션, routing, channel connection의 single source of truth 역할을 합니다. 사용자는 Control UI에서 채팅, 설정, 세션, 노드를 다룰 수 있고, CLI로도 에이전트에게 메시지를 보낼 수 있습니다. multi-agent routing으로 sender, workspace, agent마다 세션을 분리할 수 있으며, 이미지, 오디오, 문서 같은 media support도 제공됩니다. macOS 앱, iOS·Android nodes, voice wake, talk mode, live canvas 같은 기능은 “개인 비서가 여러 기기에서 실제로 움직이는 느낌”을 줍니다.
장점은 생태계와 연결성입니다. 채널이 많고, onboarding이 있으며, skills와 plugins가 풍부합니다. 집, 회사, 모바일, 데스크톱을 오가는 사용자는 OpenClaw의 Gateway 구조에서 큰 이점을 얻습니다. 특히 여러 메신저에서 같은 에이전트와 대화하거나, 채널별로 다른 agent/workspace를 붙이는 운영은 OpenClaw가 가장 자연스럽습니다.
단점은 복잡성과 보안 표면입니다. 기능이 많다는 것은 설치, 업데이트, 권한, channel pairing, provider config, skill vetting, remote exposure를 모두 신경 써야 한다는 뜻입니다. 공식 보안 문서는 신뢰된 단일 operator setup에서 host exec가 기본적으로 허용될 수 있다고 설명합니다. 또한 prompt injection은 공개 DM이 아니어도 웹 페이지, 이메일, 문서, 첨부파일, 로그처럼 에이전트가 읽는 모든 untrusted content에서 발생할 수 있다고 경고합니다. 따라서 OpenClaw는 “최대한 많은 일을 시킬 수 있는 도구”인 동시에, “어디까지 접근시킬지 계속 통제해야 하는 도구”입니다.
NanoClaw 기능과 장단점
NanoClaw는 OpenClaw의 반대편 질문에서 출발합니다. “내 삶 전체에 접근할 수 있는 복잡한 소프트웨어를 내가 이해하지 못한 채 돌려도 되는가?” 공식 README는 NanoClaw를 작은 코드베이스, 한 프로세스, 적은 파일 수, 컨테이너 격리, 사용자별 fork 커스터마이징이라는 철학으로 설명합니다. 기능을 많이 넣어 범용 플랫폼을 만들기보다, 기본 trunk를 작게 유지하고 필요한 채널이나 provider는 스킬로 추가하는 방향입니다.
지원 기능은 생각보다 실용적입니다. multi-channel messaging은 WhatsApp, Telegram, Discord, Slack, Microsoft Teams, iMessage, Matrix, Google Chat, Webex, Linear, GitHub, WeChat, email 등을 온디맨드 skill로 붙이는 방식입니다. 각 agent group은 자기 CLAUDE.md, 자기 memory, 자기 container, 허용된 mount만 갖습니다. scheduled tasks, web access, container isolation, OneCLI Agent Vault를 통한 credential injection도 README에 명시되어 있습니다. v2 README 기준으로 기본은 Claude Code와 Anthropic의 Claude Agent SDK이지만, /add-codex, /add-opencode, /add-ollama-provider 같은 경로로 다른 provider를 붙이는 설명도 있습니다.
장점은 이해 가능성과 격리입니다. 코드를 직접 읽고 수정할 수 있다는 점은 개인 에이전트에서 큰 가치입니다. 자동화 도구가 내 파일과 메신저를 만질수록 “내가 이 시스템이 뭘 하는지 이해하는가”가 중요해지기 때문입니다. 또한 container boundary를 전면에 두면, host에서 실행되는 권한 체크보다 사고 반경을 줄이기 쉽습니다. per-agent workspace 구조도 가족 채팅, 개인 업무, 회사 프로젝트처럼 맥락을 분리하고 싶은 사용자에게 유용합니다.
단점은 규모입니다. 작은 코드베이스는 장점이지만, 동시에 OpenClaw처럼 많은 UI와 channel polish를 기대하면 부족하게 느껴질 수 있습니다. 커스터마이징이 “설정 파일을 만지는 일”이 아니라 “Claude Code가 fork 코드를 고치는 일”에 가깝기 때문에, Git과 코드 변경 흐름에 익숙하지 않은 사용자는 부담을 느낄 수 있습니다. 또한 기본 경험은 Claude Code 중심이므로 Anthropic 생태계와 잘 맞는 사람에게 더 편합니다. 다양한 provider를 붙일 수는 있지만, 그 철학은 “처음부터 다 들어 있다”가 아니라 “필요한 것만 내 fork에 넣는다”입니다.
보안과 운영 관점 비교
개인 AI 에이전트 비교에서 가장 자주 빠지는 항목이 보안입니다. 그러나 실제 운영에서는 기능보다 보안이 먼저입니다. 세 도구 모두 파일, 셸, 브라우저, 메신저, API를 건드릴 수 있기 때문에, “잘 대답하는가”보다 “어디까지 손을 뻗을 수 있는가”를 먼저 봐야 합니다.
▲ Hermes Agent 보안 정책은 적대적 LLM에 대한 실제 경계를 OS 수준 격리로 본다. 출처: Hermes Security Policy
▲ OpenClaw 보안 문서는 DM 정책, install scan, prompt injection, tool blast radius를 구체적으로 다룬다. 출처: OpenClaw Security Docs
Hermes는 명시적으로 OS-level isolation을 강조합니다. 이는 사용자가 Hermes를 로컬에서 편하게 쓰더라도, untrusted input을 많이 읽는 순간에는 전체 프로세스를 Docker, cloud sandbox, remote backend 같은 경계 안에 넣어야 한다는 뜻입니다. OpenClaw는 Gateway 노출, DM pairing, allowlist, sandbox mode, plugin/skill install scan처럼 운영자가 조절해야 할 레버가 많습니다. NanoClaw는 기본 설계에서 agent container와 mount allowlist를 강조하므로 “일단 host를 그대로 만지는 구조”에 대한 불안을 줄여줍니다.
다만 컨테이너가 모든 문제를 해결하지는 않습니다. API 키가 잘못 전달되거나, mount 범위가 너무 넓거나, 메신저 adapter가 과도한 권한을 갖거나, 사용자가 스스로 위험한 스킬을 추가하면 사고는 여전히 납니다. 그래서 실전 기준은 단순합니다. OpenClaw는 넓은 연결성을 얻는 대신 접근권한을 세밀하게 줄여야 합니다. Hermes는 학습과 자동화를 얻는 대신 어떤 backend에서 무엇을 실행할지 결정해야 합니다. NanoClaw는 격리와 단순성을 얻는 대신 직접 고쳐 쓰는 운영 습관이 필요합니다.
▲ NanoClaw의 Agent Swarms 문서. v1의 swarms 프레이밍과 v2의 agent-to-agent primitive 변화도 함께 언급된다. 출처: NanoClaw Docs
어떤 도구를 선택할까
OpenClaw를 고를 상황은 명확합니다. 여러 메신저와 기기에서 같은 AI 비서를 부르고 싶고, 채널 연결과 routing이 핵심이면 OpenClaw가 가장 강합니다. 예를 들어 WhatsApp에서 개인 일정, Slack에서 업무 요약, Telegram에서 서버 알림, 데스크톱 Control UI에서 세션 확인을 한 Gateway로 묶고 싶다면 OpenClaw의 복잡성은 비용이 아니라 기능입니다. 다만 이 경우에는 처음부터 remote exposure, DM policy, sandbox mode, skill vetting을 운영 규칙으로 정해야 합니다.
Hermes를 고를 상황은 반복 작업의 품질을 계속 올리고 싶을 때입니다. 매주 비슷한 리서치를 하고, 여러 provider를 바꿔 쓰고, 터미널에서 긴 작업을 시키고, 에이전트가 경험을 바탕으로 스킬을 만들어가길 바란다면 Hermes의 학습 루프가 매력적입니다. 개발자, 연구자, 콘텐츠 제작자처럼 “지난번에 했던 방식”을 기억하고 개선하는 도구가 필요한 사람에게 맞습니다. 대신 학습된 기억과 스킬이 항상 옳지는 않으므로 주기적인 정리와 격리 정책이 필요합니다.
NanoClaw를 고를 상황은 신뢰와 이해 가능성이 최우선일 때입니다. 거대한 framework를 설치해 놓고 “아마 괜찮겠지”라고 믿기보다, 내가 읽을 수 있는 코드와 명시적 container boundary를 선호한다면 NanoClaw가 맞습니다. 가족 채팅, 개인 프로젝트, 작은 VPS, 제한된 파일 mount처럼 좁은 범위에서 확실하게 운영하고 싶은 사용자는 특히 잘 맞습니다. 반대로 설치하자마자 모든 channel과 UI가 완성되어 있길 바란다면 답답할 수 있습니다.
| 당신의 우선순위 | 추천 | 이유 |
|---|---|---|
| 메신저와 기기 연결이 가장 중요하다 | OpenClaw | Gateway, channel, node, Control UI, multi-agent routing이 가장 넓다 |
| 에이전트가 경험을 학습하고 스킬을 개선해야 한다 | Hermes Agent | 자기 개선 루프, memory, skill creation, 다양한 backend가 핵심 철학이다 |
| 작고 이해 가능한 코드와 격리가 먼저다 | NanoClaw | 컨테이너, mount allowlist, per-agent workspace, fork 기반 커스터마이징이 강하다 |
| 처음 self-hosted 에이전트를 실험한다 | NanoClaw 또는 Hermes | 작게 시작하려면 NanoClaw, 터미널 중심 작업부터 시작하려면 Hermes가 부담이 낮다 |
| 가족·회사·개인 채널을 모두 묶는다 | OpenClaw | 채널별 routing과 session 분리가 선택의 핵심이다 |
최종적으로 이 3개는 “누가 더 좋다”보다 “무엇을 위험으로 보고 무엇을 가치로 보느냐”의 문제입니다. OpenClaw는 연결성의 극대화, Hermes는 학습형 작업자의 진화, NanoClaw는 단순성과 격리를 선택합니다. 개인적으로는 처음 도입할 때 NanoClaw처럼 작은 범위에서 시작하고, 반복 작업이 쌓이면 Hermes를 검토하며, 여러 채널에 상시 운영해야 할 필요가 분명해질 때 OpenClaw로 확장하는 순서가 가장 현실적이라고 봅니다.
FAQ
출처와 확인한 자료
- NousResearch/hermes-agent GitHub README - Hermes의 학습 루프, 모델 provider, TUI, gateway, migration 기능 확인
- Hermes Agent Security Policy - OS 수준 격리와 trust model 확인
- OpenClaw 공식 문서 - Gateway, channel, routing, 핵심 기능 확인
- openclaw/openclaw GitHub README - 설치, supported channels, highlights, security model 확인
- OpenClaw Gateway Security 문서 - DM policy, install scan, prompt injection 위험 확인
- nanocoai/nanoclaw GitHub README - 작은 코드베이스, 컨테이너 격리, channel/provider skill, architecture 확인
- NanoClaw Agent Swarms 문서 - v1 swarms와 v2 agent-to-agent 전환 맥락 확인
- GitHub API 확인 시점: 2026년 5월 29일. 저장소 스타 수와 fork 수는 변동될 수 있어 본문 판단의 핵심 근거로 쓰지 않았습니다.
'AI' 카테고리의 다른 글
| 허깅페이스란? 나에게 맞는 AI 모델 찾는 법 (0) | 2026.06.20 |
|---|---|
| BGE-M3 Pairwise Embedding Fine-tuning으로 한국어 업종·가맹점 유사도 모델 개선하기 (0) | 2026.06.03 |
| Hermes Agent 리뷰 (0) | 2026.05.29 |
| OpenClaw 다운로드 및 테스트 후기 (0) | 2026.05.29 |
| Nanoclaw 실사용후기: 개인 AI 에이전트로 써볼 만할까? (0) | 2026.05.28 |
