바이브 코딩 웹, 보안은 어떤가?

자연어로 기능을 설명하면 AI가 화면과 데이터베이스, 로그인, 결제, 배포까지 만들어 주는 서비스가 빠르게 확산됐습니다. 개발 지식이 많지 않은 사람도 몇 시간 안에 회원가입이 있는 웹서비스를 공개할 수 있습니다.

이 흐름은 2025년 2월 안드레이 카파시가 사용한 “바이브 코딩”이라는 표현으로 널리 알려졌습니다. 초기에는 AI가 작성한 코드를 세밀하게 읽지 않고 실행 결과와 대화를 중심으로 개발하는 방식을 가리켰습니다. 이후 Lovable, Bolt, Replit, Base44 같은 앱 빌더와 Cursor·Claude Code·Codex 같은 코딩 에이전트를 포괄하는 말로 확장됐습니다.

웹서비스를 만드는 대표적인 구성에는 Vercel과 Supabase가 자주 등장합니다. Vercel은 프론트엔드와 서버 함수를 배포하고, Supabase는 로그인·Postgres 데이터베이스·파일 저장소·API·Edge Function을 제공합니다. GitHub 저장소를 연결하면 코드 변경이 자동으로 배포됩니다.

이 조합은 빠르고 편리합니다. 보안 책임이 사라지는 구조는 아닙니다. 브라우저에서 직접 데이터베이스 API를 호출할 수 있는 설계, 자동 생성되는 프리뷰 주소, AI가 작성한 권한정책, 환경변수와 공개 번들의 경계가 서로 맞물립니다.

Supabase와 Vercel을 연결하면 어떤 구조가 생기는가

가장 단순한 형태에서는 사용자의 브라우저가 Vercel에 배포된 화면을 내려받습니다. 화면의 JavaScript는 Supabase 프로젝트 주소와 공개용 API 키를 사용해 로그인하고 데이터를 읽습니다.

Supabase는 Postgres 위에 REST API를 자동으로 제공합니다. 테이블과 권한이 준비되면 별도의 전통적인 백엔드 서버 없이 브라우저가 데이터베이스 API와 통신할 수 있습니다.

이 구조의 안전성은 Row Level Security, 줄여서 RLS에 크게 의존합니다.

RLS는 데이터베이스가 각 행을 읽고 쓰는 조건을 직접 검사하는 Postgres 기능입니다. 로그인한 이용자는 자신의 게시물만 읽고, 관리자는 전체 자료를 읽고, 익명 이용자는 공개글만 보는 정책을 SQL로 정의할 수 있습니다.

Supabase 공식 문서는 외부에 노출된 스키마의 테이블에 RLS를 항상 활성화해야 한다고 설명합니다. 기본 노출 스키마는 `public`입니다.

대시보드의 Table Editor에서 만든 테이블에는 RLS가 기본으로 활성화됩니다. SQL 편집기나 마이그레이션으로 직접 만든 테이블은 RLS가 자동 적용되지 않을 수 있으므로 별도 명령이 필요합니다.

바이브코딩 도구는 화면, 테이블, 정책, API 호출을 연속으로 생성합니다. 기능이 정상 작동하는 순간과 권한이 올바르게 제한된 순간은 일치하지 않을 수 있습니다.

공개용 Supabase 키가 보이는 것은 정상일 수 있다

바이브코딩 앱의 JavaScript를 열어 보면 Supabase 프로젝트 URL과 `anon` 키 또는 publishable key가 발견되는 경우가 많습니다.

Supabase는 공개용 키를 브라우저에서 사용할 수 있도록 설계했습니다. 공개용 키 자체를 숨기는 방식으로 데이터베이스를 보호하지 않습니다. 요청에 적용되는 RLS 정책이 실제 접근 범위를 결정합니다.

공개용 키가 보이는 사실만으로 유출이라고 판단하기는 어렵습니다.

문제는 AI가 두 종류의 키를 혼동할 때 발생합니다. 빠르게 오류를 해결하는 과정에서 service role 키를 프론트엔드 코드에 넣으면 모든 사용자의 데이터에 접근할 수 있는 관리 권한이 브라우저로 전달될 수 있습니다.

Supabase 공식 문서는 secret key와 legacy `service_role` 키가 RLS를 우회하므로 브라우저에서 절대 사용하지 말라고 명시합니다.

사건 1: Lovable과 CVE-2025-48757

2025년 5월 NVD에 CVE-2025-48757이 등록됐습니다.

