사이드 프로젝트를 1년 동안 '바이브 코딩'으로 해본 결과, 사용자 40명에 유료 구독자 2명을 얻었습니다. 그 과정에서 배운 점들을 공유합니다.

혼자서 1년 정도 바이브 코딩(vibe coding) 해봤다. 사용자 40명에 유료 구독자 2명. 숫자는 보잘것없지만, 이 과정에서 진짜 중요한 게 뭔지 많이 배웠다. 순서 상관없이 적어본다.

범위는 목숨 걸고 좁혀라
가능한 가장 작은 MVP를 골라서 딱 그것만 만들어라. 개발하다 보면 온갖 추가 기능 아이디어가 떠오를 텐데(분명히 엄청 많이 떠오를 거다), 그건 프롬프트에 넣지 말고 '나중에' 리스트에 박아둬라. 바이브 코딩은 기능 하나만 더 추가해달라고 말하기가 너무 쉬워서 위험하다. 그러지 마라.

"로컬에서 잘 돌아가는데요?"는 아무 의미 없다
아무도 경고 안 해주는데 이게 진짜 큰 함정이다. AI는 네 컴퓨터에서 잘 돌아가는 걸 뚝딱 만들어주지만, 배포하면 바로 박살 난다. SSL 인증서, CI/CD, 로컬엔 없지만 운영 환경에선 필수인 서비스 간 권한 문제 같은 것들 말이다. 배포된 API들은 서로 통신하려면 명시적인 권한이 필요하다. 이 단계는 선택이 아니라 필수니까 시간 넉넉히 잡아둬라.

테스트 DB랑 운영 DB는 무조건 분리해라
AI가 운영 데이터 건드리게 절대 두지 마라. 나도 몇 달 동안 DB 잘 돌아가는 줄 알았는데, 알고 보니 앱에 하드코딩된 값만 계속 쓰고 있었던 거다. 진작 환경 분리했으면 바로 알아챘을 텐데.

말만 하지 말고 스크린샷을 먹여라
UI 만들 때 말로 설명하지 마라. 마음에 드는 사이트 스크린샷 찍어서 던져주는 게 최고다. 그리고 Playwright 설치해서 AI가 지가 만든 결과물을 직접 스크린샷 찍고 확인하게 시켜라. 눈 감고 수정하는 것보다 훨씬 낫다. 이것만 해도 프롬프트 엔지니어링보다 프론트엔드 실력이 훨씬 빨리 는다.

바이브보다 깃(Git) 관리가 중요하다
기능 하나씩 커밋해라. GitHub 웹훅으로 CI/CD 설정해서 테스트나 감사 자동으로 돌리고, 문제 있으면 아예 머지(merge)가 안 되게 막아버려라. CI/CD 원리까지 다 알 필요는 없다. 그냥 AI한테 필요하다고 말하고 왜 필요한지 설명하면 알아서 설정 다 도와준다.

AI가 싼 똥은 주기적으로 치워라
AI 코드는 금방 비대해진다. 몇 주에 한 번씩은 리팩토링이나 모듈화 해달라고 확실하게 시켜라. 코드베이스를 깔끔하게 유지해야 AI도 다음 세션에서 코드를 제대로 이해한다. 머지하기 전에 보안 감사랑 코드 리뷰도 직접 시켜라.

일단 배포하고 사람들을 만나러 가라
혼자 방구석에서 만들지 마라. 사람들한테 뭐 만드는지 말하고 피드백 받아라. 아픈 소리라도 일단 들어라. 아이디어는 네 거지만 돈 내는 건 걔네니까, 다음에 뭘 만들지는 걔네 의견이 우선이다.

버그는 실패가 아니다
MVP가 버그 없다는 뜻은 아니다. '진짜'라는 뜻이지. 일단 배포하고 터지는 것부터 고쳐라. 출시 전 완벽주의는 그냥 시간 끄는 핑계일 뿐이다.

개발이랑 마케팅은 동시에 해라
첫날부터 사람들 보낼 랜딩 페이지부터 만들어둬라. '완성'될 때까지 기다리지 마라. 완성 같은 건 없다.

주말에 뚝딱 만드는 게 아니다, 그래도 괜찮다
AI는 며칠 만에 아이디어를 뱉어낼 수 있다. 하지만 그걸 안전하게 만들고, 테스트하고, 제대로 설계하는 건 몇 달 걸린다. 집 짓는 거랑 똑같다. 기초 다지고, 뼈대 세우고, 배선 깔고, 마감하는 거다. 바이브 코딩은 뼈대 세우는 속도만 높여줄 뿐, 전체 공정을 다 줄여주는 건 아니다.

가끔은 좀 떨어져 있어라
진짜 과소평가된 디버깅 도구다. 산책이라도 다녀와라. 내가 겪은 '불가능한' 버그들 절반은 화면 쳐다보는 거 멈추자마자 해결됐다.