Hermes Agent 커리큘럼이 잘 정리된 이유 2026 – 개인 AI 비서에서 AI 팀까지 보는 법

Posted on by

Hermes Agent를 공부할 때 설치 명령부터 따라가면 금방 재미있어진다. 그런데 개인 업무에 오래 붙일 생각이라면 첫 질문은 설치가 아니라 “내 일이 어떤 순서로 반복되는가”여야 한다.

2026년 6월 2일 기준 WikiDocs의 에르메스 에이전트(Hermes Agent) 업무 자동화: 나만의 AI 팀 만들기는 이 지점을 꽤 잘 잡고 있다. 책의 최종 편집일은 2026년 5월 6일로 표시되고, 목차는 설치, CLI, provider, 개인비서, 역할형 에이전트, memory, MCP, cron, gateway, skill, 보안, 실제 업무 사례까지 이어진다.

그래서 이 자료는 단순히 “Hermes 사용법 모음”으로 보기보다, 개인 AI 업무 OS를 설계하는 커리큘럼으로 보는 게 낫다. 기능이 많다는 말은 별로 새롭지 않다. 어떤 기능을 어느 순서로 열어야 덜 망하는지가 더 중요하다.

먼저 답부터

WikiDocs 책이 잘 정리됐다고 느껴지는 이유는 기능표가 아니라 운영 순서로 짜여 있기 때문이다. AI 챗봇과 개인비서는 무엇이 다른가, 역할형 에이전트는 어떻게 나눌까, memory와 skill은 어디까지 남길까, cron과 gateway는 어떤 업무부터 붙일까 같은 질문이 앞뒤로 이어진다.

내 기준으로는 이 흐름이 Hermes 공식 문서보다 초보자에게 더 친절하다. 공식 문서는 기능별로 정확한 설명을 주고, WikiDocs는 그 기능을 업무 흐름 안에서 어떤 순서로 이해할지 보여준다. 둘 다 필요하다. 하나는 지도고, 하나는 산책로다. 길치인 우리는 둘 다 있으면 덜 헤맨다.

내가 보는 핵심 차이

Hermes 공식 GitHub는 Hermes를 self-improving AI agent로 소개하고, 경험에서 skill을 만들고, memory를 유지하고, 과거 대화를 검색하고, Telegram 같은 메시징 채널에서도 부를 수 있다는 점을 강조한다. 최신 GitHub 화면 기준으로는 2026년 5월 29일 v0.15.2 릴리스가 latest로 표시된다.

공식 설치 문서도 Linux, macOS, WSL2용 one-line installer와 native Windows installer, Termux 경로까지 안내한다. 즉 “켜는 법” 자체는 점점 쉬워지고 있다. 문제는 켜고 나서다.

WikiDocs가 좋은 부분은 그 다음 질문으로 넘어간다는 점이다. 설치가 끝난 뒤 개인비서가 요청을 받고, 조사형/정리형/실행형 에이전트로 일을 나누고, 기억과 도구와 스킬과 예약 실행을 어떻게 업무 흐름에 붙일지 묻는다. 이게 바로 운영형 사고다.

내 Jarvis 구조와 비교하면

내 로컬 볼트에는 이미 Jarvis + Harness + LLM Wiki + Obsidian 구조가 있다. Jarvis는 사용자의 프론트도어고, LLM Wiki는 지식층이며, agent-runtime과 preflight는 실행층에 가깝다. Obsidian no-focus 규칙은 앱 포커스를 건드리지 않고 파일시스템으로 노트를 만들고 고치는 운영 원칙이다.

그래서 Hermes를 그대로 들여오면 중복되는 부분이 생긴다. Hermes가 메인 창구가 되고 Jarvis도 메인 창구가 되면, 사람 입장에서는 “누구한테 말해야 하지” 문제가 생긴다. AI 팀 만들기 전에 사내 메신저 방부터 난장판 되는 느낌이다.

내 기준의 정답은 대체가 아니라 차용이다. Hermes의 memory, skill, gateway, cron, security 패턴을 보고, 이미 있는 Jarvis/LLM Wiki/하네스 구조에 맞게 번역하는 쪽이 낫다.

Hermes/WikiDocs 축 내 볼트에서 대응되는 축 가져올 판단
AI 개인비서 메인 창구 Jarvis 대체하지 말고 역할만 참고
역할형 에이전트 .claude/agents/ 팀 구조 조사/정리/실행 분리 기준 보강
memory/session/profile LLM Wiki, MEMORY, agent logs 장기 기억과 작업 로그를 분리
skill 운영 .claude/skills/ 후보 skill -> QA -> 운영 skill 단계화
cron/gateway morning, telegram, agent-runtime read-only digest부터 파일럿
보안/승인/격리 preflight, no-focus, secret check 자동 실행 전에 gate 강화

