Cursor · Claude Code · Bolt 기준
바이브 코딩, 3개월 지나면 달라지는 이유
“코딩 몰라도 앱 만들 수 있다”는 말, 절반은 맞고 절반은 틀립니다.
처음 3개월은 생산성이 올라가지만, 그 이후에 뭔가 달라지기 시작합니다.
바이브 코딩이 3개월 만에 막히는 구조적 이유
바이브 코딩은 AI에게 원하는 걸 말로 설명하면 코드를 만들어주는 방식입니다. Cursor, Claude Code, Bolt, Replit 같은 도구들이 대표적이고, 2025년 초 OpenAI 공동창업자 안드레이 카르파티(Andrej Karpathy)가 이 용어를 처음 쓴 이후 빠르게 퍼졌습니다. 결론부터 말씀드리면, 초반 1~2개월은 놀라울 만큼 생산성이 오릅니다. 직접 코딩했다면 몇 주 걸릴 MVP를 주말 이틀 만에 만드는 것도 가능합니다.
그런데 문제는 딱 3개월 즈음에 시작됩니다. Red Hat Developer의 공식 아티클(2026.02.17)에는 이런 구절이 나옵니다. “기능 하나를 바꾸면 다른 네 개가 깨진다. AI에게 고쳐달라고 하면 또 다른 뭔가가 이상해진다.” 두더지 잡기 게임과 같아진다는 거죠. 이건 AI가 멍청해서가 아닙니다. 명세 없이 쌓인 코드가 아무도 전체를 파악하지 못하는 상태로 커졌기 때문입니다.
AI는 한 번에 볼 수 있는 컨텍스트 창 안에서만 작동합니다. 코드베이스가 수천 줄을 넘어가면 AI도 전체를 파악하지 못하고, 이전에 내린 결정을 기억하지 못한 채 새 코드를 만들어냅니다. 그때부터 프로젝트는 아무도 지도를 갖고 있지 않은 미로가 됩니다.
AI가 만든 코드 48%, 보안에서 구멍이 납니다
여기서 일반적인 기대를 정면으로 뒤집는 수치가 등장합니다. 많은 분들이 “AI가 만든 코드니까 보안 패턴도 잘 지키겠지”라고 생각합니다. 실제로는 정반대입니다.
| 취약점 유형 | 실패율 | 출처 |
|---|---|---|
| XSS (크로스사이트 스크립팅) | 86% | Contrast Security |
| 로그 무결성 | 88% | BaxBench Analysis |
| 전체 보안 취약점 포함 | 45~48% | Veracode 2025 Report / Azati 2026 |
| API 공개 접근 허용 | 57% | Azati 보안 분석 2026 |
| API 인증 미흡 | 89% | Azati 보안 분석 2026 |
보안 스타트업 텐자이(Tenzai)는 2025년 12월, Claude Code·OpenAI Codex·Cursor·Replit·Devin 5종 도구로 테스트 앱 15개를 만들어 분석했습니다. 총 69개의 취약점이 발견됐고, 이 중 6개는 ‘치명적(Critical)’ 등급이었습니다. (출처: Tenzai Labs 블로그, blog.tenzai.com, 2026.01 기준) 이게 뜻하는 바는 단순합니다. AI는 SQL 인젝션이나 XSS처럼 패턴이 정형화된 문제는 비교적 잘 피하지만, ‘이 요청이 정상적인 요청인가 아닌가’를 판단해야 하는 비즈니스 로직 영역에서는 사람의 직관을 대체하지 못합니다.
Stack Overflow 블로그(2026.01.02)에 실린 비개발자의 바이브 코딩 체험기가 이 부분을 잘 보여줍니다. Bolt로 간단한 앱을 만들었는데, 기술 전문가가 브라우저 개발자 도구만 열어봤더니 “아무런 보안 기능이 없어서 저장된 데이터에 누구나 접근할 수 있다”는 사실이 바로 드러났습니다. 앱이 겉으로는 잘 돌아갔지만, 껍데기 안은 비어있었던 겁니다.
기술부채가 선형이 아닌 복리로 쌓이는 이유
💡 공식 발표 자료와 현장 사례를 같이 놓고 보니, 바이브 코딩의 속도 이점이 왜 일정 시점 이후 반전되는지 숫자로 보이기 시작했습니다.
기술부채는 원래 있는 개념입니다. “지금 빠르게 짜고 나중에 정리하자”는 방식이죠. 그런데 바이브 코딩으로 만든 코드의 기술부채는 일반적인 기술부채와 성격이 다릅니다. Towards AI 아티클에는 이 표현이 나옵니다. “AI가 만든 기술부채는 선형으로 쌓이지 않고 지수적으로 복리가 붙는다.” 이게 왜냐면, AI가 이미 AI가 만든 엉망인 코드를 문맥으로 학습해서 다음 코드를 만들기 때문입니다. 상태가 나쁜 코드일수록 AI가 다음에 더 나쁜 제안을 해옵니다.
Azati의 실제 사례가 이 패턴을 명확하게 보여줍니다. AI 코딩 도구를 공격적으로 도입한 중간 규모 SaaS 회사의 6개월 데이터입니다. 1~3개월 동안은 기능 개발 속도가 55% 올라갔습니다. 그런데 4~6개월에 접어드니 프로덕션 장애가 180% 늘고, 고객이 보고하는 버그는 220% 증가했습니다. 개발자들이 버그 수정에 쓰는 시간 비중은 20%에서 65%로 뛰었습니다. 결국 AI 도입 전보다 순수 기능 배포 속도가 더 느려졌습니다. (출처: Azati, ‘The Hidden Cost of Vibe Coding Without Code Review’, 2026.03.16)
이 수치가 말하는 핵심은 간단합니다. 처음 3개월은 속도 이득이 실재하지만, 그 이득이 나중 비용으로 전환될 뿐입니다.
속도가 오히려 느려지는 역설, 수치로 확인했습니다
바이브 코딩의 역설 중 하나는 “생산성 세금(Productivity Tax)”입니다. Stack Overflow 개발자 설문(2025)에 따르면, AI 코딩 도구를 쓰는 개발자의 66%가 이 세금을 경험합니다. AI가 뱉어낸 코드가 거의 맞는데 딱 맞지는 않는 상태, 그걸 고치는 데 쓰는 시간이 결국 직접 짜는 것보다 더 걸린다는 거죠. (출처: Stack Overflow Developer Survey 2025, survey.stackoverflow.co/2025)
💡 “84%의 개발자가 AI 도구를 쓰는데, 그 코드를 실제로 신뢰한다는 사람은 29%뿐”이라는 수치를 같이 놓으면, 나머지 55%는 신뢰하지 않으면서도 그냥 배포하고 있다는 얘기입니다. 이유는 조직이 속도를 기준으로 성과를 측정하기 때문입니다.
MIT Technology Review(2025.12.15)가 정리한 또 다른 문제는 LLM의 컨텍스트 창 한계입니다. 코드베이스가 커지면 AI는 자신이 이전에 뭘 했는지 잊어버립니다. 그래서 같은 기능을 두 군데에서 다른 방식으로 구현하거나, 기존에 있는 함수를 무시하고 새로 만드는 일이 생깁니다. Red Hat Developer(2026.02.17)는 이걸 “functionality flickering”이라고 불렀습니다. 버튼 색깔이 어제는 파랑이었다가 오늘은 초록이 되는 식으로, 명세가 없으니 AI가 매번 다르게 채워 넣는 겁니다.
2026년 기준 코드 변경률(Code Churn)이 전년 대비 2배로 늘고, 배포 안정성은 7.2% 하락했다는 Azati 분석이 이 맥락을 뒷받침합니다. 코드를 더 많이 바꾸면서 더 자주 깨지는 상황입니다.
AI 패키지 환각 — 아무도 말 안 해주는 공격 경로
이건 대부분의 바이브 코딩 입문 글에서 빠져있는 내용입니다. AI가 코드를 짜다가 존재하지 않는 라이브러리 이름을 제안하는 경우가 있습니다. 이걸 “패키지 환각(Package Hallucination)”이라고 합니다. 문제는 이게 단순한 실수로 끝나지 않는다는 점입니다.
공격자들이 AI가 자주 환각으로 만들어내는 패키지 이름을 미리 모니터링하다가, 그 이름으로 악성 패키지를 NPM이나 PyPI에 등록해 놓습니다. 개발자가 아무 의심 없이 npm install을 실행하면 악성코드가 설치됩니다. (출처: Databricks Security Blog, ‘Passing the Security Vibe Check’, 2026 기준) 이건 개발자가 부주의해서 생기는 문제가 아닙니다. AI가 자신감 있게 제안한 패키지를 그대로 쓴 결과입니다.
Natively.dev의 2026년 분석에 따르면, 이 경로로 들어온 악성코드는 탐지하기가 특히 어렵습니다. 정상적인 라이브러리처럼 보이기 때문입니다. 바이브 코딩의 “코드를 몰라도 된다”는 전제가 오히려 이런 경로를 더 위험하게 만듭니다.
그래도 쓸 수 있는 조건은 따로 있습니다
솔직히 말하면, 바이브 코딩이 아예 쓸모없는 건 절대 아닙니다. 분명히 빛나는 조건이 있습니다. Red Hat Developer(2026.02.17)가 제시한 기준이 현실적입니다. “단위 테스트로 검증할 수 있을 만큼 작은 범위라면 바이브해도 됩니다. 테스트로 검증할 수 없는 범위라면 명세가 필요합니다.” 이 기준 하나로 적용 범위가 꽤 명확해집니다.
프로토타입, 플래시카드 앱, 랜딩페이지, 데이터 분석용 스크립트, 내부 도구처럼 실제 사용자 데이터를 거의 다루지 않고 혼자 쓰거나 소수만 쓰는 경우라면 바이브 코딩은 여전히 강력한 무기입니다. 의료·금융·결제 흐름이 들어가거나, 장기적으로 팀이 유지보수해야 하는 프로덕션 서비스라면 얘기가 달라집니다. 기업 도입률을 보면 이 현실이 이미 반영되어 있습니다. 핀테크·금융 서비스는 34%, 헬스케어는 28%로 IT 스타트업(73%)과 비교해 절반도 되지 않습니다. (출처: Second Talent Statistics, secondtalent.com)
Amazon Kiro, GitHub Spec Kit처럼 “프롬프트 대신 명세서를 먼저 만들고, 명세서를 기준으로 코드를 생성하는” 도구들이 빠르게 성장하는 이유도 여기 있습니다. 바이브 코딩 다음 단계가 이미 시작된 겁니다.
Q&A
마치며
바이브 코딩은 분명히 실재하는 생산성 도구입니다. 아이디어를 빠르게 검증하고, 코딩 배경 없이 개념 증명을 만들고, 반복적인 단순 작업을 자동화하는 데 지금 이 순간도 잘 작동하고 있습니다. 이 부분을 부정하는 건 틀린 얘기입니다.
그런데 “빠른 시작”과 “지속 가능한 운영”은 다른 문제입니다. AI 코드 48%에 보안 취약점이 포함된다는 수치, 6개월 후 버그 220% 증가라는 사례, 기술부채가 지수적으로 복리가 붙는다는 구조, 그리고 아무도 잘 얘기 안 해주는 패키지 환각 공격 경로까지. 이 부분들을 알고 시작하는 것과 모르고 시작하는 것은 나중에 나오는 결과가 다릅니다.
바이브 코딩이 맞는 상황이 있고, 명세가 필요한 상황이 있습니다. 그 경계를 알고 쓰는 게 도구를 잘 쓰는 방법입니다.
본 포스팅 참고 자료
- Red Hat Developer — The Uncomfortable Truth About Vibe Coding (2026.02.17)
- Stack Overflow Blog — A New Worst Coder Has Entered the Chat (2026.01.02)
- Azati — The Hidden Cost of Vibe Coding Without Code Review (2026.03.16)
- Tenzai Labs — Bad Vibes: Comparing Secure Coding Capabilities (2026.01 기준)
- Natively.dev — Vibe Coding Limitations: What You Need to Know in 2026
- Stack Overflow Developer Survey 2025 (2026 포스팅 기준 인용)
본 포스팅 작성 이후 서비스 정책·UI·기능이 변경될 수 있습니다. 인용된 수치는 각 출처의 발표 시점 기준이며, 이후 업데이트된 연구 결과와 다를 수 있습니다. 보안 의사결정 전 반드시 최신 공식 문서를 함께 확인하시기 바랍니다.
댓글 남기기