Tonbi''s AI Garage LIVE (8/7): Test Stream

🖼️ 인포그래픽

🖼️ 4컷 인포그래픽

💡 한 줄 결론

Tonbi의 AI Garage 첫 시험 라이브는 Hermes Agent의 실제 작업을 공개하며 로컬·원격 실행, 권한과 격리, 프로필 설계, 목적별 AI 도구 선택을 실시간 질의응답으로 검증한 방송이다.

📌 핵심 요점

1. 첫 시험 방송은 음성·화면·채팅을 점검하는 데서 출발했지만, Hermes Agent 작업과 시청자 질문을 병행하면서 비개발자의 시행착오와 판단 기준을 공유하는 상호작용형 콘텐츠의 가능성을 확인했다.
2. Hermes 데스크톱 앱, Windows PC, DGX Spark, SSH, Docker를 오가는 구성은 로컬·원격 작업의 유연성을 높인다. 다만 에이전트에 넓은 권한을 줄수록 민감 데이터를 분리하거나 Docker로 격리하는 별도의 위험 관리가 필요하다.
3. 에이전트 운영의 핵심은 프로필을 원하는 결과별로 좁게 나누고, 위임 경로를 단순하게 설계하며, 장기 프로젝트와 불필요한 스킬을 격리해 역할 및 라우팅 드리프트를 줄이는 데 있다.
4. MiniMax H3와 DeepSeek V4 Flash 같은 로컬 모델은 영상 생성이나 가벼운 대화처럼 적합한 용도에서 의미가 있었다. 반면 클립·참조 이미지의 일관성, 메모리 요구량, 고강도 코딩 성능은 여전히 모델 선택을 제한하는 조건이다.
5. Hermes, Claude Code, Codex, Grok Build, Herder, Buzz는 서로 대체재라기보다 목적별 도구에 가깝다. 장기 스킬·메모리·자동화에는 Hermes가, 구체적인 코딩이나 시각적 완성도가 중요한 단일 작업에는 Claude Code나 Codex가 더 적합할 수 있으며, Buzz는 아직 안정성이 부족하다.

🧩 배경과 문제 정의

• 첫 라이브 스트림이라 OBS 녹화와 다른 송출 환경에서 음성·화면·채팅이 안정적으로 작동하는지 먼저 확인해야 한다.
• Hermes Agent로 실제 작업을 이어가면서 시청자 질문을 즉시 받는 형식은 기존 튜토리얼보다 비개발자의 시행착오와 판단 기준을 자연스럽게 공유할 수 있다.
• 로컬 PC·DGX Spark·Docker·데스크톱 앱을 넘나드는 실행 방식은 작업 편의성뿐 아니라 에이전트 권한, 민감 데이터 보호, 모델별 자원 요구량과 직결된다.

🕒 시간순 섹션별 상세정리

1. 첫 라이브 스트림의 기술 점검과 상호작용 목표

• 첫 라이브 송출이라 설정과 진행 방식이 아직 익숙하지 않고, 정상적으로 작동하는지 확인하는 과정부터 필요하다. [01:19]
• 음성 전달 여부와 채팅 표시 상태를 점검해 시청자와 실시간으로 소통할 기본 환경을 확보한다. [02:49]

2. 병행 작업과 비개발자 관점의 강점

• 채팅에 답하는 동안 프롬프팅을 계속하며 Grok Build의 게임과 Hermes 데스크톱 앱의 플러그인 시스템을 함께 다룬다. [04:57]
• 약 10년 동안 일본어·영어 번역가로 일했고 AI 분야에 본격적으로 들어온 시점은 최근 1년 정도라서 전통적인 개발자 경력과는 거리가 있다. [05:30]

3. 데스크톱 앱과 Spark를 오가는 작업 환경

• Hermes 데스크톱 앱은 로컬 인스턴스에서 DGX Spark 환경으로 빠르게 전환할 수 있어 여러 실행 환경을 오가는 작업이 매끄럽다. [06:40]
• 현재 기본 장비는 Windows가 설치된 Alienware PC이며, Spark는 별도의 GPU 기반 원격 작업 환경으로 활용한다. [07:36]

4. Kanban 작업 기록과 저장소 연결 방식

• Kanban 작업은 개별 Hermes Agent의 스크래치 워크스페이스에서 진행되며, 여러 실행 사례와 산출물을 한곳에서 확인할 수 있다. [09:17]
• GitHub 저장소를 연결해 업데이트를 푸시할 수 있지만 자동 반영되지는 않으며, 로컬 백엔드에서는 카드와 작업 기록을 로컬에 남긴다. [09:38]