memory는 기억력이 아니라 보관 정책이다

Hermes 공식 memory 문서는 MEMORY.md와 USER.md가 ~/.hermes/memories/에 저장되고, 세션 시작 시 system prompt에 frozen snapshot으로 주입된다고 설명한다. 중간에 memory가 바뀌어도 다음 세션 전까지 prompt에는 반영되지 않는 구조다.

이건 성능 관점에서는 깔끔하다. 하지만 개인 업무 OS 관점에서는 “무엇을 기억하면 안 되는가”가 먼저다. 고객명, 비밀키, 내부 계정, 민감한 가족/건강 정보 같은 건 장기 기억에 들어가면 편의 기능이 아니라 보관 리스크가 된다.

내 볼트에 적용한다면 memory를 세 층으로 나누는 게 낫다. 첫째, AGENTS.md 같은 실행 규칙. 둘째, LLM Wiki 같은 지식층. 셋째, 최근 작업을 남기는 agent log다. 이 셋을 섞으면 다음 세션이 똑똑해지는 게 아니라 기억 창고가 어질러진다.

skill은 자동 학습보다 리뷰 큐가 먼저다

Hermes의 매력은 반복 경험에서 skill을 만들고 개선한다는 점이다. WikiDocs도 반복 업무가 언제 skill이 되는지, 역할형 에이전트별 skill을 어떻게 나눌지, skill을 어떻게 보강하고 QA할지 별도 장으로 다룬다.

여기서 중요한 건 “반복된다”가 곧 “자동 등록해도 된다”는 뜻은 아니라는 점이다. 잘못된 우회 절차도 반복되면 skill이 될 수 있다. 자동화가 습관이 되는 순간, 나쁜 습관도 자동화된다. 이건 좀 무섭다. 컴퓨터가 잔소리 없이 잘못 배운다니, 너무 성실해서 문제다.

내 기준의 skill 운영은 세 단계다. 후보 skill은 에이전트가 제안할 수 있다. 검토 skill은 사람이 보고 샌드박스에서만 돌린다. 운영 skill은 버전, 소유자, 실패 시 롤백 기준을 가진다. 이 정도가 있어야 “self-improving”이 “self-confusing”으로 안 간다.

cron과 gateway는 편의보다 권한이다

Hermes 공식 cron 문서는 hermes cron create "every 2h" "Check server status" 같은 형태로 예약 작업을 만들 수 있고, gateway daemon이 매 60초 scheduler tick으로 due job을 실행한다고 설명한다. 결과는 local, Telegram, Slack, email 같은 여러 채널로 보낼 수 있다.

공식 Slack 문서에서는 SLACK_BOT_TOKEN, SLACK_APP_TOKEN, SLACK_ALLOWED_USERS를 .env에 넣고, allowed users를 Member ID로 제한하라고 안내한다. 보안 섹션은 사용자 allowlist, 위험 명령 승인, 컨테이너 격리, MCP credential filtering, context file scanning 같은 방어층을 설명한다.

이걸 보면 cron과 gateway는 “편하게 메시지 받는 기능”이 아니다. 정기 실행과 외부 채널을 열어주는 권한 표면이다. 그래서 처음 붙일 업무는 아침 브리핑, 문서 QA, RSS/Inbox 분류처럼 읽기 중심이어야 한다.

내가 운영한다면 첫 파일럿은 딱 하나다. 매일 아침 00.Inbox와 최근 LLM Wiki 변경 후보를 읽고, 발행이나 이동 없이 digest 초안만 남긴다. 성공 기준은 “멋진 보고서”가 아니라 “권한 밖 작업을 하지 않았고, 실패 로그가 남았고, 다음 액션이 작다”다.

그대로 가져오면 안 되는 5가지

첫째, 메인 창구를 두 개로 만들면 안 된다. Jarvis가 이미 있다면 Hermes식 개인비서 패턴은 참고하되, 호출 창구는 하나로 유지해야 한다.

둘째, memory를 만능 저장소로 쓰면 안 된다. 장기 규칙, 사용자 선호, 작업 로그, 외부 지식은 저장 위치가 달라야 한다.

셋째, skill을 자동으로 운영 등록하면 안 된다. 반복 업무라도 사람이 QA하기 전까지는 후보 큐에 있어야 한다.

