데이터가 필요한 순간: Supabase를 아주 쉽게 이해하기

웹페이지가 '기억'을 갖기 시작하는 순간

지금까지 우리가 만든 페이지들은 대부분 방문자에게 정보를 보여주고, 버튼을 누르게 하고, 문의나 신청을 유도하는 형태였습니다. 프리랜서 포트폴리오 페이지는 나를 소개했고, 상담 신청 페이지는 서비스를 설명했으며, 디지털 상품 랜딩 페이지는 구매 전 관심을 끌어냈습니다.

그런데 어느 순간 이런 질문이 생깁니다.

"방문자가 입력한 문의 내용은 어디에 저장되지?"

"예약 신청자가 여러 명이면 내가 어떻게 확인하지?"

"고객마다 자기 신청 내역만 보이게 할 수 있을까?"

이때부터 웹페이지는 단순한 소개 페이지를 넘어섭니다. 이제 웹페이지는 무언가를 저장하고, 불러오고, 관리해야 합니다. 그리고 바로 이 순간 데이터베이스가 필요해집니다.

초보자 입장에서 데이터베이스라는 말은 조금 무섭게 들릴 수 있습니다. 하지만 너무 어렵게 생각하지 않아도 됩니다. 데이터베이스는 쉽게 말해 "웹사이트 뒤에 있는 정리된 엑셀 파일"에 가깝습니다. 방문자가 이름, 이메일, 상담 내용을 입력하면 그 정보가 표 형태로 저장됩니다. 나중에 관리자는 그 표를 열어보고, 필요한 고객에게 연락하고, 상태를 바꿀 수 있습니다.

Lovable에서 이런 역할을 자주 맡는 도구가 바로 Supabase입니다.

Supabase는 웹사이트 뒤편의 사무실이다

러버블이 눈에 보이는 웹페이지를 잘 만들어주는 도구라면, Supabase는 그 웹페이지 뒤편에서 데이터를 보관하고 처리하는 사무실에 가깝습니다. Lovable 공식 문서에서도 Supabase 연동을 통해 PostgreSQL 데이터베이스, 사용자 인증, 파일 저장, 실시간 업데이트, 서버리스 함수 같은 백엔드 기능을 사용할 수 있다고 설명합니다.¹

여기서 백엔드라는 말이 나왔습니다. 백엔드는 사용자의 눈에 직접 보이지는 않지만 웹서비스가 제대로 작동하도록 뒤에서 일하는 부분입니다. 식당으로 비유하면 홀은 프론트엔드, 주방과 주문 관리 시스템은 백엔드입니다. 손님은 메뉴판과 테이블만 보지만, 음식이 나오려면 주방이 있어야 합니다.

Supabase가 대신 해주는 대표적인 일은 다음과 같습니다.

• 데이터베이스: 문의 내역, 예약 신청, 고객 목록, 상품 목록처럼 저장해야 하는 정보를 보관합니다.

• 인증: 회원가입, 로그인, 로그아웃처럼 "이 사람이 누구인지" 확인합니다.

• 파일 저장: 프로필 사진, 포트폴리오 이미지, 첨부 문서 같은 파일을 저장합니다.

• 실시간 기능: 새 신청이 들어오면 화면이 새로고침 없이 바뀌는 기능을 만들 수 있습니다.

• 백엔드 함수: 이메일 발송, 결제 처리, 외부 API 연결처럼 사용자 브라우저에서 직접 처리하면 위험하거나 복잡한 일을 맡길 수 있습니다.

초보자는 이 모든 기능을 처음부터 다 알 필요는 없습니다. 지금 단계에서 꼭 기억할 것은 하나입니다.

방문자가 입력한 내용을 나중에도 다시 보고 싶다면 Supabase 같은 데이터 저장 공간이 필요하다.

이 한 문장만 이해해도 충분합니다.

언제 Supabase가 필요할까?

