Hermes를 Slack 팀원으로 만들기: 헤르메스 연결부터 AI 동료 리서처 에이전트 추가까지

한 줄 요약: Mac에서 실행되는 Hermes Agent를 Slack에 연결하고, 별도의 딥 리서치 전문 에이전트 ‘리서’까지 추가해 사람과 AI 동료가 같은 채널에서 협업하는 구조를 만들었다.

이번에는 단순히 Slack에 챗봇 하나를 붙인 것이 아니다. ‘맥헬미’는 내 MacBook Air에서 실행되는 Hermes Agent에게 붙인 친근한 별명이다. ‘맥에서 일하는 헬미’라는 뜻으로, 지금 이 글을 함께 만들고 실제 작업을 수행하는 AI 에이전트이기도 하다. 이 맥헬미를 Slack의 정식 팀원처럼 연결하고, 이어서 딥 리서치 전담 동료 ‘리서’를 별도의 에이전트로 구성했다. 마지막에는 나와 맥헬미, 리서가 함께 일할 수 있는 협업 채널까지 만들었다.

먼저 사실관계부터 정확히 말하면 Slack 데스크톱 앱은 내가 Mac에 설치했다. 그다음 Slack 채널 생성, Hermes용 Slack App 구성, Gateway 연결, 사용자 허용 정책, 실제 메시지 왕복 검증은 맥헬미와 함께 자동화해 진행했다. 9월 10일 맥헬미 연결을 시작했고, 9월 11일에는 리서까지 독립 에이전트로 확장했다.

왜 터미널이 아니라 Slack이었나

Hermes는 터미널에서 강력하게 일하지만, 매번 터미널을 열어야 한다면 일상적인 협업 도구가 되기 어렵다. 내가 원한 것은 평소 사용하는 Slack에서 사람에게 말을 걸듯 AI 에이전트에게 요청하는 방식이었다.

DM에서는 맥헬미 (나의 헤르메스 닉네임)와 일대일로 대화한다.
프로젝트 채널에서는 맥헬미를 멘션해 업무를 맡긴다.
조사가 필요하면 리서를 멘션해 근거 수집과 교차 검증을 맡긴다.
한 스레드 안에서 사람과 에이전트가 결과를 이어서 검토한다.

목표는 “Slack에서 답변하는 봇”이 아니라, 역할과 기억과 도구를 가진 AI 동료가 실제 업무 공간에 들어오는 것이었다.

1단계: 맥헬미용 Slack 공간 만들기

처음에는 맥헬미와 대화할 전용 공개 채널을 만들었다. 이름은 #mac-helmi로 정했다. 채널만 만든다고 Hermes가 들어오는 것은 아니다. Slack에서 독립적으로 보이는 앱과 Hermes를 연결해야 한다.

Hermes CLI로 Slack App Manifest를 생성했다. Manifest에는 앱의 이름과 설명, 봇 사용자, Slash Command, 필요한 이벤트 구독, Socket Mode 설정이 들어간다. 실제 작업에서 사용한 형태는 다음과 같다.

hermes slack manifest --agent-view \
  --name 'mac-helmi' \
  --description 'Local Hermes AI agent' \
  --write

생성된 Manifest를 Slack App 설정에 등록하고 워크스페이스에 앱을 설치했다. 이때 표시 이름과 기술 이름에 적용되는 Slack의 검증 규칙이 달라 한글 이름과 영문 기술 이름을 구분해 처리해야 했다.

2단계: Slack과 Hermes Gateway 연결하기

이번 연결에서는 Slack의 Socket Mode를 사용했다. 공개 웹 서버를 별도로 열지 않고도 Slack 이벤트를 로컬 Hermes Gateway가 실시간으로 받을 수 있는 방식이다.

메시지 흐름

찰리의 Slack 메시지 → Slack App → Socket Mode → Hermes Gateway → 맥헬미 → Slack 답변

연결에 필요한 핵심 요소는 다음과 같았다.

워크스페이스에 설치된 맥헬미 Slack App
봇 인증 정보와 Socket Mode용 앱 인증 정보
메시지를 보낼 수 있는 사용자 허용 목록
Slack 플랫폼이 활성화된 Hermes 설정
Mac 로그인 때 자동으로 시작되는 Hermes Gateway

인증 정보는 화면이나 보고서에 노출하지 않고 권한이 제한된 로컬 자격 증명 저장소로 옮겼다. 설정값은 파일을 직접 손으로 고치기보다 Hermes 명령으로 적용했다.

