바이브 코딩 홍보 문구는 거의 첫 문단부터 코드 소유권을 언급한다. GitHub로 내보낼 수 있다, 독점 포맷이 아니다, 가지고 나갈 수 있다. 락인과는 정반대처럼 들리고, 앱에서 그저 React 컴포넌트에 불과한 부분에 한해서는 대체로 사실이다.
그 홍보 문구에 결코 등장하지 않는 부분이 데이터베이스다. 그리고 실제 앱은 바로 그 데이터베이스 안에 있다.
‘내보내기’가 실제로 내보내는 것
Bolt와 Base44 모두 프런트엔드용으로 간단한 GitHub 동기화를 제공하며, Lovable도 React/TypeScript 출력물에 대해 마찬가지다. 앱이 마케팅 사이트나 정적 프로토타입이라면 그 내보내기가 거의 전부이며, 저장소를 개발자에게 넘기고 깔끔하게 손을 뗄 수 있다.
업무용 앱은 그렇지 않다. 로그인, 역할, 실제 데이터가 등장하는 순간, 앱을 작동시키는 대부분은 컴포넌트 트리가 아니라 그 뒤에 있는 스키마, 인증 규칙, 권한 로직에 들어 있다. 그리고 바로 그 계층이야말로 이런 플랫폼들이 가장 쉽게 놓아주지 않으려는 부분이다.
Base44는 이를 암묵적이 아니라 명시적으로 드러낸다. 리뷰어들은 프런트엔드 코드는 GitHub로 내보낼 수 있지만, 데이터베이스와 백엔드는 전적으로 Base44 인프라에 호스팅된 채로 남아 있으며 직접 수정하거나 내보낼 수 없다고 지적한다. 자신의 파일을 플랫폼에서 빼내려던 한 Base44 빌더는 Reddit에 이렇게 직설적으로 적었다. “접근 가능한 파일 목록에 src 파일이 하나도 안 보인다. 빌드를 Base44에서 빼내려면 빌더 등급을 1년치 결제해야 할 것 같아 걱정된다. 480달러라니 좀 어이가 없다.” 기술적으로는 떠날 수 있다. 다만 무엇을 들고 떠나게 되는지 알아보려면 먼저 요금을 내야 한다.
호텔 캘리포니아 문제
Lovable에 대한 불만은 한 걸음 더 나아간다. 문제는 무엇이 내보내지지 않느냐가 아니라, 묻지도 않고 무엇이 바뀌느냐이기 때문이다. 커뮤니티에서 기준점처럼 회자되는 한 Reddit 스레드는 Lovable의 AI가 빌더의 프라이빗 Supabase 데이터베이스를 명시적 동의 없이 Lovable Cloud로 자율적으로 마이그레이션했다고 설명하며, 이 플랫폼을 “당신의 데이터베이스를 위한 호텔 캘리포니아, 체크인은 할 수 있지만 절대 나갈 수는 없다”라고 표현한다.
이는 ‘내보내기 버튼이 없다’와는 다른 종류의 실패다. 플랫폼이 애초에 내보내야 할 대상 자체를 조용히 옮겨버리는 것이다. 툴의 마케팅 방식을 믿고 자기 데이터가 자신의 Supabase 프로젝트에 있다고 가정했다면, 나중에 사실이 다르다는 것을 알게 되는 경험은 훗날 같은 가정을 하려는 다른 빌더들이 그 직전에 발견하게 되는, 경고성 Reddit 스레드로 남을 만한 종류의 놀라움이다.
Base44의 백엔드 락인은 다른 각도에서 같은 결론에 도달한다. 한 Product Hunt 리뷰어는 프런트엔드 코드가 깔끔하게 내보내지는 경우에도 데이터베이스와 백엔드는 Base44의 폐쇄형 인프라에 갇힌 채로 남아 진정한 의미의 데이터베이스 마이그레이션을 가로막는다고 지적했다. 두 플랫폼, 두 가지 방식, 그러나 결과는 같다. 실제 비즈니스 데이터를 담고 있는 부분이야말로 쉽게 들고 나갈 수 없는 부분이라는 것이다.
이 문제가 평행선이 아니라 계속 쌓여가는 이유
첫날에는 이 문제가 별로 중요하지 않다. 첫날은 샘플 데이터로 만든 데모일 뿐이기 때문이다. 문제가 중요해지기 시작하는 것은 앱에 실제 사용자가 생기고, 스키마가 처음 프롬프트 하나로 만들어졌던 범위를 넘어 커진 뒤부터다.
스키마 부채야말로 ‘언젠가 마이그레이션하면 돼’를 ‘이제 오도 가도 못 한다’로 바꿔놓는 메커니즘이다. Lovable을 오래 사용해온 빌더들에 따르면, AI에게 데이터베이스 스키마 설계를 맡기는 것은 처음에는 잘 작동하지만, 6개월에서 9개월쯤 지나면 필드 하나만 새로 추가해도 수십 개의 하위 워크플로를 다시 작성해야 할 정도로 심각한 스키마 부채가 쌓인다. 그 시점이 되면 마이그레이션은 테이블을 복사하는 일이 아니라, 만드는 동안 아무도 완전히 문서화하지 않은 시스템을 풀어헤치는 일이 된다. 같은 자료는 경험 많은 빌더들이 이제 18개월에서 24개월 이상 운영할 목적이라면 Lovable을 권하지 않으며, 그 부채가 더 쌓이기 전에 코드 우선 스택으로 옮길 것을 권장한다고 밝힌다.
여기에 플랫폼 자체가 스스로 발등을 찍는 문제까지 더해진다. Lovable 빌더들은 플랫폼 자체의 업데이트가 기존 클라이언트 앱을 정기적으로 망가뜨린다고 말하며, 일부는 이제 플랫폼 스스로가 일으킨 문제를 수습하기 위한 명목으로 클라이언트에게 월 유지보수 비용을 청구하고 있다. 데이터베이스에만 묶여 있는 게 아니다. 락인된 상태에서 벤더가 일으키는 피해를 고쳐주는 일에도 묶여 있는 것이다.
“Base44가 정말 무섭다. 내 사업의 기반을 그 플랫폼 위에 짓고 있는데… 오늘 작동하던 게 내일이면 사라져 버리니까.” - Base44 사용자, r/Base44
실제로 위험을 줄여주는 것
‘호스팅형 플랫폼’이면서 락인이 전혀 없는 버전이 존재하는 척은 하지 않겠다. Softr도 호스팅형이며, 계정을 닫으면 Lovable이나 Base44에서와 마찬가지로 들고 나갈 수 있는 이식 가능한 앱이 남지는 않는다. 정직한 질문은 ‘락인을 완전히 피할 수 있는가’가 아니라 ‘플랫폼을 계속 사용하는 동안 내 데이터가 얼마나 계속 접근 가능하게 남아 있는가, 그리고 언젠가 나가야 할 때 그 출구는 얼마나 나쁜가’다.
이 질문에서는 마케팅 문구보다 실제 작동 방식이 더 중요하다. 어떤 플랫폼 위에든 사업의 핵심을 떠받칠 무언가를 만들기 전에 확인해볼 만한 몇 가지가 있다.
- 외부 툴이 앱의 UI를 거치지 않고 데이터에 접근할 수 있는가? Softr의 데이터베이스는 자체적으로 MCP 서버(
mcp.softr.io)와 REST API를 공개하고 있어, Claude, Cursor, 또는 스크립트 같은 툴이 아직 개발 중인 상태에서도 자연어로 스키마를 읽고 쓰고 재구성할 수 있다. Softr는 이를 데이터베이스를 단일 인터페이스 밖에서도 접근 가능하게 유지함으로써 락인을 막는 장치라고 직접 설명하는데, 이는 ‘언젠가는 코드를 내보낼 수 있다’와는 다른 종류의 약속이다. - 플랫폼이 알리지 않고 조용히 인프라를 옮기는가? 이는 정확히 Lovable에 제기된 불만이다. 플랫폼이 AI 동작의 일환으로 데이터가 있는 위치를 재배정할 수 있다면, 무엇이 그것을 유발하는지, 그리고 이를 거부할 수 있는지 확인해두자.
- 6개월 뒤 스키마를 바꾸는 데 실제로 얼마나 비용이 드는가? 모든 것이 갓 만들어진 AI 뼈대에 불과한 첫날이 아니라, 실제 사용이 데이터를 형성한 이후를 기준으로 봐야 한다. 스키마 부채는 락인의 느린 버전이며, 가격 페이지에는 결코 나타나지 않는 종류다.
앱이 정말로 프로토타입이거나 개인 프로젝트라면, 이 중 어떤 것도 이번 주말에 바이브 코딩으로 그것을 만드는 걸 막을 이유가 되지 않는다. 코드를 내보낼 수 있든 없든 상관없다. 하지만 클라이언트 포털이나 사내 툴, 혹은 실제 사용자와 실제 데이터를 다루는 무언가라면, Day Two 문제와 락인 문제는 이름만 두 개인 같은 문제다. 첫날 생각하지 않았던 배관이야말로 200일째 되는 날 가장 옮기기 힘든 부분이 된다. 쉽게 떠날 수 없는 토대를 고르기 전에 클라이언트 포털 랭킹을 확인해 보자.