Hermes vs OpenClaw: 코딩 에이전트만 쓰던 개발자를 위한 상주형 에이전트 비교

클로드코드와 코덱스만 써 온 사람이라면 요즘 타임라인에서 "Hermes vs OpenClaw"라는 말을 자주 봤을 것이다. 이름만 보면 또 다른 코딩 도구 싸움 같다. Cursor냐 Windsurf냐, opencode냐 Claude Code냐 하던 흐름의 연장처럼 들린다.

그런데 둘 다 코딩 도구가 아니다. 정확히는 코딩'만' 하는 도구가 아니다. Hermes와 OpenClaw는 클로드코드와 다른 종에 속한다. 클로드코드가 내가 키보드 앞에 앉아 있을 때 옆에서 같이 코드를 짜는 도구라면, 이 둘은 내가 자리를 비운 사이에 혼자 일하는 도구다.

그리고 지난 석 달 사이 이 바닥의 1등이 바뀌었다. 1년 가까이 독주하던 OpenClaw를 신생 프로젝트 Hermes가 약 90일 만에 따라잡았다. 단순히 더 좋은 물건이 나와서가 아니다. 보안 사고가 한몫했다. 이 글에서는 두 도구가 클로드코드와 무엇이 다른지, 둘은 또 서로 어떻게 다른지, 그리고 코딩 에이전트만 쓰던 사람에게 실제로 어느 쪽이 쓸모 있는지를 정리한다.

코딩 에이전트와 상주형 에이전트는 다른 종이다

클로드코드나 코덱스를 떠올려 보자. 터미널을 열고, 프로젝트 폴더 안에서 "이 버그 고쳐줘"라고 말한다. 에이전트가 파일을 읽고 고치고 테스트를 돌린다. 내가 결과를 확인하고 다음 지시를 내린다. 세션이 끝나면 에이전트도 잠든다. 운전석에는 항상 내가 앉아 있고, 에이전트는 내가 핸들을 잡고 있는 동안만 깨어 있다.

Hermes와 OpenClaw는 이 구조를 뒤집는다. 둘 다 내 노트북이 아니라 서버나 작은 VPS, 혹은 집에 둔 미니 PC에서 24시간 돌아간다. 나는 텔레그램 같은 메신저로 말을 건다. 에이전트는 내가 시키지 않아도 정해둔 시각에 스스로 깨어나 일을 하고, 끝나면 메신저로 결과를 보고한다. 항상 켜져 있다는 뜻에서 상주형 에이전트라고 부르겠다.

차이를 한 문장으로 줄이면 이렇다. 클로드코드는 책상 앞에서 같이 일하는 동료고, Hermes와 OpenClaw는 내가 퇴근한 뒤에도 사무실에 남아 일하는 야간 근무자다. 실제로 여러 비교 글이 같은 비유를 쓴다. 클로드코드는 "책상 앞의 데일리 드라이버"이고, Hermes와 OpenClaw는 "자리를 비운 사이 일하는 에이전트"라는 것이다.

여기서 중요한 게 하나 있다. 둘은 경쟁 관계가 아니다. 상주형 에이전트를 깐다고 클로드코드를 버리는 게 아니다. 코드를 직접 붙잡고 파고드는 일은 여전히 클로드코드가 빠르고, 자리를 비운 사이 돌아가는 반복 작업은 Hermes나 OpenClaw가 맡는다. 한 개발자가 같은 저장소 안에서 클로드코드, 코덱스, OpenClaw, Hermes를 시기별로 번갈아 돌렸다는 사례도 있다. 핵심은 이거다. 오래 남는 자산은 코드 저장소와 내가 쌓은 데이터이고, 그 위에 끼우는 도구는 갈아 끼울 수 있는 손잡이일 뿐이다.

그러니 "클로드코드를 Hermes로 바꿀까"는 질문 자체가 어긋나 있다. 맞는 질문은 "내가 자리를 비운 사이 돌릴 일이 있는가, 있다면 그 손잡이로 Hermes가 나은가 OpenClaw가 나은가"다.