처음부터 모든 웹사이트에 Supabase가 필요한 것은 아닙니다. 단순히 나를 소개하는 포트폴리오, 서비스 설명 랜딩 페이지, 전자책 판매 전 관심 유도 페이지라면 데이터베이스 없이도 시작할 수 있습니다. 버튼을 카카오톡 오픈채팅, 이메일, 구글폼, 타입폼, 네이버 폼으로 연결하는 것만으로도 충분한 경우가 많습니다.

하지만 사용자의 입력값을 내 웹사이트 안에서 직접 저장하고 싶다면 이야기가 달라집니다.

예를 들어 예약·상담 신청 페이지를 만들었다고 해봅시다. 방문자가 이름, 연락처, 희망 날짜, 상담 내용을 입력합니다. 이 정보를 단순히 화면에 보여주고 끝낼 것이 아니라, 관리자 화면에서 모아보고 싶다면 데이터베이스가 필요합니다. 견적 요청 페이지도 마찬가지입니다. 고객이 예산, 프로젝트 유형, 마감일을 입력했는데 그 내용이 어딘가에 저장되지 않는다면 실제 영업에 활용하기 어렵습니다.

개인 사업자나 프리랜서에게 자주 필요한 데이터 저장 사례는 꽤 현실적입니다.

• 설문 응답 저장: 강의 수요 조사, 전자책 주제 투표, 고객 만족도 조사

• 예약 신청 저장: 상담 예약, 클래스 신청, 촬영 예약, 코칭 세션 신청

• 문의 내역 저장: 이름, 이메일, 문의 내용, 답변 상태 관리

• 고객 목록 저장: 리드 고객, 기존 고객, 재구매 가능 고객 분류

• 견적 요청 저장: 예산, 일정, 필요한 서비스, 진행 상태 기록

• 디지털 상품 신청 저장: 무료 샘플 신청자, 대기자 명단, 구매 전 관심 고객

여기서 중요한 기준은 "이 정보를 나중에 다시 봐야 하는가?"입니다. 그렇다면 데이터베이스가 필요합니다. "이 정보가 특정 사용자에게만 보여야 하는가?"까지 들어가면 인증과 권한도 필요합니다.

엑셀 표처럼 이해하는 데이터베이스

데이터베이스를 이해할 때 가장 쉬운 방법은 표를 떠올리는 것입니다. Supabase 안에는 여러 개의 표가 있고, 각각의 표를 보통 테이블이라고 부릅니다. 엑셀에서 시트 하나가 테이블 하나라고 생각하면 됩니다.

예를 들어 문의 페이지를 만든다면 inquiries라는 테이블을 만들 수 있습니다. 이 테이블에는 다음과 같은 칸이 들어갑니다.

예약 신청이라면 테이블 이름을 booking_requests로 만들 수 있습니다. 견적 요청이라면 quote_requests, 전자책 대기자 명단이라면 waitlist_signups처럼 이름을 붙일 수 있습니다. 영어 이름이 어색해도 괜찮습니다. Lovable에게 "예약 신청 데이터를 저장하는 테이블을 만들어줘"라고 설명하면, 보통 적절한 테이블 이름과 컬럼을 제안해줍니다.

다만 초보자에게 꼭 권하고 싶은 습관이 있습니다. Lovable 안에서 즉흥적으로 테이블을 만들기 전에, 외부 AI에서 먼저 "어떤 정보를 저장할지" 정리하세요. 그래야 크레딧을 아낄 수 있습니다.

Lovable에 맡기기 전에 외부 AI로 데이터 구조를 먼저 정리하기

Supabase 연동은 강력하지만, 무계획으로 시작하면 크레딧이 빠르게 사라질 수 있습니다. "예약 기능 만들어줘"라고만 입력하면 Lovable은 로그인, 캘린더, 관리자 화면, 알림, 데이터베이스까지 한 번에 복잡하게 만들려고 할 수 있습니다. 그러면 수정할 것도 많아지고 오류가 날 가능성도 커집니다.

그래서 먼저 ChatGPT나 Gemini 같은 외부 AI에게 데이터 구조를 정리하게 하는 편이 좋습니다. 이 작업은 Lovable 크레딧을 쓰지 않고 할 수 있습니다.

