바이브 코딩 MVP 개발 4단계 프로세스 (부제: 개발자가 빠지기 쉬운 3가지 착각)
어제 개발자로서 스타트업 창업을 하시려는 분께 짧은 바이브 코딩 과외를 해드렸습니다.
2시간동안 여러가지 이야기를 하다 보니 바이브 코딩으로 MVP를 개발하는 프로세스가 이렇게 4단계로 정리가 되더군요. 참고로 비개발자를 위한 바이브 코딩 입문 가이드와도 유사한데, 좀 더 '개발'에만 포커스를 맞춘 것입니다.
바이브 MVP 개발 4단계 프로세스
- PRD 제대로 깎아서 AI에게 (첫턴에) 최대한 많은 걸 시켜보기
- 컨텍스트를 파일로 스스로 문서화하게 하기 (가장 단순하게는 "TODOs.md에 기록하면서 진행해")
- TODO 문서 참조해서 요구사항을 이야기하며, 테스트 코드 먼저 짜고 통과할때까지 구현하라고 하기
- 테스트 통과하면 일단 커밋, 내가 직접 검수해서 통과하면 TODO 문서 업데이트하며 한번 더 커밋
세부적으로는 여러가지 디테일이 있지만 결국 핵심은 "AI에게 점점 더 많은 일을 시키면서 한계를 꾸준히 시험해봐라" 였어요. 이걸 '개발자가 바이브 코딩에서 빠지기 쉬운 3가지 착각'으로 얘기해볼게요.
개발자가 바이브 코딩에서 빠지기 쉬운 3가지 착각
결론부터 말하면, AI시대에는 이미 배운 걸 의식적으로 잊고 새로 배우는 'Unlearn'이 필수적이라고 생각합니다.
착각 1. 쪼개서 시킬수록 일을 더 잘 할거야 → AI는 당신의 생각보다 일을 훨씬 많이 할 수 있습니다
시간관계상 지난 바이브 코딩 과외에서는 PRD 깎는 건 생략하고 이분이 가져온 PRD를 그대로 썼는데요. Lovable에서 Supabase 연동 후에 제 경험상 AI가 테이블까지 다 설계해서 넣어줘야 하는데 안했더라고요.
왜그런지 보니 PRD에서 '프론트엔드 껍데기만 구현하고 백엔드는 다음 이터레이션에서 한다'고 써두셔서 그랬습니다. 예전에 본인이 MVP 만들 때 하시던 대로 설계하신 건데 이게 여기선 독이 된거죠.
AI에게 한번에 너무 많은 일을 맡기면 잘 못하는 건 맞아요. 하지만 그 한계는 아주 빠르게 확장되고 있습니다. 코딩 에이전트는 최초 몇 턴의 대화에서 가장 생산성이 좋기 때문에, 첫 턴에 어디까지 해줄 수 있는지 계속 밀어붙여보세요. 그러다 잘 못하면 거기서부터 쪼개면 됩니다.
착각 2. 어떻게 할지 자세히 지시할수록 잘할거야 → AI는 당신의 생각보다 훨씬 창의적입니다
개발 경험이 많을수록, 그리고 ChatGPT 초창기에 프롬프팅 배우신 분들일수록 How, "즉 어떻게 구현하라"를 상세하게 지시하는 경향이 있는데요. 때론 이게 불필요한 제약이 됩니다. 더 잘 할 수 있는 애한테 족쇄를 단다고나 할까요.
저는 그냥 What만 명확히 지시하고, 어떻게 하는지 살펴보고, 잘 못한다 싶으면 그때 가서 다시 How를 알려줘도 충분히 괜찮다고 느껴요. 요즘은 오히려 내가 생각지도 못한 방식으로 알아서 해결해주는 일도 많습니다. 그래서 How보다도 Why를 얘기해주는 게 AI가 의도파악해서 더 좋은 결과물을 만드는 데 더 좋다고 생각합니다.
물론 '어떤 결과물이 좋은 결과물이다'를 판단하는 본인의 기준은 잘 잡혀있어야겠지만요.
착각 3. 만들어진 코드를 재사용하면 비용과 시간이 절약될거야 → AI는 당신의 생각보다 훨씬 싸고 빠릅니다
바이브 코딩을 처음 겪어보는 분들은 짧은 프롬프트만으로 만들어지는 결과물의 품질이 상상 이상으로 높다는 것에 놀랍니다. 그런데 진지한 제품이 되기에는 당연히 부족한 게 보이죠. 그래서 이 상태에서 기능을 더 추가/수정하려고 하시는데, 이게 그리 좋은 선택이 아닐 수 있어요.
아깝다는 마음을 버리고 새로 시작하는 게 유리한 이유를 간단히 들어보면:
- 현재 코딩 에이전트들이 기존 코드 고치기보다는 새로 만들기를 더 잘 한다
- 모델도 계속 좋아질 뿐더러, 무작위성 때문에 새로 만들어진 게 더 만족스러울 가능성이 얼마든지 있다
- 새로 만드는 데 드는 시간과 비용이 크지도 않다
그러니 처음 만들어진 걸 테스트해보며 느낀 점들을 PRD에 다시 녹여서 깎고, 그걸로 다시 처음부터 만드는 걸 시도해보세요. AI가 잘하는 것과 못하는 걸 배우는 기회도 됩니다.
Member discussion