화면을 만들어 올렸는데 "새로고침했더니 입력한 게 다 사라졌어요"라는 말을 들었다면, Supabase가 필요한 상황입니다. 이 자료는 Supabase를 코딩을 몰라도 이해할 수 있게 앞의 두 편과 같은 식당 하나에 빗대어 설명합니다. 내 PC는 부엌, GitHub는 레시피 금고, Vercel은 매장, Supabase는 손님이 남긴 주문과 기록을 쌓아 두는 창고와 장부입니다.
위 영상(약 2분)으로 흐름을 먼저 보시고, 자세한 내용은 아래 첨부한 PDF(21쪽, 읽는 데 10분)를 보시면 됩니다. 개발 도구 3종 시리즈의 마지막 편이고, 앞의 편은 GitHub(레시피 금고)와 Vercel(매장)입니다. 앞의 두 편을 안 보셨어도 이 자료만으로 이해할 수 있습니다.
이 자료로 알게 되는 것
- Supabase가 왜 필요한지 — 입력한 내용이 사라지고, 사람마다 다른 내용을 보고, 결국 엑셀 파일을 돌리게 되는 문제를 어떻게 푸는지
- 용어 여섯 개의 뜻 — 데이터베이스, 테이블, 로그인(Auth), 파일 보관(Storage), API 키, 접근 규칙(RLS)
- 꼭 지킬 것과 처음 한 번 창고를 만들어 보는 순서
왜 입력한 게 사라질까
매장(Vercel)은 화면을 내놓는 진열대일 뿐이라 기록을 오래 쌓아 두지 못합니다. 저장할 곳이 없으면 입력한 내용은 그 사람 브라우저에서 잠깐 보이다가 사라지고, 내가 넣은 신청을 팀장님은 볼 수 없습니다. 여러 사람의 기록을 한곳에 모아 누가 열어도 같은 최신본을 보게 해 주는 저장소가 데이터베이스이고, Supabase가 이 창고를 빌려줍니다. 서버를 직접 설치할 필요 없이 웹사이트에서 창고를 만들고, 엑셀처럼 생긴 화면으로 장부를 볼 수 있습니다.
Supabase 용어를 창고 말로 바꾸면
| Supabase 용어 | 창고 말로 하면 |
|---|---|
| 프로젝트 (project) | 창고 한 채 — 매장(Vercel) 하나와 짝 |
| 데이터베이스 (database) | 창고 안의 장부 보관실 — 모든 기록이 모이는 곳 |
| 테이블 (table) | 장부 한 권 — "비품 신청 장부", "회원 명부"처럼 주제별로 |
| 행 · 열 (row · column) | 장부의 한 줄 · 칸 이름 — 한 줄이 신청 한 건 |
| 로그인 (Auth) | 출입증 발급 창구 — 누가 들어왔는지 확인 |
| 파일 보관 (Storage) | 물품 선반 — 사진·PDF 같은 파일을 따로 보관 |
| API 키 (API keys) | 창구 열쇠와 관리자 마스터키 |
| 접근 규칙 (RLS) | 창고지기의 규칙 — "자기 신청서만 볼 수 있다" |
핵심은 한 줄입니다. 레시피(코드)와 기록(데이터)은 다른 곳에 삽니다. 코드를 고쳐 GitHub에 올려도 창고 장부는 그대로이고, 반대로 장부에 쌓인 기록은 GitHub에 올라가지 않습니다. 처음에는 장부(데이터베이스)만 써도 충분하고, 로그인과 파일 보관은 필요해질 때 같은 창고에서 꺼내 쓰면 됩니다.
AI 코딩 도구에게 이렇게 말하면 됩니다
| 이렇게 말하면 | 하는 일 |
|---|---|
| 비품 신청을 저장하는 테이블 만들어줘 | 장부 만들기 — 칸 이름·형식은 AI가 정함 |
| 신청 버튼 누르면 Supabase에 저장되게 해줘 | 기록하기 — 새로고침해도 남음 |
| 신청 목록을 최신순으로 보여줘 | 꺼내 보기 — 모두가 같은 최신본 |
| 이 테이블 RLS 켜고 내 것만 보이게 해줘 | 창고지기 규칙 — 남의 기록 보호 |
| 마스터키가 화면 코드에 있는지 확인해줘 | 열쇠 점검 — secret 키 노출 방지 |
| 엑셀 파일 내용을 이 테이블로 옮기고 싶어 | 이사하기 — CSV로 가져오기 |
창고는 supabase.com에서 처음 한 번 만들고(PDF 16쪽, 약 15분), 그다음 연결은 AI 도구에게 맡기면 됩니다. 여러분은 "무엇을 기록할지"만 정하시면 됩니다.
꼭 지킬 것 세 가지
- 열쇠는 두 개이고, 마스터키는 절대 밖에 두지 않습니다. 창구 열쇠(publishable,
sb_publishable_로 시작)는 화면 코드에 들어가도 되지만, 관리자 마스터키(secret,sb_secret_로 시작)는 모든 규칙을 무시하고 장부 전체를 열 수 있어 화면 코드·GitHub·메신저에 절대 넣지 않습니다. 새어 나갔다면 바로 그 키를 폐기하고 새로 발급하세요. - 장부마다 창고지기 규칙(RLS)을 켭니다. 창구 열쇠는 누구나 볼 수 있어서, 규칙이 없으면 다른 사람의 신청 내역이 다 보이고 장부를 통째로 지울 수도 있습니다. "이 테이블에 RLS 켜고, 로그인한 사람이 자기가 쓴 것만 볼 수 있게 정책 만들어줘"라고 말하면 AI 도구가 규칙을 써 줍니다.
- 창고는 회사 밖 서비스입니다. 주민번호·계좌·환자 정보 같은 민감 정보는 넣지 않고, 고객·거래처 개인정보나 영업 기밀은 회사 방침부터 확인하세요. 무료 요금제는 연습·시범용으로 쓰고, 부서에서 계속 운영할 시스템은 회사 계정으로 옮기는 것이 원칙입니다(무료 요금제 조건은 PDF 14쪽).
자주 하는 오해 하나만 짚으면, GitHub에 올렸다고 데이터까지 백업되는 것은 아닙니다. GitHub에는 코드만 올라가니 중요한 장부는 Supabase 화면에서 CSV로 내려받아 따로 보관하세요. 지운 줄도 GitHub처럼 되돌리기 버튼이 없으니, 지우는 기능을 만들 때는 "정말 삭제할까요?" 확인을 꼭 넣으세요.
이것으로 개발 도구 3종이 끝납니다. 부엌에서 만들고, 금고에 맡기고, 매장에 내놓고, 창고에 기록을 쌓습니다. 세 곳 모두 업무용은 회사 메일로 가입해 퇴사·이동 후에도 시스템이 회사에 남게 해 주세요. 궁금한 점은 Teams로 편하게 물어봐 주세요.