바이브코딩 서비스가 출시 뒤에 무너지는 지점

바이브코딩으로 서비스를 만들어 출시하신 분들에게서 비슷한 연락을 자주 받아요. 「혼자 테스트할 때는 멀쩡했는데, 사람들이 들어오니까 이상해졌어요.」

이야기를 들어 보면 무너지는 지점이 신기할 만큼 비슷해요. 화면이 예쁘지 않아서도, 속도가 느려서도 아니에요.

출시 뒤에 무너지는 건 대개 「누가 무엇을 할 수 있는지」와 「이 데이터가 누구 것인지」를 처음에 나누지 않은 곳이에요.

혼자 쓸 때는 보이지 않는 문제

만드는 동안 그 서비스를 쓰는 사람은 사실상 한 명이에요. 대표님 자신이죠. 대표님은 손님이기도 하고, 관리자이기도 하고, 판매자이기도 해요.

이 상태에서는 역할을 나눌 이유가 없어 보여요. 모든 버튼이 보이고, 모든 데이터를 고칠 수 있어도 불편하지 않아요. AI도 요청받은 기능을 그대로 만들 뿐, 「이 버튼은 누구에게만 보여야 하나요?」라고 먼저 묻지 않아요.

그러다 출시하면 처음으로 서로 다른 사람들이 같은 서비스에 들어와요. 그 순간 숨어 있던 질문이 한꺼번에 튀어나와요.

혼자 쓰는 서비스에는 역할이 없고, 출시하는 순간 역할이 생겨요

거꾸로 말하면, 출시 전 마지막 점검으로 할 일도 분명해요. 손님 계정 두 개, 관리자 계정 하나를 만들어 서로의 화면을 오가 보는 거예요. 남의 것이 보이거나 고쳐지는 곳이 하나라도 있다면 아직 열 때가 아니에요.

무너지는 장면 세 가지

제가 실제로 자주 보는 장면을 익명으로 옮겨 볼게요.

• 남의 것이 보인다. 손님 A가 주소만 바꿔 들어가면 손님 B의 예약 내역이 보여요. 「내 것만 보기」라는 규칙이 처음부터 없었기 때문이에요.
• 직원에게 줄 권한이 없다. 일손이 늘어 직원을 들이려는데, 관리자 아니면 손님뿐이에요. 직원에게 관리자 권한을 통째로 주거나, 대표님이 다 하거나 둘 중 하나가 돼요.
• 데이터 주인이 헷갈린다. 판매자가 상품을 지우면 그 상품을 산 손님의 주문 내역까지 사라져요. 주문이 누구 것인지 정해 두지 않았기 때문이에요.

세 장면 모두 화면 한두 장을 고쳐서는 해결이 안 돼요. 데이터를 담는 방식부터 다시 짜야 해서, 운영 중인 서비스를 멈추고 공사를 해야 할 때도 있어요.

안타까운 건, 이런 일이 대개 서비스가 잘되기 시작할 때 터진다는 거예요. 손님이 늘고 직원이 필요해지는 바로 그 시점에 공사를 해야 하니, 성장에 써야 할 힘이 수리에 들어가요.

처음에 나눠 두면 되는 세 가지

다행히 이걸 막는 데 많은 게 필요하지는 않아요. 만들기 전에 종이 한 장으로 세 가지만 정해 두면 돼요.

지금 당장 역할이 둘뿐이어도, 앞으로 셋이 될 가능성이 보이면 자리를 미리 만들어 두는 게 좋아요. 빈자리를 만들어 두는 건 쉽지만, 나중에 자리를 끼워 넣는 건 어려워요.

데이터의 주인은 특히 놓치기 쉬워요. 저는 「한쪽이 떠나면 어떻게 되나요?」라는 질문을 꼭 해 봐요. 판매자가 탈퇴하면 손님의 주문 내역은 남아야 하고, 손님이 탈퇴하면 개인정보는 지워져야 해요. 이 답이 정해져 있으면 데이터를 담는 방식도 저절로 정해져요.

화면 지도에 역할을 같이 그리는 이유

저는 화면 지도(IA)를 그릴 때 화면마다 「누가 들어오는 화면인지」를 꼭 같이 적어요. 손님 화면, 직원 화면, 관리자 화면이 한눈에 갈라져 보이도록요.

이렇게 해 두면 AI에게 일을 시킬 때도 달라져요. 「예약 목록 만들어 줘」 대신 「손님이 자기 예약만 보는 목록」과 「직원이 오늘 예약 전체를 보는 목록」을 따로 요청하게 돼요. 요청이 분명해지니 결과도 분명해져요.

구조는 화면보다 먼저 정해야 하고, 출시 전에 정하는 게 가장 싸요. 플랜디에서 아이디어 인터뷰 다음 단계로 화면 지도를 두는 것도 그 때문이에요.

정리

1. 바이브코딩 서비스는 대개 역할·권한·데이터 주인을 안 나눈 곳에서 무너져요.
2. 혼자 쓸 때는 안 보이다가, 출시해서 여러 사람이 들어오면 한꺼번에 드러나요.
3. 만들기 전에 역할·권한·데이터 주인 세 가지를 종이 한 장에 정해 두세요.