How to build a JARVIS-themed PREMIUM Hermes Mission Control dashboard

🖼️ 인포그래픽

🖼️ 4컷 인포그래픽

💡 한 줄 결론

Hermes 기반 JARVIS 테마 프리미엄 미션 컨트롤은 역할별 에이전트 라우팅, 운영 데이터 시각화, 문서 분리, 실시간 검색, 음성 인터페이스를 하나의 대시보드로 통합하는 구축 방식이다.

📌 핵심 요점

1. Jarvis를 중앙 오케스트레이터로 두고 Dev·Research·Assistant에 요청을 배분하되, 텔레그램 토픽 라우터를 이용하면 전문 에이전트와 직접 대화해 중앙 병목을 줄일 수 있다.
2. 대시보드는 에이전트별 작업량·토큰 소비·활동 기록·서버 자원·예약 작업을 시각화하고, 메시지 전송과 자동화의 실행·일시 정지·삭제까지 지원하는 운영 제어면으로 기능한다.
3. 긴 조사 보고서와 전략 문서는 채팅에서 분리해 Markdown 라이브러리에 저장함으로써 대화 문맥의 팽창과 반복적인 토큰 소비를 줄인다.
4. 최신 조사는 학습 데이터나 직접 웹 탐색에만 의존하지 않고 구조화된 검색 API를 사용하며, 에이전트별 모델·기억·작업공간·도구 권한을 분리해 정확성과 역할 경계를 강화한다.
5. 음성 처리는 Chrome·Kokoro의 로컬 조합과 ElevenLabs 기반 유료 조합 중 선택할 수 있고, 원격 접근은 SSH 터널보다 Tailscale을 활용해 편의성과 접근 통제를 함께 확보할 수 있다.

🧩 배경과 문제 정의

• 여러 AI 에이전트가 코드 개발·실시간 조사·개인 일정 관리를 분담하려면, 요청을 적절한 전문 에이전트로 전달하고 결과까지 검증하는 중앙 오케스트레이터가 필요하다.
• 터미널과 메신저만으로 여러 에이전트를 운영하면 작업량·시스템 자원·토큰 소비·자동화 일정을 한눈에 파악하기 어렵고, 긴 문서가 채팅 문맥을 불필요하게 확장한다.
• 최신 정보를 다루는 조사 에이전트는 학습 데이터만으로 답하거나 웹 차단·페이지 구조 변경에 실패할 수 있어, 구조화된 실시간 검색 계층이 필요하다.
• 음성 인터페이스와 화려한 시각 효과는 몰입도를 높이지만 비용·개인정보·응답 지연·하드웨어 부하를 동반하므로, 로컬 처리와 유료 서비스 사이의 선택지가 중요하다.

🕒 시간순 섹션별 상세정리

1. 실생활 자동화와 다중 에이전트 오케스트레이션

• Jarvis가 Home Assistant로 사무실 조명을 켜고, 이메일·날씨·일정을 종합한 아침 브리핑과 두 시간짜리 집중 업무 블록을 처리한다. [00:03]
• 중앙 에이전트인 Jarvis는 개발을 맡는 Dev, 실시간 조사를 맡는 Research, 이메일·일정을 다루는 Assistant에게 요청을 배분하고 결과의 정확성을 검증한다. [01:13]

2. 에이전트 호출과 운영 현황 대시보드

• 네 에이전트에는 개별 키보드 단축키가 배정되며, 숫자 키만으로 Dev나 Research를 즉시 호출해 음성 대화를 시작할 수 있다. [03:03]
• 홈 화면은 에이전트별 작업량 분포를 보여주며, 대시보드 개발과 테스트를 주도한 Jarvis와 Dev에 작업이 집중돼 있다. [03:47]

3. 활동 추적과 자동화 일정 제어

• 에이전트 화면에는 Jarvis의 작업 비중과 누적 토큰 사용량, 수행 작업과 실행 시각이 기록되며 다른 에이전트의 활동 기록으로 전환할 수 있다. [04:56]
• 통신 화면에서는 Telegram 같은 외부 메신저로 이동하지 않고도 모든 에이전트와 대화하고 작업을 조율한다. [05:23]

4. 장문 결과물과 채팅 문맥의 분리

• 조사 보고서·마케팅 전략 같은 장문 결과물은 에이전트별 전용 저장 공간을 거쳐 라이브러리 화면에 모인다. [06:10]
• 장문을 Telegram 채팅에 직접 넣으면 문맥 창이 커지고 AI 토큰 소비도 증가하므로, 채팅에는 작업 흐름만 남기고 결과물은 별도 문서로 분리한다. [06:24]

