🖼️ 인포그래픽

🖼️ 4컷 인포그래픽

💡 한 줄 결론

Hermes Agent의 Profiles & Kanban은 여러 에이전트를 오래 지속되는 독립 작업 단위로 나누고, 재시작 이후에도 이어지는 협업 보드로 묶는 구조다.

📌 핵심 요점

1. Profile은 단순한 설정 프리셋이 아니라 config, model, memory, skills, gateway, workspace를 따로 가진 격리된 Hermes agent 상태다.
2. Sub agent는 한 세션 안에서 잠깐 쓰는 임시 helper에 가깝지만, profile은 별도 프로세스와 상태를 가진 장기 실행 agent로 다룰 수 있다.
3. 여러 profile을 동시에 실행하려면 각 profile의 gateway와 봇 토큰 충돌을 관리해야 하며, 같은 토큰을 중복 사용하면 gateway 시작 오류가 발생할 수 있다.
4. Profile은 memory와 session 같은 Hermes 상태를 분리하지만, 기본적으로 파일시스템 보안 샌드박스는 아니므로 실제 격리는 cwd 제한, Docker, SSH sandbox 같은 별도 장치가 필요하다.
5. Kanban은 작업을 triage, ready, in progress, blocked, review, done 등으로 유지하며, researcher·coder·writer 같은 profile에 durable하게 분해·배정하는 협업 계층이다.

🧩 배경과 문제 정의

• 복잡한 agentic workflow는 한 세션 안에서만 유지되는 임시 sub agent만으로는 충분하지 않으며, 독립적으로 오래 실행되는 여러 Hermes agent가 필요하다.
• profile은 단순한 설정값이 아니라 config, model, memory, skills, gateway를 각각 보유한 격리된 Hermes 상태다. 여러 agent를 동시에 실행할 때 state bleed와 데이터베이스 충돌을 막는 기반이 된다.
• profile을 사용하면 한 머신 안에서도 researcher, writer, coder처럼 역할별 agent를 분리하고, 각 agent에 서로 다른 모델·스킬·메모리·게이트웨이를 부여할 수 있다.
• 칸반 보드는 여러 profile이 재시작 이후에도 작업을 잃지 않고, durable work를 skill과 역할 기준으로 나누어 수행하도록 돕는 협업 계층이다.
• 이 모듈의 핵심 문제는 “여러 agent를 어떻게 독립적으로 실행하고, 지속 가능한 작업 단위로 협업시킬 것인가”이다.

🕒 시간순 섹션별 상세정리

1. 임시 sub agent에서 영구 profile 팀으로 확장

• Module 8의 sub agent는 한 작업 안에서 부모 agent가 자신을 임시 팀으로 나누는 방식이었고, Module 9에서는 여러 Hermes agent를 한 머신에서 더 크고 지속적인 단위로 운영하는 단계로 넘어간다 [00:22]
• 여러 Hermes agent는 각자 brain, memory, phone number를 가진 독립 단위로 동작하며, 공유 보드를 통해 협업하는 구조가 복잡한 agentic workflow의 핵심 기반이 된다 [00:37]

2. profile 하나가 갖는 격리 범위

• 팀을 실행하기 전에 먼저 팀원 하나가 무엇인지 이해해야 하며, profile은 Hermes home 아래 별도 directory에 자체 상태를 보관하는 완전한 격리 단위다 [03:08]
• profile directory에는 config, soul, memory, session, skills, cron, logs, workspace가 각각 따로 존재하며, 일반 Hermes agent의 구성요소가 profile마다 독립적으로 반복된다 [03:32]

3. 파일 구조 예시와 profile·sub agent의 차이

• Windows 기본 설치 예시에서는 users/AppData/Local/Hermes 아래에 ENV와 config 같은 default profile 파일이 직접 놓이고, profiles 폴더 안에는 별도 profile들이 저장된다 [04:41]
• X Researcher profile에는 ENV, config, soul, cron jobs, memories, plans, skills가 따로 있으며, default와 같은 구조가 특정 profile 아래에 독립적으로 복제된다 [05:10]

4. CLI로 coder profile 생성과 실행

• CLI에서는 hermes profile create coder로 새 profile을 만들 수 있고, 생성된 coder profile은 Hermes profiles directory 아래에 추가되며 bundled skills도 함께 sync된다 [07:02]
• coder setup은 해당 profile의 model 설정으로 이어지고, 설정을 마치면 coder chat으로 일반 Hermes chat이 아니라 coder profile TUI를 직접 열 수 있다 [07:26]

5. Dashboard에서 clone과 build로 profile 구성

• Hermes dashboard의 profiles 화면에서는 기존 profile 목록 확인, model 변경, soul·description 편집, skills·tools 관리, rename, active 상태 확인을 한 곳에서 처리한다 [08:31]
• 새 profile을 만들 때 clone source를 none, default, 다른 profile 중에서 선택할 수 있고, model은 inherit하거나 직접 지정하는 방식으로 설정할 수 있다 [09:10]

