바이브 코딩은 약속을 깼다
아무 빌더 포럼에서든 한 시간만 보내면, 똑같은 고백이 백 가지 다른 방식으로 쓰여 있는 것을 발견하게 된다. 누군가 AI 도구로 주말 동안 자기 앱을 만들었다. 작동했다. 배포했다. 이제 월요일이고, 인증은 깨졌고, 데이터베이스는 조용히 행을 잃고 있으며, 아무도 재현할 수 없는 그 버그가 바로 고객을 떠나게 만들고 있는 그 버그다.
반년 전 우리가 서로에게 팔았던 그 꿈이 이제 문 앞에 서서 환불을 요구하고 있다.
나는 이 이야기를 조심스럽게 하고 싶다. 이 도구들을 만들거나 써 본 사람들이 흥분한 것이 잘못이었다고 생각하지 않기 때문이다. 그 도약은 실재했다. 평범한 영어 한 단락에서 작동하는 인터페이스가 모습을 드러내는 것을 보는 일은, 지난 10년간 소프트웨어에서 진짜로 마법 같았던 경험 중 하나다. 나도 그것을 느꼈다. 우리 모두 느꼈다.
그런데 데모와 배포 사이 어딘가에서 조용한 치환이 일어났다. 우리는 프로토타입을 제품이라고 부르기 시작했다. 데모를 소프트웨어라고 부르기 시작했다. 그리고 그 혼동에 대한 청구서가 이제 만기가 되었다.
잘못된 진단
이런 일이 왜 벌어지는지에 대해 내가 가장 자주 보는 설명은 모델을 탓한다. AI가 아직 충분히 똑똑하지 않다. 환각을 일으킨다. 잘못된 라이브러리를 고른다. 시니어 엔지니어라면 잡아내고 다시 썼을 코드를 쓴다.
이 설명은 위안이 된다. 이미 해결책이 오고 있음을 암시하기 때문이다. 반년만 기다려라. 다음 모델은 더 좋을 것이다. 결국 격차는 좁혀지고 모든 것이 작동할 것이다.
나는 그렇게 믿지 않는다. 그리고 믿지 않는 이유는, 내가 계속 목격하는 실패 양상이 코드의 품질과 아무 관련이 없기 때문이다.
마이크로소프트는 2025년 실적 발표에서, GitHub Copilot 활성 사용자가 커밋한 전체 코드 중 약 46%가 이제 AI가 생성한 것이라고 밝혔다. 거의 같은 시기에 애플리케이션 보안 기업 Veracode는 AI가 생성한 코드가 테스트한 샘플의 약 45%에서 보안 취약점을 만들어 냈다는 연구를 발표했다. 이 숫자들은 좋아지기 전에 먼저 나빠질 것이고, 더 똑똑한 모델이 그것을 고쳐 주지는 않는다.
문제는 모델이 아니다. 문제는 과정이다.
실제로 빠져 있는 것
바이브 코딩으로 만든 앱이 어떻게 만들어지는지 나에게 차례대로 설명해 보고, 아키텍처 결정이 어느 단계에서 내려지는지 말해 보라.
당신은 원하는 것을 설명한다. AI는 인터페이스와 그 뒤의 코드 일부를 생성한다. 당신은 인터페이스를 보고, 이리저리 클릭해 보고, 대체로 요청한 일을 하니 완료라고 선언한다. 그 루프의 어느 지점에서도 누구도 — 사람이든 기계든 — 멈춰 서서 실제로 무엇이 만들어지고 있는지 정의하지 않았다.
스키마가 없다. 데이터 모델이 없다. 시스템이 있을 수 있는 상태의 목록도, 무엇이 유효한지에 대한 정의도 없다. 프런트엔드와 백엔드인 척하는 그것 사이에 계약이 없다. 생성기가 예상하지 못한 동작을 사용자가 했을 때 무슨 일이 벌어질지에 대한 결정이 없다. 아무도 그것을 예상하지 않았기 때문이다.
만들어진 것은, 당신이 데모에서 우연히 지나간 그 특정 경로 위에서 요청한 것처럼 보이는 어떤 것이다. 그 경로에서 벗어나면 전체 구조가 비계였음이 드러난다. 그 아래에 건물은 애초에 없었다.
이것은 지능의 실패가 아니다. 정의의 실패다. 그리고 정의되지 않은 문제에 지능을 얼마나 더 쏟아도 정의된 결과는 나오지 않는다. 같은 비계의 더 설득력 있는 버전만 나올 뿐이다.
끝내 내려지지 않은 세 가지 결정
구체적으로 말하겠다. 추상적으로 말하는 것이 바로 이 대화가 계속 제자리를 돌게 만드는 이유이기 때문이다.
인증은 나중에 추가하는 기능이 아니다. 그것은 당신의 사용자가 누구인지, 무엇을 볼 수 있는지, 당신의 애플리케이션이 어떤 신뢰 경계 위에 놓여 있는지에 관한 결정이다. 출시 2주 뒤에 바이브 코딩 앱에 그것을 덧붙이는 것은, 벽 없이 지은 집에 현관문을 설치하는 것과 같다.
데이터베이스 스키마는 AI가 그 스키마에 쓰는 폼을 생성하면서 동시에 추측해도 되는 것이 아니다. 스키마는 애플리케이션의 척추다. 그 아래로 이어지는 모든 결정 — 무엇을 조회할 수 있는지, 무엇을 인덱싱할 수 있는지, 나중에 전부 망가뜨리지 않고 무엇을 바꿀 수 있는지 — 은 미리 내려졌거나 내려지지 않은 선택에 의해 제약된다. 스키마가 즉흥적으로 만들어지면 이후의 모든 변경은 리모델링이 된다.
API 계약은 선택 사항이 아니다. 그리고 AI 에이전트가 소프트웨어를 직접 소비하는 경제에서 그것은 인터페이스보다 제품에 더 가깝다. 당신의 앱이 다른 무엇과 대화하는 순간 — 결제 처리사, 이메일 서비스, 다른 소프트웨어, AI 에이전트 — 정의된 표면이 있어야 한다. 그것이 없으면 통합은 아무도 유지할 수 없고 아무도 물려받고 싶지 않은 일회성 편법의 연속이 된다.
이것들은 고급 주제가 아니다. 첫 주말보다 오래 사는 소프트웨어를 만들기 위한 최소 조건이다. 그리고 전체 빌드 과정이 「설명하고, 보고, 배포하기」일 때 정확히 건너뛰게 되는 것들이다.
70% 문제에 이제 이름이 있다
취약한 소프트웨어를 배포하는 산업을 만들려고 작정한 사람은 없었다고 생각한다. 이 카테고리에서 등장한 도구들은 도구를 팔아 주는 그 순간 — 아이디어가 1분 안에 작동하는 화면이 되는 마법의 순간 — 에 최적화했다고 생각한다.
「마법까지의 시간」이 측정되는 대상이 되었다. 「프로덕션까지의 시간」은 다른 누군가의 문제였다.
데모에는 합리적인 최적화다. 진짜 돈이 걸린 상태로 진짜 사용자에게 진짜 애플리케이션을 배포하는 책임을 지게 된 소프트웨어 카테고리에는 형편없는 최적화다. 그것은 한 세대의 빌더 전체를 90% 지점에 좌초시킨다. 자기 화면에서는 작동하고 다른 모든 곳에서는 무너지는 무언가를 손에 든 채로.
Lovable 커뮤니티의 빌더들이 이것에 이름을 붙였다 — 70% 문제. 거의 완성된 것처럼 느껴지는 지점까지 도달하고, 그다음 진전이 멈춘다. 모든 수정이 다른 것을 망가뜨린다. 남은 작업은 프롬프트로 뚫고 지나갈 수 있는 작업이 아니다. 당신을 막고 있는 것이 빠진 코드가 아니기 때문이다. 그것은 수백 세대 전에 조용히 내려진, 빠진 결정이다.
이 카테고리의 더러운 비밀은 쉬운 부분이 처음 90%였다는 것이다. 그다음 9% — 한 명 이상의 사용자에게, 한 대 이상의 기기에서, 예상하지 못한 조건에서 실제로 작동하게 만드는 일 — 이 처음 90%를 합친 것보다 어렵다. 그리고 마지막 1%, 작동하는 애플리케이션과 취약한 애플리케이션을 구분하는 그 부분은, 시작하기 전에 무엇을 만들고 있는지 알고 있었어야 하는 부분이다.
AI가 바꾸지 않은 규칙
아무도 듣고 싶지 않은 이야기가 여기 있다. 전진만 해야 할 것 같은 순간에 한 걸음 뒤로 가는 것처럼 들리기 때문이다.
최고의 소프트웨어는 언제나 정의에서 출발했다. 코드보다 아키텍처가 먼저. 한 줄이 쓰이기 전에 문제에 대한 명확한 모델이 먼저. 50명의 엔지니어 팀이 손으로 시스템을 만들던 때에도 사실이었고, 한 사람과 모델이 주말에 같은 시스템을 만들 수 있는 지금도 사실이다.
AI는 그 규칙을 바꾸지 않았다. AI는 그것을 덜 중요하게가 아니라 더 중요하게 만들었다.
코드를 생산하는 비용이 0에 가까워지면, 잘못된 코드를 생산하는 비용도 0에 가까워진다. 즉 여전히 비용이 드는 유일한 것은, 올바른 코드가 무엇이었어야 하는지를 알아내는 일이다. 그 작업 — 정의하는 작업, 아키텍처 작업, 만들기 시작하기 전에 실제로 무엇을 만들지 결정하는 그 부분 — 이 값싼 상품이 되지 않은 유일한 부분이다.
그리고 그것이 바로 현재 세대의 도구들이 건너뛴 부분이다.
이것이 실제로 향하는 곳
답은 속도를 줄이는 것이 아니라고 생각한다. 답은 모든 것을 손으로 다시 쓰는 것도 아니다. 그 도약은 실재했고, 그 도약은 남는다.
답은 정의 단계를 루프 안에 넣는 것이다 — 업계가 이제 명세 주도 개발이라고 부르는 실천이다. 당신을 늦추는 수동 관문이 아니라, 나머지 작업이 실제로 그 위에 놓이는 토대로서. 그것을 어떻게 할지 알아내고 있는 사람들은 당신이 봐 온 것보다 더 조용한 무언가를 만들고 있다. 그들은 이 카테고리의 요란한 버전이 원래 무엇이었는지를 곧 드러낼 것이다. 그 다음 세대가 실제로 어떤 모습인지에 대해서는 따로 썼다.
작동하는 화면은 애초에 작동하는 시스템과 같은 것이 아니었다. 우리 모두 곧 그 이유를 다시 떠올리게 될 것이다.
더 읽을 거리
무엇이 그것을 대체했는가: 명세 주도 개발. 도구들이 지금 어떻게 비교되는가: 2026년 최고의 AI 앱 빌더.
자주 묻는 질문
「바이브 코딩」은 무슨 뜻인가? 바이브 코딩은 원하는 것을 평범한 언어로 설명하고 AI가 생성한 것을 받아들이는 방식으로 소프트웨어를 쓰는 것이다. 그 아래의 아키텍처, 데이터 모델, 계약은 명시하지 않는다. Andrej Karpathy가 2025년 초에 이 용어를 만들었다. 그것은 도구의 카테고리가 아니라 작업 방식을 가리킨다 — 거의 모든 AI 빌더에서 바이브 코딩을 할 수 있다.
바이브 코딩으로 만든 앱은 왜 프로덕션에서 깨지는가? 실패가 구조적이며 코드 품질 문제가 아니기 때문이다. 생성 루프는 스키마도, 유효한 상태의 정의된 집합도, 프런트엔드와 백엔드 사이의 계약도 만들어 내지 않는다. 애플리케이션은 데모된 경로 위에서 작동하고 그 밖에서는 무너진다. 정의되지 않은 문제에 더 똑똑한 모델을 적용해도 여전히 정의되지 않은 결과가 나온다.
70% 문제란 무엇인가? AI로 만든 애플리케이션이 대략 70% 완성 지점에 도달한 뒤 진전이 멈추는 양상이다 — 모든 수정이 다른 것을 망가뜨리고, 프롬프트를 아무리 더해도 그 격차가 닫히지 않는다. 막고 있는 것은 보통 수백 세대 전에 암묵적으로 내려진 아키텍처 결정이며, 다시 쓰지 않고는 더 이상 바꿀 수 없다.
AI가 생성한 코드는 덜 안전한가? 현재의 근거는 검토가 필요하다고 말한다. Veracode의 연구는 AI가 생성한 코드가 테스트한 샘플의 약 45%에서 보안 취약점을 만들어 냈음을 발견했고, 같은 시기 마이크로소프트는 GitHub Copilot 활성 사용자가 커밋한 코드의 약 46%가 AI 생성이라고 밝혔다. 양이 검증보다 빠르게 늘고 있다.
그렇다면 AI 앱 빌더를 쓰지 말아야 한다는 뜻인가? 아니다. 프로토타입, 데모, 내부 도구에는 정말로 훌륭하고 그 속도는 실재한다. 여기서의 주장은 더 좁다: 작동하는 화면은 작동하는 시스템이 아니며, 정의 단계를 건너뛰는 도구는 모델이 얼마나 좋아지든 두 번째를 만들어 낼 수 없다.
