우리는 작동하는 예약 앱 — 로그인, 빈 시간대 캘린더, 결제, 이메일 알림 — 을 처음부터 끝까지 30분 만에 만들었고, 모든 단계를 기록했습니다. 예쁜 미리보기에서 멈추는 데모가 아닙니다. 실제 도메인 위의 진짜 앱입니다. 여기 스택과 프롬프트가 있습니다.
스택
많이 필요하지 않으며, AI 빌더가 대부분을 연결해 줍니다:
- Supabase — Postgres 데이터베이스에 더해 인증(이메일/비밀번호, 매직 링크, Google이나 GitHub OAuth)과 행 수준 보안. 이것이 중추입니다.
- Stripe — 유료 예약을 위한 결제 단계.
- Resend — 확인 및 알림 이메일.
핵심은 Supabase입니다. 하나의 대시보드에서 진짜 데이터베이스, 진짜 인증, 그리고 스토리지를 제공하므로 대부분의 AI 빌더가 직접 통합하는 것입니다.
프롬프트별로 보는 빌드
대략 다섯 개의 프롬프트면 도달합니다:
- 스캐폴드 — “예약 앱. 이메일 로그인. 빈 30분 시간대를 보여 주는 캘린더.” 몇 분 만에 인증이 포함된 작동 앱을 얻습니다.
- 데이터 모델 —
slots테이블과appointments테이블, 그리고 로그인한 사용자가 자기 예약만 볼 수 있도록 하는 행 수준 보안. - 결제 — 시간대가 확정되기 전 Stripe 체크아웃 단계.
- 알림 — 확정 시 Resend 이메일, 그리고 예약 전 리마인더.
- 관리자 — 오늘의 예약 목록을 보여 주는 페이지.
AI가 틀리는 부분
여기 AI 빌더가 매번 기본으로 출시하는 버그가 있습니다: 중복 예약. 순진하게도 생성된 코드는 빈 시간대를 읽은 다음 예약을 씁니다 — 그리고 두 사람이 같은 순간에 같은 시간대를 클릭하면 두 쓰기가 모두 성공합니다. 하나의 시간대를 두 번 판 것입니다.
해결책은 예약을 행 수준 잠금이 있는 단일 데이터베이스 트랜잭션으로 만드는
것입니다 — 시간대 행을 잠그고, 여전히 비어 있는지 확인하고, 예약을 쓰고, 해제합니다.
Supabase에서 이는 클라이언트의 별개 쿼리 두 개가 아니라 Postgres 트랜잭션(함수 안의
SELECT ... FOR UPDATE)입니다. AI는 요청하지 않으면 거의 절대 이 방법에 손을 뻗지
않습니다. 그러니 요청하세요:
“두 사용자가 같은 시간대를 예약할 수 없도록 시간대 예약을 행 수준 잠금이 있는 단일 Postgres 트랜잭션으로 만들어 줘.”
이것이 데모와 고객이 만지게 둘 수 있는 무언가의 차이입니다 — 그리고 바로 이런 종류의 정확성이 중요한 로직이 AI가 여전히 사람의 점검을 필요로 하는 지점입니다.
출시하기
미리보기 URL 위의 작동하는 앱은 아직 제품이 아닙니다. 당신의 도메인으로 연결하세요 — 그건 10분짜리 작업입니다 — 그러면 라이브 상태가 됩니다.
결론
30분은 진짜입니다, 별표 하나와 함께: AI는 당신을 빠르게 95%까지 데려가고, 마지막 5% — 동시성, 보안 규칙, 돈이 걸린 엣지 케이스 — 가 당신의 값어치를 증명하는 지점입니다. 그 5%가 어디인지 알면 스크린샷이 아니라 진짜를 출시하게 됩니다.