🖼️ 인포그래픽

🖼️ 4컷 인포그래픽

💡 한 줄 결론

Hermes Agent와 $6 VPS 조합은 Vercel·Railway 같은 managed platform의 일부 역할을 작은 Git·Markdown 기반 웹앱 운영에서는 대체할 수 있지만, 인증·데이터·트래픽 리스크가 커지는 영역에서는 관리형 플랫폼의 가치가 여전히 크다.

📌 핵심 요점

1. AI 코딩 도구로 웹앱을 만들 때 Supabase, Railway, Vercel 조합이 빠른 출발점이 되지만, 여러 서비스를 함께 쓰면 비용과 운영 단위가 늘어난다.
2. Agent Wikis는 데이터베이스와 build step 없이 Markdown 파일과 Git을 데이터베이스·CMS·배포 흐름처럼 사용하며, 서버는 요청마다 디스크의 Markdown을 렌더링한다.
3. Hermes Agent는 25GB storage, 1 vCPU, 1GB RAM VPS 안에서 Agent Wikis tenant를 운영하고, Caddy가 TLS와 reverse proxy를 맡으며 Telegram을 통해 원격 운영 명령을 받을 수 있다.
4. 콘텐츠 갱신은 cron, scout, research agent, Telegram 승인 gate, lint, commit으로 이어지며, Git 기반 구조 덕분에 재시작 없이 사이트가 최신 내용을 읽는 흐름으로 설계된다.
5. demand loop는 원문 prompt나 개인 식별 정보를 저장하지 않고 반복되는 검색 실패를 aggregate 지식 gap으로 모아, research·작성 backlog와 공개 문서 업데이트로 환류한다.

🧩 배경과 문제 정의

• AI 코딩 도구로 웹사이트나 웹앱을 만들기 시작하면 Supabase, Railway, Vercel 같은 managed platform 조합이 자연스럽게 추천되지만, 여러 서비스를 함께 붙이는 순간 비용·운영·배포 단위가 늘어난다.
• 발표자는 작은 VPS 하나와 Hermes Agent를 조합하면 프런트엔드 배포, 콘텐츠 갱신, 간단한 백엔드·데이터 관리, 운영 자동화까지 한 환경 안에 모을 수 있다고 설명한다.
• managed platform은 편의성과 위험 완화가 강점이지만, markdown·Git 중심 사이트나 작은 앱에서는 VPS와 agent workflow가 상당 부분을 대체할 수 있다는 문제의식이 깔려 있다.
• 사례로 제시되는 Agent Wikis는 데이터베이스 없는 Git 기반 사이트에서 출발해, 정기 갱신 루프, 수요 기반 지식 gap 수집, Telegram 승인 gate, 브랜치·diff 확인까지 포함하는 agentic 운영 모델로 확장된다.
• 다만 단일 VPS 자동화가 모든 managed platform을 완전히 대체한다는 주장이라기보다, 인증·보안·credentials처럼 실패 비용이 큰 영역은 더 견고한 관리형 구성이 필요하다는 한계를 함께 짚는다.

🕒 시간순 섹션별 상세정리

1. AI 코딩 배포 스택을 VPS와 Hermes로 대체하는 문제의식

• AI 코딩 도구로 웹사이트나 웹앱 배포를 시작하면 Claude나 Codex가 Supabase, Railway, Vercel 같은 플랫폼을 자주 권하고, 초보자에게는 이 조합이 빠른 출발점이 된다. [00:07]
• 발표자는 작은 VPS 하나와 Hermes Agent 하나가 앱 콘텐츠 관리와 비즈니스 운영까지 맡으면, 여러 managed platform에 흩어진 핵심 기능을 단일 운영 환경으로 모을 수 있다고 문제를 제기한다. [00:22]

2. Agent Wikis의 Git 기반 구조와 데이터베이스 없는 설계

• Agent Wikis는 데이터베이스와 build step이 없고, markdown file 중심 구조라 Git이 실제 database 역할을 맡는다. [03:24]
• 공개 wiki는 Hermes Agent, Hyperframes, ComfyUI 등 여러 folder의 markdown file로 나뉘며, 각 wiki가 별도 database table 대신 file 묶음으로 존재한다. [03:45]

3. 단일 VPS tenant 운영과 Caddy·Telegram 접속 구조

• Agent Wikis는 별도 server를 갖지 않고, 이미 Hermes Agent가 돌고 있는 25GB storage, 1 vCPU, 1GB RAM VPS의 tenant로 올라간다. [04:37]
• Hermes Agent는 Telegram에 연결된 항상 켜진 작업자라서 PC나 laptop을 열어두지 않아도 원격 명령과 운영 작업을 계속 받을 수 있다. [05:00]

4. 정기 갱신 루프와 Telegram 승인 gate

• 콘텐츠 유지 루프는 multi-agent·multi-profile pipeline을 Agent Wikis에 맞게 변형한 구조이고, cron이 scout와 research agent를 깨워 release, source, changelog, feature, community note 변화를 확인한다. [06:28]
• Hermes Agent wiki 같은 항목은 새 version, changelog 변경, 주요 feature, community note를 후보로 모으고, duplicate를 제거한 뒤 새 page나 기존 page 수정 가치가 있는지 research한다. [07:12]

