AI 앱 빌더가 가짜 데이터를 먼저 보여 주는 이유 (그리고 그게 옳은 선택인 이유)
AI 앱 빌더가 데이터베이스를 건드리기 전에 화면을 지어낸 사용자와 샘플 주문으로 채운다면, 그건 지름길이 아니라 — 올바른 제작 방식입니다. 그 이유를 알려 드립니다.
AI 앱 빌더에게 앱을 설명합니다. 1분 뒤 작동하는 인터페이스를 보고 있습니다 — 페이지, 버튼, “Alex Rivera”나 “Priya Shah” 같은 이름의 사용자가 담긴 표, 말이 안 되는 가격, 요청한 적 없는 “Pro Plan”. 아무것도 저장되지 않습니다. 새로고침하면 데이터는 그대로 있습니다. 새 사용자를 추가하면 사라집니다.
곧 무너질 마술 트릭처럼 보입니다. 아닙니다. 그게 빌드의 좋은 부분입니다. 화면의 목업 데이터는 의도된 첫걸음이고, 그다음에 나올 데이터베이스가 당신이 원한 앱과 실제로 들어맞게 되는 이유입니다.
”가짜 데이터 먼저”가 진짜 뜻하는 것
AI 앱 빌더는 당신의 요청을 받아도 곧장 데이터베이스로 가지 않습니다. 좋은 빌더는 화면을 먼저 쓰고, 그럴듯한 자리표시 데이터로 채운 다음 — 그러고 나서야 — 거기에 맞춰 데이터베이스를 설계합니다.
자리표시 데이터는 장식이 아닙니다. 계약입니다. 앱이 “모든 주문에는 고객 이름, 항목 세 개, 합계, 상태가 있다”고 말하는 순간, 그다음에 만들어지는 데이터베이스는 정확히 그것들을, 정확히 그 모양으로 가져야 합니다. 데이터가 어떻게 생겼는지는 화면이 정하지, 그 반대가 아닙니다.
이건 사람 개발자가 보통 시작하는 방식과 거꾸로입니다. 전통적인 개발자는 데이터베이스를 먼저 설계하고, 거기에 맞춰 화면을 만듭니다. AI 빌더는 그걸 뒤집었고, 대부분의 사람은 알아채지 못합니다 — 그저 가짜 사용자를 보고 빌더가 흉내만 내고 있다고 여기죠.
왜 이 순서가 AI에 더 잘 맞는가
저희는 데이터베이스와 화면을 동시에 만들어 봤습니다. 안 됐습니다. 왜 그런지 짧게 말씀드리죠.
두 AI 에이전트가 서로의 결과물을 보지 못한 채 앱의 다른 부분을 작업하면, 호환되지 않는 추측을 합니다. 인터페이스 에이전트는 사용자에게 “name” 항목이 있다고 정합니다. 데이터베이스 에이전트는 사용자에게 “fullName” 항목이 있다고 정합니다. 둘 다 맞아 보입니다. 합쳐 놓으면 아무것도 작동하지 않습니다. 세 번째 에이전트가 그 불일치를 땜질하러 투입됩니다. 그것도 추측을 합니다. 이제 추측이 셋이나 풀려나 있고, 당신이 미리보는 앱은 그 모두가 섞인 프랑켄슈타인입니다.
해결책은 거의 민망할 정도입니다: 한 가지를 먼저 하고, 그다음에 다른 것을 한다. 인터페이스가 만들어집니다. 필요한 데이터를 가짜 사용자, 가짜 주문, 당신 앱의 주제가 무엇이든 그 가짜 무언가의 단일 파일로 적어 둡니다. 데이터베이스 에이전트는 그 파일을 읽고 항목 하나하나를 맞춥니다. 추측 없음. 협상 없음. 불일치 없음.
그래서 AI 앱 빌더가 1분 만에 완성된 듯한 앱을 보여 줄 수 있는 겁니다. 빌드를 흉내 낸 게 아닙니다. 빌드의 4분의 1을 — 나머지 모든 것을 결정하는 그 부분을 — 끝낸 것이고, 데이터베이스는 앞으로 10시간이 아니라 앞으로 10초의 작업인 셈입니다.
가짜 데이터가 화면에 있을 때 무엇을 볼까
여기가 대부분의 사람이 그냥 지나치는 순간입니다. 자리표시 데이터를 보고는 색깔을 바꿔 달라고 하기 시작하죠. 하지만 자리표시 데이터는 당신에게 던지는 질문입니다. 읽으세요.
무엇을 살펴봐야 하는지 몇 가지 예를 들면:
- 틀린 어휘. 당신이 원한 앱은 “배송(shipments)“을 추적합니다. 자리표시 데이터는 그걸 “주문(orders)“이라고 부릅니다. 빌더에게 말하세요. 지금 그냥 넘어가면, 모든 화면, 모든 데이터베이스 항목, 모든 보고서가 틀린 단어를 쓰게 됩니다 — 그리고 나중에 이름을 바꾸는 건, 마케팅이 뭐라 하든, 어떤 도구에서도 클릭 한 번으로 되는 작업이 아닙니다.
- 빠진 항목. 가짜 청구서에는 합계와 날짜가 있습니다. 당신에게는 PO 번호도 필요하고요. 화면에 가짜 청구서 다섯 개가 있는 지금 추가하는 게, 데이터베이스가 만들어지고 진짜 고객 데이터로 채워진 뒤보다 낫습니다.
- 틀린 모양. 목업 데이터는 “고객 1명, 주소 1개”를 보여 줍니다. 당신의 실제 고객은 주소가 여러 개입니다. 빌더는 당신의 요청만으로는 그걸 추론할 수 없습니다. 모양을 바꾸는 데 아무 비용도 들지 않는 지금 말하세요.
- 뜻밖의 개체. 빌더가 당신이 요청하지도 않은 “팀” 개념을 지어냈습니다. 멀티유저 앱이라고 가정했기 때문이죠. 원했을 수도 있습니다. 아니었을 수도 있고요. 어느 쪽이든, 데이터베이스가 그걸 중심으로 만들어지기 전에 결정하세요.
유용한 규칙: 당신 앱에 있는 명사가 화면의 자리표시 데이터에 표현되어 있지 않다면, 빌더는 아직 그걸 모르는 겁니다. 첫 미리보기에서 “저장”을 누르기 전에 언급하세요.
왜 그 순서가 다음에 올 것을 좌우하는가
자리표시 데이터가 일단 맞으면, 데이터베이스 빌드는 기계적입니다. 빌더는 당신의 가짜 데이터를 읽고, 거기에 맞는 스키마를 생성하고, 화면이 이미 호출하려던 쿼리를 쓰고, 마지막으로 자리표시 임포트를 진짜 것으로 교체합니다. 가짜 사용자를 보여 주던 그 화면이 이제 당신이 실제로 넣은 것을 보여 줍니다.
보통은 그 교체가 실시간으로 일어나는 걸 볼 수 있습니다. 로컬 파일을 읽고 있어서 즉시 로딩되던 페이지가, 이제 0.5초짜리 로딩 상태를 갖습니다 — 그건 화면이 처음으로 진짜 데이터베이스와 대화하는 순간입니다. 대부분의 사람은 이걸 놓치고, 앱이 방금 “데모”에서 “진짜 데이터를 저장할 수 있는 것”으로 선을 넘었다는 걸 알아채지 못합니다.
이게 애초에 통하는 이유는, 그 하류의 모든 것 — 데이터베이스 설계, 쿼리, 로딩 상태, 빈 상태 — 이 자리표시 단계에서 당신이 화면에서 본 것에 의해 결정됐기 때문입니다. 세 개의 열에 동의했다면, 세 개의 열을 얻습니다. 값이 “draft”와 “sent”인 “status” 항목에 동의했다면, 데이터베이스는 정확히 그것을 받아들입니다. 디자이너-개발자 인수인계에서 무언가를 망가뜨리는 두 번째 번역 단계 같은 건 없습니다.
직접 해 볼 수 있는 작은 실험
다음에 무언가를 만들 때 이걸 시도해 보세요: 자리표시 데이터가 나타나면, 다른 어떤 것을 요청하기 전에 그 데이터에서 한 가지를 바꿔 보세요. 항목 이름을 바꾸세요. 열을 추가하세요. “users”를 “members”로 바꾸세요. 그런 다음 데이터베이스가 만들어질 때 무슨 일이 일어나는지 지켜보세요.
그 변경이 모든 곳에 나타나는 걸 보게 됩니다 — 데이터베이스 설계에, 쿼리에, 앱이 완성될 때 빌더가 넣는 시드 데이터에. 자리표시 단계의 단어 하나가 앱 전체에 파문을 일으켰습니다. 그게 이 단계에서 당신이 가진 지렛대이고, “가짜 데이터 먼저”가 손쉽게 모서리를 자르는 트릭이 아닌 이유입니다. 거기가 앱이 실제로 결정되는 곳입니다.
더 깊이 들어가고 싶다면, 지난번 글 AI로 만든 앱 안에 실제로 무엇이 들어 있는가가 처음 봐서는 보이지 않는 다른 움직이는 부품들을 짚어 줍니다. 패턴은 같습니다: 지렛대의 대부분은 중요해 보이지 않는 부분에 있습니다.