YouTubeTonbi''s AI Garage·2026년 8월 20일·0

Guide to Hermes Desktop Bot Mode: Real Multi-Agent Teams, Real Work

Quick Summary

Hermes Desktop Bot Mode는 독립 프로필을 역할·모델·스킬이 분리된 실제 다중 에이전트 팀으로 묶어 복합 작업을 병렬 실행하고 플레이 가능한 결과물까지 만드는 작업 방식이다.

영상 보기

클릭 전까지는 가벼운 미리보기만 먼저 불러옵니다.

원본 열기

🖼️ 인포그래픽

Guide to Hermes Desktop Bot Mode: Real Multi-Agent Teams, Real Work 내용을 설명하는 본문 이미지

🖼️ 4컷 인포그래픽

Guide to Hermes Desktop Bot Mode: Real Multi-Agent Teams, Real Work의 핵심 내용을 4단계로 요약한 인포그래픽
Guide to Hermes Desktop Bot Mode: Real Multi-Agent Teams, Real Work 핵심 내용을 4단계로 압축한 4컷 인포그래픽

💡 한 줄 결론

Hermes Desktop Bot Mode는 독립 프로필을 역할·모델·스킬이 분리된 실제 다중 에이전트 팀으로 묶어 복합 작업을 병렬 실행하고 플레이 가능한 결과물까지 만드는 작업 방식이다.

📌 핵심 요점

  1. Bot Mode는 기존 Hermes 프로필을 그대로 활용하면서 프로필 간 통신, 그룹 협업, 봇별 세션 관리 기능을 제공해 독립 에이전트를 하나의 프로젝트 팀으로 전환한다.
  2. 각 봇은 기본 모델·soul.md·스킬·도구·MCP를 역할에 맞게 구성할 수 있고, Agent Inbox를 통해 다른 봇에 작업을 요청하고 결과를 회수한다.
  3. Bot HR은 프로젝트 요구사항을 분석해 필요한 전문 봇과 역할을 정하고, 구현량·창의성·검증 요구에 맞는 모델을 배정해 격리된 프로필과 공유 작업 디렉터리를 구성한다.
  4. 전문 봇들은 코딩 전에 단계·역할·의존성을 합의하고 산출물 계약과 체크포인트를 공유하며, Boss Bot은 시작 지점 배정과 진행 상황 확인, 차단 요소 해소를 담당한다.
  5. 게임플레이 구현과 QA 테스트를 병렬로 수행한 팀은 실제로 조작 가능한 자동차 경주 데모를 완성했지만, 초기 제품인 Bot Mode의 운영 방식·오류 대응·작업 가시성은 더 다듬어야 한다.

🧩 배경과 문제 정의

  • Hermes Agent Desktop의 Bot Mode는 독립적으로 사용하던 프로필들을 서로 통신하고 협업하는 다중 에이전트 팀으로 전환한다.
  • 단일 에이전트가 모든 작업을 맡는 대신 오케스트레이터와 분야별 전문가가 역할을 나누면 복합 프로젝트를 병렬로 진행할 수 있다.
  • 전문 봇은 프로젝트 경험을 스킬로 축적해 다른 작업에도 재사용할 수 있지만, Bot Mode가 출시 초기 단계라 운영 방식과 오류 대응은 더 다듬어야 한다.

🕒 시간순 섹션별 상세정리

1. 다섯 에이전트가 만든 자동차 게임

  • 기초 자동차 게임은 단일 Hermes 세션이 아니라 Bot Mode에서 협업한 다섯 에이전트가 처음부터 만들었으며, 한 명은 조율을 맡고 네 명은 서로 다른 개발 영역을 담당했다. [00:18]
  • 기존 프로필도 Bot 탭에서 바로 사용할 수 있고, 이번 업데이트의 핵심 변화는 프로필 간 통신과 협업 방식 및 관리 인터페이스에 있다. [01:24]

2. Bot Mode의 기본 인터페이스

  • Desktop 앱 상단의 Sessions 탭에서 Bots 탭으로 이동하면 봇별 세션이 나타나며, 각 봇을 일반 세션처럼 직접 대화에 사용할 수 있다. [02:35]
  • 봇을 우클릭하면 해당 봇의 전체 세션을 확인할 수 있고, 이름 검색으로 필요한 세션을 필터링할 수 있다. [02:53]

