Supabase는 바이브 코딩의 함정이다 Image: AI generated

30초의 마법

“백엔드 만들어줘.” AI가 Supabase를 추천한다. URL 하나로 PostgreSQL, 인증, 스토리지, 실시간 구독이 붙는다. 30초 만에 로그인이 돌아간다. 2분이면 CRUD가 완성된다.

3개월 뒤, 누가 이 RLS(Row Level Security) 정책을 썼는지 아무도 모른다.

AI가 추천하는 이유

Supabase가 바이브 코딩의 기본 선택지가 된 건 기술적 우월성 때문이 아니다. 훈련 데이터에 튜토리얼이 많아서다.

Cursor, Bolt, v0, Lovable — 어떤 AI 코딩 도구든 “백엔드 만들어줘"를 입력하면 Supabase가 나온다. AI는 가장 많이 본 패턴을 추천한다. 가장 좋은 패턴이 아니라.

Zhang et al.(ACL 2025)은 7개 LLM이 명시적 지시 없이 특정 제공자를 체계적으로 선호하며, 입력 코드를 자율적으로 수정해 선호 제공자를 삽입하는 현상을 실증했다. 사용자는 AI가 추천한 것이 최선이라고 믿는다. AI는 훈련 데이터에서 가장 빈번한 것을 추천한다. 이것이 아첨 편향의 인프라 버전이다.

블랙박스에 로직을 숨기면

Supabase의 진짜 문제는 Supabase 자체가 아니다. 비즈니스 로직이 블랙박스 안으로 들어가는 것이 문제다.

1. RLS 정책 = 숨겨진 비즈니스 로직

Row Level Security는 강력한 기능이다. 문제는 AI가 RLS 정책을 생성하면 그것이 어디에 사는가다.

  • 코드에 없다. Supabase 대시보드에 있다.
  • git에 없다. 버전 관리가 안 된다.
  • 테스트에 없다. CI에서 검증이 안 된다.

“이 테이블에 누가 접근할 수 있는가?“라는 질문의 답이 코드베이스에 존재하지 않는다. Supabase 콘솔에 로그인해야 확인할 수 있다. 에이전트는 이것을 읽을 수 없다.

AI가 “정리"를 위해 RLS 정책을 수정하면? 인증이 뚫린다. 테스트가 없으니 아무도 모른다. 프로덕션에서 고객 데이터가 노출된 뒤에야 발견된다.

이것은 가설이 아니다. 2025년 CVE-2025-48757에서 Lovable로 생성된 170개 이상의 앱이 RLS 누락으로 Supabase 데이터베이스 전체가 노출됐다. 303개 취약 엔드포인트, 이메일, API 키, 결제 정보가 유출됐다. 2026년 1월에는 AI 소셜 네트워크 Moltbook이 RLS 비활성화 상태로 배포되어 150만 API 토큰과 35,000개 이메일이 노출됐다.

2. Edge Functions = 두 번째 블랙박스

비즈니스 로직이 두 곳에 산다. 프론트엔드 코드와 Supabase Edge Functions. 어떤 로직이 어디에 있는지 AI가 판단해야 한다. AI는 이 판단을 틀린다.

결제 할인 계산이 Edge Function에 있다. AI가 프론트엔드를 리팩토링하면서 같은 계산을 프론트엔드에 다시 만든다. 이제 할인이 두 번 적용된다. 3주 뒤 매출 보고서에서 발견된다.

3. 마이그레이션 = 탈출 비용

Supabase를 떠나려면 네 가지를 동시에 뜯어내야 한다:

  1. Auth — Supabase Auth에 묶인 JWT 구조, OAuth 콜백, 세션 관리
  2. Storage — 버킷 구조, 접근 정책, URL 서명
  3. Realtime — WebSocket 구독, Presence 채널
  4. RLS 정책 — 문서화되지 않은 비즈니스 규칙 전부

각각은 하루면 되는 것 같지만, 네 개가 서로 얽혀 있다. Auth가 바뀌면 RLS가 깨지고, RLS가 깨지면 Storage 접근이 풀리고, Storage URL이 바뀌면 프론트엔드가 깨진다.

이것이 vendor lock-in이다. 들어가는 건 30초, 나오는 건 3개월.

포트 지옥의 클라우드 버전

바이브 코더가 로컬에서 겪는 포트 지옥 — AI가 서버를 띄우고, 죽이지 않고, 포트가 꼬이고, 뭐가 돌아가는지 모르는 상태 — 이것이 Supabase에서는 인프라 레벨로 올라간다.

로컬 포트 지옥: 프로세스가 보이지 않는다. Supabase 지옥: 비즈니스 로직이 보이지 않는다.

둘 다 같은 구조다. 에이전트가 만든 것을 에이전트가 추적하지 못한다.

대안은 무엇인가

Supabase를 쓰지 말라는 게 아니다. 비즈니스 로직을 블랙박스에 넣지 말라는 것이다.

원칙: 모든 결정은 코드베이스에 살아야 한다.

  • 인증 규칙 → 코드로 선언, 테스트로 검증
  • 접근 정책 → DDL + Rego로 선언, CI에서 검증
  • 비즈니스 로직 → 한 곳에만 존재, 중복 없음
  • 인프라 설정 → Terraform/IaC로 선언, git에 버전 관리

Supabase를 프로토타이핑에 쓰는 건 합리적이다. 하지만 프로토타입을 프로덕션으로 가져가는 순간, 블랙박스 안의 로직을 꺼내서 선언적 레이어로 옮겨야 한다.

30초의 마법을 3개월의 고통으로 바꾸지 않으려면.

당신의 RLS 정책은 git에 있는가?

당신의 Edge Function은 테스트가 있는가?

AI가 “정리"하면 인증이 뚫리지 않는다고 확신하는가?

Supabase가 문제가 아니다. 보이지 않는 곳에 결정을 숨기는 것이 문제다.

관련 글

출처

  • Zhang, Y. et al. (2025). “The Invisible Hand: Unveiling Provider Bias in Large Language Models for Code Generation.” ACL 2025. arxiv.org/abs/2501.07849
  • CVE-2025-48757 (2025). Lovable 생성 앱 170+ RLS 누락으로 Supabase DB 노출. ameeba.com
  • OG William (2026). “Moltbook Hack: Supabase Vibe Coding.” 1.5M API 토큰 + 35K 이메일 노출. blog.ogwilliam.com
  • Willison, S. (2025). “Supabase MCP can leak your entire SQL database.” simonwillison.net
  • Cursino, D. et al. (2026). “Speed at the Cost of Quality? The Impact of AI Coding on Software.” MSR 2026. arxiv.org/abs/2511.04427
  • Storey, M.-A. (2026). “From Technical Debt to Cognitive and Intent Debt.” arxiv.org/abs/2603.22106
  • Encore (2026). “Backend as a Service (BaaS) in 2026: Providers, Tradeoffs, and Migration Paths.” encore.dev