예를 들어 이렇게 요청할 수 있습니다.

나는 프리랜서 상담 예약 페이지를 만들고 있어.
사용자는 이름, 이메일, 전화번호, 희망 날짜, 상담 주제, 메시지를 입력해.
관리자는 신청 목록을 보고 상태를 new, contacted, done으로 바꾸고 싶어.
초보자가 Supabase에 저장하기 좋은 테이블 구조를 제안해줘.
개인정보는 최소한으로 저장하고, 처음에는 로그인 없이 신청 폼만 만들 예정이야.

이렇게 물어보면 외부 AI는 대략 어떤 테이블이 필요한지, 어떤 컬럼이 필요한지, 상태값은 어떻게 둘지 정리해줍니다. 그 결과를 다시 다듬어 Lovable에 넣으면 됩니다.

Lovable에 넣기 전 최종 지시서는 이렇게 짧고 구체적이면 좋습니다.

Supabase에 booking_requests 테이블을 연결해 상담 신청 데이터를 저장해주세요.
저장할 필드는 name, email, phone, preferred_date, topic, message, status, created_at입니다.
사용자는 공개 페이지에서 신청서를 제출할 수 있고, 제출 후 "신청이 접수되었습니다" 메시지를 봅니다.
지금은 로그인 기능을 만들지 말고, 관리자 화면도 만들지 마세요.
먼저 데이터 저장이 정상 작동하는 MVP만 구현해주세요.

마지막 문장이 중요합니다. "지금은 로그인 기능을 만들지 말고, 관리자 화면도 만들지 마세요." 이처럼 제외할 기능을 분명히 말해야 Lovable이 일을 과하게 벌이지 않습니다. 무료 사용자에게는 이 절제가 곧 크레딧 절약입니다.

Lovable에서 Supabase를 연결하는 큰 흐름

Lovable은 Supabase 연동을 비교적 쉽게 할 수 있도록 연결 버튼과 통합 흐름을 제공합니다. 공식 문서에 따르면 Lovable 안에서 프론트엔드 UI와 Supabase 기반 백엔드 데이터베이스를 하나의 채팅 인터페이스로 다룰 수 있습니다.²

실제 화면 구성은 업데이트에 따라 조금씩 바뀔 수 있지만, 큰 흐름은 보통 다음과 같습니다.

• Supabase 계정을 만들거나 기존 계정에 로그인합니다.

• Lovable 프로젝트에서 Supabase 또는 Cloud 관련 버튼을 찾습니다.

• 새 Supabase 프로젝트를 만들거나 기존 프로젝트를 선택해 연결합니다.

• Lovable에게 저장할 데이터 구조를 설명합니다.

• Lovable이 제안하는 SQL 또는 마이그레이션 내용을 확인하고 적용합니다.

• 폼 제출, 데이터 저장, 목록 조회가 정상 작동하는지 테스트합니다.

여기서 SQL이라는 말이 나옵니다. SQL은 데이터베이스에게 "이런 표를 만들고, 이런 데이터를 저장하고, 이런 조건으로 찾아줘"라고 말하는 언어입니다. 초보자가 직접 SQL을 외울 필요는 없습니다. 다만 Lovable이 "이 SQL을 적용할까요?"라고 물을 때, 완전히 모른 채로 누르기보다는 어떤 테이블과 컬럼이 생기는지 정도는 확인해야 합니다.

예를 들어 booking_requests 테이블을 만든다고 했는데 갑자기 payments, subscriptions, admin_users 같은 테이블까지 만들어진다면 범위가 커진 것입니다. 그럴 때는 멈추고 이렇게 물어보세요.

방금 제안한 데이터베이스 변경 사항을 초보자도 이해할 수 있게 설명해주세요.
이번 MVP에 꼭 필요한 테이블과 나중에 추가해도 되는 테이블을 구분해주세요.
아직 적용하지 말고 설명만 해주세요.

이런 질문은 실제 구현 전에 복잡도를 줄이는 데 큰 도움이 됩니다.

