🖼️ 인포그래픽

🖼️ 4컷 인포그래픽

💡 한 줄 결론

다섯 개의 Hermes 에이전트를 역할별로 분리하고 사람이 승인하는 흐름으로 연결하면, 아이디어 발굴부터 HTML 캐러셀 제작과 소셜 게시까지 운영하는 AI 콘텐츠 스튜디오를 구축할 수 있다.

📌 핵심 요점

1. 기본 오케스트레이터가 Atlas의 조사, Vera의 집필, Kite의 디자인·개발, Orin의 게시 작업을 연결해 콘텐츠 제작을 하나의 체인으로 만든다.
2. 문구와 최종 게시 단계에는 사람의 승인을 남겨 자동화의 속도를 얻으면서도 브랜드 통제권과 최종 책임은 운영자가 유지한다.
3. 이미지 생성 모델 대신 HTML 템플릿과 헤드리스 브라우저를 사용하면 텍스트·위치·크기·레이아웃을 반복 수정해도 이미지 API 비용이 다시 발생하지 않는다.
4. VPS, 비루트 사용자, 영구 프로필, 분리된 메모리, 역할 경계, SQLite 활동 로그, Telegram 토픽 바인딩이 장기 운영을 위한 기반을 이룬다.
5. Perplexity·ImgBB·Buffer와 비공개 대시보드를 연결하고 실제 Instagram 게시까지 시험하면서 데이터 오염, 지표 오류, 템플릿 식별자 불일치 같은 운영 결함도 수정한다.

🧩 배경과 문제 정의

• 정기적인 소셜 콘텐츠는 아이디어 발굴, 조사, 슬라이드 집필, 디자인, 캡션·해시태그 작성과 게시를 반복해야 하므로 시간과 비용이 많이 든다.
• 네 전문 에이전트와 하나의 오케스트레이터가 과정을 분담하되 문구와 최종 게시에는 사람의 승인을 남겨 자동화와 통제력을 함께 확보한다.
• 이미지 생성 모델은 사소한 수정에도 비용이 다시 들지만 HTML 템플릿은 요소와 문구를 반복해서 수정할 수 있다.
• 에이전트를 상시 운영하려면 개인 PC와 VPS 중 실행 환경을 선택하고 장애와 작업 실수에 대비한 백업 체계도 갖춰야 한다.

🕒 시간순 섹션별 상세정리

1. 아이디어에서 게시까지 이어지는 에이전트 체인

• 콘텐츠 아이디어는 조사·집필·디자인을 거쳐 Instagram 캐러셀로 변환되며, 문구와 최종 게시 단계에는 사람의 승인이 남는다. [00:30]
• Atlas는 조사, Vera는 슬라이드·캡션·해시태그, Kite는 디자인, Orion은 게시를 맡고 오케스트레이터가 Telegram 명령과 브랜드 맥락을 전달한다. [01:43]

2. HTML 템플릿과 통합 운영 화면

• 실제 코드로 만든 HTML 템플릿을 렌더링하므로 텍스트·크기·위치를 바꿔도 슬라이드별 이미지 생성 비용이 추가되지 않는다. [02:18]
• 실행 모델과 시각을 기록하는 데이터베이스, 모바일 미리보기, 편집기, 아카이브, 예약 캘린더와 브랜드 설정이 하나의 대시보드에 연결된다. [03:01]

3. 아이디어 조사와 슬라이드 원고 작성

• Atlas는 브랜드와 게시 이력을 분석해 아직 다루지 않은 아이디어 다섯 개를 만들며 사용자가 입력한 주제도 같은 제작 흐름에 투입한다. [04:27]
• 슬라이드 수와 훅·CTA 구조, Perplexity 심층 조사, 강한 문구 모드를 선택하면 Vera가 원고를 작성하고 추가 지시에 따라 다시 다듬는다. [05:46]

4. 템플릿 선택과 코드 기반 미세 편집

