정적 블로그에 백엔드를 붙일까 — 붙인다면 뭘로 (ADR)

결정 맥락

DB 없는 정적 MDX 블로그가 잘 돌고 있다. 그런데 조회수·댓글·뉴스레터가 필요해졌다. "백엔드를 붙인다"는 되돌리기 어려운 판단 — 대안을 저울질하고 기록으로 남긴다.

첫 번째 발견: "풀세트 = 전부 DB"가 아니다

인증이 들어가는 순간에만 자체 DB가 정당화된다. 그게 분기점이다.

대안 + 트레이드오프

• Supabase: Postgres+Auth+API 단일 벤더. 풀세트 유리. 단 무료 티어는 7일 무요청 시 pause → 저트래픽 개인 사이트에 치명적.
• Turso: libSQL, HTTP 접근이라 서버리스 커넥션 풀 문제 없음, 초저비용. Auth 없음 → 인증 별도.
• Neon: Vercel 마켓플레이스 공식 Postgres. 커넥션 풀링 한 겹 더.
• 조합형: Upstash + giscus + 이메일 서비스. DB·인증 0.

제약

개인 허브 · Vercel 배포 · 하이브리드(글=mdx 유지) · 저비용 · 저트래픽. 저트래픽이 Supabase pause를 실질 리스크로 만든다.

결정 — 2단 전략

1. 기본: 조합형 (Upstash + giscus + 이메일). $0, 약 2일, 자체 DB·RLS·서버 0.
2. 승급: 자체 데이터 소유가 필요해지면 Supabase 단일 벤더로. 처음부터 인증 확정이면 바로 Supabase.

하지 말 것

• 로컬 SQLite .db를 서버리스 배포에 (파일시스템 휘발 → 데이터 소실)
• 글까지 전부 DB로 옮기는 풀 마이그레이션 (SSG·git 이점 상실)
• 코드로 만든 테이블에 RLS 안 켜기 (즉시 유출 위험)

3년 뒤에도 이 결정을 지지하는가: 그렇다. 필요해질 때 승급하는 게, 미리 다 붙이는 것보다 싸다.