Hermes Agent 왜 핫하고, 뭐가 다른가

사람들은 왜 Hermes와 OpenClaw를 쓰는 걸까. 직접 설치해보고 나서야, 이게 전혀 다른 문제를 푸는 도구라는 걸 알게 됐다.

아주 가볍게, Hermes에 대해서 알아보자.

 

1. 왜 실습했는가

실습 동기는 세 가지였다.

첫째, "왜 핫한가"를 직접 확인하고 싶었다. 커뮤니티에서 OpenClaw와 Hermes가 계속 언급되는데, 실제로 써보지 않고 논평하는 건 의미가 없다고 판단했다.

둘째, "Opus면 충분한데 왜 다들 이쪽으로 가는가" 를 이해하고 싶었다. Claude Code + Opus 조합으로 코딩할 때 병목을 느껴본 적이 없었기 때문에, 이 도구들이 어떤 다른 문제를 푸는지가 궁금했다.

셋째, 파운데이션 모델과 에이전트 프레임워크를 직접 분리해서 조합해보고 싶었다. 완제품인 Claude Code를 쓰는 것과, 모델을 선택하고 에이전트를 선택하고 직접 연결하는 것 사이에 어떤 차이가 있는지 체감하고 싶었다.

 

솔직히 말하면, 실습을 마친 지금도 세 가지 질문에 대한 답이 완전히 정리되지는 않았다. 그 열린 상태 그대로 기록한다.

 

2. 같은 카테고리가 아니다

실습 전에 갖고 있던 가장 큰 오해는, Claude Code와 OpenClaw/Hermes를 경쟁 관계로 놓고 비교하려 했다는 점이다. 실제로는 그렇지 않다.

Claude Code는 코드베이스 전체를 이해하는 목적 특화 코딩 에이전트다.
터미널 안에서 코드를 읽고, 수정하고, 테스트하고, PR을 올리는 일을 깊고 정확하게 한다. 좁고 깊은 문제에 최적화되어 있다.

OpenClaw/Hermes는 삶 전체에 걸친 작업 위임을 위한 범용 에이전트다.
WhatsApp으로 명령하면 메일을 보내고, 일정을 잡고, 정보를 조회하고, 24시간 백그라운드에서 돌아간다. 코딩 품질을 비교하는 게 아니라, 애초에 풀려는 문제가 다르다.

 

여기에 더해 Hermes가 핫해진 또 다른 이유가 있다. "사용할수록 더 똑똑해진다"는 것이다. 단, 이 표현은 정확하게 이해할 필요가 있다. 모델 가중치가 학습되는 게 아니다. Hermes Agent는 메모리를 세 레이어로 분리해서 관리한다.

• 현재 세션의 컨텍스트 윈도우(in-context memory)
• 과거 대화와 작업 결과를 벡터 DB에 저장하고 필요할 때 검색해서 꺼내오는 외부 메모리(external memory via RAG)
• 그리고 반복 작업의 패턴을 저장해두고 다음 실행 시 참조하는 절차적 메모리(procedural memory)로 구성

일반 LLM이 매 세션마다 빈 상태로 시작하는 것과 달리, Hermes는 쌓인 이력을 retrieval해서 응답에 반영한다. "똑똑해진다"의 실체는 모델의 진화가 아니라, 개인화된 컨텍스트 데이터베이스가 두터워질수록 retrieval의 정밀도가 높아지는 구조다.

비유하자면 이렇다.

• Claude Code = 매번 새로 브리핑을 받아야 하는 전문 코딩 비서
• OpenClaw/Hermes = 나의 업무 방식, 선호, 이력을 기억하며 점점 손발이 맞아가는 범용 비서

 

3. "24시간 항시 동작"의 실제 의미

OpenClaw와 Hermes를 설명할 때 자주 나오는 문구가 있다. "24시간 항시 동작한다." 이게 처음엔 직관적으로 이해가 안 됐다.

어떤 input도 없이 스스로 뭔가 하는 건가? 에이전트가 자율적으로 움직인다는 건가?

결론부터 말하면, 입력 없이 도는 에이전트는 없다. "24시간 동작"의 핵심은 자율성의 정도 차이가 아니라, input의 출처와 프로세스 생존 방식의 차이다.

 

