🖼️ 인포그래픽

🖼️ 4컷 인포그래픽

💡 한 줄 결론

Hermes 에이전트로 나만의 AI 직원 팀을 만들려면 한 명의 만능 비서보다 프로필·기억·채널·자동화를 직무별로 나눠 운영하는 구조가 핵심입니다.

📌 핵심 요점

1. 한 명의 AI 직원에게 리서치, 글쓰기, 보고를 모두 맡기면 역할이 섞이고 결과물 품질이 떨어질 수 있어, 자비스·뉴턴·해밍웨이처럼 총괄, 리서치, 콘텐츠 제작 역할을 분리하는 방식이 제안된다.
2. Hermes의 프로필 기능은 직원별 soul.md, user.md, memory.md, agents.md, skills, chrome 등을 분리해 각 AI 직원이 고유한 정체성, 기억, 운영 규칙을 갖도록 만드는 기반입니다.
3. 신규 직원은 디폴트 직원의 설정 구조를 재사용하되 세션 기록과 메모리는 복사하지 않고, 직무에 맞게 soul.md, user.md, agents.md, memory.md를 구성하는 흐름으로 온보딩된다.
4. 실제 협업을 위해서는 텔레그램·슬랙 봇 설정, allowed users, free response channels, gateway 연결, Docker 재시작 같은 운영 설정이 필요하며, Docker 환경에서는 컨테이너 내부 터미널에서 게이트웨이를 연결하는 방식이 더 안전하다고 설명된다.
5. 단순 협업은 CLI 기반 문서 생성과 최종 보고로도 가능하지만, 복잡한 업무에서는 Slack 채널별 대화 이력이 남는 구조가 더 적합하며, Cron 자동화까지 붙이면 AI 직원들이 먼저 리서치·초안·피드백을 진행할 수 있다.

🧩 배경과 문제 정의

• 한 명의 AI 직원에게 리서치, 글쓰기, 보고까지 모두 맡기면 업무가 늘어날수록 역할이 섞이고, 결과물의 품질도 흔들릴 수 있다.
• Hermes의 프로필 기능은 직원별 정체성, 기억, 운영 규칙, 스킬, 작업 환경을 분리해 여러 명의 AI 직원을 구성할 수 있게 한다.
• 1인 사업가나 작은 팀처럼 제한된 인원으로 리서치, 콘텐츠 제작, 총괄 보고를 동시에 처리해야 하는 환경에서는 역할 분담형 AI 직원 팀 구조가 중요하다.
• 기본 직원 하나를 잘 만들어 두면, 이후에는 기존 설정을 바탕으로 직무별 문서와 채널 연동만 조정해 신규 직원을 빠르게 확장할 수 있다.
• 제공된 section-detail 기준으로는 후반부에서 Slack 협업을 넘어 Cron 자동화까지 연결하며, 사람이 매번 지시하지 않아도 직원들이 역할에 따라 먼저 움직이는 운영 구조가 핵심 마무리 논지로 제시된다.

🕒 시간순 섹션별 상세정리

1. 여러 AI 직원으로 업무를 분담하는 조직 구조

• 리서치 담당이 자료를 모으고, 콘텐츠 담당이 이를 블로그 초안으로 바꾸며, 메인 비서가 최종 보고하는 구조에서는 사용자가 다른 일을 하는 동안에도 세 명의 AI 직원이 각자 업무를 나눠 처리할 수 있다 [00:56]
• 한 명의 AI 직원에게 여러 업무를 모두 맡기면 일이 많아질수록 역할이 섞이고 결과물 품질이 낮아질 수 있으므로, 직무별 AI 직원으로 작은 조직을 만드는 방식이 필요하다 [01:11]

2. 프로필 기능으로 직원별 정체성과 기억을 분리

• Hermes의 프로필 기능에서는 각 직원이 독립된 soul.md, user.md, memory.md, agents.md, 스킬, 크롬 같은 주요 기능을 별도로 가질 수 있다 [01:38]
• 멀티프로필 구조에서는 자비스, 뉴턴, 해밍웨이처럼 각 직원이 자신의 정체성, 기억, 노하우를 바탕으로 직무에 맞는 역할에 집중한다 [02:01]

