Lovable 앱 15만여 개 분석 정리: Supabase 키와 .env 점검법

3줄 요약

• Lovable로 만든 프로젝트 159,041개를 분석한 조사에서 로그인 없이 프로필, 채팅 메시지, 여권 번호 같은 민감 데이터에 접근할 수 있는 앱이 확인됐습니다 ^[2].
• 저장소에 올라간 .env 파일 속 Supabase 공개 키 자체는 대개 문제가 아니며, 핵심은 테이블에 접근 규칙(RLS)이 있는지입니다 ^[1].
• 이름이 sb_secret_로 시작하거나 service_role로 표시된 비밀 키가 코드나 VITE_ 변수에 들어갔다면 실제 유출이므로 키를 교체해야 합니다 ^[1].

무엇이 나왔나

GeekNews가 소개한 조사에 따르면, Crissy Field가 독일 경제지 Handelsblatt와 함께 Common Crawl 데이터셋에서 2025년 12월~2026년 9월 사이 Lovable 프로젝트 159,041개를 찾아 분석했습니다 ^[2]. Lovable은 자연어 설명을 웹 앱으로 바꿔 주는 스웨덴의 AI 개발 플랫폼입니다 ^[2].

이 가운데 34,545개가 Supabase(오픈소스 백엔드·데이터베이스 서비스)를 썼고, 24,664개는 로그인 같은 동작 없이 첫 화면을 여는 것만으로 데이터베이스 레코드를 내려보냈습니다 ^[2]. 같은 API 키로 읽기 전용 요청을 더 보내 보니 7,403개 사이트, 10,560개 테이블에서 이메일 주소가 담긴 레코드가 나왔습니다 ^[2].

구체적인 사례도 공개됐습니다. 독일의 한 라이프스타일 포럼에서는 8만 개가 넘는 프로필과 20만 건 이상의 채팅 메시지가, 한 서비스 업체에서는 여권 번호·만료일·국적이 담긴 레코드 1,000건 이상이 열려 있었다고 합니다 ^[2]. 행사 주최사와 음식점의 결제·티켓 정보, 부동산 관리 회사의 내부 이메일 AI 요약도 포함됐습니다 ^[2]. 다만 실제 악용 여부는 확인되지 않았습니다 ^[2].

조사팀은 Lovable의 데이터베이스 연동 방식이 앱마다 비슷하기 때문에, 한 앱에서 통한 접근법이 다른 앱에도 쉽게 적용될 수 있다고 지적했습니다 ^[2].

어떻게 써먹나

1. .env 파일부터 겁먹지 않기

DEV Community 글의 작성자는 자신이 만든 점검 도구가 Lovable 앱의 .env 파일을 위험 신호로 잘못 판단한 경험을 소개합니다 ^[1]. 이 파일에는 보통 프로젝트 주소, VITE_SUPABASE_PUBLISHABLE_KEY 또는 VITE_SUPABASE_ANON_KEY, 프로젝트 id 정도가 들어 있습니다 ^[1]. VITE_ 접두사가 붙은 값은 빌드 과정에서 브라우저용 코드에 그대로 포함되므로, 방문자는 이미 그 값을 볼 수 있습니다 ^[1]. 또 publishable 키는 Supabase가 공개해도 된다고 안내하는 종류이고, anon 키는 그 이전 버전입니다 ^[1].

2. 키 종류 구분하기

• 새 방식: sb_publishable_로 시작하면 공개 키, sb_secret_로 시작하면 비밀 키입니다 ^[1].
• 예전 방식: 둘 다 eyJ로 시작하는 긴 문자열이며, 대시보드에서 anon은 공개용, service_role은 비밀용입니다 ^[1].

비밀 키는 모든 접근 규칙을 건너뛰므로 서버에만 둬야 합니다 ^[1]. 저장소의 .env, VITE_로 시작하는 변수(커밋하지 않았더라도), 과거 커밋 기록 중 어디에라도 있다면 유출로 봐야 합니다 ^[1]. 파일을 지워도 Git 히스토리에는 남는다는 점을 기억해야 합니다 ^[1]. AI 서비스나 이메일 서비스 같은 유료 API 키도 마찬가지입니다 ^[1].

3. 테이블 규칙 확인하기

공개 키는 데이터베이스로 들어가는 문을 열 뿐이고, 들어온 사람이 무엇을 할 수 있는지는 Row Level Security(RLS, 행 단위 접근 규칙)가 정합니다 ^[1]. 규칙 없는 테이블은 공개 키만으로 읽고 바꿀 수 있는 경우가 많습니다 ^[1]. 출처에 소개된 조회 쿼리를 Supabase SQL 편집기에서 실행하면 됩니다(읽기만 합니다) ^[1].

-- Supabase SQL 편집기에서 실행 (읽기 전용)
select schemaname, tablename, rowsecurity
from pg_tables
where schemaname = 'public' -- public 스키마만
order by tablename;

결과에서 rowsecurity 값이 false인 테이블은 규칙이 전혀 없는 상태로, .env 파일보다 훨씬 우선해서 손봐야 합니다 ^[1].

4. 비밀 키가 노출됐다면 교체하기

먼저 코드에서 키를 빼서 새 키가 같은 경로로 새지 않게 하고, 대시보드에서 새 키를 발급해 서버에 적용한 뒤 기존 키를 비활성화합니다 ^[1]. Supabase는 이 과정을 키 로테이션이라고 부릅니다 ^[1].

주의할 점

• 조사에서 나온 30%라는 비율은 확정된 유출률이 아닙니다. 이메일이 공개 연락처나 테스트 데이터일 수 있고, 표본도 전체 Lovable 앱을 대표하지 않습니다 ^[2]. 반대로 일부만 내려받았기 때문에 실제 노출 규모는 더 클 수 있습니다 ^[2].
• 2025년 말 추가된 Lovable 자체 데이터베이스 기능은 이번 조사 대상이 아니었으며, 비슷한 설정 오류가 있을 수 있다고만 언급됐습니다 ^[2].
• Lovable 이용약관은 앱과 데이터 처리 책임을 고객에게 둡니다 ^[2]. 플랫폼이 보안까지 알아서 해 준다고 기대하면 안 됩니다.
• Supabase는 예전 anon·service_role 키를 2026년 말까지 단계적으로 없앤다고 밝혔으므로, 새 키 체계로의 전환이 필요합니다 ^[1].
• 자동 점검에서 문제가 나오지 않았다고 앱이 안전하다는 뜻은 아니라고 ^[1]의 작성자도 밝히고 있습니다 ^[1].

정리

바이브코딩으로 만든 앱에서 진짜 위험은 공개 키가 보이는 것이 아니라, 그 키로 무엇이든 할 수 있게 열려 있는 테이블입니다 ^[1]. 실제 고객 데이터를 받기 전에 RLS 적용 여부, 비밀 키 위치, 사용자 계정 간 데이터 분리를 점검하고, 큰 변경이 있을 때마다 다시 확인하는 것이 좋습니다 ^[2]. 내부에 전문성이 부족하다면 외부 전문가의 접근 권한 검토를 받으라는 것이 조사팀의 권고입니다 ^[2].

참고 자료

1. Lovable put a .env file in my GitHub repo. Is my Supabase key leaked? · DEV Community, 2026-11-13
2. Lovable 앱에서 여권 정보와 20만 건 이상의 비공개 메시지 노출 · GeekNews, 2026-11-14