Bob Starr는 바이브 코딩으로 "Boomberg"라는 웹사이트를 만들었다. 미국 세금이 어떤 테크 기업으로 흘러가는지 보여주는 서비스였고, 그는 완성 직후 바로 온라인에 올렸다. 문제는 몇 달 뒤에야 보였다. 숨어 있던 SQL injection 위험 때문에 공격자가 접근해서는 안 되는 데이터를 읽거나 바꿀 수 있었을지도 모른다.
The Verge가 짚은 위험은 "비전문가가 앱을 만든다"는 사실 자체가 아니다. 오히려 AI 덕분에 개인이 필요한 소프트웨어를 직접 만드는 흐름은 생산적이다. 진짜 문제는 개인용 도구가 어느 순간 공개 서비스가 되고, 그 안에 고객 로그나 의료 정보, 금융 기록, 내부 문서가 들어가는데도 만든 사람이 그 전환을 인식하지 못하는 데 있다.
사례는 이미 쌓이고 있다. PocketOS 창업자 Jer Crane은 AI 코딩 에이전트가 회사의 production database를 지웠다고 했고, Joe Procopio는 데모용 웹앱에 해커가 몰리자 서비스를 내렸다. AI 에이전트용 소셜 네트워크 Moltbook은 출시 며칠 만에 production database가 열려 있었다는 지적을 받았다. Wiz 연구진은 수만 개 이메일과 private message가 노출됐다고 봤고, Wired가 전한 Red Access 조사에서는 인기 바이브 코딩 도구로 만든 공개 앱 약 5,000개가 인증 없이 접근 가능했으며 그중 2,000개 가까이가 민감 데이터를 흘리는 것으로 보였다.
흥미로운 지점은 보안 도구가 없어서만 생기는 문제가 아니라는 점이다. Claude Code에는 /security-review가 있고, Codex Security처럼 커밋을 스캔하고 패치를 다시 검토하는 흐름도 있다. 하지만 이런 장치는 대체로 PR, commit, review, CI가 있는 개발 습관 위에서 잘 작동한다. 채팅창에서 앱을 만들고 로컬 실행만 확인한 뒤 바로 클라우드에 올리는 사람에게는 자동 안전망이 아니다.
그래서 바이브 코딩의 다음 과제는 더 똑똑한 플러그인 하나가 아니다. 실행 모델을 바꿔야 한다. 앱을 만들기 전에 어떤 데이터가 저장되는지, 누가 접근할 수 있는지, 인증이 빠지면 무엇이 노출되는지부터 적어야 한다. 배포 직전에는 SQL query, admin route, file upload, env var, DB 권한을 따로 확인해야 한다.
개인용 앱과 남의 데이터를 담는 서비스는 같은 기준으로 볼 수 없다. AI가 코드를 빨리 만들어줄수록 공개 결정은 더 느려져야 한다. 이제 중요한 능력은 앱을 순식간에 완성하는 재주만이 아니라, 인터넷에 올리기 전에 멈춰서 위험을 읽는 습관이다.