3. 프로필 폴더 구조와 소울 문서 구성

• 기본 디폴트 직원의 파일은 데이터 폴더 안에 바로 존재하지만, 추가 직원은 profiles 폴더 아래에 직무별 폴더로 분리되어 관리된다 [03:20]
• 해밍웨이 프로필 안에는 soul.md, skills, chrome, memories 폴더가 있고, memories 안에는 memory.md와 user.md가 들어가는 구조로 드러난다 [03:47]

4. 사용자 정보, 운영 규칙, 장기 기억 문서 생성

• 새로 만든 직원은 memories 폴더에 user.md와 memory.md가 아직 없을 수 있으므로, 디폴트 프로필에서 공통 사용자 정보만 가져온 user.md를 먼저 생성한다 [04:56]
• agents.md는 직원들이 작업할 때 따라야 할 공통 프로토콜과 프로세스를 담는 문서이며, 뉴턴과 해밍웨이에도 각 직무에 맞게 반영된다 [05:34]

5. 텔레그램·슬랙 연동과 직원 간 소통 설정

• 신규 직원에게 실제 작업을 요청하려면 Slack이나 Telegram 같은 채널과 연결해야 하며, config 파일과 env 파일에 직원별 설정을 매핑해야 한다 [07:45]
• 디폴트 직원을 기반으로 생성된 설정에는 기본 직원 값이 남아 있을 가능성이 높기 때문에, 각 직원에 맞는 Telegram 봇 정보와 Slack 봇 정보를 새로 넣어야 한다 [07:55]

6. 재시작과 게이트웨이 연결로 실제 운영 준비

• 설정 변경 사항을 반영하려면 Hermes 에이전트를 재시작해야 하며, Docker 설치 환경에서는 Docker restart로 변경 사항을 적용한다 [10:19]
• 재시작 이후에도 직원들의 게이트웨이가 아직 설정되지 않았다면 자비스와 다른 직원들이 서로 소통할 수 없으므로, 별도의 게이트웨이 연결 작업이 필요하다 [10:35]

7. 게이트웨이 연결 검증과 CLI 기반 직원 협업 테스트

• 게이트웨이 연결과 Docker 재시작 후 자동 복구 설정이 끝나고 프로젝트를 다시 시작하면, 해밍웨이와 뉴턴이 각각 정상적으로 응답하는지 확인한다 [12:07]
• 자비스가 뉴턴에게 먼저 리서치 작업을 맡기고, 그 결과를 받아 해밍웨이에게 블로그 재료 생성을 맡기는 방식으로 멀티프로필 협업 테스트가 진행된다 [13:07]

8. CLI 협업의 장점과 복잡한 팀 작업에서의 한계

• 각 직원이 결과물 문서를 남기면 나중에 어떤 직원이 어떤 작업을 했는지 추적하기 쉬워지고, 가벼운 협업에서는 최종 보고만 받는 방식이 효율적이다 [14:01]
• 여러 직원이 돌아가며 일을 주고받고 사람이 중간에 확인해야 하는 복잡한 팀 협업에서는 CLI 호출만으로 직원들의 답변과 작업 과정을 보기 어렵다는 한계가 있다 [14:21]

9. Slack 협업을 위한 설정과 무한 대화 방지 규칙

• allow_bots 설정을 켜면 봇끼리도 멘션에 반응할 수 있고, strict mention을 true로 두면 멘션이 있을 때만 답변하도록 제한할 수 있다 [14:56]
• 허용 채널을 지정해야 해당 Slack 방에서 직원들이 답변할 수 있으며, AGENTS.md 같은 운영 규칙에 최대 핸드오프 횟수를 넣으면 봇끼리 무한히 대화하는 상황을 줄일 수 있다 [15:13]

10. Telegram 지시에서 Slack 채널별 직원 협업으로 이어지는 업무 흐름

• 사용자는 Telegram에서 자비스에게 업무를 맡기지만, 자비스는 Slack 리서치 채널에서 뉴턴에게 리서치를 맡기고 결과를 받은 뒤 콘텐츠 채널에서 해밍웨이에게 블로그 초안을 맡긴다 [16:50]
• 이번 주 AI 자동화 트렌드 중 고객에게 설명할 만한 주제를 찾고 블로그 초안을 만드는 업무가 설정되며, 리서치와 콘텐츠 작성이 Slack 채널별로 분리된다 [17:32]

