Hermes Agent는 OpenClaw랑 뭐가 다를까? 개인 AI 에이전트에서 회사 OS까지

TL;DR

Hermes Agent는 처음 보면 OpenClaw, Claude Code, Codex CLI 같은 도구들과 같은 줄에 있는 또 하나의 AI CLI처럼 보여요. 그런데 조금 더 써보면 방향이 달라요.

OpenClaw가 “로컬에서 빠르게 AI 에이전트를 붙여 쓰는 도구”에 가깝다면, Hermes는 나를 오래 기억하고, 내가 있는 채널에서 부를 수 있고, 반복되는 작업을 skill로 흡수하는 개인 AI 에이전트에 가까워요.

재미있는 건 이 개인 에이전트 구조가 회사에도 꽤 잘 맞는다는 점이에요. 회사도 결국 Slack, GitHub, AWS, DB, 브라우저, 문서, CLI 사이를 계속 오가며 일하는 하나의 복잡한 작업 환경이거든요.

마인드로직에서는 Hermes를 기존 인포미 운영 봇의 즉시 대체재로 보지는 않고 있어요. 인포미를 운영하면서 배운 것들을 기준으로, Hermes가 개인 에이전트에서 팀의 업무 OS로 어디까지 자연스럽게 확장될 수 있는지 보고 있어요.

처음엔 그냥 “또 다른 에이전트 CLI”인 줄 알았어요

요즘 AI 에이전트 도구가 정말 많아요.

Claude Code, Codex CLI, OpenCode, OpenClaw, Gemini CLI, Cursor, 각종 MCP 호스트들까지. 이름만 보면 다 비슷해 보여요. 터미널에서 명령을 받고, 파일을 읽고, 코드를 고치고, 필요하면 브라우저도 열고, 외부 도구도 붙이고.

그래서 Hermes Agent를 처음 봤을 때도 솔직히 큰 기대는 없었어요.

“이것도 결국 CLI 에이전트 하나 더 아닌가?”

근데 문서를 읽고 직접 붙여보니, Hermes가 강조하는 건 조금 달랐어요. Hermes는 IDE에 붙은 코딩 copilot도 아니고, 특정 API를 감싼 챗봇도 아니에요. 오래 켜두고, 여러 채널에서 부르고, 내가 반복해서 하는 일을 기억하고, 시간이 지나면서 나에게 맞춰지는 에이전트에 가까워요.

이 차이가 생각보다 커요.

대부분의 AI CLI는 내가 터미널을 열었을 때만 존재해요. 반면 Hermes는 내가 작업하는 환경 바깥에 떠 있는 개인 작업자에 가까워요. 집에서는 Telegram으로 물어보고, 회사에서는 Slack에서 부르고, 터미널에서는 직접 작업을 시킬 수 있어요. 같은 memory와 skill을 들고요.

개인 비서가 회사에도 따라 들어오는 느낌이라고 할까요.

인포미를 운영하면서 배운 것들

마인드로직에는 이미 인포미라는 Slack 운영 봇이 있어요. 이름은 봇이지만, 실제로는 작은 운영 시스템에 가까워요.

Slack에서 누군가 멘션하면 그냥 답변만 하는 게 아니에요. thread 단위로 세션을 유지하고, 처음 들어온 thread라면 이전 대화 맥락을 읽고, 이미지나 첨부 파일이 있으면 같이 처리하고, 긴 작업은 중간에 “아직 작업 중”이라고 알려줘요. 답변이 길면 Slack 제한에 맞게 나눠 보내고, 실패해도 로그를 남겨요. 필요하면 다음 요청이 들어왔을 때 이전 작업을 중단하고 새 요청을 처리하기도 해요.

이런 것들은 데모에서는 별로 눈에 띄지 않아요. 하지만 실제 회사 Slack에 붙여보면 이게 전부예요.

예를 들어 누군가 “이 고객 문의 좀 봐줘”라고 했을 때, AI가 답변을 잘 쓰는 것만으로는 부족해요.

