Hermes Agent × Slack/Discord 실제 운영 사례 41건 분석

조사 기준일: 2026-08-06
조사 언어: 영어·중국어·한국어
최종 적격 사례: 41건
플랫폼: Discord 28건 · Slack 13건
증거 등급: A 29건 · B 12건
정본 데이터: cases.json
공식 기준선: NousResearch/hermes-agent 공식 문서 및 GitHub main commit aaf9688519cca58dd5f76a589a0911aff269b060

이 보고서는 “Hermes가 Slack/Discord를 지원한다”는 기능 소개를 세지 않았다. 실제 설치·실행·산출물·장애·복구 중 하나 이상이 공개 원문에서 확인된 독립 운영 사례만 포함했다. 공식 문서와 소스는 제품 기능의 기준선일 뿐 사용자 성과 사례가 아니다.

Executive Summary

결론부터 말하면, Hermes와 Slack/Discord의 공통 성공식은 메신저 안에 챗봇을 넣는 것이 아니다. 반복해서 유효했던 구조는 메신저를 원격 control plane으로 사용 → 채널과 thread를 작업 경계로 사용 → 실제 작업은 파일·Git·Obsidian·서버·브라우저에서 수행 → 결과와 상태를 다시 메신저로 전달하는 형태다.

41건에서 가장 강하게 나타난 공통분모는 다음 일곱 가지다.

메신저는 대화창보다 원격 조종면이다. 휴대폰에서 리서치, 코드 수정, 서버 상태 확인, cron 브리프, 파일 생성과 멀티에이전트 위임을 시작한다.
채널은 업무 도메인, thread는 실행 단위다. 채널을 운동·뉴스·이메일·프로젝트·에이전트 역할별로 나누고 thread를 개별 세션과 결과의 컨테이너로 쓴다.
지속 상태는 채팅 밖에 둔다. Obsidian, Git 저장소, 진행 파일, report webview가 정본이고 Slack/Discord는 명령과 알림 표면이 된다.
능동적 가치의 분기점은 cron·알림이다. 단발 질의보다 일일 브리프, 빌드 완료, 사이트 장애, 뉴스·날씨 보고처럼 에이전트가 먼저 결과를 보내는 순간 효용이 커진다.
멀티에이전트는 역할 수보다 경계 품질이 중요하다. bot ID, profile, channel, memory, workspace와 handoff 규칙이 명시되지 않으면 identity 혼입, bot loop, 권한 차단과 결과 덮어쓰기가 발생한다.
가장 흔한 장애는 모델 품질이 아니라 운영 배관이다. intent, allowlist, channel ID, gateway restart, thread 권한, Socket Mode stale connection, attachment 크기, slash-command 제약이 실제 실패를 만들었다.
공개 사례는 아직 M5가 아니다. 장기 SLO·비용·오류율·품질 지표까지 관리하는 성과 기반 autonomy ops 사례는 확인하지 못했다. 대부분은 M1~M3이며, M4 수준의 통제·복구 가능한 다중 루프는 2건뿐이다.

Son님 환경은 외부 사례의 평균보다 이미 앞선다. Discord thread 중심 문맥 분리, 전문 profile, 상태·로그·긴 보고서 표면 분리는 M3~M4 설계에 가깝다. 다음 병목은 에이전트를 더 늘리는 것이 아니라 배달 계약, 설정 preflight, event freshness, identity boundary와 outcome metric을 운영 규격으로 고정하는 것이다.

1. 연구 질문

이 조사는 다음을 판별하기 위해 수행했다.

Hermes 사용자는 Slack/Discord에서 실제로 어떤 업무를 위임하는가?
채널·thread·session·memory·skill·cron을 어떻게 조합하는가?
개인, 팀, 멀티에이전트 사례의 구조는 어떻게 다른가?
실제 장애는 어느 계층에서 발생하고 어떤 복구 패턴이 필요한가?
Son님의 Discord 기반 AI autonomy/ops lab에 적용할 공통 구조와 피해야 할 안티패턴은 무엇인가?

2. 방법과 적격성

2.1 수집면

영어: YouTube 원본/자동자막, DEV, 개인 블로그, GitHub Issues·PR
중국어: 독립 블로그, GitHub Pages, YouTube, 知乎·CSDN·掘金 후보 검토
한국어: Naver Blog, Velog, Tistory, GitHub Pages, YouTube 후보 검토
공식 기준선: Hermes 공식 Discord·Slack·sessions·cron·webhook·profiles·memory·skills·security 문서와 commit 고정 GitHub 소스

2.2 포함 기준

Nous Research의 Hermes Agent임이 확인될 것
Discord 또는 Slack이 실제 입력·작업·전달 표면일 것
설정, 실제 실행, 산출물, 장애, 복구 중 하나 이상을 원문에서 확인할 수 있을 것
같은 작성자의 같은 인스턴스·후속 재게시물은 한 사례로 병합할 것

2.3 제외 기준

공식 기능 문서와 소스 자체
단순 설치 가능성이나 가상 시나리오만 제시한 글
호스팅·리셀러·SEO 랜딩 페이지
Medium 검색 스니펫처럼 원문을 확인하지 못한 항목
OpenClaw 등 다른 제품, 동명이인 Hermes, 번역·재게시 중복
중국어 DevTuts 페이지처럼 이미 영어 원사례와 동일한 번역판

2.4 증거 등급

A: 실제 화면·로그·명령·산출물·실패/복구 등 직접 증거가 확인됨
B: 직접 운용 진술과 구체적 설정·동작은 있으나 장기 결과나 산출물 증거가 제한적

이번 41건은 A 29건, B 12건이다. 검색 스니펫만 확보한 C/D급은 최종 코퍼스에서 제외했다.

3. 표본 구성

구분	사례 수	해석
영어 커뮤니티·블로그·영상	16	개인 생산성, 리서치, 개발, 멀티에이전트와 멀티모달 사례가 가장 다양함
GitHub 실운영 이슈·PR	16	성공담보다 권한·라우팅·배달·복구의 실패 증거가 강함
중국어	3	모두 Discord. 서버 원격관리·크로스머신 멀티에이전트가 중심
한국어	6	표본은 작지만 Slack 기반 연구·작성·정기 리포트 사례가 상대적으로 구체적
합계	41	Discord 28 · Slack 13

