Founders & Indie Hackers: MVP 콘텐츠를 모두 데이터베이스에 넣는 것을 멈추세요

Source: Dev.to

OCR Trips 만들기: 가벼운 MVP 접근법

저는 OCR Trips를 만들고 있습니다 – 사용자가 다음과 같은 일을 할 수 있게 도와주는 장애물 코스 레이스 여행 플래너입니다:

• 레이스 찾기
• 여행 계획하기
• 항공편, 호텔, 레이스 참가비를 한 곳에서 예산 잡기

“앱” 부분(계정 및 여행 계획)은 Supabase에서 실행됩니다. 🏄 하지만 MVP 콘텐츠에 대해서는 모든 것을 데이터베이스에 넣고 싶지 않았습니다.

원래 아이디어

사용자가 알고 있는 레이스를 직접 추가하도록 했습니다. 목표는 가벼운 여행 플래너로, 다음 OCR을 입력하면 항공편, 호텔, 예산을 도와주는 것이었습니다.

범위 확대

아직 레이스가 없고 찾는 데 도움이 필요한 사람은 어떨까요?
저는 Obstacle Course Race Calendar라는 공개 디렉터리를 추가했습니다 – 누구나 다음을 할 수 있습니다:

• 국가와 도시별 장애물 코스 레이스 탐색
• 인근 공항 및 대략적인 여행 아이디어 확인
• 레이스 날짜별 일반적인 날씨 확인
• 브랜드, 거리 등으로 필터링

왜 Supabase 테이블을 사용하지 않을까?

첫 번째 생각: “쉽다. Supabase에 races 테이블을 만들고 관리자 UI를 구축한다.”
두 번째 생각: 정말 Supabase에 넣고 싶을까?

플랫 파일 솔루션

races 테이블 대신 데이터를 MDX 파일로 저장했습니다:

content/races/
├── spartan/
│   └── 2026/
│       ├── paris.mdx
│       └── london.mdx
├── tough-mudder/
│   └── 2025/
│       └── atlanta.mdx
└── ... 200+ files

각 파일에는 front‑matter + MDX(브랜드, 날짜, 위치, 거리, 좌표, 지형, 설명)가 들어 있습니다.
Velite는 빌드 시 이 파일들을 읽고, 검증하고, Next.js에서 가져올 수 있는 타입이 지정된 데이터셋을 제공합니다.

데이터베이스를 건너뛰는 장점 (현재 기준)

• 레이스 필드가 바뀔 때마다 마이그레이션이 필요 없음
• 콘텐츠 편집을 위한 커스텀 관리자 패널이 필요 없음
• 개발/스테이징/프로덕션용 시드 스크립트가 필요 없음
• 환경 간 스키마 드리프트가 없음
• 정적 페이지가 될 수 있는 페이지에서 “DB에 연결할 수 없음” 같은 런타임 버그가 없음

MVP에서는 피해야 할 영역이 많이 줄어듭니다.

플랫 파일 워크플로우

1. .mdx 파일을 편집
2. 변경 사항을 커밋
3. Vercel이 재빌드 → /races가 최신 상태가 됨

배포가 바로 출판이 됩니다.

Velite가 파일을 “데이터베이스처럼” 느끼게 하는 방법

빌드 시에:

• Zod/TS 스키마에 맞춰 콘텐츠 검증
• TypeScript 타입 생성
• 가져와서 필터링할 수 있는 배열 출력

import { races } from "@/content/generated";

const frenchSpartan = races.filter(
  (race) =>
    race.brand === "spartan" &&
    race.country === "France"
);

여전히 얻을 수 있는 것:

• 필터링
• 검색
• 타입이 지정된 필드
• 에디터 자동 완성

파일을 넘어선 확장

“하지만 이걸 넘어서면 어떻게 하지?”

파일로 시작하는 것이 함정은 아닙니다. /races에 다음과 같은 요구가 생기면:

• 비기술 편집자 필요
• 배포 없이 실시간 업데이트 필요
• 매우 복잡한 쿼리 필요

…다음과 같이 진행할 수 있습니다:

1. Supabase에 races 테이블 생성
2. MDX 파일을 읽어 DB에 삽입하는 일회성 스크립트 작성
3. import { races }를 await db.query.races로 교체

초기 선택(파일)은 나중 선택(데이터베이스)을 막지 않으며, 지금 더 빠르게 배포할 수 있게 해줍니다.

창업자와 인디 해커를 위한 조언

다음과 같이 바로 시작하기 전에:

• 모든 것을 SQL로 모델링
• 관리자 UI 구축
• “콘텐츠” 관리를 위한 폼 연결

스스로에게 물어보세요:

• 사용자가 실제로 이곳에 글을 쓰게 될까?
• 내용이 자주 바뀔까?
• 지금 바로 쿼리 도구가 필요할까?

답이 **“그렇지 않다”**면 다음 스택을 시도해 보세요:

• Git에 파일 저장
• 스키마 레이어(Velite 등)
• 정적 생성

나중에 데이터베이스로 마이그레이션할 수는 있지만, 반드시 그렇게 해야 할 필요는 없을 수도 있습니다.