어떤 채널에서 온 요청인지 알아야 해요
누가 물어봤는지 알아야 해요
thread 앞부분에서 이미 나온 조건을 놓치면 안 돼요
첨부된 이미지나 파일을 같이 봐야 해요
오래 걸리는 작업이면 사용자가 불안하지 않게 신호를 줘야 해요
최종 답변은 Slack에서 읽기 좋은 형태로 나와야 해요
비용, 로그, 실패 원인은 나중에 추적할 수 있어야 해요

인포미를 운영하면서 느낀 건, 회사용 AI 에이전트의 핵심은 모델 하나가 아니라 주변부라는 거였어요. 라우팅, 세션, 권한, 파일 처리, 관측성, 재시도, 포맷팅, 운영 규칙 같은 것들이요.

Hermes가 흥미로웠던 이유도 여기 있어요. Hermes는 이 주변부를 꽤 진지하게 다루고 있었어요.

Hermes는 개인 에이전트에 더 가깝다

Hermes를 “회사 운영 Agent”라고만 부르면 조금 틀린 설명이 돼요. 출발점은 오히려 개인 에이전트에 가까워요.

공식 문서에서 Hermes는 “lives where you do”라는 방향을 보여줘요. 터미널에서만 쓰는 게 아니라 Telegram, Discord, Slack, WhatsApp, Signal, Email 같은 메시징 채널에서도 같은 에이전트를 부를 수 있어요. 노트북에 묶인 도구가 아니라, 작은 VPS나 클라우드 VM에서 계속 살아 있고, 내가 있는 곳에서 부르는 에이전트에 가까운 거예요.

그래서 Hermes는 개인용으로 자연스러워요. 내 말투를 기억하고, 내가 자주 쓰는 명령을 익히고, 반복되는 작업을 skill로 남기고, 필요하면 cron으로 먼저 움직일 수도 있어요.

그런데 바로 이 지점 때문에 회사에도 잘 맞아요. 회사 업무도 결국 “한 사람이 쓰는 여러 도구”가 “여러 사람이 공유하는 여러 도구”로 커진 형태이기 때문이에요.

개인의 반복 작업이 skill이 되면, 회사에서는 플레이북이 돼요. 개인의 memory가 팀 단위로 정리되면, 운영 규칙이 돼요. 개인이 쓰던 gateway가 Slack에 붙으면, 팀 전체가 같은 에이전트를 부를 수 있어요.

OpenClaw와 Hermes의 차이는 기능 개수가 아니라 방향성이에요

OpenClaw류 도구의 매력은 분명해요. 가볍게 시작하고, 로컬 환경에 붙이고, 필요한 도구를 연결해서 개인 생산성을 올리는 데 좋아요. 개발자 입장에서는 이런 도구가 제일 직관적이에요.

터미널에서 열고, 프롬프트 던지고, 코드 고치고, 끝.

반면 Hermes는 “명령을 잘 수행하는가”보다 “시간이 지나며 나에게 맞춰지는가”에 더 관심이 있어 보여요. 그래서 비교 기준도 조금 달라져야 해요.

OpenClaw를 볼 때는 이런 질문을 하게 돼요.

로컬에서 얼마나 빨리 붙일 수 있나?
코드 작업을 얼마나 편하게 시킬 수 있나?
내 개발 환경과 얼마나 자연스럽게 이어지나?

Hermes를 볼 때는 질문이 조금 바뀌어요.

이 에이전트가 여러 채널에서 같은 정체성을 유지할 수 있나?
한 번 배운 선호와 절차를 다음에도 적용할 수 있나?
memory와 skill이 장기적으로 품질을 높여주나?
MCP뿐 아니라 CLI 도구까지 현실적인 업무 도구로 쓸 수 있나?
cron, subagent, session search 같은 기능이 반복 업무를 줄여주나?
개인 에이전트로 시작해서 팀의 workflow까지 확장할 수 있나?

둘 다 좋은 방향이에요. 다만 OpenClaw가 “가볍게 쓰는 AI 에이전트”에 가깝다면, Hermes는 “오래 데리고 사는 AI 에이전트”에 더 가까워요.

핵심은 memory가 아니라 learning loop예요

Hermes 문서에서 가장 강조하는 표현 중 하나가 self-improving agent예요. 말 그대로 스스로 개선되는 에이전트라는 뜻인데, 처음엔 조금 거창하게 들릴 수 있어요.

