바이브코딩 앱이 계속 털리는 진짜 이유 — 배포 전 RLS 체크리스트

핵심 요약 (TL;DR)

바이브코딩 앱이 사용자 데이터를 흘리는 핵심 원인은 도구가 아니라 '기본값'입니다. Supabase 테이블을 AI나 SQL로 생성하면 Row-Level Security(RLS)가 기본 비활성이라, 앱에 박힌 public anon key로 로그인 없이 테이블을 통째로 덤프할 수 있습니다. 보안업체 RedAccess는 수천 개 앱을 스캔해 5,000개가 사실상 인증이 없고 그중 40%가 민감정보를 노출했다고 주장했습니다(벤더 측 반박 있음). 5분이면 막을 수 있는 문제입니다.

"한 줄도 안 짜고 만들었다"의 청구서

바이브코딩으로 앱을 만들어 실제 배포까지 해보셨다면, 이 글은 축하가 아니라 경고로 읽으셔야 합니다. 배포 버튼을 누른 그 순간, 누군가 당신의 데이터베이스를 로그인 없이 열어보고 있을지도 모르니까요.

이건 특정 개발자의 실수담이 아닙니다. 구조적인 문제죠. 보안 기업 RedAccess(CEO Dor Zvi)는 공개 배포된 바이브코딩 앱을 대량 스캔한 결과, 5,000개가 인증이 사실상 전무했고 그중 40%가 의료·금융·기업 문서·비공개 챗봇 로그 같은 민감정보를 노출하고 있었다고 밝혔습니다(futurism.com). 다만 이 5,000·40% 수치는 보안업체의 자체 스캔 주장이고, Lovable·Base44 등 일부 플랫폼은 검증 자료가 부족하다며 반박하고 있다는 점은 함께 기억해 두시죠.

한 가지 더 중요한 맥락. 이 이슈는 '어제 터진 신규 사건'이 아닙니다. 관련 수치 대부분은 2026년 2월부터 5월 사이 스캔이고, 이번 주에 커뮤니티에서 다시 불붙은 진행형 문제입니다. 바꿔 말하면, 몇 달째 반복되는데도 여전히 안 고쳐지고 있다는 뜻이죠.

왜 하필 Supabase에서 이런 일이 반복되나

원인은 의외로 단순합니다. Supabase 테이블을 대시보드 Table Editor로 만들면 RLS가 켜져 있지만, AI 에이전트나 SQL로 생성하면 RLS가 기본 비활성입니다. 바이브코딩은 정확히 후자죠. AI에게 "이런 테이블 만들어줘"라고 하면 SQL이 실행되고, 그 테이블은 문이 활짝 열린 채 세상에 나옵니다.

RLS가 꺼진 테이블은 클라이언트에 노출된 public anon key만 있으면 누구나 조회할 수 있습니다. 이 키는 원래 공개용이라 앱 소스에 그대로 박혀 있죠. 앱을 열어본 사람이라면 누구든 당신의 사용자 테이블 전체를 내려받을 수 있다는 의미입니다.

실제 피해 규모도 확인됐습니다. CVE-2025-48757 건에서는 Lovable 쇼케이스 앱 1,645개 중 170개(10.3%)가 치명적 RLS 실패로 분류됐습니다(이 CVE는 현재 벤더 이의제기 상태). 2월엔 조회수 10만이 넘던 교육 앱 하나에서 취약점 16개가 발견돼 약 18,000명의 정보가 노출됐고요(The Register 보도 참고). '5분이면 켤 수 있는 것'을 아무도 안 켠 결과입니다.

배포 전 RLS 체크리스트 5개

지금 배포된 앱이 있다면, 아래를 순서대로 점검해 보세요.

1. 모든 테이블에 RLS가 켜져 있는가. Supabase 대시보드의 Table Editor에서 각 테이블 옆 'RLS disabled' 표시가 없는지 확인합니다.
2. RLS를 켰다면, 정책(policy)도 만들었는가. RLS만 켜고 정책이 없으면 아무도 접근 못 하거나, 반대로 정책이 허술하면 그대로 뚫립니다.
3. public anon key로 접근 가능한 테이블에 민감정보가 없는가.
4. AI로 테이블을 추가할 때마다 RLS 상태를 재확인하는가. 새 테이블은 또 기본 비활성으로 태어납니다.
5. 배포 전 익명 요청으로 실제 덤프가 되는지 직접 테스트했는가.

SQL로는 이렇게 켭니다.

-- 1) 테이블에 RLS 활성화
alter table public.profiles enable row level security;

-- 2) 본인 데이터만 조회 가능하도록 정책 추가
create policy "본인 행만 조회"
  on public.profiles
  for select
  using (auth.uid() = user_id);

AI 에이전트를 쓰신다면 프롬프트에 못을 박아두는 것도 방법입니다. "테이블을 만들 때마다 반드시 RLS를 활성화하고, auth.uid() 기반 정책을 함께 생성해줘. 정책 없이 RLS만 켜지 마." 기본값이 위험하다면, 그 기본값을 바꾸라고 시키면 되는 거죠.

'나도 바이브코딩 해봐야 하나'의 설렘 반대편에는 반드시 이 체크리스트가 붙어 있어야 합니다. 만드는 속도가 빨라진 만큼, 새는 속도도 빨라졌으니까요.

자주 묻는 질문 (FAQ)

Q. RLS만 켜면 안전한가요?
아닙니다. RLS는 스위치일 뿐이고, 실제 접근 제어는 정책(policy)이 합니다. RLS를 켜고 정책을 안 만들면 접근이 막히거나, 정책이 느슨하면 여전히 노출됩니다. 둘은 항상 세트입니다.

Q. public anon key가 소스에 노출돼도 괜찮은가요?
anon key 자체는 공개되도록 설계된 키입니다. 문제는 그 키로 접근하는 테이블에 RLS와 정책이 제대로 걸려 있느냐입니다. 방어선은 키가 아니라 RLS입니다.

Q. 이미 배포한 앱, 지금이라도 고치면 되나요?
됩니다. 다만 이미 노출됐던 데이터가 수집됐을 가능성은 되돌릴 수 없으므로, RLS 적용과 함께 민감정보 유출 여부 점검, 필요 시 키 로테이션까지 함께 진행하시길 권합니다.