6. Desktop app 관리와 active profile 전환

• 데스크톱 앱은 하단에 profile 목록을 보여주며, 새 profile 생성·clone·optional soul 추가를 web app과 유사한 흐름으로 처리한다 [10:48]
• manage profiles 화면에서는 profile별 model과 skills를 확인하고, rename·delete·add 같은 관리 작업을 profile 단위로 수행할 수 있다 [11:05]

7. 프로필 전환과 삭제의 기본 운영

• 데스크톱 앱에서는 원하는 프로필을 클릭해 즉시 전환할 수 있으며, 선택된 프로필에는 테두리가 표시되어 현재 active 상태를 확인할 수 있다 [12:00]
• 터미널 없이도 기본적인 프로필 전환은 가능하지만, 터미널에서는 여러 프로필의 전환·편집·관리를 더 폭넓게 처리할 수 있다 [12:16]

8. 여러 프로필 게이트웨이와 봇 토큰 충돌

• 여러 프로필을 동시에 실행하려면 각 프로필이 자체 게이트웨이와 자체 봇 토큰을 가져야 하며, 한 머신에서 Slack 코더와 Telegram 어시스턴트를 독립적으로 운용할 수 있다 [13:21]
• X researcher 프로필은 별도 게이트웨이로 실행되며, 연결된 Telegram 봇은 자신이 X researcher 프로필이고 내부 모델로 Grok을 사용한다고 응답한다 [13:58]

9. 프로필 격리의 한계와 실제 샌드박스 조건

• 프로필은 상태를 분리하지만 컴퓨터 자체를 샌드박싱하지 않으며, gateway install 같은 지속 서비스는 프로필별 systemd·launchd 서비스로 따로 실행된다 [16:16]
• 격리 범위는 주로 메모리와 세션에 해당하며, 기본 설정만으로는 파일시스템 접근이 제한되지 않아 로컬 백엔드의 coder가 전체 디스크를 읽을 수 있다 [16:39]

10. 프로필 패키징과 에이전트 배포

• Hermes profile export coder 같은 명령은 프로필 전체를 tar.gz 스냅샷으로 만들고, import를 통해 작동 중인 설정을 다른 환경에 복원할 수 있게 한다 [17:34]
• export·import 흐름을 사용하면 한 번 설계한 에이전트의 작업 설정을 이동 가능한 형태로 보관하고, 필요한 환경에 다시 배포할 수 있다 [17:53]

11. 칸반 보드의 durable 협업 모델

• 칸반 보드는 단독 프로필 운영을 넘어 여러 프로필이 장기간 협업하도록 만드는 구조이며, 이전의 delegate task보다 durable한 협업 방식에 가깝다 [18:49]
• delegate task는 한 세션 안에서 끝나는 임시 자식 작업에 적합하고 부모가 중단되면 함께 사라지지만, 칸반 보드는 재시작 후에도 작업 상태를 유지한다 [19:02]

12. 칸반 CLI, 작업 도구, 보드 상태와 모델 할당

• CLI에서는 create, decompose, list, show, assign, dispatch 명령으로 목표 생성·분해·조회·배정·실행을 다루며, swarm에서는 worker·verifier·synthesizer 같은 역할 기반 흐름을 활용한다 [21:41]
• 작업자 에이전트는 셸에서 Hermes 칸반 명령을 직접 실행하지 않고, show, create, complete, block, comment 같은 제한된 칸반 도구로만 보드를 갱신한다 [21:56]

13. 프로필별 모델·스킬 맞춤화와 Kanban 목표 생성

• researcher, writer, coder 세 프로필을 만들고, researcher와 coder는 기본 GPT 5.5, writer는 더 저렴한 GLM 5.2를 사용하도록 나눠 역할별 비용과 성능을 조정한다 [24:01]
• 프로필마다 모델과 스킬을 따로 선택할 수 있어, 연구·작성·코딩처럼 성격이 다른 작업에 맞는 실행 환경을 구성할 수 있다 [24:24]

14. triage와 decompose를 통한 자동 역할 분해

• create 명령에 triage flag를 붙이면 작업이 triage 영역에 들어가고, auto decompose가 켜진 구성에서는 적절한 프로필에 하위 작업이 자동 배정된다 [25:16]
• 수동 decompose도 가능하며, 카드 화면에서 decompose를 누르거나 특정 프로필을 지정해 연구·코딩·작성 흐름을 직접 조정할 수 있다 [25:46]

15. 진행 중 오류·차단·사람 검토를 처리하는 운영 흐름

• ready 상태에 멈춘 카드는 nudge dispatcher로 progress로 이동시킬 수 있고, researcher 작업은 진행 상태로 바뀌며 실제 실행을 시작한다 [26:46]
• 모델 문제가 생긴 작업은 모델을 바꾼 뒤 ready로 되돌리고 다시 progress로 보내 재시작할 수 있으며, 연구 완료 후에는 coder가 작은 ML 프로토타입 제작을 이어받는다 [27:03]

