오픈클로와 헤르메스, 에이전트의 진화는 어디로 가나 — 다메섹 교수

오픈클로와 헤르메스, 에이전트의 진화는 어디로 가나

은퇴 교수가 직접 설치해 보고 정리한 심층 가이드

작성: 다메섹 교수 (그린아프로) | 2026년 9월 대상: n8n 자동화를 한 번쯤 만져 본 50~60대 독자, 그리고 "AI 비서"라는 말에 궁금증이 생긴 분

0. 들어가며 — 자동화 다음은 "위임"이다

오늘은 인공지능을 통한 자동화, 그 다음은 뭘까? 에 대해 생각하는 시간입니다. 지난 1년 동안 저는 n8n으로 블로그 10개를 굴리는 자동화를 만들었습니다. 정해진 시간에 기사를 긁어 오고, 클로드가 글을 쓰고, 워드프레스와 블로거에 올리고, 쓰레드와 페이스북에 퍼뜨립니다. 대부분은 잘 돌아갑니다.

문제는 깨질 때입니다. 네이버 API가 갑자기 중단되고, 페이스북 토큰이 만료되고, 어느 노드 하나가 null 값을 받아 조용히 멈춥니다. 그때마다 저는 새벽에 텔레그램 알림을 받고 PC 앞에 앉아 원인을 찾았습니다. 자동화를 만들었는데 정작 사람이 24시간 대기해야 한다면, 그건 반쪽짜리 자동화입니다.

올해 상반기부터 이 빈틈을 메우는 새로운 부류의 도구가 폭발적으로 퍼졌습니다. 오픈클로(OpenClaw) 와 헤르메스 에이전트(Hermes Agent) 입니다. 둘 다 "정해진 레일 위를 달리는 자동화"가 아니라 "상황을 보고 판단해서 움직이는 비서"를 지향합니다. 이 글은 두 도구가 무엇이고, 왜 필요하며, 어떻게 설치하고, 무엇을 조심해야 하는지, 그리고 앞으로 어디로 갈지를 제 실제 경험 위주로 정리한 것입니다.

1. 오픈클로와 헤르메스 — 무엇이 어떻게 다른가

오픈클로(OpenClaw)

2026년 초 개발자 커뮤니티를 뒤집어 놓은 오픈소스 개인 AI 에이전트입니다. 초기에는 다른 이름으로 불리다가 상표 문제로 두 차례 이름을 바꿔 지금의 오픈클로가 되었습니다. 핵심 아이디어는 단순합니다.

https://hermes-ai.net/ko/

내 PC나 서버에 게이트웨이를 하나 띄운다.
왓츠앱, 텔레그램, 디스코드, 슬랙, 아이메시지 같은 내가 이미 쓰는 메신저로 말을 건다.
에이전트가 브라우저를 열고, 파일을 다루고, 명령을 실행하고, 결과를 메신저로 돌려준다.
기능은 스킬(Skill) 이라는 마크다운 문서로 추가한다. 스킬 장터도 있다.

깃허브 스타가 몇 주 만에 수만 개를 넘겼고, 그만큼 사고도 많았습니다. 게이트웨이를 인터넷에 그대로 노출한 사용자가 수천 명 발견됐고, 스킬 장터에 악성 스킬이 올라오는 일도 있었습니다. "무엇이든 할 수 있는 비서"는 곧 "무엇이든 당할 수 있는 비서"이기도 하다는 교훈을 남겼습니다.

헤르메스 에이전트(Hermes Agent)

Nous Research가 공개한 오픈소스 에이전트 프레임워크입니다. 오픈클로가 "내 PC에서 뭐든 하는 만능 비서"라면, 헤르메스는 처음부터 스스로 배우고, 기억하고, 일을 나누어 맡기는 에이전트를 목표로 설계됐습니다.