언어권별 균형을 억지로 맞추지 않았다. 중국어권 Slack 독립 실사용 사례는 확인되지 않았고, 한국어 자료도 상당수가 공식 문서 재작성이나 VPS 제휴 콘텐츠였다. 이 부족 자체가 현재 생태계의 관찰 결과다.

4. 실제로 사용된 업무 유형

4.1 개인 지식·리서치

Artem Zhutov는 Discord에서 Obsidian vault와 리서치 skill을 사용했고, Rick Mulready는 Slack에서 사업 리서치를 시킨 뒤 evidence queue와 콘텐츠 기회를 Obsidian에 저장했다. Kris Torrington은 Discord에서 browser tools를 실행해 당일 뉴스 보고서를 받았다. 한국어권 PYU 사례는 Slack 검색 결과를 thread로 정리하고 이후 연구자·작성자·오케스트레이터 파이프라인으로 확장했다.

공통 구조는 명확하다. 대화 기록 자체가 지식베이스가 아니라, 메신저가 외부 지식 작업을 호출하고 결과 위치를 알려주는 인터페이스였다.

4.2 개발·파일·프로젝트 작업

Tina Huang은 Discord를 주 작업면으로 앱 개발과 빌드 알림을 운영했다. David Ondrej는 휴대폰 Discord에서 장기 refactor, 진행 ping, 버그 진단과 GitHub push를 설계했다. 한국어 WSL2 사례는 Discord에서 실제 README.md 생성 같은 파일 작업을 수행했다. AIHQ 사례는 Slack thread를 canonical progress file과 바인딩하고 subagent 위임과 파일 업로드를 검증했다.

여기서 메신저는 IDE를 대체하지 않는다. 작업 시작, 진행 상태, 승인, 결과 회수의 thin client로 기능한다.

4.3 정기 자동화·관제

일일 AI 브리프, 뉴스·날씨 보고, 사이트 장애 알림, 빌드 완료, 이메일·AI 뉴스 채널이 반복됐다. 중국어 GK实验室 사례는 휴대폰 Discord에서 서버 상태를 묻고 매일 자동 보고와 사이트 다운 알림을 받았다. 이 범주에서 Hermes의 가치는 “질문하면 답한다”에서 “필요할 때 먼저 알려준다”로 바뀐다.

다만 GitHub 사례는 cron 실행 성공과 전달 성공이 별개임을 보여준다. 결과가 지정 home channel이 아니라 원래 대화로 돌아간 사례가 있었고, 큰 미디어는 작업 완료 후 Discord attachment 전달에서 실패했다.

4.4 멀티에이전트·팀 협업

영어권 Superbash, Clearmud, Asad Tinkers, 중국어 GoFly, 한국어 PYU에서 인간+여러 agent 또는 agent-to-agent 구조가 나타났다. 성공 조건은 agent 수가 아니라 다음 경계였다.

profile과 bot token 분리
역할별 channel 또는 thread
허용 bot ID와 명시적 mention
handoff 시 원본 task context 전달
canonical progress file 또는 외부 정본
버전과 산출물 이름 충돌 방지

실패도 같은 곳에서 발생했다. Cypher가 자신을 Neo라고 부르는 identity cross-pollination, Slack bot 본문 유실, SLACK_ALLOWED_USERS가 agent 간 호출을 차단한 사례, 여러 봇의 mention loop 위험이 확인됐다.

4.5 멀티모달·음성

Discord에서 이미지·음악·TTS·voice channel을 사용한 사례가 있었지만 voice는 느렸고 realtime streaming이 없어 실시간 대화 품질에는 미달했다. NixOS에서는 Opus 라이브러리 탐색이 실패했다. 생성 동영상은 Discord 크기 제한으로 실제 전달이 유실됐다.

따라서 멀티모달은 “생성 성공”과 “메신저 배달 성공”을 별도 단계로 검증해야 한다.

5. 공통 운영 패턴

5.1 채널은 도메인, thread는 실행 컨텍스트

Discord 사례는 채널을 운동, 할 일, 이메일, 뉴스, 프로젝트, 에이전트 역할로 나누는 경향이 강했다. Discord의 기본 auto-thread는 새 멘션마다 격리된 대화를 만들기 쉬웠다. Slack은 원문 메시지에 붙는 thread가 자연스러운 프로젝트 기록 단위였다.

가장 안전한 모델은 다음과 같다.

channel = 업무 도메인·팀·에이전트 역할
thread = 하나의 목표·실행·incident·보고서
session = thread와 일치하는 대화 상태
external artifact = 파일·Git·Obsidian·webview 정본

이 네 경계가 어긋나면 parent channel 문맥 혼입, mention 없는 후속 대화 누락, cron 결과 오배달, 프로젝트 버전 덮어쓰기가 발생했다.

5.2 메신저는 control plane, 정본은 외부에

성공 사례는 Discord/Slack 메시지에 모든 상태를 쌓지 않았다. Obsidian, Git, 로컬 파일, progress document, HTML 보고서가 durable state였고 메신저는 명령·상태·링크를 전달했다. 이 구조는 채팅 로그가 길어져도 프로젝트 진실이 사라지지 않게 한다.

5.3 능동적 전달이 실제 효용을 만든다

일일 브리프, 빌드 알림, 서버 장애와 cron 결과가 반복적으로 언급됐다. 그러나 proactive delivery는 다음 계약을 필요로 한다.

실행 대상과 delivery target 분리
origin, home channel, 특정 thread의 우선순위
긴 결과와 큰 파일의 fallback
재시작 중 중복·유실 정책
후속 대화를 이어갈 continuation surface

5.4 allowlist와 mention은 UX가 아니라 권한 경계

여러 사례에서 allowlist가 비어 봇이 침묵했고, 문자열형 배열이나 wildcard가 모든 메시지를 무음 폐기했다. 반대로 ALLOW_ALL_USERS는 빠른 복구처럼 보이지만 공격면을 넓힌다. mention 면제 채널은 편리하지만 누가 agent를 깨울 수 있는지와 비용·권한을 함께 바꾼다.

5.5 장기 서비스는 process alive보다 event freshness가 중요하다

Slack Socket Mode는 연결 상태가 정상처럼 보이면서 이벤트만 멈췄다. Discord는 잘못된 supervisor 정책으로 1,000회 이상 재접속했다. 따라서 health check는 단순 PID나 WebSocket connected가 아니라 다음을 봐야 한다.