OpenClaw: 먼저 자리를 잡은 통제탑

OpenClaw는 이 분야의 맏형이다. PSPDFKit을 만들었던 오스트리아 개발자 Peter Steinberger가 시작했고, 2025년 말부터 폭발적으로 컸다. 2026년 4월 기준 깃허브 스타 34만 5천 개를 넘겼다. 한동안 이 카테고리에서 압도적 1등이었다.

대중에게는 "메신저로 부리는 생활 비서"로 더 알려져 있다. 왓츠앱이나 텔레그램으로 말을 걸면 이메일을 정리하고 일정을 잡고 장을 봐주는 도구. 맞는 설명이지만 절반만 맞다. 그 생활 비서 기능을 떠받치는 속살은 범용 에이전트 통제탑(control plane)이다. 여러 에이전트와 여러 채널을 한곳에서 지휘하는 관제 시스템이라는 뜻이다. 개발자들이 이걸 코딩 에이전트와 같은 선상에서 비교하는 이유가 여기 있다. 생활 자동화든 개발 자동화든, 결국 "여러 작업을 자동으로 굴리는 판"이라는 점은 같기 때문이다.

OpenClaw의 진짜 강점은 두 가지다.

첫째는 생태계의 넓이다. ClawHub라는 스킬 장터가 있다. 커뮤니티가 만든 외부 서비스 연동 기능이 2,800개 넘게 올라와 있고, 명령어 한 줄이면 설치된다. 깃허브, 노션, 슬랙, 캘린더, 쇼핑몰까지 웬만한 서비스는 이미 누군가 연동을 만들어 뒀다. 직접 코드를 짤 필요 없이 가져다 쓰면 된다. 연결되는 메신저와 플랫폼도 22개에 이른다.

둘째는 멀티 에이전트 조율이다. 전문 분야가 다른 에이전트 여럿을 동시에 돌리고, 그 사이의 작업 분배와 세션 격리, 조율을 OpenClaw가 알아서 처리한다. 예를 들어 릴리스 관리 에이전트가 QA 에이전트, 문서 작성 에이전트와 협업하며 슬랙과 깃허브, 이메일을 오가는 식의 구성을 별도 코드 없이 짤 수 있다. 비교 분석을 쓴 Composio는 이 점을 두고 "OpenClaw는 더 나은 통제탑"이라고 못 박았다. 멀티 채널 라우팅, 지속되는 에이전트 팀, 장터 기반 워크플로가 강점이라는 것이다.

요약하면 OpenClaw는 "오늘 당장 돌아가는 것이 많은" 도구다. 같은 분석의 표현을 빌리면 "지금 바로 작동하는 게 필요하면 OpenClaw"다. 넓고, 성숙했고, 검증됐다.

Hermes: 일하면서 스스로 자라는 런타임

Hermes는 도전자다. 오픈소스 AI 연구소 Nous Research가 만들었고, 깃허브 저장소 이름은 nousresearch/hermes-agent다. 저장소 소개 문구가 그대로 정체성을 말해준다. "당신과 함께 자라는 에이전트(the agent that grows with you)."

이 "자란다"는 말이 Hermes의 핵심이자, 가장 오해받는 지점이다. 무슨 신비한 자가 진화가 아니다. 구조는 의외로 담백하다. 하나의 닫힌 학습 루프, 즉 "수행하고(do) 배우고(learn) 개선한다(improve)"를 반복한다.