구분	오픈클로	헤르메스 에이전트
개발 주체	개인 개발자 중심 오픈소스	Nous Research (AI 연구 조직)
언어/구조	TypeScript, 게이트웨이 중심	Python, CLI + 게이트웨이
강점	메신저 연동 폭, 커뮤니티 규모, 스킬 장터	세션 간 기억, 스킬 자가 생성, 위임(delegation), 크론, 200개 이상 모델 교체
접근 방식	"일단 다 해 본다"	"구조를 갖추고 위임한다"
배우기	처음 시작은 쉬움	설정 마법사가 길지만 이후는 체계적

두 도구는 경쟁 관계이면서 서로를 닮아 가고 있습니다. 오픈클로는 보안과 구조를 보강하고 있고, 헤르메스는 메신저 연동을 넓히고 있습니다. 저는 최종적으로 헤르메스를 선택했는데, 이유는 뒤에서 설명할 "에이전트가 에이전트를 부리는" 구조가 헤르메스 쪽에 더 명확히 준비되어 있었기 때문입니다.

2. 헤르메스는 뭐지 — 한 문장으로

헤르메스는 "내 컴퓨터에 상주하는 총무"입니다.

n8n이 "정해진 순서대로 일하는 공장 라인"이라면, 헤르메스는 "라인이 멈추면 원인을 보고, 필요하면 수리공을 부르고, 결과를 사장에게 보고하는 총무"입니다. 구체적으로 이런 것들을 갖추고 있습니다.

기억(Memory) — 어제 나눈 대화, 내가 자주 시키는 일, 내 사이트 구조를 다음 세션에도 기억합니다.
스킬(Skills) — 어떤 일을 한 번 해내면 그 절차를 스스로 문서로 남겨 다음에 재사용합니다. agentskills.io 표준과 호환됩니다.
위임(Delegation) — 큰 일을 하위 에이전트에게 쪼개 맡기고 결과를 모읍니다.
크론(Cron) — "매일 아침 7시에 사이트 상태 점검해서 보고해"가 됩니다.
웹훅(Webhook) — 외부 시스템(제 경우 n8n)이 헤르메스를 깨울 수 있습니다.
홈 채널(Home channel) — 모든 보고가 모이는 메신저 방. 저는 텔레그램입니다.
모델 자유 — 클로드, GPT, 제미나이, 로컬 모델까지 명령 한 줄로 바꿉니다.

3. 왜 필요한가 — n8n이 있는데도

이 질문을 저도 오래 했습니다. 결론은 역할이 다르다는 것입니다.

n8n이 잘하는 것: 같은 일을 같은 순서로 수백 번 반복하기. RSS → 클로드 → 워드프레스 → SNS 같은 파이프라인은 n8n이 훨씬 싸고 안정적입니다. 에이전트에게 이걸 시키면 매번 "생각"을 하느라 토큰만 낭비합니다.

n8n이 못하는 것: 예상 못 한 상황에서의 판단. "오류 코드 401이 떴는데 토큰 만료인지 권한 변경인지 보고, 만료면 갱신 스크립트를 돌리고, 아니면 나한테 물어봐" — 이런 분기는 n8n으로 짜려면 경우의 수마다 노드를 만들어야 합니다. 그리고 다음 달에 새로운 경우가 또 생깁니다.

그래서 제 설계는 이렇습니다.

[n8n]     정해진 파이프라인 (A~E 워크플로) — 여전히 주력
   │ 오류 발생
   ▼
[헤르메스] 진단 → 위임 → 수리 → 보고  — 판단이 필요한 예외 처리
   │
   ▼
[텔레그램] 나에게는 "원인 / 조치 / 결과" 세 줄만 온다

자동화의 마지막 조각은 "더 많은 워크플로"가 아니라 "워크플로를 돌보는 존재" 였습니다.

4. 설치하고 이용하는 방법 — 윈도우 PC 기준

