YouTube실밸개발자·2026년 6월 14일·0

헤르메스 에이전트 - 노트북 꺼도 24시간 일하는 AI 팀 만들기

Quick Summary

헤르메스 에이전트는 노트북 꺼도 24시간 일하는 AI 팀을 만들기 위해 서버, 메시징 채널, 메모리, 스킬, 칸반 실행 흐름을 결합한 지속형 자율 에이전트 구조다.

영상 보기

클릭 전까지는 가벼운 미리보기만 먼저 불러옵니다.

원본 열기

🖼️ 인포그래픽

헤르메스 에이전트 - 노트북 꺼도 24시간 일하는 AI 팀 만들기 내용을 설명하는 본문 이미지

🖼️ 4컷 인포그래픽

헤르메스 에이전트 - 노트북 꺼도 24시간 일하는 AI 팀 만들기 내용을 설명하는 본문 이미지

💡 한 줄 결론

헤르메스 에이전트는 노트북 꺼도 24시간 일하는 AI 팀을 만들기 위해 서버, 메시징 채널, 메모리, 스킬, 칸반 실행 흐름을 결합한 지속형 자율 에이전트 구조다.

📌 핵심 요점

  1. 헤르메스 에이전트는 Nous Research의 오픈소스 자율 에이전트 시스템으로 소개되며, 특정 LLM 모델이 아니라 GPT·Claude·로컬 모델 등을 연결해 쓰는 실행 환경에 가깝다.
  2. 일반 챗봇처럼 매번 프롬프트를 주고받는 구조와 달리, VPS나 Docker 컨테이너에서 24시간 대기하며 Discord 같은 메시징 채널을 통해 작업을 받을 수 있다는 점이 핵심이다.
  3. 작업 결과를 바탕으로 메모리와 스킬을 저장·갱신하는 closed learning loop가 강조되며, 비슷한 문제가 다시 나오면 이전 경험을 재사용해 더 빠르게 처리하는 방향을 지향한다.
  4. 설치 흐름은 VPS 선택, Docker 기반 배포, 모델 인증, Discord 봇 생성, Gateway 연결, 사용자 ID·권한 설정, Doctor 점검, 컨테이너 재시작을 통한 24시간 동작 확인으로 이어진다.
  5. 후반부에서는 멀티프로필, Discord 작업 지시, 대시보드, 크론잡, 칸반 보드를 통해 개인 비서형 AI를 넘어 목표를 작업 단위로 쪼개 실행하는 멀티에이전트 운영 가능성을 보여준다.

🧩 배경과 문제 정의

  • 핵심 문제는 노트북이 꺼지면 터미널 중심 에이전트도 함께 멈춘다는 한계다. 이를 해결하려면 서버에서 24시간 대기하며 메시징 채널로 응답하는 지속형 AI 직원 구조가 필요하다.
  • 헤르메스 에이전트는 모델 자체가 아니라 Nous Research의 오픈소스 자율 에이전트 시스템이다. GPT, Claude, 로컬 모델 등을 연결해 역할별로 활용할 수 있다.
  • 기존 챗봇과 달리 작업 실행, 결과 학습, 스킬과 메모리 축적, 서버 기반 상시 실행이 결합되면서 개인 비서보다 업무를 맡는 AI 직원에 가까운 형태가 된다.
  • 설치 위치는 보안과 비용에 직접적인 영향을 준다. 메인 노트북은 개인정보 노출 위험이 크고, 전용 서버는 비용 부담이 있으며, 클라우드 VPS는 실험용 대안으로 제시된다.

🕒 시간순 섹션별 상세정리

1. 설치 흐름과 데모 목표

  • 초기 확인 뒤 풀 셋업으로 들어가며, 디스코드 연결과 사용자별 MD 파일 생성을 위한 딥 인터뷰 흐름이 준비된다 [00:51]
  • 칸반은 헤르메스의 멀티 에이전트 오케스트레이션을 위한 시스템으로 소개되고, 에이전트들이 섹션 단위로 배치된 구조가 드러난다 [00:56]

2. 헤르메스 에이전트의 정체와 사용 범위

  • 헤르메스 에이전트는 Nous Research가 만든 에이전트 시스템으로, 같은 이름의 LLM 모델과는 별개다 [01:06]
  • 이번 영상의 대상은 모델이 아니라 에이전트 시스템이며, GPT·Claude·로컬 모델 등 다양한 모델을 연결해 쓸 수 있다는 점이 핵심 장점이다 [01:24]

