"결과는 있는데, 보여줄 화면이 없습니다"
지난 회를 올리고 사흘쯤 지났을 때, 한 제조업 대표님께서 짧은 메일을 보내오셨습니다. "1000장 디지털화 결과, 저희 현장에서 직접 들여다볼 수 있는 화면이 있을까요?" 답을 적다가 손이 멈췄습니다. 운영 데이터는 분명히 쌓이고 있었지만, 그걸 손쉽게 보여줄 대시보드가 아직 없었기 때문입니다.
OCR 파이프라인은 백엔드 이야기였습니다. 그 앞단 — 결재자가 손가락으로 직접 만지는 화면과 그 뒤의 데이터 흐름을 28일 안에 깎아 올리는 일은 또 다른 호흡입니다. 지난 회 OCR 운영 기록에서 못다 한 두 번째 절반에 해당하는 이야기를 이번 회에 풀어보려 합니다.
왜 Next.js, Supabase, Vercel 세 가지인가
먼저 솔직히 말씀드리면, 세 가지를 묶은 이유는 "유행이라서"가 아닙니다. 4주라는 기간에 풀스택 MVP가 손에 잡힐 만한 구성을 역산하다 보니 이 셋이 남았습니다.
Next.js 14는 2026년 기준 신규 풀스택 프로젝트의 사실상 디폴트입니다. App Router, Server Components, Server Actions, Middleware가 한 프레임워크 안에 묶여 있고, 화면 단(SSR/CSR)과 API 단을 같은 코드베이스로 끝냅니다. 별도의 백엔드 레포·배포 라인을 두지 않는 것만으로도 1주차의 마찰이 한 단계 가벼워집니다.
Supabase는 Postgres 위에 인증·스토리지·실시간이 얹혀 있고, 그 위에 행 수준 보안(RLS)이 기본으로 깔려 있습니다. 핵심은 "그냥 데이터베이스"가 아니라 "권한이 데이터베이스 안에서 결정된다"는 점입니다. 28일이라는 호흡의 두 번째 축입니다.
Vercel은 GitHub 레포 한 줄 연결로 CI/CD가 끝납니다. main 브랜치 push는 곧 프로덕션, 다른 브랜치는 자동 프리뷰 URL이 붙습니다. 별도의 Jenkins·도커·쿠버네티스 설정이 필요 없습니다. 결재자에게 PR 단계에서 "이 URL로 한번 보세요"를 던지는 흐름이 의외로 큰 역할을 합니다.
5ya.io 자체를 깎아 올린 28일
지금 이 글이 올라가 있는 5ya.io 자체도 그렇게 만들어졌습니다. 4개 국어(한·일·영·중) middleware 라우팅, 블로그·외부 매체·프로스펙트 관리 어드민, 컨택트 폼, 이미지 자동 생성 파이프라인 — 한 사람이 4주 안에 깎아 올린 풀스택입니다. 추상적인 자랑이 아니라, 이 사이트의 메뉴 하나하나가 28일이라는 호흡 안에서 무엇이 들어가고 무엇이 빠졌는지의 결과물입니다.
1주차 — 라우팅과 인증의 뼈대
middleware로 ko/ja/en/zh 4개 locale 라우팅을 잡고, Supabase Auth로 어드민 로그인 흐름을 만듭니다. RLS 정책 초안도 이 시점에 함께 그립니다. 화면은 거의 없습니다. 대신 "이후 3주가 흔들리지 않을 골조"를 세우는 시기입니다.
2주차 — 데이터 모델과 RLS
blog, external_posts, prospect_companies, contact_submissions 같은 핵심 테이블을 한 번에 설계합니다. 어드민 권한은 server-side에서 검증하고, 클라이언트 번들에 service_role 키가 절대 들어가지 않도록 환경변수 이름부터 분리합니다. 이 부분에서 며칠 더 쓰는 것이, 운영에 들어간 뒤 한 달치 사고를 막아줍니다.
3주차 — 화면과 프리뷰의 반복
PR 하나마다 Vercel이 자동으로 preview-{sha}.vercel.app 같은 URL을 내보냅니다. 외주 디자이너·기획자에게 "스테이징 빌드 기다리세요"라는 말이 사라진 첫 프로젝트였습니다. 작은 변경 하나하나를 URL로 공유하면서 의사결정 속도가 체감으로 두 배 가까이 빨라집니다.
4주차 — 다국어와 운영 준비
4주차는 늘 "마감되지 않을 것 같은 자잘한 것들"의 모음입니다. SEO 메타, sitemap, OpenGraph 이미지, 에러 페이지, 모니터링, RLS 정책 재점검. 화려하지 않지만 결재자가 사이트를 처음 열어보는 순간의 인상을 좌우합니다.
월 운영 비용 — 실제 숫자로
여기서 결재자의 질문은 거의 같습니다. "그래서 매달 얼마나 나갑니까."
5인 규모 팀이 본격적으로 운영을 시작하면, Vercel Pro는 사용자 1명당 월 20달러로 시작해 트래픽·컴퓨트에 따라 월 100~250달러 구간에서 움직입니다. 대역폭 100GB를 넘어서면 40달러가 추가로 붙는 구조입니다. 트래픽이 폭증하는 캠페인이 없는 일반 운영에서는 200달러를 좀처럼 넘지 않습니다.
Supabase Pro 플랜은 25달러 선에서 시작합니다. PITR(시점 복원) 같은 운영에 꼭 필요한 옵션까지 얹으면 100~200달러 사이로 봅니다. 두 가지를 합쳐 월 환산 30~60만 원 정도가, 일반적인 MVP 1년차의 인프라 고정비라고 보면 크게 빗나가지 않습니다.
한국 외주 시장 기준과 견주면 어떨까요. 위시켓 같은 곳의 최근 데이터를 보면, 간단한 서비스 MVP가 100~300만 원, 복잡도가 올라가면 300~500만 원 이상, API 서버까지 직접 만드는 구성은 1000만 원에서 8000만 원까지도 흩어집니다. Supabase처럼 잘 만들어진 BaaS를 쓰는 경우 백엔드 개발비가 30~50% 정도 줄어든다는 것이 시장 전반의 감각입니다.
Supabase 운영에서 미리 알아둬야 할 세 가지
RLS는 만들어 두면 끝이 아닙니다. 운영을 일 년 가까이 굴려본 입장에서 짚으면, 세 가지가 가장 흔히 발목을 잡습니다.
첫째, 모든 public 스키마 테이블에 RLS를 켜는 것을 기본으로 합니다. 마이그레이션에 정책까지 같이 적어두지 않으면, 어느 순간 누구나 읽을 수 있는 테이블이 한두 개 섞여 들어갑니다. 둘째, service_role 키는 절대로 클라이언트 번들에 들어가서는 안 됩니다. 환경변수 이름부터 분리해두는 편이 안전합니다. 셋째, RLS 정책 안에서 참조되는 컬럼에는 반드시 인덱스를 겁니다. 인덱스를 빠뜨린 RLS는 실제 운영에서 "왜 이렇게 느리지"의 1순위 원인입니다.
세 가지 모두 28일이라는 호흡 안에서 빠뜨리기 가장 쉬운 항목이지만, 운영에 들어간 뒤에는 가장 비싸게 되돌려야 하는 항목입니다.
"이 PR로 한번 들어가 보세요"
Vercel과 GitHub 조합의 진짜 장점은 비용이 아니라 의사결정 속도라고 봅니다.
5ya.io 운영 중 가장 자주 쓰는 흐름이 이렇습니다. 작은 카피 수정, 새로운 블로그 카테고리, 어드민의 새 메뉴 — 무엇이든 브랜치를 따서 PR을 열면 Vercel이 자동으로 프리뷰 URL을 답니다. 의사결정자에게 그 URL을 던지면 30분 안에 "오케이" 또는 "이 줄만 바꿔주세요"가 돌아옵니다. 별도의 스테이징 빌드 큐, 디자이너의 상호 검토 일정, 데모용 배포일 — 이런 마찰이 한꺼번에 사라집니다.
28일이 가능한 사람, 어려운 사람
다만 정직하게 적자면, 28일이 모두에게 가능한 호흡은 아닙니다. 결재자 입장에서 가장 큰 변수는 "기획 결정의 속도"입니다. 코드는 사실 가장 빠른 부분입니다. 매번 회의를 다시 잡고 의사결정이 2주씩 미뤄지면 28일은 56일이 됩니다.
5ya.io를 깎을 때 가장 도움이 된 부분은 "결정을 비동기로 내릴 도구가 이미 들어와 있다"는 점이었습니다. 프리뷰 URL을 슬랙에 던지고, 댓글로 의견을 주고받는 흐름이 자리잡혀 있으면 4주는 충분합니다. 반대로 모든 결정을 대면 회의에서만 한다면, 같은 빌드가 8주로 늘어집니다.
다음 회 예고와 마무리
다음 회는 시선을 살짝 바꿔, 럭셔리 D2C 브랜드가 디지털 빌드에 들어갈 때 결재자가 마주하는 7가지 결정 — 도메인 전략부터 결제, CRM, 재고 동기화까지 — 를 짚어볼 예정입니다. 같은 풀스택 빌드라도, 결재해야 할 항목의 무게가 어떻게 달라지는지가 핵심입니다.
28일 MVP라는 호흡이 자기 회사 아이디어에 맞는지 가늠해보고 싶으시다면, 5years+ 무료 상담으로 한 줄 보내주셔도 좋습니다. 첫 30분은 비용 없이 현재 아이디어의 풀스택 범위 — 어디까지가 28일이고, 어디서부터가 56일인지 — 를 함께 짚어드립니다.