예약이 저장되고 회원이 관리되는, 진짜로 일하는 앱
완성하면 생기는 것
뷰티 스튜디오 예약 앱을 예시로 화면 흐름·데이터 저장·BYO 연결·로그인·관리자 화면·결제 흐름까지, 데이터가 살아 있는 앱의 전 공정을 완주합니다.
바이브캠퍼스 계정필수
스튜디오에서 실습하며 진행합니다. 가입은 무료입니다.
웹사이트 마스터 코스 수료선택
섹션 구조·리파인·폰 미리보기에 익숙하다는 전제로 진행합니다. 순서를 권장합니다.
밤 11시, 뷰티 스튜디오 사장님의 폰이 조용히 울립니다. 내일 오후 2시 예약이 들어왔다는 알림입니다. 손님은 앱에서 시술 사진을 보고, 비어 있는 시간대를 골라 예약했고, 그 기록은 관리자 대시보드에 자동으로 쌓였습니다. 사장님이 한 일은 아침에 확인 버튼을 누른 것뿐입니다.
이번 코스에서 만드는 것이 바로 이 앱입니다. 보여 주기만 하는 페이지가 아니라 예약을 받고, 손님을 기억하고, 사장님에게 관리 화면을 내어 주는 서비스. 지금까지의 코스가 간판을 만드는 법이었다면, 이제 가게 전체를 짓습니다.
고급 코스라는 이름에 긴장할 필요는 없습니다. 어려운 것은 AI가 하고, 여러분은 어떤 가게를 지을지 결정하면 됩니다.
웹페이지와 앱을 가르는 기준은 화려함이 아니라 기억력입니다. 페이지는 누가 와도 같은 내용을 보여 주고, 방문자가 떠나면 아무것도 남지 않습니다. 앱은 다릅니다. 손님이 예약하면 그 예약이 남고, 다시 오면 알아보고, 쌓인 기록으로 관리 화면이 채워집니다.
그래서 앱에는 페이지에 없던 세 가지 부품이 필요합니다. 데이터를 보관할 저장소(DB), 사람을 구분할 로그인, 그리고 상태에 따라 달라지는 화면. 이 세 부품이 이번 코스의 주인공들입니다.
내 아이디어가 앱이어야 하는지 헷갈리면 이렇게 물어보세요. '방문자가 남긴 것이 내일도 남아 있어야 하는가?' 그렇다면 앱입니다.
자, 이제 첫 삽을 뜹니다. 아래 직접 해보기 버튼을 누르면 뷰티 스튜디오 예약 앱의 뼈대 프롬프트가 채워져 있습니다. 시간대 슬롯, 고객 로그인, 예약을 관리하는 관리자 대시보드. 앱의 3대 부품이 전부 명시된 주문서입니다.
빌드 종류가 앱으로 되어 있는지 확인하고 보내세요. 손님에게 내놓을 물건을 연습하는 것이니 빌드 모드는 심화(딥빌드)를 권합니다. 제품 기획서가 화면 흐름과 데이터 구조까지 잡아 주는 것을 직접 보게 될 겁니다.
틀려도 됩니다. 재생성은 무료입니다. 앱 빌드는 부품이 많은 만큼 첫판부터 완벽하지 않은 게 오히려 정상이고, 이 코스 전체가 그걸 다듬는 과정입니다.
이렇게 나오면 성공
빌드가 끝나면 미리보기에 시간대 선택 화면이 뜹니다. 예약을 하나 넣어 보고, 관리자 화면으로 들어가 방금 예약이 목록에 나타나는지 확인해 보세요.
앱에는 두 종류의 사람이 들어옵니다. 손님과 사장님. 두 동선을 분리해서 그리는 것이 화면 흐름 설계의 핵심입니다. 손님의 동선은 '시술 구경 → 시간대 선택 → 로그인 → 예약 확정 → 내 예약 확인'. 사장님의 동선은 '관리자 로그인 → 오늘 예약 목록 → 확정·취소 처리 → 시간대 관리'입니다.
이 동선을 프롬프트나 블루프린트 피드백에서 화살표 그대로 말해 주면 AI가 화면을 정확히 짭니다. '손님은 로그인 없이 구경까지는 가능하고, 예약 확정 직전에만 로그인을 요구해줘'처럼 순서에 대한 요구가 특히 값집니다.
왜 동선이 먼저냐면, 화면 하나하나의 디자인은 고치기 쉽지만 동선이 꼬인 앱은 뼈대부터 다시 지어야 하기 때문입니다.
팁
종이에 네모(화면)와 화살표(이동)만으로 동선을 먼저 그려 보세요. 5분짜리 낙서가 빌드 몇 번을 아껴 줍니다.
손님이 예약 버튼을 누르는 순간, 그 예약은 어디로 갈까요? 화면에만 있다면 새로고침 한 번에 증발합니다. 그래서 앱에는 냉장고가 필요합니다. 데이터베이스(DB), 넣어 둔 것을 내일 열어도 그대로 꺼낼 수 있는 저장소입니다.
냉장고 안은 칸으로 정리됩니다. 손님 칸에는 이름과 연락처, 예약 칸에는 날짜와 시간대와 담당자, 시술 칸에는 메뉴와 가격. 이렇게 칸을 나눠 두면 '이번 주 예약 전부'나 '단골 손님 목록'처럼 원하는 것만 골라 꺼낼 수 있습니다.
다행히 칸 설계는 AI가 잘합니다. 딥빌드의 기획서에 데이터 모델이라는 섹션이 있었던 것을 기억하세요. 여러분은 '무엇이 저장되어야 하는가'만 챙기면 됩니다. 예약 앱이라면 손님, 예약, 시술 세 가지가 반드시 저장되어야겠죠.
그 냉장고를 누구 명의로 둘 것인가. 이것이 BYO의 문제의식입니다. 바이브캠퍼스는 여러분 자신의 Supabase를 스튜디오에 직접 연결하는 것을 지원합니다. 손님 명단과 예약 기록 같은 사업의 핵심 자산이 처음부터 여러분 소유의 창고에 쌓이는 구조입니다.
연결은 어렵지 않습니다. Supabase에 가입해 프로젝트를 만들면 주소(URL)와 열쇠(키)를 받는데, 이 두 값을 스튜디오의 연결 설정에 넣으면 끝입니다. 아래 예시처럼 환경변수라는 금고에 보관되며, 코드에 직접 적히지 않습니다.
왜 이렇게까지 하냐면, 데이터의 명의가 곧 사업의 독립성이기 때문입니다. 내 창고에 쌓인 데이터는 언제든 통째로 들고 이사할 수 있습니다. 아래 카드 네 장으로 이 단계의 용어를 확실히 잡고 갑시다.
$# .env — your own Supabase, connected in the studio (BYO)$SUPABASE_URL=https://xxxx.supabase.co$SUPABASE_ANON_KEY=eyJhbGciOi...
이렇게 나오면 성공
예시의 두 줄이 연결의 전부입니다. SUPABASE_URL은 내 창고의 주소, SUPABASE_ANON_KEY는 출입증입니다. 두 값 모두 Supabase 대시보드에서 복사해 옵니다.
용어 카드 · 탭해서 열기
칸칸이 정리된 큰 냉장고입니다. 넣어 둔 것을 내일 열어도 그대로 있습니다.
손님, 예약, 시술 같은 정보를 구조적으로 보관하는 저장소입니다. 화면의 내용은 새로고침이면 사라지지만 DB에 저장된 것은 남습니다. 데이터가 살아 있는 앱의 심장입니다.
잠금장치와 배달 창구까지 갖춰 통째로 빌려주는 완성형 냉장고 창고입니다.
DB에 로그인, 파일 저장까지 묶어 주는 서비스입니다. 무료로 시작할 수 있고, 스튜디오와 직결하면 내 앱의 데이터가 처음부터 내 계정에 쌓입니다.
단골 식당에 내 와인을 가져가는 것입니다. 내용물도 계산도 전부 내 관리입니다.
Bring Your Own, 내 계정과 키를 가져와 연결하는 방식입니다. 데이터의 명의가 나에게 있으므로 서비스가 커져도 플랫폼에 묶이지 않고, 언제든 통째로 이사할 수 있습니다.
무대 뒤의 금고입니다. 배우는 연기만 하고 귀중품은 금고에 둡니다.
키 같은 비밀값을 코드 바깥에 보관하는 설정 공간입니다. 코드를 공유해도 비밀이 새지 않고, 창고를 바꿀 때도 코드는 그대로 두고 금고 속 값만 교체하면 됩니다.
주의
키는 비밀번호입니다. 화면 캡처, 커뮤니티 질문 글, 공개 코드 어디에도 붙여 넣지 마세요. 노출됐다면 Supabase에서 키를 재발급받는 것이 원칙입니다.
예약이 저장되기 시작하면 곧바로 다음 질문이 옵니다. 이 예약은 누구의 것인가? 그래서 로그인이 필요합니다. 로그인은 문지기입니다. 손님마다 자기 예약만 보이게 하고, 관리자 화면은 사장님에게만 열어 줍니다.
스튜디오에 요청할 때는 수준을 정해 주면 좋습니다. 가볍게 가려면 이메일 로그인, 문턱을 낮추려면 소셜 로그인, 그리고 관리자는 별도 권한으로. '손님은 소셜 로그인, 관리자는 별도 관리자 계정으로 분리해줘'라는 한 문장이면 AI가 문과 자물쇠를 함께 답니다.
주의
비밀번호 저장 로직을 직접 발명하려 하지 마세요. 로그인은 검증된 방식(Supabase 인증 등)에 맡기는 것이 보안의 정석입니다. AI에게도 '검증된 인증 방식을 써줘'라고 요청하면 됩니다.
앱의 데이터 품질은 폼에서 결정됩니다. 손님이 전화번호 칸에 '문자주세요'라고 적어 넣거나, 지나간 날짜로 예약하는 일은 반드시 생깁니다. 입력 검증은 이런 이상한 값을 저장되기 전에 문앞에서 돌려보내는 장치입니다.
요청 요령은 규칙을 나열하는 것입니다. '전화번호는 숫자만, 예약 날짜는 오늘 이후만, 이름은 필수'처럼요. 그리고 거절할 때의 안내 문구도 함께 챙기세요. '잘못된 입력입니다'보다 '전화번호는 숫자만 입력해 주세요'가 손님을 덜 떠나게 합니다.
팁
검증 규칙이 잘 작동하는지 시험할 때는 일부러 못된 손님이 되어 보세요. 빈칸 제출, 과거 날짜, 이모지 이름까지 넣어 보고 전부 친절하게 거절되면 합격입니다.
손님 쪽 화면이 매장이라면 관리자 화면은 조종석입니다. 오늘의 예약 목록, 확정과 취소 버튼, 시간대 열고 닫기, 간단한 통계까지. 사장님이 매일 아침 여는 화면이므로 화려함보다 한눈에 보이는 것이 최고의 미덕입니다.
요청할 때는 사장님의 하루를 기준으로 말하세요. '아침에 열면 오늘 예약이 시간순으로 보이고, 각 예약 옆에 확정·취소 버튼, 상단에 이번 주 예약 수 요약'처럼요. 실제 운영의 동선이 담긴 요청이 쓸모 있는 조종석을 만듭니다.
이렇게 나오면 성공
관리자 화면에서 예약 하나를 취소해 보세요. 손님 쪽 화면의 해당 시간대가 다시 예약 가능으로 풀리면, 두 화면이 같은 냉장고를 보고 있다는 증거입니다.
예약에 결제가 붙으면 노쇼가 줄고 매출이 앞당겨집니다. 스튜디오에서는 결제 흐름을 먼저 데모 모드로 지을 수 있습니다. 금액 표시, 결제 버튼, 완료 화면까지 실제와 똑같이 작동하지만 진짜 돈은 오가지 않는 상태입니다.
왜 데모부터냐면, 결제는 흐름 설계가 9할이기 때문입니다. 언제 결제를 요구할지(예약 확정 전? 방문 후?), 취소하면 어떻게 되는지 같은 규칙을 데모에서 충분히 다듬은 뒤, 결제 제공사 연동 준비가 되면 실결제로 전환하는 것이 안전한 순서입니다.
주의
실결제로 전환하기 전에 취소와 환불 흐름까지 반드시 데모에서 검증하세요. 돈이 들어오는 문보다 나가는 문이 허술할 때 사고가 납니다.
손님은 이 앱을 폰으로 씁니다. 폰 미리보기로 아이폰과 갤럭시 두 프레임을 열고, 시간대 버튼이 엄지로 누르기 충분한지, 예약까지의 스크롤이 길지 않은지 확인하세요. 폼 입력은 특히 폰에서 지옥이 되기 쉬우니 직접 예약 한 건을 폰 프레임 안에서 완주해 보는 것이 최고의 점검입니다.
그리고 손님에게 알려 줄 꿀팁 하나. 브라우저의 홈 화면에 추가 기능을 쓰면 내 앱이 폰 바탕화면에 아이콘으로 자리 잡습니다. 앱스토어를 거치지 않고도 설치된 앱처럼 쓰이게 되는 것이죠. 단골에게는 이 방법을 안내 문구로 알려 주는 것도 좋습니다.
팁
홈 화면 추가를 안내하는 작은 배너를 앱에 넣어 달라고 리파인으로 요청해 보세요. 재방문이 잦은 예약 앱과 특히 궁합이 좋습니다.
출시된 앱은 계속 자랍니다. 손님의 요구가 생기고, 메뉴가 바뀌고, 화면 하나가 더 필요해집니다. 바이브캠퍼스에서 앱을 기르는 길은 세 갈래입니다. 첫째, 리파인 채팅. 말로 요청하는 일상적인 수정에 가장 빠릅니다. 둘째, 클릭 편집. 문구와 디자인의 미세 조정을 손으로 직접 합니다. 셋째, 핸드오프팩. 코드를 통째로 내려받아 외부 개발 도구나 개발자에게 넘겨 이어 가는 큰 공사용 길입니다.
대부분의 날은 첫째와 둘째로 충분합니다. 셋째 길이 있다는 사실이 중요한 이유는 안심입니다. 어떤 순간에도 여러분의 앱은 이 플랫폼 안에 갇히지 않습니다.
팁
수정 요청이 쌓이면 즉흥적으로 처리하지 말고 메모로 모았다가 일주일에 한 번 몰아서 반영해 보세요. 앱의 방향이 일관되게 유지됩니다.
핸드오프팩은 내 빌드의 이삿짐입니다. 내려받으면 완성된 코드에 실행과 호스팅 방법을 담은 README, 그리고 AI 개발 도구에게 건네는 인수인계 문서인 AGENTS.md까지 zip 하나에 담겨 나옵니다.
이 zip을 풀어 Claude Code나 Cursor 같은 도구로 열면 바깥에서도 그대로 이어서 개발할 수 있고, 개발자를 고용하게 되면 이 팩 하나가 곧 인수인계 서류가 됩니다. 폼과 회원 기능도 계속 작동하도록 준비되어 나오니, 이사 후 첫날부터 영업이 됩니다.
떠나라고 만든 기능이 아니라, 떠날 수 있어서 안심하고 머물라고 만든 기능입니다. 내 사업의 어떤 자산도 인질이 되지 않는다는 것. 그것이 이 플랫폼의 약속입니다.
손님이 오늘 저장한 예약이 내일 앱을 다시 열어도 남아 있으려면 무엇이 필요한가요?
마지막 실전입니다. 아래 직접 해보기 버튼을 누르면 습관 트래커 앱 프롬프트가 채워져 있습니다. 데일리 체크리스트, 연속 달성을 세는 스트릭 카운터, 주간 진행 차트. 이번에는 뷰티 스튜디오와 전혀 다른 주제로, 배운 것이 진짜 실력이 됐는지 확인합니다.
핵심 관문은 하나입니다. 데이터가 정말 살아 있는가. 체크하고, 새로고침하고, 그래도 남아 있는지 여러분 눈으로 확인하세요.
직접 해보기미션
채워진 프롬프트로 습관 트래커 앱을 빌드하세요. 필수 체크는 네 가지입니다. ① 습관을 두 개 등록하고 오늘 치를 체크 ② 새로고침 후에도 체크 기록이 남아 있는지 확인 ③ 스트릭 카운터와 주간 차트가 기록을 반영하는지 확인 ④ 폰 미리보기로 아이폰·갤럭시에서 체크 버튼이 누르기 편한지 확인. 마치면 저장하세요.
모범 경로는 이렇습니다. 앱 종류와 심화 모드로 보내면 기획서의 데이터 모델에 습관과 체크 기록이 잡혀 있을 겁니다. 빌드 후 습관 두 개를 등록하고 체크한 뒤 새로고침했을 때 기록이 남아 있다면 저장이 제대로 연결된 것이고, 사라졌다면 리파인으로 '체크 기록이 새로고침 후에도 유지되게 저장해줘'라고 요청하면 됩니다. 스트릭이 어제와 오늘 연속 체크를 세는지, 주간 차트에 오늘 막대가 올라가는지까지 확인하고, 폰 프레임에서 체크 버튼 크기를 점검했다면 완주입니다. 이 과정을 스스로 진단하고 고쳤다면, 여러분은 이제 데이터가 살아 있는 앱을 다루는 사람입니다.
이 코스를 시작할 때 여러분은 화면을 만드는 사람이었고, 지금은 서비스를 짓는 사람입니다. 동선을 설계하고, 데이터의 명의를 챙기고, 문지기를 세우고, 조종석을 달고, 결제의 순서를 정하는 일까지. 이것이 앱을 만든다는 말의 진짜 의미입니다.
여기서 배운 뼈대는 어떤 업종에도 이식됩니다. 뷰티 스튜디오가 미용실이 되고, 습관 트래커가 독서 모임 출석부가 되는 것은 프롬프트 몇 단어의 차이일 뿐입니다. 다음은 여러분 자신의 아이디어 차례입니다.