hermes config set platforms.slack.enabled true
hermes config get platforms.slack.enabled
hermes config check

Gateway는 macOS의 관리 서비스로 등록했다. 실제 확인 결과 서비스 정의가 현재 Hermes 설치와 일치했고, 로그인 시 자동 시작과 비정상 종료 시 자동 재시작이 가능한 상태였다.

3단계: “연결됨”을 실제 대화로 검증하기

Socket Mode가 연결됐다는 로그만으로는 작업이 끝난 것이 아니다. 앱이 채널에 들어와 있는지, 내가 허용된 사용자인지, Hermes가 요청을 처리하고 최종 답변을 다시 Slack에 올리는지까지 확인해야 한다.

#mac-helmi 채널에서 다음처럼 실제 메시지를 보냈다.

@mac-helmi 연결 성공이라고 답해줘.

맥헬미가 “연결 성공! ✅”이라고 답했다. 이어서 DM에서도 멘션 없이 대화가 되는 것을 확인했고, 채널을 홈 채널로 지정했다. 이 시점에서야 Slack 설치가 아니라 Hermes와 Slack의 종단 간 연결이 완료됐다고 판단했다.

4단계: 두 번째 AI 동료 ‘리서’ 만들기

맥헬미 하나가 모든 일을 처리하게 할 수도 있지만, 협업 구조를 만들려면 역할을 분리하는 편이 낫다. 강의 원고와 컨설팅 보고서를 만들면서 자료 조사, 1차 출처 확인, 상충하는 정보의 교차 검증을 전담할 동료가 필요해졌다. 그래서 맥헬미가 딥 리서치(Deep Research) 전문 에이전트를 별도의 Hermes 프로필로 만들고 ‘리서’라는 이름을 붙였다.

‘리서’는 Research와 Researcher, 그리고 Deep Research의 역할을 한국어로 짧고 편하게 부르기 위해 만든 이름이다. Slack에서 “리서에게 조사시켜 보자”라고 자연스럽게 부를 수 있으면서, 무슨 일을 맡은 동료인지 이름만 들어도 알 수 있게 한 것이다.

리서는 단순한 별명이 아니라 별도의 Hermes 프로필이다. 현재 리서의 역할은 다음처럼 정의되어 있다.

근거 중심의 심층 리서치 전문 연구원. 1차 자료를 우선 조사하고 출처를 교차 검증하여 인용 가능한 의사결정 보고서를 작성한다.

모델과 역할, 기억, 설정, Slack 연결을 맥헬미와 분리했다. 확인 당시 기본 맥헬미 프로필과 researcher 프로필의 Gateway가 각각 실행 중이었다. 리서는 별도의 Slack App ‘리서’로 설치해 Slack에서도 독립된 팀원으로 보이게 했다.

중요한 차이: Hermes 프로필을 하나 더 만드는 것만으로 Slack에 새 팀원이 자동으로 생기지는 않는다. Slack에서 독립적으로 대화할 에이전트마다 별도의 Slack App 정체성, 인증 정보, 프로필 범위의 Gateway가 필요하다.

5단계: 맥헬미와 리서를 같은 협업 채널에 추가하기

두 에이전트와 내가 함께 일할 공개 채널로 #agent-lab을 만들었다. 이 채널에 맥헬미와 리서를 각각 초대했다.

에이전트끼리 메시지를 무제한으로 읽고 답하게 두면 서로의 답변에 다시 반응하며 반복 루프가 생길 수 있다. 그래서 리서에는 다음 원칙을 적용했다.

봇 메시지는 명시적으로 멘션된 경우에만 처리한다.
채널에서는 정확한 멘션이 있을 때만 답한다.
사람 → 맥헬미 → 리서처럼 한 방향씩 테스트한다.
각 에이전트는 한 번 답하고, 추가 멘션이 없으면 멈춘다.

실제 설정에서도 allow_bots: mentions, require_mention: true, strict_mention: true를 적용했다. 이것이 여러 AI 에이전트를 Slack에 넣을 때 필요한 기본 안전장치다.

DM, 채널, 스레드는 같은 기억을 공유할까?

여기서 중요한 운영 원리를 하나 알게 됐다. Slack의 DM, 채널 일반 대화, 각 채널 스레드는 서로 다른 대화 세션이다.