Lovable Cloud와 내 Supabase 프로젝트의 차이

여기서 한 가지 헷갈리는 지점이 있습니다. Lovable 프로젝트의 백엔드는 Lovable Cloud로 관리될 수도 있고, 내가 직접 만든 Supabase 프로젝트에 연결될 수도 있습니다. Supabase 문서에서는 Lovable Cloud를 사용하는 경우 기본 Supabase 인스턴스가 Lovable 쪽에서 관리되므로 내 Supabase 대시보드에 보이지 않을 수 있다고 설명합니다.³

초보자에게 이 차이는 꽤 중요합니다. Lovable Cloud 방식은 간편할 수 있지만, 내가 Supabase 대시보드에서 직접 프로젝트를 관리하고 싶다면 처음부터 내 Supabase 프로젝트를 만들어 연결하는 편이 이해하기 쉽습니다. 특히 나중에 데이터 구조를 직접 확인하거나, 보안 규칙을 점검하거나, 서비스가 커져 개발자에게 넘길 계획이 있다면 "내가 관리하는 Supabase 프로젝트"인지 확인해두는 것이 좋습니다.

Lovable 상단의 Cloud 또는 Supabase 관련 설정 화면에서 현재 백엔드가 어떤 방식으로 연결되어 있는지 확인할 수 있습니다. 만약 Supabase 대시보드에서 프로젝트가 보이지 않는다면, Lovable Cloud로 만들어진 백엔드일 가능성이 있습니다. 이 경우 당황하지 말고 먼저 현재 연결 방식을 확인하세요.

처음부터 로그인까지 넣으면 왜 어려워질까?

초보자가 Supabase를 처음 만났을 때 가장 자주 하는 실수가 있습니다. 바로 첫날부터 로그인, 회원가입, 관리자 권한, 사용자별 데이터, 파일 업로드, 이메일 알림을 한꺼번에 넣으려는 것입니다.

물론 Supabase는 인증 기능을 제공합니다. 이메일과 비밀번호 로그인, 소셜 로그인 같은 기능도 만들 수 있습니다.⁴ Lovable에 "로그인 페이지를 만들어줘"라고 요청하면 기본적인 인증 흐름을 생성할 수도 있습니다. 문제는 로그인 기능이 들어가는 순간 생각해야 할 것이 확 늘어난다는 점입니다.

로그인이 들어가면 웹사이트는 더 이상 "누가 제출했는지 몰라도 되는 폼"이 아닙니다. 이제 사용자를 구분해야 합니다. A 고객이 입력한 데이터가 B 고객에게 보이면 안 됩니다. 로그인하지 않은 사용자는 어떤 페이지에 접근할 수 있는지, 로그인한 사용자는 어떤 데이터를 볼 수 있는지, 관리자는 무엇을 수정할 수 있는지 정해야 합니다.

즉, 로그인은 단순히 이메일과 비밀번호 입력창을 추가하는 일이 아닙니다. 문 하나를 만드는 것이 아니라, 건물 전체의 출입 규칙을 정하는 일입니다.

그래서 이 책의 독자처럼 무료 크레딧을 아껴야 하는 초보자라면 다음 순서가 더 안전합니다.

처음에는 "로그인 없는 신청 폼"으로 충분합니다. 실제로 문의나 예약 신청은 방문자가 굳이 회원가입하지 않아도 제출할 수 있어야 전환율이 높습니다. 로그인은 고객용 대시보드, 구매자 전용 자료실, 회원별 기록 관리처럼 정말 필요한 순간에 넣어도 늦지 않습니다.

초보자용 Supabase 도입 3단계

Supabase를 처음 도입할 때는 세 단계로 나누면 좋습니다. 한 번에 앱 전체를 데이터베이스 중심으로 바꾸지 말고, 작은 폼 하나부터 연결하세요.

1단계: 공개 폼 데이터를 저장한다

가장 쉬운 시작은 문의 폼, 예약 폼, 견적 요청 폼입니다. 사용자는 로그인하지 않고 정보를 입력합니다. 제출하면 Supabase 테이블에 한 줄이 추가됩니다.