NVD 설명에 따르면 2025년 4월 15일까지 영향을 받은 Lovable 환경에서 불충분한 데이터베이스 RLS 정책으로 인해 인증하지 않은 원격 공격자가 생성된 사이트의 임의 데이터베이스 테이블을 읽거나 쓸 수 있었습니다.

취약점 유형은 CWE-863 Incorrect Authorization, 잘못된 권한검사로 분류됐습니다. 공격복잡도가 낮고 사용자 상호작용이 필요하지 않은 네트워크 공격 조건이 기재됐습니다.

이 기록에는 공급업체의 이의도 함께 남아 있습니다. Lovable 측은 개별 고객이 애플리케이션 데이터 보호 책임을 수락한다는 이유로 CVE 설명에 이견을 제기했습니다.

이 사건은 Supabase 자체 암호가 깨진 사건으로 공개된 것이 아닙니다. 생성된 애플리케이션의 데이터 접근정책이 충분하지 않아 공개 API를 통해 읽기·쓰기 권한이 열릴 수 있었던 권한설계 문제입니다.

RLS가 꺼진 테이블은 공개용 키로도 데이터가 노출될 수 있습니다. RLS가 켜져 있어도 `using (true)`처럼 모든 이용자에게 전체 행을 허용하는 정책이 존재하면 결과는 비슷해질 수 있습니다.

AI가 “게시판을 만들어 줘”라는 요청을 처리할 때 기능 완성을 우선하면 모든 게시물을 읽고 쓰게 하는 넓은 정책이 생성될 수 있습니다. 이후 “사용자별로 분리해 줘”라는 요청이 들어와도 기존 정책을 지우지 않고 새 정책을 추가하면 넓은 허용규칙이 남을 수 있습니다.

RLS는 켜짐과 안전함이 같은 의미가 아니다

RLS 상태가 `enabled`로 표시돼도 정책의 논리가 잘못되면 데이터가 노출될 수 있습니다.

게시물 테이블에 `user_id`가 존재한다고 가정해 보겠습니다. 정상적인 사용자 구분에는 로그인 토큰의 사용자 ID와 행의 `user_id`가 일치하는지 검사하는 조건이 필요합니다.

정책이 로그인 여부만 확인하면 모든 로그인 사용자가 모든 행을 읽을 수 있습니다. 익명 역할에 읽기 권한을 주면 로그인 전에도 접근이 가능할 수 있습니다. 업데이트 정책에 검사조건이 빠지면 다른 사람의 행을 자신의 ID로 바꿀 수 있습니다.

읽기, 생성, 수정, 삭제는 각각 다른 작업입니다. 한 작업의 정책을 작성했다고 다른 작업이 자동으로 보호되는 것도 아닙니다.

Supabase 공식 문서는 사용자 JWT의 `raw_user_meta_data`를 권한판단에 사용하면 보안문제가 생길 수 있다고 설명합니다. 해당 영역은 사용자가 수정할 수 있습니다. 관리자 여부와 조직 역할 같은 권한정보는 사용자가 변경할 수 없는 `raw_app_meta_data`나 서버의 권한테이블에서 관리하는 방식이 사용됩니다.

사건 2: Base44 비공개 앱 인증 우회

2025년 7월 Wiz Research는 Base44에서 비공개 애플리케이션 접근을 우회할 수 있는 취약점을 공개했습니다.

연구진 설명에 따르면 공격자는 비밀정보가 아닌 `app_id` 값만 이용해 문서화되지 않은 가입·이메일 검증 엔드포인트를 호출하고 비공개 애플리케이션의 검증된 계정을 생성할 수 있었습니다.

이 방식은 Base44가 제공한 인증통제와 SSO를 우회해 비공개 기업용 앱과 그 안의 데이터에 접근할 가능성을 만들었습니다.

Wiz는 Base44와 모회사 Wix에 취약점을 신고했습니다. 문제는 24시간 안에 수정됐으며 Wix는 과거 악용 증거가 확인되지 않았다고 밝혔습니다.

이 사례의 원인은 개별 이용자가 작성한 화면 코드에만 있지 않았습니다. 여러 고객의 애플리케이션이 공유하는 플랫폼 인증계층에 취약점이 존재했습니다.

바이브코딩 플랫폼에서는 사용자가 만든 코드의 보안과 플랫폼이 제공하는 공통 인증·호스팅의 보안이 함께 작동합니다. 플랫폼 공통계층의 한 취약점이 여러 비공개 앱에 영향을 줄 수 있습니다.