3. 챗봇과 다른 상시 대기형 에이전트 구조

  • 일반 챗봇은 사용자가 매번 프롬프트를 입력하고 응답을 받는 왕복 구조지만, 헤르메스 에이전트는 24시간 응답을 기다리는 대기 상태를 유지한다 [02:31]
  • 사용자가 말하면 즉시 응답하고 작업을 실행하며, 그 결과를 바탕으로 배우고 개선되는 에이전틱 시스템에 가깝다 [02:52]

4. 자동 학습 루프와 노트북 독립성

  • 공식 사이트는 내장 학습 루프를 강점으로 강조하지만, Claude Code나 Codex에도 스킬·메모리와 유사한 기능은 존재한다 [03:50]
  • 핵심 차이는 사용자가 “기억해”라고 직접 지시하지 않아도, 헤르메스 에이전트가 필요한 기억과 스킬을 스스로 저장한다는 점이다 [04:04]

5. 오픈클로와의 차이, 메모리 관리, 마이그레이션

  • 오픈클로는 채널 연결과 생태계 확장성이 강한 중앙 관제탑에 가깝고, 멀티 에이전트 오케스트레이션과 멀티 프로파일 운영에 더 특화돼 있다 [05:00]
  • 헤르메스는 작업 실행과 자가 개선에 더 초점을 두며, 메모리와 스킬을 스스로 갱신해 시간이 지날수록 나아지는 자동화 에이전트를 지향한다 [05:39]

6. 공식 사이트의 장점과 설치 위치 선택

  • 공식 사이트의 핵심 메시지는 “서버에 설치하고 메시징 계정을 연결하면 지속적인 개인 에이전트가 된다”는 것이며, 프로젝트 학습·자체 스킬 구축·어디서든 접근 가능성이 주요 셀링 포인트다 [07:17]
  • 주요 장점은 지속 메모리, 자동 스킬 생성, 멀티플랫폼 게이트웨이, 예약 자동화, 병렬 서브 에이전트, 브라우저 제어로 압축된다 [07:52]

7. 호스팅어 VPS 선택과 비용 구조

  • 호스팅어 VPS를 빌리면 개인 서버를 직접 유지보수하지 않고도, 클라우드 서버에 접속해 헤르메스 에이전트를 설치해 사용할 수 있다 [12:12]
  • 데이터센터 위치는 가까울수록 성능에 유리하며, 한국 사용자에게는 인도네시아가 비교적 가까운 선택지로 드러난다 [13:02]

8. VPS 구매 후 Docker Manager에서 헤르메스 배포

  • 구매가 끝나면 호스팅어의 VPS 관리 화면에서 Docker Manager로 이동하고, 프로젝트의 Compose 메뉴에서 원클릭 디플로이를 실행한다 [14:31]
  • 원클릭 디플로이 목록에서 헤르메스 에이전트를 선택하고 패스워드를 지정하면, 서버 안에 헤르메스 실행 환경이 생성된다 [15:03]

9. 모델 인증과 Docker·Discord 옵션 선택

  • 헤르메스는 코딩에는 코덱스, 기획에는 클로드, X 검색에는 그록처럼 여러 모델을 역할별로 조합해 쓰는 오케스트레이션 구조를 갖는다 [16:03]
  • 클로드 코드는 구독제가 아니라 API 과금 방식으로 연결되어 추가 비용이 발생하고, 코덱스는 오픈AI 구독제 기반으로 연결하는 흐름이 추천된다 [16:49]

10. 디스코드 애플리케이션 생성과 봇 토큰 설정

  • Discord Developer Portal에서 새 애플리케이션을 만들고, 봇 이름은 헤르메스나 개인 비서처럼 원하는 이름으로 지정한다 [18:25]
  • 봇 설정에서 이름과 아이콘을 정한 뒤, Hermes setup에 필요한 Bot Token을 발급받기 위해 토큰을 리셋하고 복사한다 [18:57]

11. OAuth2 권한 부여와 디스코드 서버 초대

  • OAuth2 메뉴에서 봇 초대 URL을 생성하며, 이 URL을 통해 봇을 자신의 디스코드 서버에 초대한다 [20:25]
  • 봇 권한에는 메시지 보내기, 메시지 히스토리 읽기, 채널 보기, 파일 첨부처럼 채팅 응답과 작업 결과 전달에 필요한 기능을 포함한다 [20:56]

