5,600개 앱을 뜯어봤더니 — 바이브코딩의 진짜 비용은 보안 부채였다
핵심 요약 (TL;DR)
Escape.tech가 Lovable, Bolt.new, Create.xyz 등에서 만들어진 5,600개 바이브코딩 앱을 보안 감사한 결과, 2,000개 이상의 고위험 취약점, 400개 이상의 API 키 노출, 175건의 개인정보 유출을 발견했습니다. 바이브코딩이 만들어낸 보안 부채의 규모가 처음으로 숫자로 드러났습니다.
5,600개 — 바이브코딩 보안의 첫 대규모 진단
Lovable로 앱을 만들고 Supabase로 백엔드를 붙여서 배포까지 마쳤다면, 한 가지 질문을 던져볼 때입니다. "보안 설정, 직접 확인해보셨나요?"
프랑스 사이버보안 스타트업 Escape.tech가 바이브코딩 앱 5,600개를 수집하고, 14,600개 자산(앱, API, 호스트, 스키마)을 스캔했습니다. $18M 시리즈A를 유치한 AI 기반 공격 표면 관리 전문 기업의 체계적인 감사였습니다.
결과는 충격적이었습니다.
숫자가 말해주는 현실
- 2,000개 이상의 고위험 취약점 발견
- 400개 이상의 시크릿(API 키, 토큰)이 프론트엔드 번들에 그대로 노출
- 175건의 개인정보 — 의료 기록, IBAN 계좌번호, 전화번호, 이메일이 외부에서 접근 가능한 상태
스캔 대상의 약 71%가 Lovable로 만들어진 앱이었는데, 핵심 원인은 Lovable-Supabase 통합 시 Row-Level Security(RLS) 정책이 기본값 그대로 배포된 데 있었습니다.
RLS는 데이터베이스 테이블에 "누가 어떤 행을 읽고 쓸 수 있는지"를 정의하는 보안 규칙입니다. 이걸 설정하지 않으면 — 말 그대로 문을 열어둔 채 외출하는 것과 같습니다.
왜 이런 일이 반복될까?
바이브코딩의 본질적인 구조 때문입니다. AI가 기능 구현에는 놀라울 정도로 유능하지만, 보안 설정은 "요청하지 않으면 해주지 않는" 영역이거든요. 비개발자 바이브코더가 RLS 정책이 뭔지 모르는 건 당연합니다. 문제는, AI도 알아서 챙겨주지 않는다는 겁니다.
이전에 다뤘던 18,697명의 데이터가 노출된 사고도 같은 맥락이었습니다. 개별 사고가 아니라 구조적 패턴인 거죠.
Escape.tech의 감사는 샘플 편향(Lovable 앱이 71%)이 있고, 자사 제품 홍보 성격도 있습니다. 하지만 방법론이 투명하게 공개되어 있고, 패시브 모드(실제 공격 없이 스캔)만 사용했다는 점에서 데이터의 방향성은 신뢰할 수 있습니다.
바이브코더를 위한 보안 체크리스트
바이브코딩으로 앱을 만들었다면, 배포 전에 최소한 이것만은 확인해보세요.
- Supabase RLS 정책: 모든 테이블에 RLS가 활성화되어 있는지, 그리고 적절한 정책이 설정되어 있는지
- 프론트엔드 소스 코드: 브라우저 개발자 도구로 번들을 열어 API 키나 시크릿이 노출되어 있지 않은지
- 환경 변수 분리: 민감한 키는 반드시 서버 사이드에서만 사용하도록 분리했는지
바이브코딩이 만드는 속도를 혁신했다면, 이제 안전의 속도도 따라가야 할 차례입니다. 빠르게 만드는 것과 안전하게 만드는 것 — 이 둘 사이의 간극을 좁히는 것이 바이브코딩 생태계의 다음 과제 아닐까요?
FAQ
Lovable로 만든 앱은 전부 취약한 건가요?
전부는 아닙니다. RLS 정책을 직접 설정한 앱은 안전할 수 있습니다. 문제는 기본값 상태로 배포된 앱들이며, 이 비율이 높았다는 것이 이번 감사의 핵심 발견입니다.
AI에게 "보안도 챙겨줘"라고 프롬프트하면 되지 않나요?
도움이 되지만 충분하지 않습니다. AI가 생성하는 보안 설정도 검증이 필요하고, RLS처럼 플랫폼별 설정은 코드 밖에서 직접 확인해야 하는 경우가 많습니다.
내 앱이 취약한지 어떻게 확인할 수 있나요?
Supabase 대시보드에서 각 테이블의 RLS 상태를 확인하고, 브라우저 개발자 도구(F12)의 Sources 탭에서 번들 파일 내 API 키 노출 여부를 검사하는 것이 첫 단계입니다.
댓글 0
아직 댓글이 없습니다