아래는 2026년 8월 제 윈도우 PC에서 실제로 겪은 순서입니다. 헤르메스는 업데이트가 잦으니 명령어 이름은 공식 문서에서 다시 확인하시기 바랍니다. 리눅스/맥/WSL 사용자는 한 줄 설치 스크립트로 훨씬 수월합니다.

4-1. 설치

공식 설치 프로그램을 관리자 권한으로 실행합니다. 일반 권한으로 돌리면 시스템 패키지(ripgrep, ffmpeg 등) 설치 단계에서 "액세스 거부(OS error 5)"가 날 수 있습니다.
설치가 중간에 멈추면 재부팅 → 설치 캐시 폴더 삭제 → 관리자 권한 재실행. 저는 이 순서로 해결했습니다.
설치 확인: hermes doctor "All checks passed"가 나오면 끝입니다.

4-2. 설정 마법사 — 곁길로 새지 않는 요령

hermes setup

마법사가 매우 깁니다(모델 제공자, 터미널 백엔드, 메신저, TTS, 웹검색, 이미지 생성…). 기본값이 로그인이 필요한 포털 쪽으로 잡혀 있어 빈 엔터를 치다 보면 자꾸 로그인 창이 뜹니다. 필요 없는 단계는 목록 맨 아래 "Skip / Leave unchanged" 번호를 정확히 입력하세요. 꼬이면 Ctrl+C 대신 터미널 창을 통째로 닫고 새로 여는 게 확실합니다.

4-3. 모델 연결

hermes model

Anthropic API 키를 넣고 모델을 고릅니다. 저는 판단이 필요한 총무 역할이라 Sonnet급을 썼습니다(루틴 작업은 Haiku급으로 낮추는 방법은 6장에서). 주의: 터미널에서 키를 붙여넣을 때 클립보드 인식 오류로 엉뚱한 글자가 저장되는 경우가 있습니다. 저는 실제로 키가 "SYN" 세 글자로 저장돼서 한참 헤맸습니다. .env 파일을 에디터로 열어 직접 확인하세요.

4-4. 텔레그램 연결 — 홈 채널 만들기

텔레그램에서 @BotFather 에게 /newbot → 봇 이름과 아이디 지정 → 토큰 받기
.env 파일에 텔레그램 토큰과 본인 사용자 ID 입력
가장 흔한 실수: .env의 설정 줄 앞에 #(주석)이 그대로 남아 있으면 "No messaging platforms enabled" 오류가 납니다. #을 지우세요.
게이트웨이 실행: hermes gateway run
텔레그램에서 봇에게 아무 말이나 걸면 답이 옵니다. 그 채팅창에 /sethome 을 입력하면 이 방이 홈 채널이 됩니다. 이후 크론 결과, 웹훅 보고가 모두 여기로 옵니다.

4-5. 항상 켜 두기

게이트웨이는 터미널을 닫으면 죽습니다. 윈도우에서는 nssm 같은 도구로 윈도우 서비스에 등록하면 PC가 켜져 있는 한 상주합니다. 이때 실행 파일 경로는 파이썬 래퍼 스크립트가 아니라 가상환경(venv) 안의 hermes.exe 를 지정해야 합니다. 저는 이걸 몰라 서비스가 조용히 죽는 걸 한나절 겪었습니다.

4-6. 첫 사용 예

텔레그램에 이렇게 보내 봅니다.

"내 워드프레스 사이트 3개 지금 접속되는지 확인해서 표로 보고해"
"매일 아침 7시에 위 점검을 반복해 (크론 등록)"
"어제 내가 시킨 일 요약해 줘" (기억 확인)

5. 주의할 내용 — 토큰 폭탄과 보안

에이전트를 쓰기 시작한 사람들이 가장 먼저 하는 말은 "청구서가 무섭다"입니다. 오픈클로 커뮤니티에서 "하루 만에 수십 달러가 사라졌다"는 글이 넘쳐났던 이유가 있습니다. 왜 그런지 알면 막을 수 있습니다.

5-1. 토큰이 새는 다섯 가지 구멍