Claude Code의 구조

기본 모드에서 input 출처는 단 하나다. "사람이 터미널 앞에서 타이핑"이다.

터미널(또는 SSH 세션)을 닫으면 프로세스 그룹에 SIGHUP 신호가 전달되고, Claude Code도 함께 종료된다. 살아있게 하려면 tmux 같은 멀티플렉서로 세션을 유지하거나, 상시 켜진 서버에 올려야 한다.

Claude Code가 CI 트리거나 cron job으로 헤드리스 모드(claude -p)로 실행될 수 있는 건 사실이다. 그러나 이 경우도 패턴은 동일하다: "한 번 호출 → 한 번 실행 → 종료". 세션이 계속 살아서 다음 이벤트를 기다리는 구조가 아니다.

즉, "24시간 항시 동작"은 Claude Code의 기본 설계가 아니다. 사람이 인프라를 더 얹어서 흉내내는 것이다.

OpenClaw/Hermes의 구조

구조 자체가 다르다.

프로세스 생존 방식: 처음부터 백그라운드 데몬(서버)으로 설계되어 있다. 앱을 닫아도 프로세스가 죽지 않는다.

Input의 출처가 다양하다:

• WhatsApp, Telegram, Slack, iMessage 등 8개 이상의 메시징 플랫폼 동시 연결
• 30분마다 작동하는 내부 하트비트 스케줄러
• 외부 시스템의 webhook/이벤트

"30분마다 스스로 알아서 뭔가 한다"는 것도 사실은 처음에 "30분마다 할 일 목록을 체크하라"는 설정 input을 한 번 박아둔 것이다. 그 설정 자체가 input이다. 자율 동작처럼 보이지만, 트리거의 출처가 사람의 타이핑이 아니라 스케줄러일 뿐이다.

정리하면

Claude Code (기본) OpenClaw / Hermes

Input 출처	터미널 타이핑 (또는 CI 1회성)	메신저 + 하트비트 + webhook
프로세스 형태	터미널 종속 포그라운드	독립적인 백그라운드 데몬
상시 동작	tmux + 상시-on 서버 필요	기본 설계가 상시-on

"24시간 항시 동작"의 실제 의미는 이것이다. input을 줄 수 있는 채널이 항상 열려 있고, 그걸 받아먹을 프로세스(데몬)가 항상 살아있다. 자율성의 차이가 아니라, 인프라 설계 철학의 차이다.

 

4. 파운데이션 모델과 에이전트를 직접 조합해보며 알게 된 것

Hermes Agent를 Qwen3.5와 직접 연결해보면서 얻은 가장 큰 수확은 도구 자체의 편의성이 아니었다. 모델과 에이전트 프레임워크 사이의 경계가 어디서 갈리는지를 직접 체감한 것이었다.

Claude Code는 훌륭한 완제품이다. 그러나 완제품은 "왜 이 모델이 도구 호출을 잘하고, 저 모델은 못하는지"를 보여주지 않는다. 파운데이션 모델을 직접 선택하고, 에이전트 프레임워크를 따로 선택하고, 그 둘을 연결해보는 과정에서 도구 호출 신뢰도(tool-calling reliability) 라는 변수가 실제로 존재한다는 걸 체감하게 된다.

Qwen3.5가 왜 tool calling에 강하다고 평가받는지, 모델마다 function calling 포맷(ChatML, Hermes 포맷 등)이 왜 다른지, 에이전트 로직을 다시 쓰지 않고 모델만 교체할 수 있다는 것이 실제로 무슨 의미인지 이걸 사용 설명서가 아니라 직접 손으로 확인하며 느낀 것이 이번 실습의 핵심 가치였다.

 

5. 아직 답을 못 찾은 것들

정리하고 나니 오히려 질문이 선명해졌다.

• 코딩엔 Claude Code + Opus, 그 외 범용 작업엔 Hermes/OpenClaw라는 이분법이 실제 워크플로우에서 지속 가능한가?
• 아니면 이 조합은 아직 내 워크플로우에서는 불필요한 복잡성인가?
• 모델 비종속 아키텍처가 주는 유연성이, 완제품의 통합된 품질을 실제로 넘어서는 시점은 언제인가?