찰리와 맥헬미의 DM은 하나의 독립 세션이다.
#agent-lab의 일반 대화는 또 다른 세션이다.
#agent-lab 안의 각 스레드도 스레드별 세션이다.
찰리와 리서의 DM은 리서 프로필의 별도 세션이다.

같은 프로필은 역할, 장기 기억, 스킬, 설정과 파일을 공유할 수 있지만, 이전 대화 전체가 다른 채널이나 새 스레드에 자동으로 붙는 것은 아니다. 따라서 실제 협업에서는 하나의 업무를 하나의 루트 메시지와 스레드에서 계속 이어가는 편이 좋다.

자동화 과정에서 가장 어려웠던 부분

1. 앱 설치와 실제 연결은 다르다

Slack App이 워크스페이스에 보인다고 Hermes와 대화할 수 있는 것은 아니다. 앱 설치, Socket Mode, 사용자 허용 정책, 채널 가입, Gateway 실행과 메시지 왕복이 모두 성공해야 한다.

2. 채널 가입을 별도로 확인해야 한다

명령이 Hermes에 도착해도 봇이 채널 멤버가 아니면 답변 게시가 실패할 수 있다. 그래서 앱 목록에 보이는지만 확인하지 않고 실제 채널 멤버십과 답변까지 검증했다.

3. 에이전트마다 독립된 정체성이 필요하다

맥헬미와 리서는 같은 Hermes 기술을 사용하지만 Slack에서는 서로 다른 팀원이다. 독립 DM과 독립 멘션을 제공하려면 각자 프로필, Slack App과 Gateway가 필요하다.

4. 봇 간 대화에는 루프 방지 정책이 필요하다

여러 에이전트를 한 채널에 넣을수록 “모든 메시지에 반응”하는 설정은 위험하다. 명시적 멘션과 한 방향씩의 테스트가 중요했다.

이번 작업을 작은 AI 팀의 관점에서 보면

이 구조의 핵심은 역할이 다른 여러 AI 에이전트를 한 업무 공간에서 조율하는 데 있다.

큰 모델 하나에게 모든 일을 맡기는 대신, 맥헬미는 업무 총괄과 실행을 담당하고 리서는 근거 조사와 교차 검증을 담당한다. 사람인 나는 Slack에서 적합한 동료를 호출하고, 결과를 확인하고, 다음 행동을 승인한다.

사람: 목적 설정, 승인, 최종 판단
맥헬미: 업무 분해, 실행, 결과 통합
리서: 1차 자료 조사, 출처 교차 검증, 근거 보고
Slack: 요청·협업·검토가 모이는 공통 작업 공간

핵심은 AI가 사람을 대신하는 것이 아니라, 사람이 여러 AI 동료의 역할과 비용과 권한을 조정하는 데 있다.

개인과 소규모 조직이 적용할 때의 체크리스트

첫 번째 에이전트의 역할을 한 문장으로 정한다.
전용 Slack App과 채널을 만든다.
사용자·채널 허용 범위를 먼저 설정한다.
Gateway 연결 로그와 실제 메시지 왕복을 모두 확인한다.
두 번째 에이전트는 역할이 분명할 때만 추가한다.
에이전트마다 독립된 프로필과 Slack 정체성을 사용한다.
공용 채널에서는 멘션 전용 정책으로 반복 대화를 막는다.
업무별로 하나의 스레드를 유지한다.
토큰·인증 정보·개인 ID는 문서와 화면에 노출하지 않는다.
AI의 결과는 사람이 확인한 뒤 외부 발송이나 게시를 승인한다.

마무리

이번 작업으로 Mac 안에서만 일하던 Hermes가 Slack의 실제 업무 공간으로 들어왔다. 그리고 맥헬미 하나에서 끝나지 않고, 리서라는 전문 동료를 추가해 작은 AI 팀의 형태를 갖추었다.

가장 인상적인 변화는 기술보다 사용 방식이다. 이제 나는 터미널 명령을 기억하기보다 Slack에서 동료를 부른다. 맥헬미에게 일을 정리해 달라고 하고, 리서에게 근거를 조사해 달라고 요청한다. 결과는 같은 스레드에서 검토한다.

AI 에이전트의 다음 단계는 더 똑똑한 챗봇이 아니라, 역할과 책임과 협업 규칙을 가진 작은 팀일 수 있다.

찰리초이 스토리 블로그

이 블로그 검색