사건 3: Replit Agent의 운영 데이터 삭제

2025년 7월 SaaStr 창업자 제이슨 렘킨은 Replit Agent를 사용하던 중 운영 데이터베이스가 삭제됐다고 공개했습니다.

Replit 최고경영자 암자드 마사드는 Agent가 개발 과정에서 운영 데이터베이스의 데이터를 삭제한 사실을 인정하고 해당 상황은 허용될 수 없다고 밝혔습니다.

Replit은 이후 공식 글에서 Agent가 앱 데이터베이스의 데이터를 삭제한 사건을 언급하며 데이터 변경을 복구할 수 있는 롤백 기능과 안전조치 강화를 설명했습니다.

2025년 12월 Replit은 스냅샷 엔진을 소개하면서 개발·운영 데이터베이스의 완전한 분리와 Agent의 개발 데이터베이스 접근 제한을 추가했다고 밝혔습니다.

이 사건은 외부 해커의 침입사고가 아닙니다. 코딩 에이전트가 데이터베이스 명령을 실행할 권한을 가진 상태에서 의도하지 않은 파괴 작업을 수행한 운영사고입니다.

바이브코딩 보안에는 기밀성만 포함되지 않습니다. 데이터의 무결성과 가용성, 변경 승인, 운영·개발 분리, 백업 복구도 포함됩니다.

Supabase와 Vercel을 사용하는 코딩 에이전트가 SQL 마이그레이션, 테이블 삭제, 환경변수 변경, 운영 배포 권한을 함께 가지면 비슷한 유형의 사고가 발생할 수 있습니다.

브라우저에 있는 인증은 보호장치가 되기 어렵다

Wiz는 2025년 바이브코딩 앱 연구에서 인증 절차 전체가 브라우저 JavaScript에 구현된 실제 사례들을 확인했습니다.

일부 앱은 정해진 문자열과 사용자가 입력한 비밀번호를 브라우저에서 비교했습니다. 인증 성공 여부는 LocalStorage의 값 하나로 관리됐습니다.

브라우저에 전달된 JavaScript는 이용자가 내려받아 확인하고 수정할 수 있습니다. 코드 안에 비밀번호가 존재하면 개발자도구와 소스파일에서 찾을 수 있습니다. LocalStorage의 `authenticated=true` 같은 값을 이용자가 직접 만들 수도 있습니다.

로그인 화면이 존재한다는 사실은 서버가 권한을 검사한다는 증거가 아닙니다.

보호가 필요한 데이터 요청마다 서버나 데이터베이스가 사용자 신원과 권한을 확인해야 합니다. 화면을 숨기는 상태값은 편의기능으로 사용할 수 있으며 접근통제를 대신하지 못합니다.

하드코딩된 API 키와 환경변수

Wiz는 생성된 클라이언트 JavaScript 안에 OpenAI API 키와 서비스 계정 자격증명이 직접 들어간 사례를 확인했습니다.

프론트엔드 번들에 들어간 값은 웹페이지 방문자에게 전달됩니다. 코드를 난독화해도 브라우저가 실행하려면 값을 받을 수 있어야 합니다.

Next.js에서는 `NEXT_PUBLIC_` 접두사가 붙은 환경변수가 빌드 과정에서 클라이언트 JavaScript에 포함됩니다. Vercel 공식 문서도 해당 접두사의 변수가 브라우저 번들에 인라인된다고 설명합니다.

서버용 비밀키에 공개 접두사를 붙이면 Vercel 대시보드에서 환경변수로 관리했더라도 최종 번들에서 노출될 수 있습니다.

Vercel의 환경변수는 저장 시 암호화됩니다. 프로젝트 접근권한이 있는 사용자는 일반 환경변수 값을 볼 수 있습니다. Sensitive로 표시한 변수는 생성 후 읽을 수 없는 형태로 관리됩니다.

환경변수 값은 새 배포에 적용됩니다. 이미 만들어진 과거 배포에는 변경 전 값과 코드가 남을 수 있습니다. 키를 교체할 때 현재 프로덕션만 다시 배포하고 과거 프리뷰 배포를 남겨 두면 이전 번들 또는 기능이 계속 접근 가능할 수 있습니다.

Git 저장소에 들어간 비밀값

AI는 오류를 해결하기 위해 `.env` 파일을 생성하고 키를 붙여 넣는 작업을 수행할 수 있습니다.

