Cursor를 열고 프롬프트를 넣었더니 진짜 돌아가는 게 나왔습니다. 로그인이 됩니다. 화면 전환도 되고요. 데이터까지 저장돼요. 불과 며칠 전까지 머릿속에만 있던 게 눈앞에서 움직이고 있으니까 솔직히 좀 놀랍습니다.
"이 정도면 출시해도 되는 거 아닌가?"
그 생각이 드는 게 자연스러워요. 근데 한 번만 물어볼게요. 지금 만든 것을 스토어에 올릴 수 있나요. 모르는 사람이 결제해서 쓸 수 있나요. 새벽에 서버가 터져도 대응할 수 있나요. 매달 운영비를 감당할 수 있는 상태인가요.
대부분은 여기서 멈칫합니다. 만들어진 것이 돌아가는 건 맞는데, 그게 서비스가 되는 것과는 다르다는 걸 이 질문 앞에서 느끼게 돼요.
바이브코딩으로 만든 건 "이 아이디어가 형태를 갖출 수 있다"는 걸 확인한 겁니다. 그 자체로 대단한 일이에요. 예전이었으면 수백만 원을 써야 볼 수 있었던 걸 며칠 만에 눈으로 확인한 거니까요. 다만 거기서 바로 출시로 건너뛰면 돌이키기 어려운 일들이 생기기 시작합니다.
출시하고 나서 알게 되는 것들
프로토타입 상태로 스토어에 올리면 어떤 일이 벌어지는지 구체적으로 이야기해 볼게요.
사용자가 앱을 쓰다가 에러를 만났습니다. 그런데 에러 화면이 없어요. 앱이 그냥 멈춰버립니다. 사용자 입장에서는 뭐가 잘못된 건지 알 수가 없으니까 그대로 나가버려요.
인터넷이 잠깐 불안정해졌습니다. 앱이 하얀 화면 그대로 굳어요. 지하철에서 쓰고 있었다면 터널 한 번 지나는 사이에 앱을 포기하게 됩니다.
로그인 세션이 만료됐는데 안내가 없어서 쓰던 데이터가 통째로 날아가는 경우도 있어요. 이건 한 번 겪으면 다시는 안 쓰게 되는 종류의 경험입니다.
"그래도 초기에 버그 좀 있을 수 있지 않나?"
본인이 쓸 때는 그렇게 생각할 수 있어요. 근데 모르는 사람은 달라요. 앱스토어에서 뭔가를 깔아봤는데 한 번 버벅거리면 삭제합니다. 별점 1점을 남기기도 해요.
그리고 앱스토어 알고리즘은 초기 리뷰에 민감하게 반응하거든요. 낮은 별점이 쌓이면 노출이 내려갑니다. 한 번 내려간 앱을 다시 올리는 건 처음 올리는 것보다 몇 배로 어려워요.
그러니까 문제는 버그 자체가 아닙니다. 첫인상을 회복할 기회가 없다는 게 문제예요.
"그래서 어디까지 다시 만들어야 하나요"
이 질문이 제일 먼저 나옵니다.
"바이브코딩으로 만든 거 다 버리고 처음부터 다시 해야 하는 건 아닌가."
아닙니다. 전부 버리는 경우는 오히려 드물어요. 바이브코딩 결과물도 코드니까 잘 된 부분은 살리고 위험한 부분만 다시 잡으면 됩니다.
다만 이걸 판단하려면 기준이 필요해요.
확인해야 할 건 크게 두 가지입니다.
첫째
지금 코드 위에 기능을 추가할 수 있는 구조인가. 기능 하나를 넣었을 때 기존 기능이 깨지지 않는다면 구조를 살릴 수 있습니다. 반대로 뭘 건드려도 예상 못한 곳에서 문제가 생긴다면 기능을 쌓을수록 더 깊은 수렁에 빠지게 돼요. 그런 경우에는 구조 자체를 다시 잡는 게 오히려 빠릅니다.
둘째
사용자 데이터를 안전하게 다룰 수 있는 상태인가. 로그인이나 결제, 개인정보가 들어가는 서비스라면 보안은 타협할 수 없는 영역이에요. 이 부분이 허술하면 아무리 다른 코드가 잘 되어 있어도 고쳐야 합니다. 사용자 정보가 한 번 유출되면 서비스의 신뢰가 통째로 무너지거든요.
솔직히 이 두 가지는 코드를 읽을 수 있는 사람이 직접 봐야 판단이 됩니다. 만든 본인이 확인하기 어려운 영역이에요.
프로토타입에서 제품으로 가는 세 단계
살릴 부분과 다시 만들 부분이 나뉘었다면 이제 제품으로 올리는 과정입니다. 크게 세 단계로 나뉘어요.
코드 리뷰와 구조 진단
지금 만들어진 것이 어떤 상태인지 정확히 파악하는 단계입니다. 어디를 살리고 어디를 다시 만들지 나누고 전체 작업 범위를 산정해요.
이걸 건너뛰고 바로 "이것저것 고쳐주세요"라고 하면 견적도 정확하게 안 나옵니다. 작업 중간에 예상 못한 이슈가 계속 불거져요.
건물 리모델링을 할 때 벽부터 허무는 게 아니라 구조 진단부터 하는 것과 같습니다.
서비스 안정화
에러 처리, 서버 안정성, 보안, 결제 연동 같은 것들을 제품 수준으로 올리는 단계입니다. 사용자가 쓸 때 "어?"라고 느끼지 않는 최소한의 품질을 만드는 거예요.
이 단계에서 기능을 더 넣고 싶은 유혹이 생깁니다. 참아야 해요. 지금은 기존 기능이 안정적으로 돌아가게 만드는 데 집중하는 게 맞습니다.
새 기능은 출시 후에 사용자가 뭘 원하는지 직접 확인하고 나서 넣어도 전혀 늦지 않아요.
출시 준비
앱스토어 등록, ASO 키워드 설정, 사전 신청 페이지, 초기 마케팅 채널 세팅까지. 출시 자체를 하나의 이벤트로 설계하는 단계입니다.
이 세 단계를 거치면 바이브코딩으로 시작한 아이디어가 모르는 사람이 결제하고 쓰는 서비스가 됩니다.
오해 하나만 풀고 가겠습니다
"결국 바이브코딩으로 만든 건 다 버리고 개발사에 돈 주고 다시 만들라는 거 아니냐."
이렇게 읽힐 수 있다는 걸 알고 있어요. 근데 정반대입니다.
바이브코딩으로 만든 프로토타입은 기획서보다 훨씬 강력한 자산이에요. "이런 걸 만들고 싶어요"를 말로 설명하는 것과 "이렇게 돌아가는 걸 만들었는데 이걸 제품으로 올려주세요"라고 보여주는 건 출발점 자체가 다릅니다.
개발사 입장에서도 프로토타입이 있으면 작업 범위가 선명해져요. 견적이 정확해지고 커뮤니케이션에서 어긋나는 일이 줄어듭니다. 시간도 비용도 아낄 수 있어요.
그러니까 바이브코딩으로 만든 걸 들고 개발사를 찾아가는 건 가장 현명한 순서입니다. 빈손으로 가는 것보다 훨씬 유리한 위치에서 대화를 시작하는 거예요.
