지금 벌어지는 변화는 단순한 AI 툴 유행이 아니다. 더 정확히 말하면, 소프트웨어를 만들고 운영하는 방식 자체가 바뀌는 중이다. 예전에는 개발자가 직접 코드를 쓰고, 직접 서버를 보고, 직접 로그를 읽고, 직접 메시지에 답하고, 직접 배포와 검수를 반복했다. 그다음 단계에서는 AI가 옆에서 도와주는 보조자 역할을 맡았다. 그런데 OpenClaw와 Hermes 같은 시스템이 등장하면서 판이 한 번 더 뒤집어졌다. 이제 AI는 옆에서 조언하는 것이 아니라, 원격에서 호출되고, 병렬로 움직이고, 장기 기억을 갖고, 채널마다 다른 역할을 맡는 실행 단위가 되기 시작했다.
이 변화의 핵심은 모델 성능이 아니라 운영 구조다. OpenClaw는 2026년 1월 말 GitHub에 공개된 지 이틀 만에 별 3만 4천 개를 찍고, 4월 현재 357,000개 이상의 스타를 기록하며 Linux와 React를 넘어 GitHub 역대 최다 스타 프로젝트로 올라섰다. 그 뒤를 이어 2026년 2월 25일 Nous Research가 공개한 Hermes Agent는 두 달도 안 되어 81,000개 이상의 스타를 모으며 빠르게 성장 중이다. 두 프로젝트 모두 AI를 채팅창 안에 가두지 않고 Telegram·Slack·Discord·WhatsApp·Web UI·모바일 노드·원격 Gateway에 풀어 놓는 발상을 공유한다.
이 글에서는 OpenClaw가 실제로 무엇을 바꿨고, 왜 보안 문제가 구조적으로 터질 수밖에 없었으며, OpenAI가 왜 창업자를 데려갔고, Hermes가 무엇을 더 정교하게 보완했고, 왜 이 구조를 세팅한 사람과 아닌 사람 사이의 개발 격차가 시간이 갈수록 벌어지는지를 다룬다.
1. OpenClaw가 실제로 바꾼 것: 챗봇이 아니라 원격 실행 계층
OpenClaw의 공식 Gateway Architecture 문서를 읽어 보면, 프로젝트의 진짜 포인트가 모델 자체가 아니라 아키텍처라는 점이 드러난다. 단일 Gateway가 WebSocket 서버(기본 포트 18789)로 동작하면서 다수 채널을 하나의 컨트롤 플레인으로 묶고, macOS 앱, CLI, Web Admin, iOS/Android 모바일 노드가 같은 서버에 연결되며, 노드는 단순한 알림 수신기가 아니라 기기 기능까지 에이전트 도구로 노출하는 실행 장치다.
1.1 단일 Gateway가 만드는 운영 일관성
- OpenClaw의 Gateway는 WebSocket 프로토콜 기반으로, 모든 클라이언트가 role(CLI, web UI, macOS app, iOS/Android node, headless node)을 선언하며 접속한다. Gateway는 이 접속 정보를 바탕으로 메시지를 올바른 세션과 큐에 배분한다.
- 지원 채널은 WhatsApp(Baileys), Telegram(grammY), Slack, Discord, Signal, iMessage, WebChat이며, 하나의 Gateway 프로세스가 이 채널 전부를 동시에 소유한다. 채널마다 별도 프로세스를 띄울 필요가 없다.
- Gateway 자체는 리소스가 가볍다. Nebius의 보안 분석에 따르면 CPU 1개, RAM 1GB 미만으로 동작하며, 컨트롤 플레인과 추론 평면을 깔끔하게 분리한다.
- 이 구조 덕분에 Telegram에서 시작한 대화를 CLI에서 이어가거나, Discord에서 내린 지시의 결과를 Slack에서 받는 식의 크로스 플랫폼 세션 연속성이 가능하다.
1.2 Multi-agent Routing과 역할 분리
- OpenClaw는 하나의 Gateway 안에 여러 agent를 등록하고, 각각에 독립된 personality(SOUL.md), workspace(AGENTS.md), auth, sessions를 부여한다. 공식 Multi-Agent Routing 문서에는 에이전트마다 다른 보안 프로필, 다른 모델, 다른 도구셋을 줄 수 있다고 명시되어 있다.
- 라우팅은 Bindings라는 매칭 규칙으로 동작한다. 수신 메시지의 채널, 사용자 ID, 그룹 같은 조건을 평가해 어떤 agent로 보낼지 결정한다. 한 실무 사례에서는 4개의 Telegram 봇과 4개의 agent를 1:1로 바인딩해 각각 다른 프로젝트를 전담시켰다.
- agent 간에는 cross-talk이 기본적으로 차단되어 있고, 명시적으로 허용한 경우에만 상호 참조가 가능하다. 이는 보안과 컨텍스트 오염 방지를 위한 설계다.
- 이 구조 덕분에 사람 여러 명이 동시에 일하는 것 같은 운영 모델이 가능해진다. PR 리뷰 전담 agent, 배포 감시 agent, 리서치 agent, 고객 응대 agent를 한 Gateway 안에서 분리 운영할 수 있다.
1.3 모바일 노드와 물리 세계 연결
- iOS/Android 노드는 WebSocket에
role: node로 접속하며, 단순 알림 수신기가 아니라camera.*,screen.record,location.get,canvas.*같은 디바이스 기능을 에이전트 도구로 노출하는 실행 장치다. - 이것은 AI가 디지털 세계에만 머무르지 않고 카메라로 사진을 찍거나, 위치를 확인하거나, 화면을 녹화하는 등 물리 세계와 연결되는 인터페이스를 갖는다는 뜻이다.
- Remote access는 SSH tunnel, tailnet, loopback 중심으로 설계되어 있어, 사용자가 노트북 앞에 앉아 있지 않아도 어디서든 Gateway에 접근할 수 있다.
| OpenClaw 구조 | 단순 챗봇과 다른 점 | 왜 중요한가 |
|---|---|---|
| 단일 Gateway (WebSocket, 포트 18789) | 채널·세션·상태의 중심 허브 | 운영 일관성 확보, 1CPU/1GB로 경량 동작 |
| Multi-agent routing + Bindings | agent마다 workspace, state, sessions 분리 | 역할별 전문화, cross-talk 차단 |
| Mobile/Desktop Nodes | 기기 기능을 에이전트 도구로 노출 | 물리 세계와 연결 |
| Remote access (SSH, tailnet) | 로컬 의존성 제거 | 어디서든 접근 가능 |
| Pairing + allowlist | DM/node 승인 절차 내장 | 접근 권한 통제 |
핵심 포인트: OpenClaw의 혁신은 모델 성능이 아니라 AI를 원격 실행 계층으로 바꿨다는 데 있다. 단일 Gateway가 7개 이상의 메시징 채널, 모바일 노드, CLI, 웹 UI를 하나로 묶고, Multi-agent routing으로 역할을 분리하는 순간 AI는 검색 도우미가 아니라 조직의 운영 시스템이 된다.
2. 왜 보안 문제가 터질 수밖에 없었나
원격 AI 에이전트가 강력하다는 말은 곧 권한이 넓다는 뜻이다. 권한이 넓으면 공격 표면도 넓고, 보안 이슈는 예외가 아니라 구조적 숙명에 가깝다. OpenClaw는 시장을 빠르게 열었지만, 그만큼 문제도 빠르게 드러났다.
2.1 숫자로 보는 OpenClaw 보안 현황
- 2026년 2월 SecurityScorecard STRIKE 팀은 인터넷에 노출된 OpenClaw 인스턴스를 42,900개 이상 발견했고, 이 중 약 15,200개가 원격 탈취에 취약하다고 보고했다. The Register는 노출 수를 135,000개 이상으로 추산했고, 별도 분석에서는 220,000개 이상이라는 수치도 나왔다.
- 2026년 4월 기준으로 추적된 보안 권고(advisory)는 139건이며, 그중 Critical 2건과 High 39건을 포함해 41건이 고위험으로 분류되었다.
- 2026년 2월까지 발견된 악성 skill은 약 900개에 달한다. 단순 의심이 아니라 실제 악성 행위가 확인된 사례다.
- 대표적인 CVE 두 건을 보면, CVE-2026-25253(CVSS 8.8)은 쿼리 스트링의 gatewayUrl 값을 검증 없이 WebSocket 연결에 사용하는 원클릭 RCE 취약점이고, CVE-2026-33579(CVSS 8.1~9.8)은
/pair approve경로에서 caller scope를 제대로 전달하지 않는 권한 상승 취약점이다.
2.2 GitHub 이슈 #56441: child process로 새는 API key
- 이 이슈의 요약은 직설적이다.
models.providers.<name>.apiKey의 resolved key가 startup 시점에process.env에 주입되고, 이후exectool로 spawn된 모든 child process가 이를 inherited environment로 받는다. - Root Cause는 네 단계로 분해된다. provider key가 startup에
process.env에 저장되고, exec 도구가 child process를 spawn할 때 env를 그대로 상속하며,sanitizeHostExecEnv는LD_*같은 위험 변수만 제거하고 provider API key 변수는 건드리지 않고, skill 단위 key 추적 메커니즘(activeSkillEnvEntries)은 skill-injected key만 처리하므로 provider-level key는 빠져나간다. - 영향 범위가 크다. 이미지 생성 전용으로 범위를 제한한 OpenAI API key가
OPENAI_API_KEY라는 이름으로 blogwatcher, git, curl, 임의 스크립트 등 모든 spawned binary에 노출될 수 있다. 오염되거나 침해된 binary가 이 key를 읽어 외부로 유출할 수 있다. - 이슈가 제안한 세 가지 해결 방안 중 Option C(process.env 주입 자체를 제거하고 SDK 생성자에 직접 key 전달)가 가장 근본적이지만, 모든 provider 코드 경로를 감사해야 하므로 공수가 크다. Option A(sanitizeHostExecEnv에 provider key strip 추가)가 최소 변경으로 권장되었다.
2.3 기본 설정의 함정: 노출 인스턴스 폭발
- OpenClaw는 기본적으로 로컬 머신에서 동작하도록 설계되었지만, 많은 사용자가 VPS에 배포하면서 gateway auth를 설정하지 않은 채 인터넷에 그대로 노출시켰다. 공식 보안 문서는 Gateway auth 노출, 브라우저 제어 노출, 과도한 allowlist, 파일시스템 권한, 허술한 exec 승인, 열린 port 등을 주요 footgun으로 경고한다.
- CVE-2026-25253의 경우 hunt.io가 17,500개 이상의 취약 인스턴스를 직접 확인했다. 악성 링크 클릭 한 번으로 원격 코드 실행이 가능한 심각도였다.
- 공급망 오염도 현실화되었다. GitHub에서 OpenClaw를 사칭한 가짜 저장소가 infostealer를 배포하는 사례가 2026년 3월에 보고되었고, 가짜 CLAW 토큰 에어드롭으로 개발자를 유인하는 피싱 공격도 등장했다.
| 보안 문제 | 겉으로는 편의 기능 | 실제 리스크 |
|---|---|---|
| env 기반 key 주입 | SDK 연동 간편 | child process 전체 상속, 비의도적 유출 |
| 기본 설정 노출 | 빠른 시작 가능 | 4만~22만 인스턴스 인터넷 노출 |
| 넓은 exec surface | agent가 다양한 작업 수행 | 악성 binary가 secret 접근 가능 |
| plugin/skill ecosystem | 확장성 증가 | 900건 악성 skill, 공급망 공격면 확대 |
| remote nodes | 기기 제어 가능 | CVE-2026-33579 같은 권한 상승 위험 |
핵심 포인트: OpenClaw 보안 이슈는 단순 실수가 아니라 원격 에이전트 제품군 전체가 맞닥뜨리는 구조적 과제를 드러낸다. 42,900개 이상의 노출 인스턴스, 139건의 보안 권고, 900개 악성 skill, 2건의 Critical CVE는 강력한 실행 권한이 생산성의 원천이면서 동시에 가장 큰 위험이라는 사실을 보여 준다.
3. OpenAI와 OpenClaw: 중요한 것은 법적 형식보다 전략적 신호다
2026년 2월 15일, Sam Altman은 X(구 Twitter)를 통해 OpenClaw 창업자 Peter Steinberger가 OpenAI에 합류한다고 발표했다. Reuters, TechCrunch, Forbes, CNBC 등 주요 매체가 당일 보도했고, Steinberger 본인도 자신의 블로그에서 확인했다.
3.1 거래의 실제 구조
- 이것은 전통적 의미의 기업 인수(acquisition)가 아니라 acqui-hire에 가깝다. Steinberger와 핵심 메인테이너가 OpenAI에 합류하고, OpenClaw 자체는 재단(foundation)으로 이관되어 오픈소스 독립 프로젝트로 유지된다.
- Sam Altman은 발표에서 미래가 극도로 multi-agent적이 될 것이라고 직접 언급했으며, OpenAI가 재단을 계속 지원할 것이라고 밝혔다. 이는 Linux Foundation, Apache Foundation 같은 모델과 유사한 구조다.
- 온라인에서는 acquisition, founder hire, sponsor 등 다양하게 불리지만, 핵심은 OpenClaw 코드가 OpenAI 소유가 된 것이 아니라 재단으로 갔다는 점이다. 오픈소스 프로젝트의 독립성은 유지된다.
3.2 시장이 읽어야 할 전략 신호
- OpenAI 같은 상위 모델 기업도 이제는 실행 프레임워크와 운영 계층을 전략 자산으로 본다. 모델만 잘 만들어서는 부족하고, 그 모델이 실제로 일을 굴리는 구조까지 확보해야 경쟁력이 생긴다.
- LinkedIn에서는 이를 2026년 최대의 전략적 움직임이라고 평가한 글이 수천 건의 반응을 얻었다. 모델 출시가 아니라 한 사람을 영입한 것이 가장 큰 뉴스가 되었다는 사실 자체가 시사적이다.
- 경쟁의 초점이 누가 더 좋은 답변을 하느냐에서 누가 더 많은 실제 작업을 대신하느냐로 이동하고 있다. 모델 경쟁은 언젠가 평준화될 수 있지만, 운영 구조와 워크플로 자산은 쉽게 따라잡기 어렵다.
핵심 포인트: OpenAI와 OpenClaw를 둘러싼 관계에서 진짜 중요한 것은 거래 형식이 아니라, 에이전트 실행 계층이 모델 못지않은 전략 자산으로 인식되기 시작했다는 사실이다. Sam Altman이 multi-agent 미래를 직접 언급한 것이 그 증거다.
4. Hermes는 무엇을 더 잘하려고 나왔나
2026년 2월 25일 Nous Research가 Hermes Agent를 GitHub에 공개했다. 자신을 OpenClaw와 같은 카테고리의 autonomous coding and task-execution agent라고 설명하면서도, provider-agnostic 구조, self-improving skills, persistent memory, profiles, multi-platform gateway를 전면에 둔다. 2026년 4월 현재 81,000개 이상의 GitHub 스타를 기록했고, v0.10.0(2026.4.16)까지 빠르게 릴리스를 이어가고 있다.
4.1 Provider-Agnostic: 20개 이상의 공급자 지원
- Hermes 공식 provider 문서에 따르면 지원 provider는 20개 이상이다. Nous Portal, OpenRouter(200+ 모델), Anthropic(Claude Code 크리덴셜 자동 감지), OpenAI Codex(디바이스 코드 인증), GitHub Copilot(Direct API + ACP 두 모드), Google Gemini(API key + OAuth 두 방식), DeepSeek, Hugging Face(20+ 오픈 모델 자동 라우팅)가 1급 지원된다.
- 중국 AI 공급자도 전용 provider ID로 지원한다. z.ai/GLM, Kimi/Moonshot(국제+중국 엔드포인트 분리), MiniMax(글로벌+중국), Alibaba Cloud/DashScope(Qwen), Xiaomi MiMo, Arcee AI까지 포함된다.
- 로컬 모델도 1급이다. Ollama, vLLM, SGLang, llama.cpp/llama-server, LM Studio 같은 자체 호스팅 서버에 대해 상세한 설정 문서와 context length, tool calling parser 설정까지 공식 문서로 제공한다.
hermes model명령어로 대화형 설정 마법사를 실행하고, 세션 중간에/model openrouter:claude-sonnet-4처럼 빠르게 모델을 전환할 수 있다. 특정 provider 장애 시에는 config.yaml의 ordered fallback list를 따라 자동으로 다음 provider로 전환된다.
4.2 Self-Improving Learning Loop: 4단계 순환 구조
- Hermes의 가장 큰 차별점은 단순 기억이 아니라 학습이다. 공식 문서에 따르면 closed learning loop가 모든 세션 아래에서 돌아가며, memory, skills, session search가 같은 연속 프로세스의 산출물이다.
- 루프의 네 가지 구성 요소는 다음과 같다. Periodic Nudge(설정 간격마다 agent가 최근 활동을 돌아보고 memory에 쓸 가치가 있는 것을 판단), Skill Creation(5회 이상의 tool call, 에러 복구, 사용자 교정, 비자명 워크플로 성공 시
~/.hermes/skills/에 재사용 가능한 절차 문서 생성), Skill Self-Improvement(기존 skill을 사용하다 더 나은 경로를 발견하면 patch로 갱신, 전체 rewrite가 아니라 변경분만 수정해 토큰 효율과 안정성 확보), Session Search(SQLite + FTS5로 과거 세션을 인덱싱하고, 필요할 때 LLM 요약을 거쳐 현재 컨텍스트에 주입). - 이 구조의 실질적 효과는 시간이 지날수록 같은 유형의 작업에 대한 처리 품질과 속도가 올라간다는 것이다. 200개의 skill이 있어도 이름과 요약만 기본 로드하고 실제 내용은 필요할 때만 불러오므로, skill 수가 늘어도 토큰 비용이 거의 일정하다.
4.3 4계층 Memory 아키텍처
- Prompt Memory(MEMORY.md, USER.md): 매 세션 시작 시 시스템 프롬프트에 자동 주입되는 always-on 레이어. 두 파일 합계 3,575자 제한으로 큐레이션을 강제한다. agent가 add, replace, remove 세 가지 연산으로 직접 관리한다.
- Session Archive: SQLite + FTS5 인덱싱으로 과거 대화를 저장하고, agent가 명시적으로 쿼리할 때만 LLM 요약을 거쳐 현재 세션에 주입한다. 에피소딕 메모리(무엇이 일어났는가)를 담당한다.
- Skills(Procedural Memory):
~/.hermes/skills/에 개별 마크다운 파일로 저장되며, agentskills.io 오픈 표준을 따라 다른 호환 agent와 포터블하다. 카테고리 디렉토리, 참조 문서, 템플릿, 스크립트, 에셋을 포함하는 구조화된 포맷이다. - Honcho(User Modeling, 선택): 12개 identity layer에 걸쳐 사용자와 agent를 dialectic 모델링하는 선택적 레이어. 일상적 개인 비서로 쓸 때 응답이 사용자의 실제 작업 방식에 맞춰진다.
4.4 Profiles: 완전 격리된 다중 에이전트 환경
- v0.6.0(2026년 3월 30일)에서 도입된 profiles는 Hermes의 핵심 운영 기능이다. 공식 문서에 따르면 profile은 fully isolated Hermes environment로, 각각 독립된
config.yaml,.env,SOUL.md, memories, sessions, skills, cron jobs, state database를 갖는다. hermes profile create coder를 실행하면 즉시coder chat,coder setup,coder gateway start같은 독립 명령어가~/.local/bin/에 생성된다. 내부적으로는HERMES_HOME환경변수를 profile별 디렉토리로 설정해 119개 이상의 소스 파일이 자동으로 해당 경로를 참조한다.--clone으로 config만 복제하거나,--clone-all로 memory, session history, skills, cron jobs까지 전부 복제할 수 있다.--clone-from옵션으로 특정 profile에서 복제하는 것도 가능하다.- 두 profile이 같은 bot token을 사용하면 token lock이 작동해 두 번째 gateway가 자동 차단되고, 충돌하는 profile 이름을 에러 메시지에 표시한다. Telegram, Discord, Slack, WhatsApp, Signal 모두 지원한다.
hermes profile use coder로 기본 profile을 전환하면 이후 plainhermes명령이 해당 profile을 대상으로 동작한다.kubectl config use-context와 같은 패턴이다.
4.5 메시징 Gateway와 스케줄링
- Hermes의 messaging gateway는 Telegram, Discord, Slack, WhatsApp, Signal, SMS(Twilio), Email, Home Assistant, Mattermost, Matrix, DingTalk, Feishu/Lark 등 12개 이상의 플랫폼을 단일 gateway 프로세스로 지원한다.
- Telegram에서는 Private Chat Topics를 이용한 Project Conversations가 가능하다. 하나의 채팅 안에서 토픽마다 다른 skill 바인딩과 세션 컨텍스트를 유지할 수 있다.
- Cron scheduling은 shell cron이 아니라 agent 태스크로 실행된다. 스케줄된 시간이 되면 agent loop가 memory와 skills에 접근하면서 전체 파이프라인을 돈다. 결과는 gateway를 통해 지정된 플랫폼으로 전달된다.
- Webhook도 지원하므로, 외부 이벤트(서버 알림, CI/CD 트리거 등)가 agent 태스크를 자동 기동할 수 있다.
4.6 hermes claw migrate: OpenClaw 자산 흡수
hermes claw migrate는 OpenClaw(또는 레거시 Clawdbot/Moltbot)의 자산을 Hermes로 자동 마이그레이션한다.~/.openclaw/,~/.clawdbot/,~/.moltbot/디렉토리를 자동 감지한다.- 마이그레이션 대상은 광범위하다. persona(SOUL.md), workspace 지시사항(AGENTS.md), 장기 기억(MEMORY.md, USER.md, daily memory files), 4개 경로의 skills, 모델/provider 설정, provider API keys, 에이전트 동작 설정(max turns, reasoning effort, 압축, human delay, timezone 등), session reset 정책, MCP 서버, TTS 설정, 7개 메시징 플랫폼 토큰(Telegram, Discord, Slack, WhatsApp, Signal, Matrix, Mattermost), 승인 모드, 명령 허용 목록, 브라우저 설정까지 포함한다.
--dry-run으로 미리보기,--preset user-data로 API key 제외,--skill-conflict skip/overwrite/rename으로 skill 충돌 처리 방식 지정이 가능하다.- OpenClaw의 SecretRef(plain string, env template, SecretRef object 세 가지 형식)를 모두 해석하되,
source: file이나source: exec타입은 자동 해석이 불가능하므로 경고를 띄우고 수동 설정을 안내한다.
| Hermes 특징 | 세부 사항 | 왜 중요한가 |
|---|---|---|
| Provider-agnostic | 20+ providers, 200+ 모델, 로컬 서버 지원 | 공급자 리스크 분산 |
| Self-improving loop | 4단계 순환: nudge → skill creation → patch → session search | 시간이 갈수록 효율 상승 |
| 4계층 Memory | prompt memory + session archive + skills + Honcho | 용도별 분리로 정확도 유지 |
| Profiles | 완전 격리 환경, token lock, clone 옵션 | 다중 agent 충돌 없이 운영 |
| Messaging gateway | 12+ 플랫폼, Project Conversations | 어디서든 접근 |
| hermes claw migrate | persona, memory, skills, keys, 7개 플랫폼 토큰 이전 | OpenClaw 자산 보존 |
핵심 포인트: Hermes의 본질은 OpenClaw의 원격 에이전트 비전을 부정한 것이 아니라, 그것을 20개 이상의 provider, 4계층 memory, self-improving skills, 완전 격리 profiles로 재구성한 데 있다. hermes claw migrate의 존재 자체가 OpenClaw 시대의 유산을 흡수하겠다는 명시적 선언이다.
5. 왜 다중 원격 에이전트를 운영하면 격차가 폭발적으로 벌어지나
가장 중요한 질문으로 넘어간다. 왜 어떤 사람은 Telegram 같은 봇 채널에 여러 agent를 붙이는 순간, 다른 사람보다 압도적으로 빨라지는가. 이유는 단순 자동화가 아니라 작업 구조 자체의 변환이다.
5.1 실행자에서 운영자로의 역할 전환
- 에이전트를 안 세팅한 사람은 여전히 모든 일을 자신의 시간 블록 안에서 처리한다. 코드도 보고, 로그도 보고, 문서도 쓰고, 질문도 받고, 리서치도 하고, 스케줄도 기억해야 한다. 모든 실행 비용을 자기 시간이라는 자원으로 지불한다.
- Hermes profiles나 OpenClaw multi-agent routing을 활용해 여러 원격 agent를 구축한 사람은 역할을 쪼갠다. 한 agent는 PR 리뷰 전담, 한 agent는 서버 로그와 배포 상태 감시, 한 agent는 새벽 cron으로 리서치와 요약, 한 agent는 문서/콘텐츠 초안 생성, 한 agent는 Telegram에서 즉시 실행되는 개인 운영 비서 역할을 한다.
- 이때 사람의 역할은 직접 실행에서 요청·배분·검수로 바뀐다. Reddit에서는 Hermes profile 5개를 Telegram에 연결해 각각 다른 프로젝트를 전담시키는 개발자 사례가 이미 공유되고 있다.
5.2 비동기성이 만드는 시간 해방
- 사람이 자는 동안에도 작업이 돈다. Hermes의 cron scheduling은 agent 태스크로 실행되므로, 새벽 3시에 의존성 업데이트를 점검하고 결과를 아침에 Telegram으로 받는 흐름이 가능하다.
- Webhook으로 서버 알림을 받아 agent가 자동 대응하는 구조에서는 사람이 모니터링 화면 앞에 앉아 있을 필요가 없다. 이벤트 발생 → agent 처리 → 결과 보고가 사람 개입 없이 돌아간다.
- 이것은 근무 시간이라는 물리적 제약을 깨는 구조적 변화다. 같은 24시간을 쓰지만, agent가 비동기로 일하는 시간만큼 사람의 유효 작업 시간이 늘어난다.
5.3 병렬성과 누적 문맥이 만드는 복리 효과
- 한 번에 하나의 일만 처리하는 인간과 달리, 여러 agent가 동시에 서로 다른 작업 흐름을 진행한다. Hermes의 profile별 독립 gateway가 이를 구조적으로 뒷받침한다. 각 profile이 자기 systemd/launchd 서비스로 돌아가므로 한 agent의 장애가 다른 agent에 영향을 주지 않는다.
- Hermes의 self-improving skills는 반복 업무를 절차 자산으로 변환한다. 처음에 5회 이상의 tool call이 필요했던 작업이 skill로 저장되면, 다음번에는 그 skill을 참조해 더 적은 단계로 처리된다. 시간이 지날수록 같은 입력에 대한 출력 품질과 속도가 모두 올라간다.
- memory 역시 누적된다. MEMORY.md에 프로젝트 맥락이 쌓이고, session archive에서 과거 패턴을 검색할 수 있으므로, 매번 처음부터 설명하는 비용이 줄어든다. 이것은 신규 팀원에게 매번 온보딩을 하는 것과 5년차 팀원에게 한 줄로 지시하는 것의 차이다.
- 이 세 가지가 결합하면 격차는 선형이 아니라 복리로 벌어진다. 하루에 한두 개 작업을 병렬화하는 것만으로는 별 차이 없어 보이지만, 몇 주, 몇 달 지나면 skills가 쌓이고, routing이 다듬어지고, 각 bot의 역할이 정리되면서, 운영자는 점점 더 적은 입력으로 더 많은 출력을 얻는다.
| 비교 항목 | 일반 개발자 | 원격 AI 에이전트 운영자 |
|---|---|---|
| 역할 | 직접 실행 중심 | 요청·배분·검수 중심 |
| 작업 흐름 | 순차적, 한 번에 하나 | 병렬적, 동시에 여러 흐름 |
| 컨텍스트 | 매번 새로 설명 | memory·skills로 누적 |
| 작업 시간 | 본인이 깨어 있는 동안 | cron·webhook으로 24시간 |
| 반복 업무 | 집중력을 갉아먹음 | skill·cron·bot이 흡수 |
| 채널 전환 | 도구마다 직접 이동 | 한 채널에서 지시, 다른 채널에서 수신 |
| 시간에 따른 변화 | 실력은 선형 성장 | skills·memory 누적으로 복리 성장 |
핵심 포인트: 여러 원격 AI 에이전트를 운영하는 사람은 더 열심히 일하는 사람이 아니라 실행 시스템을 가진 사람이다. 격차는 순간의 생산성이 아니라 비동기성·병렬성·누적 문맥이 만드는 운영 레버리지에서 복리적으로 커진다.
6. 왜 지금 이 구조를 배워야 하나
많은 사람이 원격 AI 에이전트를 얼리어답터 장난감처럼 본다. 그런데 진짜 위험은 반대다. 너무 늦게 배우면 따라잡기 어려운 종류의 도구일 가능성이 크다.
6.1 모델은 교체 가능하지만 운영 철학은 아니다
- 모델은 나중에 바꿀 수 있다. Hermes가 20개 이상의 provider를 지원하고,
/model명령 하나로 세션 중 전환이 가능한 것이 그 증거다. 하지만 어떤 채널로 호출할지, 어떤 agent에 어떤 권한을 줄지, 어떤 작업을 cron으로 넘길지, 어떤 정보를 memory로 남길지, 어떤 반복 절차를 skill로 만들지 같은 운영 판단은 경험으로만 쌓인다. - OpenClaw가 보여 준 #56441 이슈, 4만 건 이상의 노출 인스턴스는 이 구조가 강력한 만큼 운영 역량 없이 쓰면 위험하다는 것을 증명한다. 보안 정책으로 child process와 credentials를 제어하는 능력은 하루아침에 생기지 않는다.
- Hermes가 profiles, provider-agnostic 설계, credential 분리, token lock, migration tooling으로 보완하고 있다는 것은 시장이 이미 운영 가능한 형태로 성숙하고 있다는 신호다. 성숙 초기에 올라타는 것과 이미 정착된 후에 따라가는 것은 학습 곡선이 다르다.
6.2 에이전트 프레임워크 성숙 속도가 빠르다
- OpenClaw는 2026년 1월 말에 공개되어 4월 현재 357,000+ 스타, 1,800+ 기여자를 기록하고 있다. Hermes는 2월 말 공개 후 두 달 만에 81,000+ 스타, 373+ 기여자에 도달했다. 이 속도는 과거 어떤 오픈소스 프로젝트에서도 보기 어려운 수준이다.
- Hermes의 경우 v0.6.0에서 profiles, v0.10.0에서 Tool Gateway가 추가되는 등 2주에 한 번꼴로 구조적 업데이트가 나오고 있다. 지금 배우기 시작하면 성장 곡선을 함께 탈 수 있지만, 1년 뒤에는 축적된 생태계(skills, plugins, 커뮤니티 지식)를 한꺼번에 따라잡아야 한다.
- 이 능력은 단순 AI 사용 능력이 아니라 AI 운영 능력이다. 그리고 에이전트 프레임워크가 빠르게 성숙하는 지금이, 이 능력을 쌓기 가장 좋은 시점이다.
7. 마무리
위에서 살펴본 원격 AI 에이전트의 핵심 내용을 정리하면 다음과 같습니다.
핵심 요약:
- OpenClaw는 GitHub 357,000+ 스타를 기록하며 단일 Gateway, WebSocket control plane, 7개 이상 메시징 채널, Multi-agent routing, 모바일 노드를 통해 AI를 원격 실행 계층으로 바꾼 대표 사례입니다.
- 이 구조는 강력하지만, 42,900개 이상의 노출 인스턴스, 139건의 보안 권고, GitHub 이슈 #56441의 provider API key child process 상속, CVE-2026-25253(RCE), CVE-2026-33579(권한 상승)이 보여 주듯 보안 부담이 구조적으로 크다는 점이 드러났습니다.
- 2026년 2월 OpenAI가 Peter Steinberger를 영입하고 OpenClaw를 재단으로 이관한 것은 에이전트 실행 계층이 모델 못지않은 전략 자산이 되었다는 시장 신호입니다.
- Hermes Agent는 20개 이상의 provider, 4단계 self-improving learning loop, 4계층 memory 아키텍처, 완전 격리 profiles, 12개 이상 메시징 플랫폼, hermes claw migrate를 통해 원격 에이전트 운영을 더 누적 가능하고 더 유연한 구조로 다듬은 프레임워크입니다.
- 다중 원격 agent를 운영하면 사람은 실행자에서 운영자로 이동하고, 비동기성·병렬성·누적 문맥이 만드는 레버리지가 시간에 비례해 복리적으로 생산성 격차를 키웁니다.
- 모델은 교체 가능하지만 운영 철학은 하루아침에 생기지 않으므로, 에이전트 프레임워크가 빠르게 성숙하는 지금이 AI 운영 역량을 쌓기에 가장 적합한 시점입니다.
결국 앞으로 중요한 것은 어떤 모델이 가장 똑똑하냐보다, 누가 더 안전하게 연결하고, 더 많은 일을 원격 에이전트 시스템으로 굴릴 수 있느냐입니다. OpenClaw가 시장을 열었고, Hermes가 구조를 다듬었고, 이 흐름 위에서 운영 역량을 쌓는 사람이 다음 단계의 생산성을 가져가게 됩니다.