컨텍스트 누적 — 대화가 길어질수록 매 요청마다 지난 대화 전체를 다시 보냅니다. 하루 종일 한 세션을 쓰면 요청 하나가 수만 토큰이 됩니다.
하트비트/주기 점검 — "몇 분마다 상태를 확인해라"를 걸어 두면 아무 일 없을 때도 계속 모델을 호출합니다.
도구 호출 루프 — 검색 → 실패 → 재검색 → 실패… 에이전트는 포기를 잘 안 합니다.
서브에이전트 연쇄 — 위임한 에이전트가 또 위임하면 비용이 곱으로 늘어납니다.
큰 파일 통째로 읽기 — 로그 파일 하나를 그대로 던지면 그것만으로 수만 토큰입니다.

5-2. 제한하는 방법 — 제가 실제로 걸어 둔 것

방법	구체적 설정
모델 계층화	총무(판단)는 Sonnet, 루틴 점검·요약은 Haiku. 헤르메스는 작업별로 모델을 바꿀 수 있습니다.
세션 정리	큰 일이 끝나면 `/new` 로 세션을 새로 시작. 필요한 것은 기억(memory)에 남기고 대화는 비웁니다.
스킬로 굳히기	한 번 성공한 절차는 스킬 문서로 저장. 다음부터는 "생각" 없이 절차만 따르므로 토큰이 크게 줍니다.
위임 깊이 제한	하위 에이전트는 1단계까지만, 재시도는 2회까지. 2회 실패면 사람(나)에게 넘깁니다.
크론 주기 현실화	5분마다가 아니라 하루 1~2회. 오류는 n8n 웹훅이 즉시 깨우니 주기 점검은 드물어도 됩니다.
파일은 요약해서	로그를 통째로 주지 말고 "마지막 50줄만" 또는 "ERROR 줄만" 뽑아서 넘기게 스킬에 명시.
API 콘솔 예산 알림	Anthropic 콘솔에서 월 사용 한도와 알림 이메일 설정. 이건 도구 설정이 아니라 지갑 쪽 안전장치입니다.
사용량 눈으로 보기	헤르메스의 사용량/비용 확인 명령을 매주 한 번 봅니다. 숫자를 보면 습관이 바뀝니다.

5-3. 보안 — 오픈클로 사태에서 배운 것

게이트웨이 포트를 인터넷에 직접 열지 마세요. 제 n8n(도커)과 헤르메스(윈도우 호스트)는 host.docker.internal 로 PC 내부에서만 통신합니다.
웹훅에는 반드시 서명(HMAC) 을 겁니다. 서명 없는 요청은 버립니다.
남이 만든 스킬은 설치 전에 마크다운을 직접 읽어 보세요. 스킬은 그냥 글이라 읽으면 무슨 짓을 하는지 보입니다.
API 키, 토큰은 .env에만 두고, 에이전트에게 "키 값을 채팅으로 보여 줘"라고 시키지 마세요. 에이전트는 시키면 합니다.

6. 에이전트가 에이전트를 부린다 — 텔레그램으로 지시하는 구체적 방법

여기가 이 글의 핵심입니다. 제 목표는 "오류 알림"이 아니라 "오류 자가 수리" 였습니다.

6-1. 전체 구조

n8n 워크플로 오류 발생
   │
   ▼
n8n Error Trigger → Code 노드(페이로드 정리) → HMAC 서명 → HTTP Request
   │   (host.docker.internal:8644, X-Hub-Signature-256 헤더)
   ▼
헤르메스 게이트웨이 (웹훅 구독: n8n-error)
   │
   ▼
[총무 에이전트]  "무슨 오류인가?" 진단
   │  위임(delegate)
   ▼
[A/S 에이전트]   ① 워크플로 JSON 백업(git) → ② 수정 → ③ 재실행 → ④ 결과 확인
   │
   ▼
[총무 에이전트]  보고서 작성: 원인 / 조치 / 결과
   │
   ▼