5. 에이전트 권한과 Docker 격리의 절충

• Hermes를 Docker 샌드박스 안에서 실행하지 않는 대신 민감한 자료를 현재 PC에 두지 않아, 에이전트에 넓은 권한을 주면서도 핵심 데이터의 위험을 줄인다. [10:10]
• 민감한 파일이 많은 장비에는 Docker 격리가 적합하지만, 현재 환경에서는 에이전트의 자유로운 제어를 우선하고 Docker를 주로 개발 도구로만 사용한다. [10:43]

6. 로컬·원격 Hermes 운용과 코딩 에이전트 기능

• 배치 파일을 사용하면 데스크톱 앱의 로컬·원격 인스턴스를 동시에 실행할 수 있고, Spark에 SSH로 접속하는 구성에도 활용할 수 있다. [11:02]
• Spark의 Hermes Agent는 로컬 PC와 분리된 작업 공간을 제공하며, 이 환경에서는 영상 생성 작업을 집중적으로 수행한다. [11:51]

7. 브레인스토밍부터 에이전트 인계까지의 흐름

• 새 프로젝트는 여러 Telegram Agent를 활용한 브레인스토밍으로 시작하며, Scampi가 주요 진입점 역할을 맡는다. [13:23]
• Shrimp Brainstorming에서 아이디어를 구체화한 뒤 인계 파일을 만들어 Claude 또는 Soul을 사용하는 Hermes Agent에 전달한다. [13:46]

8. MiniMax H3로 제작하는 로컬 어린이 영상

• MiniMax H3를 Spark에서 로컬로 실행해 공룡을 좋아하는 세 살 아들을 위한 프로그램을 만들고, 매일 몇 분씩 영상을 추가한다. [15:28]
• 약 15초 단위의 클립 사이에서 일관성을 유지하기 어렵지만, 이전 클립의 마지막 프레임을 다음 클립의 첫 프레임으로 연결하면 전환 품질이 좋아진다. [16:13]

9. Mac·Docker 환경의 세션 복구 오류

• Mac의 Docker 컨테이너에서 원격 게이트웨이에 연결할 때 상태 데이터베이스가 손상됐다는 오류가 발생하고, 데스크톱 앱에서 기존 세션을 재개하지 못하는 사례가 있다. [17:32]
• Mac과 Docker를 같은 방식으로 사용한 경험이 없어 즉시 원인을 확정하기 어렵고, 활발한 Nous Research Discord에서 추가 지원을 받을 수 있다. [18:11]

10. H3 로컬 파이프라인 최적화와 일관성 문제

• Spark의 Telegram Agent에서 H3를 완전히 로컬로 실행하며, 공식 ComfyUI 구성을 최적화한 뒤 어린이 영상 제작 흐름이 비교적 안정됐다. [19:02]
• 입력 이미지 생성에 사용하는 Crayta 2는 기본 품질은 좋지만 참조 이미지와 장면 사이의 일관성을 유지하는 데 문제가 남는다. [19:14]

11. 결과 중심 프로필과 위임 경로로 드리프트 억제

• 프로필은 원하는 결과를 기준으로 나누며, 리서치·지식베이스처럼 목적별 역할에 맞춰 커스텀 스킬이나 특정 모델을 배정한다. [20:11]
• 한 프로필이 두 에이전트에 작업을 위임하는 구조를 미리 도식화하고, Kanban에서 최대한 단순한 이동 경로를 유지한다. [20:40]

12. 단일 DGX Spark에서의 DeepSeek V4 Flash

• 두 번째 Spark용 Telegram Agent인 Hibana를 통해 DeepSeek V4 Flash 계열 로컬 모델을 설정하고 단일 DGX Spark에서 실행한 경험이 있다. [21:34]
• 일반 대화에서는 응답 속도가 빠르지만 고강도 코딩 작업에는 적합하지 않아, 가벼운 채팅 중심으로 용도를 제한하는 편이 낫다. [21:55]

13. 차세대 프런티어 모델의 경쟁 전망

• GPT-4 Astra의 출시가 임박했다는 소식 뒤에 지연 정황도 나왔으며, 원인이 정부 규제일 수 있다는 판단은 확인되지 않은 추정이다. [23:40]
• DeepSeek V4 Flash가 어려운 과제에서 K3 수준이자 Fable 5보다 약간 낮은 성능을 보였다는 경험을 근거로, 후속 V4 Pro가 Fable 5를 넘어설 가능성을 예상한다. [24:44]

14. Buzz의 미성숙한 안정성과 적합한 사용 범위

