"1주일 만에 랜딩페이지를 만들어 첫날 12.5% 전환을 얻었다." 한 인디 파운더가 dev.to에 공유한 이 사례는 AI 프로토타이핑이 가진 진짜 힘을 보여준다. 아이디어를 6개월이 아닌 7일 만에 시장에 던져 보는 것—이 흐름 자체는 옳다. 문제는 그 다음이다. 검증이 끝난 프로토타입을 그대로 프로덕션으로 밀어 넣는 순간, 완전히 다른 게임이 시작된다.
숫자가 먼저 말한다
보안 리서치 업체 Escape.tech가 2025년 10월 공개 배포된 Lovable·Bolt.new·Cursor 앱 5,600개를 스캔한 결과, 취약점 2,000건 이상, 노출된 시크릿 400건 이상, 의료 기록·계좌 번호를 포함한 개인 정보 노출 175건이 발견됐다. 별도로 Tenzai가 5개 AI 코딩 도구로 동일한 테스트 앱 15개를 만들어 분석했더니 69개 취약점이 나왔고, 15개 앱 중 CSRF 보호를 갖춘 것은 단 하나도 없었다. 로그인 레이트 리미팅? 제로. Content Security Policy 헤더? 역시 제로. 이건 특수한 사례가 아니라 AI 코딩 도구의 기본 출력값이다.
가장 위험한 구멍: RLS 미설정
Lovable이나 Bolt.new로 만든 앱 대부분은 Supabase를 백엔드로 쓴다. Supabase 자체는 훌륭한 제품이다. 문제는 AI가 앱과 데이터베이스 사이의 연결을 생성할 때, Supabase가 요구하는 보안 레이어—Row Level Security(RLS)—를 자동으로 설정하지 않는다는 점이다. RLS가 없으면 Supabase URL을 아는 사람은 누구나 데이터베이스 전체를 직접 쿼리할 수 있다. 이론이 아니라 실제로.
2025년 5월, 한 보안 연구자가 Lovable 쇼케이스 앱 1,645개를 스캔했을 때 170개(10.3%)에서 RLS 치명적 결함이 발견됐다(CVE-2025-48757, CVSS 8.26). 노출된 데이터에는 이름·이메일·전화번호·집 주소·금융 정보가 포함됐다. 더 극단적인 사례는 AI 소셜 네트워크 Moltbook이다. 창업자가 직접 "코드를 한 줄도 쓰지 않았다"고 밝힌 이 플랫폼은 2026년 1월 Wiz Research에 의해 클라이언트 사이드 JavaScript에 Supabase API 키가 노출되고 RLS가 완전히 비활성화된 상태로 발견됐다. 결과: OpenAI·Anthropic·AWS·Google Cloud 토큰 150만 건, 이메일 3만 5천 건, 비공개 메시지 4천 건, DB 레코드 475만 건 유출. Supabase CISO Bill Harmer는 공개적으로 "RLS는 단순하고 강력하지만 너무 자주 무시된다"고 말했다.
로그인 화면이 있다고 인증이 있는 게 아니다
두 번째 패턴은 인증이다. 대부분의 바이브 코딩 앱에 로그인 화면은 있다. 없는 것은 인증 집행 레이어다. 토큰 갱신 로직, 서버 사이드 검증, 자동화 공격 방어—이것들이 빠진 상태에서 로그인 화면은 잠금장치 없는 문에 불과하다. Bright Security의 동적 보안 테스트(2025년 11월) 결과 주요 AI 도구 4개가 생성한 포럼 앱 전체에서 사용자 가장 공격을 가능하게 하는 인증 결함, 접근 제어 부재, 레이트 리미팅 없음이 공통으로 발견됐다. 한 SaaS 창업자는 Cursor로 전체 제품을 빌드하고 배포한 지 72시간 만에 사용자들이 브라우저 콘솔에서 값 하나를 바꿔 결제 제한을 우회했다고 밝혔다. 그는 공개적으로 서비스 종료를 선언하며 이렇게 썼다. "보안이 없는 코드를 프로덕션에 배포하지 말았어야 했다."
프로토타입 비용이 '무료'처럼 보이는 함정
보안 문제만이 아니다. dev.to에 게재된 또 다른 분석은 유지비용 함정을 날카롭게 짚는다. 주말에 바이브 코딩으로 내부 CRM을 만들었다고 하자. 팀원들이 쓰기 시작한다. 영업팀은 승인 워크플로우를 원하고, 마케팅은 대시보드를 요청하고, 누군가는 이메일 연동을 원한다. 요청이 쌓인다. 그 프로덕트의 PM이 된 사람은 원래 그 역할을 맡은 게 아니었다.
비용을 수치로 보면 더 명확해진다. HubSpot Starter는 영업 10명 기준 연 최대 1만 2천 달러다. 중간 규모 시장 엔지니어의 완전 부담 비용은 연 12만~18만 달러. 그 엔지니어가 바이브 코딩한 내부 도구 유지보수에 25%만 써도 연 3만~4만 5천 달러가 나간다. HubSpot보다 2~3배 비싼 셈이다. 기능이 추가될수록 이 비율은 계속 올라간다.
그럼 언제 빌드하고, 언제 멈춰야 하나
'빠르게 만들어 검증하는' 흐름 자체를 부정하는 것이 아니다. 오히려 그 흐름은 유효하다. 핵심은 전환 기준이다. 프로토타입을 프로덕션으로 올리기 전, 세 관문을 통과해야 한다.
첫째, 보안 감사. Supabase를 쓴다면 RLS 설정이 첫 번째 체크포인트다. Supabase는 바이브 코더를 위한 보안 체크리스트와 RLS 정책 생성 전용 AI 프롬프트를 공식 제공하고 있다. 그 다음은 API 키가 클라이언트 코드에 노출되어 있는지 확인하고, 인증 흐름에 서버 사이드 검증이 실제로 있는지 검토한다. 도구의 내장 스태틱 스캐너를 믿지 말 것. Bright Security 연구에서 한 도구의 내부 스캐너는 동적 테스트에서 치명적 결함 4건이 발견된 동일한 코드베이스를 '취약점 없음'으로 리포트했다.
둘째, 아키텍처 결정. 보안 픽스가 가능한지, 리팩토링이 필요한지, 다시 만들어야 하는지를 판단해야 한다. AI가 생성한 코드는 구조적으로 유지보수가 어렵게 짜이는 경향이 있다. 에러가 발생하면 AI는 근본 원인을 찾지 않고 표면 증상을 반복 수정하는 패턴을 보인다. Lovable 앱에서 문서화된 사례처럼, 동일한 버그를 AI가 6번 수정 시도하면서 매번 로딩 상태만 건드렸고 비동기 콜백 문제는 끝까지 찾지 못한 경우도 있다.
셋째, 소유권 질문. 이 도구를 팀이 지속적으로 소유할 수 있는가? 실제 사용자 데이터가 흐르는가? 핵심 비즈니스 로직인가? 세 질문 중 하나라도 '예스'라면, 프로토타입 코드 위에 기능을 쌓는 것이 아니라 처음부터 제대로 만들거나 검증된 솔루션을 구매하는 것을 진지하게 고민해야 한다.
빠른 실험은 계속하되, 경계를 설계하라
AI 코딩 도구는 프로토타이핑 레이어에서 진짜 위력을 발휘한다. 7일 만에 랜딩페이지를 만들어 시장 반응을 확인하는 것—이 접근법은 유효하고 권장할 만하다. 하지만 그 검증이 성공했을 때, 프로토타입을 그대로 프로덕션으로 승격시키는 것은 설계가 아닌 도박이다. 보안 취약점은 배포 직후가 아니라 스케일이 커진 후에 터진다. 그때는 이미 실사용자 데이터가 위험에 노출된 뒤다.
빠름의 가치는 인정하되, 그 빠름이 어디서 멈춰야 하는지를 미리 설계해두는 것—그것이 지금 AI 프로토타이핑 시대에 개발자와 파운더 모두에게 요구되는 진짜 역량이다.