Supabase 공식 문서는 `.env` 파일을 Git에 커밋하지 말고 `.gitignore`에 추가하라고 안내합니다.

비밀키가 공개 Git 저장소에 한 번 올라가면 이후 커밋에서 삭제해도 과거 기록에 남을 수 있습니다. 포크, 캐시, 빌드 로그, 자동화 서비스가 이미 값을 복사했을 가능성도 있습니다.

GitHub는 공개 저장소와 Gist의 비밀값을 탐지해 공급자에게 알리는 secret scanning 기능을 운영합니다. 탐지 뒤에는 코드에서 문자열을 지우는 작업과 키를 폐기·재발급하는 작업이 함께 필요합니다.

바이브코딩 도구가 “키를 숨겨 줘”라는 요청에 환경변수로 이동하는 코드만 만들 수 있습니다. 이미 노출된 키의 폐기까지 자동으로 수행됐는지는 별도 사실입니다.

Vercel 프리뷰 배포는 이름이 어려워도 비공개를 뜻하지 않는다

Vercel은 Git 브랜치와 커밋마다 고유한 프리뷰 배포를 만들 수 있습니다.

프리뷰 주소는 길고 추측하기 어려울 수 있습니다. 인증이 적용됐다는 의미는 아닙니다.

Vercel은 프리뷰와 프로덕션 URL의 접근자를 제한하는 Deployment Protection 기능을 제공합니다. 적용 범위와 보호방법은 프로젝트 설정과 요금제에 따라 달라집니다.

내부 관리자 화면, 테스트용 CRM, 설문 결과, 실데이터가 들어간 데모 앱이 프리뷰 주소에 배포되면 URL을 아는 사람이나 검색·로그·공유기록을 통해 주소를 얻은 사람이 접근할 가능성이 생깁니다.

Wiz는 공개 인터넷에서 인증 없이 노출된 내부 앱, 지식베이스, 민감정보가 포함된 챗봇을 확인했다고 밝혔습니다.

보안상 공개 여부는 커스텀 도메인의 존재로 판단되지 않습니다. `vercel.app`, `lovable.app`, `replit.app` 같은 플랫폼 도메인의 배포도 인터넷에 연결된 웹서비스입니다.

2026년 공개 앱 노출 조사

RedAccess는 2026년 공개한 보고서에서 바이브코딩 관련 자산 38만 개를 검토했고 기업용 목적으로 만들어진 것으로 분류한 앱 5,000개 가운데 40%가 민감정보를 노출했다고 주장했습니다.

WIRED는 이 조사와 관련해 약 5,000개의 앱에 실질적인 인증이 없었고 약 2,000개에서 의료·재무정보, 기업전략, 고객 상담기록 같은 비공개 자료로 보이는 정보가 확인됐다고 보도했습니다. 일부 표본은 WIRED가 직접 확인했다고 밝혔습니다.

플랫폼 사업자들은 공개된 앱의 데이터가 실제 자료인지 예시자료인지 외부에서 판별하기 어렵다는 점과 이용자가 공개설정을 관리한다는 입장을 제시했습니다.

RedAccess 수치는 보안업체의 탐색방법과 분류기준을 토대로 한 조사결과입니다. 모든 노출 앱이 실제 침해사고로 확정됐다는 통계는 아닙니다.

이 조사에서 확인되는 중요한 현상은 검색엔진으로 플랫폼 도메인을 찾는 것만으로 다수의 앱이 발견됐다는 점입니다. 개인이 만든 임시 도구와 기업 내부자료를 담은 앱이 같은 공개 호스팅 환경에 존재할 수 있습니다.

Storage 버킷과 업로드 파일

Supabase Storage는 이미지, 문서, 영상과 일반 파일을 저장합니다. 접근통제에는 Postgres RLS 정책이 사용됩니다.

공개 버킷은 URL을 가진 사람이 파일을 읽을 수 있는 용도에 적합합니다. 프로필 공개사진이나 공개 게시물 첨부파일에 사용할 수 있습니다.

이력서, 계약서, 진단서, 신분증, 내부 문서는 비공개 접근정책이 필요합니다.

버킷을 비공개로 만들었다고 업로드·목록조회·수정·삭제 권한이 자동으로 업무요건에 맞게 완성되는 것은 아닙니다. Storage의 `objects` 테이블 정책이 파일 경로와 사용자 ID를 정확하게 검사해야 합니다.