마지막 inbound event 시각
heartbeat ACK age와 latency
queue depth와 drop count
마지막 successful outbound delivery
reconnect 횟수와 circuit-breaker 상태
cron execution과 delivery ledger의 차이

6. 반복 장애와 안티패턴

6.1 설정은 유효하지만 의미가 틀린 상태

YAML 리스트 대신 JSON 문자열, wildcard 오해, 잘못된 권한 정수처럼 파서는 통과하지만 실제 라우팅과 권한이 망가지는 사례가 있었다. 시작 시 typed schema 검증과 실제 channel/user ID 해석 결과를 출력해야 한다.

6.2 gateway online을 서비스 정상으로 오인

gateway 재시작 누락, privileged intent 누락, stale Socket Mode, reconnection storm이 반복됐다. online 표시만으로 inbound·outbound·thread·attachment·cron delivery가 정상이라고 볼 수 없다.

6.3 작업 성공과 전달 성공을 합침

동영상 생성은 성공했지만 Discord 업로드가 실패했고, cron은 실행됐지만 목적지가 틀렸다. 작업 execution state와 delivery state를 별도 ledger로 관리해야 한다.

6.4 모든 것을 메인 채널에 출력

free-response와 inline 답변은 편하지만 긴 tool progress와 보고서가 채널을 오염시킨다. thread, status channel, log channel, report webview를 분리해야 한다.

6.5 멀티에이전트를 같은 정체성과 기억에 연결

bot-to-bot 상호작용에서 identity 혼입, 본문 유실, 무한 mention loop, 권한 차단이 나타났다. profile 이름만 다르게 하는 것으로 충분하지 않고 token·workspace·session·memory·handoff contract를 함께 분리해야 한다.

6.6 플랫폼 제약을 모델에게 해결시키려 함

Slack thread의 slash command·approval button 제한, Discord attachment 크기와 intents는 모델 추론 문제가 아니다. adapter가 명시적 fallback과 오류 메시지를 제공해야 한다.

7. Discord와 Slack 비교

비교축	Discord	Slack
강한 사용 맥락	개인 AI lab, 홈랩, 모바일 원격 조작, 멀티봇·음성	업무 리서치, 프로젝트 thread, 팀 협업, Socket Mode
기본 대화 구조	멘션마다 새 auto-thread를 만들기 쉬움	원문 메시지에 붙는 thread가 자연스러움
채널 모델	역할·생활 영역·에이전트별 room 구성에 유리	기존 업무 채널과 프로젝트 문맥에 결합하기 쉬움
명령 제약	native slash와 voice 기능	thread 내 native slash·approval UI 제약, `!cmd` fallback 필요
대표 장애	intents, 권한 정수, thread membership, attachment, reconnect	Socket stale, SDK 누락, allowlist parsing, thread state·button·bot message
적합한 전달	진행 thread, 알림 채널, media와 webview 링크	thread brief, 파일 업로드, 프로젝트 permalink와 continuation

Son님 환경처럼 자율 agent의 공간성과 역할 분리가 중요한 경우 Discord가 더 자연스럽다. 기존 회사 업무와 검색·문서·프로젝트 기록을 붙이는 경우 Slack이 강하다. 어느 쪽이 우월하다기보다 topology가 다르다.

8. 언어권별 관찰

8.1 영어권

표본과 유형이 가장 풍부했다. 개인 지식관리, 사업 리서치, 개발, VPS, 음성, 멀티에이전트까지 확인됐다. 동시에 GitHub에는 성공담에서 잘 보이지 않는 배관 장애가 축적돼 있었다. 커뮤니티 글은 가치 흐름, GitHub는 실패 경로를 보여준다는 보완 관계가 있었다.

8.2 중국어권

최종 고유 사례는 3건이며 모두 Discord였다. 7×24 VPS 서버 관리, WSL2/WeChat 병행, Mac·Windows 멀티에이전트처럼 원격 운영 성격이 강했다. 중국어권 Slack 사례는 독립 원문을 확인하지 못했다. Telegram·WeChat·Feishu 사례가 더 풍부했으므로 중국어권에서 Slack 공백을 보급률의 인과로 단정할 수는 없지만, 공개 생태계의 방향 차이는 분명했다.

8.3 한국어권

최종 6건으로 표본은 작다. 그러나 Slack에서 일일 리포트, 논문 요약, 연구자→작성자→오케스트레이터 흐름, 학교·집·스마트폰 공통 인터페이스가 확인됐다. Discord는 WSL2 격리, 로컬 LLM, cron 브리핑 중심이었다. 다수 검색 결과는 실제 결과 없이 공식 설정을 재서술하거나 VPS 제휴에 묶여 있어 제외했다.

9. 성숙도 분석

이번 보고서의 M0~M5는 Hermes 공식 분류가 아니라 관찰 증거의 상한을 나타내는 연구용 모델이다.

단계	정의	사례 수
M1	연결·기본 routing·allowlist 수준	9
M2	thread/session 경계와 실제 tool 실행이 확인됨	20
M3	cron·장기 서비스·멀티에이전트 등 반복 루프가 확인됨	10
M4	역할 경계, 정본, 관찰·복구를 함께 검증한 다중 루프	2
M5	SLO·비용·품질·업무 outcome을 장기 관리	0

M4로 분류한 것은 AIHQ의 Slack 프로젝트 시스템과 PYU의 연구·작성 멀티에이전트 파이프라인 두 건이다. 이들도 조직 차원의 장기 SLO나 비용 대비 효과를 증명한 M5는 아니다.

핵심은 기능 수가 아니다. bot이 많거나 cron이 있다고 성숙한 것이 아니라 경계, 배달, 복구, 측정이 닫힌 루프를 이루는가가 기준이다.

10. Hermes 공식 기준선

공식 문서와 commit 고정 소스에서 확인한 현재 기능은 다음과 같다. 이는 capability evidence이며 사례 수에 포함하지 않았다.

