Hermes Agent는 2026년 기준 Slack, Telegram, Discord 같은 메시징 채널에서 장기 실행 에이전트를 부를 수 있게 하는 오픈소스 AI 에이전트다. Slack에 붙일 때 핵심은 설치 명령보다 xoxb·xapp 토큰, allowed users, home channel, 메모리, 크론, 승인 루프를 먼저 정하는 일이다.
VPS에 Hermes를 올리고 Slack에서 아침 브리핑, 회의 액션, 이메일 초안, 견적서 같은 업무를 맡긴다는 말은 꽤 달콤하다. 하지만 회사 Slack에 붙는 순간 이건 채팅창이 아니라 업무 권한을 가진 입구가 된다. 설치보다 먼저 볼 건 “잘 되나”가 아니라 “누가 무엇을 시킬 수 있나”다.
이 글은 내가 Hermes를 회사 프로덕션에 직접 올렸다는 후기가 아니다. 2026년 6월 1일 기준 Hermes Agent 공식 GitHub, 설치 문서, Slack 문서, memory·cron·security 문서, 그리고 내 로컬 Blog OS에서 쓰는 권한·로그·preflight 운영 경험을 기준으로 설치 전에 확인할 표를 만든 것이다. 기능 소개는 이미 충분히 많으니, 여기서는 손이 먼저 가기 전에 손목 보호대부터 채우자.
먼저 한 문장으로
Hermes Agent를 Slack에 붙일지 고민한다면 첫 PoC는 “회사 전체 자동화”가 아니라 “제한된 Slack 채널에서 read-only 브리핑 1개를 안전하게 돌리는 것”이어야 한다. VPS 비용이나 설치 시간보다 더 중요한 기준은 토큰을 누가 보관하고, 어떤 Slack 사용자가 명령할 수 있고, 어떤 작업은 사람 승인 없이 절대 실행하지 않는지다.
| 질문 | 첫 기준 |
|---|---|
| 어디에 설치하나 | 개인 노트북보다 테스트용 VPS 또는 격리 컨테이너 |
| Slack에서 누가 부르나 | SLACK_ALLOWED_USERS에 들어간 사용자만 |
| 어떤 토큰이 필요한가 | Bot token xoxb-, App-level token xapp- |
| 무엇부터 맡기나 | 아침 브리핑, 회의 액션 후보, 문서 요약 같은 read-only 작업 |
| 무엇은 막나 | 고객 발송, 결제, 세금계산서 발급, production 변경 |
| 무엇을 남기나 | 실행 시각, 호출자, 사용 도구, 승인 여부, 실패 이유 |
왜 Slack 자동화는 설치보다 권한표가 먼저인가
Hermes Agent 공식 README는 built-in learning loop, skill 생성과 개선, past conversation search, cloud VM/VPS 실행을 전면에 둔다. 공식 문서도 messaging gateway를 통해 Slack, Telegram, Discord 같은 채널에서 같은 에이전트를 부를 수 있다고 설명한다. 이 구조는 개인에게는 편하고, 팀에게는 강력하다.
문제는 강력한 도구일수록 Slack에서 더 쉽게 오해된다는 점이다. Slack 메시지는 가볍다. “어제 회의 정리해줘”는 사람이 보면 요청이지만, 에이전트가 보면 파일 읽기, 채널 히스토리 검색, 메모리 참조, 외부 모델 호출, 결과 전송까지 이어질 수 있다. 같은 문장인데 실행 표면이 갑자기 넓어진다.
그래서 첫 번째 산출물은 설치 성공 스크린샷이 아니라 권한표여야 한다. 어떤 채널에서 어떤 명령을 받을지, DM과 공개 채널의 응답 기준을 어떻게 다르게 둘지, bot이 초안만 만들지 실제 전송까지 할지 먼저 적어야 한다. 이 표가 없으면 Slack의 편의성이 운영 리스크를 예쁘게 포장한다. 포장이 예쁘면 더 위험하다. 뜯기 전까지 사고인지 선물인지 모른다.
설치 흐름은 짧지만 운영 흐름은 길다
공식 설치 문서는 Linux, macOS, WSL2에서 one-line CLI installer를 제공한다. Windows native 설치도 문서화되어 있고, CLI, gateway, cron scheduler, MCP servers 같은 기능이 Windows에서도 동작한다고 설명한다. 설치만 보면 “2분 컷”이라는 말이 나올 만하다.
그런데 회사 업무용 PoC에서는 설치 명령보다 환경 분리가 먼저다. 개인 노트북에서 바로 팀 Slack으로 연결하면 테스트와 운영이 섞인다. 권장 흐름은 테스트용 VPS 또는 별도 컨테이너, 테스트 Slack app, 제한된 채널, 제한된 allowed users, read-only 작업 1개다. 처음부터 회사 전체 workspace에 초대하는 건 입사 첫날 전사 관리자 권한을 주는 느낌이다. 인사팀도 놀라고 서버도 놀란다.
실제 첫 주 작업은 단순해야 한다. Hermes를 설치하고 hermes setup으로 provider를 연결한 뒤, Slack app manifest를 만들고, 토큰과 allowed user를 넣고, gateway를 foreground로 띄워 DM과 테스트 채널에서만 확인한다. 이 단계에서 성공 기준은 “대답했다”가 아니라 “권한 없는 사용자는 무시했고, channel invite 전에는 채널 히스토리를 읽지 않았고, 실패 로그가 남았다”가 되어야 한다.
Slack 연결에서 먼저 막히는 지점
Hermes의 공식 Slack 문서는 Socket Mode를 기준으로 설명한다. Socket Mode는 public HTTP endpoint가 아니라 WebSocket으로 연결되므로, Hermes 인스턴스가 꼭 공개 URL을 가질 필요는 없다. 방화벽 뒤 노트북이나 private server에서도 가능하다는 장점이 있다.
대신 Slack app 설정에서 놓치기 쉬운 지점이 많다. Bot Token Scopes에는 chat:write, app_mentions:read, channels:history, groups:history, im:history, im:read, im:write, users:read, files:read, files:write 등이 등장한다. App-level token에는 Socket Mode 연결을 위한 connections:write가 필요하다. 그리고 scope를 나중에 바꾸면 app을 다시 install해야 적용된다.
운영자가 꼭 기억할 토큰은 두 개다. xoxb-로 시작하는 Bot User OAuth Token은 메시지 전송과 Slack API 호출에 쓰이고, xapp-로 시작하는 App-Level Token은 Socket Mode WebSocket 연결에 쓰인다. 둘 중 하나라도 빠지면 “봇이 조용하다”는 증상이 나온다. 조용한 봇은 귀엽지 않다. 대부분 설정이 빠진 것이다.
allowed users는 보안 장식이 아니다
Hermes Slack 설정에서 가장 먼저 눈에 들어와야 하는 값은 SLACK_ALLOWED_USERS다. 공식 문서는 Slack member ID를 allowlist에 넣는 구조를 설명한다. 사용자명이나 표시명이 아니라 U01... 형태의 member ID가 기준이다.
이 값은 보안 장식이 아니라 비용과 권한의 문지기다. 팀 Slack에서 누구나 에이전트에게 긴 작업을 시킬 수 있으면 모델 비용이 새고, 더 위험하게는 권한 있는 bot을 통해 내부 데이터 접근이 넓어진다. 특히 에이전트가 memory, skills, tools, cron을 함께 가진다면 “질문 가능한 사람”과 “실행을 유도할 수 있는 사람”을 같은 말로 보면 안 된다.
첫 PoC에서는 allowed users를 1명으로 시작하는 게 낫다. 그 다음 운영자 1명, 리뷰어 1명까지 넓힌다. 채널도 SLACK_ALLOWED_CHANNELS나 설정 파일의 channel allowlist로 좁힐 수 있다면 더 좋다. 공개 채널에서는 @mention이 있을 때만 답하게 하고, DM도 pairing이나 ignore 정책을 확인한다. Slack은 편한 문이지만, 문이 많으면 자물쇠도 많아야 한다.
memory와 cron은 켜기 전에 정책을 써야 한다
Hermes persistent memory 문서는 MEMORY.md와 USER.md를 통해 agent notes와 user profile을 관리하고, 세션 시작 시 system prompt에 frozen snapshot으로 주입되는 방식을 설명한다. 이건 장기 운영에서 강력하다. 매번 같은 설명을 반복하지 않아도 되고, 환경 관례나 선호를 기억하게 만들 수 있다.
하지만 회사 Slack에서는 memory가 곧 보관 정책이다. 회의록, 고객명, 계약 조건, 내부 URL, 장애 원인, 조직 정보가 무심코 memory에 들어가면 “편리한 기억”이 아니라 “감사해야 할 데이터 저장소”가 된다. 첫 PoC에서는 memory에 넣어도 되는 항목과 금지 항목을 따로 써야 한다.
Cron도 비슷하다. 공식 문서는 /cron add 30m, hermes cron create "every 2h" 같은 형태의 scheduled task를 제공하고, gateway daemon이 scheduler tick으로 due job을 실행한다고 설명한다. 이 기능으로 매일 아침 Slack 브리핑을 만들 수 있다. 동시에 매일 아침 잘못된 데이터를 자동 전송할 수도 있다. 그래서 cron은 처음부터 전송까지 열지 말고, “요약 초안 생성 -> 사람 확인 -> 전송” 흐름으로 두는 편이 안전하다.
첫 업무는 아침 브리핑 하나면 충분하다
영상 요약 노트는 Hermes를 VPS에 설치해 Slack과 연결하고, 회사 맥락을 적재해 아침 브리핑, 회의 액션 추출, 견적서, 세금계산서, 이메일 대응까지 자동화하는 흐름을 제안한다. 방향 자체는 매력적이다. 다만 PoC에서는 너무 많은 업무를 한꺼번에 올리면 실패 원인을 분리하기 어렵다.
첫 업무는 “매일 아침 테스트 채널에서 어제 회의록과 이슈를 읽고 브리핑 초안을 만든다” 정도가 좋다. 읽을 데이터 위치, 실행 시간, 출력 채널, 승인자, 실패 시 동작을 모두 표로 적을 수 있기 때문이다. 틀려도 외부 고객에게 나가지 않고, 사람이 고치기 쉽고, 반복 가치도 있다.
반대로 첫 달에 열지 말아야 할 작업도 선명하다. 고객에게 직접 메일 보내기, 견적서 확정 발송, 세금계산서 발급, 결제 API 호출, production 설정 변경, 개인정보가 섞인 데이터 요약은 보류한다. 에이전트는 일을 잘할 수 있지만, 법무와 회계의 심장을 단련시키는 도구가 되면 곤란하다.
비용은 VPS보다 모델 호출과 재시도가 더 크다
Hermes README는 $5 VPS에서도 돌릴 수 있다는 메시지를 보여준다. 이 문장은 설치 장벽을 낮추는 데 좋지만, 회사 운영 비용을 VPS 월요금 하나로 보면 안 된다. 실제 비용은 모델 provider, Slack에서 반복되는 긴 context, cron 재시도, 첨부 파일 처리, 실패 디버깅 시간에서 나온다.
비용표는 세 줄이면 시작할 수 있다. 첫째, 고정 인프라 비용이다. VPS, storage, backup, monitoring이 여기에 들어간다. 둘째, 모델 호출 비용이다. provider별 입력·출력 토큰, 긴 Slack thread, memory injection, tool 결과가 영향을 준다. 셋째, 운영 비용이다. 토큰 교체, scope 변경 후 재설치, gateway 장애, 로그 점검, 승인 대기 시간이 여기에 들어간다.
내가 Blog OS를 굴릴 때도 비슷했다. 비싼 건 모델 이름 하나가 아니라 재작업이었다. preflight 없이 발행하면 나중에 수정, 시트 정합성, 텔레그램 알림, 내부링크까지 다시 손봐야 한다. Hermes Slack PoC도 처음부터 비용 상한과 중단 조건을 둬야 한다. 예를 들어 하루 모델 호출 30회, cron 실패 2회, 동일 thread context 1만 토큰 초과 같은 기준을 정해두면 사고가 표정 관리할 틈이 줄어든다.
승인 루프를 어디에 넣을까
Slack 자동화의 핵심은 “사람을 빼는 것”이 아니라 “사람이 확인해야 할 지점을 줄이고 선명하게 만드는 것”이다. 모든 작업에 승인 버튼을 붙이면 자동화가 답답해진다. 반대로 모든 작업을 자동 실행하면 업무가 너무 신나서 혼자 멀리 간다.
승인 루프는 작업 위험도별로 나누는 편이 좋다. read-only 요약은 자동 실행해도 된다. 내부 초안 작성은 자동 생성하되 사람이 전송한다. 외부 발송, 돈, 계약, 고객 데이터, production write는 사람 승인 없이는 실행하지 않는다. 이 기준은 Hermes만의 문제가 아니라 모든 Slack형 AI 에이전트의 기본선이다.
아래 표처럼 시작하면 실무 대화가 빨라진다.
| 작업 | 자동 실행 | 사람 승인 | 금지/보류 |
|---|---|---|---|
| 회의록 요약 | 가능 | 필요 시 | 민감 회의 제외 |
| 아침 브리핑 초안 | 가능 | 전송 전 확인 권장 | 외부 전송 금지 |
| 이슈 분류 | 가능 | 대량 변경 전 확인 | 자동 close 금지 |
| 이메일 답장 초안 | 초안만 | 발송 전 필수 | 자동 발송 금지 |
| 견적서/세금계산서 | 초안 또는 검토 자료만 | 확정 전 필수 | 자동 발급 금지 |
| production 변경 | 보류 | 별도 change process | Slack 명령 실행 금지 |
PoC 체크리스트
Hermes Agent를 Slack과 VPS에 붙이기 전 체크리스트는 아래처럼 두면 된다. 이 표를 채우지 못하면 설치를 미루는 게 낫다. 설치는 도망가지 않는다. 권한 사고는 가끔 뛰어온다.
| 구분 | 체크 질문 | 완료 기준 |
|---|---|---|
| 호스트 | 어디에서 실행하나 | 테스트 VPS 또는 격리 컨테이너 |
| provider | 어떤 모델/API를 쓰나 | 키 보관 위치와 월 상한 확인 |
| Slack app | manifest/scopes/events가 정리됐나 | DM, channel, files 범위 문서화 |
| 토큰 | xoxb, xapp를 어디에 두나 |
.env와 secret rotation 기준 확인 |
| 사용자 | 누가 명령할 수 있나 | SLACK_ALLOWED_USERS 최소 인원 |
| 채널 | 어느 채널에서 응답하나 | 테스트 채널 1개부터 시작 |
| memory | 무엇을 기억하나 | 고객정보·비밀키·민감정보 금지 |
| cron | 무엇을 정기 실행하나 | 초안 생성까지만 자동 |
| 로그 | 무엇을 남기나 | 호출자, 도구, 결과, 실패 이유 |
| 중단 | 언제 멈추나 | 비용 초과, 실패 반복, scope 오류 |
내 기준의 채택 판단
Hermes Agent를 Slack에 붙이는 건 충분히 시도할 만하다. 특히 팀이 이미 Slack에 업무 맥락을 많이 남기고 있고, 반복 브리핑이나 회의 액션 추출 같은 작업이 많다면 PoC 가치가 있다. 다만 이 글의 기준으로는 “회사 운영 자동화”보다 “Slack에 들어온 제한된 운영 도우미”로 시작하는 편이 맞다.
기존 TECHTAEK 글에서 Hermes를 운영형 비서 4층 구조로 보고, LightAgent·Hermes 같은 오픈소스 에이전트를 회사 업무에 붙일 때 권한·메모리·스킬·로그를 먼저 보자고 정리했다. 이번 글은 그 다음 단계다. “그래서 Slack에 붙이면 어디서 막히나”를 설치 전 체크표로 좁힌다.
내가 실제 운영한다면 첫 달 목표는 자동화 성공이 아니라 실패 표본 수집이다. 어떤 scope가 빠졌는지, 어떤 사용자가 권한 밖 요청을 했는지, cron이 어느 상황에서 실패했는지, memory에 넣으면 안 되는 문장이 무엇인지 기록한다. 처음 한 달은 에이전트를 똑똑하게 만드는 기간이 아니라, 사람과 에이전트 사이의 안전 난간을 세우는 기간이다.
실수 TOP 5
첫 번째 실수는 Slack app을 만들자마자 회사 전체 채널에 초대하는 것이다. 테스트 채널 1개, allowed user 1명, read-only 작업 1개로 시작해야 원인 추적이 가능하다.
두 번째 실수는 SLACK_ALLOWED_USERS를 나중에 보려는 것이다. allowed users는 옵션이 아니라 시작 조건이다. 이 값이 비어 있거나 너무 넓으면 비용과 권한이 같이 샌다.
세 번째 실수는 memory를 편의 기능으로만 보는 것이다. 장기 기억은 팀의 데이터 보관 정책과 연결된다. 무엇을 기억하지 않을지 먼저 정해야 한다.
네 번째 실수는 cron으로 바로 공개 채널 전송까지 하는 것이다. 첫 달에는 초안 생성까지만 자동화하고, 전송은 사람이 눌러야 한다. 특히 고객명, 장애, 매출, 계약 같은 단어가 섞인 브리핑은 더 조심해야 한다.
다섯 번째 실수는 비용을 VPS 월요금으로만 보는 것이다. Slack thread가 길어지고 cron이 반복되고 provider 오류로 재시도가 붙으면 모델 호출과 운영 시간이 더 커진다. 작은 월요금이 큰 재작업을 숨기지 못하게 해야 한다.
FAQ
Hermes Agent를 Slack에 붙이면 public server가 꼭 필요한가?
공식 Slack 문서는 Socket Mode를 사용한다고 설명한다. Socket Mode는 WebSocket 기반이라 Hermes 인스턴스가 public HTTP endpoint를 노출하지 않아도 된다. 다만 gateway 프로세스가 안정적으로 살아 있어야 하므로, 개인 노트북보다 테스트 VPS나 관리 가능한 서버가 운영에는 더 낫다.
Slack에서 꼭 필요한 토큰은 무엇인가?
Bot User OAuth Token인 xoxb- 토큰과 App-Level Token인 xapp- 토큰이 핵심이다. xoxb-는 메시지 전송과 Slack API 호출에, xapp-는 Socket Mode 연결에 쓰인다. 둘 중 하나가 빠지면 봇이 응답하지 않거나 연결 자체가 되지 않을 수 있다.
Hermes memory는 켜도 되나?
켜도 되지만 정책이 먼저다. 공식 memory 문서는 MEMORY.md와 USER.md를 통해 환경 사실, 사용자 선호, 배운 점을 관리하는 구조를 설명한다. 회사 Slack에서는 고객정보, 비밀키, 개인정보, 계약 조건 같은 항목을 memory에 남기지 않는 기준이 필요하다.
cron으로 매일 아침 Slack 브리핑을 보내도 되나?
가능하지만 첫 PoC에서는 “초안 생성”까지만 자동화하는 편이 안전하다. 공식 cron 문서는 gateway daemon이 스케줄러를 돌려 due job을 실행한다고 설명한다. 정기 실행은 편한 만큼 stale 데이터나 잘못된 요약이 반복 전송될 수 있으므로 사람 확인 단계를 두는 게 좋다.
Hostinger VPS 같은 저렴한 VPS면 충분한가?
간단한 gateway와 read-only PoC는 저렴한 VPS로도 시작할 수 있다. 다만 실제 비용은 VPS보다 모델 provider 호출, 긴 Slack thread context, cron 재시도, 로그 관리, 장애 대응 시간이 더 크게 작용할 수 있다. 월 비용 상한과 중단 조건을 같이 정해야 한다.
첫 업무로 무엇을 맡기는 게 좋나?
회의록 요약, 아침 브리핑 초안, 이슈 분류, 문서 중복 탐지처럼 틀려도 사람이 쉽게 확인할 수 있는 read-only 작업이 좋다. 고객 발송, 결제, 세금계산서 발급, production 변경처럼 외부 영향이 있는 작업은 첫 달에 열지 않는 편이 안전하다.
관련 글
- LightAgent·Hermes 같은 오픈소스 AI 에이전트를 회사 업무에 붙이기 전 볼 운영표 2026
- Hermes Agent는 왜 단순 챗봇이 아니라 운영형 비서로 보일까 2026
- AI 에이전트 하네스가 뭐지 2026 – 프롬프트보다 실행 계층이 중요한 이유
참고 자료
- NousResearch, Hermes Agent GitHub README, 2026-06-01 확인
- Hermes Agent Docs, Installation, 2026-06-01 확인
- Hermes Agent Docs, Slack Setup, 2026-06-01 확인
- Hermes Agent Docs, Persistent Memory, 2026-06-01 확인
- Hermes Agent Docs, Scheduled Tasks, 2026-06-01 확인
- Hermes Agent Docs, Security, 2026-06-01 확인
- 내부 노트:
00.Inbox/260530_[요약] 헤르메스 에이전트 처음 써보는 분도 이 영상 하나로 끝납니다, 설치부터 회사 운영 자동화까지.md