11. Slack 협업 실행 결과와 대화 이력의 운영 가치

• 자비스가 리서치 채널에서 뉴턴을 멘션해 작업을 맡기고, 뉴턴은 리서치 채널 안에서 해당 작업을 수행한다 [18:10]
• 뉴턴의 작업 결과를 받은 자비스가 이를 콘텐츠 채널로 넘기고, 해밍웨이에게 블로그 글 구조와 초안 생성을 맡긴다 [18:28]

12. Cron 자동화와 역할 분담형 AI 직원 팀 운영

• Slack을 쓰더라도 사람이 매번 직접 일을 시켜야 한다면 효용이 줄어들기 때문에, 반복 업무는 Cron으로 자동화해 직원들이 먼저 움직이게 하는 방식이 핵심이다 [19:19]
• 뉴턴은 정해진 주제 리서치를 수행하고, 해밍웨이는 생성된 리서치 파일을 읽어 블로그 초안을 만들며, 자비스는 이후 초안을 확인하고 피드백까지 줄 수 있는 역할 분담형 운영 구조로 계속된다 [19:47]
• 검증 필요: 제공된 section-detail에는 19:47 이후의 상세 발화가 포함되어 있지 않아, 영상 전체 길이 기준 후반 약 3분 구간의 추가 마무리 멘트나 결론은 이 입력만으로 단정할 수 없다 [20:02]

13. 자비스 검수와 대표 컨펌 중심의 자동 협업 흐름

• 자비스도 별도 Cron으로 뉴턴의 리서치와 해밍웨이의 초안을 확인한 뒤 피드백을 주도록 구성할 수 있다 [20:03]
• 이렇게 하면 사용자가 요청하기 전에 AI 직원들이 초안 검수와 피드백까지 먼저 처리하는 흐름이 된다 [20:12]
• 사람은 이후 Slack 채널에서 작업 내용을 확인하고 추가 컨펌이나 피드백만 주면 된다 [20:23]
• 최종적으로 AI 직원들이 선작업을 끝낸 뒤 대표에게 승인만 받는 방식으로 협업할 수 있다 [20:36]

14. 작은 AI 팀 운영 원칙과 단계적 확장 마무리

• AI 직원은 한 명을 만능으로 키우기보다 직무를 나눠 작은 팀으로 굴리는 편이 더 안정적이라는 점이 핵심이다 [20:40]
• 자비스는 팀장, 뉴턴은 리서치, 해밍웨이는 콘텐츠처럼 직원별 담당 업무를 배분하는 구조가 예시로 제시된다 [20:51]
• 처음부터 여러 명을 한꺼번에 세팅하기보다, 먼저 디폴트 직원 한 명을 잘 키운 뒤 그 설정 문서를 기반으로 다른 직원을 만드는 방식이 권장된다 [21:03]
• Slack 커뮤니케이션 룰과 Cron을 함께 활용하면 직원들이 먼저 협업하고 피드백하는 AI 조직을 만들 수 있으며, 시청자에게 어떤 직원을 추가하고 싶은지 댓글을 요청하며 마무리한다 [21:25]

🧾 결론

• 이 영상의 핵심은 Hermes를 단일 비서 도구가 아니라 직무별 AI 직원 팀으로 확장해 운영하는 방법입니다.
• 프로필 분리는 단순히 이름만 다른 봇을 만드는 것이 아니라, 정체성, 기억, 사용자 맥락, 운영 규칙, 스킬을 분리해 각 직원이 맡은 역할에 집중하도록 만드는 구조입니다.
• Slack과 Telegram 연동은 직원 간 협업을 실제 업무 흐름으로 바꾸는 핵심 요소이며, 특히 Slack은 대화 이력과 채널 분리를 통해 복잡한 협업의 가시성을 높입니다.
• 무한 대화를 막기 위해 strict mention, allow bots, 허용 채널, 최대 핸드오프 횟수 같은 규칙을 명확히 두는 것이 중요한다.
• 최종적으로는 사람이 매번 지시하는 구조보다 Cron 자동화를 통해 AI 직원들이 먼저 일하고, 사람은 검토와 방향 조정에 집중하는 운영 방식이 목표로 제시된다.

