본문은 요즘IT와 번역가 Yuna가 함께 아메드 하프디(Ahmed Hafdi)님의 글 <Vibe Coding Is Over. What Comes Next Is Much Harder.>를 번역한 글입니다. 필자는 모로코 라바트(Rabat)를 기반으로 활동하는 소프트웨어 엔지니어이자 데이터 사이언티스트로, 풀스택 개발과 머신러닝, AI 분야에 관심을 가지고 다양한 글을 발표해 왔습니다.

이 글은 안드레 카파시(Andrej Karpathy)가 명명한 바이브 코딩(vibe coding)이 불과 14개월 만에 한계를 드러낸 과정을 담고 있습니다. 수치와 실제 사례를 바탕으로 AI가 생성한 코드가 실제 프로덕션 환경에서 어떤 문제를 만들어냈는지 짚고, 이제 개발자들이 AI를 어떻게 다뤄야 하는지 구체적인 방향을 제시합니다.

필자에게 허락을 받고 번역했으며, 글에 포함된 링크는 원문에 따라 표시했습니다.

"설명만 하면 배포"의 시대, 한동안 잘 굴러갔습니다. 무엇이 그 시대를 끝냈고, 지금 진짜 판은 어떻게 돌아가는지 정리했습니다.

꽤 그럴듯한 환상이었습니다. 아이디어를 설명하면 AI가 코드를 만들어줍니다. 프로젝트에 붙여 넣고 브라우저를 새로고침하면, 앱이 돌아갑니다. CS 학위도, Stack Overflow를 뒤질 일도, 새벽 2시에 디버깅할 일도 없었죠. 바이브만 있으면 됐습니다.

이 환상에는 이름도 있었습니다. OpenAI 공동 창업자이자 전 테슬라 AI 총괄이었던 안드레이 카파시(Andrej Karpathy)가 2025년 2월에 붙인 이름, 바이브 코딩(vibe coding)이었는데요. 모든 줄을 이해하지 못해도 AI가 생성한 코드를 그대로 받아들이는, "바이브에 완전히 몸을 맡기는" 개발 방식을 뜻했습니다. Collins 사전은 이 단어를 2025년 올해의 단어로 선정하기도 했죠.

그리고 14개월이 지난 지금, 후폭풍이 오고 있습니다.

이 꿈을 만든 숫자들

먼저 이 흐름이 얼마나 빨랐는지부터 짚어보겠습니다.

Y Combinator 2025년 윈터 배치에서는 스타트업의 25%가 코드베이스의 95% 이상을 AI로 만들었습니다. GitHub에 따르면 지금 커밋되는 신규 코드의 46%가 AI 생성 코드입니다. 한 분석에서는 미국 개발자의 92%가 매일 AI 코딩 도구를 쓰는 것으로 나타났죠. Cursor, Replit, Bolt, Lovable 같은 도구들은 수십억 달러의 벤처 투자를 받았고, 시장 규모는 2026년 기준 47억 달러, 내년에는 123억 달러에 이를 전망입니다.

일시적인 유행이 아니었습니다. 개발자들은 AI의 도움을 받아 25~55% 더 빠르게 일을 끝냈습니다. AI 결과물을 제대로 평가할 수 있는 시니어 엔지니어들은 생산성이 최대 81%까지 올랐다고 보고했고요. 비개발자들도 예전에는 만들 수 없었던 앱을 만들어냈습니다. 소프트웨어 제작의 민주화라는 약속은, 어느 정도 실제로 지켜지고 있었던 거죠.

그런데 뭐가 잘못된 걸까요?

아무도 꺼내고 싶어 하지 않던 이야기

2025년 12월, 한 리서치 회사가 오픈소스 GitHub 풀 리퀘스트 470건을 분석했습니다. 결과는 꽤 당혹스러웠습니다. AI가 공동 작성한 코드에는 사람이 쓴 코드보다 주요 이슈가 1.7배 더 많았습니다. 로직 오류는 더 자주 나왔고, 설정 오류는 75% 더 많았으며, 보안 취약점은 사람이 쓴 코드의 2.74배에 달했죠.

그리고 Lovable 사건이 터졌습니다. Lovable은 가장 인기 있는 바이브 코딩 플랫폼 중 하나입니다. 비개발자도 프롬프트만으로 실제 웹 앱을 만들 수 있게 해주는 서비스죠. 보안 연구자들이 Lovable로 만든 앱 1,645개를 조사한 결과, 170개(10%가 넘는 수치)의 데이터베이스 설정에 치명적인 Row-Level 보안 결함이 있었습니다. 테스트용 앱이 아니라, 실제 사용자 데이터를 다루는 앱들이었습니다. 기본적인 공격 스킬만 있어도 누구나 접근할 수 있는 상태였죠.