근데 실제로 써보면 꽤 현실적인 개념이에요.

에이전트가 어떤 복잡한 일을 처리해요. 예를 들어 운영 DB를 조회하고, Vercel 로그를 확인하고, Slack thread 맥락을 읽고, 고객 응대 초안을 만들었다고 해볼게요.

보통의 에이전트라면 여기서 끝나요. 다음에 비슷한 일이 생기면 다시 처음부터 설명해야 해요.

“이 DB는 read-only야.”
“고객 응대에서는 내부 시스템 용어를 쓰면 안 돼.”
“Slack에서는 링크를 이렇게 써야 해.”
“이런 작업은 코드 변경이 아니라 초안만 줘야 해.”

Hermes는 이런 내용을 memory와 skill로 남길 수 있어요. 단순히 대화 로그를 저장하는 게 아니라, 앞으로도 써먹을 수 있는 사실과 절차로 정리하는 쪽에 가까워요.

공식 문서 기준으로 memory는 꽤 작고 curated 되어 있어요. 무한히 모든 걸 기억하는 방식이 아니에요. 중요한 사실만 좁게 들고 가요. 대신 skill은 절차를 담아요. 어떤 일을 할 때 어떤 순서로 봐야 하는지, 어떤 함정을 피해야 하는지, 어떤 명령을 써야 하는지 같은 것들이요.

이 둘이 합쳐지면 “기억하는 챗봇”이 아니라 “작업 방식을 학습하는 에이전트”가 돼요.

skill은 회사의 플레이북이 될 수 있어요

개인적으로 Hermes에서 제일 마음에 들었던 부분은 skill 시스템이에요.

메모리는 “사실”을 기억하는 데 좋아요.

예를 들면 이런 것들이요.

사용자는 Slack 답변을 간결하게 선호해요
특정 서비스의 운영 DB는 어떤 MCP를 통해 조회해요
고객 응대에서는 내부 기술 용어를 쓰면 안 돼요
Slack에서는 mention된 경우에만 응답해야 해요

반면 skill은 “일하는 방식”을 기억해요.

예를 들면 이런 것들이에요.

QA를 할 때 어떤 계정으로 로그인하고 어떤 페이지를 확인해야 하는지
Vercel preview deployment를 테스트할 때 어떤 순서로 접근해야 하는지
DB export를 할 때 CSV 인코딩을 어떻게 해야 Excel에서 안 깨지는지
GitHub PR을 만들 때 어떤 branch policy와 author rule을 지켜야 하는지
Hermes 자체 설정을 점검할 때 어떤 CLI 명령으로 확인해야 하는지

메모리만 있는 에이전트는 똑똑한 비서에 가깝고, skill이 있는 에이전트는 회사의 운영 플레이북을 조금씩 흡수하는 동료에 가까워져요.

물론 이게 마법처럼 자동으로 완벽해지는 건 아니에요. 잘못된 skill이 쌓이면 오히려 위험할 수도 있어요. 그래서 Hermes를 회사에 도입할 때는 “무엇을 memory로 남기고, 무엇을 skill로 남길지”를 꽤 신중하게 정해야 해요.

근데 방향성 자체는 맞다고 느꼈어요. 회사에서 AI agent를 오래 쓰려면, 결국 다시 설명하지 않아도 되는 일이 많아져야 하거든요.

Hermes가 회사 OS로도 잘 맞는 이유

Hermes가 꼭 회사 운영 에이전트로 태어난 건 아니지만, 회사 OS로 쓰기 좋은 구조를 많이 갖고 있어요.

첫째, 모델에 강하게 묶여 있지 않아요. OpenRouter, OpenAI, Anthropic, Nous Portal, 자체 endpoint 등 여러 provider를 붙이고 바꿀 수 있어요. 회사 입장에서는 이게 중요해요. 모델 품질, 비용, 장애 상황이 계속 바뀌기 때문이에요.

둘째, messaging gateway가 있어요. Slack, Telegram, Discord 같은 채널에서 같은 에이전트를 부를 수 있어요. 회사에서는 Slack이 곧 업무 OS인 경우가 많기 때문에, 에이전트가 Slack thread 안에서 자연스럽게 일할 수 있는지가 중요해요.