5. 실시간 조사 실패를 막는 검색 API 계층

• 조사 에이전트가 최신 사건을 학습 데이터에만 의존하면 수개월 전 정보로도 확신에 찬 답을 만들 수 있어, 기억이 아니라 실시간 확인이 필요하다. [06:47]
• 직접 웹을 탐색하는 방식은 CAPTCHA·접속 차단·프록시·원시 HTML·레이아웃 변경에 취약하며, 실패 후 과거 지식으로 되돌아가도 사용자가 이를 알아차리기 어렵다. [07:08]

6. 에이전트별 모델 선택과 운영 유연성

• 문서 화면에는 대시보드 템플릿과 작동 방식을 이해하는 데 필요한 사용 자료가 모이며, 복잡한 구성의 운영 지침을 한곳에서 확인할 수 있다. [08:09]
• 제어 화면에서는 Jarvis·Dev·Research·Assistant마다 서로 다른 AI 제공자와 모델을 배정할 수 있다. [08:15]

7. 세 가지 음성 처리 방식과 실제 지연 요인

• 무료 로컬 구성은 Chrome의 음성 인식으로 사용자 발화를 텍스트로 바꾸고, 에이전트의 텍스트 응답은 서버에 설치한 Kokoro가 음성으로 변환해 외부 전송 없이 처리한다. [08:44]
• 유료 구성은 Chrome 입력과 ElevenLabs 출력의 조합 또는 입력·출력을 모두 ElevenLabs에서 처리하는 조합을 제공하지만, 구독 비용과 대화 데이터의 외부 처리가 뒤따른다. [09:35]

8. 스마트홈 확장과 그래픽 부하 대응

• Home Assistant를 연결하면 Jarvis가 조명처럼 같은 홈 네트워크에 있는 장치를 직접 제어할 수 있다. [11:02]
• 움직이는 도시 배경과 인터페이스 요소, Jarvis 애니메이션은 몰입감을 높이지만 CPU·GPU가 약한 장치에서는 브라우저 자원 사용량을 크게 늘릴 수 있다. [11:13]

9. Hermes Agent를 기반으로 삼는 이유

• 구축 과정은 Hermes Agent 설치부터 시작하며, 이미 설치 경험이 있는 사용자는 이 단계를 건너뛸 수 있다. [12:57]
• Hermes Agent는 PC나 서버에 여러 에이전트를 배포하고 OpenAI·Anthropic·Grok을 포함한 다양한 모델 제공자를 역할별로 사용할 수 있다. [13:16]

10. 전용 장비와 임대형 VPS 선택

• Hermes는 전용 PC나 미니 컴퓨터에서 실행할 수 있지만, 초기 장비 투자가 어렵다면 하드웨어 사양이 정해진 24시간 온라인 VPS를 월 단위로 임대할 수 있다. [14:04]
• VPS는 인터넷 연결과 물리 장비 관리 부담을 줄이는 대신 매달 비용이 발생하며, 이 구성에서는 가격 대비 하드웨어 사양을 기준으로 Contabo를 선택한다. [14:21]

11. VPS 계약·운영체제·복구 구성

• 사용 기간이 불확실하면 월별 취소가 가능한 1개월 계약이 안전하며, 장기 계약은 단가가 낮아지는 대신 12개월 또는 24개월 동안 비용이 묶인다. [15:41]
• 기본 100GB SSD와 Ubuntu를 유지할 수 있고, 가까운 지역을 선택해 추가 비용을 내기보다 무료 EU 리전을 사용해도 이 작업에서는 지연 문제가 크지 않다. [16:08]

12. SSH 접속과 비루트 계정 보안

• 구매 완료 이메일에서 VPS의 고유 IP 주소와 사용자 이름을 확인하고, 설정 과정에서 직접 만든 비밀번호와 함께 접속 정보로 사용한다. [17:40]
• Windows PowerShell이나 macOS Terminal에서 ssh root@IP주소를 실행하고, 최초 접속 시 서버 지문을 승인한 뒤 비밀번호를 입력하면 VPS 셸에 연결된다. [18:17]

13. Hermes 설치와 초기 온보딩