3. 봇 프로필 설정과 에이전트 간 통신

  • 새 봇은 다른 프로필의 설정을 복제하거나 번들 스킬만으로 시작할 수 있으며, 기본 모델·soul.md·스킬·도구·MCP를 역할에 맞게 구성할 수 있다. [04:21]
  • 한 봇이 다른 봇에게 자기소개를 요청하고 응답을 다시 전달받는 방식으로, 프로필 간 작업 요청과 결과 회수가 가능하다. [05:20]

4. 그룹 협업과 Bot HR의 필요성

  • 봇은 상단 고정·숨김·프로필 수정·새 채팅 생성이 가능하고, 여러 봇을 하나의 그룹에 넣으면 프로젝트 팀 단위로 협업시킬 수 있다. [06:45]
  • 프로젝트마다 전문 봇을 여러 개 수동 생성하는 부담을 줄이기 위해, 요구사항을 분석해 필요한 봇과 각자의 역할을 정하는 Bot HR이 필요해진다. [08:03]

5. 게임 명세를 전문 팀으로 분해

  • Bot HR은 레이싱 게임 명세와 사용 가능한 모델 목록을 입력받고, 역할에 적합한 모델까지 선택해 프로젝트용 에이전트를 만들도록 요청받았다. [09:24]
  • 명세는 렌더링·게임플레이·테크니컬 아트·독립 브라우저 QA로 분해됐고, 네 개의 격리된 프로필에는 공유 작업 디렉터리와 역할별 soul.md가 설정됐다. [09:40]

6. 책임 범위와 모델 배정

  • 게임플레이 봇은 차량 물리·충돌 반응·AI 차량군·레이스 상태를 책임지고, 자신의 업무뿐 아니라 함께 일할 팀원과 역할 경계도 인식한다. [10:49]
  • 게임플레이·QA·테크니컬 아트·WebGL 리드에는 서로 다른 모델이 배정돼, 각 역할의 구현량과 창의성 및 검증 요구에 맞춘 혼합 모델 팀이 구성됐다. [11:20]

7. 팀 공동 계획과 작업 계약

  • 네 봇은 코딩을 시작하기 전에 명세를 함께 검토하고, 프로젝트 단계와 역할 분담을 자체적으로 합의하도록 요청받았다. [12:44]
  • 초기 단계는 여러 봇이 차단 관계 없이 병렬로 작업하도록 구성됐고, 이후 단계에는 각 결과물을 연결하는 의존성과 책임 범위가 배치됐다. [13:21]

8. Boss Bot을 통한 실행 조율

  • 작업자 네 명만으로 구성된 팀에 Boss Bot을 추가해 전체 진행 상황을 관리하고, 각 전문 봇의 작업을 조율하는 오케스트레이터 역할을 맡겼다. [14:29]
  • 모든 봇은 확정된 단계별 계획에 따라 작업을 시작하고, 완료 여부나 차단 요소 및 필요한 지원을 팀에 보고하도록 지시받았다. [15:30]

9. 병렬 개발과 진행 상황 감시

  • 팀은 자체적으로 로컬 서버를 실행했고, 게임플레이 봇은 핵심 시뮬레이션을 구현하는 동안 QA 봇은 테스트 작성을 병행했다. [15:53]
  • 개별 도구 호출이 그룹 화면에 드러나지 않아 작업 여부를 파악하기 어려웠지만, 백그라운드에서는 봇 간 협업과 파일 작업이 계속 진행됐다. [16:15]

10. 단계 추적과 분리된 대화 스레드

  • 일부 단계가 완료된 뒤 시각 요소 개발이 진행됐고, 최종 단계에는 Playwright를 이용해 실제 게임 동작을 검사하는 브라우저 테스트가 배정됐다. [17:47]
  • 사용자가 별도 지시를 내리지 않는 동안에도 전문 봇들은 서로 메시지를 주고받으며 구현 순서와 문제 해결 방식을 조정했다. [18:26]

11. 플레이 가능한 결과와 남은 과제

  • Boss Bot의 역할별 작업 내역을 바탕으로 결과물을 실행하자, 자동차를 직접 조작하고 경주할 수 있는 플레이 가능한 데모가 완성됐다. [19:38]
  • 별도 그래픽 자산이 없어 시각 품질은 기본적인 수준이지만, 주행 조작은 부드럽고 레이스 진행도 정상적으로 작동해 핵심 기능은 구현됐다. [20:18]

