AI가 코드를 대신 짜주는 시대가 열리자, 앱을 만드는 문턱은 낮아졌다.
하지만 보안의 문턱까지 함께 낮아진 것은 아니다.
UpGuard Research가 공개한 조사 보고서 「Everything Everywhere: Systemic Data Exposure in Supabase Apps」는 이 간극을 정면으로 보여준다. 보고서의 결론은 단순하다. Supabase를 사용하는 수많은 웹앱에서 데이터베이스 오설정으로 개인정보와 민감 데이터가 노출되고 있으며, 이 문제는 AI 코딩 에이전트와 바이브 코딩 확산으로 더 커지고 있다는 것이다.
Supabase는 AI 기업이 아니다.
Supabase의 핵심 제품은 호스팅 Postgres 데이터베이스다. 웹 애플리케이션을 만들 때 필요한 백엔드 데이터베이스 서비스다. 그러나 AI 붐 속에서 Supabase는 중요한 위치를 차지하게 됐다. 보고서는 Supabase가 Claude Code가 가장 많이 추천하는 데이터베이스 제품이며, 바이브 코딩으로 수익형 제품을 만들고 싶어 하는 이용자에게 적합한 도구로 자리 잡았다고 설명한다.
문제는 바로 그 편의성에서 시작된다.
바이브 코딩은 사용자가 자연어로 원하는 기능을 말하고, AI 코딩 에이전트가 코드를 만들고 배포를 돕는 방식이다. 이 흐름에서는 사용자가 직접 코드와 설정을 깊이 이해하지 않아도 앱을 만들 수 있다. 이는 생산성 측면에서는 혁명적이지만, 보안 측면에서는 위험하다. 앱은 만들어졌지만, 데이터베이스 접근 통제와 권한 정책이 제대로 설정됐는지 사용자가 모를 수 있기 때문이다.
UpGuard는 이 문제를 과거의 S3 버킷과 GitHub 공개 저장소 문제에 비유한다.
Amazon S3는 초기 설정의 편의성 때문에 수많은 데이터 노출 사고를 낳았다. GitHub도 공개 기본 모델을 통해 빠르게 성장했지만, 그 과정에서 인증정보와 민감 개인정보가 노출되는 일이 반복됐다. 보고서는 Supabase가 지금 대중적 채택 단계에 들어서며, 불안전한 설정 패턴이 구조적 데이터 노출로 이어지는 위치에 놓였다고 진단한다.
즉 문제는 특정 개발자의 실수만이 아니다.
도구가 빠르게 대중화되고, 사용자는 보안 설정을 충분히 이해하지 못하며, AI 코딩 에이전트는 앱이 작동하는 것을 우선 목표로 삼는다. 이 세 가지가 결합하면 오설정은 예외가 아니라 패턴이 된다.
이미 경고는 있었다.
2025년 3월 개발자 Matt Turner는 바이브 코딩 플랫폼 Lovable이 만든 Supabase 데이터베이스에서 광범위한 오설정을 보고했다. 가장 단순한 형태의 취약한 설정은 누구나 데이터베이스를 쿼리하지 못하도록 막는 통제가 없는 경우였다. 이후 연구에서는 정책이 존재하지만 접근을 충분히 제한하지 못하거나, 클라이언트 코드에 공유된 공개 키가 마치 비밀 키처럼 사용되는 등 다른 노출 방식도 확인됐다.
Supabase도 개선을 했다.
보고서에 따르면 Supabase는 Table Editor UI에서 생성된 테이블에 대해 RLS, 즉 Row Level Security를 기본 적용하도록 제품을 바꿨다. 그러나 AI 코딩 에이전트가 Supabase와 상호작용하는 방식인 API를 통해 프로그래밍 방식으로 생성된 테이블에는 RLS가 기본 활성화되지 않는다. RLS가 켜져 있더라도 제대로 구성하고 자격증명을 올바르게 사용해야 데이터가 보호된다.
이 대목이 핵심이다.
보안 기능이 존재하는 것과 보안이 적용되는 것은 다르다.
RLS가 있다는 것과 RLS가 제대로 설정됐다는 것은 다르다.
AI가 앱을 만들어줬다는 것과 그 앱이 안전하다는 것은 다르다.
UpGuard는 이번 조사를 통해 약 30만 개의 Supabase 사용 흔적이 있는 도메인을 수집했다. 연구진은 공개 자바스크립트 파일에서 Supabase 키 이름과 데이터베이스 주소를 찾아 Supabase 사용 여부를 식별했다. BuiltWith와 Chrome UX Report 데이터셋을 활용해 후보군을 만들고, 각 도메인에 대해 흔한 테이블명인 “users” 테이블을 조회하는 방식으로 접근 가능 여부를 확인했다.
그 결과는 상당했다.
UpGuard는 후보군에서 읽기 가능한 테이블을 노출한 데이터베이스 1만6,326개를 식별했다. 너무 큰 규모였기 때문에 모든 행을 읽는 방식이 아니라, 테이블 스키마를 분석해 어떤 유형의 데이터가 잠재적으로 노출됐는지 평가했다. 그 결과 절반이 넘는 데이터베이스에서 개인정보 지표가 확인됐고, 더 작은 비율에서는 비밀번호나 인증 토큰이 포함됐다. 일부는 신용카드 데이터 가능성이 있었고, 더 흔하게는 결제 시스템 사용 흔적이 확인됐다.
이 숫자는 Supabase만의 문제가 아니다.
AI 코딩 에이전트가 만든 앱이 실제 비즈니스로 운영되고, 고객 데이터를 모으고, 결제 시스템과 연결되고, 사용자 계정을 관리하는 상황에서 데이터베이스 오설정이 발생하면 피해는 현실이 된다. 개인 프로젝트의 실수로 끝나는 것이 아니라, 고객 정보와 기업 데이터, 결제 흐름, 공급망 데이터가 노출될 수 있다.
UpGuard는 산업별 영향도 살폈다.
전자상거래와 음식점 관련 사이트는 노출된 데이터베이스에서 개인정보를 다루고 결제 시스템을 통합했을 가능성이 높았다. 무허가 온라인 베팅 서비스는 비밀번호와 기타 자격증명 유출 가능성이 높았다. 산업재를 판매하는 회사들도 높은 노출 위험을 보였는데, 이들은 기업 고객에게 판매하고 기업 데이터를 다룰 가능성이 있다는 점에서 공급망 리스크로 이어질 수 있다.
흥미로운 점은 B2C와 B2B 여부가 노출 데이터 유형에 큰 차이를 만들지 않았다는 것이다.
보고서는 사이트가 소비자 대상 서비스인지 기업 대상 서비스인지와 관계없이 데이터 노출 유형이 크게 다르지 않았다고 설명한다. 이유는 보안 설정이 비즈니스 유형과 무관하게 동일하기 때문이다. 어떤 사업을 하는지 아는 인간이 데이터베이스 설정을 이해하지 못하고, AI 코딩 에이전트가 만든 앱이 그대로 운영되는 구조가 공통 문제라는 분석이다.
이는 바이브 코딩의 가장 큰 역설이다.
사용자는 자신이 어떤 비즈니스를 만드는지는 안다.
하지만 그 비즈니스가 어떤 데이터베이스 권한 구조로 작동하는지는 모를 수 있다.
AI는 기능을 구현한다.
하지만 모든 보안 의도를 정확히 반영하지는 못할 수 있다.
결과적으로 앱은 잘 작동하지만, 데이터는 열려 있을 수 있다.
UpGuard가 제시한 실제 사례들은 이 위험을 더 구체적으로 보여준다.
인도의 OnlyFans 유사 사이트에서는 users 테이블에 6만5,467명의 개인이 확인됐다. 이름, 이메일 주소, 생년월일, 주소 같은 일반 개인정보뿐 아니라 운전면허 정보, 여권 세부정보, PAN 카드 번호, Aadhar 번호 마지막 4자리 등이 포함됐다. 여기에 PayPal, Payoneer, Zelle, 암호화폐 지갑, 은행 계좌, Stripe 계정 정보 같은 금융 데이터도 연결돼 있었다. 별도 메시지 테이블에는 성인 콘텐츠 크리에이터와 주고받은 비공개 메시지 10만 건 이상이 포함됐다.
필리핀 OTP 서비스 사례도 심각하다.
해당 노출 데이터베이스에는 이메일 주소, 전화번호, 지갑 잔액 등 정보를 가진 이용자 2,000명 이상이 포함됐다. 또 OTP 코드, 발신자 ID, SIM 코드가 담긴 SMS 메시지 10만 건 이상이 있었다. 표본의 95%는 OTP 코드였지만, 2,000~2,400건은 실제 개인 간 문자 메시지였고, 대부분 필리핀의 차량 호출 서비스에서 운전자와 승객 사이에 오간 메시지로 보였다.
이 사례는 데이터 노출의 2차 피해를 보여준다.
해당 서비스와 직접 관련 없는 사람들의 문자까지 함께 노출될 수 있다. SIM 팜이나 OTP 서비스처럼 사이버범죄 공급망과 연결될 수 있는 인프라에서는 제3자의 데이터가 부수적으로 노출될 위험도 커진다.
미국 기반 발레 서비스 사례에서는 10만 명 이상의 고객 데이터가 노출됐다. 각 고객의 전화번호가 포함됐고, 약 4만3,000명은 이메일 주소와 전체 이름도 포함됐다. 약 7만8,000명은 차량 번호판 정보가 포함됐으며, 방문 이력, 평생 가치, 팁 이력, 자유 텍스트 메모 필드도 있었다. 직원 users 테이블에는 665명의 이메일 주소, 전화번호, 푸시 토큰이 있었다.
이 사례는 개인정보가 단순한 연락처를 넘어 행동 이력과 고객 가치 데이터로 확장될 수 있음을 보여준다.
발레 서비스의 데이터는 이름과 전화번호에 그치지 않는다. 누가 언제 방문했는지, 얼마나 많이 썼는지, 어떤 메모가 남았는지, 어떤 차량을 이용했는지가 포함된다. 이는 마케팅 데이터이자 위치·생활 패턴 데이터가 될 수 있다.
아프리카 영사관 사례는 더 민감하다.
UpGuard는 한 아프리카 국가 정부가 운영하는 영사관 관련 Supabase 데이터베이스에서 개인정보와 물리적 주소를 가진 2만5,000명의 이용자를 확인했다고 밝혔다. 해당 서비스의 성격상 노출된 사람들은 취약한 인구집단에 속하며, 또 다른 필드는 개인들이 현재 어느 긴급 주거 시설에 머물고 있는지도 식별했다.
이 사례는 단순한 스타트업 보안 미숙을 넘어 공공성과 인권 리스크까지 연결된다.
긴급 주거 위치는 매우 민감한 정보다. 취약한 인구집단의 물리적 주소와 거주 장소가 노출되면 사생활 침해를 넘어 안전 위험으로 이어질 수 있다. 데이터베이스 오설정은 때로 직접적인 물리적 위험을 낳는다.
캐나다 이민·정착 서비스 사례도 있다.
캐나다로 이주하려는 사람들에게 코칭과 조언을 제공하는 서비스의 노출 데이터베이스에서는 약 5,000건의 users 레코드가 확인됐다. 거의 모든 레코드에 전체 이름, 이메일 주소, 전화번호, 생년월일이 포함됐고, 884건에는 평문 비밀번호가 저장돼 있었다.
평문 비밀번호는 기본적인 보안 실패다.
하지만 바이브 코딩 환경에서는 이런 기본 실패도 발생할 수 있다. 사용자가 AI에게 로그인 기능을 만들어 달라고 요청하면 앱은 로그인처럼 보일 수 있다. 그러나 비밀번호 해싱, 접근 권한, 세션 관리, 데이터베이스 정책까지 제대로 구현됐는지는 별개의 문제다.
UpGuard의 결론은 명확하다.
데이터 유출은 기술의 오설정 가능성과 사용자 기반 규모가 곱해진 결과다. 소수의 기술만이 둘 모두를 달성한다. Supabase는 바이브 코딩 앱의 거의 기본 데이터베이스 선택지가 되면서, 인간 또는 AI 코딩 에이전트가 좋은 보안 설정을 잘못 이해할 때 그 영향이 전 세계, 모든 산업, 모든 비즈니스 모델에 걸쳐 나타난다는 것이다.
이 표현은 중요하다.
보안 사고는 더 이상 고급 해커의 공격만으로 발생하지 않는다.
누군가 편리한 도구를 빠르게 채택하고, AI가 앱을 만들어주고, 사용자가 보안 설정을 이해하지 못한 채 배포하면, 데이터는 조용히 열려 있을 수 있다.
바이브 코딩은 개발의 민주화를 가져왔다.
그러나 개발의 민주화가 곧 보안의 민주화를 뜻하지는 않는다. 오히려 더 많은 비전문가가 실제 고객 데이터를 다루는 앱을 만들게 되면서, 보안 실수의 총량은 늘어날 수 있다. AI가 코드를 만들어주는 시대에는 “작동하는 앱”과 “안전한 앱”의 차이를 더 명확히 구분해야 한다.
AI 코딩 에이전트의 평가 방식도 문제와 연결된다.
보고서는 AI 모델이 강화학습을 통해 개선되고, 인간 만족도에 따라 미래 선택이 달라진다고 설명한다. 데이터베이스 제품을 사용했을 때 AI가 잘 작동하고 사용자가 만족하면, 해당 제품을 추천할 가능성이 커진다. Supabase는 AI 코딩 에이전트가 쉽게 사용할 수 있도록 설계되어 있고, 바로 이 점이 추천과 확산을 강화한다.
여기서 보안은 종종 뒤로 밀린다.
AI 에이전트는 사용자가 요구한 기능이 빨리 작동하도록 만드는 데 강하다. 회원가입, 로그인, 프로필, 결제, 관리자 페이지, 메시지 기능이 눈앞에서 구현되면 사용자는 만족한다. 하지만 데이터베이스 권한 정책이 제대로 되어 있는지, 공개 키와 비밀 키를 구분했는지, RLS가 API 생성 테이블에 적용됐는지, users 테이블이 외부에서 읽히지 않는지는 눈에 잘 보이지 않는다.
보안은 실패할 때까지 보이지 않는다.
그래서 Supabase 오설정 문제는 AI 시대의 소프트웨어 공급망 문제이기도 하다.
AI가 만든 앱은 독립된 코드 조각이 아니다. 데이터베이스, 인증, 결제, 메시징, 스토리지, 배포 플랫폼, 외부 API가 연결된 시스템이다. 그중 하나라도 잘못 설정되면 고객 데이터가 노출된다. 사용자는 “AI가 만들어줬으니 됐다”고 생각할 수 있지만, 실제 책임은 사라지지 않는다.
이 문제를 해결하려면 누가 바뀌어야 할까.
첫째, 플랫폼이 바뀌어야 한다.
Supabase 같은 도구는 AI 코딩 에이전트가 사용하는 경로에서도 안전한 기본값을 제공해야 한다. Table Editor UI에서 RLS가 기본 적용되더라도, API로 생성된 테이블에서 빠진다면 AI 코딩 시대에는 구멍이 남는다. AI 에이전트가 가장 많이 쓰는 경로가 곧 가장 중요한 보안 경로다.
둘째, AI 코딩 도구가 바뀌어야 한다.
Claude Code, Codex, Lovable, Replit 같은 도구는 단순히 작동하는 코드를 만드는 것을 넘어, 보안 설정을 검증하고 경고해야 한다. users 테이블을 만들었다면 RLS가 켜져 있는지, 공개 키로 읽히지 않는지, 비밀번호가 평문으로 저장되지 않는지, 민감 데이터 필드가 노출되지 않는지 확인해야 한다.
셋째, 사용자의 기대도 바뀌어야 한다.
바이브 코딩은 프로토타입을 빠르게 만들 수 있게 해준다. 그러나 고객 데이터를 받는 순간 그것은 장난감이 아니라 서비스가 된다. 이메일, 전화번호, 생년월일, 결제 계정, 메시지, 주소, 차량 번호판, 여권 정보, 긴급 주거 위치를 저장한다면 보안 검토는 선택이 아니다.
넷째, 외부 점검이 필요하다.
AI가 만든 앱은 빠르게 늘어나지만, 만든 사람이 보안 설정을 이해하지 못할 수 있다. 따라서 배포 전 자동 보안 점검, 노출 스캔, 데이터베이스 정책 검사, 키 관리 검사 같은 절차가 필수화될 필요가 있다.
UpGuard 보고서는 AI 코딩 에이전트의 위험을 과장하지 않는다.
문제는 AI가 악의적으로 데이터를 유출했다는 것이 아니다. 더 현실적인 문제는 AI가 앱을 너무 쉽게 만들게 되면서, 보안 설정을 이해하지 못한 앱이 너무 쉽게 배포된다는 점이다. 이 위험은 더 조용하고 더 넓다.
그리고 그 조용함이 가장 위험하다.
데이터베이스가 노출되어도 앱은 정상 작동한다.
사용자는 로그인할 수 있고, 주문할 수 있고, 메시지를 보낼 수 있다.
운영자는 서비스가 잘 돌아간다고 생각한다.
하지만 공격자나 연구자는 공개 자바스크립트와 API 키를 따라가 데이터베이스를 읽을 수 있다.
겉으로는 성공한 앱이다.
안쪽으로는 열린 데이터베이스다.
Supabase는 AI 시대의 성공한 도구다. 그 자체가 문제라는 뜻은 아니다. 문제는 성공한 도구가 보안 기본값과 사용자 이해를 따라잡지 못할 때, 그 영향이 전 세계적으로 확산된다는 점이다.
S3가 그랬고, GitHub가 그랬다.
이제 Supabase가 같은 시험대에 올랐다.
AI 코딩 에이전트 시대에는 개발자가 아닌 사람도 앱을 만든다. 그래서 데이터베이스는 더 안전한 기본값을 가져야 하고, AI는 더 보수적인 보안 판단을 해야 하며, 플랫폼은 오설정을 제품 차원에서 막아야 한다.
바이브 코딩의 다음 과제는 더 빠른 개발이 아니다.
AI가 만든 앱이 고객 데이터를 맡아도 되는 수준인지 증명하는 일이다.