Discord 공식 문서: DM session, 기본 mention gate, auto-thread, 사용자별 공유 채널 session, history backfill
Slack 공식 문서: Socket Mode, 기본 thread reply, DM/thread session 규칙, mention 정책, !cmd fallback
Cron: fresh isolated run, execution ledger, origin/home/specific target, dedicated continuation thread
Webhooks: HMAC, replay 방지, idempotency, rate limit, profile binding, direct delivery
Profiles: config·session·memory·skill·cron·gateway state 격리. 단 filesystem sandbox는 아님
Security: allowlist, pairing, admin tier, dangerous-command approval와 hardline blocklist

공식 기능의 존재가 실제 설정과 안정성을 보장하지 않는다는 점은 16건의 GitHub 운영 장애가 직접 보여준다.

11. Son님의 Discord autonomy/ops lab 평가

11.1 이미 외부 평균보다 강한 부분

Home parent → thread 구조: 외부 사례에서 반복된 channel/thread/session 정렬 원칙과 일치한다.
전문 profile 분리: Sonia, ops, research, dev, dashboard, quant, game 경계는 멀티에이전트 identity 혼입을 줄이는 올바른 방향이다.
상태·로그·보고서 분리: #periodic-summary, 임시 #hermes-logs, 긴 HTML webview는 메인 대화 오염을 줄이고 execution과 artifact를 분리한다.
Sonia front-operator 모델: 전문 lane 결과를 그대로 붙이지 않고 검토·번역하는 구조는 외부 다중 agent 사례보다 governance가 강하다.
정본을 채팅 밖에 유지: 파일·DB·wiki·HTML report를 정본으로 두는 원칙은 가장 성숙한 사례군과 일치한다.

11.2 현재 가장 중요한 갭

P0. 설정 preflight와 typed policy 검증

시작 시 allowlist, channel ID, parent/thread 상속, bot token 중복, intent, 권한을 실제 플랫폼 정보와 대조해야 한다. 문자열형 배열이나 wildcard 같은 “문법은 맞지만 의미가 틀린 설정”을 gateway 시작 전에 차단하는 것이 우선이다.

P0. execution과 delivery의 분리 검증

정기적으로 작은 canary로 다음 경로를 검증해야 한다.

inbound mention → thread 생성 → response
free-response channel → 올바른 session
cron execution → 지정 summary channel
긴 보고서 → webview 링크
파일·미디어 → 크기 초과 시 명시적 fallback
gateway restart 이후 continuation

P1. event freshness 기반 health

프로세스와 WebSocket 연결 여부만 보지 말고 마지막 inbound event, heartbeat ACK age, 마지막 outbound, queue depth, reconnect rate를 상태면에 올려야 한다.

P1. profile/bot identity contract

각 profile에 대해 bot token, home channel, 허용 parent/thread, memory·skill 정본, handoff format, 호출 가능한 다른 bot을 표로 고정해야 한다. bot-to-bot은 기본 금지하고 필요한 lane만 명시적으로 허용하는 편이 안전하다.

P1. 결과 전달 계약

짧은 상태는 Discord, 긴 본문은 webview, 원본은 Markdown, 큰 media는 별도 저장소라는 규칙을 adapter와 job prompt에 일관되게 반영해야 한다. “작업은 성공했지만 사용자가 결과를 못 받는” 상태를 실패로 간주해야 한다.

P2. M5로 가기 위한 outcome metric

다음 정도면 충분하다.

예약 작업 실행 성공률과 전달 성공률
사용자 개입 없이 완료된 작업 비율
중복·오배달·무응답 수
평균 복구 시간
결과 수정률 또는 재작업률
profile별 비용·토큰과 실제 사용 빈도

화려한 dashboard보다 먼저 데이터 정의와 ledger가 필요하다.

12. 권고 운영 모델

Discord channel/thread
  → explicit trigger·allowlist
  → deterministic routing key
  → profile/session/context boundary
  → tool/subagent execution
  → canonical artifact write
  → short Discord status + verified webview/file delivery
  → execution ledger + delivery ledger
  → freshness/queue/reconnect alert
  → bounded recovery or human escalation

바로 적용할 우선순위

배달 canary 5종을 정기적으로 검증한다.
profile/channel/session registry를 하나의 기계 판독 가능한 정본으로 만든다.
gateway health에 event freshness와 reconnect storm을 추가한다.
bot-to-bot lane은 명시적 identity·mention·handoff 계약이 있는 경우만 허용한다.
execution과 delivery를 분리한 성공률 지표를 축적한다.
새 에이전트나 dashboard 추가는 위 다섯 항목이 안정된 뒤 판단한다.

13. 최종 판단

Hermes+Slack/Discord의 실제 가치는 “언제 어디서나 AI와 채팅”이 아니다. 더 정확히는 기존 메신저를 개인 또는 팀의 agent control plane으로 바꾸고, thread를 실행 컨텍스트로 만들며, 외부 정본과 자동 전달을 연결하는 것이다.

하지만 공개 사례의 대부분은 아직 연결·라우팅·반복 자동화 단계에 머문다. 장애의 중심도 LLM이 아니라 권한, 설정, session key, WebSocket, supervisor, 파일 전달이다. 따라서 Son님의 다음 발전 방향은 agent 수 확대가 아니라 다음 세 문장으로 요약된다.

모든 작업에는 deterministic한 context와 delivery target이 있어야 한다.
작업 성공과 결과 전달 성공을 별도로 증명해야 한다.
alive가 아니라 fresh하고 recoverable한지를 관측해야 한다.

현재 Son님의 구조는 외부 공개 사례 평균보다 이미 성숙하다. 이제 M4를 안정적으로 운영하고 M5로 넘어가려면 낭만을 없앨 필요가 아니라, 낭만을 지탱할 배관을 더 엄격하게 만들면 된다. 예쁜 관제실도 메시지가 유실되면 그냥 어두운 방이니까요.

부록 A. 적격 사례 41건

EN01. Hermes Agents + Obsidian: My Second Brain Has a Team of Agents in Discord

언어·플랫폼·등급: 영어 · Discord · A · 관찰 상한 M2
작성자·날짜: Artem Zhutov · 2026-04-22
유형: 개인 지식관리
워크플로: 휴대폰 Discord의 생활영역별 채널에서 Obsidian vault 질의, YouTube 피드 수집, 리서치와 아이디어 캡처를 실행한다.
근거: 실제 Discord 응답과 skill 실행 결과를 영상에서 확인했다.
장애·경계: 깊은 검토는 Discord보다 Claude Code와 Obsidian 조합을 선호한다고 경계를 밝혔다.