• 사람이 원고를 승인한 뒤 50개가 넘는 템플릿에서 브랜드에 맞는 디자인을 선택한다. [06:18]
• Vera는 레이아웃의 글자 수용량에 맞춰 문장을 줄이고 Kite는 슬라이드를 렌더링하며, Studio에서는 문구·위치·크기·글꼴을 직접 수정할 수 있다. [07:45]

5. 다중 형식 변환과 실제 게시

• 완성된 캐러셀은 4:5 연속 애니메이션이나 9:16 전체 화면 릴로 변환해 하나의 결과물을 여러 형식으로 활용한다. [08:02]
• 사람이 게시 경고를 승인하면 Orion이 Buffer로 Instagram에 전송하며, 에이전트별 실행 수·성공률·히트맵을 확인할 수 있고 자동 설치는 수분 안에 끝난다. [09:34]

6. Hermes 실행 환경 선택

• Hermes Agents는 Telegram·Discord·Slack·WhatsApp을 인터페이스로 사용하고 OpenAI·Anthropic 등 여러 모델을 선택하며 Windows 전용 PC나 Linux에 설치할 수 있다. [10:35]
• 24시간 운영에는 연 약 35달러의 2코어·2GB RAM VPS나 월 약 8달러의 4코어·8GB RAM·100GB SSD VPS가 비용과 성능이 다른 후보로 드러난다. [12:10]

7. VPS 계약 조건과 백업

• 첫 VPS 상품은 기본 하드웨어·RAM·위치 설정을 유지하면 추가 비용을 피할 수 있고 주문 후 접속 자격 증명을 이메일로 받는다. [13:02]
• Contabo는 계약 기간과 지역·저장 장치 선택을 확인해야 하며, 매일 스냅샷을 생성하는 선택형 백업으로 작업 오류 시 약 10일 전 상태까지 복구할 수 있다. [14:59]

8. 접속 정보 확인과 SSH 연결

• Racknet VPS에는 고유 IP 주소, root 사용자명과 루트 비밀번호가 필요하다. [15:43]
• Contabo 비밀번호는 구매 때 설정한 값을 사용하며 Windows PowerShell과 macOS Terminal에서 SSH 지문을 승인하고 비밀번호를 입력하면 접속된다. [17:07]

9. 전용 사용자와 권한 분리

• 최고 권한인 root 계정에 Hermes를 직접 설치하지 않고 애플리케이션 전용 사용자를 만들어 보안 위험을 낮춘다. [18:00]
• adduser와 usermod -aG sudo로 계정을 준비한 뒤 su로 전환하거나 해당 사용자명으로 다시 SSH 접속해 설치를 계속한다. [20:10]

10. 원라인 설치와 Quick Setup

• Hermes 공식 사이트의 curl 원라인 명령은 실행에 필요한 의존성을 함께 설치해 개별 패키지 준비를 줄인다. [20:46]
• 빠른 파일 검색과 TTS 구성 요소를 필요에 따라 추가하고, 불필요한 질문이 많은 Full Setup 대신 Quick Setup으로 핵심 설정을 진행한다. [21:41]

11. Nous 계정과 기본 도구 선택

• VPS의 Hermes를 Nous Research 계정에 연결하며 자체 모델을 사용할 경우 무료 계정으로도 초기 구성을 진행할 수 있다. [22:05]
• 기본 모델 선택은 건너뛰고 검색·웹 수집·이미지·TTS·STT 도구를 필요한 만큼 활성화하며 터미널 백엔드는 현재 VPS에서 실행되는 Local로 유지한다. [23:26]

12. Telegram 봇과 토큰 연결

• 매번 터미널을 열지 않고 에이전트와 대화하도록 메시징 설정에서 Telegram을 선택한다. [23:33]
• 공식 BotFather에서 /newbot을 실행하고 bot으로 끝나는 사용자명을 만든 뒤 발급된 소유권 토큰을 Hermes 설정에 입력한다. [25:23]

