🖼️ 인포그래픽

🖼️ 4컷 인포그래픽

💡 한 줄 요약

Hermes Agent는 단순 질의응답 도구가 아니라, 메모리·스킬·툴·배포 환경을 결합해 마케팅 워크플로를 반복 실행하고 점진적으로 자동화하는 오픈소스 에이전트 운영 프레임워크라는 주장이다.

📌 핵심 요약

• 저자는 Hermes Agent를 “시간이 지날수록 더 유능해지는 자율 운영자”로 설명하며, 챗봇보다 워크플로 실행 프레임워크에 가깝다고 본다.
• Hermes의 핵심은 지속 메모리, 성격 설정, 기본 제공 스킬, 도구 게이트웨이, 다양한 메시징 인터페이스가 하나의 운영 구조로 묶인다는 점이다.
• 저자는 하나의 개인 에이전트에서 시작해 전문 에이전트, 오케스트레이터, 자동화된 에이전트 팀으로 확장하는 4단계 모델을 제안한다.
• 마케팅 관점에서는 SEO, 콘텐츠 배포, 리서치, 개인 비서, 회사 지식 검색, 업무 라우팅 같은 반복 업무를 Hermes 위에 올릴 수 있다고 설명한다.
• 다만 강한 기본값, VPS·Docker·SSH 기반 운영의 학습 곡선, 모델 성능 의존성은 명확한 한계로 제시된다.

🧩 주요 포인트

1. Hermes Agent는 질문에 답하는 도구가 아니라 브라우저 조작, 터미널 실행, 크론 작업, 메시징, 문서 작성·게시까지 연결하는 실행형 에이전트로 소개된다.
2. 저자는 Hermes의 구조를 brain, personality, skillset으로 단순화해 설명하며, 이 세 요소가 하나의 폴더 구조 안에서 운영된다고 본다.
3. 핵심 전략은 처음부터 완성형 자동화 시스템을 설계하는 것이 아니라, 실제 업무를 반복 실행하면서 에이전트가 메모리와 스킬을 축적하게 하는 것이다.
4. 여러 에이전트를 운영할 때는 “control room”을 별도로 두어 에이전트 목록, 역할, 포트, 자격 증명, 실행·복구 방법을 문서화해야 한다고 주장한다.
5. Hermes는 강한 기본값과 번들 스킬로 빠르게 시작할 수 있지만, 세밀한 제어를 선호하는 사용자에게는 무겁게 느껴질 수 있다는 반론 가능성도 인정된다.

🧠 상세 정리

1. 저자의 핵심 thesis: Hermes는 챗봇이 아니라 운영 시스템이다

저자는 Hermes Agent를 “질문에 답하는 AI 도구”가 아니라 “워크플로를 끝까지 실행하는 자율 운영자”로 규정한다. 브라우저를 조작하고, 터미널 명령을 실행하며, 크론 작업을 예약하고, 이메일과 메시징 채널을 확인하고, 초안을 작성한 뒤 결과물을 Telegram, Discord, Slack, 이메일 스레드 등 사용자가 일하는 장소로 전달할 수 있다는 설명이다. 이 관점에서 중요한 차이는 AI를 대화 상대로 보는지, 실행 환경을 가진 작업자로 보는지에 있다. 저자에게 Hermes는 마케팅 운영 전체를 얹을 수 있는 프레임워크다. 특히 반복되는 콘텐츠, SEO, 리서치, 배포, 내부 커뮤니케이션 업무에서는 매번 프롬프트를 새로 쓰는 방식보다, 메모리와 스킬이 누적되는 실행 시스템이 더 큰 복리 효과를 낸다는 주장이다.

2. Hermes의 기본 구조: brain, personality, skillset

저자는 Hermes를 이해하기 쉽게 세 가지 구성요소로 나눈다. 첫째는 brain이다. 메모리는 ~/.hermes/memories/에 존재하고, MEMORY.md와 USER.md가 세션 시작 시 주입된다고 설명한다. 브랜드 노트, 고객 언어, 지난주 수정사항, 사용자의 선호 출력 형식 같은 정보가 다음 작업에도 이어지는 구조다. 둘째는 personality다. soul.md에는 에이전트의 말투와 태도가 담긴다. 같은 기본 메모리를 공유하더라도, 하나는 영업 담당자처럼, 다른 하나는 긴 문장을 선호하는 리서처처럼, 또 다른 하나는 짧게 정리하는 비서처럼 설정할 수 있다는 설명이다. 셋째는 skillset이다. 저자는 Hermes가 GitHub, Obsidian, Google Workspace, Linear, Notion, Typefully, Perplexity, deep research, 브라우저 제어, 웹 스크래핑, 음성, 스케줄링 등 123개 기본 스킬을 제공한다고 주장한다.

