🖼️ 인포그래픽

🖼️ 4컷 인포그래픽

💡 한 줄 결론

AI Study Companion은 6 Hermes Agents와 Mission Control Dashboard를 묶어 PDF 업로드부터 노트·퀴즈·일정·연구·채팅까지 이어지는 학습 자동화 운영체제를 구현한 사례다.

📌 핵심 요점

1. 시스템의 중심은 Telegram의 오케스트레이터 Bill과 Discord의 Vault, Scholar, Quiz Master, Planner, Dev 전문 에이전트 5개로 구성된 6개 Hermes 에이전트 구조다.
2. PDF 강의노트를 업로드하면 Vault가 저장하고, Scholar가 구조화 Markdown 노트를 만들며, Quiz Master가 퀴즈를 생성하고, Planner가 마감·시험·수업 일정을 추출하는 순차 파이프라인이 작동한다.
3. Mission Control Dashboard는 과목 수, 노트·퀴즈 수, 에이전트별 작업량, 활동 히트맵, 로그, 라이브러리, 연구, 퀴즈 연습, 일정, 채팅을 한 화면에서 관리하도록 설계됐다.
4. 구축 과정은 VPS 선택, Ubuntu 환경, Hermes 설치, Telegram 봇 설정, Discord 봇·채널 바인딩, OpenAI Codex 모델 연결, SSH 터널과 Tailscale 접근까지 포함한다.
5. 최종 검증에서는 Biology 강의노트 업로드 후 PDF 저장, Markdown 노트 생성, 25문항 퀴즈 로드, Planner 일정 화면, 대시보드 내 Telegram·Discord 채팅 연동, 아침 브리프까지 확인됐다.

🧩 배경과 문제 정의

• 이 영상의 핵심은 PDF 업로드를 시작으로 저장, 구조화된 노트 추출, 퀴즈 생성, 일정 추적, 대시보드 확인까지 이어지는 학습·연구 자동화 흐름이다.
• 6개의 Hermes 에이전트가 각각의 역할과 규칙에 따라 움직이며, Telegram 오케스트레이터와 Discord 전문 에이전트 채널을 통해 작업을 분담한다.
• 연구자나 학생이 아니더라도 문서 주입, 에이전트 파이프라인, 실시간 대시보드 구조를 다른 업무 자동화 사례로 응용해볼 수 있다.

🕒 시간순 섹션별 상세정리

1. 6개 Hermes 에이전트와 미션 컨트롤 구조

• PDF 업로드부터 파일 저장, 구조화 노트 생성, 퀴즈 제작, 마감 추적까지 하나의 자동화 체인으로 연결된다 [00:23]
• 시스템은 Telegram 오케스트레이터와 Discord 기반 Vault, Scholar, Quiz Master, Planner, Dev 전문 에이전트로 구성된다 [00:38]

2. Biology 강의 노트 업로드와 에이전트 파이프라인 실행

• 예시 PDF에는 세포생물학 강의 일정, 실험 세션, 과제 마감, 시험일, 강사명, 강의 본문이 포함된다 [01:40]
• 업로드 탭에서 Biology 과목과 강의 노트를 넣고 파이프라인을 시작하면 Bill이 각 에이전트의 작업을 조율한다 [02:03]

3. 대시보드에서 작업량, 로그, 채팅, 라이브러리 확인

• Overview 페이지는 과목 수, 생성된 노트 수, 퀴즈 수, 에이전트 작업 수를 한눈에 보여준다 [04:13]
• 파이 차트와 7일 활동 히트맵으로 에이전트별 활동 비중과 시간대별 활동 강도를 확인할 수 있다 [04:25]

4. 연구 생성, 퀴즈 연습, 일정 관리 기능

• Research 탭에 제목과 주제를 입력하면 Scholar가 해당 주제의 연구 결과물을 생성한다 [06:42]
• 생성 결과에는 executive summary, key findings, evidence, sources, study notes가 함께 포함된다 [06:49]

5. Hermes 실행 환경 선택과 VPS 사용 이유