13. 사용자 제한과 상시 게이트웨이

• 봇 사용자명을 아는 다른 사람이 접근하지 못하도록 허용 목록을 켜고 UserInfoBot에서 얻은 자신의 Telegram 사용자 ID만 등록한다. [26:05]
• 해당 ID를 홈 채널로 지정하고 Hermes Gateway를 백그라운드 시스템 서비스로 설치하면 재시작 알림을 받고 VPS 재부팅 뒤에도 자동 복구된다. [27:15]

14. 자체 AI 모델과 비용 구조

• 설정 파일이 잘못 변경될 위험을 줄이기 위해 자체 AI 모델 연결은 설치 직후 운영자가 직접 수행하는 방식이 권장된다. [27:31]
• Codex는 ChatGPT Plus·Pro 구독의 고정 한도를 활용하고 Grok과 OpenRouter도 대안이지만, Go 지원 여부는 불확실하며 OpenRouter는 별도 사용량 비용이 발생한다. [29:58]

15. 모델 인증과 성능·사용량 절충

• OpenRouter는 월정액 한도가 아니라 사용량에 따라 비용이 증가하므로 구독 상태와 예상 작업량을 함께 비교해야 한다. [30:05]
• hermes model에서 Codex 인증 URL과 코드를 사용해 연결하고 Linux 복사 단축키에 유의하며, 성능과 토큰 한도를 절충해 GPT-5.5를 기본 모델로 설정한다. [32:16]

16. Hermes와 Telegram 연결 검증

• hermes 터미널 인터페이스에서 메시지 응답을 확인하면 설치와 기본 모델 구성이 정상인지 점검할 수 있다. [33:06]
• BotFather가 제공한 URL로 봇 대화를 시작하고 hi에 입력 표시와 응답이 나타나는지 확인해 Telegram 연결을 검증한다. [34:12]

17. 역할별 Telegram 그룹과 토픽

• 오케스트레이터·개발자·Studio 토픽을 만들기 위해 봇을 Telegram 그룹 구성원으로 추가한다. [34:49]
• 봇에 필요한 관리자 권한을 주고 Topics 기능을 활성화한 뒤 General을 orchestrator로 바꾸고 응답을 확인한다. [36:43]

18. 브랜드와 운영자 맥락 주입

• 최초 봇에 orchestrator라는 이름, 멀티에이전트 최상위 조정자 역할과 운영자의 최종 권한을 명시한다. [38:38]
• 브랜드명·계정·주제·독자·문체·시간대를 입력하고 봇이 Larry와 Computer Mechanic 브랜드 맥락을 되짚는지 확인한다. [39:43]

19. 인터뷰와 영구 운영 규칙

• 10~15개 인터뷰 질문으로 구축 목적과 독자를 더 깊게 학습시킬 수 있지만 튜토리얼에서는 길이를 줄이기 위해 생략한다. [40:15]
• 작업 전 계획과 진행 상황 공유를 영구 규칙으로 두되 모든 계획에 사전 승인을 요구하면 느려질 수 있어 이번 구성에서는 적용하지 않는다. [40:56]

20. 다섯 역할과 지휘 구조 확정

• 기본 오케스트레이터와 아이디어 담당 Atlas, 작성 담당 Vera, 디자인·개발 담당 Kite, 게시 담당 Orin으로 역할을 분리한다. [41:20]
• 기본 오케스트레이터를 중복 생성하지 않고 프로필 매핑을 먼저 확인하며, Cadence 콘텐츠 운영체제의 최종 권한은 운영자에게 둔다. [42:23]

21. 영구 프로필과 역할 문서화

