바이브 코딩으로 장난감 말고 진짜 출시까지 가는 법

바이브 코딩(vibe coding)으로 만든 데모는 타임라인에 넘쳐난다. 스크린샷도 멋지고, 영상도 그럴듯하다. 그런데 그중 실제로 출시돼서, 누군가 돈을 내고 쓰고, 다음 달에도 돌아가고 있는 건 몇 개나 될까.

나는 지금까지 100개가 넘는 프로젝트를 벌여놨다. 그중 실제로 출시해서 운영하는 건 십여 개다. 나머지는 조용히 접거나 멈춰 있다. 이 글은 그 십여 개를 출시까지 끌고 가면서 알게 된, 데모와 제품 사이의 진짜 차이에 대한 것이다.

바이브 코딩이 쉬운 건 데모까지다

바이브 코딩은 "이런 거 만들어줘"라고 말하면 AI가 알아서 코드를 짜주는 방식이다. 화면 하나, 기능 하나 만드는 건 정말 빠르다. 30분이면 움직이는 무언가가 나온다.

문제는 거기서부터다. 데모는 happy path만 돌아가면 된다. 내가 시키는 대로, 내가 누르는 순서대로만 작동하면 영상은 찍힌다. 하지만 출시는 다르다. 모르는 사람이, 내가 예상 못 한 순서로, 이상한 입력을 넣어도 안 깨져야 한다.

데모에서 제품으로 가는 길에 죽는 것들:

• 빈 화면 / 로딩 / 에러 상태 (데모엔 데이터가 항상 있다)
• 첫 사용자 경험 (데모는 이미 세팅된 상태에서 시작한다)
• 결제·로그인·데이터 저장 (데모는 가짜로 넘어간다)
• 앱스토어 심사·배포·도메인 (데모는 내 노트북에서만 돈다)
• 다음 달에도 돌아가게 유지하는 일 (데모는 한 번 찍고 끝이다)

바이브 코딩이 "쉽다"고 느껴지는 건, 대부분 이 선을 넘기 전에 멈추기 때문이다.

출시까지 가는 흐름

내가 하나를 실제로 내보낼 때 거치는 단계는 늘 비슷하다. 바이브 코딩의 속도는 그대로 쓰되, 데모에서 멈추지 않게 하는 장치들이다.

1. 만들기 전에 수요부터 본다

가장 많이 죽는 이유는 버그가 아니라 아무도 원하지 않아서다. 그래서 코드를 짜기 전에, 그 문제를 실제로 겪는 사람이 있는지부터 확인한다. 수요가 안 보이면 안 만든다. 이 한 단계가 toy 양산을 막는다.

2. 빠르게 만들되, 설계는 먼저 받는다

바이브로 바로 코드를 뽑으면 큰 작업일수록 엉뚱하게 샌다. 그래서 "이렇게 만들겠다"는 계획을 먼저 받고, 그걸 보고 방향을 잡은 다음 구현에 들어간다. 속도를 버리는 게 아니라, 다시 짜는 시간을 버는 것이다.

3. "돌아가는 척"을 검증으로 잡는다

바이브 코딩의 가장 위험한 점은 그럴듯하게 돌아가는 척한다는 것이다. 화면은 멀쩡한데 실제로는 안 되는 경우가 흔하다. 그래서 "됐다"는 말을 믿지 않는다. 빌드와 타입 체크를 돌리고, 실제로 눌러보고 넘어간다. 이 습관 하나가 출시 후 터지는 사고를 대부분 막는다.

4. 출시는 별도의 일이다

여기서 대부분 포기한다. 앱스토어 심사 자료, 개인정보처리방침, 도메인 연결, 검색 등록 — 코드와 무관한 일이 한 무더기다. 재미없지만 이게 데모를 제품으로 만드는 마지막 관문이다. 나는 이걸 매번 같은 절차로 묶어둬서, 새 앱마다 처음부터 헤매지 않게 했다.

5. 출시가 끝이 아니라 운영의 시작이다

toy에는 없는 단계다. 에러가 나는지 모니터링하고, 문의가 오면 답하고, 가끔 고친다. 운영까지 가야 비로소 "만들었다"가 아니라 "운영한다"가 된다.

대부분은 죽는다. 그래서 많이 만든다

솔직히 말하면, 출시한 것 중에서도 대부분은 크게 안 된다. 십여 개를 운영하지만 잘 되는 건 그중 일부다.

그런데 이게 문제가 안 되는 이유가 있다. AI로 만들면 하나를 만드는 비용이 거의 0에 가깝기 때문이다. 그래서 하나에 모든 걸 걸지 않는다. 대신 내보내는 것 하나하나는 출시하고 운영하는 데까지 제대로 책임진다. 충분히 해봐도 반응이 없으면 방치하지 않고 깔끔하게 정리하고, 그 시간을 반응이 오는 것에 더 쓴다. 100개를 벌이고 십여 개를 출시하는 건 무모해 보이지만, 실패 비용이 0에 가까우면 그게 가장 합리적인 전략이 된다.

바이브 코딩의 진짜 가치

바이브 코딩의 진짜 가치는 "코드를 빨리 짜준다"가 아니다. 실패의 비용을 0에 가깝게 만들어준다는 것이다.

예전이라면 아이디어 하나를 검증하는 데 몇 주가 들었다. 지금은 만들어서 내보내고 반응을 보는 데까지 며칠이면 된다. 그러니 아이디어를 아끼지 않고, 틀려도 빨리 접고, 다음으로 넘어간다.

데모에서 멈추면 그 가치를 절반도 못 쓴다. 진짜는 출시하고, 반응을 보고, 죽이거나 키우는 그 다음에 있다.