🧾 결론

  • Bot Mode의 핵심 변화는 단일 세션의 능력 확장이 아니라, 전문 프로필들이 통신하고 책임을 나누는 팀 단위 실행 구조에 있다.
  • 다중 에이전트의 성과를 연결하려면 명확한 역할 경계, 단계별 의존성, 산출물 계약, 공통 체크포인트와 전담 오케스트레이터가 필요하다.
  • 역할별로 축적된 스킬은 이후 프로젝트에서 재사용할 수 있어 전문 에이전트 팀의 경험을 반복 가능한 작업 자산으로 전환한다.
  • 플레이 가능한 데모는 병렬 협업의 실행 가능성을 보여주지만, 출시 초기의 버그와 운영상 불확실성까지 해결됐다는 의미는 아니다.

📈 투자·시사 포인트

  • 에이전트 제품의 경쟁 축은 개별 모델 성능뿐 아니라 프로필 통신, 역할 설계, 팀 편성, 실행 조율을 얼마나 일관되게 제공하는지로 확장될 수 있다.
  • 구현량·창의성·검증 요구에 따라 서로 다른 모델을 배정한 사례는 단일 모델 중심보다 역할 적합형 모델 조합이 중요해질 가능성을 보여준다.
  • 프로젝트 경험을 역할별 스킬로 축적하고 재사용하는 구조는 전문 에이전트의 반복 작업 효율과 조직 지식의 지속성을 높일 수 있다.
  • 실제 활용도를 평가할 때는 데모 완성 여부와 함께 진행 상황 가시성, 중단 감지, 오류 복구, 독립 QA 같은 운영 통제 기능을 확인해야 한다.

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

  • Bot Mode는 출시 초기 단계이므로 장기 실행 중 발생하는 버그, 통신 실패, 작업 중단과 오류 복구 방식이 충분히 검증됐는지는 확인되지 않았다.
  • 그룹 화면에 개별 도구 호출이 표시되지 않아 각 봇이 실제로 작업 중인지, 어디에서 멈췄는지 즉시 파악하기 어렵다.
  • 제시된 결과는 자동차 게임 한 건의 사례이므로 더 크고 의존성이 복잡한 프로젝트에서도 같은 협업 품질이 유지되는지는 추가 검증이 필요하다.
  • 자막 기반 정리: 타임스탬프가 있는 자막을 기준으로 정리했으며, 고유명사·수치·인용은 원문 확인 필요 시 별도 검증한다.
  • 영상 속 주장: 발표자의 해석·전망·비교는 확인된 외부 사실이 아니라 영상 속 주장으로 분리해 읽는다.
  • 검증 필요: 수치, 기업 실적, 정책·시장 전망은 발행 전 최신 자료로 별도 검증이 필요하다.

✅ 액션 아이템

  • 기존 프로필 복제 또는 번들 스킬을 활용해 역할별 봇을 만들고 모델·soul.md·스킬·도구·MCP 구성을 문서화한다.
  • 프로젝트 명세를 병렬 작업 단위로 분해한 뒤 역할 경계, 공유 작업 디렉터리, 의존성, 산출물 형식과 체크포인트를 사전에 합의한다.
  • Bot HR로 팀 편성과 모델 배정을 수행하고 Boss Bot에는 시작 지점 배정, 완료·차단 보고 수집, 주기적 진행 확인 임무를 부여한다.
  • 구현 봇과 분리된 QA 봇을 두고 최종 단계에서 Playwright 기반 브라우저 테스트로 실제 동작을 검증한다.

❓ 열린 질문

  • 봇이 응답하지 않거나 잘못된 파일을 수정했을 때 Boss Bot은 어떤 기준과 절차로 중단을 감지하고 작업을 복구해야 하는가?
  • 그룹 화면에서 개별 도구 호출과 진행 상태를 더 명확하게 보여주면서도 작업자별 대화 스레드를 방해하지 않는 인터페이스는 무엇인가?
  • 역할별 모델 선택을 구현량·창의성·검증 요구 외에 어떤 측정 기준으로 평가하고 조정할 수 있는가?

관련 문서

공통 태그와 주제 흐름을 기준으로 같이 보면 좋은 문서를 이어서 제안합니다.