Supabase는 무엇이고, 왜 쓰는가

들어가며

사이드 프로젝트를 시작할 때마다 같은 작업을 반복한다. EC2 띄우고, RDS 붙이고, S3 권한 정리하고, JWT 라이브러리 골라서 로그인 만들고, 비밀번호 해시 정책 세우고, 이메일 인증 메일 SMTP 연결하고, 파일 업로드 presigned URL 코드 짜고… 정작 만들고 싶었던 기능 은 시작도 못 했는데 인프라 부트스트랩에 며칠이 녹는다.

Supabase 는 그 부트스트랩을 통째로 들어내고 시작하자는 도구다. "Postgres 를 코어로 쓰는 오픈소스 Firebase 대안" — 공식 한 줄 소개가 정확하다.

BaaS, 한 번 정리하고 가자

BaaS 는 Backend-as-a-Service 의 약자. 전형적인 백엔드가 떠안던 일들 — 데이터베이스, 인증, 파일 저장, 실시간 푸시, 서버리스 함수 — 을 SaaS 한 벌로 묶어 SDK·REST·관리 콘솔로 제공한다.

직접 백엔드를 만들 때 vs BaaS 를 쓸 때, 무엇이 달라지는가:

• 직접 운영: 서버 인스턴스·DB·스토리지·인증 미들웨어를 내가 결정하고 내가 책임진다. 자유도 최고, 시간 비용 최고.
• BaaS: DB 스키마와 정책만 정의하면 REST·SDK·Auth UI 가 자동으로 따라온다. 자유도는 그 위에서 그 SDK 가 허용하는 범위.

Supabase 한눈에 보기

Supabase 는 한 덩어리 서비스가 아니다. 오픈소스 부품을 모아 통합 콘솔과 API 로 묶은 plumbing 의 패키지 에 가깝다.

핵심 구성 요소 다섯 가지:

1. Postgres — 진짜 PostgreSQL 한 인스턴스. extension·트리거·view 까지 풀로 사용 가능.
2. Auth — GoTrue 기반 인증 서버. 이메일·매직 링크·OAuth·OTP·MFA.
3. Storage — S3 호환 객체 스토리지. RLS 와 동일한 정책 모델로 권한 제어.
4. Realtime — Postgres wal2json 을 흘려서 변경사항을 WebSocket 으로 브로드캐스트.
5. Edge Functions — Deno 런타임 위의 서버리스 함수.

여기에 자동 REST API (PostgREST) 와 GraphQL API (pg_graphql) 가 스키마에서 자동 생성된다 — 테이블만 만들면 그날부터 GET/POST/PATCH/DELETE 엔드포인트가 살아 있다.

Firebase 와의 차이

Supabase 가 자신을 "Firebase 대안" 이라 부르니 비교는 피할 수 없다. 가장 큰 차이는 데이터 모델 이다.

• Firebase Firestore: 문서/컬렉션 기반의 NoSQL. 스키마 자유도는 높지만 join·트랜잭션·복잡한 집계는 약함.
• Supabase Postgres: 관계형. 외래키·트랜잭션·복잡한 join·CTE·window function 다 됨. 대신 스키마를 미리 설계해야 한다.

권한 모델도 다르다.

• Firebase Security Rules: 프로젝트 루트에 별도 DSL 파일을 둬서, 경로별 read/write 규칙을 선언.
• Supabase RLS (Row Level Security): Postgres 의 표준 기능. 테이블마다 SQL 정책을 붙여 행 단위로 가시성·수정 권한을 결정.

어떨 때 Supabase 를 고르면 좋은가

선택은 항상 trade-off 다. 잘 맞는 경우와 그렇지 않은 경우를 분리해서 보자.

잘 맞는 경우

• 사이드 프로젝트·MVP — 인프라에 들이는 시간을 0 에 가깝게 줄여야 할 때.
• SQL 에 익숙한 팀 — 관계형 모델·인덱스·뷰·함수를 쓰던 사고방식 그대로 가져갈 수 있다.
• 인증·실시간이 필요한 앱 — 채팅·라이브 대시보드·협업 도구처럼 WebSocket 이 핵심인 도메인.
• 빠른 프로토타입 후 self-host 로 옮기고 싶을 때 — 같은 스택을 그대로 가져갈 수 있다.