5. 수요 기반 지식 gap 수집과 개인정보 최소화

• demand loop는 wiki 안에서 답을 찾지 못한 질문을 지식 gap으로 취급하고, agent가 찾아낸 보완 정보를 바탕으로 빠진 내용을 채우려는 흐름이다. [08:24]
• 목표는 개인 prompt를 읽지 않고 agent들이 실제로 요구하는 topic을 파악해, 반복되는 gap을 knowledge base 보강 입력으로 자동 환류하는 것이다. [08:51]

6. 반복 miss를 연구·작성 backlog로 전환하는 운영 흐름

• 반복 miss는 scout format candidate로 바뀌고, research agent가 실제 조사 대상과 page 후보를 만들며 release 검색 대신 demand data가 source 역할을 한다. [09:44]
• 이후 plan은 신규 entry, 기존 page edit, page versus extend 판단으로 갈라지고, human gate가 research 방향과 승인 여부를 정한다. [10:07]

7. 수요 격차 감지와 승인 게이트

• KB intake에서 최근 1주일 동안 같은 주제나 키워드가 최소 두 번 이상 등장한 항목만 수요 격차로 잡히며, 발견된 5개 항목은 모두 100점 만점에 88점으로 통과한다. [12:01]
• 파이프라인은 5개 item 파일과 15개 child card를 만들고, intake card 완료 뒤 리서치를 시작하며, 진행 상태는 Telegram과 VPS 에이전트의 Kanban 보드로 확인된다. [12:22]

8. 문서 업데이트와 lint 검증 흐름

• 업데이트 대상은 messaging gateway.md이며, webhook route rate limit 답변을 추가하기 전에 기존 문서에서 rate 관련 항목이 있는지 검색해 중복과 충돌 가능성을 확인한다. [14:00]
• 기존 문서에는 migrate rate limit과 code expiration 관련 언급만 있고 webhook route rate limit 답변은 부족하므로, 새 답변이 실제 사이트의 지식 공백을 채우는 변경이 된다. [14:16]

9. 브랜치 커밋, diff 확인, 라이브 사이트 반영

• 완료된 변경은 에이전트의 clone 버전과 별도 브랜치에 커밋되며, main 병합 여부는 인간이 diff를 확인한 뒤 결정한다. [15:21]
• 최종 인간 게이트는 원래 제안 승인과 병합 전 diff 확인 두 단계이고, 신뢰가 쌓이면 마지막 병합 단계까지 자동화할 수 있지만 초기 운영에서는 사람이 루프 안에 남아 있다. [16:11]

10. VPS 자동화의 적합 범위와 다음 확장 과제

• 이 workflow의 핵심은 VPS 위 에이전트가 사이트 운영, 업데이트, lint, 정보 최신화를 대부분 자율적으로 처리해 wiki가 스스로 진화하고 정제되는 구조를 만드는 데 있다. [17:24]
• 단일 VPS는 유용하지만 password reset, OAuth failure mode, 실제 credentials 처리처럼 인증과 보안 리스크가 큰 영역에서는 더 견고한 관리형 구성이 필요하다. [17:50]

11. 단일 VPS를 넘어 managed 서비스가 필요한 경우

• 잃으면 안 되거나 규제가 필요한 데이터는 로컬 백업과 GitHub만으로는 부족할 수 있어 managed Postgres, 예를 들면 Railway 같은 선택지가 필요하다고 본다. [18:21]
• 글로벌·바이럴 트래픽에는 Vercel과 Cloudflare 같은 더 고급 배포·엣지 옵션이 적합할 수 있다. [18:30]
• 이메일 발송은 self-hosted SMTP가 스팸으로 갈 수 있어 Postmark나 Resend 같은 서비스를 쓰는 편이 낫다. [18:38]
• 팀 단위 속도와 preview deploy가 필요하면 Vercel과 Railway 조합이 좋고, 특히 실제 credentials를 다루는 인증 영역은 breach를 피하도록 더 안전하게 처리해야 한다. [19:04]

12. 첫 번째 VPS 에이전트 데모 정리와 다음 편 예고

• 이번 영상에서는 데이터베이스가 필요 없는 웹앱을 대상으로, 에이전트가 사이트를 자율적으로 유지·관리하는 여러 loop를 보여줬다. [19:18]
• 이 방식은 Vercel, Supabase, Railway 없이도 같은 VPS에서 웹앱을 운영하고 유지하는 흐름이라는 점이 핵심이었다. [19:22]
• 다음 영상에서는 초반에 언급했던 game app처럼 데이터베이스가 필요한 사이트를 같은 VPS와 Admiral 위에 실제로 배포하는 과정을 다룰 예정이다. [19:53]
• 시청자에게 이 workflow를 자신의 앱이나 사이트에 어떻게 적용하고 싶은지 댓글로 의견을 남겨 달라고 요청하며 영상을 마무리한다. [20:08]

🧾 결론