이때 Lovable 프롬프트는 이렇게 작성할 수 있습니다.

현재 문의 폼을 Supabase와 연결해주세요.
inquiries 테이블에 name, email, message, status, created_at을 저장합니다.
status의 기본값은 new로 설정해주세요.
제출 성공 시 감사 메시지를 보여주고, 실패 시 다시 시도하라는 안내를 보여주세요.
지금은 로그인, 관리자 페이지, 이메일 발송은 추가하지 마세요.

이 단계의 목표는 단순합니다. "제출했더니 Supabase에 저장된다." 여기까지만 성공해도 큰 진전입니다.

2단계: 관리자 목록 화면을 만든다

데이터가 저장되기 시작하면 다음으로 필요한 것은 목록 화면입니다. Supabase 대시보드에서 직접 봐도 되지만, 매번 대시보드에 들어가는 것이 번거롭다면 Lovable 앱 안에 간단한 관리자 페이지를 만들 수 있습니다.

다만 이때도 처음부터 완벽한 CRM을 만들려고 하지 마세요. 표 하나면 충분합니다.

/admin/inquiries 페이지를 만들어 Supabase의 inquiries 테이블 데이터를 최신순으로 보여주세요.
표시할 컬럼은 이름, 이메일, 문의 내용 요약, 상태, 접수일입니다.
상태를 new, contacted, closed 중 하나로 변경할 수 있게 해주세요.
지금은 관리자 로그인은 만들지 말고, 개발 테스트용 내부 페이지로만 구성해주세요.
배포 전에는 반드시 접근 제한을 추가할 예정이라고 코드 주석 또는 안내를 남겨주세요.

여기서 "지금은 관리자 로그인은 만들지 말고"라는 지시는 상황에 따라 조심해야 합니다. 이미 실제 고객 개인정보가 저장되는 상태라면 관리자 페이지를 공개 배포하면 안 됩니다. 로컬 테스트나 비공개 미리보기에서만 확인하고, 실제 배포 전에는 반드시 접근 제한을 넣어야 합니다.

3단계: 필요한 경우에만 로그인과 권한을 추가한다

데이터 저장과 관리자 목록이 잘 작동하면 그 다음에 로그인과 권한을 붙입니다. 이때는 Lovable에게 한 번에 "완벽한 회원 시스템"을 만들라고 하지 말고, 관리자 보호부터 시작하는 편이 좋습니다.

Supabase Auth를 사용해 관리자 로그인 기능을 추가해주세요.
/admin/inquiries 페이지는 로그인한 관리자만 접근할 수 있게 보호해주세요.
로그인하지 않은 사용자가 접근하면 /login으로 이동시켜주세요.
일반 사용자의 문의 제출 폼은 계속 로그인 없이 사용할 수 있어야 합니다.
변경 후 테스트해야 할 시나리오를 함께 설명해주세요.

이렇게 하면 공개 신청 폼과 관리자 기능을 분리할 수 있습니다. 초보자는 이 구분을 꼭 기억해야 합니다. 모든 방문자에게 로그인을 강요하는 앱은 만들기 복잡할 뿐 아니라, 실제 전환율도 떨어질 수 있습니다.

사용자별 데이터 분리는 '나중에'가 아니라 '반드시' 점검할 문제다

사용자별 데이터가 들어가는 순간 보안 문제는 훨씬 중요해집니다. 예를 들어 고객이 로그인해서 자신의 상담 내역을 보는 기능을 만들었다고 해봅시다. 이때 A 고객이 B 고객의 상담 내용을 볼 수 있다면 큰 사고입니다. 특히 이름, 이메일, 전화번호, 상담 내용, 예산, 건강 정보, 학습 기록처럼 민감할 수 있는 정보가 들어가면 더욱 조심해야 합니다.

Supabase에서는 이런 문제를 막기 위해 RLS(Row Level Security)라는 보안 기능을 사용합니다. Row Level Security는 말 그대로 "행 단위 보안"입니다. 데이터베이스 표의 각 줄마다 누가 읽고, 쓰고, 수정하고, 삭제할 수 있는지를 정하는 규칙입니다.