• 새 사용자를 생성해 비밀번호를 설정하고 sudo 권한을 부여한 뒤 해당 계정으로 전환하면, root 권한 노출을 줄이면서 Hermes와 개발 도구를 설치할 수 있다. [20:18]
• Hermes 공식 사이트의 Linux용 한 줄 설치 명령은 필수 구성 요소를 함께 설치하며, 의존성 설치 후 빠른 설정을 선택해 Nous Research 계정과 서버를 연결한다. [22:27]

14. 텔레그램 봇 생성과 사용자 접근 제한

• 설치 화면에서 텔레그램 옵션은 엔터가 아니라 스페이스바로 선택해야 하며, 수동 설정을 선택한 뒤 공식 BotFather에서 새 봇과 봇 토큰을 생성한다. 유사 봇을 피하려면 정확한 사용자명과 이용자 규모를 함께 확인해야 한다. [25:01]
• 봇 토큰을 PowerShell에 입력한 뒤 UserInfoBot에서 얻은 텔레그램 계정 ID를 등록하면, 지정된 사용자만 봇과 대화할 수 있어 공개된 봇 사용자명을 통한 무단 접근을 막을 수 있다. [26:11]

15. 홈 채널과 상시 실행 게이트웨이 구성

• 텔레그램 봇을 홈 채널로 지정하면 헤르메스 게이트웨이의 재시작과 복구 상태가 해당 채널로 전달되어 원격 운영 상태를 확인할 수 있다. [27:10]
• 게이트웨이를 사용자 시스템 서비스와 백엔드 서비스로 설치하면 서버 업데이트나 재부팅 이후에도 자동으로 다시 실행되며, 설치 후 셸을 다시 불러오면 어느 경로에서든 hermes 명령을 사용할 수 있다. [27:24]

16. AI 모델과 과금 방식 선택

• 헤르메스는 여러 AI 모델을 지원하며, OpenAI 구독자는 별도 종량제 API 비용 없이 Codex 계열 모델을 사용할 수 있다. 월 20달러 요금제로 시작한 뒤 사용량이 부족할 때 상위 요금제로 전환하는 방식도 가능하다. [28:19]
• OpenRouter는 하나의 API 키로 다양한 모델을 쓸 수 있지만 사용량에 따라 비용이 늘고 모델별 단가도 다르다. 고정 구독은 사용 한도 내 비용 예측이 쉽고, 충분히 성능이 좋은 모델을 선택하면 작업 부담도 줄어든다. [29:03]

17. OpenAI 계정 연결과 기본 모델 지정

• hermes model에서 OpenAI의 Codex 인증 방식을 선택하면 구독 계정을 헤르메스에 연결할 URL과 인증 코드가 생성된다. 터미널에서 코드를 복사할 때 Ctrl+C를 누르면 절차가 취소되므로 Ctrl+Shift+C를 사용해야 한다. [29:49]
• 인증을 마치면 사용 가능한 모델 목록에서 기본 모델을 지정할 수 있다. 최신 상위 모델은 더 많은 토큰을 소비하므로 사용 한도가 낮다면 충분한 성능의 하위 모델을 유지하고, 여유가 있을 때 상위 모델을 선택하는 편이 효율적이다. [31:21]

18. 터미널과 텔레그램 연결 검증

• 헤르메스 터미널 인터페이스에서 간단한 메시지에 응답이 돌아오면 설치와 모델 연결이 모두 정상이다. 이 인터페이스는 텔레그램 장애 시 봇 문제를 진단하고 복구를 요청할 수 있는 백업 채널이 된다. [32:08]
• BotFather가 제공한 봇 링크에서 대화를 시작하고 메시지에 응답이 돌아오면 텔레그램 연결도 정상이다. 이후 여러 에이전트를 역할별로 구분하기 위해 개인 채팅이 아닌 토픽 기반 그룹 구조로 전환한다. [33:12]

19. 토픽 기반 텔레그램 그룹 구축

• 새 텔레그램 그룹에 봇을 추가하고 토픽 기능을 활성화하면 개발자·연구자·개인 비서가 각자의 채널에서 대화할 수 있는 멀티에이전트 공간이 만들어진다. [34:11]
• 봇을 그룹 관리자로 지정하고 권한을 검토한 뒤 기본 토픽을 자비스 채널로 변경한다. 그룹 안에서 보낸 테스트 메시지에 봇이 반응하면 관리자 권한과 그룹 연결이 정상이다. [34:44]

20. 프롬프트 기반 구축 비용과 자동 설치 대안