EN02. Hermes Agent Fundamentals In 29 Minutes

언어·플랫폼·등급: 영어 · Discord · A · 관찰 상한 M3
작성자·날짜: Tina Huang · 2026-07-20
유형: 개발·정기 브리프
워크플로: Discord를 주 작업면으로 사용해 일일 AI 브리프와 빌드 알림을 받고 멀티에이전트로 앱을 개발한다.
근거: 본인 Discord, 일일 브리프, 빌드 완료 알림과 완성 앱을 영상에서 확인했다.
장애·경계: 치명적 장애 보고는 없었다.

EN03. 7 Mind-Blowing Use Cases for Hermes Agent

언어·플랫폼·등급: 영어 · Slack · A · 관찰 상한 M3
작성자·날짜: Rick Mulready · 2026-06-11
유형: 사업 리서치
워크플로: Slack에서 사업 리서치를 지시하고 evidence queue와 콘텐츠 기회를 Obsidian에 저장한 뒤 operator brief를 회수한다.
근거: 실제 Slack 프롬프트, 약 20분 뒤 브리프, Obsidian 저장 파일이 확인됐다.
장애·경계: 장애보다 Slack의 복사·공유 편의성이 강조됐다.

EN04. Hermes Agent Setup with Discord

언어·플랫폼·등급: 영어 · Discord · A · 관찰 상한 M3
작성자·날짜: Superbash / BoxminingAI · 2026-04-10
유형: 인간+에이전트 팀
워크플로: 5명의 인간과 여러 에이전트가 있는 Discord에서 뉴스 수집·트레이딩 보조·cron 알림을 운영한다.
근거: 실제 팀 서버 구조와 Hermes 담당 업무, 신규 봇 설정과 thread 동작을 확인했다.
장애·경계: home channel과 thread UX가 직관적이지 않다는 평가가 있었다.

EN05. How I have my Hermes and OpenClaw AI Agents Working Together

언어·플랫폼·등급: 영어 · Discord · A · 관찰 상한 M3
작성자·날짜: Clearmud · 2026-05-09
유형: 봇 간 협업
워크플로: Discord shared-comms 채널에서 Hermes와 OpenClaw의 여러 역할 에이전트를 연결한다.
근거: 봇 생성, 역할, 온라인 상태, 상호 메시지와 설정 진단을 실시간 확인했다.
장애·경계: Discord API 장애, typing indicator 부재, 무응답, identity cross-pollination과 routing 오류가 발생했다.

EN06. Hermes agent: Connect to Discord

언어·플랫폼·등급: 영어 · Discord · A · 관찰 상한 M2
작성자·날짜: Phú · 2026-05-12
유형: 멀티모달·음성
워크플로: Discord에서 이미지·음악 생성, TTS와 voice channel 대화를 실행한다.
근거: 작성자 설정 화면과 생성 결과, voice demo를 원문에서 확인했다.
장애·경계: 음성은 매우 느렸고 realtime streaming이 없어 실시간 대화로 보기 어려웠다.

EN07. Bitdoze Hermes VPS/Discord 운영기

언어·플랫폼·등급: 영어 · Discord · A · 관찰 상한 M2
작성자·날짜: Dragos / Bitdoze · 2026-04~07
유형: VPS 원격 작업
워크플로: VPS Hermes를 Discord에서 호출해 코드, 웹 검색, 파일 편집을 수행하고 Workspace에서 세션·메모리·토큰을 추적한다.
근거: 수개월 운영 진술, 실제 Discord 연결과 사용량 기록을 확인했다. 같은 저자의 후속 setup guide는 이 사례로 병합했다.
장애·경계: 무료 모델 프로모션 종료와 큰 토큰 사용량이 제약이었다.

EN08. Build Hermes AgentOS: 5 Agents Discord Crew

언어·플랫폼·등급: 영어 · Discord · A · 관찰 상한 M3
작성자·날짜: Asad Tinkers · 2026-06-18
유형: 멀티에이전트 운영실
워크플로: VPS에 5-agent crew와 orchestrator, Discord 채널별 위임, mission-control dashboard를 구성한다.
근거: 설치, 채널 구성, 에이전트 온라인 상태와 agent 간 통신을 확인했다.
장애·경계: 초기에는 orchestrator 한 명만 Discord에 연결되어 채널 매핑을 추가해야 했다.

EN09. Run Multiple AI Agents From ONE Bot

언어·플랫폼·등급: 영어 · Discord · A · 관찰 상한 M3
작성자·날짜: Code With Arjun · 2026-06-12
유형: 생활·업무 채널 자동화
워크플로: 운동, 칼로리, 할 일, 이메일, AI 뉴스, 업무 채널을 한 Hermes bot으로 운영한다.
근거: 기존 서버의 실제 알림과 새 설치 후 응답을 영상에서 확인했다.
장애·경계: gateway 재시작 누락으로 봇이 offline이었고 mention/thread UX를 조정해야 했다.

EN10. Hermes Agent Masterclass: VPS and Discord

언어·플랫폼·등급: 영어 · Discord · A · 관찰 상한 M1
작성자·날짜: Tonbi's AI Garage · 2026-05-11
유형: 멀티플랫폼 원격 접속
워크플로: VPS의 동일 Hermes를 Telegram과 Discord thread에서 접근한다.
근거: 봇 초대, 자동 thread와 응답을 실제 화면에서 확인했다.
장애·경계: privileged intents를 빠뜨리면 빈 메시지만 받아 무응답처럼 보인다.

EN11. Connect Hermes Agent to Discord in 3 Minutes

언어·플랫폼·등급: 영어 · Discord · A · 관찰 상한 M2
작성자·날짜: Kris Torrington · 2026-05-02
유형: 모바일 리서치
워크플로: Discord에서 당일 뉴스 조사를 지시하고 browser tools를 거쳐 분류 보고서를 받는다.
근거: pairing, 봇 온라인, tool activity와 최종 보고서 반환을 영상에서 확인했다.
장애·경계: 로컬 PC가 켜져 있어야 하므로 24/7 운영에는 VPS가 필요하다.

EN12. 100 hours of Hermes Agent lessons