쉽게 말해 이런 규칙입니다.

"로그인한 사용자는 자기 user_id가 붙은 데이터만 볼 수 있다."

"일반 사용자는 다른 사람의 신청 내역을 볼 수 없다."

"관리자는 모든 문의를 볼 수 있지만, 일반 사용자는 자기 문의만 볼 수 있다."

Supabase와 Lovable 연동 가이드들에서도 RLS를 중요한 보안 설정으로 다룹니다. 특히 사용자별 데이터가 있는 테이블에서는 RLS를 활성화하고, auth.uid() 같은 사용자 식별값을 기준으로 접근 정책을 만들어야 한다고 설명합니다.⁵

초보자에게는 조금 어려운 말일 수 있습니다. 하지만 겁먹을 필요는 없습니다. 직접 코드를 쓰지 않더라도 Lovable에게 이렇게 요청할 수 있습니다.

Supabase의 RLS 보안 규칙을 점검해주세요.
사용자는 자신의 user_id와 연결된 데이터만 읽고 수정할 수 있어야 합니다.
다른 사용자의 데이터는 절대 조회할 수 없어야 합니다.
관리자 전용 접근이 필요한 테이블과 공개 제출이 가능한 테이블을 구분해서 설명해주세요.
적용 전에 어떤 정책이 만들어지는지 한국어로 먼저 설명해주세요.

핵심은 "적용 전에 설명해달라"는 것입니다. 보안 규칙은 모르고 적용하는 것보다, 조금 느리더라도 이해하고 적용하는 편이 안전합니다.

개인정보는 적게 받을수록 안전하다

개인 사업자나 프리랜서가 만든 작은 웹사이트라고 해서 개인정보 문제가 가벼워지는 것은 아닙니다. 문의 폼에 이름과 이메일만 받아도 개인정보입니다. 전화번호, 회사명, 예산, 상담 내용, 건강 상태, 학습 수준, 결제 관련 정보가 들어가면 더 조심해야 합니다.

초보자일수록 처음에는 데이터를 많이 받고 싶어합니다. "나중에 필요할 수도 있으니까"라는 이유로 생년월일, 주소, 직책, 전화번호, SNS 계정까지 모두 요구하고 싶어집니다. 하지만 실제로는 반대가 더 좋습니다.

필요 없는 정보는 받지 않는 것이 가장 안전합니다. 저장하지 않은 정보는 유출될 수도 없습니다.

예를 들어 전자책 대기자 명단이라면 이메일 하나면 충분할 수 있습니다. 상담 신청이라면 이름, 이메일, 희망 상담 주제 정도로 시작할 수 있습니다. 전화번호는 정말 전화 상담이 필요한 경우에만 받으세요. 주민등록번호, 상세 주소, 민감한 건강 정보 같은 것은 초보 단계의 웹앱에서 함부로 받지 않는 편이 좋습니다.

Lovable에 폼을 만들라고 할 때도 이렇게 말할 수 있습니다.

개인정보를 최소한으로 받는 신청 폼으로 만들어주세요.
필수 입력은 이름과 이메일, 문의 내용만 사용합니다.
전화번호는 선택 입력으로 두고, 주민등록번호나 주소 같은 민감한 정보는 받지 않습니다.
폼 하단에 "입력한 정보는 문의 응대 목적으로만 사용됩니다"라는 짧은 안내 문구를 넣어주세요.

작은 문구 하나가 모든 법적 책임을 해결해주지는 않습니다. 하지만 초보 단계에서 개인정보를 가볍게 여기지 않는 습관을 만드는 것은 매우 중요합니다.

실전 예시: 지난 장들의 폼을 Supabase로 바꾸기

이제 앞에서 만든 페이지들을 떠올려봅시다. 프리랜서 포트폴리오의 문의 폼, 예약·상담 신청 페이지, 견적 요청 페이지, 디지털 상품 랜딩 페이지의 대기자 신청 폼은 모두 Supabase와 잘 어울립니다.