풀어서 설명하면 이렇다. 어떤 작업을 처음 시킨다. Hermes가 이런저런 도구를 써가며 해낸다. 작업이 끝나면 자기가 거쳐온 과정을 되짚어 본다. 무엇이 통했고 무엇이 헛수고였는지 추린 뒤, 다음에 비슷한 일이 들어오면 바로 꺼내 쓸 수 있게 절차를 스킬 파일로 저장한다. 이 스킬은 사람이 짠 프롬프트가 아니라 에이전트가 직접 쓴 마크다운 문서다. 실제로 ~/.hermes/skills/ 폴더 아래 SKILL.md 형태로 쌓인다. 성과가 나쁜 스킬은 고치거나 갈아엎고, 쓸 만한 건 다듬어 간다. 그래서 오래 굴릴수록 똑같은 일을 점점 더 매끄럽게 처리한다.

기억을 다루는 방식도 다르다. Hermes의 메모리는 세 층으로 나뉜다. 지금 처리 중인 작업의 작업 기억, 지난 작업들을 SQLite에 검색 가능하게 쌓아두는 일화 기억, 그리고 방금 말한 스킬 형태의 절차 기억이다. 새 작업이 들어오면 핵심 정보부터 보고, 부족하면 연관 기억으로, 그래도 모자라면 전체 검색으로 넓혀간다. Composio는 이 방식을 "단계별(core → reachable → vector)"이라 부르며, 무엇이든 통째로 벡터 검색에 밀어 넣어 문맥이 비대해지기 쉬운 OpenClaw와 대비시켰다. 같은 글의 표현으로 OpenClaw의 메모리는 "비대해지기 쉽고", Hermes는 "날렵하고 검색 중심"이다. 군더더기 없이 필요한 것만 꺼내 쓰니 토큰도 덜 먹고 초점도 덜 흐려진다.

나머지 기능은 상주형 에이전트의 기본기다. 정해둔 시각에 작업을 돌리는 크론 스케줄러가 내장돼 있어 "매일 아침 9시에 이걸 해둬" 같은 지시가 가능하다. 큰 작업은 짧게 살았다 사라지는 서브 에이전트로 쪼개 맡긴다. 모델도 가리지 않는다. Claude Sonnet 4.6, OpenAI 모델은 물론 llama.cpp나 Ollama로 돌리는 로컬 모델까지 200종 넘게 붙는다. 하드웨어 문턱도 낮아서 한 달 5달러짜리 VPS에서도 돌고, 늘 켜두고 빠르게 쓰려면 NVIDIA RTX PC나 DGX Spark 같은 로컬 장비에 얹으면 된다.

성적은 화려하다. 출시 석 달이 안 돼 깃허브 스타 14만 개를 모았고, 모델 중개 서비스 OpenRouter에서 가장 많이 쓰이는 에이전트가 됐다. 한 팟캐스트의 표현으로는 "90일 만에 챔피언 OpenClaw를 추월"했다.

여기서 숫자를 정확히 읽어야 한다. 누적 스타는 여전히 OpenClaw(34만 5천)가 Hermes(14만)보다 많다. 스타는 "관심을 받았다"는 지표지 "실제로 쓰인다"는 지표가 아니다. Hermes가 추월한 건 실사용량 쪽이다. 관심의 총량은 OpenClaw가 앞서지만, 지금 사람들이 손에 쥐고 돌리는 빈도는 Hermes가 빠르게 역전했다는 뜻이다. 참고로 Hermes는 아직 버전 0.14대다. 성숙도로 치면 한참 어린 프로젝트라는 뜻이기도 하다.

90일 만의 역전, 절반은 보안 사고였다

신생 도구가 1년 묵은 강자를 석 달 만에 따라잡는 일은 흔치 않다. Hermes가 빨라서만은 아니다. OpenClaw가 휘청인 게 컸다.