언어·플랫폼·등급: 영어 · Discord · A · 관찰 상한 M2
작성자·날짜: David Ondrej · 2026-05-06
유형: 모바일 개발 관제
워크플로: Discord에서 채널 읽기 MCP를 시험하고 장기 refactor, 진행 ping, 버그 진단, GitHub push 흐름을 설계한다.
근거: Discord thread·message·channel read 결과와 성공을 영상에서 확인했다.
장애·경계: token, intent, 권한 설정 복잡성이 높았다.

EN13. Hermes Agent: Slack Bot with Socket Mode

언어·플랫폼·등급: 영어 · Slack · B · 관찰 상한 M2
작성자·날짜: ActionableOps · 2026-06-26
유형: Slack 사설망 운영
워크플로: Socket Mode로 private server 뒤의 Hermes를 DM, channel mention, thread별 session으로 사용한다.
근거: Hermes 전용 명령, token, allowlist와 메시지 동작을 구체적으로 시연했다.
장애·경계: thread 안 slash command와 approval button이 막혀 !stop·!approve 같은 대체 명령이 필요했다.

EN14. Hermes Agent: Discord Bot Setup

언어·플랫폼·등급: 영어 · Discord · B · 관찰 상한 M1
작성자·날짜: ActionableOps · 2026-07-09
유형: Discord 세션 격리 설정
워크플로: DM, 서버 채널, thread, voice channel과 공유 채널 사용자별 세션 격리를 구성한다.
근거: Hermes 고유 설정과 동작 규칙을 구체적으로 설명했다.
장애·경계: allowlist가 없으면 fail-closed, intents 누락 시 메시지와 사용자명 처리가 실패한다.

EN15. Hermes Agent Installation & Discord Configuration Tutorial

언어·플랫폼·등급: 영어 · Discord · B · 관찰 상한 M1
작성자·날짜: DevTuts/Tinkink · 2026-04-14
유형: 팀 서버 설치
워크플로: macOS에서 Hermes를 Discord server bot으로 설정해 channel response, auto-thread와 알림 채널을 구성한다.
근거: 작성자가 실제 팀 서버에 설정했다고 명시했으나 업무 산출물은 제한적이다.
장애·경계: 글 자체가 최신 설정과 다를 수 있음을 경고한다. 중국어 번역판은 중복 제외했다.

EN16. Connecting Hermes Agent to Discord: Complete Setup Guide

언어·플랫폼·등급: 영어 · Discord · B · 관찰 상한 M1
작성자·날짜: Luca Berton · 2026-07-22
유형: Oracle VPS 연결
워크플로: Oracle Cloud free-tier의 Hermes를 Discord DM, server, thread에서 접근하도록 구성한다.
근거: 실제 실패 패턴과 end-to-end 권한 요구를 구체적으로 기록했다.
장애·경계: Message Content Intent 누락 시 text가 비고 thread 권한 부족 시 응답이 실패한다.

GH01. s6 감독 게이트웨이 1,000회 재접속 폭주

언어·플랫폼·등급: 영어/GitHub · Discord · A · 관찰 상한 M2
작성자·날짜: GitHub reporter · 2026-08-01
유형: 상시 서비스 복구
워크플로: s6가 Discord gateway를 상시 감독하는 프로필 운영이다.
근거: 실제 1,000회 이상 연결 시도와 token reset, 후속 수정 PR이 기록됐다.
장애·경계: 정상 종료까지 재시작해 Discord가 token을 초기화했다.

GH02. 공식 절차 설치가 privileged intents에서 실패

언어·플랫폼·등급: 영어/GitHub · Discord · A · 관찰 상한 M1
작성자·날짜: GitHub reporter · 2026-08-05
유형: 신규 설치 장애
워크플로: macOS Desktop과 Discord gateway 신규 설정이다.
근거: 문서 1:1 수행 진술, 438번째 재접속 로그와 수정 PR이 있다.
장애·경계: 누락된 privileged intent 때문에 연결 실패와 재접속 루프가 발생했다.

GH03. cron 결과가 알림 채널 대신 원래 대화로 배달

언어·플랫폼·등급: 영어/GitHub · Discord · B · 관찰 상한 M2
작성자·날짜: GitHub reporter · 2026-04-10
유형: 예약 결과 전달
워크플로: Discord에서 cron을 만들고 별도 notifications home channel로 결과를 보내려 했다.
근거: 예약 실행 성공과 잘못된 실제 배달 위치가 재현됐다.
장애·경계: 결과가 home channel이 아니라 job을 만든 DM·채널로 돌아갔다.

GH04. Discord 초대 권한 정수 오류

언어·플랫폼·등급: 영어/GitHub · Discord · A · 관찰 상한 M1
작성자·날짜: GitHub reporter · 2026-07-28
유형: 권한 구성
워크플로: 문서의 권한 정수로 신규 Discord 앱을 초대했다.
근거: 실제 설치자 혼란과 잘못 부여된 외부 이모지 권한, 문서 수정이 기록됐다.
장애·경계: 문서와 실제 권한 범위가 불일치했다.

GH05. channel allowlist wildcard가 전 메시지를 무음 폐기

언어·플랫폼·등급: 영어/GitHub · Discord · B · 관찰 상한 M1
작성자·날짜: GitHub reporter · 2026-04-24
유형: 채널 접근 제어
워크플로: 서버 전체 free-response를 위해 wildcard allowlist를 사용했다.
근거: gateway online과 MESSAGE_CREATE 수신에도 전 메시지가 버려지는 재현이 있다.
장애·경계: 폐기 이유가 DEBUG에만 있어 운영자가 원인을 알 수 없었다.

GH06. 생성 동영상 Discord 전달 유실

언어·플랫폼·등급: 영어/GitHub · Discord · A · 관찰 상한 M2
작성자·날짜: GitHub reporter · 2026-06-22
유형: 미디어 산출물 전달
워크플로: 로컬에서 생성·편집한 동영상을 Discord attachment로 반환한다.
근거: 413/40005와 fallback 실패, 업로드 전 검사 수정이 기록됐다.
장애·경계: 에이전트는 결과를 보고했지만 실제 Discord 배달은 실패했다.

GH07. private thread 생성자가 thread에 접근하지 못함

언어·플랫폼·등급: 영어/GitHub · Discord · B · 관찰 상한 M1
작성자·날짜: GitHub contributor · 2026-04-06
유형: 작업 스레드 생성
워크플로: /thread 명령으로 private 작업 공간을 만든다.
근거: 생성자가 자동 멤버가 되지 않는 결함과 add_user 수정이 있다.
장애·경계: 요청자가 자신이 만든 thread에 접근할 수 없었다.