• 일회성 에이전트 대신 기본 오케스트레이터 아래에서 반복 사용할 영구 프로필을 만들고 최상위 지휘권은 하나의 기본 에이전트에 남긴다. [43:24]
• 각 프로필의 SOUL.md에 이름·업무·운영자·작업 시스템을 기록하고 Scout·Scribe·Dev·Rich와 Atlas·Vera·Kite·Orin의 매핑을 확인한다. [44:55]

22. 생성 상태와 메모리 격리

• 프로필 목록에서 기본 오케스트레이터와 네 전문 에이전트가 존재하는지 확인하며 비활성 에이전트의 게이트웨이가 중지된 것은 정상으로 본다. [45:26]
• 하나의 MEMORY.md를 공유하지 않고 에이전트별 폴더·기억·정체성을 분리해 문맥 혼합과 불필요한 토큰 소비를 막는다. [46:21]

23. 역할 경계와 권한 오남용 방지

• Atlas가 개발 요청을 받으면 Kite에게 넘기는 것처럼 에이전트는 담당 범위를 벗어난 일을 거부하거나 적절한 역할로 전달한다. [46:36]
• 동일 권한을 가진 다른 에이전트가 재무 제한을 모르는 위험을 예로 들고, Vera와 Kite의 교차 요청 시험으로 실제 역할 경계가 유지되는지 확인한다. [47:29]

24. SQLite 활동 로그 구축

• 각 에이전트는 완료 응답 전에 이름, 수행 내용, 실행 시각과 사용 모델을 SQLite 실행 테이블에 기록한다. [48:02]
• 대시보드는 이 기록으로 히트맵과 최근 작업을 만들며 운영 규칙 배포 후 다섯 에이전트의 데이터베이스 권한과 로깅 경로를 함께 점검한다. [50:00]

25. 봇 토큰과 토픽 라우팅 설계

• 대시보드 개발은 Kite가 담당하고 별도의 Studio 채널은 콘텐츠 아이디어와 프로모션을 논의하는 공간으로 둔다. [50:22]
• Telegram의 봇당 단일 토큰 구조를 고려해 Kite 전용 두 번째 봇을 선택하고 각 봇이 허용된 토픽만 받도록 필터 플러그인을 요구한다. [52:18]

26. Kite 전용 봇 연결

• BotFather에서 bot으로 끝나는 Kite 사용자명을 만들고 전용 토큰을 발급받는다. [53:54]
• 토큰은 root가 아닌 Hermes 일반 사용자 환경에 저장해야 하며 존재 여부와 활성 상태를 점검해 직접 메시지가 가능한지 확인한다. [55:27]

27. Kite와 Studio 스레드 ID 확보

• Kite 토픽에 첫 메시지를 보내 활성화하고 얻은 고유 스레드 ID를 독점 바인딩 기준으로 사용한다. [56:05]
• Studio 토픽에서도 스레드 ID를 얻되 실제 바인딩 전까지 두 신규 토픽의 응답은 오케스트레이터가 처리한다. [57:02]

28. 그룹·스레드 레인 바인딩

• 그룹 ID와 세 토픽 ID로 오케스트레이터는 자신의 토픽과 Studio를, Kite는 개발 토픽만 수신하도록 접근 레인을 구성한다. [57:41]
• 네 매개변수를 전달해 바인딩을 저장하고 재시작 중 failed to connect to bus가 나오면 오류 전문을 바탕으로 현재 셸 환경에 맞는 명령을 다시 적용한다. [59:59]

29. 게이트웨이와 채널 격리 검증

• 게이트웨이 재시작 직후에는 모든 에이전트가 부팅될 때까지 응답이 늦을 수 있으므로 잠시 기다린 뒤 상태를 다시 확인한다. [1:00:24]
• Kite·Orchestrator·Studio의 신원 응답이 각각 일치하고 서로 다른 채널을 엿듣지 않는지 시험해 바인딩과 격리를 검증한다. [1:02:36]

30. 콘텐츠 스튜디오 전체 구조 설계