• 전체 환경을 직접 구축하려면 20개가 넘는 프롬프트와 상당한 AI 토큰이 필요하고, 수동 작업에는 약 6시간이 걸릴 수 있다. 자동 설치 방식은 몇 가지 정보만 입력해 동일한 백엔드를 5분 이내에 구성하는 대안이다. [35:32]
• 유료 멤버십이나 번들에는 프롬프트와 템플릿이 포함되며, 월 10달러 멤버십은 튜토리얼 자료와 비공개 텔레그램 지원 그룹까지 제공하는 구조다. [36:15]

21. 자비스의 정체성과 사용자 맥락 초기화

• 첫 설정 프롬프트에는 에이전트 이름과 최고 권한을 가진 사용자, 시간대, 근무 시간, 사용 목적을 포함한다. 자비스는 최고 책임자이자 가장 자주 대화할 기본 에이전트로 지정된다. [37:16]
• 무작위 대화를 시작하기 전에 프로젝트 목표와 역할을 먼저 저장하면 깨끗한 초기 기억 위에서 작업을 확장할 수 있다. 응답에 기억 저장 상태가 나타나고, 음성 기반 미션 컨트롤과 네 명의 에이전트라는 우선 목표도 유지된다. [38:04]

22. 실행 통제와 네 명의 에이전트 설계

• 선택적인 사용자 인터뷰는 초기 정보에서 부족한 요구사항을 보완하며 약 10~15분이 걸린다. 모든 작업 전에 계획을 제출하고 승인 후 실행하도록 설정하면 통제력은 높아지지만 상호작용과 구축 시간도 늘어난다. [38:51]
• 기본 에이전트인 자비스 아래에 개발자·연구자·개인 비서를 두고 각 역할을 먼저 브리핑한다. 복잡한 생성을 바로 지시하기보다 조직 구조와 책임을 선행 공유하면 이후 프로필 생성 기준이 명확해진다. [39:46]

23. 영구 프로필 생성과 실제 상태 검증

• 일회성 임시 에이전트와 달리 개발자·연구자·개인 비서는 정의된 역할을 계속 유지하는 영구 헤르메스 프로필로 생성된다. 각 프로필의 역할과 임무는 정체성 파일에 저장되어 장기 작업의 일관성을 지킨다. [40:45]
• hermes profile list에서 기본 프로필과 세 개의 전문 프로필, 공통 AI 모델을 확인하면 실제 생성 여부를 검증할 수 있다. 텔레그램의 제약 때문에 이 시점에는 자비스 게이트웨이만 실행되며, 하나의 봇 토큰으로 모든 에이전트를 동시에 활성화할 수 없다. [42:00]

24. 에이전트별 기억 분리와 역할 경계 설정

• 네 에이전트가 하나의 기억을 공유하면 개발 기록, 조사 자료, 일정 정보가 뒤섞이므로 프로필마다 전용 기억과 작업공간을 만든다. 역할 경계와 팀 인식을 함께 부여하면 담당 밖의 요청을 적합한 에이전트로 넘길 수 있다. [42:57]
• 경계 테스트에서 자비스는 개발 요청을 개발자에게, 개발자는 조사 요청을 연구자에게 넘긴다. 특히 금융처럼 위험도가 높은 업무에서는 비전문 에이전트가 다른 역할의 데이터나 도구를 잘못 다루는 사고를 줄일 수 있다. [44:05]

25. 단일 봇 토큰을 위한 토픽 라우터 설계

• 에이전트마다 봇 토큰과 게이트웨이를 만들면 구성이 복잡해지고 여러 게이트웨이를 동시에 운영해야 하며, 모든 메시지를 자비스가 중계하게 하면 기본 에이전트가 불필요한 병목이 된다. [45:01]
• 라우터 플러그인은 텔레그램 토픽의 고유 ID를 읽어 수신 메시지를 담당 프로필로 직접 전달하고, 응답은 원래 토픽 ID로 돌아가게 한다. 이 구조는 하나의 봇 토큰을 유지하면서도 자비스를 거치지 않는 역할별 대화를 가능하게 한다. [45:58]

26. 프로필 라우팅 설정과 게이트웨이 재시작

• 자비스는 Hermes 문서를 검색해 채팅 ID와 각 프로필의 채널 바인딩을 JSON 설정에 반영했고, 리서치·개발·어시스턴트가 서로 다른 채널을 사용하도록 구성했다. [50:05]
• 게이트웨이 내부 프로세스에서는 자체 재시작 명령이 차단되므로, PowerShell에서 재시작 명령을 직접 실행해야 설정을 적용할 수 있다. [50:44]