텔레그램 홈 채널로 세 줄 보고

6-2. 준비물

n8n API 키 — 헤르메스가 워크플로를 읽고, 고치고, 다시 실행하려면 필요합니다. n8n 설정 → API에서 발급.
웹훅 구독 — 게이트웨이를 한 터미널에서 실행한 채로, 다른 터미널에서 hermes webhook subscribe 로 n8n-error 경로를 만듭니다. 이때 경로 전용 비밀키를 받습니다. (게이트웨이를 Ctrl+C로 끊고 구독하면 실패합니다. 저는 이걸로 반나절을 썼습니다.)
백업 저장소 — 수정 전 워크플로 JSON을 git 저장소에 커밋하도록 A/S 에이전트에게 규칙을 줍니다. 되돌릴 수 없는 수정은 하지 않게 합니다.

6-3. 텔레그램으로 지시하는 실제 문장들

에이전트에게는 코드가 아니라 업무 지시서를 씁니다. 제가 홈 채널에 실제로 보낸 지시 형식입니다.

총무 역할 정의 (처음 한 번)

너는 내 자동화 시스템의 총무다. n8n-error 웹훅이 오면 다음 순서로 일해라. 1. 오류 메시지와 워크플로 이름을 보고 원인을 한 문장으로 진단한다. 2. 토큰 만료·null 값·API 응답 형식 변경 세 가지 유형이면 A/S 에이전트에게 위임한다. 그 외는 나에게 묻는다. 3. A/S 결과를 받으면 "원인 / 조치 / 결과" 세 줄로 이 방에 보고한다. 4. 같은 워크플로가 2회 연속 실패하면 수리를 멈추고 나를 부른다.

A/S 에이전트 규칙 (위임 시 함께 전달)

수정 전에 반드시 워크플로 JSON을 백업 저장소에 커밋한다. 발행(publish) 노드는 절대 두 번 실행하지 않는다. 재실행은 1회만 한다. 성공·실패와 무관하게 무엇을 바꿨는지 총무에게 돌려준다.

일상 지시 예 - "ganatoday 워크플로 어제 실행 이력 보고, 실패한 게 있으면 위 규칙대로 처리해" - "artsense 파이프라인에서 위키 이미지가 null이면 건너뛰도록 노드 하나 고쳐. 고치기 전에 백업하고 뭘 바꿨는지 알려 줘" - "지난 일주일 A/S 보고서 모아서 어떤 오류가 제일 잦았는지 표로 정리해"

핵심은 에이전트에게 권한과 함께 금지선을 준다는 것입니다. "뭐든 해" 대신 "이 세 가지는 네가 하고, 나머지는 물어봐, 이 한 가지는 절대 하지 마"가 안전하고, 토큰도 아낍니다.

6-4. 첫 성공의 기억

첫 자동 수리가 성공한 날 텔레그램에 이런 보고가 왔습니다.

원인: artsense 워크플로, 위키 이미지 URL이 null이라 중복 제거 노드에서 0건 출력 조치: 백업 후 null 필터 노드 추가, 재실행 1회 결과: 게시 3건 정상 완료

새벽 3시였고, 저는 자고 있었습니다. 그때 "자동화가 드디어 완성됐구나" 싶었습니다.

7. 향후 전략 — 에이전트 시대, 시니어 1인 운영자는 어디에 서야 하나

7-1. 도구가 갈 방향 (2026 하반기 ~ 2027 전망)