• 첫 단계는 Hermes 에이전트를 실행할 시스템을 정하는 것이며, 선택지는 로컬 장비와 외부 VPS로 나뉜다 [08:10]
• 미니 PC나 Raspberry Pi도 사용할 수 있지만, VPS는 홈 네트워크와 분리된 독립 운영 환경을 제공한다 [08:23]

6. VPS 계약 기간, 지역, 저장장치 선택

• VPS 구매 단계에서는 사용 기간을 선택하며, 계약 기간이 길수록 월별 비용은 낮아진다 [10:28]
• 1개월 옵션은 시험 운영에 적합하고, 장기 사용이 확실하다면 12개월 옵션이 비용 면에서 유리하다 [10:50]

7. VPS 저장 공간, Ubuntu, 자동 백업과 비밀번호 설정

• 강의 노트와 자료 저장량을 고려해 저장 공간을 정하고, 운영체제는 Ubuntu 계열로 유지한다 [12:00]
• 자동 백업을 추가하면 대시보드 설정이 망가졌을 때 전날 상태로 복구할 수 있다 [12:17]

8. PowerShell 또는 Terminal로 VPS에 SSH 접속

• Windows는 PowerShell, Mac은 Terminal을 사용해 동일한 SSH 접속 흐름을 진행할 수 있다 [13:56]
• SSH 명령은 root 사용자명과 VPS IP 주소를 조합해 실행한다 [14:32]

9. Hermes Agent 설치와 빠른 설정, 계정 로그인

• VPS에 접속한 뒤 Nous Research 공식 사이트의 Linux용 한 줄 설치 명령으로 Hermes Agent를 설치한다 [15:22]
• 설치 명령은 필요한 의존성과 애플리케이션을 함께 설치해 별도 구성 부담을 줄여준다 [15:50]

10. 기본 모델, 도구, 터미널 백엔드와 Telegram 메시징 선택

• 계정 연결 후 기본 모델은 무료 step 계열로 유지하고, 무료 도구는 선택된 상태로 설치한다 [18:03]
• 터미널 백엔드는 current 옵션을 사용하며, 이후 메시징 플랫폼 설정이 핵심 분기점이 된다 [18:26]

11. BotFather로 Telegram 봇 토큰 생성

• Hermes 설정에는 Telegram 봇 토큰이 필요하므로 BotFather에서 새 봇을 생성한다 [19:19]
• 공식 BotFather 계정을 확인한 뒤 /newbot 명령으로 봇 생성 절차를 시작한다 [19:31]

12. Telegram 사용자 ID 바인딩, 게이트웨이 서비스화, Codex 모델 선택

• Hermes는 봇 접근을 제한하기 위해 Telegram 사용자 ID를 요구한다 [20:41]
• 사용자 ID를 입력한 뒤 home channel로 사용할지 묻는 단계에서 Y를 입력해 기본 대화 채널로 연결한다 [21:15]

13. OpenAI Codex 인증과 기본 모델 선택

• 월 20달러 구독으로도 Hermes 운영이 가능하며, hermes model 명령으로 모델 선택 절차를 시작한다 [24:01]
• OpenAI Codex 옵션은 ChatGPT 구독을 Hermes와 연결해 API 사용량 과금보다 비용 예측성을 높인다 [24:33]

14. Hermes 터미널과 Telegram 봇 연결 확인

• hermes 명령으로 터미널 UI를 열어 설치와 모델 연결이 실제 응답으로 이어지는지 확인한다 [26:20]
• 환영 메시지와 hello 응답이 확인되면 Hermes 설치와 GPT 5.5 연결이 정상 작동 중이다 [26:43]

15. 오케스트레이터 Bill에게 사용자와 시스템 구조 부여

• 새 Hermes는 사용자 이름, 에이전트 이름, 구축 목표를 모르는 상태이므로 초기 설명이 필요하다 [28:28]
• 프롬프트에는 사용자 Larry, 오케스트레이터 Bill, AI student companion system 구축 목표가 포함된다 [29:07]

16. 기억 저장과 작업 커뮤니케이션 규칙 설정

