바이브코딩이 실패하는 이유
분량 조절 실패
바이브코딩을 하다가 막혀서 저에게 컨설팅을 받으시는 분들은 대부분 구현 결과물을 너무 복잡하게 만들어서 수습이 안 되는 상황이었습니다. 몇 개월 동안 쉬지 않고 AI와 함께 코딩을 하다 보니 구현된 기능도 많고 파일 수도 많고 코드량도 많습니다.
비개발자 한 명이 2~3개월 구현한 코드가 어느 정도로 많으냐면, AI 이전 시대에 몇 명의 개발자가 몇 년 동안 구현했을 법한 분량의 코드가 있습니다. AI가 코드를 빨리 작성하니 당연한 것 아니냐고 생각할 수 있지만, 코드 작성은 AI가 하더라도 코드 관리와 책임은 사람이 져야 한다는 점을 간과한 것입니다.
빨리 작성할 수는 있어도 작성한 분량이 어느 정도 임계점을 넘어가면 비개발자든 개발자든 프로젝트 관리와 수습이 거의 불가능하다고 봐야 합니다. 웬만한 개발자보다 AI가 코드를 잘 작성한다고 생각하지만 그건 코드 작성에 한해서이고 개발에는 코드 작성 외에 많은 중요한 요소가 포함됩니다.
사용 흐름, 구조 설계, 리스크 파악, 정책과 권한, 기술 스택 결정 등은 AI가 제대로 하지 못하는 인간의 검토와 의사결정이 필요한 영역이고, 검토와 의사결정 시점에 코드 작성은 멈춰서야 합니다. 중간중간 멈춰야 하고 또 어느 지점 이후에는 개발을 멈추고 운영 모드로 넘어가야 합니다.
대략 2주에서 1개월 정도를 집중해서 AI로 코딩을 진행했다면, 이때는 개발을 더 진행하지 않고 서비스를 라이브에 올려 사람들의 피드백을 받으면서 운영 모드에 들어가는 게 좋다고 생각합니다. 다르게 말하면 첫 번째 출시 버전은 2주에서 1개월 만에 완성하는 것을 목표로 해야 합니다.
AI의 개발 속도가 사람보다 대략 10배 빠르다고 본다면, 한 명이 바이브코딩으로 2주 동안 개발한 분량은 한 명이 바이브코딩 없이 5개월 동안 개발한 분량이 됩니다. 이 정도면 오류가 난 부분, 설계가 잘못된 부분을 어느 정도 사람이 직접 고칠 수 있고, AI도 프롬프팅만 잘하면 수습할 수 있습니다. 리팩토링도 할 만합니다.
기술 스택의 코드량과 생산성에 따라 고려할 부분이 있습니다. 루비 온 레일즈는 동일한 기능에 대해 코드 작성량과 외부 툴 연동의 필요성이 적습니다. 같은 코드량을 작성했을 때 다른 프레임워크와 비교해 루비 온 레일즈는 2~3배로 더 많은 기능이 구현됩니다.
작성된 코드량이 작업한 기간과 비례한다고 가정하면 루비 온 레일즈로 2주간 개발한 기능 범위가 장고로 4주간 개발한 분량, 리액트 계열의 프론트/백엔드 분리 스택으로 6주간 개발한 분량이 됩니다. 다르게 말하면 2주 동안 루비 온 레일즈로 12개의 기능을 만들 동안 프론트/백엔드 분리 스택으로는 4개를 만들 수 있습니다.
기술 스택의 생산성은 프로젝트 특성이나 개인의 경험에 따라 이견이 있을 수 있을 텐데, 우선 프론트/백엔드 스택에서 레일즈로 전환한 비개발자 바이브코더 분들은 생산성 차이에 대해 저와 비슷한 의견을 주었습니다. 레일즈로 하더라도 2주에서 1개월 정도가 넘어가면 기능이 너무 많아지고 복잡도가 올라가서 오류 빈도가 올라가고 생산성이 급격히 떨어지고 운영에 대한 리스크가 올라갔습니다.
숙련된 개발자가 바이브코딩을 하는 경우 코드를 모두 읽지는 않더라도 코드의 복잡도가 어떤 부채를 만들어낼지의 직관과 경험이 있기 때문에 무턱대고 기능 구현을 계속하지 않습니다. 잘못 만들어서 뜯어 고치는 것보다는 처음부터 잘 만드는 게 훨씬 쉽다는 것을 알기 때문에 사전에 설계를 하고 구현 순서를 고민하고 적절하게 태스크를 쪼개서 진행합니다.
비개발자는 바이브코딩을 배우기 시작한 초기에는 출시할 제품을 바로 만들지 않고 여러 연습용 제품을 만드는 게 좋습니다. 출시할 제품을 만들어도 되지만 출시할 생각으로 만들지 말고 만들고 고치고 부수고 배우고 처음부터 몇 번 다시 만들 생각으로 바이브코딩을 진행해야 합니다. 그리고 끝까지 바이브코딩을 하는 게 아니라 코드를 배우면서 이해하면서 AI를 과외 선생님으로 활용해야 합니다.
프로젝트를 출시할 때쯤에는 준개발자가 되어서 왜 이 기술 스택으로 만들었고 프로젝트 구조는 어떤 상태이며 권한 처리는 어떻게 되어 있고, 인프라를 어떻게 활용하고 있고, 프로젝트에 어떤 리스크가 있는지, 사용자는 대략 어느 정도 감당할 수 있는지 등등을 파악한 상태여야 합니다. 예전에는 이 지식을 얻으려면 몇 년의 시행착오와 구글링과 멘토링이 필요했지만 지금은 바이브코딩하면서 꼼꼼하게 AI에게 질문하는 것만으로도 상당히 학습할 수 있습니다.
비개발자가 만약 코드에 대한 이해 없이 몇 개월 동안 바이브코딩을 신나게 진행했다면 프로젝트 코드가 수많은 땜질과 이해 못할 코드로 가득한 상태일 겁니다. 이대로 실서비스를 하면 위험합니다. 몇 개월의 시간이 있다면 2주~1개월 간격으로 3~4번 만들고 부쉈다가 다시 만들 생각으로 만드세요. 만들어진 코드에 대해서 모든 코드를 최대한 이해하려고 하세요.
개발자들도 바이브코딩을 합니다. 하지만 개발자들은 본능적으로 리스크가 있는 부분에 대해서는 직접 검토를 합니다. 설계가 이상하게 된다 싶으면 설계에 대한 가이드를 프롬프팅하고요. 비개발자의 바이브코딩과는 다릅니다. 즉 결론은 비개발자가 바이브코딩으로 서비스 제작 경험을 시작하더라도 끝맺음은 반드시 개발을 이해하는 시점(개발자라는 타이틀은 달지 않더라도)에 배포해야 한다는 것입니다.
바이브코딩 때처럼 시원시원하게 개발하는 것은 출시 전까지만입니다. 출시 후에는 코드 수정을 아주 작은 단위로 쪼개야 하고 그 단위마다 진행 후 동작 검수(새 기능뿐만 아니라 기존에 구현된 기능까지)를 해야 하며 가급적 수정된 코드를 대략적으로 읽고 검토해야 합니다.
운영 단계에서 바이브코딩의 속도가 느려짐에도 불구하고 개발 단계에서 속도가 10배가 난다는 점에서 제품 발굴, 개발, 출시 전략을 기존과 다르게 세울 필요가 있습니다. 기존에 설문이나 MVP로 했던 PMF 검증을 이제 완제품으로 할 수 있습니다. 그 완제품은 1개월 이내에 한 명의 개발자/비개발자만이 투입되었기 때문에 PMF 검증 후 쉽게 폐기할 수 있습니다. 비개발자도 제품을 만들면서 개발자가 될 수 있습니다. 개발자는 제품 기획/디자인/UX에 관여하면서 점차 올라운드 플레이어가 될 수 있습니다.
