Engineering

Firebase를 버리고 Supabase로 갈아탄 이유

Mike발행일 2026년 1월 10일읽는 시간 약 3

안녕 Firebase, 반가워 Supabase

처음 개발 배울 때 다들 Firebase로 시작하잖아요? 저도 그랬습니다. JSON 덩어리 막 던지면 저장되고, 실시간으로 동기화되고... 마법 같았죠. 근데 서비스가 커지니까 그 마법이 저주가 되더군요.

이 글은 Firebase에서 Supabase로 이사한 실제 경험을 바탕으로, 언제 어떤 도구를 선택해야 하는지 판단 기준을 제공합니다.

내가 Firebase를 떠난 이유

1. 쿼리가 너무 빈약함

"A조건 만족하면서 B조건 만족하는 데이터 줘" -> 이게 안 됩니다. NoSQL 특성상 데이터를 미리 비정규화(Denormalization) 해야 하는데, 나중엔 데이터 중복 관리가 안 돼서 대환장 파티가 열립니다.

예를 들어 "최근 한 달 동안 주문 금액이 10만원 이상이고 서울 지역인 고객 목록"을 뽑으려면? Firebase에서는 이 데이터를 위한 별도 컬렉션을 미리 만들어 놔야 합니다. 요구사항이 바뀔 때마다 데이터 구조를 재설계해야 하는 악몽이 반복됩니다.

2. 벤더 락인(Vendor Lock-in)

Firebase 쓰다가 AWS로 옮긴다? 거의 불가능합니다. 코드를 다 새로 짜야 하니까요. 구글이 "내일부터 가격 2배!"라고 해도 울며 겨자 먹기로 써야 합니다.

파이어스토어 SDK, Firebase Auth, Cloud Functions... 모든 게 구글 생태계에 밀접하게 묶여 있습니다. 하나를 떼어내려면 전체를 다 바꿔야 합니다.

3. 예측 불가능한 비용

읽기/쓰기 횟수 기반이라, 실수로 useEffect 무한 루프 한 번 돌면 다음 달에 차 한 대 값 나옵니다. 실시간 리스너가 활성화된 상태에서 컴포넌트가 리렌더링되면? 읽기 횟수가 기하급수적으로 불어납니다.

우리 팀도 한 번 경험했습니다. 실시간 쿼리를 잘못 설정해서 하루 만에 월 예산의 3배를 태웠습니다. 그날 이후로 비용 알람을 5개나 걸었습니다.

Supabase는 뭐가 다른데?

그냥 PostgreSQL입니다. 이 한마디로 정리됩니다. SQL(관계형 DB)의 강력함은 그대로 가져오면서, Firebase처럼 쓰기 편한 API를 제공합니다.

Join이 된다는 것의 의미

"유저 정보 가져오면서 그 유저가 쓴 글 5개만 가져와" -> SQL 한 줄이면 끝납니다. Firebase에서는 두 번 요청해야 할 것을, Supabase에서는 한 번에 처리합니다.

더 중요한 건 유연성입니다. 기획자가 "이 데이터를 이렇게 보여주고 싶어요"라는 새로운 요구사항을 가져와도, SQL 쿼리 하나만 짜면 됩니다. 데이터 구조를 뜯어고칠 필요가 없어요.

Row Level Security (RLS): 보안의 꽃

Supabase에서 가장 강력한 기능 중 하나가 RLS입니다. "이 행(row)은 이 사용자만 읽을 수 있다"를 데이터베이스 레벨에서 강제합니다.

Firebase의 Security Rules와 비슷하지만, SQL의 표현력을 활용할 수 있어서 훨씬 더 복잡한 접근 제어가 가능합니다. "같은 팀에 속한 사용자만 팀 데이터를 읽을 수 있다" 같은 규칙도 SQL 한 줄로 표현할 수 있습니다.

RLS의 가장 좋은 점은, API를 아무리 잘못 만들어도 데이터가 유출되지 않는다는 겁니다. 보안이 애플리케이션 코드가 아닌 데이터베이스에 내장되어 있으니까요.

Auth: 이것도 기본 내장

Supabase Auth는 이메일/비밀번호, OAuth(Google, GitHub, Apple 등), Magic Link, 전화번호 인증까지 지원합니다. Firebase Auth와 거의 동등한 기능을 제공하면서, 사용자 데이터가 PostgreSQL 테이블에 저장되어 SQL로 조회할 수 있다는 게 장점입니다.

Storage: S3 걱정 끝

파일 업로드/다운로드도 내장되어 있습니다. 버킷(Bucket) 기반이고, RLS와 통합되어 "이 파일은 업로드한 사용자만 접근 가능" 같은 규칙을 걸 수 있습니다. 이미지 리사이즈와 CDN 캐싱도 기본 제공됩니다.

Edge Functions: 서버리스 함수

Deno 런타임 기반의 서버리스 함수입니다. Firebase의 Cloud Functions과 동일한 역할을 합니다. Webhook 처리, 외부 API 연동, 복잡한 비즈니스 로직을 여기서 처리합니다.

오픈소스의 힘

마음에 안 들면 내가 직접 서버 사서 호스팅해도 됩니다(Self-hosting). 탈출구가 있다는 게 얼마나 큰 위안인지 모릅니다. Docker Compose 한 줄이면 로컬에 Supabase 전체 스택을 올릴 수 있습니다.

착한 가격

함께 읽으면 좋은 글

Engineering

Next.js 인증 리다이렉트 루프 방지 플레이북: 로그인 UX와 보안을 동시에 지키는 운영 설계

2026-03-03
Engineering

Next.js 서버 액션 장애 복구 플레이북: 실패를 사용자 이탈로 번지지 않게 막는 실무 설계

2026-03-01

본문 작성/검수 원칙은 편집 원칙에서 확인할 수 있습니다.

← 목록으로 돌아가기