• 에이전트가 응답 중일 때 추가 메시지를 보내면 일부 메시지가 유실될 수 있으므로 응답 완료 후 입력한다 [30:18]
• Bill 확인 후 user.md와 memory에 Larry 정보, AI student companion 목표, Bill의 코디네이터 역할이 저장된다 [30:32]

17. 다섯 persistent Hermes profiles 생성

• 다음 핵심 단계는 Bill과 함께 작동할 다섯 개의 전문 에이전트 profile을 만드는 것이다 [31:58]
• persistent profile은 일회성 생성이 아니라 지속적으로 유지되는 구조이므로, Discord에서 직접 대화하는 흐름에 중요하다 [32:05]

18. 승인 흐름, 에이전트 검증, 독립 workspace 준비

• 복잡한 profile 생성 과정은 여러 단계로 나뉘며, 사용자는 전체 진행 상황을 단계별로 확인할 수 있다 [33:53]
• 권한 승인 화면에서는 allow once, always, deny를 선택해 에이전트가 어디까지 진행할지 통제한다 [34:11]

19. 팀 인식과 라우팅 기반 구축

• 다섯 에이전트는 각각 전용 workspace를 갖고, 업데이트와 경계 테스트를 거쳐 준비된다 [36:15]
• shared team awareness는 각 에이전트가 다른 팀원의 역할까지 이해하게 해 적절한 handoff를 가능하게 한다 [36:31]

20. 에이전트 작업 로그 데이터베이스와 운영 규칙

• agent login system은 작업 ID, 에이전트명, 작업 설명, 사용 모델, 상태, 날짜와 시간을 기록한다 [38:19]
• SQLite 기반 작업 로그는 VPS 부담을 낮추면서 에이전트 활동을 투명하게 추적하는 역할을 한다 [38:52]

21. Telegram 단일 채널의 한계와 Discord 병행 구조

• Telegram에서는 Bill과 직접 대화하고, 다른 에이전트는 슬래시 명령으로 라우팅해야 한다 [40:14]
• Discord에 에이전트별 채널을 만들면 Bill을 거치지 않고 각 전문 에이전트에게 직접 요청할 수 있다 [40:28]

22. Discord 서버와 봇 애플리케이션 생성

• Discord 설정은 새 서버 생성에서 시작하며, 서버명은 프로젝트 목적에 맞게 정한다 [42:23]
• Discord Developer Portal에서는 같은 이름의 application을 만들어 봇과 애플리케이션 이름을 일관되게 맞춘다 [42:45]

23. 봇 권한, 토큰, 초대 URL 설정

• administrator 권한은 자동 채널 생성에는 편리하지만, 잘못 동작할 경우 위험도 커진다 [43:33]
• reset token으로 Discord bot token을 만들고, 이 값은 안전한 곳에 보관해야 한다 [44:05]

24. Discord 식별자 수집과 Hermes 설정 진입

• Discord 연동에는 bot token, server ID, user ID가 모두 필요하다 [46:00]
• server ID가 보이지 않으면 developer options를 켠 뒤 서버 ID와 사용자 ID를 복사한다 [46:28]

25. Discord gateway 설정과 접근 제한

• Hermes 설정에서 Telegram 재설정을 건너뛰고 Discord 봇 토큰을 입력한다 [48:06]
• Discord user ID를 추가해 허용된 사용자만 봇과 대화할 수 있게 제한한다 [48:26]

26. Gateway 재시작 확인과 터미널 기반 복구 수단

• Gateway 재시작 중 메시징 채널에 알림이 오고, 중단된 작업은 온라인 복구 후 이어질 수 있다 [49:11]
• Discord 서버에 gateway online 메시지가 표시되면 Hermes가 서버에 접근 가능한 상태다 [49:32]

27. Discord 서버 연결 검증과 에이전트 채널 생성

• Discord 서버 ID를 Bill에게 전달해 Hermes 설정과 서버 연결을 맞추도록 요청한다 [51:06]
• Bill은 Dev에게 작업을 위임하고, reachability 테스트 메시지로 Discord 연결을 확인한다 [51:39]

28. 에이전트별 채널 바인딩 오류와 수정

