Supabase 한계 총정리 — 이 5가지 기능은 백엔드 없이 안 됩니다

"Supabase 하나면 서버는 따로 안 만들어도 된다"는 말, 외주 견적이나 제안서에서 보셨을 겁니다.

절반은 맞고 절반은 틀립니다. 강력하지만 구조적으로 못 하는 영역이 분명히 있거든요.

에그코드는 자체 서비스를 직접 만들고 운영하는 개발사입니다.

수파베이스로 웹·SaaS·MVP를 만들다가 "여기서부턴 백엔드 서버가 필요하다"고 판단했던 지점을 정리했습니다.

1. Edge Functions — 무거운 작업은 도중에 끊깁니다

Supabase의 Edge Functions는 서버 코드를 함수 단위로 실행해줍니다. (Deno 기반 서버리스 함수 = 요청 때만 잠깐 도는 짧은 코드)

한계: 영상 인코딩·대량 배치·ML 추론처럼 수 분 이상 걸리는 작업은 실행 시간·CPU 제약에 막힙니다. 짧게 돌도록 설계돼 긴 작업은 끊기죠.

2. Realtime — 채팅은 되지만 게임 서버는 안 됩니다

Supabase Realtime은 데이터 변경을 화면에 알려주고(변경 구독), 접속자끼리 메시지를 주고받는(broadcast·presence) pub-sub 기능입니다. 채팅·알림엔 충분하죠.

한계: 게임 서버처럼 서버가 모든 판정의 주인인 권위 서버나, 임의로 정한 커스텀 실시간 프로토콜은 이 구조로 못 만듭니다. 정해진 pub-sub 모델이지 내 규칙을 돌리는 엔진이 아니거든요.

3. RLS — 단순 권한은 되지만 다단계 결재는 버겁습니다

RLS(Row Level Security)는 "이 데이터를 누가 볼 수 있는가"를 데이터베이스 차원에서 막는 Postgres 보안 정책입니다. "본인 글만 수정 가능" 같은 규칙은 깔끔합니다.

한계: "1차 승인·2차 반려·금액별 임원 승인"처럼 여러 상태가 얽힌 다단계 권한은 정책 한 줄로 표현하기 어렵습니다.

4. pg_cron — 예약 실행은 되지만 정교한 작업 큐는 아닙니다

Supabase는 pg_cron으로 "매일 새벽 3시 정리 작업" 같은 간단한 예약 작업을 걸 수 있습니다.

한계: 하지만 "실패하면 3번 재시도, 동시 10개만 처리, 우선순위 먼저" 같은 작업 큐(job queue)·재시도·동시성 제어는 단순 스케줄러와 다른 영역입니다.

5. 서버 검증 — 결제·웹훅은 신뢰할 수 있는 서버가 필요합니다

클라이언트 SDK는 브라우저·앱에서 데이터베이스에 직접 접근합니다. 편하지만, 결제 승인·웹훅 검증처럼 위변조되면 안 되는 로직까지 사용자 기기에 맡길 순 없습니다.

정리하며

오해를 풀면, Supabase가 부족한 도구라는 뜻이 아닙니다. 대부분의 MVP·웹 서비스는 수파베이스만으로 충분히 출시할 수 있습니다.

다만 위 5가지 중 하나가 서비스의 핵심이라면, 처음부터 백엔드 서버를 함께 설계해야 합니다. 어디까지 이 도구로 가고 어디서 서버를 붙일지, 그 경계를 긋는 것이 곧 개발사의 실력입니다.