제가 진행한 거의 모든 회의적인 데모에서 나오는 질문입니다. 누군가 AI 빌더가 몇 분 만에 작동하는 앱을 만들어내는 것을 보고, "오, 빠르네"라는 첫 반응이 가시고 나면 진짜 질문이 나옵니다: 그런데 여기 진짜 데이터베이스가 있는 건가요, 아니면 그냥 흉내만 낸 건가요? 타당한 질문입니다. 사람들이 이 부분을 파고들면서 회의가 진화하는 순서대로, 대략 자주 나오는 질문들을 정리했습니다.
진짜 데이터베이스가 있는 건가요, 아니면 데모가 샘플 데이터로 흉내만 내는 건가요?
진짜 데이터베이스가 있습니다. 다만 어떤 것을 쓰는지가 다르며, 앞으로 유지할 계획인 무언가를 만들기 전에 이해할 가치가 있는 부분이 바로 그 차이입니다. "90초 만에 이게 작동하는 걸 보세요"에 최적화된 프로토타입형 AI 빌더는 보통 SQLite를 씁니다 — 디스크상의 단일 파일이고, 설정이 필요 없으며, 단일 사용자용 실제 앱을 실행하기에 완벽히 충분합니다. "실제 트래픽과 여러 테넌트에도 견뎌야 한다"에 최적화된 빌더는 Postgres를 씁니다. 둘 이상의 프로세스가 동시에 쓰기를 하는 순간부터 SQLite의 파일 잠금 모델이 고통스러워지기 때문입니다. 어떤 것을 쓰는지 물어보세요. 영업 페이지나 지원 채팅에 물어보기에 전혀 이상하지 않은 질문이고, 아무도 명확하게 답하지 못한다면 그 자체가 시사하는 바가 있습니다.
실제로 어떤 데이터베이스 엔진을 쓰나요?
장난감 수준을 넘어서는 것을 위해 만들어진 플랫폼이라면 Postgres입니다. 지루하지만 올바른 답이고, 여기서는 지루한 것이 원하는 것입니다. Postgres는 애플리케이션 코드에 버그가 있어도 테넌트 A의 행이 테넌트 B의 쿼리에 보이지 않도록 하는 행 수준 보안, 진짜 외래 키, 진짜 트랜잭션을 제공하며, 20년간 "누군가 이미 이 엣지 케이스를 겪고 고쳤다"는 이력이 뒷받침합니다. 흥미로운 실패 지점은 "어떤 SQL 방언인가"가 아니라, 속도를 위해 SQLite로 시작했다가 사용량이 늘어나도 절대 마이그레이션하지 않는 빌더들입니다. 사용자가 있는 라이브 데이터베이스를 마이그레이션하는 건 화려하지 않은 작업이라 계속 우선순위에서 밀리기 쉽기 때문입니다. 몇 년간 운영할 것을 목적으로 빌더를 평가한다면, 앱이 사용자 한 명을 넘어 확장될 때 데이터베이스에 무슨 일이 생기는지 물어보세요. 정직한 답에는 마이그레이션 경로가 포함되고, 회피하는 답에는 구체적인 것 없이 "확장 가능"이라는 단어만 반복됩니다.
제 데이터를 직접 볼 수 있나요, 아니면 블랙박스 안에 갇혀 있나요?
당연히 볼 수 있어야 합니다. 테이블 브라우저, 쿼리 콘솔, 내보내기 버튼 — 앱 자체의 UI를 거치지 않고 행을 들여다볼 수 있는 어떤 방법이든 있어야 합니다. 이는 기술적인 질문이라기보다 신뢰의 질문입니다. 검사할 수 없는 스키마를 생성하는 AI 빌더는 당신이 작성하지 않았고 감사할 수도 없는 코드를 신뢰하라고 요구하는 것이며, 이는 "믿어보세요, UI 버튼은 작동합니다"보다 훨씬 큰 요구입니다. 이 부분을 제대로 다루는 도구들은 기본적으로 기저 데이터를 당신이 접근하지 못하게 보호하는 구현 세부사항이 아니라, 당신 소유의 것으로 취급합니다.
새 기능을 요청하면 스키마 변경도 처리해주나요?
바로 여기서 진짜 어려워지고, 많은 AI 빌더들이 조용히 부족함을 드러내는 지점입니다. 컬럼을 추가하는 건 쉽습니다. 컬럼을 추가하고, 기존 행에 합리적인 기본값으로 백필하고, 그 테이블을 다루는 모든 쿼리를 업데이트하고, 이미 있는 데이터를 잃지 않으면서 그걸 해내는 것 — 그것이 마이그레이션이며, "AI가 컴파일되는 코드를 작성했다"가 "AI가 운영 데이터에 안전하게 실행할 수 있는 코드를 작성했다"와 같지 않은 몇 안 되는 지점 중 하나입니다. 제대로 된 빌더는 스키마 변경을 더 큰 기능 요청에 조용히 끼워 넣는 것이 아니라 그 자체로 검토 가능한 단계로 다룹니다. "작업에 마감일 추가해줘"라고 요청했는데 프런트엔드만 바뀐 diff가 돌아온다면 의심하세요 — 데이터베이스는 그 메모를 받지 못한 겁니다.
관계를 제대로 모델링하나요, 아니면 모든 것이 하나의 큰 JSON 덩어리로 평탄화되나요?
둘 다 존재하며, 처음 시작할 때 사람들이 생각하는 것보다 어느 쪽을 얻느냐가 더 중요합니다. 사용자, 주문, 주문 항목을 위한 별도 테이블을 외래 키로 연결하는 관계형 스키마는 앱의 원래 UI가 전혀 예상하지 못했던 질문을 할 수 있게 해줍니다: "X와 Y를 함께 구매한 고객은 누구인가", "제품 카테고리별 환불율은 얼마인가". 레코드당 단일 비정규화 JSON 덩어리는 생성이 더 빠르고 정말 단순한 앱에는 괜찮지만, 향후 "리포트만 추가해줘"라는 모든 요청을 재설계 작업으로 바꿔버립니다. 실행 중인 앱만이 아니라 스키마를 보여달라고 요청하세요. 모든 테이블이 `{ id, data jsonb }` 처럼 의심스럽게 보인다면, 화면에 무언가를 빠르게 띄우는 데 최적화하고 실제 데이터 모델링은 미룬 빌더를 보고 있는 것입니다.
| 패턴 | 잘하는 것 | 깨지는 지점 |
|---|---|---|
| 제대로 된 관계형 스키마 (별도 테이블, 외래 키) | 리포팅, 조인, 데이터 무결성, 아직 생각하지 못한 미래 기능 | 초기 생성 시간이 조금 더 걸림; 단순한 프롬프트로 첫 시도에 정확히 맞추기 더 어려움 |
| 레코드당 단일 JSON 덩어리 | 첫 데모까지의 속도, 단순한 단일 엔티티 앱(메모 도구, 기본 양식) | 레코드를 넘나드는 모든 쿼리, 모든 관계, 모든 리포트 — SQL이 아니라 애플리케이션 코드의 우회책이 됨 |
| 하이브리드 (핵심 필드는 컬럼, 유연한 부가 항목은 jsonb 컬럼) | 안정적인 핵심 형태에 사용자 정의 필드가 추가되는 앱 | 빌더가 언제 어느 것을 써야 하는지 알아야 함 — 부실한 버전은 모든 것을 그냥 jsonb 컬럼에 넣어버림 |
만들어질 때 예상했던 데이터 양을 넘어서면 어떻게 되나요?
기저 엔진이 애초에 동시성을 위해 만들어졌는지에 전적으로 달려 있습니다. 이는 SQLite 대 Postgres 질문이 다른 모습으로 다시 나타난 것입니다. 한 사용자를 위해 수백 개 행을 다루는 SQLite 기반 앱은 같은 부하를 다루는 Postgres 기반 앱과 동일하게 느껴집니다 — 그 차이는 동시 쓰기자를 추가하거나, 행 수가 늘어나거나, 인덱스와 쿼리 플래닝의 이점을 보는 분석 쿼리를 실행할 때만 드러납니다. 앱이 진짜로 영구히 단일 사용자, 저용량이라면 이 문제는 영영 발생하지 않을 수 있습니다. 고객이 생기길 바라는 무언가를 만들고 있다면, 지원 티켓이 답을 가르쳐주기 전에 확장성 질문을 먼저 해두세요.
공유 플랫폼에서 다른 사용자들로부터 제 데이터가 실제로 격리되어 있나요?
이것이 제가 가장 강하게 밀어붙이고 싶은 질문입니다. 실패할 때까지는 보이지 않기 때문입니다. 모든 사람의 데이터를 같은 데이터베이스에 저장하는 멀티테넌트 플랫폼은 진짜 격리 경계가 필요합니다 — 데이터베이스 자체가 강제하는 행 수준 보안 정책이어야지, 모든 쿼리에 `WHERE user_id = ?` 절을 추가하는 걸 기억하는 애플리케이션 코드에만 의존해서는 안 됩니다. 이 차이가 중요한 이유는 애플리케이션 코드 격리는 조용히 실패하기 때문입니다: 한 엔드포인트에서 필터 하나만 빠뜨려도 테넌트 A가 갑자기 테넌트 B의 행을 볼 수 있게 됩니다. 데이터베이스가 강제하는 격리는 크게 실패합니다. 애플리케이션 코드가 필터를 빠뜨려도 쿼리는 그냥 아무것도 반환하지 않기 때문입니다. 테넌트 격리가 데이터베이스 계층에서 강제되는지, 아니면 애플리케이션 코드에 맡겨져 있는지 구체적으로 물어보세요. "진짜 데이터베이스를 다룰 수 있나요"라고 묻는 대부분의 사람들은 사실 아직 그 용어를 몰라서 이 질문을 하고 있는 것입니다.
원한다면 모든 것을 내보내고 떠날 수 있나요?
실제 데이터의 전체 내보내기를 받을 수 있어야 합니다 — 앱의 스크린샷도, 리포트의 PDF도 아니라, 다른 곳에 불러올 수 있는 형식의 기저 행 데이터여야 합니다. 이를 어렵게 만드는 빌더는 그 관계를 어떻게 생각하는지에 대해 무언가를 말해주고 있는 것입니다. "AI 빌더"의 정직한 의미는 플랫폼이 당신을 대신해 코드와 스키마를 생성했다는 것이지, 당신이 직접 프로비저닝하지 않은 테이블에 데이터가 들어가는 순간 그 데이터가 당신 것이 아니게 된다는 뜻이 되어서는 안 됩니다.
데이터베이스는 아무도 데모해주지 않는 부분이며, 그렇기 때문에 무언가에 가입하기 전에 물어볼 가치가 있는 부분이기도 합니다.
이 중 어느 것도 특별히 이색적인 엔지니어링이 아닙니다. 어떤 백엔드형 서비스(BaaS)나 호스팅을 결정할 때든 적용할 만한 동일한 실사 과정일 뿐입니다. AI라는 요소는 그저 물어보는 걸 잊기 쉽게 만들 뿐입니다. 데모가 배관을 숨기는 데 워낙 능숙하기 때문이죠. 어떤 엔진인지 물어보고, 스키마를 보여달라고 하고, 마이그레이션에 대해 묻고, 격리에 대해 물어보세요. 답이 구체적이라면 아마 괜찮을 것입니다.