• Buzz는 아직 버그가 많고 성숙도가 부족해 공개 출시를 조금 더 늦췄어야 할 정도로 초기 설정과 사용 과정이 불안정하다. [25:42]
• 설정을 끝낸 것처럼 보여도 다시 비정상적으로 작동하며, 별도 스킬을 만들어 보완해도 문제가 남아 지속적인 업데이트 관찰이 필요하다. [26:43]

15. 로컬 모델 자원과 플랫폼 연동의 남은 과제

• H3 실행을 위한 보수적인 메모리 계획치는 약 40~45GB이며, 100GB 이상 메모리를 갖춘 Mac에서는 비교적 여유롭게 운용할 수 있다. [28:55]
• Windows 데스크톱 설치는 WSL의 Hermes와 별도 인스턴스를 만들고, 기존 WSL 환경을 데스크톱 앱에 연결하는 방법은 아직 알 수 없다. [29:22]

16. Buzz·MOA와 Cloudflare OS의 구조 차이

• Buzz는 MOA 자체라기보다 여러 에이전트를 한 공간에서 다루는 Slack형 앱에 가깝고, MOA는 여러 모델을 포함한 단일 에이전트 구조에 가깝다. [30:31]
• Cloudflare OS는 전통적인 운영체제보다 오픈소스 AI 생산성 플랫폼에 가깝고, 에이전트에게 요청해 샌드박스형 개인 앱을 만든 뒤 플랫폼 안에서 공유할 수 있다. [31:10]

17. 직접 만들며 익히는 시스템 아키텍처

• 비전통 개발자에게는 교재나 튜토리얼을 순서대로 공부하기보다 관심 있는 결과물을 직접 만드는 방식이 더 실용적이다. [31:48]
• 구현 실패와 수정 과정을 반복하면 구성 요소의 연결 방식과 시스템 아키텍처를 자연스럽게 익힐 수 있으며, 실제 경험이 학습의 핵심 자원이 된다. [32:16]

18. Hermes와 Claude Code의 역할 분담

• Claude Code는 Fable을 비롯한 구체적인 코딩 프로젝트에 적합하고, Hermes는 Telegram에서 쉽게 접근하며 동작 방식을 세밀하게 조정할 수 있다. [33:14]
• Hermes는 사용자가 에이전트와 스킬을 직접 소유하므로 폐쇄형 공급자나 정책 변화에 대한 종속 위험을 낮추고, 필요에 따라 여러 모델을 선택할 수 있다. [33:28]

19. 분산 에이전트 연결과 하네스 선택

• WSL에서 VPS로 연결할 때는 원격 게이트웨이가 필요할 가능성이 크지만, 같은 머신 안에서의 구성은 추가 확인이 필요하다. [34:53]
• 로컬 delegator가 원격 VPS 팀을 안정적으로 다루려면 해당 팀에 맞춘 전용 프로필과 스킬·도구가 필요하며, 그렇지 않으면 라우팅 드리프트가 생길 수 있다. [35:58]

20. 빠른 도구 변화가 만든 미완성과 AGI 불확실성

• 작업 폴더에는 여러 프로젝트가 쌓여 있지만 실제 공개까지 끝낸 것은 일부이며, 새 도구와 모델을 계속 시험하면서 기존 프로젝트의 마무리가 밀린다. [38:45]
• AGI의 정의가 사람마다 달라 현재 도달 여부를 판단하기 어렵고, 내년 전후라는 전망도 불확실한 추정에 가깝다. [39:19]

21. Herder를 중심으로 한 터미널 운영

• Herder 안에서 일반 PowerShell을 사용하며, 멀티플렉서가 터미널 세션을 유지하므로 창을 닫았다가 다시 열어도 작업 상태를 이어갈 수 있다. [40:09]
• 여러 에이전트를 한 화면에서 깔끔하게 조율하고 세션을 복원할 수 있어 Warp를 대체했으며, 최근 Y Combinator 합류도 제품 성장의 긍정적 신호다. [40:44]

22. 스킬·프로필·컨텍스트 위생

• Hermes 대시보드의 스킬 화면에서 필요 없는 번들 스킬을 비활성화할 수 있으며, 사용하지 않는 스킬이 차지하는 컨텍스트 자체는 크지 않다. [41:57]
• 스킬 큐레이터로 커스텀 스킬을 주기적으로 점검하고, 장기 프로젝트를 별도 프로필에 격리하면 종료된 프로젝트의 스킬이 기본 에이전트를 오염시키는 문제를 줄일 수 있다. [42:36]

23. 라이브 스트림의 운영 목적

