Hermes Agent를 처음 보면 사람은 보통 이렇게 생각한다.
또 챗봇 하나 나왔네
근데 README와 문서를 조금만 읽어보면 톤이 좀 다르다.
이 프로젝트가 밀고 있는 건 질문 하나 더 잘 답하는 채팅창이 아니라, 에이전트 하나를 더 오래 일하게 붙잡아 두는 운영 구조에 가깝다.
2026년 4월 10일 기준 Hermes 공식 GitHub와 문서가 반복해서 미는 축은 비슷하다.
기억
스킬
메신저 게이트웨이
스케줄 자동화
이 네 개를 한 덩어리로 묶고 있기 때문이다.
그래서 내 눈에는 Hermes가 단순 챗봇보다 운영형 비서 플랫폼처럼 보인다.
공식 GitHub와 문서 기준으로 Hermes는
경험에서 스킬을 만들고,
세션을 넘겨 기억을 이어가고,
Telegram 같은 메신저에서 계속 접근하고,
cron 스케줄까지 기본으로 품으려는 구조다.
그래서 이건 대답형 챗봇보다
오래 굴리는 비서형 시스템에 더 가깝다.
지금 결론
| 질문 | 더 가까운 답 |
|---|---|
| Hermes는 챗봇인가 | 챗봇보다는 운영형 에이전트 플랫폼에 가깝다 |
| 왜 그렇게 느껴지나 | 기억, 스킬, 메신저, 스케줄이 한 제품 안에 같이 들어 있기 때문이다 |
| 무엇이 제일 다르나 | 계속 일하게 만드는 기능 비중이 높다 |
| 누구에게 맞나 | 에이전트 하나를 장기 실행형 비서처럼 키우고 싶은 사람 |
| 누구에겐 안 맞나 | IDE 안에서 짧은 코딩 보조만 원하거나, 강한 통제형 하네스를 직접 짜는 팀 |
짧게 줄이면 이렇다.
- 단순 챗봇은 보통
질문-답변이 중심이다. - Hermes는
기억-행동-재호출-자동화가 중심이다. - 그래서 제품 계위가 다르게 보인다.
이 글에서 내가 직접 본 범위와 문서로 본 범위
이 주제는 여기부터 분리해두는 게 낫다.
내가 직접 오래 굴린 건 Hermes 자체가 아니라 내 볼트 쪽 Jarvis + Harness + LLM Wiki 운영 체계다.
그래서 아래는 실제 체감으로 말할 수 있다.
- 기억층을 따로 두면 세션 워밍업이 빨라진다
- 실행층을 따로 두면 덜 죽는다
- 오케스트레이터를 따로 두면 역할 충돌이 줄어든다
- 메신저 접근과 스케줄이 붙으면 에이전트 성격이 확 바뀐다
반대로 Hermes 자체의 세부 기능은 공식 GitHub README, 공식 docs, 그리고 RELEASE_v0.8.0 기준으로 읽었다.
즉 이 글은 내가 Hermes를 이미 전부 실서비스로 굴렸다 가 아니라, 내가 실제로 굴리는 운영 체계에 Hermes 문서를 대입하면 왜 비서형으로 읽히는지 를 정리한 글이다.
왜 챗봇보다 운영형 비서처럼 읽히나
Hermes docs 첫 화면부터 메시지가 꽤 선명하다.
문서 홈은 Hermes를 self-improving AI agent라고 부르고, 경험에서 스킬을 만들고, 세션을 넘겨 기억을 쌓고, 메신저와 스케줄을 통해 오래 굴릴 수 있다는 점을 전면에 둔다.
GitHub README도 비슷하다.
거기서 핵심 문장은 대략 아래 흐름으로 읽힌다.
- built-in learning loop
- creates skills from experience
- searches its own past conversations
- talk to it from Telegram while it works on a cloud VM
- built-in cron scheduler
이 조합이 중요한 이유는 간단하다.
보통 챗봇은 질문이 오면 답하고 끝난다.
그런데 Hermes가 강조하는 건 질문을 넘어서 에이전트를 어디서, 얼마나 오래, 어떤 기억과 함께, 어떤 채널로 이어서 부를 수 있는가다.
이건 제품 무게중심이 완전히 다르다.
4층 구조로 보면 훨씬 안 헷갈린다
내가 보기엔 Hermes를 이해할 때 4층으로 자르는 게 제일 쉽다.
1. 기억층
이 층은 이전 세션에서 뭘 했는가를 남기는 층이다.
Hermes docs는 persistent memory와 cross-session recall을 전면에 둔다.
README에서도 past conversations search와 deepening user model을 강조한다.
이 말은 결국 매번 새로 만나는 챗봇보다, 이전 맥락을 이어 받는 비서에 가깝다는 뜻이다.
2. 스킬층
이 층은 반복되는 행동을 절차 기억처럼 굳히는 층이다.
Hermes는 경험에서 스킬을 만들고, 사용 중 스킬을 개선한다는 메시지를 아주 강하게 민다.
이건 단순 프롬프트 저장이 아니라 다음에도 이 일을 더 잘하게 만드는 루프를 제품 안에 넣겠다는 선언에 가깝다.
3. 메신저층
이 층은 에이전트를 내가 있는 곳으로 끌고 오는 층이다.
CLI 하나만 있는 도구와 달리 Hermes는 Telegram, Discord, Slack, WhatsApp, Signal 같은 채널을 한 gateway process로 묶는 구조를 민다.
여기서부터 느낌이 바뀐다.
IDE 안에서만 부르는 도구는 아직 작업 보조 느낌이 강하다.
반면 메신저로 이어지면 정말 비서처럼 느껴진다.
내가 있는 채널에서 계속 불러 쓸 수 있기 때문이다.
4. 스케줄층
이 층은 에이전트가 내가 안 불러도 일하게 만드는 층이다.
Hermes docs와 README는 built-in cron scheduling, delivery to any platform, scheduled automations를 강조한다.
이건 진짜로 챗봇과 갈린다.
챗봇은 보통 내가 부르면 답하는 쪽이다.
스케줄이 내장된 에이전트는 이제 나 대신 계속 확인하는 존재 쪽으로 간다.
그래서 운영형 비서로 읽힌다.
이 4층이 한 몸이면 뭐가 달라지나
한 층씩 따로 보면 다 익숙한 기능처럼 보인다.
- 메모리? 다른 데도 있다
- 스킬? 요즘 다 비슷하게 말한다
- 메신저 연동? 봇 만들면 된다
- 스케줄? cron 붙이면 된다
근데 Hermes가 재밌는 건 이걸 제품 한 몸으로 묶으려 한다는 점이다.
한 몸이 되면 사용자 경험도 바뀐다.
예를 들어 어제 Telegram에서 던진 요청 지난주 만든 skill 오늘 아침 자동 실행된 스케줄 지금 CLI에서 이어 받는 세션
이게 같은 에이전트 정체성 안에서 연결되기 시작한다.
바로 이 감각 때문에 운영형 비서처럼 보이는 거다.
내 시스템에 대입하면 왜 더 그렇게 보였나
내 볼트 쪽 운영 체계를 기준으로 보면 레이어가 원래 나뉘어 있다.
- LLM Wiki는 지식층
- Harness는 실행층
- Jarvis는 오케스트레이션 층
이 구조는 통제력이 강하다.
대신 하나의 에이전트가 나를 오래 기억하는 집사처럼 보이기보다는, 역할이 분리된 팀처럼 느껴진다.
그래서 Hermes 문서를 읽으면 차이가 더 또렷하다.
Hermes는 팀 구조보다 한 명의 비서가 점점 커지는 쪽에 가깝다.
내 시스템은 누가 무엇을 맡는지가 중요하고, Hermes는 한 에이전트가 얼마나 지속적으로 일을 이어 가는지가 더 중요해 보인다.
둘 다 맞는 철학이다.
다만 성격이 다르다.
GitHub README에서 특히 강하게 보이는 포인트
공식 GitHub README 기준으로 비서형 느낌을 강하게 만드는 문장은 몇 개가 있다.
1. built-in learning loop
이건 그냥 기능 추가가 아니다.
사용 중에 경험을 스킬로 만들고, 그 스킬을 또 개선한다는 얘기라서, 정적 프롬프트 모음보다 훨씬 더 살아 있는 운영체 느낌이 난다.
2. not tied to your laptop
README는 $5 VPS, GPU cluster, serverless persistence 같은 표현을 같이 쓴다.
이건 개발자에게 아주 중요한 신호다.
이 도구는 노트북 안의 조수보다, 밖에서 계속 살아 있는 개체를 지향한다
3. talk to it from Telegram
이 문장이 꽤 세다.
이건 곧 작업 장소와 호출 장소를 분리한다는 뜻이기 때문이다.
작업은 클라우드 VM에서, 호출은 메신저에서 하는 순간 이미 IDE 챗봇과는 결이 달라진다.
4. built-in cron scheduler
스케줄이 기본 축으로 들어가면 제품은 더 이상 단순 대화 도구가 아니다.
이제 운영 루틴을 맡길 수 있는 후보가 된다.
v0.8.0 릴리즈 노트에서 보이는 운영형 냄새
RELEASE_v0.8.0을 보면 이 제품이 어디에 힘을 주는지 더 잘 보인다.
릴리즈 하이라이트에는 아래가 같이 나온다.
- background process auto-notifications
- live model switching across all platforms
- approval buttons on Slack & Telegram
- centralized logging
- security hardening
이걸 한 줄로 보면 전형적인 운영형 제품 냄새다.
답변 품질만이 아니라, 장시간 작업, 알림, 승인, 로그, 보안이 한 묶음으로 움직이고 있기 때문이다.
특히 Telegram 승인 버튼, background process auto-notifications, inactivity-based timeout 같은 기능은 에이전트를 길게 굴릴 때 필요한 장치들이다.
이건 IDE 코파일럿식 사고보다 항상성 있는 비서 사고에 더 가깝다.
그래서 누가 이걸 좋아할까
맞는 사람
- 에이전트 하나를 여러 채널에서 이어 쓰고 싶은 사람
- 기억과 스킬을 같은 시스템 안에 오래 쌓고 싶은 사람
- Telegram이나 Discord 같은 메신저 기반 호출을 중요하게 보는 사람
- 스케줄 자동화와 비동기 작업을 기본 기능으로 원한 사람
덜 맞는 사람
- IDE 안에서 짧게 코딩 보조만 받고 싶은 사람
- 실행 안정성보다 문답 품질만 중요하게 보는 사람
- 메신저 게이트웨이나 다채널 구조가 오히려 과하다고 느끼는 사람
- 팀 역할 분리형 오케스트레이션을 더 선호하는 사람
TECHTAEK답게 보려면 “언제 안 쓰는가”도 같이 써야 한다
이걸 그냥 멋진 기능 목록으로 쓰면 TECHTAEK 글이 아니라 제품 소개 요약이 된다.
실무 기준으로는 안 쓰는 순간을 같이 적어야 한다.
1. 짧은 코딩 세션이 전부일 때
이 경우엔 CLI 도구나 IDE 에이전트만으로 충분할 수 있다.
기억, 메신저, 스케줄까지 다 품은 플랫폼은 오히려 무겁다.
2. 강한 통제형 하네스를 직접 만들고 있을 때
이미 팀이 승인, 복구, 원장, 로그, 세션 handoff를 세밀하게 설계하고 있다면 플랫폼형 추상화가 답답할 수도 있다.
3. 하나의 비서보다 팀형 분업이 더 중요한 경우
Hermes는 한 명의 개체를 길게 키우는 쪽에 가깝다.
반면 어떤 조직은 전문화된 담당 에이전트들을 나눠 굴리는 편이 더 맞는다.
이 경우엔 Jarvis식 오케스트레이션이 더 자연스러울 수 있다.
실수 TOP 4
1. Hermes를 그냥 “챗봇 하나 더 나온 것”으로 보는 것
그렇게 보면 왜 기억과 메신저와 스케줄이 한몸으로 붙어 있는지 이해가 안 된다.
그러면 제품 포지션을 계속 잘못 읽게 된다.
2. 반대로 모든 걸 다 대신할 거라고 기대하는 것
기억, 스킬, 게이트웨이, 스케줄이 많다는 건 가능성도 크지만 복잡도도 크다는 뜻이다.
비서형 플랫폼은 보통 설정과 관측도 무거워진다.
3. 메모리 기능을 지식 위키와 같은 줄로 보는 것
LLM Wiki는 읽기 좋은 compiled knowledge다.
Hermes 메모리는 행동과 세션 연속성을 위한 기억층에 더 가깝다.
둘을 같은 줄에 놓으면 자꾸 꼬인다.
4. 하네스 문제를 전부 플랫폼 문제로 바꾸는 것
Hermes가 운영형이라고 해서 모든 실행 안정성 문제가 자동으로 사라지는 건 아니다.
복구 규칙, 원본 보호, 승인 정책 같은 건 여전히 별도 설계가 필요할 수 있다.
아주 짧은 비교표
| 항목 | Hermes | Jarvis/LLM Wiki/Harness 조합 |
|---|---|---|
| 기본 성격 | 한 명의 비서를 오래 키우는 쪽 | 역할을 나눠 팀처럼 굴리는 쪽 |
| 기억 | 제품 안에서 세게 통합 | 별도 층으로 분리 |
| 메신저 | 기본 축으로 강함 | 필요할 때 붙이는 편 |
| 스케줄 | 제품 안에 내장 | 별도 하네스/자동화로 분리 |
| 장점 | 연속성, 접근성, 비서감 | 통제력, 책임 분리, 구조 명확성 |
| 주의점 | 복잡도와 안정성 검증 필요 | 조립 비용과 운영 비용이 큼 |
FAQ
Q1. Hermes는 그냥 챗봇이 아니라 에이전트 플랫폼이라고 봐도 되나요?
공식 README와 docs 기준으로는 그렇게 읽는 편이 더 자연스럽다.
기억, 스킬, 메신저, 스케줄이 같이 묶여 있기 때문이다.
Q2. Hermes의 핵심은 모델인가요, 런타임인가요?
내가 보기엔 모델보다 런타임 쪽이 더 핵심이다.
여러 모델을 갈아끼울 수 있다고 말하지만, 제품 개성은 기억과 게이트웨이와 자동화 쪽에서 더 강하게 보인다.
Q3. OpenClaw와는 어떤 관계로 봐야 하나요?
공식 GitHub README 기준으로 Hermes는 OpenClaw 마이그레이션 명령도 제공한다.
즉 완전히 무관한 도구라기보다, 일부 사용자를 흡수하는 운영형 플랫폼 축으로 읽는 게 자연스럽다.
Q4. Hermes가 있으면 LLM Wiki나 Harness는 필요 없나요?
그렇게 단정하면 위험하다.
위키는 읽기 좋은 지식층이고, 하네스는 실행 안정성 장치다.
Hermes가 많은 걸 품고 있어도 이 레이어 구분은 여전히 유효하다.
Q5. 가장 실무적인 한 줄 판단은 뭔가요?
에이전트 하나를 여러 채널에서 오래 비서처럼 굴리고 싶다면 Hermes를 보라.
반대로 역할 분리와 원본 보호가 더 중요하면 오케스트레이션 + 하네스 조합을 먼저 봐라.
Q6. 지금 당장 뭘 확인하면 좋나요?
공식 docs의 Memory, Skills, Messaging Gateway, Cron Scheduling 네 섹션만 먼저 봐도 이 제품의 무게중심이 어딘지 거의 드러난다.