🖼️ 인포그래픽

🖼️ 4컷 인포그래픽

💡 한 줄 결론

Hermes Kanban 기반 Multi-Agent Workflow는 LLM 위키를 더 최신이고 검증 가능한 지식베이스로 유지하기 위한 실전형 자동화 구조다.

📌 핵심 요점

1. 영상의 핵심 문제의식은 빠르게 변하는 Hermes Agent 관련 문서, 릴리스, GitHub 변경사항, 커뮤니티 자료를 수동으로 계속 정리하기 어렵다는 점이다.
2. 제안된 구조는 scout, orchestrator, researcher, ingestor, linter로 역할을 나누고, Kanban 보드를 통해 새 정보 발견부터 검증, 작성, lint, commit까지 이어지게 만든다.
3. source judgment score는 novelty, source confidence, scope fit, version relevance, clarity gain을 기준으로 삼으며, 기준점에 못 미치는 정보는 지식베이스에 반영하지 않는다.
4. 충돌 가능성이 있거나 지식 삭제가 필요한 변경은 자동 처리하지 않고, Telegram 승인 흐름과 추가 human gate를 통해 안전하게 통제한다.
5. 데모에서는 open model과 여러 worker profile을 조합해 실제 Hermes 지식베이스 업데이트를 수행했고, 중복 감지, branch 기반 작업, linter 검증, commit까지 이어지는 운영 가능한 사례를 보여준다.

🧩 배경과 문제 정의

• 기존 멀티 에이전트 칸반 예제는 에이전트 사용자 pain point 조사, 도구 제작, 영상 소재 제작처럼 특정 목적에 강하게 묶여 있어, 더 일반적으로 적용할 수 있는 사례가 필요하다.
• Hermes Agent처럼 빠르게 변화하는 도구는 공식 문서, 릴리스, GitHub 변경사항, 커뮤니티 자료가 계속 쌓이기 때문에 최신성과 정확성을 유지하는 지식베이스가 중요하다.
• LLM 위키는 에이전트가 매번 검색을 반복하는 방식보다 빠르고 정확한 답변을 만드는 데 도움이 되지만, 오래된 정보 제거, 링크·형식 검증, 중복 반영 방지, 충돌 판단을 수동으로 처리하기는 어렵다.
• 공유 Kanban 보드, 역할이 나뉜 에이전트 fleet, 인간 승인 게이트, deterministic linter, git 기반 변경 추적을 결합하면 지식베이스 업데이트를 더 안전하고 되돌릴 수 있는 workflow로 구성할 수 있다.

🕒 시간순 섹션별 상세정리

1. LLM 위키 유지관리를 위한 더 일반적인 멀티 에이전트 예제

• 이전 멀티 에이전트 칸반 예제는 에이전트 사용자의 pain point를 조사한 뒤 도구나 영상 자료를 만드는 흐름이었으며, 개인 작업에는 유용하지만 외부 사용자가 그대로 활용하기에는 목적이 다소 특정적이었다 [00:10]
• 이번 예제는 Hermes Kanban 기반 멀티 에이전트 workflow를 LLM 위키, 즉 Karpathy 스타일 지식베이스의 유지·업데이트에 적용해 더 넓은 프로젝트에 재사용할 수 있는 구조를 목표로 한다 [00:32]

2. 지식베이스가 반복 검색보다 정확하고 빠른 이유

• 여러 장기 프로젝트에서 LLM 위키의 규모가 커지고 있으며, 특정 주제를 다룰 때마다 에이전트가 정보를 새로 수집하게 하기보다 한 번 구축한 지식베이스를 주기적으로 갱신하는 방식이 더 효율적이다 [01:50]
• 잘 관리된 지식베이스는 질문에 더 상세하고 빠르게 답할 수 있게 하며, 환각이나 오래된 정보가 섞일 가능성도 줄인다 [02:11]

3. 원천 자료와 위키 구조, 그리고 유지보수 부담

