Supabase는 왜 인기 있을까

지금까지 Express로 라우트를 만들고, MySQL에 데이터를 저장하고, 쿠키로 인증을 처리하는 법을 배웠습니다. 직접 만들어보니 백엔드가 어떻게 동작하는지 이해됩니다.

그런데 현실에서 서비스를 만들 때, 이 모든 것을 처음부터 직접 만드는 팀은 생각보다 적습니다. "데이터베이스는 뭘 쓸지", "인증은 어떻게 구현할지", "파일 업로드는 어디에 저장할지" — 하나하나 결정하고 구축하다 보면, 정작 핵심 기능을 만들 시간이 부족합니다.

이 문제를 해결하기 위해 등장한 것이 **BaaS(Backend as a Service)**이고, 그 대표 주자가 Supabase입니다.

백엔드 병목이라는 현실

실험실에서 비유하면 — 새로운 분석법을 개발하려는데, 시약을 직접 합성하고, 장비를 직접 조립하고, 소프트웨어를 직접 짜야 한다면? 분석법 하나 만드는 데 1년이 걸립니다. 대부분은 검증된 시약을 사고, 상용 장비를 쓰고, 기존 분석 소프트웨어 위에서 작업합니다.

웹 개발도 마찬가지입니다. 서비스를 만들 때 필요한 백엔드 기본 부품들:

이 중 하나라도 빠지면 서비스가 동작하지 않습니다. 그런데 이것들을 전부 직접 만드는 것은 — 마치 실험할 때마다 PCR 기계를 직접 조립하는 것과 같습니다. 가능은 하지만, 그래야 할 이유가 있어야 합니다.

BaaS: 백엔드를 서비스처럼 쓰기

BaaS는 이 기본 부품들을 이미 만들어진 서비스로 제공합니다. 데이터베이스, 인증, 파일 저장, API가 한 묶음으로 준비되어 있고, 개발자는 그 위에 자기 서비스의 핵심 로직만 올리면 됩니다.

DevBench의 학습 과정과 연결하면:

직접 만드는 방식 (우리가 배운 것):
  Node.js → Express → MySQL → 쿠키/세션 → 직접 조립

BaaS 방식:
  Supabase 계정 생성 → 테이블 만들기 → API 자동 생성 → 인증 설정
  → 핵심 기능 개발에 집중

"그러면 왜 Express랑 MySQL을 배웠지?" — 이것이 핵심입니다. BaaS를 제대로 쓰려면, 그 안에서 무슨 일이 벌어지는지 알아야 합니다. SQL을 모르면 Supabase 테이블을 설계할 수 없고, HTTP를 모르면 API 호출을 디버깅할 수 없습니다. 기초를 배운 사람만이 BaaS를 도구로 쓸 수 있고, 안 배운 사람은 BaaS에 끌려다닙니다.

Supabase가 선택되는 이유

BaaS 서비스는 여럿 있는데, 요즘 Supabase가 자주 선택되는 이유는 세 가지입니다.

1. PostgreSQL 기반

Supabase의 데이터베이스는 PostgreSQL입니다. 우리가 배운 MySQL과 SQL 문법이 90% 이상 동일합니다. SELECT, INSERT, JOIN — 전부 그대로 씁니다.

PostgreSQL은 세계에서 가장 널리 쓰이는 관계형 데이터베이스 중 하나입니다. 즉, Supabase를 쓰다가 나중에 다른 시스템으로 옮기더라도, SQL 지식과 데이터 구조가 그대로 살아남습니다. 실험 데이터를 표준 포맷(CSV, FASTA)으로 저장하면 어떤 분석 도구에서든 쓸 수 있는 것과 같습니다.

2. 오픈소스

Supabase는 오픈소스입니다. 코드가 공개되어 있고, 원하면 자기 서버에 직접 설치해서 쓸 수 있습니다. 이것은 "벤더 종속(vendor lock-in)" — 특정 서비스에 묶여서 나올 수 없는 상태 — 을 방지합니다.

3. 웹 개발 생태계와의 궁합

React, Next.js 같은 프론트엔드 프레임워크와 자연스럽게 연결됩니다. BioPlayground도 Next.js + Supabase 조합으로 만들어져 있습니다.

Firebase vs Supabase vs 직접 구축

Firebase는 Google의 BaaS로, 모바일 앱에서 특히 강합니다. 하지만 NoSQL 기반이라 관계형 데이터(시료-연구자 관계 같은 것)를 다루기 어렵습니다.

Supabase는 SQL 기반이라, 우리가 배운 관계형 데이터 모델을 그대로 쓸 수 있습니다. "Firebase의 편리함 + PostgreSQL의 안정성"이 Supabase의 포지션입니다.

연구자에게 BaaS가 의미하는 것

연구실에서 간단한 시료 관리 웹앱, 실험 기록 대시보드, 팀 내부 도구를 만들고 싶을 때 — 백엔드를 처음부터 구축할 필요가 없습니다.

Supabase 같은 BaaS를 쓰면:

• 테이블 설계 → Supabase 대시보드에서 클릭으로
• 인증 → 이메일/Google 로그인이 설정만으로
• API → 테이블을 만들면 자동으로 REST API 생성
• 프론트엔드 → React로 화면만 만들면 됨

이것이 가능하려면 — SQL이 뭔지, API가 뭔지, 인증이 어떻게 동작하는지를 이미 알고 있어야 합니다. DevBench에서 배운 것들이 정확히 이 기초입니다.

결론: 기초 위에 올라서야 도구가 보인다

BaaS는 백엔드를 "없애는" 것이 아니라, 반복적인 부분을 서비스로 대체하는 것입니다. Express로 서버를 직접 만들어본 사람은 Supabase가 무엇을 대신해주는지 정확히 이해합니다. 만들어보지 않은 사람은 "뭐가 편해진 건지" 감이 안 옵니다.

실험 장비를 쓰려면 원리를 알아야 하듯, BaaS를 쓰려면 백엔드의 원리를 알아야 합니다. 그래야 문제가 생겼을 때 — "이건 내 코드 문제인가, Supabase 설정 문제인가?"를 구분할 수 있습니다.

지금까지 배운 것들이 헛되지 않았습니다. 오히려 이제부터 진짜 힘을 발휘합니다.