내가 '바이브 코딩'으로 만들지 말았어야 할 딱 한 가지...

이런 종류의 버그는 앱의 어떤 부분을 '바이브 코딩'으로 만들고 어떤 부분을 만들지 말아야 할지 다시 생각하게 만든다.

나는 저널링 앱을 운영하는 1인 창업자이고, 전체 앱을 바이브 코딩으로 만들었다. 오늘 Stripe 대시보드를 확인하다가 뭔가 잘못된 것을 발견했다. 한 사용자가 같은 계정에 두 개의 활성 구독을 가지고 있었다. 그들은 15달러/월 요금제에서 30달러/월 Pro 요금제로 업그레이드하려고 했다. 하지만 기존 구독을 전환하는 대신, 내 결제 흐름은 기존 구독과 나란히 새로운 두 번째 구독을 생성해버렸다.

그래서 그들은 총 30달러를 내고 있었지만 하위 요금제 제한에 묶여 있었다. 일일 입력 제한에 걸리고, 이미 업그레이드를 시도했음에도 불구하고 "Pro로 업그레이드하세요"라는 모달을 보고 있었다. 그들은 아직 나에게 이메일을 보내지 않았다. 내가 그들이 알아채기 전에 잡아냈다.

버그는 당혹스러울 정도로 간단했다. 내 결제 생성 엔드포인트에는 고객이 이미 활성 구독을 가지고 있는지 확인하는 절차가 전혀 없었다. 매번 새로운 결제 세션을 열 뿐이었다. 전형적인 바이브 코딩 방식: 해피 패스를 만들고, 배포하고, 넘어간다. 엣지 케이스는 없다. "업그레이드를 두 번 클릭하면 어떡하지?"도 없다. "Stripe에 이미 이 고객의 활성 구독이 있으면 어떡하지?"도 없다. 그냥 바이브만 있을 뿐.

나는 중복 결제 금액을 전액 환불해주고, 수동으로 Pro로 업그레이드해주었으며, 불편을 끼쳐 죄송하다는 의미로 이번 달은 무료로 제공하겠다는 이메일을 보냈다. 차액을 청구하지도 않았다. 내가 감수한 15달러는 아마 내가 지금까지 쓴 돈 중 가장 저렴한 신뢰 구축 비용일 것이다. "버그가 있었는데 한 달을 무료로 줬어"라는 이야기는 친구에게 할 만한 이야기다. "중복 결제를 환불해주고 제대로 청구했어"는 그냥 회계일 뿐... 그리고 회계 이야기를 다시 하는 사람은 아무도 없다.

그리고 실제 버그를 수정했다. 이제 엔드포인트는 새로운 구독을 생성하기 전에 기존 활성 구독을 확인하고, 요금제 변경을 위해 고객 포털로 리디렉션한다. 첫날부터 있었어야 할 방어적인 코드지만, 빠르게 움직이고 "테스트에서 작동했기" 때문에 없었던 코드다.

문제를 인지하고 완전히 해결하기까지 걸린 총 시간: 약 20분.

몇 달 동안 전체 제품을 바이브 코딩으로 만든 후의 내 결론은 이렇다: 바이브 코딩으로 만들 수 있는 기능이 있고 절대 그렇게 해서는 안 되는 기능이 있다.

UI, 랜딩 페이지, 블로그 레이아웃, 온보딩 흐름은 모두 괜찮다. 빠르게 반복하고, 부수고, 나중에 고치면 된다.

하지만 결제, 인증, 그리고 돈과 관련된 모든 것은 누군가가 적극적으로 그것을 깨뜨리려고 하는 것처럼 작성되어야 한다. 사용자가 악의적이어서가 아니라, 결제 흐름의 엣지 케이스는 UI 버그로 나타나지 않기 때문이다. 그것들은 신뢰 위반으로 나타난다... 그리고 신뢰를 얻을 기회는 단 한 번뿐이다.

다른 바이브 코더들이 배포했다가 뒤통수를 맞은 것들이 무엇인지 궁금하다.

특히 Stripe나 결제와 관련된 것이라면 더더욱. "실제 사용자가 내가 테스트하지 않은 무언가를 하기 전까지는 잘 작동하던 것들"이라는 범주가 통째로 존재하는 것 같다.