AI가 파일경로를 `userId/file.pdf` 형태로 만들더라도 요청자가 해당 `userId`의 실제 소유자인지 정책에서 검사하지 않으면 다른 사람의 경로를 추측해 접근할 수 있습니다.

서명 URL은 일정 시간 동안 비공개 파일에 접근하도록 만드는 기능입니다. URL이 로그, 분석도구, 메신저에 남으면 유효기간 동안 소유자 외의 사람도 사용할 수 있습니다.

Edge Function을 만들었다고 서버 보안이 자동 완성되지는 않는다

Supabase Edge Functions는 결제 웹훅, 이메일 발송, 외부 API 호출, AI 요청 같은 서버 작업에 사용됩니다.

비밀키를 브라우저에 넣지 않고 Edge Function의 secret으로 저장하는 구조는 키 노출을 줄입니다.

함수 자체의 인증과 권한검사는 별도입니다.

Supabase는 사용자 JWT를 검증하는 `user` 모드, 비밀키를 사용하는 `secret` 모드, 공개키만 확인하는 `publishable` 모드, 아무 인증도 요구하지 않는 `none` 모드를 제공합니다.

웹훅처럼 외부 서비스가 호출하는 함수에는 공개접근이 필요할 수 있습니다. 이때 서명 검증이 빠지면 누구나 결제 완료나 계정 생성 이벤트를 위조해 호출할 수 있습니다.

사용자용 함수가 JWT를 검사한 뒤에도 요청자가 해당 레코드의 소유자인지 확인해야 합니다. 관리자용 secret key로 데이터베이스를 호출하면 RLS가 우회되므로 함수 코드의 권한검사가 유일한 통제가 될 수 있습니다.

인증과 인가의 혼동

로그인에 성공한 사용자가 모든 기능을 사용할 수 있는 것은 아닙니다.

인증은 사용자가 누구인지 확인합니다. 인가는 해당 사용자가 어떤 데이터와 기능을 사용할 수 있는지 결정합니다.

바이브코딩 앱에서는 로그인 기능이 구현된 뒤 전체 테이블 조회가 허용되는 경우가 생깁니다. AI에게 “관리자 페이지를 추가해 줘”라고 요청한 뒤 URL 경로만 `/admin`으로 만들고 서버의 관리자 권한검사를 생략할 수도 있습니다.

URL을 숨기는 방식, 메뉴를 보이지 않게 하는 방식, 프론트엔드에서 역할을 확인하는 방식은 서버 인가를 대체하지 못합니다.

사용자 ID를 요청 본문으로 받아 데이터베이스를 조회하는 코드도 주의가 필요합니다. 공격자는 자신의 요청 본문을 다른 사용자 ID로 바꿀 수 있습니다. 서버는 로그인 토큰에서 확인한 사용자 ID를 사용해야 합니다.

이 유형은 객체 수준 권한검사 실패, 흔히 IDOR 또는 BOLA로 설명됩니다.

생성 코드는 작동하면서 취약할 수 있다

Veracode는 2025년 100개가 넘는 대규모 언어모델을 80개 보안 관련 코딩 작업에서 평가했습니다.

전체 코드 표본의 45%가 보안시험을 통과하지 못하고 OWASP Top 10 계열 취약점을 포함했습니다. 언어별 실패율은 Java 72%, C# 45%, JavaScript 43%, Python 38%로 보고됐습니다.

관련 작업에서 교차사이트 스크립팅, XSS 방어 실패율은 86%였습니다.

이 연구는 인터넷에 배포된 바이브코딩 앱의 침해율을 측정한 통계가 아닙니다. 모델이 주어진 코딩 과제를 해결하면서 안전한 구현을 생성했는지 평가한 벤치마크입니다.

2025년 공개된 별도 학술 프리프린트는 실제 오픈소스 기능요청을 바탕으로 만든 200개 보안 과제에서 코딩 에이전트를 평가했습니다. 한 구성에서 기능적으로 맞는 해법은 61%였으며 보안 요구까지 충족한 해법은 10.5%였습니다.

기능 테스트가 성공했다는 사실과 적대적 입력을 견딘다는 사실이 분리될 수 있다는 결과입니다.

XSS와 입력값 처리

사용자가 작성한 게시글, 프로필, 문의내용을 화면에 표시할 때 HTML과 스크립트가 실행되면 XSS가 발생할 수 있습니다.

React는 일반적인 문자열 출력을 기본 이스케이프합니다. Markdown 렌더러, HTML 미리보기, `dangerouslySetInnerHTML`, 외부 에디터를 사용하면 별도의 정제가 필요할 수 있습니다.