• 코딩 전에 Kite에게 프리미엄 콘텐츠 자동화 스튜디오와 웹 제어 화면의 목표·역할 범위를 먼저 전달한다. [1:03:20]
• Atlas 조사, 사용자 승인, Vera 집필, Kite 템플릿 적용과 1080×1350 렌더링, Orin 게시를 연결하고 제공된 템플릿은 변경하지 않는 기준점으로 둔다. [1:04:06]

31. 비공개 대시보드와 SSH 터널

• Python 백엔드는 SSH 로컬 포트 포워딩으로 연결해 VPS 자격 증명이 있는 사용자만 대시보드에 접근하도록 한다. [1:05:07]
• 장기적으로 Tailscale 접근을 계획하며, SSH 터널 뒤 보인 빈 화면은 콘텐츠 부재 때문이고 Python 서버 연결 자체는 성공한 것으로 진단한다. [1:06:32]

32. 업로드 경로와 원본 디자인 보존

• 빈 대시보드를 채우기 위해 HTML 화면과 캐러셀 자료를 받을 웹 업로드 페이지를 추가한다. [1:06:45]
• HTML 하나와 JSON 세 개가 모두 저장됐는지 확인하고 HTML을 전용 폴더의 index.html로 바꾸되 원본 디자인과 이후 실데이터로 교체할 임시 수치를 구분한다. [1:08:30]

33. 시각적 동일성과 누락 파일 복구

• Hermes 헤드리스 브라우저가 화면을 직접 열고 클릭한 뒤 스냅샷을 비교해 원본 템플릿과의 시각적 동일성을 점검한다. [1:09:03]
• 누락된 templates pack을 다시 업로드하고 localhost:8892의 모든 페이지가 원본과 일대일로 일치하는지 확인해 렌더링을 검증한다. [1:10:30]

34. 변경 안전장치와 실제 지표 연결

• 화면 수정 전 대시보드 사본을 저장하고 변경마다 버전 번호를 갱신해 기존 결과물을 잃지 않도록 한다. [1:10:50]
• 하드코딩된 콘텐츠 지표와 히트맵을 실제 활동 로그로 교체했지만 전날 기록이 보이지 않아 조회 범위가 당일로 제한된 문제를 발견한다. [1:12:28]

35. 운영 데이터 오염과 종단간 시험

• 테스트용 Python 서버가 운영 데이터베이스를 삭제하던 결함을 찾아 테스트가 운영 데이터에 접근하지 못하도록 분리한다. [1:13:39]
• 모든 에이전트에 시험 활동을 발생시켜 저장과 화면 반영을 함께 검증했으며 지표는 복구됐지만 업무량 합계가 100이 되지 않는 문제가 남는다. [1:14:57]

36. 워크로드 지표 정상화

• 워크로드 합계를 350%에서 100%로 바로잡아 Kite가 가장 활발하다는 실제 활동 분포를 명확히 드러낸다. [1:15:19]
• 에이전트 로그와 탭별 지표가 정상 작동하자 다른 대시보드 구성요소 개발로 범위를 전환한다. [1:15:29]

37. HTML 캐러셀의 반복 편집 이점

• 이미지 생성 모델과 달리 HTML 슬라이드는 문구 한 줄을 바꿀 때 새 API 호출이나 생성 비용이 필요하지 않다. [1:16:03]
• Fine-tune 화면에서 텍스트·위치·크기·레이아웃을 바꾸고 다시 렌더링해 추가 이미지 API 없이 새 결과물을 만든다. [1:17:55]

38. 헤드리스 브라우저 익스포터

• 완성된 HTML 캐러셀을 헤드리스 브라우저로 캡처해 Instagram과 TikTok에서 사용할 JPEG·PNG 파일로 변환한다. [1:18:23]
• Kite는 Hermes에 포함된 Chromium을 재사용해 익스포터를 구축하고 HTML에서 PNG까지 이어지는 스모크 테스트를 통과시킨다. [1:20:02]