27. 텔레그램 채널별 프로필 검증

• 라우팅 인프라는 활성화됐지만 실제 토픽 라우팅은 아직 검증되지 않아, 각 채널에 이름과 실행 중인 프로필을 묻는 동일한 테스트를 보냈다. [52:06]
• 어시스턴트 채널은 커뮤니케이션·캘린더 전문 프로필로 응답했고, 개발·리서치·자비스 채널도 각각 자신의 역할과 일치하는 응답을 반환했다. [52:29]

28. 작업 로그 데이터베이스와 공통 기록 규칙

• 경량 SQL 기반 로그에는 에이전트 이름, 수행 작업, 사용 모델, 실행 시각, 성공·실패·진행 상태를 저장해 작업 이력과 실패 여부를 추적한다. [53:13]
• 모든 에이전트는 사용자에게 최종 응답하기 전에 작업 결과를 기록하며, 대시보드 가독성을 위해 작업 설명은 최대 140자로 제한한다. [54:18]

29. 대시보드 구축 도구와 실행 경로 선택

• 기본 인프라가 완성된 뒤 미션 컨트롤 구축은 Claude Code로 진행하지만, 같은 작업을 기존 개발 에이전트에 맡기는 대체 경로도 사용할 수 있다. [55:29]
• 에이전트·로그 데이터베이스·텔레그램·음성 설정을 수동으로 구성하면 테스트 기준 약 6시간이 걸렸고, 선택형 자동 설치기는 같은 구성을 몇 분 안에 처리한다. [56:04]

30. VPS 원격 개발 환경 연결

• Claude Code에 VPS를 SSH 호스트로 추가할 때 root가 아닌 새 사용자 계정을 사용하며, 비밀번호 또는 SSH 키 쌍으로 서버 접근 권한을 구성한다. [56:58]
• 연결 후 Claude Code 구성 요소가 서버에 설치됐고, 기존 미션 컨트롤 폴더를 작업 공간으로 선택해 서버 파일 접근을 확인했다. [57:49]

31. 서버 구조 탐색과 Claude Code 온보딩

• 새 Claude Code 세션에는 기존 환경 정보가 없으므로, 파일을 수정하기 전에 Hermes 설정·에이전트 구조·텔레그램 라우팅·로그 데이터베이스를 조사하도록 범위를 지정했다. [59:10]
• Hermes가 익숙하지 않을 경우 공식 문서 경로를 직접 읽고 현재 서버 구성과 개발 규칙을 파악하도록 온보딩 조건을 추가했다. [1:00:12]

32. 데이터 읽기 계층과 SSH 터널

• 기존 Hermes 구성과 에이전트 데이터를 다시 조사한 뒤, 그 정보를 백엔드 개발의 기준으로 삼아 중복되거나 잘못된 가정을 줄였다. [1:00:58]
• Python 서버와 여러 데이터 조회 엔드포인트로 읽기 계층을 구성해 에이전트 로그와 서버 정보를 대시보드에 연결했다. [1:02:21]

33. HTML 템플릿 업로드와 디자인 기준 고정

• 미리 제작한 HTML 템플릿을 서버로 전달하기 위해 웹 업로드 엔드포인트를 만들고, 업로드 파일명을 시스템이 기대하는 이름과 정확히 맞췄다. [1:03:29]
• 업로드한 템플릿은 프로젝트 폴더에 저장된 뒤 메인 화면을 담당하는 index.html로 복사돼 대시보드의 초기 UI가 됐다. [1:04:27]

34. 초기 화면 검증과 변경 안전장치

• 브라우저를 새로고침하자 서버가 템플릿 기반 대시보드를 정상 반환했고, 로컬 SSH 터널을 통한 화면 접근도 성공했다. [1:05:40]
• 화면 녹화 중 GPU 부하를 줄이기 위해 제어 메뉴에서 애니메이션을 일괄 비활성화했으며, 같은 옵션으로 저사양 환경의 렌더링 부담도 조절할 수 있다. [1:06:20]

35. 하드코딩 데이터를 실제 운영 데이터로 전환

• 홈·에이전트·커뮤니케이션 화면의 하드코딩 값을 실제 서버 지표와 로그로 교체하는 작업을 연속 실행했다. [1:07:03]
• 홈 화면의 최근 임무와 CPU 지표가 실제 값으로 바뀌었고, 에이전트 화면에는 작업 점유율·활동 히트맵·실시간 로그가 데이터베이스 기준으로 반영됐다. [1:07:46]