• 익숙하지 않은 방송 소프트웨어도 약 5분 만에 설정했고, 시험 방송이 안정적으로 진행되면서 공개 방송과 멤버 전용 방송을 간헐적으로 병행할 가능성이 생겼다. [44:09]
• 약 한 시간 분량의 짧은 라이브에서 시청자 질문을 수집하면 반복되는 문제를 발견하고, 이를 별도의 집중 영상 주제로 발전시킬 수 있다. [44:52]

24. 픽셀 게임과 로컬 모델 결제 연구

• Wayfarer 관련 영상에서 다룬 Token Burn 게임을 Grok Build로 제작하며, 픽셀 스타일을 목표로 게임 구조보다 아트 자산부터 구축한다. [45:00]
• 평소 아트 자산에는 Codex를 사용하지만 이번에는 Grok의 결과물과 게임 제작 능력을 직접 시험한다. [45:27]

25. 내장 메모리와 설정 자동화

• 별도 LLM이 필요한 G Brain 계열도 시험했지만 뚜렷한 필요성을 찾지 못해, 현재는 Hermes 내장 메모리를 주로 사용한다. [47:27]
• 현재 사용하는 설정을 Claude·Kimi가 마크다운으로 정리하고 다시 실제 설정 파일로 변환하게 하면, 복잡한 설정 문법을 직접 관리하지 않고도 재현 가능한 구성을 만들 수 있다. [48:26]

26. 픽셀 아트 탐색과 게임 규칙 구체화

• 초기 실루엣은 크기가 작고 형태가 단순해 원하는 고품질 픽셀 아트와 거리가 있었으며, 더 높은 해상도와 세부 묘사가 필요했다. [49:40]
• 개선된 결과물은 후기 Mega Man 계열과 비슷한 스타일에 가까워졌고, 색상 일부를 제외하면 게임의 시각적 방향으로 사용할 만한 품질에 도달했다. [51:26]

27. 시간이 필요한 메모리와 게임 품질 검증

• Cloudflare Workers와 R2를 활용한 장기 메모리도 후보지만, 메모리 시스템은 충분한 사용 시간이 지나야 유지력과 정확도를 판단할 수 있어 단기 비교가 어렵다. [52:44]
• 초기 OpenClaw 메모리의 심각한 오류가 에이전트 사용자들에게 불신을 남겼지만, 최근 시스템들의 품질은 크게 좋아졌고 Hermes 기본 메모리도 실사용에 충분하다. [53:26]

28. Grok 이미지 생성과 애니메이션 자산

• 픽셀 스프라이트는 코드만으로 만든 결과물이 아니라 프롬프트를 받은 Grok 이미지 생성 기능의 출력이며, AI 이미지 생성이 아트 제작 흐름에 직접 들어간다. [55:39]
• 배경 설정과 로봇형 에이전트 캐릭터의 품질이 목표에 가까워지면서, 정지 이미지 다음 단계로 애니메이션 시트 제작을 이어간다. [56:35]

29. 외부 메모리와 Graphify 탐색

• Hindsight는 Hermes와 쉽게 연결할 수 있는 인기 메모리 후보지만, 기본 메모리보다 실제로 더 많은 정보를 안정적으로 유지하는지가 핵심 비교 기준이다. [57:04]
• Graphify는 오픈소스 버전이 공개된 것으로 추정되지만 아직 직접 사용하지 않았으며, 에이전트 활용 가능성을 확인할 후속 조사 대상으로 남아 있다. [57:33]

30. 차기 모델 검증과 도구 재평가

• Qwen Max 계열과 로컬 27B 모델이 준비되면 동일한 고난도 작업을 여러 시간 연속 실행해, 대형 원격 모델과 소형 로컬 모델의 성능을 정면 비교할 계획이다. [58:19]
• Buzz는 Block이 만든 에이전트 협업 개념으로 초기 관심을 끌었지만, 현재 구현은 버그가 많고 사용성이 낮아 본격적인 도구로 채택하기에는 이르다. [58:50]

31. 애니메이션 점검과 목적별 AI 도구 선택

• 캐릭터가 달리고 점프하는 애니메이션이 정상 작동하며, 결과물의 완성도도 준수하다. [1:00:12]
• 스킬이 없는 프런티어 모델과 요청에 맞춰 스킬을 만드는 하위 모델을 비교하려면, 스킬을 모두 제거한 빈 Hermes 에이전트와 API로 실험 조건을 격리해야 한다. [1:00:38]

32. 시험 방송 평가와 후속 콘텐츠 계획