• 지식베이스의 raw sources에는 Hermes Agent 공식 문서뿐 아니라 changelog, GitHub 정보, 커뮤니티 리소스, 플러그인·스킬·MCP 서버·통합 관련 자료가 함께 모인다 [02:44]
• raw folder에 모인 자료는 memory system 같은 개별 위키 페이지로 재구성되며, 세부 기능을 정확히 다뤄야 하는 콘텐츠 제작에서 작은 차이까지 확인하는 근거가 된다 [03:18]

4. 에이전트 역할과 파이프라인의 기본 흐름

• 에이전트 fleet은 knowledgebase scout, orchestrator, researcher, ingestor, linter로 나뉘며, orchestrator는 전체 pipeline을 판단하고 조율하는 중심 역할을 맡는다 [05:16]
• scout는 새 릴리스, transcript, docs를 찾고, researcher는 새 정보의 진위와 영향을 받는 페이지를 확인하며, ingestor는 wiki summary·concept·entity를 작성한다 [05:34]

5. 판단 점수, conflict 처리, 인간 승인 게이트

• linter는 정보 추가 후 형식, 링크, 섹션 구성, freshness를 점검하고 obsolete 정보를 제거할 수 있게 하며, 마지막에는 orchestrator가 private git에 commit하고 index와 log를 업데이트한다 [07:16]
• source judgment score는 novelty, source confidence, scope fit, version relevance, clarity gain을 기준으로 산정되며, 65점을 넘지 못하면 지식베이스에 추가되지 않는다 [07:49]

6. 데모 준비물과 안전한 통합 경계

• 데모는 Hermes multi-agent workflow template과 Hermes Agent knowledge base를 기반 자산으로 사용한다. 별도 지식베이스가 없다면 LLM wiki template을 출발점으로 직접 구축할 수 있다 [09:26]
• Cloud Code에서는 일부 script 작성과 변경 개요를 다루고, 실제 주요 작업은 Hermes Agent에서 진행된다. 이미 준비된 assets 위에 sub-agent와 task 정의를 추가하는 방식으로 구성된다 [09:55]

7. 지식베이스 도메인에 맞춘 template 전환

• clone template의 triage.yml은 painpoint judge 중심이 아니라 knowledgebase domain에 맞게 전환된다. source 기반 판단, worth-ingesting rubric, research lanes, ingest route map을 포함하도록 재정의된다 [12:32]
• ingest rules 역시 지식베이스 갱신 흐름에 맞게 바뀌어야 한다. 기존 painpoint 판단 구조를 그대로 쓰면 새 정보의 수집·분류 기준이 어긋난다 [12:47]

8. 충돌 판단과 linter 검증 구조

• 새 정보가 기존 페이지와 모순되는 conflict route는 사람이 판정해야 하는 핵심 예외다. 실제 contradiction인지 감지하는 품질이 workflow의 중요한 판단 기준이 된다 [13:24]
• phase one에서는 gate 2를 의도적으로 뒤로 미루고, 먼저 open-source GitHub template을 clone한 뒤 KB linter부터 만드는 단계적 접근을 택한다 [13:45]

9. Git helper, skill template, worker model route 구성

• linter가 기본 구조를 갖추고 dead link를 찾아내면, 복사된 파일 묶음을 proper Git repo로 만들기 위해 git init 단계가 필요해진다 [15:02]
• commit step을 위한 작은 KB git Python helper, triage YAML, 네 개 worker skill, template, page format spec이 이어서 만들어진다 [15:28]

10. Claude 작업물을 Hermes 실행 runbook으로 넘기는 단계

• Claude 쪽에서는 Python script와 skill 작성이 거의 마무리되고, 이후 Hermes 환경에서 실행할 나머지 setup을 위해 runbook을 작성한다 [17:00]
• runbook은 Hermes가 final setup을 수행하기 위한 실행 지침이다. profile 생성과 model route 적용까지 포함한 절차를 담는다 [17:23]

11. Hermes에서 profile과 Kanban board를 실제 생성

• Hermes workflow operations skill은 이전 workflow 설정 과정에서 만든 custom skill이다. 기존 painpoint workflow와 별도로 LLM wiki knowledgebase workflow용 새 board가 만들어진다 [19:31]
• runbook 실행 승인 후 Hermes가 필요한 항목을 생성하기 시작한다. OpenRouter API key는 chat에 직접 넘기지 않고 profile 환경 파일에 수동으로 넣는 방식이 안전하다 [19:46]