2026년 들어 OpenClaw에 심각한 보안 구멍이 잇따라 드러났다. 가장 알려진 건 CVE-2026-25253이다. OpenClaw가 웹소켓 연결의 출처(origin)를 제대로 검증하지 않은 탓에, 악성 웹페이지가 내 PC 안에서 돌고 있는 OpenClaw(ws://127.0.0.1:포트)에 몰래 접속해 인증 토큰을 빼낼 수 있었다. 내 컴퓨터에만 열어둔 인스턴스도 안전하지 않았다는 게 문제였다. 보안 분석가 William Spurlock의 정리에 따르면 인터넷에 노출된 OpenClaw 인스턴스가 13만 5천 개가 넘었고, 그중 5만 개 이상이 원격 코드 실행에 취약했다.

이게 끝이 아니었다. 명령어 주입 취약점(CVE-2026-24763, CVE-2026-25157), 관리자 권한 탈취와 원격 코드 실행으로 이어지는 권한 상승 취약점(CVE-2026-32922, 보안업체 ARMO가 보고)이 함께 도마에 올랐다. 커뮤니티 장터인 ClawHub도 공격 통로가 됐다. "ClawHavoc"이라 불린 공급망 공격 정황이 나오면서, 2026년 2월 이전에 설치한 스킬은 다시 점검하라는 권고까지 붙었다.

OpenClaw 측은 빠르게 패치했다. v2026.1.29, v2026.2.25, v2026.2.26 이후 버전에서 구멍을 메웠고, 5월 말 2026.5.27 업데이트는 아예 보안에 초점을 맞췄다. NVIDIA와 손잡고 악성 스킬을 걸러내는 검사 도구(SkillSpector)도 내놨다. 지금의 OpenClaw가 위험하다는 얘기가 아니다. 다만 한바탕 홍역을 치르는 동안 사람들의 신뢰에 금이 갔고, 그 틈에 Hermes가 비집고 들어왔다.

왜 보안이 이 비교의 중심에 오는지 짚어야 한다. 상주형 에이전트는 권한 덩어리다. 내 이메일을 읽고, 메신저 대화에 접근하고, 토큰을 쥐고, 파일을 만지고, 24시간 켜져 있다. 한번 뚫리면 피해 범위가 코딩 에이전트와 비교가 안 된다. 클로드코드는 내가 세션을 닫으면 잠들지만, 상주형 에이전트는 잠들지 않는다. 공격자에게 열린 창이 계속 열려 있는 셈이다. OpenClaw의 강점인 개방성, 즉 2,800개 장터 스킬과 22개 연동은 그대로 공격 표면이기도 하다.

Hermes는 정반대 설계를 들고 나왔다. 인증을 기본값으로 켜두고, 웹소켓 출처 검증도 기본으로 작동하며, 인증 시도에 횟수 제한을 건다. 무엇보다 스킬을 공개 장터에서 내려받지 않는다. 자기가 직접 만들어 쓴다. 그래서 남이 심어둔 악성 스킬에 당하는 공급망 공격의 통로 자체가 좁다. 2026년 4월 기준 Hermes에는 에이전트 고유의 보안 취약점이 보고되지 않았다. 마침 OpenClaw의 보안 이야기가 흔들리던 순간에, Hermes는 "기본이 안전한" 쪽으로 보였다. 90일 역전의 절반은 여기서 나왔다.

코딩 에이전트만 쓰던 사람에게, 어느 쪽이 쓸모 있나

이제 본론이다. 클로드코드나 코덱스만 쓰던 사람이 상주형 에이전트를 들인다면, Hermes와 OpenClaw 중 무엇을 골라야 할까.

먼저 깔고 갈 전제. 둘 다 클로드코드의 대체재가 아니다. 코드를 깊게 파고드는 일, 큰 리팩토링, 까다로운 디버깅은 책상 앞 도구가 여전히 낫다. 상주형 에이전트는 그 위에 얹는 자동화 층이다. 자리를 비운 사이 돌릴 일이 있을 때 빛난다. 개발자에게 그런 일은 생각보다 많다.

• 매일 밤 저장소를 정리한다. 브랜치를 솎아내고, 커밋 기록에서 변경 이력(changelog)을 뽑는다.
• 의존성을 점검하고 위험한 패키지가 보이면 이슈나 PR을 열어 요약해 둔다.
• CI가 깨지면 실패 원인과 다음 할 일을 메신저로 정리해 보낸다.
• 아침마다 "어제 커밋, 리뷰 기다리는 PR, CI 상태"를 한 장으로 묶어 보고한다.
• 경쟁사나 라이브러리 동향을 오래 조사해 사내 위키에 붙여 둔다.

이런 일은 클로드코드에 매번 시키기엔 번거롭고, 사람이 직접 하기엔 지루하다. 상주형 에이전트가 가장 잘 맞는 자리다.

그 위에서 Hermes와 OpenClaw를 가르는 기준은 의외로 명확하다.

Composio의 결론을 빌리면 "OpenClaw는 생태계의 규모를, Hermes는 반복의 속도를 준다." 그리고 "조율이 문제라면 OpenClaw, 상시 자동화가 문제라면 Hermes"다.

실무로 옮기면 이렇게 갈린다.

혼자 일하는 개발자가 개인 자동화를 깔끔하게 굴리고 싶다면 Hermes가 맞다. 설치 문턱이 낮고, 텔레그램으로 바로 부리고, 쓸수록 스킬이 쌓여 똑똑해지고, 보안 기본값이 안전하다. 하나의 통제 에이전트가 정해진 시각에 백그라운드 작업을 처리하는 그림에 잘 맞는다.

반대로 지금 당장 연동해야 할 서비스가 많거나, 역할이 다른 에이전트 여럿을 팀이나 채널을 가로질러 굴려야 한다면 OpenClaw다. 장터에서 가져다 쓰면 되니 연동을 직접 짤 필요가 없고, 멀티 에이전트 조율이 기본으로 들어 있다. 대신 보안은 내가 책임져야 한다. 패치를 따라가고 권한을 좁히고 장터 스킬을 검증하는 일이 따라붙는다.

한 가지 솔직하게 덧붙이면, 진짜 비용은 소프트웨어가 아니다. 둘 다 공짜 오픈소스다. 진짜 비용은 24시간 도는 서비스를 안전하게 운영하는 일이다. 서버를 띄우고, OAuth 권한 범위를 좁게 잡고, 토큰과 비밀키를 관리하고, 이상 동작을 감시하고, 보안 패치를 제때 따라가야 한다. CVE-2026-25253이 보여주듯, 이 운영을 감당할 자신이 없다면 상주형 에이전트는 아직 이르다. 그럴 땐 책상 앞 코딩 에이전트로 충분하다. Spurlock이 정리한 판단 기준도 같은 말을 한다. "우리 패치 대응 속도(SLA)를 자신 있게 답할 수 없다면 기본이 안전한 Hermes를, 보안 역량이 있고 연동 속도가 급하다면 하드닝 체크리스트와 함께 OpenClaw를." 그리고 그는 못을 박는다. "어느 것도 무조건 최고는 아니다. 각자 맞는 자리가 다를 뿐이다."

결국 던져야 할 질문

코딩 에이전트는 개발자에게 "키보드 앞에서 일을 위임하는 법"을 가르쳤다. 상주형 에이전트는 그 위임을 내가 자리를 비운 시간으로 넓힌다. Hermes냐 OpenClaw냐는 사실 그다음 문제다.

먼저 답할 질문은 따로 있다. 내 작업 흐름 중 어디까지를 사람 없이 돌게 둘 것인가. 그 에이전트에게 토큰과 권한을 얼마나 쥐여줄 것인가. 어떤 행동은 반드시 내 확인을 거치게 할 것인가. 도구가 아무리 똑똑해져도 이 선을 긋는 일은 사람 몫으로 남는다. 90일 만에 1등이 바뀐 이번 사건이 또렷이 보여준 것도 결국 그것이다. 성능이 아니라 신뢰가, 그리고 그 신뢰를 떠받치는 보안 설계가 판을 갈랐다는 사실 말이다.