12. 사용자 ID 입력과 설정 완료 점검

  • 호스팅어 터미널로 돌아가 사용자 ID를 입력해야 하며, 디스코드 개발자 모드를 켜면 사용자 ID 복사 메뉴를 사용할 수 있다 [22:48]
  • 복사한 사용자 ID를 붙여 넣고, 홈 채널 ID는 당장 비워 두어도 되며 이후 /sethome 명령으로 자동 설정할 수 있다 [23:19]

13. Doctor 점검과 Discord Gateway 연결 확인

  • Hermes Doctor가 API 키 설정 등 문제를 감지하고, doctor fix로 대부분의 오류를 자동 수정할 수 있는 상태를 만든다 [24:02]
  • hermes gateway run을 실행해 Gateway를 열고, Discord와 메시지를 주고받을 수 있는지 확인한다 [24:19]

14. 수동 Gateway의 한계와 24시간 동작 검증

  • 터미널에서 Gateway를 수동 실행하면 접속이 끊겼을 때 Discord 메시지가 Hermes Agent까지 전달되지 않는 한계가 있다 [25:18]
  • Docker 컨테이너를 재시작하면 Gateway가 함께 다시 올라가며, 별도 수동 실행 없이 24시간 동작하는 구조가 된다 [25:36]

15. Discord 작업 지시와 멘션 불편 문제

  • Discord에서 아키텍처 패턴 세 가지를 정리해 달라고 요청하며, Hermes가 일반적인 질문형 작업에 응답하는지 확인한다 [26:15]
  • 봇 멘션을 빠뜨리면 요청이 전달되지 않을 수 있어, 매번 멘션해야 하는 사용성 문제가 확인된다 [26:30]

16. VS Code Remote SSH로 서버 프로젝트 열기

  • VS Code에서 Remote SSH 확장을 설치하고, 명령 팔레트에서 SSH 호스트 연결을 시작한다 [27:08]
  • Docker 컨테이너 화면에 표시된 ssh root@... 주소를 현재 대여 중인 서버 주소로 보고, 이를 새 SSH 호스트로 추가한다 [28:01]

17. 멘션 필수 설정 해제와 접근 권한 관리

  • config 파일에서 require_mention 값을 찾아 Discord 설정의 멘션 필수 옵션을 false로 바꾸면, 봇 멘션 없이도 메시지를 받을 수 있다 [30:11]
  • 설정 파일을 수정한 직후에는 변경이 바로 적용되지 않으므로 Docker 컨테이너를 재시작해 새 설정을 반영한다 [30:40]

18. 네 가지 컨텍스트 파일과 개인화 인터뷰 시작

  • Hermes Agent의 첫 번째 레이어는 정체성과 규칙이며, SOUL.md는 에이전트의 성격과 정체성을 담는 핵심 파일이다 [32:30]
  • AGENTS.md에는 작업 실행 규칙이 들어가고, Claude 계열의 규칙 파일처럼 Hermes가 태스크를 수행할 때 따라야 할 기준을 제공한다 [33:15]

19. 개인화 컨텍스트 파일 구성과 딥 인터뷰

  • 비서의 성격은 SOUL 파일에, 사용자가 누구인지에 대한 정보는 USER 파일에, 작업 실행 시 지켜야 할 규칙과 프로세스는 AGENTS.md에 들어간다 [36:02]
  • 딥 인터뷰는 사용자의 삶, 핵심 키워드, 원하는 비서상, 절대 피해야 할 도움 방식 같은 질문을 통해 장기적으로 필요한 개인 맥락을 수집한다 [36:25]

20. 사용자 이해 검증과 단일 프로필의 한계

  • SOUL 파일에는 “실배 개발자의 장기적인 사고 실행 파트너” 같은 정체성, 콜 센텐스, 퍼스널리티가 117줄 정도로 정리되어 에이전트 역할이 구체화된다 [37:02]
  • 개인화 파일이 없는 상태라면 “나에 대해 알고 있는 것”을 물어도 답할 근거가 거의 없고, 단일 프로필만으로 모든 업무를 처리하는 데 한계가 드러난다 [37:20]

21. 멀티프로필과 에이전트 간 오케스트레이션 구조

  • 유튜브, 개인 업무, 사이드 프로젝트, 회사 업무를 각각 별도 봇으로 만들면 목적별 SOUL.md가 생기고, 메인 헤르메스 에이전트가 상위 오케스트레이터가 된다 [38:35]
  • 메인 에이전트는 유튜브 에이전트 같은 하위 에이전트에게 일을 시키고, 하위 에이전트와 직접 대화하며 사용자를 거치지 않는 보고 체계를 만든다 [38:59]