📈 투자·시사 포인트

• 1인 사업가나 작은 팀에게는 사람을 바로 늘리기보다 역할 분담형 AI 직원 구조를 먼저 설계하는 것이 반복 업무 처리와 콘텐츠 생산 흐름을 안정화하는 선택지가 될 수 있다.
• 초기 투자 포인트는 여러 직원을 한꺼번에 만드는 것이 아니라, 디폴트 직원 하나의 설정 문서와 운영 규칙을 잘 정리한 뒤 이를 기반으로 두 번째, 세 번째 직원을 확장하는 데 있다.
• Slack 채널, 봇 권한, 멘션 규칙, Cron 자동화 같은 운영 인프라를 제대로 설계해야 AI 직원 팀이 단순 챗봇 묶음이 아니라 추적 가능한 업무 시스템으로 작동할 수 있다.
• 검증 필요: 영상에서는 AI 직원 팀 구조의 운영 방식과 데모 흐름은 설명되지만, 실제 생산성 향상 폭, 비용 절감 규모, 장기 운영 안정성 같은 정량 성과는 transcript 안에서 단정적으로 제시되지 않습니다.
• 검증 필요: Docker, Slack, Telegram, gateway 설정은 환경별로 달라질 수 있으므로, 실제 도입 전에는 각자의 설치 환경에서 재시작, 자동 복구, 봇 간 멘션, 채널 권한이 정상 동작하는지 별도 확인이 필요하다.

⚠️ 불확실하거나 확인이 필요한 부분

• 추가 직원 프로필이 profiles 폴더 아래 분리되고 soul.md, skills, chrome, memories, memory.md, user.md 구조를 가진다고 설명되지만, 실제 설치 환경의 경로와 파일명은 직접 확인이 필요하다.
• 디폴트 직원을 기반으로 생성된 설정에 기존 봇 정보나 기본 직원 값이 남아 있을 수 있다고 언급되지만, 어떤 항목이 실제로 남는지는 config 파일과 env 파일을 점검해야 한다.
• Telegram에서 게이트웨이 설정을 처리하면 Docker 버전에서 불안정할 수 있다고 설명되지만, 모든 Docker 환경에서 동일하게 발생하는지는 검증이 필요하다.
• 자막 기반 정리: 타임스탬프가 있는 자막을 기준으로 정리했으며, 고유명사·수치·인용은 원문 확인 필요 시 별도 검증한다.
• 영상 속 주장: 발표자의 해석·전망·비교는 확인된 외부 사실이 아니라 영상 속 주장으로 분리해 읽는다.
• 검증 필요: 수치, 기업 실적, 정책·시장 전망은 발행 전 최신 자료로 별도 검증이 필요하다.

✅ 액션 아이템

• 기본 직원의 soul.md, user.md, agents.md, memory.md 구성을 먼저 정리하고 재사용 가능한 공통 항목과 직무별로 바꿀 항목을 분리한다.
• 리서치 담당, 콘텐츠 담당, 총괄 담당처럼 직원별 역할을 나눈 뒤 각 프로필의 정체성, 미션, 운영 원칙, 보고 방식을 작성한다.
• 신규 직원별 Telegram 봇 정보, Slack 봇 정보, allowed users, 홈 채널, free response 채널 설정을 실제 config와 env 파일에서 확인한다.
• Docker 환경이라면 설정 변경 후 에이전트를 재시작하고, 각 직원이 정상 응답하는지 개별 테스트를 진행한다.

❓ 열린 질문

• 우리 업무에서는 자비스, 뉴턴, 해밍웨이처럼 총괄·리서치·콘텐츠 3개 역할이면 충분한가, 아니면 검수·디자인·배포 담당을 별도 프로필로 나눌 필요가 있는가?
• 직원 간 협업 기록은 CLI 결과 문서 중심으로 관리하는 편이 나은가, 아니면 Slack 채널 대화 이력을 주된 운영 로그로 삼는 편이 나은가?
• 봇끼리 대화할 때 최대 핸드오프 횟수는 5회가 적절한가, 아니면 업무 유형별로 더 짧거나 긴 제한을 둬야 하는가?