정적 사이트 호스팅 아키텍처 선택 (Self-Host vs CDN)
Key Insight
“노트북/서버를 켜 두어야 사이트가 뜬다”는 구조(Self-Host + Reverse Tunnel)와 “빌드 결과물만 올리면 그 뒤로는 소스 머신과 무관하게 떠 있다”는 구조(CDN 배포)는 겉보기엔 비슷해 보여도 가용성 보장 범위가 근본적으로 다르다.
Overview
개인 컴퓨터의 콘텐츠를 웹사이트로 공개하는 방법은 크게 두 갈래다:
- Self-Host + Reverse Tunnel: 로컬 머신에 웹 서버(Caddy, nginx 등)를 띄우고, Cloudflare Tunnel 같은 리버스 프록시로 외부에 노출. 로컬 머신이 곧 origin 서버.
- 정적 빌드 + CDN 배포: 콘텐츠를 정적 파일(HTML/CSS/JS)로 빌드해 Cloudflare Pages, Netlify, Vercel, GitHub Pages 같은 CDN에 업로드. 로컬 머신은 “빌드/배포 시점”에만 필요하고, 이후 서빙은 CDN이 전담.
Details
언제 Self-Host + Tunnel이 부족한가
Self-Host 구조는 다음 조건에서 정상 동작한다: 로컬 머신 전원 On, 웹 서버 프로세스 실행 중, tunnel 프로세스 실행 중, 인터넷 연결 유지. 이 중 하나라도 깨지면 사이트 전체가 다운된다. 실제로 다음 3단계 장애가 순차적으로 나타났다 (출처: 2026-07-31-ai-research-Osync-셀프호스팅-04_GuWiki-동기화):
- cloudflared를 수동 프로세스로 실행 → 터미널 세션 종료 시 다운
- Windows 작업 스케줄러로 로그온 시 자동 실행 → 재부팅에는 대응했지만, 노트북이 꺼져 있거나 자동 생성된 CLI 창을 사용자가 닫으면 여전히 다운 (Cloudflare Error 1033 재현)
- → 근본 해결은 아키텍처 자체를 CDN 배포로 바꾸는 것뿐이었음
즉, Self-Host + Tunnel의 가용성 문제는 점진적 자동화(재시작 루프, 재부팅 트리거)로는 완전히 해소되지 않는다 — 원인이 “로컬 머신이 origin”이라는 구조 자체에 있기 때문이다.
언제 CDN 배포가 적합한가
- 콘텐츠가 정적으로 빌드 가능(Obsidian → Quartz 같은 정적 사이트 생성기, 또는 그냥 HTML/Markdown)
- 실시간 서버 사이드 로직이 불필요 (인증은 CDN의 Edge Function/미들웨어로 대체 가능 — 예: Cloudflare Pages Functions)
- “소스가 갱신되면 재배포”만 하면 충분하고, 상시 라이브 연결(WebSocket 등)이 필요 없음
트레이드오프
| 항목 | Self-Host + Tunnel | 정적 빌드 + CDN |
|---|---|---|
| 로컬 머신 꺼짐 시 | 사이트 다운 | 영향 없음 (최신 배포 상태 유지) |
| 실시간 서버 로직 | 자유로움 | 제한적 (Edge Function 필요) |
| 초기 설정 복잡도 | 상대적으로 단순 (서버 하나) | 빌드 파이프라인 + 배포 자동화 필요 |
| 비용 | 없음(로컬 자원) | 대부분 무료 티어로 충분(Cloudflare Pages) |
| 콘텐츠 갱신 반영 속도 | 즉시(파일 저장) | 재빌드+재배포 주기에 종속 |
Related
- Obsidian 볼트를 Cloudflare Pages로 웹 발행하기 — 이 개념을 적용한 실제 구축 가이드
- MOC-TAB 프로젝트
Sources
- 2026-07-31-ai-research-Osync-셀프호스팅-04_GuWiki-동기화 — 실제로 Self-Host+Tunnel의 3단계 장애를 겪고 CDN으로 전환한 세션 기록
Open Questions
Open Question
실시간성이 필요한 콘텐츠(예: 라이브 대시보드)를 CDN 배포 구조에서 어떻게 다뤄야 하는지는 이번 사례에서 다루지 않았다 — Cloudflare Workers/D1 같은 조합이 필요할 것으로 추정되나 미검증.
Bias Check
Counter-argument: 이 비교는 “가용성”만 축으로 삼았다 — 보안 격리, 데이터 주권(자체 서버 vs 제3자 CDN), 비정형 워크로드(대용량 파일, 스트리밍) 같은 다른 축에서는 결론이 달라질 수 있다. Data gap: 단 하나의 사례(04_GuWiki → turboairbrain.uk)에서 관찰된 패턴이며, 다른 CDN 제공자나 다른 정적 사이트 생성기로 일반화되는지는 추가 검증 필요.