바이브 코딩, 14개월 만에 벽을 만났다: 이제 진짜 시작이다

AI가 코드를 써주면 다 되는 줄 알았어요

솔직히 처음엔 저도 흥분했습니다.

프롬프트 하나 넣으면 앱이 뚝딱 나오고, 개발자 없이도 서비스가 만들어지는 세상이요. 2025년 초부터 유튜브, 링크드인, 개발자 커뮤니티 할 것 없이 "나 AI로 앱 만들었어"라는 글이 쏟아졌죠.

그런데 지금은요? 그 흥분의 뒷면이 슬슬 보이기 시작했습니다.

오늘은 바이브 코딩이 어떤 한계에 부딪혔는지, 그리고 그 다음에 어떤 판이 펼쳐지는지를 같이 짚어보려고 해요. AI 코딩 도구를 쓰고 있거나, 쓸 생각이 있다면 끝까지 읽어보시길 추천드립니다.

한 줄 정리: 바이브 코딩의 거품이 꺼지는 게 아니라, 이제 제대로 쓸 차례가 온 겁니다.

바이브 코딩이 대체 뭔가요?

바이브 코딩(Vibe Coding)이라는 이름은 테슬라 전 AI 수장이자 OpenAI 연구원 출신인 안드레이 카파시(Andrei Karpathy)가 붙였습니다. 2025년 초의 일입니다.

개념 자체는 간단해요. AI가 생성한 코드를 상세히 이해하지 않고 그대로 받아들이는 개발 방식입니다. 느낌(vibe) 대로 큰 그림만 제시하고, 나머지는 AI가 채우는 거죠.

"회원가입 기능 만들어줘", "결제 페이지 붙여줘" 같은 말 한마디로 앱이 생겨나는 마법입니다. Cursor, Lovable, GitHub Copilot, Bolt 같은 도구들이 이 흐름을 타고 엄청난 인기를 끌었죠.

실제 수치도 대단했어요. 2025년 기준 미국 개발자의 92%가 AI 도구를 사용하고, GitHub에 올라오는 커밋의 46%가 AI가 만든 코드라는 통계까지 나왔습니다. 개발 생산성은 최대 55% 향상됐다는 보고도 나왔고요.

그러니 흥분하지 않을 수가 없었겠죠.

한 줄 정리: 바이브 코딩은 AI를 도구로 쓰는 게 아니라, AI에게 개발을 통째로 맡기는 방식입니다.

14개월 만에 뭔가 이상해지기 시작했다

문제는 프로토타입 단계에서 실제 서비스로 넘어가는 순간 터졌습니다.

코드래빗(CodeRabbit)이 470개 오픈소스 GitHub PR을 분석한 결과, AI가 공동 작성한 코드는 사람이 만든 코드보다 보안 취약점이 2.74배 높게 나왔습니다. Stanford 연구에서는 AI가 생성한 코드의 40%에 보안 문제가 포함되어 있다는 결과도 나왔어요.

더 충격적인 건 따로 있습니다. 2025년 7월, AI 평가 기관 METR이 숙련된 오픈소스 개발자들에게 Cursor 같은 AI 도구를 쓰게 하면서 실제 태스크를 수행하게 했는데요. 결과가 어땠을까요? 개발자들은 스스로 24% 빨라질 거라 예측했지만, 실측은 오히려 19% 느려졌습니다.

왜냐고요? AI가 수천 줄 코드를 빠르게 만들어줘도, 그 코드를 검증하고 이해하는 데 훨씬 많은 시간이 들었기 때문입니다. 체감 생산성과 실제 생산성이 완전히 달랐던 거예요.

거기다 코드 품질 문제도 심각했습니다. 코드 중복은 4배로 증가하고, 코드 구조를 건강하게 유지해주는 리팩터링 비중은 2021년 25%에서 2024년 10% 이하로 급감했다는 분석도 나왔어요. 처음엔 안 보이지만, 6개월 뒤 유지보수 비용이 폭발적으로 늘어납니다.

한 줄 정리: 빠르게 만드는 것과, 오래 쓸 수 있는 것은 다른 이야기입니다.

Lovable 사건, 이건 그냥 경고가 아니었습니다

2025년, 바이브 코딩 플랫폼 중 큰 인기를 끌었던 Lovable로 만들어진 앱 1,645개를 분석했더니 170개에서 데이터베이스 보안 결함이 발견됐습니다. CVE-2025-48757이라는 공식 보안 취약점 번호까지 부여될 만큼 심각한 수준이었어요.

"해킹될 수도 있다"는 경고 수준이 아닙니다. 실제 서비스를 배포한 사람들의 사용자 데이터가 위험에 처한 겁니다.

보안 스타트업 텐자이(Tenzai)는 Claude Code, OpenAI Codex, Cursor, Replit, Devin 등 주요 바이브 코딩 도구 5종을 대상으로 동일한 앱 15개를 만들어봤습니다. 결과는 취약점 69개, 그중 6개는 치명적인 수준이었어요.

AI 코드 분석 업체 Apiiro는 2025년 6월 기준, AI가 생성한 코드가 한 달에 1만 건이 넘는 신규 보안 취약점을 발생시켰다고 발표했습니다. 6개월 만에 10배 증가한 수치입니다.