AI는 “사용자가 입력한 HTML을 그대로 미리보기해 줘”라는 기능요청을 빠르게 구현할 수 있습니다. 실행 가능한 태그와 이벤트 속성을 제거하는 처리가 빠지면 다른 사용자의 세션과 화면을 공격하는 코드가 저장될 수 있습니다.

관리자 화면에서 문의내용을 열람할 때 실행되는 저장형 XSS는 관리자 권한으로 동작할 가능성이 있습니다.

SQL 함수와 관리자 기능

Supabase는 Postgres 함수와 RPC를 API로 호출할 수 있습니다.

`security definer` 함수는 함수 소유자의 권한으로 실행될 수 있습니다. 검색경로와 입력값 검증, 실행권한이 잘못 설정되면 일반 사용자가 높은 권한의 작업을 수행할 수 있습니다.

AI가 복잡한 RLS를 우회하기 위해 관리자 함수를 만드는 해결책을 제안할 수 있습니다. 기능오류는 사라지며 권한경계도 함께 약해질 수 있습니다.

SQL 문자열을 직접 조합하는 코드, 사용자 입력으로 정렬 컬럼과 테이블 이름을 선택하는 코드, 관리자 전용 RPC의 실행권한을 모든 역할에 주는 코드가 대표적인 위험입니다.

Supabase의 자동 API는 매개변수화된 질의를 활용합니다. 사용자 정의 함수와 외부 데이터베이스 연결에서는 작성한 SQL의 안전성이 다시 중요해집니다.

CORS는 데이터 권한정책이 아니다

브라우저의 CORS 설정은 어떤 출처의 웹페이지가 응답을 읽을 수 있는지 제한합니다.

CORS가 특정 도메인만 허용한다고 서버 API가 해당 도메인 사용자에게만 열린 것은 아닙니다. 브라우저 밖의 프로그램은 직접 HTTP 요청을 보낼 수 있습니다.

API 인증과 RLS가 없고 CORS만 설정된 경우 공격자는 서버에서 직접 요청해 데이터를 받을 수 있습니다.

AI가 브라우저 오류를 해결하기 위해 `Access-Control-Allow-Origin: *`를 추가할 수 있습니다. 해당 변경은 브라우저 접근범위를 넓히며 데이터 권한을 새로 만들지는 않습니다.

요금 폭탄과 자원 남용

공개된 서버 함수가 외부 AI API, 이메일, 문자, 이미지 생성 서비스를 호출하면 공격자는 해당 엔드포인트를 반복 호출할 수 있습니다.

사용자 인증, 요청량 제한, 결제한도, 봇 방어가 없으면 API 비용과 데이터베이스 부하가 증가합니다.

Vercel은 WAF와 Rate Limiting 기능을 제공하고 Supabase Edge Functions는 게이트웨이와 함수에서 요청 제한을 구성할 수 있습니다.

플랫폼 기능이 존재해도 프로젝트에 자동으로 업무별 한도가 정해지는 것은 아닙니다. 로그인 시도, 비밀번호 재설정, 파일 업로드, AI 생성, 초대메일, 쿠폰발급은 서로 다른 제한이 필요할 수 있습니다.

바이브코딩 앱은 기능 데모 단계에서 정상 사용자 한 명의 흐름을 확인하고 배포되는 경우가 많습니다. 동일 요청을 자동화해 수천 번 보내는 상황은 별도의 시험입니다.

프롬프트가 코드와 설정을 계속 바꾸는 문제

바이브코딩은 대화를 반복하며 시스템을 계속 수정하는 방식으로 사용됩니다.

초기 요청에서는 RLS가 올바르게 만들어질 수 있습니다. 이후 “테스트가 안 되니 권한을 풀어 줘”, “로그인 없이 데모를 보게 해 줘”, “일단 모두 읽게 해 줘” 같은 요청이 들어오면 보안정책이 약해질 수 있습니다.

AI는 현재 대화문맥과 코드 일부를 중심으로 수정합니다. 과거에 정한 권한원칙과 데이터 분류를 항상 유지한다는 보장은 없습니다.

2026년 실세계 바이브코딩 앱을 분석한 학술연구는 반복되는 취약점으로 placeholder logic, 필터링되지 않은 입력, 비밀값 노출을 보고했습니다. 연구진은 에이전트의 문맥 손실, 지역적인 기능 최적화, 보안지식 부족을 원인으로 분석했습니다.