12. Scout 실행과 지식베이스 자동화 확장 구상

• workflow는 scout에서 시작되며, cron job으로 자동화할 때도 scout profile을 trigger하는 방식이 핵심 진입점이 된다 [21:39]
• board에 intake card가 생성되고 scout가 research job을 수행한 뒤, orchestrator가 업데이트를 intake하면서 며칠간 수동 갱신되지 않았던 knowledge base 변경사항을 포착하기 시작한다 [21:52]

13. 병렬 researcher 구성과 릴리스 영향 범위 탐색

• 새 패치 릴리스로 영향을 받는 페이지가 많아지자 orchestrator가 작업을 라우팅하고, 최대 여섯 개의 researcher 작업이 병렬로 확장된다 [24:02]
• researcher는 Neotron 모델로 실행되며, 기존의 Grok·GPT 5.5 중심 구성과 달리 무료 모델의 실사용 성능을 확인하는 실험이 된다 [24:31]

14. 원격 추적, 병렬 fan-out, API 안정성 리스크

• Kanban 화면을 직접 확인하지 않아도 cron으로 자동 실행된 작업 상태를 텔레그램에서 추적할 수 있고, 세 개의 Hermes Agent 릴리스 후보가 기준 점수 이상으로 통과한 상태가 확인된다 [25:38]
• researcher agent들은 fan-out 방식으로 퍼져 병렬 검증을 수행하지만, 무료 OpenRouter 모델은 timeout이나 API 오류가 발생할 수 있어 실행 안정성이 주요 리스크로 남는다 [25:56]

15. 중복 감지와 ingest 필요성 판정

• orchestrator는 Velocity 15 릴리스를 shelve 처리했지만, 지식베이스 확인 결과 이미 수동 업데이트가 완료된 상태라 추가 ingest는 필요하지 않았다 [27:23]
• 중복 감지가 작동해 불필요한 재반영을 피했고, 남은 패치 릴리스는 별도 plan change와 propose ingest 대상으로 남아 업데이트 후보가 된다 [27:57]

16. 승인 기반 ingest 계획과 소스 확장 방향

• KB plan change는 version 5 markdown 파일과 summaries 파일을 최소 편집 대상으로 지정하고, 불필요한 인덱스 변경 없이 관련 페이지만 수정하는 방향을 택한다 [28:56]
• ingest proposal은 패치 릴리스의 출처, 변경 내용, ingest 사유, 89점 점수, 영향을 받는 페이지를 함께 제시해 승인자가 변경 범위와 필요성을 판단할 수 있게 한다 [29:08]

17. 파일 쓰기, 동시 변경 회피, lint와 커밋

• ingest 이후에는 lint와 commit으로 이어지는 todo 흐름이 준비되고, lint 결과에 따른 추가 변경도 다시 proposal로 처리되는 구조가 된다 [30:39]
• M3가 페이지 작성을 시작하며, ingest는 원문 노트를 단순 복사하지 않고 내용을 읽고 요약·처리해 agent가 나중에 빠르게 접근할 수 있는 wiki 페이지로 조직한다 [31:03]

18. 지식베이스 결과 확인과 오픈 모델 성능 평가

• release 15 페이지의 patches 구간에 새 변경 내용이 반영됐고, 패치 상세와 변경 사항이 구체적으로 남아 지식베이스 갱신 결과를 확인할 수 있다 [33:35]
• OpenRouter 기준 MiniMax ingest 비용은 95센트였으며, 비용 대비 가치는 사용자 환경과 갱신 빈도에 따라 달라지는 운영 판단으로 압축된다 [34:04]

🧾 결론