프리랜서 포트폴리오 문의 폼이라면 목표는 단순합니다. 방문자가 문의를 남기면 inquiries 테이블에 저장되고, 나는 나중에 목록을 확인합니다.

프리랜서 포트폴리오의 문의 폼을 Supabase와 연결해주세요.
inquiries 테이블에 name, email, service_type, budget_range, message, status, created_at을 저장합니다.
제출 성공 후에는 "문의가 접수되었습니다. 1~2영업일 내 답변드릴게요." 메시지를 보여주세요.
실패하면 입력값을 유지한 채 오류 메시지를 보여주세요.
로그인 기능은 아직 추가하지 마세요.

예약·상담 신청 페이지라면 날짜와 상태 관리가 중요합니다.

상담 신청 폼을 Supabase의 consultation_requests 테이블과 연결해주세요.
필드는 name, email, phone, preferred_date, preferred_time, consultation_topic, message, status, created_at입니다.
status 기본값은 new입니다.
같은 시간대 중복 예약을 완전히 막는 복잡한 기능은 아직 만들지 말고, 신청 데이터 저장까지만 구현해주세요.

견적 요청 페이지라면 리드 관리 관점이 들어갑니다.

견적 요청 폼을 Supabase에 저장해주세요.
quote_requests 테이블을 사용하고, name, email, company, project_type, budget_range, deadline, description, status, created_at을 저장합니다.
관리자 목록에서 status를 new, reviewing, sent, closed로 바꿀 수 있도록 나중에 확장 가능한 구조로 만들어주세요.
이번 단계에서는 폼 제출과 저장 성공 확인까지만 구현합니다.

전자책·강의·디지털 상품 랜딩 페이지라면 대기자 명단이 좋습니다.

랜딩 페이지의 사전 신청 폼을 Supabase와 연결해주세요.
waitlist_signups 테이블에 email, name, interest_topic, source, created_at을 저장합니다.
이메일 중복 제출은 막아주세요.
제출 후 "출시 소식을 가장 먼저 보내드릴게요" 메시지를 보여주세요.
결제 기능은 아직 추가하지 마세요.

이 프롬프트들의 공통점은 "이번 단계에서 할 일"과 "아직 하지 않을 일"이 분명하다는 것입니다. Lovable은 똑똑하지만, 사용자가 범위를 정해주지 않으면 자꾸 더 많은 것을 만들려고 할 수 있습니다. 초보자는 그 친절함 때문에 오히려 길을 잃습니다.

데이터 저장 기능을 만든 뒤 반드시 테스트할 것

Supabase 연결이 끝났다고 바로 배포하지 마세요. 데이터 기능은 눈으로 보이는 디자인보다 더 꼼꼼하게 테스트해야 합니다. 버튼 색상이 조금 이상한 것은 나중에 고쳐도 되지만, 고객 문의가 저장되지 않는 문제는 곧바로 사업 기회를 잃게 만듭니다.

최소한 다음 흐름은 직접 테스트해보세요.

• 정상 입력: 모든 필수 정보를 입력했을 때 Supabase에 데이터가 저장되는지 확인합니다.

• 빈 입력: 이름이나 이메일을 비웠을 때 적절한 안내가 나오는지 확인합니다.

• 잘못된 이메일: 이메일 형식이 틀렸을 때 제출이 막히는지 확인합니다.

• 제출 성공 메시지: 사용자가 "내 신청이 접수됐다"고 확신할 수 있는지 확인합니다.

• 저장 실패 처리: 네트워크 오류나 저장 실패 시 사용자에게 무슨 일이 일어났는지 알려주는지 확인합니다.

• 중복 제출: 버튼을 여러 번 눌렀을 때 같은 데이터가 여러 번 저장되지 않는지 확인합니다.

• 관리자 확인: Supabase 대시보드나 관리자 목록에서 실제 데이터가 보이는지 확인합니다.