39. 텍스트와 템플릿의 오토핏

• 아이디어를 승격하고 슬라이드 수를 지정하면 Vera가 원문을 작성하고 백엔드가 선택된 HTML 템플릿에 텍스트를 삽입한다. [1:21:15]
• 렌더 엔진은 템플릿의 글자 수와 배치 여유를 분석해 긴 문장을 자동 조정하고 디자인 붕괴를 막는다. [1:22:38]

40. 대시보드 트리거와 제작 규칙

• 버튼을 누르면 코드 트리거가 Atlas·Vera·Kite·Orin에게 작업을 전달하므로 Telegram에서 각 에이전트에게 개별 명령을 내릴 필요가 없다. [1:23:15]
• Atlas와 Vera에는 짧고 쉬운 문장, 과장·유행어 배제, 한 번에 아이디어 네 개라는 규칙을 주고 Post 동작은 소셜 업로드 백엔드에 연결한다. [1:24:16]

41. 선택형 Perplexity 리서치

• 최신 데이터가 필요한 콘텐츠에서는 Atlas가 슬라이드 작성 전에 Perplexity를 조회해 최근 조사 결과를 활용한다. [1:25:36]
• 승격 화면에서 심층 조사를 켜거나 표준 검색·기존 모델 지식을 선택할 수 있으며 Perplexity 콘솔에서 만든 API 키를 조사 기능에 연결한다. [1:27:10]

42. ImgBB와 공통 게시 계층

• 플랫폼별 API를 직접 구축하는 대신 Buffer나 Metricool을 Instagram·TikTok·Facebook 등에 연결되는 공통 게시 계층으로 사용한다. [1:27:51]
• Buffer의 이미지 수신 제약은 ImgBB를 중간 저장소로 해결하며 Metricool API는 테스트 당시 월 약 43달러의 Advanced 요금제가 필요했다. [1:29:59]

43. 게시 플랫폼 비용 비교

• Metricool Starter는 월 16달러로 여러 채널을 추가해도 비용이 늘지 않아 수동 게시 중심의 다계정 운영에 유리하다. [1:30:13]
• Buffer는 낮은 요금제에서도 API를 쓸 수 있지만 채널당 5달러가 들며, 직접 다운로드 게시에는 Metricool이, Cadence 자동 전송과 소수 계정 시험에는 Buffer가 적합하다. [1:31:46]

44. 비밀값 저장과 연결 검증

• Buffer의 My Organization → API → New Key에서 키를 만들면 Perplexity·ImgBB·Buffer 세 서비스를 연결할 준비가 된다. [1:32:07]
• 키는 Telegram이 아니라 PowerShell을 통해 서버 비밀 저장소에 넣고, 입력 위치 오류를 수정한 뒤 세 서비스의 스모크 테스트를 모두 통과시킨다. [1:34:30]

45. 아이디어와 카피 생성 시험

• 개발 프롬프트로 Ideas·Studio·Publish·Templates 탭과 아이디어 생성·작성·렌더링·게시 트리거를 연결한다. [1:34:35]
• Generate Ideas로 Atlas가 아이디어 네 개를 만들고 하나를 10장으로 승격하자 Vera가 조사 자료와 강한 문구 모드를 활용해 전체 슬라이드 카피를 완성한다. [1:36:43]

46. 템플릿 분량 조정과 Studio 편집

• 4:5 Instagram 템플릿을 선택하면 Vera가 고정 문구와 글자 수용량을 읽어 디자인이 깨지지 않도록 슬라이드 문장을 다시 맞춘다. [1:37:11]
• Render Now로 Studio에 옮긴 뒤 Fine-tune에서 표지 문구를 바꾸고 슬라이드 순서를 위아래로 재배치한다. [1:38:14]

47. Buffer 게시와 Publish 화면 복구