이 취약점에는 CVE-2025–48757이라는 번호까지 부여됐습니다. 바이브 코딩 업계의 첫 메이저 보안 위기가 온 겁니다.

예외는 아니었습니다. 보안 회사 Tenzai는 별도 테스트에서 많이 쓰는 바이브 코딩 도구 다섯 개(Claude Code, OpenAI Codex, Cursor, Replit, Devin)로 동일한 앱 15개를 만들어봤는데요. 결과는 취약점 69개, 그중 6개는 치명적인 수준이었습니다.

코드 변경 빈도는 41% 늘었습니다. 코드 중복은 4배로 증가했고요. 코드베이스를 건강하게 유지해주던 꼼꼼한 리팩터링은 무너졌습니다. 2021년에는 변경된 라인의 25%가 리팩터링이었지만, 2024년에는 10% 아래로 떨어졌죠. 2026년 1월에 나온 한 학술 논문은 바이브 코딩이 핵심 인프라를 지탱하는 메인테이너들과 개발자들의 접점을 줄이면서 오픈소스 생태계를 조용히 무너뜨리고 있다고까지 주장했습니다.

속도는 얻었습니다. 대신 품질과 보안, 장기적인 유지보수 가능성을 내줬죠.

"바이브 코딩이 끝났다"는 말의 진짜 의미

이 지점에서 오해가 가장 많이 생기니 정확히 짚고 넘어가죠. 카파시가 원래 정의했던 의미의 바이브 코딩, 즉 AI 결과물을 검토 없이 받아들이고 넘어가는 방식은, 실무에서 쓸 수 있는 방식으로는 수명을 다했습니다. 도구가 나빠져서가 아니라, 현실이 그 한계를 드러냈기 때문이죠.

프로덕션에 올리자 앱이 터졌습니다. 보안 구멍이 발견됐고요. 코드베이스는 유지보수가 불가능해졌습니다. 엔지니어링 지식이 전혀 없어도 스타트업이 주말 안에 프로토타입을 띄울 수는 있습니다. 하지만 실제 사용자가 들어와 예상치 못한 행동을 하기 시작하면, AI가 만들어놓은 뼈대는 대부분 버텨주지 못했습니다.

이 흐름을 한 줄로 압축한 표현이 있습니다.

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

끝나는 건 AI 보조 개발이 아닙니다. AI 보조 개발은 앞으로도 남을 거고, 오히려 더 강력해지는 중이죠. 끝나는 건 "이해 없이 바이브만으로 밀어붙일 수 있다"는 생각입니다. 지금 상황을 가장 정직하게 요약하면 이렇습니다. 거대한 프롬프트 하나로 밀어붙이던 시대는 끝났습니다. 이제는 작업을 잘게 쪼개 설계하는 시대죠.

새로운 판의 시작, 바이브를 설계하기

2026년에 실제로 잘나가는 개발자들은 이 사실을 이미 파악했습니다.

개발자라는 역할은 사라지지 않았습니다. 바뀌었을 뿐이죠. 지금 가장 가치 있는 엔지니어는 가장 많은 줄의 코드를 짜는 사람이 아닙니다. AI를 효과적으로 지휘하고, 그 결과물을 평가할 수 있는 사람입니다. 아키텍처에 대한 판단력, 보안에 대한 직관, 복잡한 시스템을 AI가 건드리기 전에 검토 가능한 단위로 분해하는 능력 같은 것들이죠.

반복해서 나오는 비유가 있습니다. 이제 당신은 조각가고, AI는 점토라고요. 실제로 현장에서는 이런 모습입니다.

프롬프트 전에 설계부터 합니다

2026년에 안정적으로 소프트웨어를 출시하는 팀들은 Cursor를 열고 "SaaS 하나 만들어줘"를 치지 않습니다. AI에 뭔가 넘기기 전에 먼저 기술 PRD(제품 요구사항 문서)를 쓰는데요. 데이터 모델, 연동 포인트, 보안 가드레일을 정의해둡니다. 맥락이 충분히 주어졌을 때 AI는 훨씬 빨라지거든요.

AI 코드는 검증되지 않은 코드로 취급합니다

대부분의 바이브 코더들이 거부했던 불편한 인식 전환이죠. AI가 만든 코드는 기본적으로 안전하지 않습니다. 출처를 알 수 없는 코드와 똑같이 보안 스캔, 코드 리뷰, 테스트를 거쳐야 합니다. Snyk, Semgrep 같은 도구가 AI 보조 개발의 필수 관문으로 자리 잡은 이유도 바로 이겁니다.

한 번에 다 만들지 말고, 조금씩 붙여나갑니다