• 이 영상은 LLM 위키 유지관리를 단순 문서 정리가 아니라 지속적으로 운영되는 지식 파이프라인으로 다룬다.
• 핵심은 모든 작업을 한 에이전트에게 맡기는 것이 아니라, 발견·판단·검증·작성·검사 역할을 나눠 오류와 중복을 줄이는 데 있다.
• Kanban 보드는 서로 다른 모델과 에이전트가 직접 대화하지 않아도 작업 상태와 책임을 공유하게 만드는 조정 계층으로 사용된다.
• human gate와 Git 기반 branch/commit 구조는 지식베이스 변경을 되돌릴 수 있게 만들고, 특히 삭제나 충돌 처리에서 안전장치 역할을 한다.
• 영상에서 확인된 범위 안에서는 Hermes Agent 지식베이스 업데이트가 실제로 완료됐고, MiniMax M3와 Neotron 계열 모델도 해당 workflow에서 테스트된 것으로 정리된다.

📈 투자·시사 포인트

• 장기 프로젝트에서 반복 검색 비용이 커질수록, LLM 위키 같은 유지형 지식베이스에 투자할 유인이 커진다.
• 단순 자동 수집보다 중요한 것은 “무엇을 반영하지 않을지”를 정하는 기준이며, novelty와 source confidence 같은 점수 체계가 품질 관리의 핵심이 된다.
• 지식베이스 자동화는 비용 절감만이 아니라 최신성, 추적 가능성, 변경 승인, rollback 가능성을 함께 제공해야 실무적으로 의미가 있다.
• open model을 worker 역할에 배치하는 방식은 비용을 낮출 가능성이 있지만, 영상에서도 언급된 것처럼 timeout이나 API 오류 같은 안정성 리스크를 함께 고려해야 한다.
• 검증 필요: 영상에서 GitHub 공개, 특정 모델 비용, 향후 커뮤니티 소스와 X 게시물 확장 가능성이 언급되지만, 실제 repo 상태·가격·지원 범위는 시점에 따라 별도 확인이 필요하다.

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

• Hermes multi-agent workflow GitHub와 LLM wiki GitHub가 오픈소스로 공개되어 있다고 언급되지만, 실제 저장소 URL, 최신 유지보수 상태, 설치 절차는 영상 설명란이나 GitHub에서 별도 확인이 필요하다.
• MiniMax M3 ingest 비용이 약 95센트였다는 내용은 해당 데모 실행 기준으로 보이며, 현재 OpenRouter 가격, 토큰 사용량, 모델 라우팅 설정에 따라 달라질 수 있다.
• Neotron/Nemotron 계열 모델과 MiniMax M3가 오류 없이 동작했다는 평가는 영상 속 테스트 범위에 한정된다. 장기 운영에서의 timeout, rate limit, 품질 안정성은 추가 검증이 필요하다.
• 자막 기반 정리: 타임스탬프가 있는 자막을 기준으로 정리했으며, 고유명사·수치·인용은 원문 확인 필요 시 별도 검증한다.
• 영상 속 주장: 발표자의 해석·전망·비교는 확인된 외부 사실이 아니라 영상 속 주장으로 분리해 읽는다.
• 검증 필요: 수치, 기업 실적, 정책·시장 전망은 발행 전 최신 자료로 별도 검증이 필요하다.

✅ 액션 아이템

• 영상 설명란 또는 관련 GitHub에서 Hermes multi-agent workflow template과 LLM wiki template의 실제 저장소, 라이선스, 최신 커밋 상태를 확인한다.
• 기존 pain point triage 구조를 knowledgebase domain에 맞게 바꾸기 위해 source judgment score, worth-ingesting rubric, research lanes, ingest route map을 정의한다.
• scout, orchestrator, researcher, ingestor, linter의 역할 경계를 문서화하고, 각 worker profile에 필요한 skill과 model route를 분리한다.
• KB linter가 front matter, section format, dead link, stub link, freshness, obsolete 정보 후보를 검출하는지 작은 샘플 KB에서 먼저 테스트한다.

❓ 열린 질문

• source judgment score의 65점 기준은 모든 지식베이스에 적합한가, 아니면 프로젝트별로 novelty, confidence, scope fit 가중치를 조정해야 하는가?
• 기존 페이지와 새 정보가 충돌할 때, 어떤 수준의 불일치를 conflict로 보고 인간 승인 게이트로 넘길 것인가?
• scout의 source 범위는 공식 문서와 GitHub 릴리스에만 둘 것인가, 아니면 YouTube transcript, 커뮤니티 리소스, X 게시물까지 포함할 것인가?