• Post Now에서 Instagram을 선택하고 승인하면 캐러셀이 Buffer로 전송되고 작업 상태가 Publish 탭으로 이동한다. [1:39:02]
• 테스트 계정에 이미지와 설명문이 실제 게시됐지만 Publish 화면이 비어 있었고, Kite가 수정한 뒤 콘텐츠 카드가 정상 표시된다. [101:03] [1:39:22]

48. 운영 설정과 Telegram 원격 제어

• Configuration에서 브랜드명·핸들·기본 슬라이드 수·Perplexity 기본값을 바꾸면 이후 생성 작업에 반영된다. [101:21] [1:39:37]
• Studio 채널에서 아이디어 생성과 승격을 시작하도록 원격 제어를 붙였으며 Kite의 재시작 권한 문제는 PowerShell에서 Gateway를 직접 다시 올려 해결한다. [102:43] [1:40:46]

49. Telegram과 웹 대시보드 동기화

• Telegram의 /ideas가 새 아이디어를 만들고 같은 결과가 웹 Ideas 탭에도 즉시 나타난다. [103:10] [1:41:50]
• /promote 11은 Vera 작업을 실행했지만 응답 처리 오류가 발생해 수정했으며, 브레인스토밍은 Telegram에서 하고 템플릿·레이아웃 편집은 Studio에서 마무리하도록 권장한다. [104:59] [1:42:53]

50. 템플릿 식별자 불일치 수정

• statement 입력에서 template not found가 발생해 대시보드 표시명과 Telegram 명령의 허용 식별자가 다르다는 원인을 찾는다. [105:19] [1:45:19]
• isometric은 정상 작동했지만 tip-deck처럼 하이픈 규칙이 필요해 표시명과 명령 입력값을 일치시키는 수정 작업을 Kite에 전달한다. [106:23] [1:45:51]

51. Tailscale 기반 상시 접속

• Tailscale은 매번 SSH 터널 명령과 비밀번호를 입력하는 절차를 계정에 연결된 고유 URL로 대체한다. [107:13] [1:46:04]
• PC·MacBook·모바일에 무료 앱을 설치하고 같은 계정으로 로그인하면 연결된 장치와 서버의 접속 주소를 확인할 수 있다. [109:20] [1:47:08]

52. 비공개 네트워크 제한 검증

• 템플릿 이름 수정을 마친 뒤 Kite에게 개인 기기에서 안전하게 접속할 Tailscale 구성을 요청한다. [110:39] [1:48:12]
• cadence dashboard 장치를 Tailnet에 연결하고 공인 IP 접근 실패와 Tailscale URL 성공을 확인하며 다른 VPN과 충돌할 때는 먼저 중지한다. [112:22] [1:49:41]

53. 제작·발행 통합 대시보드

• 메인 화면은 활동 데이터베이스를 읽고 Ideas 탭은 직접 입력 또는 자동 생성한 주제를 콘텐츠 제작 작업으로 넘긴다. [113:00] [1:49:56]
• promote와 post now가 Studio·소셜 플랫폼·Publish 기록을 연결하며 템플릿, 히트맵, 일정, 브랜드 설정과 문서를 한곳에서 관리한다. [113:49] [1:51:23]

54. 장기 데이터 정리와 재현 가능한 운영

• 활동 로그가 복잡해지는 것을 막기 위해 7일보다 오래된 실행 기록을 매주 삭제하는 정리 작업을 추가할 수 있다. [114:09] [1:52:26]
• 추가 프롬프트로 기능을 확장하고 실제 구축 중 발생한 오류와 해결 흐름을 재사용하면 비슷한 문제를 같은 방식으로 진단할 수 있다. [114:27] [1:53:30]

🧾 결론