3. 기존 방식과의 차이: 직접 스킬을 쓰기보다 실제 업무로 성장시킨다

저자가 강조하는 운영 원칙은 “첫날부터 직접 스킬을 쓰려 하지 말라”는 것이다. 대신 실제 업무를 실행하게 하고, 에이전트가 작업 과정을 관찰하면서 필요한 스킬을 축적하게 하라는 접근이다. 즉, 프롬프트를 먼저 완벽하게 설계하는 방식이 아니라, 업무 수행과 수정의 반복을 통해 시스템을 길들이는 방식이다. 이 차이는 마케팅 업무에서 특히 크다. SEO 글 작성, 광고 크리에이티브 리뷰, 콘텐츠 스프린트, 리드 마그넷 제작 같은 작업은 처음부터 완성된 절차로 존재하지 않는 경우가 많다. 저자는 Hermes를 이런 “아직 정형화되지 않은 업무”의 프로토타이핑 환경으로 보고, 2~3회 실제 작업을 돌리며 드리프트를 교정한 뒤, 전용 워크스페이스에서 프롬프트와 라우팅, 오류 처리를 조정하고, 마지막에 VPS와 Docker, cron으로 배포하는 방식을 제안한다.

4. 마케팅 운영 사례: SEO, 콘텐츠 배포, 회사 brain

저자는 자신이 Hermes로 운영 중인 사례를 여러 개 제시한다. 개인 비서는 Telegram에 연결되어 업무와 개인 영역을 처리하고, 매일 아침 읽을 만한 이메일을 걸러내며, 리마인더와 회의 요약을 담당한다. 별도의 마케팅 프로토타이핑 벤치에서는 리드 마그넷, 광고 리뷰, 콘텐츠 스프린트 같은 새 흐름을 실제 업무로 테스트한다. 가장 구체적인 사례는 SEO 에이전트다. 저자는 키워드 seed에서 게시된 기사까지 이어지는 21단계 파이프라인을 하나의 Docker 컨테이너 안에서 실행한다고 설명한다. 이 구조에는 회사 brain, 오케스트레이터 Hermes Agent, SEO brain, 그리고 research/ideate, production, distribution을 맡는 세 개의 하위 에이전트가 포함된다. 저자가 하나의 컨테이너를 선호하는 이유는 SEO 업무가 순차적이기 때문이다. 리서치가 브리프를 만들고, 브리프가 제작을 이끌며, 제작 결과가 배포로 이어지므로 단계 사이의 상태와 결정 맥락이 끊기면 비용과 오류가 커진다는 주장이다.

5. 하나의 에이전트에서 fleet으로: 4단계 확장 모델

저자는 Hermes 운영을 네 단계로 나눈다. 1단계는 하나의 개인 Hermes Agent를 운영하는 것이다. SOUL.md, MEMORY.md, USER.md를 채우고 Telegram이나 Discord에 연결한 뒤 실제 업무에 사용하면서 메모리와 스킬을 쌓는다. 이 단계에서도 control room은 권장되지만, 주된 목적은 한 에이전트를 안정적으로 쓰는 것이다. 2단계는 직접 대화하는 전문 에이전트들이다. SEO, outbound, design, support처럼 역할이 다른 에이전트를 만들되, 아직 오케스트레이터는 두지 않는다. 저자는 여기서 너무 빨리 오케스트레이터를 도입하는 것을 경계한다. 먼저 각 전문가 에이전트가 실제로 유용한지 검증한 뒤, “하나의 입구”가 필요할 때 오케스트레이터를 추가하라는 설명이다. 3단계는 오케스트레이터와 전문가 에이전트의 조합이다. 오케스트레이터는 control room을 읽어 어떤 에이전트가 존재하는지, 각자의 역할은 무엇인지, 승인 필요 작업과 금지 작업은 무엇인지 파악하고 요청을 라우팅한다. 4단계는 여기에 반복 자동화가 붙은 형태다. 주간 SEO 리포트, 서버 상태 점검, 백업 검증, 크로스 에이전트 업무가 cron 등으로 자동 실행된다. 저자는 이 단계를 “터미널 안의 마케팅 부서”처럼 묘사한다.

6. control room의 의미: 시스템의 brain과 runtime을 분리한다