• 각 에이전트를 전용 채널 ID에 바인딩하고, 채널별 “who are you?” 응답으로 라우팅을 검증한다 [53:10]
• 첫 검증에서는 모든 채널에서 Bill이 응답해 채널별 라우팅 실패와 매핑 오류가 드러난다 [53:43]

29. Mission Control Dashboard 백엔드 구축 착수

• Dashboard 구현은 Dev가 맡아 백엔드와 프런트엔드 개발자 역할을 수행한다 [55:18]
• 첫 요청에는 단일 파일 Python 서버, 접근 방식, 설치 항목, 데이터베이스, students 폴더 조건이 포함된다 [55:36]

30. SSH tunneling으로 Dashboard 접근과 디자인 템플릿 준비

• Dev는 백엔드 구현 후 SSH tunneling 명령과 VPS IP를 제공해 로컬 PC에서 dashboard를 열게 한다 [57:04]
• SSH tunnel은 로컬 포트와 VPS 포트를 연결하며, VPS 비밀번호가 접근 보안 장벽이 된다 [57:30]

31. 디자인 템플릿 업로드와 대시보드 프론트엔드 구축

• 대시보드에 디자인 레퍼런스 업로드 지점이 생기고, VPS에서 템플릿 파일을 로드한다 [1:00:10]
• Dev에게 템플릿과 최대한 유사한 프런트엔드 구현 요구가 전달된다 [1:00:38]

32. 개요 페이지 수정과 프롬프트 품질 관리

• 첫 Overview 결과물은 히트맵, 캘린더, 에이전트 상태 표시가 어색해 추가 조정이 필요하다 [1:02:06]
• 수정 후 활동 맵과 캘린더가 정리되지만, 오른쪽 중복 카드 제거 요구가 계속된다 [1:02:28]

33. Hermes 내장 브라우저와 개요 대시보드 데이터 구성

• Hermes 내장 브라우저로 Dev가 화면을 탐색하고 비전·콘솔로 동작을 확인한다 [1:03:43]
• 개요 탭은 전체 작업 수, 에이전트별 활동 파이 차트, 최근 활동 데이터를 표시한다 [1:04:13]

34. 백업 규칙과 버전 관리로 대시보드 손상 위험 줄이기

• 대시보드 수정 전 index.html을 백업하는 규칙이 필요하다 [1:05:02]
• 백업 없이 화면이 망가진 경험 때문에 최신 또는 직전 버전으로 되돌릴 복구 지점이 중요하다 [1:05:24]

35. 에이전트 분석 페이지 구축과 무료 자료 제공 맥락

• Agents 페이지는 각 에이전트의 작업 내용과 최근 활동을 더 구조화해 보여주는 화면이다 [1:07:26]
• Dev는 여섯 에이전트별 정보를 반환하는 엔드포인트와 디자인 요구를 반영한다 [1:07:43]

36. 문서 파이프라인과 Scholar 연구 기능 확장

• PDF 업로드 후 Vault가 subject.md에 기록하고 Scholar가 전용 notes 폴더에 구조화 노트를 만든다 [1:09:13]
• Scholar 이후 Quiz Master가 퀴즈를 만들고 Planner가 시험일·마감일·강의 시간을 planning 파일에 반영한다 [1:09:50]

37. Scholar 연구 워크스페이스와 handoff 검증

• 연구 요청은 요약, 핵심 인사이트, 근거, 참고자료, 실행 제안을 포함하며 Scholar 채널로 전달돼야 한다 [1:12:10]
• 대시보드에는 연구 입력 화면과 연구 요청을 저장하는 작은 데이터베이스·엔드포인트가 필요하다 [1:12:45]

38. 실제 연구 결과 확인과 lecture notes reader 추가

• 활동 탭과 연구 탭에 이전 연구 요청과 Dev 스모크 테스트가 완료 상태로 표시된다 [1:15:17]
• “학생과 AI” 연구는 약 5분 만에 완료되고 executive summary, key findings, 참고자료를 포함한다 [1:15:58]

39. Quiz Master 기반 퀴즈와 플래시카드 학습 기능