잘 안 맞는 경우

• 백엔드 비즈니스 로직이 매우 복잡 한 서비스 — 결제·정산·복잡한 워크플로우는 Edge Functions 만으로 부족할 수 있다.
• 멀티 리전 read/write 가 필수인 글로벌 서비스 — 매니지드 Supabase 는 단일 리전 Postgres 가 기본.
• 이미 운영 중인 자체 백엔드와 통합해야 하는 경우 — 권한 모델이 두 벌 되면 오히려 복잡해진다.

5분 만에 시작해보기

추상적인 설명보다 직접 한 번 눌러 보는 게 빠르다. 신용카드 없이 무료 plan 으로 한 프로젝트 생성 가능.

1. 프로젝트 만들기

supabase.com 에 가입하고 New Project 를 누르면 된다.

• Name: 프로젝트 식별자 (대시보드용).
• Database password: 한 번만 보여주니 비밀번호 매니저에 저장.
• Region: 사용자 위치와 가까운 곳. 한국 서비스라면 ap-northeast-2 (Seoul) 또는 ap-northeast-1 (Tokyo).

대시보드 UI 는 자주 바뀌므로 캡처를 박아두기보단 직접 들어가서 흐름을 따라가는 편이 정확하다 — supabase.com/dashboard 에서 New Project 버튼이 첫 화면에 있다.

프로젝트가 프로비저닝되는 데 1~2분. 끝나면 대시보드로 들어가 Settings → API 에서 두 가지를 메모해 두자.

• Project URL — REST/Realtime 진입점.
• anon public key — 클라이언트에서 쓰는 익명 키.

2. 첫 테이블 만들기

좌측 메뉴 Table Editor 에서 GUI 로 만들거나, SQL Editor 에서 SQL 로 직접 만들 수 있다. 이 글에선 SQL 쪽이 더 빠르다.

1create table posts (
2  id          bigserial primary key,
3  title       text not null,
4  content     text,
5  published   boolean not null default false,
6  created_at  timestamptz not null default now()
7);

이 한 줄로 끝이다. 테이블이 만들어지는 즉시:

• Table Editor 에 행 단위 편집 UI 가 생김.
• PostgREST 가 /rest/v1/posts 엔드포인트를 자동 노출.
• pg_graphql 이 posts 쿼리/뮤테이션을 GraphQL 스키마에 추가.

3. JS SDK 로 한 번 호출해 보기

1import { createClient } from '@supabase/supabase-js';
2
3const supabase = createClient(
4  process.env.SUPABASE_URL!,
5  process.env.SUPABASE_ANON_KEY!,
6);
7
8const { data, error } = await supabase
9  .from('posts')
10  .insert({ title: 'Hello, Supabase', published: true })
11  .select()
12  .single();
13
14console.log(data, error);

서버 한 대 띄우지 않고도 INSERT 가 동작한다 — 단, 지금 이 상태로는 누구나 쓰고 누구나 읽는다. 그래서 다음 단계가 RLS 다.

정리

Supabase 는 "백엔드를 안 만든다" 가 아니라 "공통 백엔드를 위탁하고, 데이터 모델과 정책 설계에 집중한다" 는 도구다. Postgres 에 익숙하다면 진입 장벽이 낮고, 이탈 비용도 낮다 — 같은 스택을 self-host 로 그대로 옮길 수 있기 때문.

이 시리즈에서 다룰 순서:

1. (이번 편) Supabase 가 무엇이고 왜 쓰는가
2. Database · RLS — 스키마 설계와 행 단위 권한
3. Auth — 이메일·OAuth·매직 링크 실전
4. Storage · Realtime — 파일 업로드와 WebSocket 구독
5. Supabase vs Convex — 어떤 BaaS 를 고를까