바이브 코딩 앱 10%에 보안 구멍: 47억 달러 시장의 첫 번째 위기
1,645개 앱을 스캔했더니 170개가 뚫렸다
바이브 코딩 시장이 47억 달러(약 6.4조 원) 규모에 연간 38% 성장률을 찍고 있다. 근데 이 성장의 이면에서 첫 번째 대형 보안 사고가 터졌다. 보안 연구팀 Escape가 Lovable 플랫폼에서 생성된 앱 1,645개를 분석한 결과, 170개(10.3%)에서 Supabase Row-Level Security(RLS) 설정이 완전히 빠져 있었거든요. 단순한 설정 실수가 아니라, AI가 생성한 코드에서 보안이 구조적으로 누락된 거다.
더 넓게 보면 상황이 심각합니다. 바이브 코딩으로 만든 앱 5,600개를 조사했을 때 2,000개 이상의 취약점, 400개 이상의 노출된 시크릿 키, 175건의 개인정보 유출이 발견됐다. 한 앱에서만 18,000명의 사용자 데이터가 새어나간 사례도 있었죠.
왜 바이브 코딩에서 보안이 빠지는가
문제의 핵심은 AI 코드 생성기가 '작동하는 코드'와 '안전한 코드'를 구분하지 못한다는 점입니다. Supabase 인증 정보가 클라이언트 번들에 그대로 노출되는 실수가 바이브 코딩 앱의 80%에서 반복되고 있는데요, DevTools만 열면 누구나 볼 수 있는 수준이다. AI는 프롬프트에 "보안 설정해줘"라고 명시하지 않으면 RLS를 알아서 적용하지 않거든요.
이건 바이브 코딩만의 문제가 아니라 AI 코드 생성 전반의 구조적 한계다. Getautonoma 조사에 따르면 AI가 생성한 코드의 53%에 보안 취약점이 있다고 합니다. 코드가 돌아가는 것과 프로덕션에 올릴 수 있는 건 완전히 다른 문제죠.
Google Antigravity — 바이브 코딩의 다음 단계인가
이런 와중에 Google이 3월 18일 AI Studio에 풀스택 바이브 코딩 경험을 출시했다. Antigravity라는 코딩 에이전트가 핵심인데요, 텍스트 프롬프트만으로 React, Angular, Next.js 앱을 통째로 만들어준다. 제가 주목하는 건 Firebase 자동 통합 부분입니다. 앱에 데이터베이스나 사용자 인증이 필요하면 Antigravity가 감지해서 Cloud Firestore와 Firebase Authentication을 자동 연결하거든요.
Lovable 보안 사태와 비교하면 방향성이 다르다. Google은 보안 설정을 사용자에게 떠넘기지 않고 에이전트가 자동으로 처리하는 쪽을 택했다. 내부적으로 이미 수십만 개의 앱을 이 방식으로 빌드했다고 합니다. 근데 Antigravity도 결국 Firebase 생태계에 종속된다는 점은 알고 가야 하죠.
Cursor 20억 달러, 바이브 코딩 도구 전쟁 격화
3월 초 Cursor가 연간 반복 매출(ARR) 20억 달러(약 2.7조 원)를 돌파했다는 보도가 나왔다. Claude Code가 연간 25억 달러 규모인 걸 감안하면, 두 도구가 시장을 양분하는 구도가 확실해졌죠. 미국 개발자 92%가 어떤 형태로든 바이브 코딩을 쓰고 있고, 전체 코드의 41%가 AI 생성이라는 수치가 이 시장의 규모를 말해줍니다.
바이브 코딩 사용자의 63%가 비개발자라는 통계도 있는데요, 이게 보안 문제가 더 심각해질 수밖에 없는 구조적 이유다.
한국 개발자에게 이게 뭘 의미하나
Google Antigravity는 한국어 프롬프트를 지원하고, Firebase도 한국 카드 결제가 가능합니다. Spark 무료 플랜으로 시작할 수 있어서 진입 장벽이 낮죠. Cursor는 월 $20(약 27,000원) Pro 플랜, Claude Code는 Claude Max 구독($100~200/월, 약 13.7만~27.4만 원)으로 사용 가능합니다.
근데 한국에서 바이브 코딩으로 만든 앱을 실서비스에 올리려면 개인정보보호법을 반드시 체크해야 한다. RLS가 빠진 앱으로 한국 사용자 데이터가 노출되면 과징금이 매출액의 3%까지 나올 수 있거든요. 국내 대안으로는 네이버 클라우드의 CLOVA Studio가 있지만, 풀스택 바이브 코딩까지는 아직 지원하지 않는 상황이다.
이건 쓰지 말아야 하는 경우
사용자 인증이나 결제가 포함된 앱을 바이브 코딩만으로 프로덕션에 배포하면 안 됩니다. Lovable 사태가 증명했듯이, AI가 생성한 보안 설정을 검증 없이 신뢰하는 순간 사고가 난다. 의료, 금융, 교육 분야처럼 개인정보를 다루는 서비스는 반드시 보안 전문가의 감수를 거쳐야 하거든요.
바이브 코딩은 프로토타이핑과 내부 도구에서 가장 안전하게 쓸 수 있다. MVP를 빠르게 만들어서 투자자에게 보여주는 용도로는 최적이지만, 그걸 그대로 실서비스에 올리는 건 다른 문제죠.
Fortune이 정의한 'Supervisor Class'
Fortune이 오늘(3월 31일) 발행한 기사에서 개발자의 미래를 'Supervisor Class'로 정의했다. 코드를 직접 쓰는 대신 AI 에이전트를 감독하고 오케스트레이션하는 역할로 가치가 이동한다는 분석인데요, 사실 이미 현장에서 벌어지고 있는 일이다. 문제는 감독자가 코드를 읽을 줄 모르면 감독이 안 된다는 거죠.
비개발자 63%가 바이브 코딩을 쓰는 지금, 이 감독 공백이 Lovable 같은 보안 사고로 이어지고 있다. 속도만 올리고 검증은 빼먹는 패턴이 반복되고 있거든요.
내 판단 — 속도를 늦추라는 게 아니다
바이브 코딩 자체를 멈출 필요는 없습니다. 47억 달러 시장이 38% 성장하는 건 실제 생산성 향상이 뒷받침되기 때문이죠. 근데 '만들었으니 배포한다'가 아니라 '만들었으니 검증한다'로 흐름을 바꿔야 한다. Google이 Antigravity에서 보안 자동화를 기본 내장한 건 올바른 방향이고, 이게 업계 표준이 될 겁니다.
보안 검증 없는 바이브 코딩은 브레이크 없는 차와 같거든요. Supervisor Class가 되려면 AI가 만든 코드의 보안 감수 능력이 첫 번째 자격 요건이다.
바로 실행할 한 가지
지금 바이브 코딩으로 만든 프로젝트가 있다면, Supabase 대시보드에서 RLS가 활성화되어 있는지 확인하세요. Table Editor에서 각 테이블의 RLS Policies를 열면 30초면 확인할 수 있습니다. 정책이 비어 있으면 즉시 추가해야 한다. Lovable을 쓰고 있다면 무료 보안 스캔 기능을 배포 전에 반드시 돌리세요. 이 한 단계가 18,000명 데이터 유출과 정상 운영의 차이를 만들거든요.