36. 예약 작업과 장문 문서 관리 구조

• 스케줄 화면은 서버의 예약 작업을 모아 보여주고, 각 작업을 수동 실행·일시정지·삭제할 수 있는 운영 제어 지점으로 설계했다. [1:09:30]
• 장문 리서치를 채팅에 붙여 넣으면 대화가 복잡해지고 매 요청마다 읽어야 하는 컨텍스트가 커져 토큰 비용이 증가하므로, 별도의 라이브러리 저장소가 필요하다. [1:10:08]

37. 라이브러리·예약 작업의 실제 동작 검증

• 라이브러리 화면에는 리서치 에이전트가 생성한 스모크 테스트 문서가 나타났지만, 스케줄 화면은 등록된 예약 작업이 없어 비어 있었다. [1:11:35]
• 매일 오전 8시에 성경 메시지를 보내는 예약 작업을 자비스에게 생성하도록 요청했고, 완료 직후 해당 작업이 스케줄 화면에 나타났다. [1:12:06]

38. 실시간 리서치 API 연동 준비

• 리서치 에이전트가 자체 학습 데이터에만 의존하지 않고 최신 정보를 조회할 수 있도록 외부 검색 API를 다음 도구로 선택했다. [1:12:50]
• 무료 플랜은 월 250회의 사용량을 제공하며, 이메일과 전화번호 인증 후 대시보드에서 비공개 API 키를 복사할 수 있다. [1:13:08]

39. 연구 에이전트에 실시간 웹 검색 연결

• 연구 에이전트 전용 웹 검색 명령이 SE API를 호출하고, 다른 에이전트는 명시적으로 권한을 확장할 때만 같은 도구를 사용할 수 있도록 접근 범위를 제한한다. [1:14:05]
• ChatGPT 업무 자동화를 주제로 한 스모크 테스트에서 상세 보고서와 신뢰 가능한 출처가 라이브러리에 저장되며, 실시간 검색 데이터 연동이 정상 작동한다. [1:14:49]

40. 음성 모드의 처리 구조와 로컬 구성

• 사용자의 음성을 텍스트로 변환해 에이전트에 보내고, 에이전트의 텍스트 응답을 다시 음성으로 합성하는 양방향 파이프라인이 기본 구조다. [1:15:33]
• 로컬 모드는 브라우저가 음성 인식을 담당하고 Kokoro가 응답 음성을 합성하므로 비용이 들지 않으며, 데이터가 서버 밖으로 나가지 않아 세 가지 구성 중 개인정보 보호 수준이 가장 높다. [1:16:10]

41. ElevenLabs 기반 모드와 실제 지연 병목

• 두 번째 모드는 브라우저 음성 인식과 ElevenLabs 음성 합성을 결합하고, 세 번째 모드는 녹음·음성 인식·음성 합성을 모두 ElevenLabs에서 처리해 브라우저 호환성과 음성 선택 폭을 넓힌다. [1:17:08]
• 체감 지연의 대부분은 음성 변환보다 Hermes 에이전트가 요청을 받아 작업하고 응답하는 과정에서 발생하므로, ElevenLabs를 사용해도 전체 대화 속도가 크게 개선되지는 않는다. [1:18:11]

42. Kokoro 서비스 설치와 ElevenLabs 키 보호

• Kokoro와 필요한 음성 파일을 서버에 설치하고 시스템 서비스로 등록해, 서버가 재부팅된 뒤에도 로컬 음성 합성 기능이 자동으로 시작되도록 구성한다. [1:19:40]
• ElevenLabs 키에는 음성 인식·합성 및 음성 조회에 필요한 권한만 부여하고, 채팅에 키를 노출하지 않은 채 터미널의 비공개 입력 명령으로 서버에 저장해 유출 위험을 줄인다. [1:20:49]

43. 제어 탭과 음성 대화 인터페이스 구현

• 제어 탭에서 에이전트별 AI 모델과 세 가지 음성 시나리오를 선택할 수 있으며, Research가 DeepSeek로 표시되는 모델 불일치는 이후 수정할 과제로 남는다. [1:22:37]
• 에이전트별 인사 음성을 미리 생성해 반복적인 음성 합성 비용을 없애고, 중앙 글로브의 푸시투토크와 우측 대화 패널을 통해 발화 내용과 응답 상태를 실시간으로 확인한다. [1:23:21]

44. 세 가지 시나리오와 에이전트 음성 응답 검증