저자가 특히 강조하는 개념은 agent control room이다. 이는 사용자가 대화하는 에이전트가 아니라, 전체 fleet을 문서화하고 통제하는 폴더 구조다. 어떤 에이전트가 있는지, 무엇을 하는지, 어떤 포트를 쓰는지, 어떤 자격 증명을 참조하는지, 재시작·디버깅·재빌드 방법은 무엇인지가 여기에 정리된다. 이 구분은 단순한 정리 습관이 아니라 운영 전략이다. 저자는 control room을 시스템을 정의하는 brain, 실제 실행 환경을 body로 본다. body는 brain으로부터 다시 만들 수 있지만, brain은 body만 보고 복구하기 어렵다는 논리다. 따라서 여러 에이전트를 VPS에서 운영하려면 런타임과 운영 문서를 분리하고, 오케스트레이터도 이 문서를 읽어 스스로 판단할 수 있게 해야 한다.

7. 한계와 반론 가능성: 기본값, 복잡도, 모델 의존성

저자는 Hermes를 무조건적인 해법으로 제시하지 않는다. 첫 번째 한계는 기본값이 강하다는 점이다. Hermes의 장점은 메모리, 스킬, 도구 사용 방식에 대한 의견 있는 기본값이지만, 모든 단계를 명시적으로 통제하고 싶은 사용자에게는 무겁게 느껴질 수 있다. 저자는 이런 취향에는 OpenClaw가 더 맞을 수 있다고 비교한다. 두 번째 한계는 학습 곡선이다. Level 3과 4로 올라가면 Docker, VPS, SSH, control room 폴더 구조, 오케스트레이터 스킬이 필요하다. 따라서 매일 Level 1 Hermes를 쓰는 경험 없이 곧바로 multi-agent 운영으로 넘어가면 부담이 크다는 설명이다. 세 번째는 모델 성능 의존성이다. Hermes는 좋은 모델을 더 유용하게 만드는 프레임워크이지, 작은 모델을 전략가로 바꾸는 장치는 아니라는 점을 분명히 한다. 저자는 중요한 작업에는 강한 모델을 쓰고, 리서치 스크래핑이나 배치 처리처럼 덜 중요한 작업에는 더 저렴한 모델을 쓰는 식의 구분을 제안한다.

🧾 핵심 주장 / 시사점

• Hermes의 핵심 가치는 대화 능력보다 지속 메모리, 스킬 축적, 도구 실행, 배포 환경이 결합될 때 발생한다.
• 마케팅 자동화는 처음부터 완성형 시스템으로 설계하기보다, 실제 업무 반복을 통해 프로토타입을 성장시키는 방식이 더 적합하다는 주장이다.
• 여러 에이전트를 운영하려면 작업자 에이전트보다 먼저 control room, 역할 정의, 권한 범위, 복구 문서를 갖추는 것이 중요하다.
• 오케스트레이터는 전문가 에이전트가 충분히 검증된 뒤 도입해야 하며, 너무 이른 orchestration은 복잡도만 높일 수 있다.
• Hermes는 강한 기본값을 선호하는 사용자에게 적합하지만, 모든 단계를 직접 제어하려는 사용자에게는 맞지 않을 수 있다.

✅ 액션 아이템

• Hermes를 처음 도입한다면 MEMORY.md, USER.md, soul.md에 비즈니스 정보, 사용자 선호, 에이전트 성격을 분리해 정리한다.
• SEO, 콘텐츠 배포, 리서치, 개인 비서 중 하나의 실제 마케팅 업무를 골라 Hermes에서 2~3회 반복 실행하며 수정사항을 기록한다.
• 여러 에이전트를 만들기 전 /root/agent-control-room 같은 control room 구조에 에이전트 역할, 포트, 자격 증명 참조, 재시작 방법을 문서화한다.
• 오케스트레이터를 도입하기 전에 SEO agent, outbound agent, design review agent 같은 전문 에이전트를 직접 사용해 실제 효용을 먼저 검증한다.

❓ 열린 질문

• Hermes가 작성하거나 축적하는 스킬을 장기간 운영할 때, 품질 관리와 버전 관리는 어떤 방식으로 해야 안정적일까?
• control room 문서가 오래되거나 실제 runtime과 달라질 경우, 오케스트레이터의 판단 오류를 어떻게 감지하고 수정할 수 있을까?
• 마케팅 업무에서 어떤 단계까지 자동화하고, 어떤 지점은 사람의 최종 판단이나 취향 검토로 남겨야 할까?