22. 대시보드에서 확인하는 헤르메스 운영 기능

  • 헤르메스 대시보드에는 최근 칸반 기능이 추가되어 멀티 에이전트 오케스트레이션을 웹 UI에서 관리할 수 있고, 채팅 화면에서는 GPT 5.5와 현재 컨텍스트를 함께 확인할 수 있다 [40:45]
  • “실배 개발자님” 같은 호칭은 유저 MD와 컨텍스트 파일을 미리 채워 둔 결과이며, 세션 화면에서는 디스코드에서 진행한 기록과 연결된 플랫폼 정보까지 확인할 수 있다 [41:59]

23. 칸반의 기본 개념과 헤르메스 안의 작업 보드

  • 칸반은 일을 카드 단위로 만들고 투두, 진행 중, 완료 같은 상태 칸에 배치해 작업 진행 상황을 한눈에 파악하는 업무 추적 방식이다 [44:08]
  • 소프트웨어 개발에서는 칸반이 애자일 방법론의 한 형태로 쓰였고, 헤르메스에서는 이 구조가 멀티 에이전트 오케스트레이션을 실행하는 작업 보드로 계속된다 [44:47]

24. 목표 카드 하나에서 자동 작업 분해와 실행으로 이어지는 흐름

  • 새 작업이 생기면 디스패처가 이를 인식하고, 스펙이 자세할수록 에이전트는 일을 더 세분화해 실행 가능한 하위 작업으로 나눈다 [45:53]
  • 랜딩 페이지 요청은 콘텐츠 작성, UI 구조 설계와 구현, 반응형 스타일과 접근성 보장, SEO 메타데이터와 최종 문구 정리, 최종 QA라는 다섯 개 투두로 분해된다 [46:30]

25. 인텐트만으로는 원하는 결과에 도달하기 어렵다

  • 프롬프트 엔지니어링은 자세한 스펙을 줄수록 원하는 결과에 가까워졌고, 최근에는 의도만 주면 AI가 빈틈을 채우는 루프 엔지니어링으로 이동했다는 인식이 커졌다 [48:10]
  • 인텐트만으로도 작업은 진행되지만, 사람의 취향이 중요한 결과물은 기대와 어긋날 수 있으며, 특히 UI처럼 감각이 필요한 영역에서는 중간 검수가 중요하다 [48:47]

26. 24시간 에이전트는 작업 장소와 리듬을 바꾼다

  • 개발 자동화는 일상 자동화보다 체감 효용이 크고, 사이드 프로젝트와 유튜브 작업까지 헤르메스 에이전트로 처리하려는 흐름으로 계속된다 [49:39]
  • 24/7 에이전트의 핵심 장점은 컴퓨터 앞에서 Claude Code와 계속 대화해야 하는 제약을 줄이고, 침대·카페·외출 중에도 지시와 검수를 이어갈 수 있다는 점이다 [49:59]

27. 다음 경쟁력은 프로액티브한 인사이트 자동화다

  • 에이전트에게 일을 시켜 잘하게 만드는 단계는 점점 기본값이 되었고, 다음으로 중요한 방향은 에이전트가 먼저 인사이트를 제안하고 다음 작업을 물어보는 것이다 [50:35]
  • 크론잡으로 한 시간마다 AI 트렌드 인사이트를 조사해 사용자에게 전달하게 만들면, 사람이 영상과 글을 모두 직접 소비하지 않아도 인사이트 탐색 범위를 넓힐 수 있다 [51:00]

28. 대시보드 데모와 자가 개선 에이전트의 관리 포인트

  • 칸반 대시보드에서는 헤르메스 에이전트가 대부분의 작업을 완료한 상태였고, 한 줄짜리 랜딩 페이지 요청만으로 Claude Code 실전 강의 사이트가 생성된 결과를 확인할 수 있다 [51:51]
  • GitHub 이슈를 자기 전에 만들어 두면 새벽에도 24/7 에이전트가 버그를 고칠 수 있고, CI 실패를 10분마다 확인해 수정하도록 설정하면 GitHub 작업까지 자동화할 수 있다 [52:36]

🧾 결론

  • 이 영상의 핵심은 “AI를 내 노트북 안의 도구로만 쓰지 않고, 서버에 상주하는 업무 실행 주체로 옮길 수 있는가”라는 질문에 대한 실전형 답변이다.
  • 헤르메스 에이전트는 Discord 연결, Docker 실행, 메모리·스킬 파일, Gateway, 대시보드, 칸반을 엮어 사용자가 어디서든 일을 맡기고 결과를 확인할 수 있는 구조를 제시한다.
  • 다만 24시간 동작 자체보다 중요한 것은 권한 관리, 개인화 컨텍스트 설계, 멘션·홈 채널 같은 사용성 설정, 그리고 스스로 바꾸는 스킬과 메모리의 품질을 주기적으로 점검하는 일이다.
  • 영상은 “목표만 던지면 끝”이라는 낙관보다, 좋은 결과를 위해서는 스펙 작성과 중간 검수, 휴먼 인 더 루프가 여전히 필요하다는 현실적인 한계도 함께 짚는다.