넷째, cron을 바로 전송 자동화로 열면 안 된다. 첫 달에는 초안 생성과 로컬 저장이 더 안전하다.

다섯째, Slack이나 Telegram을 전체 명령권으로 보면 안 된다. 메시징 채널은 편하지만, 편한 입구일수록 allowed users, allowed channels, 승인 루프가 먼저다.

이런 순서로 붙이면 덜 꼬인다

개인 AI 업무 OS에 Hermes 감각을 붙인다면, 나는 아래 순서로 간다. 설치보다 운영 순서가 먼저다.

단계 할 일 통과 기준
1 내 업무를 요청/조사/정리/실행으로 나눈다 한 업무에 책임자가 하나씩 보인다
2 기억할 것과 남기지 않을 것을 나눈다 memory 금지 항목이 문서화된다
3 반복 작업을 후보 skill로만 적는다 실행 권한 없이 절차만 남긴다
4 read-only cron digest를 만든다 파일 수정/외부 전송 없이 보고서만 생성
5 gateway 채널을 하나만 연다 allowed users와 로그 기준이 있다
6 preflight와 리뷰를 붙인다 실패 시 멈추고 이유가 남는다

이 순서면 Hermes의 좋은 감각을 가져오면서도, 이미 있는 Jarvis와 LLM Wiki를 밀어내지 않는다. 새 도구가 들어올 때 제일 위험한 건 기존 체계를 갑자기 촌스럽게 보는 마음이다. 새 장난감 앞에서 인간은 원래 약하다. 나도 안다.

실수 TOP 5

첫 번째 실수는 “Hermes가 좋다”를 “우리 메인 운영체계를 갈아엎자”로 번역하는 것이다. 지금 잘 굴러가는 Jarvis, LLM Wiki, preflight가 있다면 먼저 mapping table을 만드는 편이 낫다.

두 번째 실수는 WikiDocs 목차를 그대로 구현 계획으로 보는 것이다. 목차는 학습 순서이고, 내 업무의 실행 순서는 별도다. 학습은 넓게, 적용은 좁게 가야 한다.

세 번째 실수는 memory와 LLM Wiki를 같은 것으로 보는 것이다. memory는 세션 시작에 바로 주입되는 압축된 개인/작업 힌트에 가깝고, LLM Wiki는 출처와 schema를 가진 지식층이다. 둘을 섞으면 검색도 기억도 흐려진다.

네 번째 실수는 skill을 “프롬프트 저장소”처럼 다루는 것이다. 좋은 skill은 재사용 가능한 절차, 입력 조건, 실패 기준, 검증 방법을 같이 가진다.

다섯 번째 실수는 cron을 성과물 발행까지 바로 연결하는 것이다. 정기 자동화의 첫 목표는 생산량이 아니라 반복 품질 확인이다. 자동 발행은 그 다음이다.

FAQ

Hermes Agent를 지금 설치해야 하나?

설치 자체가 목적이면 굳이 서두를 필요는 없다. 먼저 내 업무에서 반복되는 요청 1개를 고르고, 그 요청이 조사형인지 정리형인지 실행형인지 나누는 게 낫다. 설치는 그 다음이어도 늦지 않다.

WikiDocs 책만 보면 충분한가?

학습 순서를 잡는 데는 좋다. 다만 설치 명령, Slack 설정, memory 동작, cron 옵션, 보안 승인 구조는 공식 Hermes docs와 GitHub README로 확인해야 한다. 특히 Hermes는 릴리스가 빠르게 움직이므로 발행일 기준 확인이 필요하다.

내 Obsidian에는 어떻게 붙이는 게 좋나?

처음에는 Obsidian 파일을 자동 이동하거나 수정하지 말고, 00.Inbox와 LLM Wiki 후보를 읽어서 digest 초안을 만드는 정도가 좋다. no-focus 원칙을 지키면서 파일시스템 기반으로 기록하고, 사람이 승인한 뒤에만 이동/수정하는 흐름이 안전하다.

Hermes와 Claude Code/Codex는 경쟁인가?

완전히 같은 층은 아니다. Claude Code/Codex는 개발 작업과 IDE/코딩 에이전트 흐름에 강하고, Hermes는 memory, skill, gateway, cron을 묶어 장기 운영형 비서처럼 굴리는 쪽에 가깝다. 내 업무 OS에서는 둘을 경쟁시키기보다 역할을 나누는 게 현실적이다.

관련 글

참고 자료