• Quiz Master는 생성된 노트를 읽고 시험 대비 퀴즈를 만들어 특정 과목 학습을 돕는다 [1:18:07]
• 이동 중에도 대시보드에 접근해 버스나 기차 안에서 문제 풀이 훈련을 할 수 있는 시나리오가 드러난다 [1:18:24]

40. 작업관리와 포모도로 중심의 생산성 기능

• 학습 대시보드에는 과제와 일정을 관리하는 Kanban taskboard가 추가된다 [1:21:07]
• task는 to-do, in progress, done 사이에서 이동하며 활동과 마감일을 관리한다 [1:21:29]

41. 대시보드 내 에이전트 채팅과 Telegram 연동 확인

• chat 탭은 Discord나 Telegram으로 이동하지 않고, 대시보드 안에서 곧바로 에이전트와 대화하도록 만든 기능이다 [1:22:54]
• 구현 후 Bill, Vela, Scholar 등 에이전트별 채팅 화면에서 직접 메시지를 보내고 응답을 확인할 수 있다 [1:23:15]

42. 대시보드 채팅 통합과 전체 파이프라인 검증 시작

• Vault의 Discord 응답이 Mission Control Dashboard에도 표시되며, chat integration이 정상 작동함을 확인한다 [1:24:24]
• 핵심 목표는 Dashboard 한곳에서 agent orchestration을 처리해 외부 채팅 앱으로 이동하는 흐름을 줄이는 것이다 [1:24:37]

43. 강의 노트 업로드 후 agent pipeline 순차 실행

• Vault activation과 업로드 logging이 시작되고, 첫 단계가 끝나면 다음 에이전트로 이어지는 cascade 구조가 확인된다 [1:26:29]
• Vault는 biology 처리를 48초 만에 완료하고, Scholar가 lecture notes를 markdown notes로 추출하기 시작한다 [1:26:38]

44. 결과물 확인과 notes·planner endpoint 보완

• Library에는 생성된 biology PDF가 표시되고, Vault가 업로드 파일과 library 기록을 남긴 상태도 확인된다 [1:27:43]
• Practice 탭에서 biology quiz를 시작하면 25문항이 로드되며, 오답 선택 시 정답과 incorrect 상태가 함께 반환된다 [1:28:04]

45. SSH 터널 한계와 Tailscale 기반 접근 전환

• 기존 접근 방식은 SSH tunnel, VPS username, password, IP 입력이 필요하고, tunnel이 열린 PC에서만 사용할 수 있다 [1:29:28]
• Tailscale은 PC VPN 설정 후 받은 URL을 북마크해, 매번 IP와 비밀번호를 입력하지 않고 접속하게 해준다 [1:29:58]

46. VPS·PC Tailscale 인증과 안전한 dashboard 접속

• Dev가 VPS에 Tailscale을 설치하고 authentication URL을 제공하면, 브라우저에서 device connect를 완료한다 [1:31:39]
• 인증 완료를 알리면 Dev가 SSH tunnel 없이 Dashboard에 접근할 수 있는 새 URL을 반환한다 [1:32:04]

47. 아침 브리프 자동화와 최종 활용 범위

• 마지막 자동화는 Bill이 매일 아침 weather, today lectures, upcoming deadlines를 보내는 morning brief다 [1:33:23]
• 첫 smoke test는 Telegram으로 도착하지만 location 누락으로 weather는 실패하고, 수업과 마감 정보는 포함된 상태로 최종 동작 범위를 확인한다 [1:33:44]

🧾 결론

• 이 영상의 핵심은 단순한 챗봇 제작이 아니라, 문서 입력을 출발점으로 여러 전문 에이전트가 분업하고 결과를 대시보드에서 추적하는 학습 운영 시스템 구축이다.
• Hermes profile을 에이전트 단위로 나누고, 각 에이전트에 역할·메모리·워크스페이스·라우팅 규칙을 부여한 점이 전체 구조의 기반이다.
• 대시보드는 사용자가 Telegram이나 Discord를 오가지 않아도 파일 업로드, 연구 요청, 퀴즈 연습, 일정 확인, 에이전트 채팅을 수행하게 만드는 통합 인터페이스 역할을 한다.
• 실전 운영 관점에서는 로그 데이터베이스, 변경 전 백업 규칙, gateway 복구 수단, Tailscale 접근, morning brief 같은 보조 장치가 시스템의 지속 사용 가능성을 높인다.
• 영상 안에서 확인된 범위는 튜토리얼 환경의 작동 사례이며, 실제 장기 운영 안정성이나 대규모 사용자 환경에서의 성능은 별도 검증이 필요하다.

