내가 첫 SaaS를 '바이브코딩'하며 겪은 실수들, 여러분은 겪지 마세요
Mistakes I made vibecoding my first saas so you dont have to
핵심 요약
AI를 활용해 SaaS를 개발하며 얻은 실전 팁과 시행착오를 공유하는 글.
- 코드 수정 지양 — 작동하는 코드는 건드리지 말고 AI에게 리팩토링을 맡기지 않아야 함.
- 프롬프트 전략 — 코드 구현 방식이 아닌 사용자 경험 위주로 상세히 설명해야 함.
- 테스트 환경 구축 — 실제 API 연결 전 가짜 데이터로 프론트엔드 문제를 먼저 확인해야 함.
- 우선순위 설정 — 가장 위험하고 어려운 핵심 기능을 먼저 개발해야 함.
코딩 경험 제로 상태에서 2주 만에 실제 유저가 사용하는 SaaS를 '바이브코딩'으로 완성했다. 시작하기 전에 누군가 알려줬으면 좋았을 것들을 공유한다.
AI가 작동하는 코드를 리팩토링하게 두지 마라. 이미 작동하는 것을 Cursor에게 "정리해달라"거나 "개선해달라"고 할 때마다 다른 무언가가 고장 났다. 작동하면 건드리지 마라. 작동하지 않는 깔끔한 코드보다 작동하는 지저분한 코드가 낫다.
앱이 고장 나서 에러를 Cursor에 붙여넣을 때, AI가 추측하게 두지 마라. 빨간 글씨만 복사하지 말고 터미널 출력 전체를 복사해라. 에러 자체보다 에러 주변의 문맥이 훨씬 중요하며, AI는 모든 것을 볼 때 훨씬 더 나은 해결책을 제시한다.
프롬프트는 코드가 무엇을 해야 하는지가 아니라 사용자가 무엇을 경험하는지 설명해야 한다. "누군가 검색을 클릭하면 로딩 스피너가 보이고 결과가 이름과 제목이 포함된 카드로 나타난다"라고 말하는 것이 "JSON을 반환하고 프론트엔드에 렌더링하는 검색 기능을 만들어라"라고 하는 것보다 훨씬 더 나은 결과물을 가져다준다.
실제 API를 연결하기 전에 가짜 데이터로 테스트해라. 프론트엔드 표시 문제였는데 AI 문제인 줄 알고 디버깅하다가 OpenAI 크레딧을 40달러나 날렸다. 하드코딩된 더미 데이터로 5분 만에 잡을 수 있었던 문제였다.
랜딩 페이지는 바이브코딩하지 마라. 이상하게 들리겠지만 AI가 생성한 랜딩 페이지는 다 똑같이 생겼고 사람들은 그걸 즉시 알아챈다. 나는 랜딩 페이지에는 Framer를 사용했고 실제 제품만 바이브코딩했다. 랜딩 페이지는 사람들을 가입하게 만드는 곳이므로 다른 AI 템플릿처럼 보이지 않아야 한다.
하지만 가장 중요한 것은, 가장 쉬운 기능이 아니라 가장 위험한 기능을 먼저 바이브코딩하라는 것이다. 핵심 검색 기능이 작동하는지 테스트하기도 전에 사용자 설정과 프로필 페이지를 만드는 데 3일을 썼다. 반대가 되었어야 했다. 어려운 부분이 작동하지 않으면 다른 건 아무 의미가 없다.
