Hermes 에이전트로 나만의 AI 직원 팀 만들기
📺 원본 영상: Hermes 에이전트로 나만의 AI 직원 팀 만들기! 🎙️ 채널: 시민개발자 구씨 📅 정리 일자: 2026-06-13 ⚠️ Note: 본 리포트는 영상의 음성을 텍스트로 변환(STT)하여 정리한 것입니다. 화면에 표시된 자료(코드, 파일 구조, 설정 화면 등)는 포함되지 않을 수 있으며, 일부 내용은 원본 영상 참조가 필요합니다.
개요
Hermes 에이전트는 단일 AI 비서 하나를 만능으로 운영하는 것에서 벗어나, 직무별로 역할이 분리된 여러 AI 직원이 서로 협업하는 팀 구조를 구현할 수 있는 프레임워크다. 이 영상은 기본 직원(자비스)을 총괄 PM으로 두고, 리서치 담당 뉴턴(Newton)과 콘텐츠 담당 해밍웨이(Hemingway)를 추가 채용하여 세 명이 Slack에서 실제로 협업하는 조직을 구축하는 전 과정을 다룬다. 1인 사업가나 소규모 팀처럼 여러 업무를 병렬로 굴려야 하는 환경에서 즉시 적용 가능한 실전 가이드다.
왜 AI 직원을 1명이 아닌 팀으로 운영해야 하는가
AI 비서를 처음 도입할 때 많은 사람들은 한 명의 직원에게 리서치, 글쓰기, 일정 관리, 보고까지 모든 업무를 몰아서 시키는 방식을 택한다. 강연자도 이 방식으로 시작했지만, 업무량이 늘어날수록 명확한 문제가 드러났다고 설명한다. 한 직원이 여러 역할을 동시에 수행하다 보면 역할의 경계가 흐려지고, 그 결과 결과물의 품질이 저하된다는 것이다.
이 문제의 해법은 현실 조직 운영과 동일하다. 리서치는 리서치 전문가에게, 콘텐츠 제작은 콘텐츠 전문가에게 위임하고, 총괄 PM이 이를 조율하며 최종 보고를 올리는 구조다. 강연자는 이러한 역할 분리가 AI 직원에서도 결과물의 완성도를 높이는 핵심 원리라고 강조한다.
Hermes 멀티 프로필의 구조적 원리
Hermes가 이러한 팀 구조를 가능하게 하는 핵심 메커니즘은 프로필(Profile) 기능이다. Hermes 안에서 여러 프로필을 생성하면 각 프로필이 완전히 독립된 AI 직원으로 동작한다. 단순히 시스템 프롬프트만 다른 것이 아니라, 각 직원은 자신만의 정체성, 기억, 운영 규칙을 별도로 가진다.
구체적으로 각 프로필은 다음 네 가지 핵심 문서를 독립적으로 보유한다.
soul.md— 직원의 정체성(Identity), 미션, 운영 원칙user.md— 사용자에 대한 맥락 정보memory.md— 직원의 장기 기억agents.md— 업무 수행 시 준수해야 할 공통 프로토콜 및 프로세스
04:17 - 해밍웨이 soul.md 내용 — Identity, Mission, Operating Principles 등 항목 구성 화면
이 네 문서가 직원마다 별도로 존재하기 때문에, 자비스·뉴턴·해밍웨이는 각자 고유한 정체성과 노하우를 가지고 자신의 직무에만 집중할 수 있다. 강연자는 이 구조를 통해 “각 직원이 본인만의 직무에 포커스하는 전문성”을 확보할 수 있다고 설명한다.
파일 시스템 구조 이해하기
Hermes의 파일 저장 구조를 이해하는 것은 멀티 프로필 관리의 기초다. 기본(디폴트) 직원의 파일은 data 폴더 바로 아래에 soul.md, agents.md, 그리고 memories/ 하위의 memory.md, user.md가 위치한다. 반면 추가로 생성한 직원들은 별도의 profiles/ 폴더 아래에 직원 이름으로 된 하위 폴더가 생성되고, 그 안에 동일한 문서 구조가 복제된다.
03:25 - VS Code에서 데이터 폴더 구조 확인 — 디폴트 직원의 soul.md, agents.md, memories 폴더 구성
정리하면 다음과 같다.
data/
soul.md ← 디폴트 직원(자비스)
agents.md
memories/
memory.md
user.md
profiles/
newton/ ← 추가 직원 뉴턴
soul.md
agents.md
skills/
crons/
memories/
memory.md
user.md
hemingway/ ← 추가 직원 해밍웨이
soul.md
agents.md
...
💡 [영상 참조] 위 구조는 강연자의 구두 설명을 바탕으로 재구성한 것입니다. 실제 디렉토리 구조는 원본 영상의 VS Code 화면을 참고하세요.
새 직원 온보딩 프로세스 — 단계별 가이드
1단계: 기존 직원에게 프로필 생성 위임
새 직원 프로필을 만들기 위해 별도의 설치 작업이 필요하지 않다. 이미 셋업된 기본 직원(자비스)에게 텔레그램 채팅창으로 “기본 프로필을 참고해서 뉴턴과 해밍웨이 프로필 두 개를 만들어 달라”고 요청하면 된다. 이때 중요한 포인트는 세션 기록이나 메모리는 복사하지 말도록 명시하는 것이다. 환경 설정의 뼈대는 공유하되, 각 직원의 개인 기억은 깨끗한 상태로 시작해야 하기 때문이다.
강연자는 이 접근 방식의 장점으로 문서 구조의 일관성을 꼽는다. 직원마다 soul.md의 형태가 제각각이면 나중에 유지보수가 어려워진다. 디폴트 직원을 먼저 잘 만들어두고, 그것을 기반으로 내용만 직무에 맞게 수정하는 방식이 관리하기 훨씬 수월하다.
2단계: 핵심 문서 4종 생성
프로필이 생성된 직후에는 soul.md만 존재하고 나머지 문서가 없는 상태다. 따라서 다음 네 가지를 순서대로 생성 요청해야 한다.
user.md 생성: 디폴트 직원의 사용자 정보 중 공통 항목만 가져와서 생성을 요청한다. 사용자 이름, 선호도, 업무 맥락처럼 모든 직원이 공유해야 하는 기본 정보가 이 파일에 담긴다.
agents.md 생성: 모든 직원이 작업 수행 시 지켜야 하는 공통 프로토콜과 프로세스를 정의한다. 자비스에 이미 이 파일이 존재하므로, 그것을 기반으로 각 직원의 직무에 맞게 수정하도록 요청한다. 강연자는 이 프롬프트를 영상 설명란의 상세 가이드 문서에 첨부한다고 언급했다.
memory.md 생성: 실제 작업을 하면서 자연스럽게 내용이 쌓이지만, 시드(seed) 데이터로서 기초 메모리를 미리 넣어두면 직원이 처음부터 맥락을 파악하고 일을 시작할 수 있다. 초기 생성 이후에는 Hermes가 작업 과정에서 자동으로 user.md와 memory.md를 갱신한다.
3단계: .env 및 config.yml 설정
새 직원이 실제로 Slack이나 텔레그램을 통해 소통하려면 .env 파일에 채널 연동 정보를 입력해야 한다. 설정이 필요한 주요 항목은 다음과 같다.
08:41 - .env 파일 설정 화면 — 텔레그램 봇 토큰, 슬랙 봇 토큰, allowed users, home channel 항목
TELEGRAM_BOT_TOKEN: 직원별 텔레그램 봇 토큰TELEGRAM_ALLOWED_USERS: 본인의 텔레그램 사용자 IDSLACK_BOT_TOKEN/SLACK_APP_TOKEN: 슬랙 연동 토큰SLACK_ALLOWED_USERS: 본인의 슬랙 ID + 각 직원들의 슬랙 봇 ID (직원끼리 서로 소통하려면 반드시 직원들의 ID도 포함해야 한다)SLACK_HOME_CHANNEL: 해당 직원이 기본으로 활동할 슬랙 채널 ID
슬랙 채널 ID는 슬랙에서 해당 채널명을 클릭하면 하단에 표시된다. 직원마다 서로 다른 홈 채널을 지정할 수 있어, 뉴턴은 리서치 채널, 해밍웨이는 콘텐츠 채널에 각각 귀속시킬 수 있다.
09:26 - Slack 채널 ID 확인 방법 — 채널명 클릭 시 하단에 채널 ID가 표시되는 화면
4단계: 게이트웨이 연결 및 재시작
도커(Docker) 환경에서 운영 중이라면 Hermes 에이전트를 재시작한 뒤 게이트웨이 연결을 확인해야 한다. 강연자는 텔레그램이 아닌 터미널에서 직접 도커 컨테이너로 접속하여 Hermes 터미널을 실행하는 방식을 권장한다. 텔레그램에서 재시작 관련 작업을 요청하면 도커 환경에서 에러가 발생할 수 있기 때문이다.
# 도커 컨테이너 접속 예시 (재구성된 명령어)
docker exec -it [컨테이너_풀네임] bash💡 [영상 참조] 정확한 docker exec 명령어 전체 형태는 원본 영상의 터미널 화면을 참고하세요. 강연자는 상세 가이드 문서에 이 명령어를 포함한다고 언급했습니다.
게이트웨이 연결 후 텔레그램에서 각 직원에게 직접 말을 걸어 응답이 오는지 확인하면 온보딩이 완료된 것이다.
Slack 멀티 에이전트 협업 설정
CLI 방식으로도 직원들 간 협업이 가능하지만, 복잡한 업무일수록 각 직원이 어떤 식으로 소통하며 작업했는지 추적하기가 어렵다. Slack을 협업 채널로 활용하면 대화 이력이 채널에 남아 나중에 검토하기 용이해진다. 이를 위해 config.yml에서 다음 세 가지를 설정해야 한다.
allow_bots: true: 봇(직원)이 다른 봇을 맨션했을 때 반응할 수 있도록 허용한다. 이 설정이 없으면 직원끼리 서로 메시지를 전달할 수 없다.
strict_mention: true: 반드시 @직원명으로 맨션했을 때만 해당 직원이 응답하도록 제한한다. 이 설정이 없으면 의도치 않게 여러 직원이 동시에 반응하는 상황이 생길 수 있다.
allowed_channels: 직원이 활동할 수 있는 채널 목록을 명시한다. 채널 ID를 리스트로 입력하면 해당 채널 내에서만 직원이 응답한다.
무한 루프 방지 규칙
멀티 에이전트 환경에서 가장 주의해야 할 문제는 직원들이 서로 맨션을 무한 반복하며 토큰을 낭비하는 상황이다. 이를 방지하기 위해 강연자는 agents.md에 핸드오프(handoff) 횟수 제한 규칙을 명시하는 방법을 사용한다. 예를 들어 “최대 5회까지만 다른 직원에게 작업을 넘길 수 있다”는 규칙을 운영 프로토콜로 정의해두면, 직원들이 불필요한 대화를 이어가지 않고 주어진 횟수 안에 결과를 내놓게 된다.
실전 협업 시연 — 리서치부터 블로그 초안까지
CLI 방식 협업
강연자는 먼저 자비스에게 “멀티 프로필 구분 사용 이유에 대한 블로그 초안 재료를 만들어라”는 작업을 지시했다. 자비스는 뉴턴을 호출해 리서치를 요청하고, 결과를 받아 해밍웨이에게 블로그 초안 생성을 의뢰한 후, 최종 결과를 보고한다. 각 직원이 생성한 결과물은 별도 문서(Summary, Draft Material)로 저장된다.
13:45 - CLI 협업 테스트 완료 — 자비스가 뉴턴·해밍웨이를 호출해 생성한 Summary 및 Draft Material 문서
이 방식은 간단하고 빠르지만, 각 직원이 어떤 과정으로 작업했는지 중간 커뮤니케이션 내용을 실시간으로 볼 수 없다는 한계가 있다.
Slack 방식 협업 (권장)
보다 복잡한 업무에는 Slack을 통한 협업 방식이 적합하다. 강연자는 텔레그램으로 자비스에게 “이번 주 AI 자동화 트렌드 중 고객에게 설명할 주제를 찾아 블로그를 제작하라”고 지시했다. 이후 실제 작업은 Slack에서 다음과 같이 진행됐다.
- 자비스가 리서치 채널에서
@뉴턴을 맨션하며 리서치 의뢰 - 뉴턴이 작업을 완료하고 자비스에게 보고
- 자비스가 콘텐츠 채널로 이동하여
@해밍웨이에게 블로그 초안 작성 요청 - 해밍웨이가 초안 완성 후 자비스에게 보고
- 자비스가 슬랙 채널과 텔레그램 모두에 최종 결과를 보고
18:15 - Slack 리서치 채널 — 자비스가 뉴턴을 맨션하며 작업 요청하고 뉴턴이 완료 보고하는 대화 이력
19:02 - 텔레그램 최종 보고 화면 — 자비스가 슬랙 협업 완료 결과를 텔레그램으로 보고하는 메시지
이 방식의 핵심 장점은 각 채널의 대화 이력이 그대로 보존된다는 점이다. 나중에 슬랙 채널에 들어가면 직원들이 어떤 맥락에서 어떤 식으로 소통하며 작업했는지 전체 흐름을 추적할 수 있다.
Cron을 활용한 완전 자율 운영
Slack 협업 구조만으로는 아직 사람이 매번 초기 요청을 보내야 한다는 한계가 있다. 진정한 의미의 AI 조직은 내가 요청하기 전에 직원들이 먼저 알아서 일을 시작하고, 서로 협업하고, 결과를 가져다 놓는 구조다. 이를 구현하는 것이 **크론(Cron)**이다.
강연자가 제시하는 크론 기반 자율 운영 시나리오는 다음과 같다. 뉴턴은 특정 주제에 대해 주기적으로 리서치를 수행하고 결과를 정해진 폴더에 저장한다. 해밍웨이는 그 폴더를 주기적으로 감시하다가 새 파일이 생기면 자동으로 블로그 초안을 생성한다. 자비스는 두 작업이 완료된 후 초안을 검토하고 피드백을 남긴다. 이 모든 과정이 사용자의 개입 없이 진행되고, 사용자는 슬랙 채널에 접속해 이미 정리된 결과물에 최종 컨펌이나 추가 피드백만 남기면 된다.
이 구조가 완성되면 “내가 확인하기 전에 직원들이 알아서 협업을 진행하고 서로 피드백도 하는” 진정한 AI 팀이 만들어진다.
마무리 — 핵심 원칙과 실행 순서
강연자는 이 영상의 핵심을 한 문장으로 정리한다. “AI 직원은 한 명을 만능으로 키우기보다 직무를 나눠서 작은 팀으로 굴리는 것이 훨씬 안정적이다.”
처음부터 여러 직원을 한꺼번에 셋업하려 하면 각 문서의 품질을 관리하기 어렵다. 강연자가 권장하는 실행 순서는 명확하다. 먼저 디폴트 직원 하나를 충분히 잘 만들어 놓는다. 그 문서 구조를 기반으로 두 번째, 세 번째 직원을 온보딩한다. Slack 커뮤니케이션 설정과 agents.md의 운영 규칙으로 협업 구조를 잡는다. 마지막으로 Cron으로 반복 업무를 자동화하면 조직이 자율적으로 돌아가기 시작한다.
첫 번째 직원 셋업에 공을 들일수록 이후 직원들을 추가하는 비용이 낮아지고, 전체 조직의 운영 품질이 균일하게 유지된다는 것이 강연자의 핵심 조언이다.
📚 출처 및 참고
| 구분 | 내용 |
|---|---|
| 원본 영상 | Hermes 에이전트로 나만의 AI 직원 팀 만들기! |
| 채널 | 시민개발자 구씨 |
| 영상 길이 | 약 22분 |
| 리포트 작성 | 2026-06-13 |
| 작성 방식 | YouTube 영상 STT 변환 후 에디팅 |
💬 본 리포트는 영상 내용을 바탕으로 재구성되었습니다. 정확한 내용은 원본 영상을 참조해 주세요.