• 제어 탭에서 시나리오 1·2·3을 선택할 때 각각의 활성화 음성이 재생돼, 세 가지 음성 구성의 전환 기능이 정상 작동한다. [1:25:15]
• Chrome이 사용자의 음성을 텍스트로 변환해 Jarvis에 전달하고, Jarvis의 텍스트와 음성 응답이 대화 패널과 스피커에서 함께 출력된다. [1:25:43]

45. 응답 지연의 재확인과 키보드 단축키

• Dev 에이전트와의 대화에서도 음성 인식보다 에이전트의 작업 처리에 더 긴 시간이 걸리며, 텍스트 채팅에도 같은 지연이 존재해 병목이 음성 계층이 아님을 확인한다. [1:26:24]
• 숫자 1~4를 Jarvis·Dev·Research·Assistant에 할당해 마우스 없이 즉시 대화를 시작하며, 브라우저가 선점하는 Ctrl·Command 조합 대신 충돌이 적은 단일 숫자 키를 사용한다. [1:27:46]

46. Composio를 통한 이메일·캘린더 연결

• Composio에 Gmail과 Google Calendar를 연결하면 개인 비서가 이메일과 일정을 조회해 하루 일정을 브리핑할 수 있지만, 해당 외부 서비스 연결은 선택 사항이다. [1:29:02]
• 에이전트가 사용자를 대신해 메일을 보내지 못하도록 Gmail과 캘린더 권한을 읽기 전용으로 제한하고, 필요한 툴킷만 Hermes 환경에 연결한다. [1:30:11]

47. Composio 설치·인증과 에이전트별 권한 제한

• VPS에서 Composio CLI 설치가 unzip 누락으로 실패한 뒤 의존성을 먼저 설치해 문제를 해결하고, 브라우저 인증 URL로 서버와 Composio 계정을 연결한다. [1:31:05]
• Gmail과 Calendar 스모크 테스트가 통과한 뒤 이메일 접근 권한을 Jarvis와 Assistant 두 에이전트로 제한해, 다른 에이전트가 개인 데이터에 접근하지 못하게 한다. [1:32:16]

48. 이메일 조회와 에이전트 음성 결함 수정

• 최초 테스트에서는 Assistant가 읽지 않은 이메일 수만 확인하고 본문과 시간은 읽지 못했으며, 대화 응답도 에이전트 구분 없이 같은 남성 음성으로 재생되는 두 가지 결함이 드러난다. [1:33:02]
• 수정 후 Assistant가 이메일 내용을 가져오고 캘린더에도 접근할 수 있게 되며, 개인정보가 화면이나 음성으로 노출되지 않도록 실제 응답 재생은 중간에 중단한다. [1:34:04]

49. SSH 터널의 한계와 Tailscale 전환

• SSH 터널 방식은 접속할 때마다 터미널 명령과 비밀번호가 필요하고 모바일을 비롯한 다른 기기에서 사용하기 어려워, 일상적인 대시보드 접근 경로로는 번거롭다. [1:34:43]
• Tailscale은 계정에 연결된 기기들 사이에 가상 사설망을 만들고 전용 URL을 제공하며, 승인된 계정과 앱이 없는 외부 사용자의 대시보드 접근을 차단한다. [1:35:27]

50. Tailscale 계정과 클라이언트 설치

• Mission Control 대시보드 연결은 Tailscale 무료 플랜으로 가능하며, 먼저 계정을 만든 뒤 각 접속 기기에 클라이언트를 설치해 동일한 사설망에 참여시킨다. [1:36:05]
• 운영체제에 맞는 클라이언트를 내려받아 Windows에 설치하면 Tailscale이 작업 표시줄에서 실행되고, 이후 서버와 기기를 연결할 준비가 완료된다. [1:37:04]

51. Tailscale 설치와 VPS 계정 바인딩

• 로컬 PC에 Tailscale을 설치한 뒤 로그인하고, 해당 PC를 자신의 Tailscale 계정에 연결해야 한다. [1:37:05]
• Claude Code에 서버 연결 작업을 요청하더라도 설치 권한이 부족할 수 있으므로, PowerShell로 VPS에 로그인해 안내된 명령을 직접 실행해야 한다. [1:37:25]

52. 전용 URL 접속 검증과 VPN 충돌 방지

