바이브코딩으로 만든 앱, 그냥 배포해도 되나 — 프롬프트와 프로덕션 사이의 검증 공백

어떤 문제인가

바이브코딩의 약속은 단순하다. 말로 설명하면 앱이 나온다. 디자이너도, 마케터도 코드 한 줄 안 짜고 동작하는 소프트웨어를 만든다. 문제는 “동작한다”와 “배포해도 된다”가 전혀 다른 말이라는 점이다. 카네기멜런 연구에서 AI 생성 코드의 61%는 제대로 작동했지만 보안 리뷰를 통과한 건 10.5%뿐이었다. 비개발자는 이 간극을 볼 눈이 없다. 화면에 결과가 뜨면 끝난 줄 안다. 그 뒤에 하드코딩된 데이터베이스 비밀번호가 들어 있는지, 입력값 검증이 빠져 인젝션이 열렸는지, 아예 존재하지도 않는 패키지 이름을 import 하는지는 보이지 않는다. Escape.tech가 5,600개 바이브코딩 앱을 훑었더니 400건 넘는 시크릿과 175건의 개인정보가 그대로 노출돼 있었다. 만든 사람은 그 사실을 모른 채 ‘배포’를 눌렀다.

왜 지금인가

도구는 이미 대중화됐는데, 그걸 막아설 관문이 없다. 스택오버플로 2025 개발자 설문에서 AI 도구를 쓰거나 쓸 계획이라는 응답이 84%까지 올랐지만, AI 정확도를 신뢰한다는 응답은 33%로 떨어졌고 적극적으로 불신한다는 쪽이 46%로 더 많았다. 전문 개발자조차 “거의 맞는데 정확히는 아닌” 코드(응답자 66%가 지목)와 씨름하는 마당이다. 비개발자에겐 이걸 가려낼 도구가 아예 없다. 동시에 위험은 측정 가능한 속도로 커지고 있다. 조지아공대의 Vibe Security Radar는 2025년 5월 6건이던 AI 생성 코드 유래 CVE가 2026년 3월 74건으로 늘었다고 집계했다. 가트너는 2028년까지 프롬프트-투-앱 방식이 소프트웨어 결함을 2,500% 늘릴 거라 내다봤다. 만들기는 쉬워지는데 검증은 그대로면, 그 사이가 곧 사업이다.

어떻게 만들 수 있나

비개발자가 배포 버튼을 누르는 그 지점에 게이트를 끼운다. 기존 SAST·시크릿 스캐너를 비개발자용으로 번역하는 게 핵심이다. CVE 번호나 CWE 코드를 들이밀면 안 된다. “데이터베이스 비밀번호가 코드에 그대로 적혀 있어요. 이대로 올리면 누구나 볼 수 있습니다 — 고치고 올릴까요?”처럼, 위험을 사람 말로 바꾸고 한 번 클릭으로 자동 수정까지 제안한다. 통합 지점은 배포 훅이다. Vercel·Netlify·Firebase·Replit 배포 직전에 끼어들어 통과 못 한 빌드를 멈춘다. 차별화는 셋이다. 하드코딩 시크릿·인젝션·환각 패키지(2.23백만 샘플 중 19.7%가 존재하지 않는 패키지명을 포함했다)처럼 바이브코딩이 유독 잘 내는 결함에 특화한 룰셋, 비개발자가 읽고 바로 행동하는 리포트, 그리고 막는 데 그치지 않고 고쳐 주는 자동 리메디에이션.

성공 조건

이건 개발자용 보안 도구의 카피가 되면 죽는다. Snyk·Semgrep은 이미 있다. 살아남으려면 “코드를 못 읽는 사람”을 유일한 고객으로 못 박아야 한다. 영업은 바이브코딩 플랫폼 자체를 향한다 — 이들은 자기 사용자가 사고 치는 걸 두려워하므로, 검증 게이트를 기본 탑재하고 싶어 한다. 그래서 B2B2C로 플랫폼에 OEM 납품하는 길이 가장 빠르다. 위험은 분명하다. Replit·Lovable 같은 플랫폼이 이 기능을 자체 내장하면 시장이 증발한다. 그러니 한 플랫폼에 종속되지 않는 횡단 표준, 그리고 여러 도구를 오가는 비개발자(오전엔 Lovable, 오후엔 Bolt)를 따라다니는 계정 단위 검증 이력으로 자리를 선점해야 한다. 게이트가 너무 빡세서 멀쩡한 배포까지 막으면 비개발자는 그냥 꺼 버린다. 오탐을 0에 수렴시키는 게 생존선이다.