한 컴포넌트를 만들고, 테스트하고, 이해한 다음, 다음으로 넘어갑니다. "프롬프트 한 번으로 앱 전체 만들기" 식 접근은 아무도, 심지어 만든 개발자 본인조차 이해하지 못하는 시스템을 만들어냅니다. 이해하지 못하는 시스템은 망가졌을 때 고칠 수 없죠.

비개발자들에게는 더 쓴 진실

바이브 코딩의 원래 약속은 민주화였습니다. 누구나 소프트웨어를 만들 수 있다는 것. 이 약속은 어느 정도 지켜졌습니다. 하버드 교육대학원의 카렌 브레넌(Karen Brennan) 교수는 2025년 말에 바이브 코딩을 주제로 강의를 진행했는데요. 바이브 코딩의 핵심 가치는 "실험해 보는 비용을 확 낮춘 것"이라고 짚었습니다. 일단 만들어봐야 이해할 수 있는 것들이 있는데, 그걸 빠르게 해볼 수 있게 됐다는 거죠.

이건 정말로 앞으로 계속될 일입니다. 하지만 아무리 AI 성능이 좋아져도 메우지 못한 간극이 하나 있습니다. 데모에서 돌아가는 프로토타입과, 실제 데이터를 가진 실제 사용자들을 대상으로 프로덕션에서 안정적으로 돌아가는 소프트웨어 사이의 간극이죠. 이 간극을 메우려면 코드가 뭘 하고 있는지 이해하는 사람이 필요합니다. 모든 줄을 직접 쓴 사람일 필요는 없습니다. 다만 그 줄들을 읽고, 평가하고, 책임질 수 있는 사람이어야 하죠.

개발자 커뮤니티에서 존경받는 사이먼 윌리슨(Simon Willison)은 이렇게 정리했습니다.

"LLM이 코드를 한 줄 한 줄 다 썼다고 해도, 그걸 전부 리뷰하고, 테스트하고, 이해했다면, 제 기준에서 그건 바이브 코딩이 아닙니다. LLM을 타이핑 도우미로 쓴 거죠."

이 차이가 중요합니다. AI를 타이핑 도우미로 쓰거나, 초안 뽑아주는 도구로 쓰거나, 빠르지만 가끔 실수하는 페어 프로그래머로 쓰는 건 전혀 문제가 없습니다. 오히려 제대로 된 활용법이죠. 반면 AI가 내놓은 결과물을 이해도 하지 않은 채 그대로 배포하는 건 전혀 다른 이야기입니다. 2025년이 우리에게 가르쳐준 건, 바로 그 다른 이야기를 그만해야 한다는 겁니다.

결국 남는 건?

만약 개발자라면, 일자리 걱정은 안 하셔도 됩니다. 역할이 달라지고 있을 뿐이죠. 지금 힘들어하는 엔지니어는 AI 도구를 아예 거부하거나, 아무 생각 없이 갖다 쓰는 사람들입니다. 잘나가는 쪽은 안목을 키운 사람들이고요. AI 결과물을 언제 믿고 언제 의심해야 하는지 아는 사람, 복잡한 시스템을 AI가 풀 수 있는 작은 문제들로 쪼갤 줄 아는 사람들이죠.

Cursor나 Bolt로 뭔가 만들어본 비개발자라면, 그 경험은 분명 가치 있었습니다. 배운 게 있으실 테니까요. 문제는 그다음입니다. 실제 사용자에게 서비스를 배포할 생각이라면, 코드를 직접 리뷰할 실력을 갖추거나, 대신 해줄 동료가 필요합니다.

바이브 코딩 도구에 투자하거나 직접 개발하는 입장이라면, 로드맵은 명확합니다. 속도 문제는 이미 풀렸습니다. 앞으로 10년은 AI가 만든 코드를 기본적으로 믿을 수 있게 만드는 사람들의 시대가 될 겁니다. 나중에 덧붙이는 기능이 아니라, 첫 프롬프트부터 설계에 녹아 있는 형태여야 합니다.

바이브 코딩은 끝나지 않았습니다. 다만 어려운 부분을 건너뛰어도 됐던 시절은 끝났죠. 어려운 부분은 결국 돌아오게 되어 있습니다. 늘 그래왔듯이요.

<참고>

여러 연구에서 반복적으로 확인되는 패턴은 같습니다. AI는 개발 속도를 높이지만, 제대로 된 리뷰 없이는 훨씬 더 많은 보안 리스크를 만들어냅니다.

여러분의 경험은 어떠셨나요? 여전히 바이브 타는 중이신가요, 아니면 좀 더 의도적인 방식으로 넘어오셨나요?

<원문>

Vibe Coding Is Over. What Comes Next Is Much Harder.