📈 투자·시사 포인트

  • 24시간 AI 에이전트의 가치는 단순 질의응답보다 지속 대기, 업무 실행, 알림, 일정·메일 확인, GitHub 작업 자동화처럼 반복 운영이 필요한 영역에서 커질 가능성이 있다.
  • VPS, Docker, 메시징 게이트웨이, 멀티프로필, 칸반 같은 요소가 결합되면서 개인 사용자도 작은 AI 운영팀을 구성하는 방향으로 도구 사용 방식이 바뀔 수 있다.
  • 비용 측면에서는 로컬 노트북, 전용 서버, 클라우드 VPS 사이의 선택이 중요하며, 영상은 실험용 대안으로 클라우드 VPS를 제시하지만 장기 결제·API 과금·서버 비용은 별도 계산이 필요하다.
  • 보안 측면에서는 Discord 봇 권한, allowed_user 설정, GitHub·Gmail·Google Calendar 같은 외부 연동 권한이 핵심 리스크로 언급되며, 24시간 에이전트일수록 접근 권한을 좁게 관리해야 한다.
  • 검증 필요: 영상에 나온 GitHub 스타 수, MIT 라이선스, 호스팅어 VPS 가격, 특정 데이터센터 선택의 성능 이점은 업로드 시점 기준 설명일 수 있으므로 실제 도입 전 최신 공식 정보를 확인해야 한다.

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

  • 영상에서 언급된 Hermes Agent의 GitHub 스타 수, MIT 라이선스, 공개 시점 등 프로젝트 상태는 시간이 지나며 바뀔 수 있으므로 실제 도입 전 공식 저장소와 문서를 다시 확인해야 한다.
  • 호스팅어 VPS의 KVM2 요금, 1개월·24개월 결제 금액, 데이터센터 선택지는 영상 촬영 시점 기준일 수 있어 현재 가격과 제공 지역을 별도로 검증해야 한다.
  • 영상에서는 Docker 컨테이너 기반 실행이 로컬 메인 노트북보다 안전한 선택지로 설명되지만, 실제 보안 수준은 마운트된 파일, API 키 권한, Discord 봇 권한, 외부 서비스 연동 범위에 따라 달라진다.
  • 자막 기반 정리: 타임스탬프가 있는 자막을 기준으로 정리했으며, 고유명사·수치·인용은 원문 확인 필요 시 별도 검증한다.
  • 영상 속 주장: 발표자의 해석·전망·비교는 확인된 외부 사실이 아니라 영상 속 주장으로 분리해 읽는다.
  • 검증 필요: 수치, 기업 실적, 정책·시장 전망은 발행 전 최신 자료로 별도 검증이 필요하다.

✅ 액션 아이템

  • 설치 전에 실행 위치를 결정한다: 메인 노트북, 전용 서버, 클라우드 VPS 중 개인정보 노출 위험과 비용을 비교한다.
  • VPS에 Hermes Agent를 설치한 뒤 hermes --version, hermes setup, hermes doctor로 기본 설치와 설정 상태를 점검한다.
  • Discord Developer Portal에서 봇을 만들고 Bot Token, Message Content Intent, OAuth2 초대 URL, 메시지·히스토리·채널 보기·파일 첨부 권한을 설정한다.
  • Discord 사용자 ID를 복사해 Hermes 설정의 허용 사용자로 넣고, 홈 채널은 필요하면 /sethome으로 지정한다.

❓ 열린 질문

  • 개인 비서 하나로 충분한가, 아니면 유튜브·개인 업무·사이드 프로젝트·회사 업무를 분리한 멀티프로필 구조가 더 적합한가?
  • Hermes가 자동으로 생성·수정하는 스킬과 메모리는 어느 주기로, 어떤 기준으로 사람이 리뷰해야 하는가?
  • Discord에서 멘션 없이 편하게 쓰는 사용성과 접근 권한을 엄격히 제한하는 보안 사이의 적정 균형은 어디인가?

관련 문서

공통 태그와 주제 흐름을 기준으로 같이 보면 좋은 문서를 이어서 제안합니다.