에이전트가 운영체제처럼 된다. 오픈클로와 헤르메스 둘 다 "앱"이 아니라 "상주 프로세스"입니다. 앞으로는 PC를 켜면 에이전트가 먼저 깨어 있고, 사람은 메신저로 말만 거는 형태가 표준이 될 것입니다.
스킬이 표준화된다. 이미 agentskills.io 같은 공통 형식이 자리 잡고 있습니다. 한 도구에서 만든 스킬이 다른 도구에서 그대로 돌아가는 시대가 옵니다. 지금 스킬을 마크다운으로 잘 써 두면 도구를 갈아타도 자산이 남습니다.
메신저가 화면이 된다. 대시보드를 여는 대신 텔레그램에 묻습니다. 시니어에게 이건 큰 이점입니다. 새 UI를 배울 필요가 없습니다.
로컬 모델과 클라우드 모델의 혼합. 루틴은 PC 안의 작은 모델이, 판단은 클라우드의 큰 모델이 맡는 구조가 비용 문제의 정답이 될 것입니다.
보안이 승부를 가른다. 오픈클로 사태 이후 "권한 최소화, 서명, 감사 로그"가 기본이 됩니다. 이걸 먼저 갖춘 도구가 살아남습니다.

7-2. 제 운영 전략

n8n은 그대로, 헤르메스는 그 위에. 잘 돌아가는 파이프라인을 에이전트로 바꾸지 않습니다. 에이전트는 예외 처리와 감시 층으로만 씁니다. 이게 비용과 안정성 모두에서 옳습니다.
"하나의 소스, 다중 활용"에 에이전트 층 추가. 지금은 글 하나가 7개 채널로 퍼집니다. 다음은 "채널별 반응을 보고 다음 글 주제를 제안하는" 층입니다. 이건 n8n이 아니라 에이전트의 일입니다.
경험을 곧바로 콘텐츠로. 이 글 자체가 그렇습니다. 설치하며 겪은 실패 하나하나가 블로그 글이 되고, 팟캐스트 에피소드가 되고, 전자책 한 장이 됩니다. 시니어의 경쟁력은 "가장 빨리 배운 사람"이 아니라 "가장 솔직하게 기록한 사람"에게 있습니다.
사람이 하는 일은 두 가지로 줄인다. 방향 정하기, 그리고 금지선 긋기. 나머지는 위임합니다.

7-3. 이제 시작하는 분께

헤르메스든 오픈클로든, 먼저 텔레그램 연결까지만 해 보세요. 그것만으로도 "PC와 대화한다"는 감각이 옵니다.
첫 크론은 하루 한 번 "사이트 살아 있나 확인"이면 충분합니다.
API 콘솔에 월 예산 알림부터 걸어 두세요. 그다음에 실험하세요.
실패를 기록하세요. 그게 다음 사람에게 가장 값진 글이 됩니다.

맺음말

35년 강단에서 마케팅을 가르쳤습니다. 그때 늘 하던 말이 "고객이 아니라 고객의 문제를 보라"였습니다. 은퇴 후 코딩을 배우며 다시 깨닫습니다. 자동화의 문제는 "더 많은 자동화"로 풀리지 않았습니다. 자동화를 돌봐 줄 존재가 필요했고, 그게 에이전트였습니다.

오픈클로와 헤르메스는 아직 어립니다. 이름이 바뀌고, 명령어가 바뀌고, 사고도 납니다. 그래도 방향은 분명합니다. 사람이 시키고, 에이전트가 판단하고, 에이전트가 에이전트를 부리고, 사람에게는 세 줄만 온다. 저는 그 세 줄을 텔레그램으로 받으며, 낚싯대를 챙길 생각입니다.

이 글의 설치 과정과 웹훅·위임 설정의 전체 스크립트는 전자책 「헤르메스 에이전트 완전정복」(크몽)에 정리되어 있습니다. 블로그에는 개념과 경험 중심으로, 전자책에는 명령어와 설정 파일 중심으로 나누어 담았습니다.

강조된 글 오늘 알아본 내용이 도움이 되셨나요? 더 궁금한 점은 댓글로 남겨주세요.

🎨 나만의 예술적 영감을 찾는 여정, 아트코칭-워프프레스와 함께 합니다.

지금 바로 메일침프 뉴스레터를 구독하고 특별한 가이드를 받아보세요!

[무료 구독 신청하기]