$6.6B 바이브코딩 플랫폼 Lovable, 두 건의 보안 사고가 드러낸 구조적 허점
핵심 요약 (TL;DR)
$6.6B 밸류에이션의 바이브코딩 플랫폼 Lovable에서 두 달 간격으로 보안 사고 두 건이 터졌습니다. 2월에는 Lovable로 만든 앱에서 18,697명의 데이터가 노출됐고, 4월에는 플랫폼 자체의 BOLA 취약점이 48일간 방치됐습니다. "만들기 쉬운 시대"의 이면입니다.
빠르게 만드는 건 좋습니다. 문제는 빠르게 만든 것이 빠르게 뚫릴 때 시작됩니다.
$6.6B 밸류에이션의 Lovable에서 두 달 사이 보안 사고가 연달아 터졌습니다. 그리고 이 두 사건은 바이브코딩 생태계의 서로 다른 약점을 정확히 찌르고 있습니다.
사건 1: Lovable로 만든 앱이 뚫렸다 (2월)
보안 연구원이자 테크 기업가인 Taimur Khan이 발견한 건 Lovable로 만들어진 EdTech 앱의 취약점이었습니다. 총 16개의 보안 결함. 그 결과 18,697명의 사용자 데이터가 노출됐고, 그중에는 UC Berkeley와 UC Davis 학생 4,538명의 정보도 포함돼 있었습니다.
핵심은 이겁니다 — 취약점이 개별 앱에 있었지만, 그 앱을 만든 플랫폼의 기본 보안 설정이 부실했기 때문에 가능한 사고였다는 것. Supabase 기반의 인증 구조에서 기본값이 안전하지 않았던 거거든요.
사건 2: Lovable 플랫폼 자체가 뚫렸다 (4월)
두 번째 사건은 더 심각합니다. 익명의 보안 연구원이 Lovable 플랫폼 자체에서 BOLA(Broken Object-Level Authorization) 취약점을 발견했습니다. 무료 계정으로 다른 사용자의 프로필, 공개 프로젝트, 소스코드, DB 인증정보에 접근할 수 있었습니다. API 호출 5번이면 충분했거든요.
2026년 3월 3일 HackerOne에 보고됐지만, Lovable은 처음에 "의도된 동작"이라며 부인했습니다. 이후 "문서 문제"로 책임을 전가하다가, 48일이 지난 4월 20일에야 공개. 신규 프로젝트만 패치하고 기존 프로젝트는 방치한 채로요. Nvidia, Microsoft, Uber, Spotify 직원들의 프로젝트도 영향권 안에 있었습니다.
두 사건이 말해주는 것
이 두 사건은 바이브코딩의 보안 문제가 이중 구조라는 걸 보여줍니다. 첫째, 플랫폼이 만들어주는 앱의 기본 보안이 허술합니다. 둘째, 그 앱을 만들어주는 플랫폼 자체의 보안도 허술합니다.
바이브코더에게 이건 불편한 진실입니다. "코드를 몰라도 만들 수 있다"는 건 동시에 "코드를 모르니 뭐가 뚫리는지도 모른다"는 뜻이거든요. 보안은 기능과 달리 프롬프트로 "추가해줘"라고 말할 수 있는 영역이 아닙니다.
바이브코더가 지금 할 수 있는 것
Lovable이나 유사 플랫폼을 쓰고 있다면, 최소한 이것만은 확인해보세요. Supabase RLS(Row Level Security)가 활성화돼 있는지, API 엔드포인트에 인증이 걸려 있는지, 환경 변수가 클라이언트에 노출되지 않는지. 프롬프트 한 줄로 앱을 만들 수 있는 시대에, 보안 체크리스트 한 장은 필수 비용입니다.
FAQ
Q: Lovable로 이미 만든 앱이 있다면 어떻게 해야 하나요?
Supabase 대시보드에서 RLS 정책을 확인하고, API 엔드포인트의 인증 설정을 점검하세요. Lovable이 기존 프로젝트를 자동으로 패치하지 않았으므로 직접 확인이 필요합니다.
Q: 다른 바이브코딩 플랫폼도 같은 문제가 있나요?
정도의 차이는 있지만, 바이브코딩으로 만든 앱의 보안 취약점은 플랫폼 공통 과제입니다. 어떤 플랫폼을 쓰든 보안 설정은 별도로 검증해야 합니다.
관련 글 추천
- 매일 쓰는 Cursor와 Claude Code에 RCE 취약점 — MCP 보안의 민낯
- AI 도구 하나가 Vercel을 뚫었다 — 바이브코더가 지금 당장 점검해야 할 것들
- 보안 사고가 터져도 Meta가 인수했다 — Moltbook이 증명한 바이브코딩의 역설
댓글 0
아직 댓글이 없습니다