GH08. NixOS Discord voice Opus 탐색 실패

언어·플랫폼·등급: 영어/GitHub · Discord · B · 관찰 상한 M2
작성자·날짜: GitHub reporter · 2026-05-23
유형: 음성 채널 운영
워크플로: NixOS에서 Discord voice를 사용한다.
근거: 동적 라이브러리 탐색 실패와 절대 경로 성공, 두 건의 end-to-end 검증이 기록됐다.
장애·경계: Opus가 설치돼 있어도 일반 탐색으로 찾지 못했다.

GH09. 기본 설치에 slack-bolt가 없어 gateway 시작 실패

언어·플랫폼·등급: 영어/GitHub · Slack · A · 관찰 상한 M1
작성자·날짜: GitHub reporters · 2026-03-30
유형: Slack 설치
워크플로: curl 또는 Nix 설치 후 Slack gateway를 시작한다.
근거: macOS·Fedora/Nix 재현과 수동 패키지 설치 우회가 기록됐다.
장애·경계: 필수 Slack SDK가 빠져 gateway가 시작되지 않았다.

GH10. 문자열형 Slack allowlist로 프로덕션 봇 침묵

언어·플랫폼·등급: 영어/GitHub · Slack · A · 관찰 상한 M2
작성자·날짜: GitHub reporter · 2026-07-29
유형: 프로덕션 설정 관리
워크플로: 에이전트가 config.yaml의 Slack 채널 정책을 관리하는 배포다.
근거: 프로덕션 장애, 수동 gating 추적과 복구, 후속 PR이 있다.
장애·경계: JSON 배열 문자열을 리스트로 오인해 모든 채널 메시지를 무음 폐기했다.

GH11. 재시작 후 Slack thinking 상태 영구 잔류

언어·플랫폼·등급: 영어/GitHub · Slack · B · 관찰 상한 M2
작성자·날짜: GitHub reporter · 2026-05-25
유형: 진행 상태 복구
워크플로: Slack thread에서 작업 중 gateway restart, stop 또는 예외가 발생한다.
근거: agent가 없는데도 thinking 표시가 남는 재현과 durable metadata 수정이 있다.
장애·경계: /stop도 no_active만 반환해 사용자가 상태를 지울 수 없었다.

GH12. 동일 Slack thread의 다른 AI bot 메시지 유실

언어·플랫폼·등급: 영어/GitHub · Slack · A · 관찰 상한 M3
작성자·날짜: GitHub reporters · 2026-05-21
유형: 봇 간 협업
워크플로: Hermes와 다른 AI Slack 앱을 동일 thread에서 연결한다.
근거: 실제 두 앱 구성, 수동 paste 우회와 추가 VPS 멀티에이전트 재현이 기록됐다.
장애·경계: 다른 bot의 identity만 보이고 본문이 비어 bot-to-bot 대화가 불가능했다.

GH13. 버튼 잘림으로 Slack 기획 인터뷰 사용 불가

언어·플랫폼·등급: 영어/GitHub · Slack · A · 관찰 상한 M2
작성자·날짜: GitHub reporter · 2026-08-04
유형: 대화형 설계 스킬
워크플로: Git 저장소와 연결된 Slack thread에서 연속 객관식 설계 인터뷰를 수행한다.
근거: desktop·Android 스크린샷과 실제 사용 불가 진술, 수정 PR이 있다.
장애·경계: Block Kit 버튼의 선택지 텍스트가 잘려 응답할 수 없었다.

GH14. Raspberry Pi 장기 Slack gateway가 이벤트만 유실

언어·플랫폼·등급: 영어/GitHub · Slack · A · 관찰 상한 M3
작성자·날짜: GitHub contributor · 2026-08-02
유형: 장기 실행 복구
워크플로: Raspberry Pi에서 Socket Mode gateway를 장기 운영한다.
근거: 연결이 정상처럼 보인 채 이벤트가 멈춘 실재현과 history recovery·dedup 수정이 있다.
장애·경계: 메시지 유실과 queue overflow 순서 변경이 발생했다. 별도 backfill PR은 이 사례군에 병합했다.

GH15. AIHQ Slack 프로젝트의 thread 연속성과 파일 전달

언어·플랫폼·등급: 영어/GitHub · Slack · A · 관찰 상한 M4
작성자·날짜: GitHub contributor · 2026-06-05
유형: 프로젝트 작업 시스템
워크플로: Slack thread를 프로젝트 진행 파일에 바인딩하고 하위 에이전트 위임과 MEDIA 파일 전달을 운영한다.
근거: 실제 token/channel에서 auth, channel, 직접 업로드와 Hermes MEDIA 업로드를 검증했다.
장애·경계: thread 연결 단절, 로컬 경로 노출, context 없는 fan-out과 결과 버전 덮어쓰기 위험이 있었다.

GH16. Slack permalink로 다른 thread 문맥 가져오기

언어·플랫폼·등급: 영어/GitHub · Slack · B · 관찰 상한 M2
작성자·날짜: GitHub contributor · 2026-05-08
유형: 교차 스레드 문맥
워크플로: 현재 Slack prompt에 과거 thread permalink를 붙여 conversations.replies 문맥을 주입한다.
근거: 실제 유용한 workflow로 리뷰됐고 후속 PR로 계승됐다.
장애·경계: 임의 채널 링크 접근 권한 검증이 필요해 원 PR은 대체됐다.

ZH01. DeepSeek + Discord 7×24 VPS 서버 관리

언어·플랫폼·등급: 중국어 · Discord · A · 관찰 상한 M3
작성자·날짜: GK实验室 · 2026-06-19 update
유형: 서버 관리·알림
워크플로: 휴대폰 Discord에서 서버 상태를 묻고 매일 자동 보고와 사이트 장애 알림을 받는다.
근거: VPS 사양, 메모리, 10초 내 응답, cron, 실제 401 로그와 해결 과정을 확인했다.
장애·경계: DeepSeek 400, Discord 401, intents, systemd PATH 문제를 해결했다.

ZH02. Windows/WSL2 Discord·WeChat 통합 실전