• 추가 명령을 실행하면 Mission Control 대시보드에 연결된 Tailscale URL을 확보할 수 있고, 로컬호스트 주소가 열리지 않는 환경에서도 이 URL로 접속할 수 있다. [1:38:26]
• Tailscale URL을 브라우저에 입력하면 복잡한 SSH 터널 없이 대시보드가 정상적으로 열려 원격 접근 구성이 완료된다. [1:38:43]

🧾 결론

• 프리미엄 미션 컨트롤의 핵심은 화려한 JARVIS 외형보다 요청 라우팅, 상태 추적, 결과 검증, 권한 분리로 이어지는 운영 구조에 있다.
• Hermes의 영구 프로필과 독립된 기억·도구 구성을 이용하면 개발·조사·일정 관리가 섞이지 않는 지속적인 다중 에이전트 환경을 만들 수 있다.
• 채팅, 장문 결과물, 작업 로그, 예약 작업을 각각 적합한 저장·표시 계층으로 분리해야 토큰 비용과 운영 복잡도를 통제할 수 있다.
• 구축 후에는 프로필 목록, 텔레그램 토픽별 응답, 작업 로그, 실시간 검색 결과, 음성 시나리오, 원격 접속을 실제로 시험해 각 계층의 연결 상태를 검증해야 한다.

📈 투자·시사 포인트

• 비용 구조는 VPS·AI 모델·검색 API·음성 서비스·스냅샷의 고정비와 사용량 기반 비용이 결합되므로, 역할별 모델 배정과 로컬 음성 처리가 비용 최적화의 핵심이 된다.
• 다중 에이전트 제품의 경쟁력은 모델 수보다 라우팅, 관측 가능성, 기억 분리, 권한 통제, 실패 검증 같은 운영 계층에서 형성될 가능성이 크다.
• 구조화된 실시간 검색 API는 웹 차단과 레이아웃 변경을 외부 계층에 맡기면서 최신성 실패를 줄이는 기반 인프라로서 중요성이 커질 수 있다.
• 자동 설치가 수동 구축 시간을 크게 줄인다는 설명은 템플릿·설치 자동화·운영 지원을 결합한 상품화 기회를 보여주지만, 실제 효율은 환경별 재현성과 유지보수 품질에 달려 있다.

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

• 4개 CPU 코어·8GB RAM·100GB SSD가 충분하다는 평가는 예시 구성에 기반하며, 동시 에이전트 수·로컬 음성 처리량·그래픽 효과에 따른 구체적인 부하 시험 결과는 제시되지 않았다.
• 수동 구축 약 6시간과 자동 설치 5분 이내라는 시간 비교는 설명에 포함돼 있지만, 동일 조건에서 반복 측정한 벤치마크인지는 확인되지 않는다.
• 검색 API의 무료 사용량과 지원 검색원이 언급되지만 장기적인 가격, 호출 제한, 데이터 품질, 장애 대응 수준은 별도로 검증해야 한다.
• 자막 기반 정리: 타임스탬프가 있는 자막을 기준으로 정리했으며, 고유명사·수치·인용은 원문 확인 필요 시 별도 검증한다.
• 영상 속 주장: 발표자의 해석·전망·비교는 확인된 외부 사실이 아니라 영상 속 주장으로 분리해 읽는다.
• 검증 필요: 수치, 기업 실적, 정책·시장 전망은 발행 전 최신 자료로 별도 검증이 필요하다.

✅ 액션 아이템

• Jarvis·Dev·Research·Assistant의 역할, 위임 기준, 독립 기억, 작업공간, 도구 접근 권한을 먼저 정의한다.
• 비루트 사용자로 Hermes를 설치하고 기본 모델을 연결한 뒤 터미널 응답과 프로필 목록을 확인한다.
• 텔레그램 토픽 ID와 프로필 라우팅을 설정하고, 각 토픽에서 동일한 역할 확인 질문을 보내 올바른 에이전트가 응답하는지 시험한다.
• 작업 로그 데이터베이스, Markdown 라이브러리, 예약 작업 화면, 서버 자원 지표를 실제 데이터에 연결한다.

❓ 열린 질문

• 중앙 Jarvis의 결과 검증과 전문 프로필의 직접 라우팅 사이에서 어떤 요청만 중앙 검토 대상으로 남겨야 하는가?
• 에이전트 수와 자동화 작업이 늘어날 때 VPS 상향이 필요한 기준을 CPU·RAM·토큰·응답 지연 중 무엇으로 판단할 것인가?
• 외부 검색 API나 음성 서비스가 실패할 경우 사용자에게 실패 사실을 명확히 알리고 안전하게 대체 경로로 전환할 수 있는가?