셋째, MCP와 CLI를 같이 쓸 수 있어요. MCP는 안전하게 도구를 노출하는 데 좋고, CLI는 이미 회사에 쌓인 운영 습관과 잘 맞아요. gh, aws, acli 같은 도구를 agent workflow 안으로 가져올 수 있다는 건 생각보다 현실적인 장점이에요.

넷째, cron과 subagent가 있어요. 매일 아침 리포트를 보내거나, 배포 상태를 확인하거나, 큰 작업을 여러 갈래로 나누는 일이 가능해요. 이건 개인 비서에게도 좋지만, 팀 운영에서는 더 큰 의미가 있어요.

다섯째, 어디서 실행할지에 대한 자유도가 있어요. 로컬뿐 아니라 VPS, 클라우드 VM, serverless 환경에서도 돌릴 수 있다는 건 “내 노트북이 켜져 있어야만 일하는 에이전트”가 아니라는 뜻이에요.

이런 요소들이 모이면 Hermes는 개인 에이전트이면서 동시에 회사의 얇은 OS가 될 수 있어요. 여기서 OS라는 말은 거창한 운영체제가 아니라, 팀이 반복해서 오가는 도구와 규칙을 한곳에서 이어주는 작업 계층에 가까워요.

마인드로직에서는 이렇게 붙여보고 있어요

현재 마인드로직에서는 Hermes를 바로 기존 인포미 운영 봇의 완전 대체재로 보지는 않고 있어요. 그건 조금 위험한 접근이라고 생각해요.

이미 잘 돌고 있는 production workflow가 있고, 그 안에는 눈에 잘 안 보이는 운영 디테일이 많이 쌓여 있어요. thread 세션 관리, 첨부 파일 처리, Slack 메시지 분할, 긴 작업 heartbeat, 사용량 로깅, 에러 처리, 재시도 정책 같은 것들이요.

그래서 지금은 더 현실적인 방식으로 보고 있어요.

기존 인포미 봇은 검증된 production workflow를 계속 맡기고, Hermes는 MCP-heavy한 조사나 새로운 자동화, Slack thread/file context, 브라우저 QA, 코드 작업 위임 같은 영역에서 먼저 써보는 방식이에요.

구성도 일부러 “회사 Slack에 바로 풀어놓는 AI”처럼 하지 않았어요.

Slack에서는 명시적으로 mention했을 때만 응답하게 해요. 기존 thread라고 해서 아무 말에나 끼어들지 않게요.
DB나 Slack처럼 조심해야 하는 도구는 읽기 중심으로 좁게 열어둬요.
GitHub, AWS, Jira처럼 팀이 이미 CLI로 운영하던 흐름은 그대로 살려요.
인증이 필요한 브라우저 QA나 큰 코드 작업은 별도 도구/worker로 분리해요.
progress message는 공유 채널에서 너무 시끄럽지 않게 줄여요.

이건 기능 자랑이라기보다, 회사에서 AI agent를 Slack에 붙일 때 필요한 안전장치에 가까워요.

개인용 에이전트는 “많이 할 수 있는 것”이 중요하지만, 회사용 에이전트는 “하지 말아야 할 것을 안 하는 것”도 똑같이 중요하거든요.

회사용 Hermes 구성은 대충 이런 그림이에요

개념적으로 보면 지금 보고 있는 구조는 이래요.

Slack / CLI / Messaging Gateway
        ↓
Hermes Agent Runtime
        ↓
Memory + Skills + Session Search
        ↓
Tools + Browser + Cron + Subagents
        ↓
DB(read-only) / GitHub / AWS / Jira / Vercel / Notion / Sentry

여기서 중요한 건 가운데에 있는 Hermes Agent Runtime이에요.

개별 도구만 보면 새롭지 않을 수 있어요. Slack bot도 원래 있었고, MCP도 붙일 수 있고, 브라우저 자동화도 따로 할 수 있고, CLI script도 원래 쓸 수 있었고, cron도 따로 돌릴 수 있어요.

근데 이걸 한 에이전트의 memory와 skill, 그리고 대화 맥락 안에서 같이 다룰 수 있다는 점이 달라요.