• 약 한 시간의 시험 방송은 초반 5분간 기술적 문제가 있었지만 이를 해결해 전반적으로 무리 없이 마쳤고, 뒤늦게 참여한 사람도 녹화본을 다시 볼 수 있다. [1:01:36]
• 이후 라이브는 일부를 소규모 대화를 위한 멤버 전용으로 운영하고 나머지는 전체 공개로 진행하며, 조사 중인 Cloudflare OS 주제는 다음 주 영상 후보로 잡는다. [1:02:09]

🧾 결론

• 시험 방송은 초반 기술 문제를 해결한 뒤 약 한 시간 동안 안정적으로 진행됐으며, 공개·멤버 전용 라이브와 후속 집중 영상으로 확장할 근거를 만들었다.
• 지속 가능한 에이전트 시스템의 품질은 최신 모델 하나보다 프로필 책임, 위임 경로, 컨텍스트 위생, 스킬 축적 방식에 더 크게 좌우된다.
• 로컬 실행과 Docker 격리 여부에는 하나의 정답이 없다. 데이터 민감도, 필요한 권한, 하드웨어 자원, 작업 목적을 함께 고려해야 한다.
• 비전통 개발자에게는 완성하고 싶은 결과물을 직접 만들고 실패를 수정하는 과정이 시스템 구성 요소와 아키텍처를 익히는 실용적인 학습법이 될 수 있다.

📈 투자·시사 포인트

• AI 에이전트 제품의 차별화 축은 단일 모델 성능에서 사용자가 소유하는 스킬·프로필·메모리·자동화와 여러 모델을 선택할 수 있는 운영 계층으로 이동할 가능성이 있다.
• DGX Spark 같은 로컬 추론 장비와 MPP 기반 유료 엔드포인트의 결합은 개인 GPU 자원을 외부 서비스로 전환할 가능성을 보여주지만, 메모리 요구량과 실제 수익성 검증이 선행돼야 한다.
• Buzz 같은 협업형 에이전트 제품은 팀·커뮤니티 시장에서 잠재력이 있지만, 반복되는 설정 오류와 낮은 안정성은 초기 채택을 지연시키는 핵심 위험이다.
• 모델과 도구가 빠르게 교체되는 환경에서는 범용 승자 하나보다 코딩, 영상 생성, 디자인, 대화, 터미널 조율 등 작업별로 최적화된 도구 포트폴리오가 현실적인 운영 전략이 될 수 있다.

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

• Mac의 Docker 컨테이너에서 발생한 상태 데이터베이스 손상과 세션 복구 실패는 동일 환경에서 재현되지 않아 원인이 확정되지 않았다.
• GPT-4 Astra와 Grok 4.6의 출시 시점, 정부 규제로 인한 지연 가능성, 후속 DeepSeek V4 Pro의 성능은 소문·추정 또는 제한된 사용 경험에 기반한다.
• DeepSeek V4 Flash, Grok, Fable 계열에 대한 성능 평가는 통제된 공통 벤치마크가 아니라 개인적인 작업 경험이므로 일반화하기 어렵다.
• 자막 기반 정리: 타임스탬프가 있는 자막을 기준으로 정리했으며, 고유명사·수치·인용은 원문 확인 필요 시 별도 검증한다.
• 영상 속 주장: 발표자의 해석·전망·비교는 확인된 외부 사실이 아니라 영상 속 주장으로 분리해 읽는다.
• 검증 필요: 수치, 기업 실적, 정책·시장 전망은 발행 전 최신 자료로 별도 검증이 필요하다.

✅ 액션 아이템

• 다음 라이브 전에 음성, 화면, 채팅, 녹화본, 세션 복구를 포함한 사전 점검 체크리스트를 만들고 초반 5분의 기술 문제를 재현한다.
• 각 Hermes 프로필의 기대 결과, 허용 도구, 전용 모델, 위임 대상과 종료 조건을 한 장의 단순한 경로도로 정리한다.
• 장비별 민감 데이터와 필요한 에이전트 권한을 분류한 뒤 Docker 격리, 데이터 분리, 자유로운 로컬 제어 중 적합한 방식을 선택한다.
• 프런티어 모델과 로컬 모델에 동일한 고난도 작업을 장시간 실행해 속도, 품질, 토큰 소비, 실패율을 비교한다.

❓ 열린 질문

• Hermes 기본 메모리는 장기간 사용했을 때 Hindsight나 Graphify보다 더 많은 정보를 정확하게 유지할 수 있는가?
• 외부 모델을 전용 하네스에서 실행할 때 발생하는 토큰 증가와 성능 저하는 모델의 네이티브 환경 대비 어느 정도인가?
• MPP 기반 유료 엔드포인트는 개인 로컬 모델의 비용, 가동률, 보안 위험을 감당하면서 지속 가능한 서비스가 될 수 있는가?