가장 흔한 취약점 유형은 세 가지입니다. 인증, 권한 처리 누락과 SQL 인젝션(악의적인 코드를 데이터베이스 쿼리에 삽입하는 공격), 그리고 API 키나 민감 정보를 코드에 직접 넣는 하드코딩입니다. 배포 후 평균 15분 내에 봇이 노출된 키를 탈취한다는 분석도 있어요.

AI는 "동작하는 코드"를 만들지, "안전한 코드"를 만들지는 않습니다.

한 줄 정리: 바이브 코딩의 첫 번째 메이저 보안 위기는 이미 터졌습니다. 모른 척할 수 없는 상황입니다.

사람들이 가장 많이 하는 착각

"AI 코딩이 문제라면, 그냥 안 쓰면 되지 않나요?"

아닙니다. 그게 오해예요.

바이브 코딩의 문제는 AI 자체가 아닙니다. "이해 없이 맹목적으로 쓰는 방식"이 문제입니다.

AI가 만든 코드를 검토하지 않고 그대로 배포하고, 보안 스캔을 건너뛰고, 테스트 없이 운영에 올리는 것. 이게 문제의 본질입니다.

또 하나의 착각은 "코드 중복이 좀 생기면 어때"입니다. 처음엔 보이지 않아요. 근데 6개월 뒤 유지보수 비용이 폭발합니다. 기술 부채라는 게 그런 식으로 쌓입니다.

국내에서도 바이브 코딩으로 만든 서비스를 배포했다가 데이터베이스가 통째로 공개되는 사건이 여러 차례 발생했습니다. 대한민국 사례만 해도 적지 않아요. 개발자, 운영자가 법적 책임을 지게 될 수도 있는 상황입니다.

"바이브 코딩은 제품을 만들 수 있다. 하지만 제품을 유지할 수는 없다."

이 한 문장이 지금 상황을 가장 정확하게 정리해줍니다.

한 줄 정리: AI 사용 자체가 문제가 아니라, 검증 없는 사용이 문제입니다.

개발자가 없어지는 게 아니라 역할이 바뀌는 겁니다

많은 분들이 묻습니다. "AI가 코딩을 다 해주면 개발자가 필요 없어지지 않나요?"

현실은 정반대로 가고 있어요.

AI가 코드를 만들수록, 그 코드를 평가하고 책임질 수 있는 사람이 더 중요해집니다. AI가 만든 코드의 구조를 파악하고, 보안 취약점을 잡아내고, 유지보수 가능한 형태로 다듬는 역할. 이게 앞으로 개발자의 핵심 역량이 됩니다.

비개발자도 마찬가지입니다. 바이브 코딩 도구로 앱을 만드는 것까지는 됩니다. 근데 그걸 실제 서비스로 배포하고 사용자 데이터를 다루는 순간, 최소한의 코드 이해와 검증 절차는 필수입니다.

"만들 수 있는 것"과 "책임질 수 있는 것"은 다른 이야기입니다.

AI 시대의 개발자는 코드를 짜는 사람이 아니라, AI를 지휘하고 결과물을 책임지는 사람입니다. 이 역할을 제대로 이해하는 사람이 앞으로 훨씬 더 귀해질 거예요.

한 줄 정리: AI 코딩이 대중화될수록, 그걸 제대로 검증할 수 있는 사람의 가치가 올라갑니다.

그럼 앞으로 어떻게 써야 할까요?

세 가지로 정리할 수 있어요.

첫째, 프롬프트 전에 설계를 먼저 합니다. "SaaS 하나 만들어줘" 같은 막연한 지시가 아니라, 기능 명세, 데이터 모델, 보안 가이드라인을 먼저 정리하고 AI에게 작업을 맡깁니다. 설계 없는 프롬프트는 설계 없는 개발과 똑같습니다.

둘째, AI 코드를 검증되지 않은 코드로 취급합니다. AI가 만들었어도 출처 불명의 코드와 동일하게 다뤄야 해요. 보안 스캔, 코드 리뷰, 테스트를 반드시 거칩니다. OWASP Top 10 체크리스트 기준으로 정적 분석 도구를 배포 전에 돌리는 게 기본이 됩니다.

셋째, 한 번에 완성하려 하지 않습니다. "프롬프트 한 번으로 전체 완성"이 아니라, 기능 단위로 만들고 이해하면서 붙여나가는 방식이 오래갑니다. 각 단계마다 이해가 전제되어야 다음 단계로 넘어갈 수 있어요.

AI를 설명 받는 도구가 아니라, 지휘하는 도구로 써야 한다는 말의 의미가 이겁니다.

한 줄 정리: 빠르게 만드는 것보다 오래 쓸 수 있는 것을 목표로 삼아야 합니다.

마무리

14개월 만에 한계가 드러났다고 해서 바이브 코딩이 실패한 건 아닙니다. 오히려 이 한계 덕분에 제대로 된 활용법을 배울 기회가 생겼다고 봐야 해요.

설계를 먼저 하고, AI를 지휘하고, 결과물을 검증하는 것. 이게 다음 판의 룰입니다.

AI 코딩의 진짜 시작은 맹목적인 흥분이 가라앉은 지금부터입니다. "얼마나 빠르게 만드느냐"가 아니라 "얼마나 책임질 수 있느냐"가 핵심 역량이 되는 시대, 지금 바로 그 전환점에 서 있습니다.