기능 수정이 누적되면 사용하지 않는 API, 임시 관리자 계정, 테스트 데이터, 넓은 RLS 정책이 코드에 남을 수 있습니다.

패키지 환각과 슬롭스쿼팅

AI는 필요한 기능에 맞는 패키지 이름을 제안하고 설치 명령을 실행할 수 있습니다.

실제로 존재하지 않는 패키지 이름을 그럴듯하게 생성하는 현상도 연구됐습니다.

공격자가 반복적으로 생성되는 가짜 이름을 npm이나 PyPI에 먼저 등록하고 악성코드를 넣으면, AI 제안을 신뢰한 사용자가 해당 패키지를 설치할 수 있습니다. 이 공격을 slopsquatting이라고 부릅니다.

TrendAI 연구는 코딩 에이전트와 실시간 검색·MCP 검증이 가짜 패키지 제안을 줄일 수 있으며 완전히 제거하지는 못한다고 설명합니다.

패키지가 실제로 존재한다는 사실도 안전성을 보장하지 않습니다. 관리자 계정 탈취, 악성 업데이트, 의존성 체인 공격이 발생할 수 있습니다.

잠금파일, 패키지 출처, 유지관리자, 버전, 설치 스크립트와 알려진 취약점이 공급망 보안의 자료가 됩니다.

플랫폼이 안전하면 생성 앱도 안전한가

Vercel과 Supabase는 보안기능과 공식 가이드를 제공합니다.

Vercel은 환경변수 암호화, Sensitive 변수, Deployment Protection, WAF, 요청 제한과 팀 접근통제를 제공합니다.

Supabase는 RLS, Auth, Storage 정책, Edge Function secrets, MFA, 데이터베이스 백업과 보안문서를 제공합니다.

이 기능의 존재와 개별 앱의 적용 상태는 구분됩니다.

Supabase 공개용 키는 RLS가 정확할 때 안전하게 브라우저에서 사용할 수 있습니다. Vercel 환경변수는 서버에서만 참조할 때 비밀로 유지됩니다. 프리뷰 주소는 접근보호를 설정했을 때 내부 배포로 사용할 수 있습니다.

공통 플랫폼 취약점도 발생할 수 있습니다. Base44 사건처럼 공유 인증계층의 결함이 여러 앱에 영향을 줄 수 있습니다. 개별 앱의 정책오류와 플랫폼 공통계층의 취약점이 동시에 보안범위를 구성합니다.

보안검토에서는 무엇을 증거로 보는가

바이브코딩 앱의 안전성을 설명할 때 “AI에게 보안을 적용해 달라고 요청했다”는 대화기록만으로는 실제 상태를 확인하기 어렵습니다.

현업 보안검토에서는 배포된 시스템의 결과물을 확인합니다.

데이터베이스에서는 RLS 활성화 상태와 정책 SQL, 역할별 권한, 관리키 사용 위치가 자료가 됩니다.

애플리케이션에서는 서버 라우트의 인증·인가 로직, 공개 번들에 포함된 변수, 관리자 기능의 권한검사가 확인 대상이 됩니다.

배포환경에서는 프로덕션·프리뷰·개발 환경의 분리, Deployment Protection, 환경변수 범위, 과거 배포의 접근상태가 자료가 됩니다.

운영에서는 접속로그, 관리자 작업기록, 백업과 복구시험, 오류추적 시스템에 남는 개인정보가 확인됩니다.

공급망에서는 잠금파일, 패키지 목록, 비밀값 탐지, 취약점 스캔과 빌드출처가 사용됩니다.

자동화된 SAST·DAST·dependency scan은 알려진 유형을 찾습니다. RLS의 업무논리, 조직별 권한, 다른 사용자 데이터 접근 같은 문제는 역할을 나눈 실제 요청시험이 필요합니다.

개인정보가 들어가는 순간 성격이 달라진다

개인 메모도구와 공개 커뮤니티, 병원 예약, 채용, 결제 서비스는 같은 보안수준을 요구하지 않습니다.

이름과 이메일을 수집하면 개인정보 처리시스템이 됩니다. 건강, 금융, 신분증, 위치, 아동정보가 들어가면 사고 영향이 더 커질 수 있습니다.

바이브코딩 도구가 개인정보 처리방침 페이지를 자동 생성할 수 있습니다. 실제 데이터 흐름, 보유기간, 국외처리, 수탁자와 삭제기능이 문구와 일치하는지는 시스템에서 확인해야 합니다.