16. 산출물 확인, durable Kanban, 보안 모듈로 이어지는 결론

• 세 하위 작업이 모두 완료되면, coder가 만든 Python 프로토타입 스크립트와 writer가 작성한 보고서가 각자의 Kanban 워크스페이스에 남는다 [28:35]
• Kanban은 하나의 목표를 세 프로필로 자동 분해·라우팅하고, gateway가 죽어도 보드를 유지해 재시작 뒤에도 작업을 이어갈 수 있는 durable 구조를 제공한다 [29:06]

🧾 결론

• 이 영상의 핵심은 Hermes를 단일 에이전트 도구가 아니라, 역할별 profile과 Kanban 보드로 구성된 장기 실행형 에이전트 팀으로 확장하는 방법이다.
• Profile은 create, clone, use, export/import, install 같은 흐름을 통해 생성·복제·전환·배포할 수 있으며, 같은 머신에서 여러 Hermes agent를 비교적 안전하게 병렬 운용하는 기반이 된다.
• Kanban은 단순 delegate task보다 오래 지속되는 작업 관리 방식으로, 부모 세션이 끝나도 작업 상태를 유지하고 사람이 block/unblock/comment로 중간 개입할 수 있게 만든다.
• 다만 profile은 보안 경계가 아니라 상태 격리 수단에 가깝기 때문에, 강력한 agentic workflow를 운영할수록 샌드박스와 권한 제한을 별도로 설계해야 한다.

📈 투자·시사 포인트

• Hermes Agent 관점에서 profile과 Kanban은 “여러 모델·여러 역할·여러 gateway”를 한 환경에서 운용하는 기본 운영 단위로 보이며, 단일 챗봇보다 팀형 자동화에 초점이 맞춰져 있다.
• 도입 시에는 profile별 모델 비용, gateway 토큰 관리, skills 권한, 파일 접근 범위, 재시작 후 작업 복구 가능성을 함께 평가해야 한다.
• Kanban 방식은 긴 작업을 researcher, coder, writer 같은 역할로 나누고 blocked 상태에서 사람 승인을 받을 수 있어, 완전 자동화보다 human-in-the-loop 운영에 더 적합한 구조로 해석된다.
• 검증 필요: 영상은 기능과 사용 흐름을 설명하지만, 실제 운영 안정성, 보안 수준, 비용 효율, 최신 CLI 명령 호환성은 사용 중인 Hermes 버전과 공식 문서에서 별도로 확인해야 한다.

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

• 영상에서는 profile이 config, model, memory, skills, gateway를 분리한다고 설명하지만, 실제 파일시스템 접근까지 자동으로 제한되는 것은 아니므로 보안 격리 수준은 별도로 확인해야 한다.
• CLI 명령 표기가 Hermes, hermes처럼 섞여 있어 실제 환경에서 정확한 명령 이름과 옵션은 최신 공식 문서 또는 로컬 help로 검증이 필요하다.
• Kanban 보드가 durable SQLite 파일에 저장된다고 설명되지만, 구체적인 저장 경로, 백업 방식, 마이그레이션 방식은 입력 내용만으로는 확인되지 않는다.
• 자막 기반 정리: 타임스탬프가 있는 자막을 기준으로 정리했으며, 고유명사·수치·인용은 원문 확인 필요 시 별도 검증한다.
• 영상 속 주장: 발표자의 해석·전망·비교는 확인된 외부 사실이 아니라 영상 속 주장으로 분리해 읽는다.
• 검증 필요: 수치, 기업 실적, 정책·시장 전망은 발행 전 최신 자료로 별도 검증이 필요하다.

✅ 액션 아이템

• 여러 profile을 만들기 전에 researcher, coder, writer처럼 역할별 목적·모델·스킬·gateway 필요 여부를 먼저 정의한다.
• 각 profile이 별도 config, memory, skills, workspace를 갖는지 확인하고, default profile을 삭제하거나 이름 변경 대상으로 다루지 않는다.
• 여러 gateway를 동시에 실행할 경우 profile마다 고유한 봇 토큰과 별도 서비스 구성을 사용하도록 점검한다.
• 파일 접근 제한이 필요한 profile은 profile 설정만 믿지 말고 Docker, SSH sandbox, terminal.cwd 제한 같은 별도 격리 수단을 설계한다.

❓ 열린 질문

• Kanban 보드의 SQLite 파일은 실제로 어디에 저장되며, 장기 운영 시 백업과 복구는 어떻게 관리해야 하는가?
• profile clone 시 memories, sessions, state를 복제하는 것이 좋은 경우와 config만 복제하는 것이 안전한 경우는 어떻게 구분해야 하는가?
• 다중 gateway 운영에서 Telegram 외 Slack, Discord, 기타 플랫폼의 토큰 충돌과 우선권 동작은 동일한가?