바이브 코딩의 ‘국민스택’ Next.js + Supabase, 그 오해와 진실

Next.js와 Supabase는 많은 바이브 코딩(vibe coding) 도구가 제안하는 ‘국민스택’이지만, 이 조합이 모든 프로젝트에 최적인 것은 아닙니다. 빠른 프로토타입을 만들기에는 이상적이지만, 복잡한 비즈니스 로직이나 트래픽이 몰리면 예상치 못한 비용과 구조적 한계에 부딪힐 수 있습니다. 이 글은 스택 결정의 이면에 숨은 진실을 파헤쳐, 무비판적 수용 대신 맥락에 맞는 현명한 선택을 돕기 위해 작성했습니다.

‘국민스택’은 어떻게 탄생했나: AI 추천의 뇌이미지

최근 몇 년 사이 Claude, Cursor, v0 같은 AI 코딩 도구들은 “Next.js와 Supabase로 시작하세요”라는 조언을 거의 기본값처럼 내놓습니다. 실제로 한 개발자는 레시피 앱을 만들 때 AI가 “Next.js 14의 서버 액션, Supabase 백엔드, Tailwind와 shadcn/ui를 사용하자”고 제안한 사례를 공유했습니다. 이는 초보자도 쉽게 따라 할 수 있는 ‘준비된 길’을 제시하기 때문입니다. 하지만 이는 AI가 방대한 학습 데이터에서 가장 빈번하게 등장하는 패턴을 반복하는 것에 가까우며, 프로젝트의 고유한 요구사항을 반영한 것은 아닙니다.

작동하는 프로토타입이 완성된 앱은 아닙니다: 인식의 함정

비개발자나 이제 막 코딩을 시작한 이들은 기능이 작동하는 프로토타입을 보면 “앱이 완성됐다”고 생각하기 쉽습니다. 로이 데르크스(Roy Derks)가 지적했듯, 바이브 코딩의 가장 큰 문제는 인식입니다. 겉보기에 완벽해 보이는 앱이라도 내부에는 보안 취약점, 확장성 부재, 트랜잭션 처리 미비 같은 프로덕션 결함이 도사리고 있습니다. 예를 들어, 사용자 인증을 Supabase Auth로 간단히 구현했지만 세분화된 접근 제어(RBAC)나 세션 관리는 전혀 고려되지 않은 경우가 허다합니다. 이런 간극은 기술적 안목을 가진 전문가만이 알아챌 수 있습니다.

서버리스 마법의 그늘: 실시간·엣지 함수의 현실적인 비용과 성능

Supabase의 실시간 구독(realtime)이나 엣지 함수(Edge Functions)는 데모 앱을 만드는 데는 환상적입니다. 그러나 동시 접속자가 수백 명을 넘어가면 실시간 구독의 채널 수와 메시지 빈도가 기하급수적으로 늘어나 비용이 급증합니다. 엣지 함수 역시 Deno 기반의 제한된 환경에서 동작하므로, Node.js 생태계의 의존성을 그대로 사용할 수 없는 경우가 많습니다. Supabase 공식 문서조차 “외부 종속성 대신 Web API와 Deno 핵심 API를 사용하라”고 권장할 정도입니다. 복잡한 비즈니스 로직을 처리해야 한다면, 서버리스가 오히려 설계를 왜곡하고 디버깅을 어렵게 만들 수 있습니다.

App Router와 서버 액션: 생산성 뒤에 숨은 높은 허들

Next.js의 App Router와 서버 액션(Server Actions)은 확실히 생산성을 높여줍니다. 하지만 React의 서버 컴포넌트, 클라이언트 경계, 캐싱 전략, 데이터 페칭 패턴은 기존 Next.js 개발자에게도 상당한 학습 곡선을 요구합니다. 8개월간 Next.js와 Supabase로 프로젝트를 완료한 한 개발자는 “Vercel에 배포하고 나니 장기적으로 관리해야 할 부분이 많아졌다”고 토로했습니다. 초기에는 빠르게 진행되더라도, 기능이 추가될수록 서버와 클라이언트의 역할 분담, 에러 바운더리, 배포 파이프라인 최적화 등 유지보수 부담이 커집니다.

벤더 락인과 과금 폭탄: Vercel과 Supabase 의존의 대가

Vercel과 Supabase는 각각 호스팅과 백엔드를 훌륭하게 추상화하지만, 이는 강력한 벤더 락인으로 이어집니다. 예를 들어, Vercel의 엣지 함수는 자체 런타임을 쓰고, Supabase의 스토리지나 실시간 API는 마이그레이션을 극도로 까다롭게 만듭니다. 트래픽이 예상보다 조금만 늘어도 서버리스 함수 실행 횟수 제한이나 데이터베이스 커넥션 풀 한계에 부딪혀 과금 폭탄을 맞는 사례가 빈번합니다. 실제로 “Vercel에서 $500 요금 청구를 받았다”는 커뮤니티의 하소연을 어렵지 않게 찾을 수 있습니다.

현명한 바이브 코더로 거듭나기: 대안 스택과 프롬프트 설계

진정한 ‘바이브 코딩’의 가치는 빠른 실험에 있습니다. 따라서 프로젝트의 성격에 따라 스택을 유연하게 선택하는 지혜가 필요합니다. 예를 들어, 오프라인 우선 앱이라면 SQLite나 PouchDB 같은 로컬 퍼스트 도구를, 간단한 API 서버라면 Hono나 Fastify를 고려할 수 있습니다. 또한 AI에게 프롬프트를 던질 때 “간단한 프로토타입용이므로 Next.js+Supabase를 사용하되, 나중에 PostgreSQL 직접 연결로 바꿀 수 있도록 추상화 계층을 둬줘”와 같은 지시를 추가하면 초기부터 확장성을 확보할 수 있습니다. 결국 도구의 장단점을 이해하고 비판적으로 수용하는 태도가 중요합니다.

마무리하며

Next.js와 Supabase는 분명 강력한 도구이지만, 모든 상황을 해결해주는 마법의 지팡이는 아닙니다. 바이브 코딩의 흐름 속에서도 우리는 기술의 본질을 꿰뚫어 보는 안목을 길러야 합니다. 프로토타입 너머를 상상하고, 팀과 함께 코드를 리뷰하며 숨은 결함을 찾아내는 과정이야말로 진짜 제품을 만드는 길입니다. 이런 협업과 이력 관리를 위해 md-log 같은 휴먼 인 더 루프 리뷰 도구를 활용해 보시는 것도 좋은 방법입니다. 결국 스택은 프로젝트의 목적을 실현하는 수단일 뿐, 우리를 이끄는 주인이 되어서는 안 됩니다.

참고 자료

• 내 앱 다 만들었어 (Next.js + Supabase). Vercel, 장기적으로 ...
• You're Vibe Coding Wrong (And It's Not Your Fault)
• Supabase for Vibe Coders
• The illusion of a complete app: the problem with vibe coding | Roy Derks posted on the topic | LinkedIn