이런 테스트를 하다 보면 오류가 생길 수 있습니다. 오류는 실패가 아닙니다. 데이터 기능은 원래 한 번에 완벽하게 맞추기 어렵습니다. 중요한 것은 오류 메시지를 숨기지 말고, Lovable에게 구체적으로 설명하는 것입니다.

문의 폼을 제출하면 화면에는 성공 메시지가 뜨지만 Supabase inquiries 테이블에는 데이터가 저장되지 않습니다.
원인을 단계별로 점검해주세요.
아직 코드를 수정하지 말고, 가능한 원인과 확인 방법을 먼저 설명해주세요.

이렇게 요청하면 불필요한 수정으로 크레딧을 낭비하는 일을 줄일 수 있습니다. 바로 "고쳐줘"보다 "먼저 설명해줘"가 안전합니다.

Supabase를 붙인다고 곧바로 거대한 앱이 되는 것은 아니다

Supabase를 연결하면 갑자기 멋진 앱을 만들 수 있을 것 같은 기분이 듭니다. 실제로 가능성은 커집니다. 문의를 저장하고, 예약을 관리하고, 로그인한 사용자에게 자기 기록을 보여줄 수 있습니다. 파일 업로드도 붙일 수 있고, 나중에는 이메일 알림이나 결제와도 연결할 수 있습니다.

하지만 초보자에게 가장 중요한 전략은 여전히 같습니다.

작게 만들고, 작게 저장하고, 작게 관리하세요.

처음부터 고객 관리 시스템 전체를 만들 필요는 없습니다. 문의 폼 하나를 Supabase에 저장하는 것만으로도 이미 웹사이트는 한 단계 성장한 것입니다. 예약 신청을 표로 모아볼 수 있다면 그것만으로도 실제 업무에 도움이 됩니다. 디지털 상품 대기자 이메일을 모을 수 있다면 상품 출시 전 수요를 검증할 수 있습니다.

데이터베이스는 거창한 스타트업만 쓰는 도구가 아닙니다. 프리랜서의 문의함, 강사의 수강 신청 명단, 1인 사업자의 고객 리스트, 토이 프로젝트의 피드백 저장소가 모두 데이터베이스의 출발점입니다.

이번 장에서 기억할 것

Supabase는 Lovable로 만든 웹페이지에 "기억하는 능력"을 붙여주는 도구입니다. 단순히 보여주는 페이지에서 끝나지 않고, 방문자의 입력을 저장하고, 관리자 화면에서 확인하고, 로그인한 사용자별로 데이터를 나누는 기능을 만들 수 있게 해줍니다.

하지만 강력한 도구일수록 순서가 중요합니다. 초보자는 처음부터 로그인과 권한, 관리자 화면, 실시간 기능을 한꺼번에 넣지 말아야 합니다. 먼저 공개 폼 데이터를 저장하고, 그다음 관리자 목록을 만들고, 마지막에 필요한 경우 로그인과 RLS 보안 규칙을 붙이는 편이 안전합니다.

특히 개인정보와 사용자별 데이터는 가볍게 다루면 안 됩니다. 이름과 이메일만 저장해도 개인정보입니다. 사용자별 데이터가 있다면 RLS를 반드시 점검해야 합니다. Lovable이 많은 것을 자동으로 도와주더라도, "누가 어떤 데이터를 볼 수 있는가"는 만든 사람이 끝까지 확인해야 합니다.

다음 장에서는 이렇게 기능을 붙이다가 오류가 났을 때 어떻게 당황하지 않고 디버깅할 수 있는지 다룹니다. Supabase 연결, 폼 제출 실패, 로그인 문제, 화면 깨짐은 초보자에게 흔한 일입니다. 중요한 것은 오류를 없애는 재능이 아니라, 오류를 차분히 설명하고 하나씩 좁혀가는 습관입니다.

참고

¹Lovable Supabase Integration Overview

²Connect to Supabase - Lovable Documentation

³Identifying Lovable backend: Lovable Cloud or Supabase

⁴How to set-up Supabase Authentication?

⁵Mastering Lovable + Supabase Integration