바이브코딩으로 만든 MVP 배포 전 체크리스트
Cursor, Lovable, Bolt로 만든 MVP를 실제 고객에게 공개하기 전에 핵심 흐름, 모바일, 환경 변수, 데이터 저장, 결제, 문의 채널을 점검하는 방법을 정리했습니다.
바이브코딩으로 MVP를 만들면 배포 버튼을 누르는 순간이 꽤 빨리 옵니다. 예전 같으면 몇 주 걸릴 화면이 하루 이틀 만에 나오고, 로그인이나 결제도 생각보다 금방 붙습니다.
그래서 더 조심해야 합니다. "보인다"와 "고객이 써도 된다" 사이에는 작은 점검들이 있습니다. 특히 1인 사업자나 초기 팀은 첫 고객이 들어온 뒤에 문제가 터지면 바로 응대 부담으로 돌아옵니다.
MVP는 완벽할 필요가 없습니다. 하지만 고객이 반드시 지나야 하는 길은 끊기면 안 됩니다. 배포 전에는 아래 항목만이라도 확인해보는 편이 좋습니다.
1. 핵심 흐름을 3개만 고르기
모든 화면을 다 테스트하려고 하면 금방 지칩니다. 대신 이 서비스가 살아 있으려면 반드시 성공해야 하는 흐름을 3개만 고르세요.
예를 들면 이런 흐름입니다.
- 방문자가 문의를 남긴다
- 사용자가 회원가입하고 로그인한다
- 상품을 선택하고 결제한다
- 예약 날짜를 고르고 신청을 완료한다
- 관리자가 새 주문이나 문의를 확인한다
MVP 배포 전 테스트는 기능 목록을 지우는 일이 아니라 고객의 실제 동선을 걸어보는 일입니다. 버튼 하나씩 누르는 것보다 "고객 한 명이 들어와서 원하는 일을 끝낼 수 있는가"가 더 중요합니다.
2. 모바일에서 직접 끝까지 해보기
초기 사용자는 생각보다 많이 휴대폰으로 들어옵니다. 특히 랜딩페이지, 예약, 문의, 결제는 모바일 비중이 높습니다.
데스크톱에서는 멀쩡한데 모바일에서 입력창이 가려지거나, 버튼이 화면 밖으로 나가거나, 결제창으로 넘어가는 순간 레이아웃이 깨질 수 있습니다.
확인할 것:
- 첫 화면에서 핵심 문구와 버튼이 보이는가
- 폼 입력 중 키보드가 버튼을 가리지 않는가
- 카드나 표 때문에 가로 스크롤이 생기지 않는가
- 결제, 로그인, 예약 완료 화면까지 모바일에서 끝낼 수 있는가
- 긴 문구가 버튼 밖으로 삐져나오지 않는가
브라우저 개발자 도구의 모바일 보기만 믿지 말고, 가능하면 실제 휴대폰에서 한 번은 눌러보는 게 좋습니다.
3. 환경 변수와 배포 주소 확인하기
AI로 만든 MVP가 배포에서 막히는 가장 흔한 이유는 환경 변수입니다. 로컬에는 .env 파일이 있어서 되지만, Vercel이나 Netlify에는 값이 없어서 운영에서만 깨지는 경우입니다.
확인할 것:
- Supabase, Firebase, Clerk, 결제, 이메일 키가 배포 서비스에 들어 있는가
- 테스트 키와 운영 키를 구분했는가
- localhost 주소가 코드나 설정에 남아 있지 않은가
- 성공 URL, 실패 URL, 콜백 URL이 운영 도메인 기준인가
- 환경 변수 수정 후 다시 배포했는가
특히 결제와 로그인은 도메인 주소가 중요합니다. 미리보기 주소에서는 되던 기능이 실제 도메인에서는 막힐 수 있습니다.
4. 데이터가 실제로 저장되는지 보기
폼에서 "완료되었습니다"라는 문구가 나왔다고 해서 데이터가 저장됐다는 뜻은 아닙니다. 배포 전에는 반드시 관리자나 데이터베이스에서 실제 값이 들어왔는지 확인해야 합니다.
테스트 방법은 단순합니다.
- 실제 사용자처럼 폼을 작성한다
- 제출 후 완료 화면을 본다
- Supabase나 관리자 화면에서 방금 입력한 값이 있는지 확인한다
- 새로고침 후에도 값이 남아 있는지 본다
- 알림 이메일이나 슬랙 연동이 있다면 실제로 오는지 확인한다
AI가 만든 코드에서는 성공 메시지만 먼저 띄우고, 저장 실패를 제대로 처리하지 않는 경우도 있습니다. 사용자는 완료됐다고 믿는데 운영자는 아무것도 못 받는 상황이 가장 위험합니다.
5. 실패했을 때의 화면 준비하기
MVP에서 자주 빠지는 것이 실패 화면입니다. 결제가 실패했을 때, 로그인이 안 됐을 때, 문의 제출이 실패했을 때 사용자가 무엇을 해야 하는지 알려줘야 합니다.
멋진 에러 페이지가 필요한 것은 아닙니다. 최소한 다음 행동이 보여야 합니다.
- 다시 시도하기
- 문의하기
- 홈으로 돌아가기
- 다른 결제 수단 사용하기
- 운영자에게 보낼 수 있는 오류 정보 확인하기
실패 화면이 없으면 고객은 그냥 나갑니다. 그리고 운영자는 무엇이 잘못됐는지 알 수 없습니다. MVP일수록 실패를 완전히 없애기보다, 실패했을 때 연락이 닿게 만드는 것이 중요합니다.
6. 배포 직후 바로 확인할 사람 정하기
배포는 끝이 아니라 시작입니다. 특히 첫 공개라면 배포 후 30분에서 1시간 정도는 직접 지켜보는 편이 좋습니다.
확인할 것:
- 사이트가 실제 도메인에서 열리는가
- 문의나 결제 테스트가 통과하는가
- GA, Clarity 같은 분석 도구가 들어오는가
- 고객이 문의할 수 있는 채널이 보이는가
- 문제가 생겼을 때 바로 내릴 수 있는 이전 버전이 있는가
혼자 운영하는 서비스라면 더더욱 "누가 확인할지"가 필요 없습니다. 내가 봐야 합니다. 배포 버튼을 누르고 바로 다른 일을 시작하면, 첫 방문자의 문제를 놓칠 수 있습니다.
배포 전 최소 체크리스트
시간이 없다면 이것만 보세요.
- 핵심 사용자 흐름 3개를 끝까지 테스트했다
- 실제 휴대폰에서 화면과 폼을 확인했다
- 환경 변수를 배포 서비스에 넣었다
- localhost나 미리보기 주소가 남아 있지 않다
- 데이터가 실제 DB나 관리자 화면에 저장된다
- 결제나 로그인 콜백 주소가 운영 도메인이다
- 실패했을 때 사용자가 연락할 방법이 있다
- 배포 후 바로 확인할 시간을 비워뒀다
이 정도면 완벽한 출시는 아니어도, 첫 고객 앞에서 크게 당황할 가능성은 줄어듭니다.
정리
바이브코딩으로 만든 MVP는 빠르게 공개하는 것이 장점입니다. 하지만 빠르게 공개한다는 말이 아무 점검 없이 열어도 된다는 뜻은 아닙니다.
배포 전에는 모든 기능을 완벽하게 보려 하지 말고, 고객이 반드시 지나야 하는 핵심 흐름만 먼저 확인하세요. 모바일, 환경 변수, 데이터 저장, 실패 화면, 배포 직후 모니터링까지 보면 됩니다.
MVP의 목표는 완성도가 아니라 학습입니다. 다만 고객이 문의를 남겼는데 저장되지 않거나, 결제했는데 주문이 비는 문제는 학습 이전에 신뢰를 잃게 만듭니다. 그 지점만은 작게라도 점검하고 내보내는 편이 안전합니다.