테스트 단계에서 실제 고객 명단을 넣은 내부 도구도 유출 대상이 될 수 있습니다. 공개 앱 노출 조사에서 내부 문서와 고객 상담기록이 발견된 이유도 배포의 편리함과 데이터 사용이 빠르게 결합됐기 때문입니다.

바이브코딩 웹의 위험을 한 문장으로 설명하기 어려운 이유

바이브코딩 앱에 취약점이 생기는 경로는 여러 층에 존재합니다.

정리

Supabase와 Vercel은 바이브코딩 웹에 자주 사용되는 강력한 플랫폼입니다. 두 서비스의 사용 자체가 취약점을 의미하지 않습니다.

이 조합에서는 브라우저가 Supabase 공개 API를 직접 사용할 수 있어 RLS가 핵심 권한경계가 됩니다. 공개용 anon·publishable key는 RLS와 함께 쓰도록 설계됐습니다. secret·service_role 키는 RLS를 우회하므로 서버 환경에만 존재해야 합니다.

Vercel 환경변수는 저장 시 암호화됩니다. `NEXT_PUBLIC_` 접두사가 붙은 값은 클라이언트 번들에 들어갑니다. 프리뷰와 프로덕션 배포의 접근범위는 Deployment Protection 설정에 따라 달라집니다.

2025년 등록된 CVE-2025-48757은 Lovable 생성 사이트의 불충분한 RLS 정책으로 인증 없는 데이터베이스 읽기·쓰기 가능성을 기록했습니다. 공급업체는 고객 책임을 이유로 설명에 이견을 제기했습니다.

Base44에서는 비밀값이 아닌 앱 ID를 이용해 비공개 앱의 인증을 우회할 수 있는 플랫폼 취약점이 발견됐고 24시간 안에 수정됐습니다. 과거 악용 증거는 확인되지 않았다는 사업자 설명이 공개됐습니다.

Replit은 Agent가 운영 데이터베이스의 데이터를 삭제한 사건을 인정했습니다. 이후 개발·운영 데이터베이스 분리, Agent의 운영 DB 접근 제한과 스냅샷 복구 기능을 강화했습니다.

Wiz는 바이브코딩 앱에서 클라이언트 인증, 하드코딩된 비밀값, 개방된 데이터 정책, 공개된 내부 앱을 반복적으로 확인했습니다. RedAccess는 공개 앱 탐색에서 기업용 앱과 민감정보 노출을 다수 발견했다고 발표했습니다.

AI 생성 코드는 기능적으로 작동해도 보안시험에서 실패할 수 있습니다. Veracode 평가에서는 코드 표본 45%가 보안시험을 통과하지 못했습니다. 학술연구도 기능 정답률과 보안 정답률 사이의 큰 차이를 보고했습니다.

바이브코딩 웹의 보안은 프롬프트의 품질만으로 결정되지 않습니다. 배포된 코드, Supabase 정책, Vercel 설정, 비밀키 위치, 패키지, 로그, 백업과 실제 권한시험에서 확인됩니다.

참고자료

NVD - Lovable RLS 취약점 CVE-2025-48757

Wiz Research - Base44 비공개 앱 인증 우회 취약점

Wiz Research - 바이브코딩 앱에서 확인된 네 가지 공통 보안위험

Replit - Agent 데이터 삭제 사건과 안전조치 설명

Replit - 스냅샷 엔진과 개발·운영 데이터베이스 분리

RedAccess - Shadow Builders 공개 앱 조사

WIRED - 바이브코딩 앱의 공개 데이터 노출 조사

Veracode - 2025 GenAI Code Security Report 주요 결과

학술 프리프린트 - Is Vibe Coding Safe?

학술 프리프린트 - Understanding the (In)Security of Vibe-Coded Applications

Supabase - Row Level Security 공식 문서

Supabase - 공개키와 secret·service_role 키 공식 설명

Supabase - 데이터 보호 구성 공식 문서

Supabase - Edge Function 비밀값과 환경변수

Supabase - Edge Function 인증 방식

Supabase - Storage RLS 접근통제

Vercel - 환경변수 공식 문서

Vercel - Sensitive 환경변수

Vercel - Next.js 공개 환경변수 접두사

Vercel - Deployment Protection

Vercel - Rate Limiting

GitHub - 비밀값 탐지 구조

TrendAI - 패키지 환각과 slopsquatting 연구