예를 들어 Slack에서 누군가 “이 고객 문의 좀 봐줘”라고 하면, Hermes는 단순히 답변 초안을 쓰는 데서 끝나지 않아요. 필요한 경우 DB를 read-only로 조회하고, 관련 로그를 확인하고, 이전에 정리된 고객 응대 규칙을 적용하고, 필요하면 Jira나 GitHub 작업 초안까지 이어갈 수 있어요.

물론 모든 걸 자동으로 하게 두면 안 돼요. 그래서 권한을 나누고, 위험한 작업은 막고, 고객-facing 작업은 초안까지만 만들게 하는 식의 설계가 필요해요.

Hermes가 좋은 건 이런 운영 설계를 할 수 있는 여지가 있다는 점이에요.

OpenClaw가 나쁘다는 얘기는 아니에요

여기서 조심해야 할 게 있어요.

OpenClaw가 별로고 Hermes가 무조건 낫다는 얘기를 하려는 건 아니에요. 둘의 쓰임새가 조금 다르다는 얘기에 가까워요.

OpenClaw는 개인 생산성 도구로 접근하기 좋아 보여요. 로컬 개발 환경에 빠르게 붙이고, 가볍게 실험하고, 개인 workflow에 맞춰 쓰는 쪽에 장점이 있어요.

반면 Hermes는 조금 더 넓게 봐야 해요. 설정할 것도 많고, memory/skill/gateway/tools/cron/provider 같은 개념도 챙겨야 해요. 그냥 설치하고 “코드 고쳐줘”만 시킬 거라면 과하게 느껴질 수도 있어요.

근데 오래 쓸 개인 에이전트나, 팀 단위 에이전트를 생각하면 이 “넓음”이 장점이 돼요.

개인에게는 지속성이고, 회사에게는 통제 가능성이에요. 개인에게는 기억이고, 회사에게는 플레이북이에요. 개인에게는 어디서든 부를 수 있는 비서고, 회사에게는 Slack과 여러 운영 도구 사이를 이어주는 얇은 OS가 될 수 있어요.

결론: 개인 에이전트로 시작해서, 회사 OS까지 갈 수 있는 구조

개인적으로 Hermes와 OpenClaw를 비교하면서 든 생각은 이거였어요.

OpenClaw는 “내가 AI agent를 빠르게 잘 쓰게 해주는 도구”에 가깝고,
Hermes는 “나를 오래 기억하는 개인 에이전트를 만들고, 그 구조를 팀의 작업 환경까지 확장할 수 있는 런타임”에 가까워요.

둘 다 필요할 수 있어요. 그리고 어떤 사람에게는 OpenClaw 같은 가벼운 도구가 더 맞을 수도 있어요.

하지만 내가 쓰는 여러 채널에서 같은 에이전트를 부르고 싶고, 반복되는 작업을 skill로 남기고 싶고, memory와 session search로 맥락을 이어가고 싶고, 나아가 Slack/GitHub/AWS/DB/브라우저를 오가는 팀 업무까지 연결하고 싶다면 Hermes 쪽이 더 자연스러워 보여요.

AI agent 도입에서 결국 중요한 건 데모가 아니에요. 데모는 하루 만에 만들 수 있어요.

진짜 어려운 건 이거예요.

한 달 뒤에도 쓸 수 있는가.
다른 사람이 불러도 같은 규칙을 지키는가.
어제 배운 것을 오늘도 기억하는가.
권한을 넘지 않는가.
그리고 실제 업무 속도에 도움이 되는가.

Hermes는 이 질문들에 꽤 진지하게 답하려는 도구예요.

그래서 당분간은 기존 인포미 운영 봇을 유지하면서, Hermes를 옆에 두고 계속 밀어붙여 보려고 해요. 완전 교체가 목표라기보다는, 어떤 업무는 Hermes가 더 잘하고 어떤 업무는 기존 시스템이 더 안정적인지 확인하는 단계예요.

Hermes를 써보면서 제일 크게 느낀 것도 그거였어요. 좋은 에이전트는 사람을 대체하는 게 아니라, 개인과 팀의 작업 방식을 조금씩 흡수하면서 옆자리에 앉는 도구에 가깝다는 것.