• 핵심 성과는 에이전트 수 자체가 아니라 조사·집필·디자인·게시의 책임을 분리하고 오케스트레이터가 순서를 통제하도록 설계한 데 있다.
• HTML 기반 제작 방식은 템플릿의 시각적 일관성을 유지하면서도 사람이 결과물을 세밀하게 고칠 수 있어 생성형 이미지 중심 방식보다 반복 편집에 적합하다.
• Telegram은 아이디어 생성과 원격 명령에 유용하지만, 템플릿 선택과 레이아웃 미세 조정은 웹 Studio에서 마무리하는 역할 분담이 더 안정적이다.
• 실제 운영 수준에 도달하려면 설치뿐 아니라 비밀값 저장, 접근 제한, 백업, 로그 검증, 테스트 데이터 격리와 종단간 게시 확인까지 함께 완료해야 한다.

📈 투자·시사 포인트

• 이미지 API를 반복 호출하는 구조를 HTML 렌더링으로 바꾸면 콘텐츠 수정 횟수가 늘어날수록 변동비를 억제할 수 있다.
• 비용 구조는 VPS와 백업 같은 고정비, AI 모델 구독 또는 사용량 비용, Buffer·Metricool 같은 채널별 게시 비용의 조합으로 결정된다.
• 여러 소셜 API를 직접 통합하는 대신 공통 게시 계층을 사용하면 구축 복잡도는 낮아지지만, 요금제와 API 접근 조건이 운영 확장성에 영향을 준다.
• 역할별 메모리·권한·로그와 비공개 접속을 갖춘 에이전트 시스템은 단순 콘텐츠 생성 도구보다 추적 가능하고 통제 가능한 운영 소프트웨어에 가깝다.

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

• ChatGPT Go 요금제에서 Codex를 Hermes에 연결할 수 있는지는 출처에서도 확실하지 않다고 명시돼 있으므로 실제 계정에서 별도 확인이 필요하다.
• 영상 앞부분에서는 게시 에이전트를 Orion으로, 역할 확정 단계에서는 Orin으로 표기하므로 프로필명·봇명·라우팅 설정에서 사용할 정식 이름을 통일해야 한다.
• VPS 가격, Metricool·Buffer 요금과 API 제공 등급은 출처가 설명한 계약 조건 또는 테스트 당시 기준이므로 구축 시점의 실제 가격과 약관을 다시 확인해야 한다.
• 자막 기반 정리: 타임스탬프가 있는 자막을 기준으로 정리했으며, 고유명사·수치·인용은 원문 확인 필요 시 별도 검증한다.
• 영상 속 주장: 발표자의 해석·전망·비교는 확인된 외부 사실이 아니라 영상 속 주장으로 분리해 읽는다.
• 검증 필요: 수치, 기업 실적, 정책·시장 전망은 발행 전 최신 자료로 별도 검증이 필요하다.

✅ 액션 아이템

• 개인 PC와 VPS 중 가동 시간·성능·비용에 맞는 실행 환경을 선택하고 스냅샷 백업 및 복원 기준을 정한다.
• VPS에서는 root 직접 운영을 피하고 전용 일반 사용자와 필요한 sudo 권한만 구성한다.
• Hermes를 설치한 뒤 모델 제공자, Local 터미널 백엔드, 필요한 검색·이미지·음성 도구만 선택해 기본 응답을 검증한다.
• Telegram 봇을 만들고 사용자 허용 목록, 홈 채널, 토픽별 에이전트 바인딩과 게이트웨이 자동 재시작을 설정한다.

❓ 열린 질문

• 문구 승인과 최종 게시 승인 외에 템플릿 선택이나 외부 조사 실행에도 사람의 승인을 둘 것인가?
• 채널과 에이전트가 늘어날 때 별도 봇 토큰을 계속 추가할 것인가, 토픽 ID를 판별하는 단일 라우터로 전환할 것인가?
• 고정 구독형 Codex와 사용량 기반 OpenRouter 중 예상 작업량에 더 적합한 모델 비용 구조는 무엇인가?