언어·플랫폼·등급: 중국어 · Discord · A · 관찰 상한 M2
작성자·날짜: Xie Jiayun · 2026-04-17
유형: Windows 격리 운영
워크플로: WSL2의 Hermes를 Discord channel mention과 DM으로 사용하고 WeChat도 병행 연결한다.
근거: 버전, doctor, gateway 출력과 실제 설정·오류를 확인했다.
장애·경계: skill slash-command가 Discord 8,000자 제한을 넘어 동기화에 실패했지만 기본 채팅은 동작했다.

ZH03. Mac·Windows 여러 Agent의 Discord 통합 관리

언어·플랫폼·등급: 중국어 · Discord · A · 관찰 상한 M3
작성자·날짜: GoFly · 2026-04-12
유형: 크로스머신 멀티에이전트
워크플로: Mac과 Windows의 Hermes/OpenClaw를 같은 Discord 서버에 연결하고 agent-to-agent 호출을 구성한다.
근거: 작성자가 실제 통과한 세 에이전트와 상호 호출을 영상 설명에서 명시했다.
장애·경계: Telegram을 포기하고 Discord로 전환했으며 상세 장애 로그는 제한적이다.

KO01. Hermes 설치 + local LLM + Discord 설정

언어·플랫폼·등급: 한국어 · Discord · A · 관찰 상한 M2
작성자·날짜: 낭뉴 · 2026-04-18
유형: 로컬 모델 원격 사용
워크플로: Mac의 llama.cpp Qwen 모델을 Hermes와 Discord gateway에 연결한다.
근거: 설치 출력, 모델 응답, unauthorized 로그와 재시작 후 성공을 기록했다.
장애·경계: allowlist 부재로 이모지만 반응했다. allow-all 우회는 보안상 위험하다.

KO02. WSL2 격리 환경 Discord 작업 봇

언어·플랫폼·등급: 한국어 · Discord · A · 관찰 상한 M2
작성자·날짜: EUNCHEOK · 2026-05-31
유형: 격리형 작업 봇
워크플로: Windows 파일 접근 위험을 줄이기 위해 WSL2에 설치하고 전용 free-response 채널에서 코드·파일 작업을 수행한다.
근거: 설정, 서비스 등록, 봇 성공과 README 생성 같은 실제 작업을 기록했다.
장애·경계: 설정 항목이 많고 기존 bot token과 채널 정책을 세밀하게 맞춰야 했다.

KO03. Hermes Slack 세팅 핵심만 쉽게 따라하기

언어·플랫폼·등급: 한국어 · Slack · A · 관찰 상한 M2
작성자·날짜: PYU · 2026-05-07
유형: Slack thread 작업
워크플로: Socket Mode를 연결하고 최신 자료 검색을 시킨 뒤 thread 응답으로 전환한다.
근거: 첫 응답, 작업 결과, sethome 시행착오와 thread 결과를 기록했다.
장애·경계: @봇이름 /sethome 형식과 reply_in_thread 설정을 찾아야 했다.

KO04. Hermes 싱글에이전트에서 멀티에이전트로

언어·플랫폼·등급: 한국어 · Slack · A · 관찰 상한 M4
작성자·날짜: PYU · 2026-05-20
유형: 연구·작성 파이프라인
워크플로: Slack에서 researcher, writer, orchestrator가 조사·작성·HTML 생성·완료 보고를 이어간다.
근거: 실사용 중인 일일 리포트·논문 요약, agent 호출 흐름과 권한 장애를 기록했다.
장애·경계: SLACK_ALLOWED_USERS가 bot 간 호출을 막아 각 Bot ID에 권한을 추가했다.

KO05. Hermes Agent로 나만의 Slack AI 비서 구축

언어·플랫폼·등급: 한국어 · Slack · B · 관찰 상한 M2
작성자·날짜: 양파고 · 날짜 미표기
유형: 학교·집·모바일 공통 인터페이스
워크플로: Windows Hermes를 Slack Socket Mode에 연결하고 로컬 Gemma와 Gemini 모델을 수동 전환·fallback한다.
근거: 첫 연동, 실제 대화, 모델 확인과 Ollama 중지 후 fallback 테스트를 기록했다.
장애·경계: Slack 패키지 추가 설치가 필요했고 자동 난이도 라우팅 대신 수동 별칭을 사용했다.

KO06. Hermes Agent로 로컬 AI 자동화하기

언어·플랫폼·등급: 한국어 · Discord · B · 관찰 상한 M2
작성자·날짜: Kim, DongKi · 2026-07-01
유형: cron 브리핑
워크플로: 날씨·뉴스 브리핑 cron과 skill을 구성하고 Discord로 결과를 전달한다.
근거: 작성자가 직접 사용한 흐름이라고 명시했으나 대화·결과 화면은 제한적이다.
장애·경계: 한 서버의 여러 AI bot 사이 mention loop를 주의점으로 지적했다.

부록 B. 조사 한계

Reddit 직접 원문은 공개 검색 밀도가 낮아, 실제 사례의 상당수는 YouTube·블로그·GitHub에서 확보했다.
공식 Discord 내부 대화는 공개 영구 링크와 전체 검색이 제한돼 GitHub로 공개 전환된 기록만 사용했다.
중국어 知乎·일부 CSDN·微信公众号는 접근 제한이 있었으며 스니펫만 확보한 후보는 제외했다.
한국어 Naver·비공개 Discord 커뮤니티는 검색 색인이 제한적이다.
영상 자동자막은 제품명 오인식 가능성이 있어 화면·설명·문맥과 함께 검토했다.
사례 공개자는 성공적인 사용자와 기술 콘텐츠 제작자에 편향될 수 있다. GitHub 장애 사례를 별도 포함해 성공 편향을 완화했지만 전체 사용자 모집단을 대표하지는 않는다.
M0~M5는 연구용 가설이며 제품 공식 등급이 아니다. 반복 기간과 outcome metric이 부족한 사례에는 보수적인 상한을 부여했다.

부록 C. 재현·검증 정보

데이터 파일: reports/hermes-slack-discord-cases/cases.json
생성 스크립트: reports/hermes-slack-discord-cases/build_report.py
사례 수: 41
고유 ID: 41
고유 URL: 41
필수 필드 누락: 0
공식 audit 원본: C:/Users/msi/hermes-agent-official-audit-report-ko.md