Supabase

The Open Source Firebase Alternative. (오픈소스 파이어베이스 대체제)

— 수파베이스 깃허브 공식 저장소 및 홈페이지 리드미 메인 문구

그냥 이쁜 옷을 입혀 놓은 PostgreSQL. ~~NoSQL 질색하는 프론트엔드 개발자들이 열광해서 입문했다가, 결국 SQL 쿼리와 DB 정규화라는 진짜 현실의 지옥을 마주하고 오열한다.(...)~~

1. 개요

구글이 장악한 모바일/웹 백엔드 서비스(BaaS) 시장의 독점 구도를 깨뜨리기 위해 혜성처럼 등장한 오픈소스 프로젝트. 구글의 파이어베이스가 NoSQL 기반의 Firestore를 밀어붙일 때, 수파베이스는 관계형 데이터베이스의 최고봉인 PostgreSQL을 메인 엔진으로 채택해 SQL 성애자들과 기존 백엔드 생태계의 열렬한 환호를 받았다. 프론트엔드 코드에서 직접 DB에 질의를 던지면서도 안전하게 데이터를 관리할 수 있는 모던 풀스택 개발의 치트키로 군림하고 있다.

2. Firebase Killer의 정체

수파베이스의 아이덴티티는 완벽하게 파이어베이스의 약점을 파고드는 데 있다. 파이어베이스의 독자적인 NoSQL 쿼리 구문에 고통받던 개발자들에게 익숙하고 강력한 SQL의 축복을 다시 내렸으며, 특정 기업 서비스에 종속되는 것을 혐오하는 개발자들을 위해 '우리는 오픈소스라 원하면 니네 온프레미스 서버에 직접 구축해서 쓸 수 있다'는 점을 적극 어필한다. 실시간 데이터 스트리밍(Realtime Auth), 회원 가입 및 로그인 인증(GoTrue), 파일 스토리지 인프라를 전부 패키지로 묶어 마우스 클릭 몇 번에 제공하는 사기적인 편리함을 구축했다. ~~덕분에 백엔드 개발자 없는 사이드 프로젝트 팀들이 싱글벙글 웃으며 프로덕션을 론칭한다.~~(...)¹

3. PostgreSQL 만능주의와 RLS의 늪

수파베이스의 모든 작동 메커니즘은 "어떻게든 PostgreSQL 하나로 끝장을 본다"로 압축된다. 프론트엔드 단에서 직접 DB를 조작할 수 있는 비밀은 바로 PostgreSQL 내부의 강력한 보안 기능인 행 단위 보안(Row Level Security, RLS)에 있다. 사용자가 보낸 JWT 토큰을 해석해 해당 행에 접근 권한이 있는지를 DB 엔진이 직접 감시하는 방식이다. 그러나 이 강력한 기능은 양날의 검인데, 조금만 서비스 규모가 커져서 정교한 백엔드 비즈니스 로직을 태우려고 하면 결국 데이터베이스 콘솔 창을 열고 구닥다리 PL/pgSQL 언어로 가득 찬 트리거(Trigger)와 프로시저를 구구절절 작성해 넣어야 하는 "DB 중심적 감옥"에 갇히게 된다.² 프론트엔드가 편하자고 시작했다가, 오히려 서버 없이 데이터베이스와 온몸으로 맞다이를 까는 기묘한 형국이 펼쳐지는 것이다.

4. 관련 밈 및 드립

4.1. Firebase, 게 섯거라!

수파베이스의 마케팅 부서는 깃허브 트렌딩 목록이나 개발자 트위터(X)에서 파이어베이스의 단점(NoSQL의 한계, 과금 폭탄 이슈)이 언급될 때마다 맹렬하게 난입해 '오픈소스 대안이 여기 있습니다!'라며 츄라이를 시전하는 것으로 악명 높다. 거의 종교 단체급 포교 활동에 가까운데, 실제로 써 보면 나름 맛있어서 당한 놈들이 다시 영업사원이 되어 다른 피해자(?)를 낚아 오는 선순환이 지속되고 있다.

4.2. DB가 시키는 대로 했을 뿐입니다

수파베이스 개발 중 데이터가 제대로 안 읽히거나 인증 오류가 나면, 십중팔구 RLS(행 단위 보안)를 활성화해 놓고 정책(Policy)을 안 적었거나 반대로 RLS를 아예 꺼놔서 전 세계 해커들에게 테이블을 활짝 열어둔 상태인 경우다. 버그 리포트를 올리면 모더레이터들이 앵무새마냥 'RLS 정책 확인해보셨나요?'라고 답해서, 개발자들 사이에서는 '네가 겪는 고통의 99%는 RLS 때문이다'가 불문율로 통한다.(...)

5. 여담

Elixir와 Go의 누더기 골렘: 수파베이스는 전부 새로 코딩한 솔루션이 아니다. 실시간 통신 엔진은 엘릭서로 짰고, 인증 엔진은 Go 기반의 외부 오픈소스(GoTrue)를 가져다 개조했으며, 코어 데이터베이스는 순수 PostgreSQL을 돌린다. 이 이질적인 기술 스택을 API 게이트웨이인 Kong으로 접착제처럼 이어서 완성했는데, 아키텍처 다이어그램을 본 엔지니어들은 기겁을 금치 못한다.
자체 호스팅(Self-hosting)의 매운맛: 공식 문서에서는 도커 컴포즈 파일 하나로 니네 서버에 수파베이스 전체 서비스를 공짜로 띄울 수 있다고 큰소리를 떵떵 친다. 하지만 실제로 로컬에 도커 컴포즈를 올리는 순간 수십 개의 컨테이너가 램을 인정사정없이 갉아먹으며 에러 로그를 뿜어내고, 환경 변수 수십 개를 수동으로 매칭하느라 대가리가 박살이 나는 경험을 하게 된다. 결국 쌍욕을 뱉으며 유료 클라우드 SaaS 플랜에 카드를 긁게 만드려는 고도의 계략이라는 게 학계의 정설.
인공지능의 시대와 pgvector: AI 붐이 불자, 수파베이스는 가장 발 빠르게 PostgreSQL의 벡터 데이터 저장용 확장 프로그램인 pgvector 지원을 대대적으로 홍보했다. 덕분에 전 세계 AI 스타트업들이 값비싼 벡터 전용 DB(Pinecone 등)를 쓰는 대신 수파베이스 무료 티어에 벡터 데이터를 꾸역꾸역 집어넣고 연명하는 진풍경이 벌어졌다.

6. 관련 문서

물론 프로젝트가 대기업 수준으로 커지거나 복잡한 레거시 결제망 모듈, ERP 등을 연동해야 하는 시점이 오면, 프론트엔드 코드 내부의 수파베이스 API 호출 코드들이 거대한 스파게티로 변해 폭발하므로 결국 별도의 Node.js나 Spring Boot 백엔드 서버를 뒤늦게 파는 사태가 벌어진다. ↩
실제로 데이터베이스 트리거 내부에서 외부 타사 API를 호출하거나 복잡한 분기 처리를 구현하다가 에러가 나면 디버깅이 거의 불가능에 가깝다. 에러 로그에는 단 한 줄의 불친절한 SQL 오류 코드만 찍히기 때문에, 모니터 벽면에 머리를 박고 피를 흘리는 개발자들을 심심치 않게 찾아볼 수 있다. ↩