• 이 영상의 핵심은 “작고 단순한 웹앱이나 문서형 사이트라면 managed platform 조합 대신 VPS와 Hermes Agent 기반 운영도 현실적인 선택지가 될 수 있다”는 주장이다.
• 특히 Markdown·Git 중심의 wiki, docs, blog, marketing page처럼 데이터베이스 요구가 낮은 서비스에서는 Git이 데이터 저장소, 변경 이력, 배포 파이프라인 역할을 동시에 맡을 수 있다.
• Hermes Agent가 VPS 내부 파일과 운영 컨텍스트에 직접 접근하고, Telegram 승인 gate를 통해 사람의 개입 지점을 줄이면 콘텐츠 유지보수와 지식베이스 갱신을 상당 부분 자동화할 수 있다.
• 다만 password reset, OAuth failure mode, 실제 credentials 처리, 잃어버리면 안 되는 데이터, 규제 대상 데이터처럼 보안·신뢰성이 중요한 영역은 managed Postgres나 더 견고한 관리형 구성이 적합하다고 선을 긋는다.
• 제목의 “$6 VPS” 비용 표현은 영상 제목의 주장으로 확인되지만, 실제 VPS 요금제·지역·성능·트래픽 조건은 별도 검증이 필요하다.

📈 투자·시사 포인트

• 소규모 AI 서비스와 콘텐츠형 웹앱에서는 “managed platform을 많이 붙이는 방식”보다 “작은 VPS 위에 agentic workflow를 얹는 방식”이 비용 효율적 대안이 될 수 있다.
• Vercel, Railway, Supabase 같은 플랫폼의 강점은 여전히 편의성, 협업, preview deploy, 인증·DB·스토리지 관리, 트래픽 대응에 있으므로, VPS 자동화가 모든 사용 사례를 대체한다고 보기는 어렵다.
• Git·Markdown 기반 지식베이스, docs, wiki, developer content 운영에서는 agent가 반복 miss를 감지하고 문서를 갱신하는 구조가 콘텐츠 품질 유지 비용을 낮출 가능성이 있다.
• 개인정보를 줄이는 aggregate demand loop는 사용자 질문 데이터를 직접 수집하지 않고도 지식 공백을 개선하려는 접근으로, AI 검색·문서 서비스 운영에서 중요한 설계 방향을 보여준다.
• 투자 관점에서는 “AI agent가 배포·문서화·운영까지 맡는 초소형 인프라”와 “관리형 플랫폼의 안정성·확장성”이 서로 경쟁하면서도 사용 규모와 리스크에 따라 공존할 가능성이 크다.

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

• $6 VPS 하나로 Vercel·Railway·Supabase 조합을 대체할 수 있다는 주장은 영상의 Agent Wikis 사례에는 적용되지만, 인증, 결제, 사용자 데이터, 대규모 트래픽이 있는 일반 웹앱까지 그대로 확장 가능한지는 별도 검증이 필요하다.
• 영상에서 언급된 VPS 사양인 25GB storage, 1 vCPU, 1GB RAM이 실제로 어느 정도 동시 접속, 검색 인덱스 크기, agent 작업량까지 감당하는지는 transcript만으로는 확인할 수 없다.
• demand loop에서 원문 prompt, IP, identity를 저장하지 않고 distilled query와 aggregate miss만 남긴다는 설명은 설계 의도로 제시되지만, 실제 구현 코드와 로그 보존 정책이 그렇게 되어 있는지는 별도 확인이 필요하다.
• 자막 기반 정리: 타임스탬프가 있는 자막을 기준으로 정리했으며, 고유명사·수치·인용은 원문 확인 필요 시 별도 검증한다.
• 영상 속 주장: 발표자의 해석·전망·비교는 확인된 외부 사실이 아니라 영상 속 주장으로 분리해 읽는다.
• 검증 필요: 수치, 기업 실적, 정책·시장 전망은 발행 전 최신 자료로 별도 검증이 필요하다.

✅ 액션 아이템

• 현재 운영하려는 사이트가 markdown·Git 중심 구조로 충분한지, 아니면 Postgres·auth·storage 같은 managed service가 필요한지 먼저 분류한다.
• Vercel, Railway, Supabase 등 기존 managed platform 사용 비용과 실제로 쓰는 기능을 목록화해 VPS로 대체 가능한 영역을 구분한다.
• VPS에 올릴 경우 Caddy 또는 유사 reverse proxy, TLS, workspace 권한, Git clone 위치, agent 접근 범위를 명확히 설계한다.
• 문서·wiki·블로그형 사이트라면 Git을 database, CMS, deploy pipeline으로 쓰는 구조를 소규모로 먼저 검증한다.

❓ 열린 질문

• 어떤 종류의 웹앱까지 Git·markdown·VPS 중심 구조로 충분하고, 어느 시점부터 managed database나 managed auth가 필수가 되는가?
• Agent가 직접 파일과 Git repository를 수정하는 구조에서 최소 권한은 어디까지로 제한해야 안전한가?
• Telegram 승인 gate는 제안 승인과 merge 전 diff 확인 두 단계가 적절한가, 아니면 신뢰가 쌓이면 어느 단계까지 자동화해도 되는가?