📈 투자·시사 포인트

• 개인 학습 도구의 방향은 단순 요약 앱에서 문서 수집, 구조화, 문제 생성, 일정 관리, 반복 학습까지 묶는 에이전트형 워크플로로 확장될 가능성을 보여준다.
• 기업이나 연구 조직 입장에서는 강의노트 대신 보고서, 계약서, 리서치 자료, 회의록을 넣어 유사한 문서 처리·검토·추적 파이프라인으로 재구성할 수 있다.
• Telegram과 Discord를 병행한 구조는 사용자 접점과 에이전트 전용 작업 공간을 분리하는 방식으로, 멀티에이전트 운영에서 채널 설계가 중요하다는 점을 시사한다.
• VPS, 백업, 권한 제한, 로그 기록, Tailscale 접근처럼 인프라·보안·복구 요소가 포함되어야 에이전트 자동화가 데모를 넘어 실제 운영 도구에 가까워진다.
• 검증 필요 항목: Contabo 비용, 특정 Hermes 설치 절차, GPT 5.5 및 Codex 연결 방식, 장기 안정성, 데이터 보안 수준은 영상 속 설명과 시연을 넘어 최신 공식 문서와 실제 환경 테스트로 확인해야 한다.

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

• Contabo VPS의 가격, CPU/RAM 구성, 지역별 추가 비용, 백업 요금은 영상 시점의 설명이므로 실제 구매 전 현재 요금표를 다시 확인해야 한다.
• Hermes Agent 설치 명령, 포털 가입 절차, 무료 플랜, 기본 모델, 도구 선택 화면은 서비스 업데이트에 따라 달라질 수 있으므로 공식 Hermes 문서 기준으로 재확인해야 한다.
• 영상에서는 OpenAI Codex 모델을 ChatGPT Plus/Pro 구독으로 Hermes에 연결하는 흐름을 설명하지만, 실제 사용 가능 모델·한도·정책은 현재 OpenAI와 Hermes의 조건을 따로 확인해야 한다.
• 자막 기반 정리: 타임스탬프가 있는 자막을 기준으로 정리했으며, 고유명사·수치·인용은 원문 확인 필요 시 별도 검증한다.
• 영상 속 주장: 발표자의 해석·전망·비교는 확인된 외부 사실이 아니라 영상 속 주장으로 분리해 읽는다.
• 검증 필요: 수치, 기업 실적, 정책·시장 전망은 발행 전 최신 자료로 별도 검증이 필요하다.

✅ 액션 아이템

• Hermes Agent를 설치하기 전, 로컬 장비와 VPS 중 어떤 환경이 운영 안정성·비용·보안 요구에 맞는지 결정한다.
• Telegram BotFather로 봇을 만들고, 봇 토큰과 Telegram 사용자 ID를 안전한 위치에 보관한다.
• Discord 연동을 사용할 경우 bot token, server ID, user ID를 준비하고, message content intent 등 필요한 설정을 활성화한다.
• Vault, Scholar, Quiz Master, Planner, Dev처럼 역할이 분리된 persistent profile을 만들고 각 에이전트의 책임 범위를 명확히 문서화한다.

❓ 열린 질문

• 이 구조를 실제 학습 환경에서 사용할 때, 6개의 에이전트로 나누는 방식이 단일 에이전트나 더 단순한 자동화보다 충분히 큰 이점을 주는가?
• Scholar가 만든 구조화 노트와 Quiz Master가 만든 퀴즈의 품질을 어떤 기준으로 검수하고, 오류가 발견되면 어떤 피드백 루프로 개선할 것인가?
• 학생의 강의자료, 일정, 연구 주제, 채팅 기록이 VPS와 메신저 플랫폼을 거칠 때 개인정보와 저작권 자료를 어떻게 보호할 것인가?