디자이너가 Firebase를 선택한 이유 ✦ ft. Supabase

안녕하세요! ARCOA 지안입니다. 👋

이전 글에서 FlutterFlow(FF)와 Firebase(Fb) 기반의 노코드 앱 개발에 도전한다고 말씀드렸는데요. 본격적인 세팅에 들어가기 전에, 많은 분이 궁금해하시는 "왜 Firebase인가?"에 대한 이야기를 먼저 나누려고 합니다.

 

스타트업은 Supabase,
Firebase는 비싸다

처음 찾아본 정보들은 위와 같이 요약할 수 있었습니다. 특히 개발자 커뮤니티에서는 Supabase의 SQL 기반 구조와 오픈소스 철학을 높이 평가하더군요. 그래서 저도 자연스럽게 Supabase를 먼저 고려했지만, Firebase를 선택했습니다.


 

 

 

1/ Firebase vs Supabase. 디자이너 관점

저는 MVP(Minimum Viable Product)를 빠르게 만들고 시장에 출시하는 것을 목표로 했기 때문에 백엔드를 고를 때 다음 세 가지에 집중했습니다.

• ① 개발 속도와 러닝 커브: 디자이너가 직접 코딩 없이 얼마나 빨리, 쉽게 구현할 수 있는가?
• ② 프론트엔드와의 궁합: FlutterFlow와 얼마나 오류 없이 잘 연결되는가?
• ③ 문제 해결 용이성: 막혔을 때, 해결책을 얼마나 쉽게 찾을 수 있는가?

두 서비스를 비교하며 고민한 결과를 표로 정리해봤습니다.

구분	Firebase	Supabase
데이터베이스	NoSQL (Firestore)	PostgreSQL (SQL)
FlutterFlow 연동	최상 네이티브 지원 ⭐	우수 수동 API (최근 지원 강화 중)
실시간 기능	안정 기본 제공	불안 베타 수준 제공
디자이너 친화	높음 유연성, 즉시 연동 ⭐	중간 SQL 문법 학습 필요
무료 플랜	읽기 50K/일, 쓰기 20K/일	500MB DB, API 무제한
Analytics	기본 탑재	별도 설정
한국어 문서	풍부 ⭐	부족
커뮤니티	대규모	성장 중
비용 (확장 시)	종량제 (비쌀 수 있음)	25달러부터 정액제

 

 

 

2/ Firebase를 선택한 결정적 이유

1️⃣ FlutterFlow와의 네이티브 통합

Firebase는 FlutterFlow에서 비교적 쉽게 연동됩니다. 프로젝트 생성 시 "Setup Firebase" 옵션을 선택하면 Auth, Firestore, Storage를 자동으로 설정할 수 있습니다. 반면 Supabase는 API 키를 직접 입력하고, Custom Action을 일일이 구성해야 합니다.​
디자이너에게 이 차이는 결정적입니다. 코드를 모르는 상태에서 API 연동 오류를 디버깅하는 건 너무 큰 벽인데, Firebase는 이 벽을 없애줬습니다.​

 

2️⃣ 유연한 Firestore의 매력

Firebase의 DB인 Firestore는 NoSQL로 유연합니다. Firestore는 문서(Document) 단위로 데이터를 저장하므로, 기능이 추가되거나 데이터 필드가 바뀌어도 기존 구조를 크게 해치지 않고 유연하게 대응할 수 있습니다.
SQL은 테이블 간 관계를 엄격하게 정의해야 하므로, 개발 초기부터 데이터 설계(DB Design)에 많은 시간이 필요합니다. 하지만 MVP는 기획이 자주 바뀌죠. 제품의 초기 아이디어를 실험하고 검증하는 디자이너에게는 이 유연성은 최고의 장점입니다.

TIP 디자이너 혼자 가능한 선택일까?
Firebase는 서버 관리, 배포, 초기 스케일링을 모두 자동화합니다. FlutterFlow는 데이터 연결 코딩을 클릭 한 번으로 대신해 줍니다. 따라서 디자이너는 코드를 짜는 것 대신, 데이터 구조를 설계하는 것에만 집중할 수 있습니다.
디자이너가 백엔드 개발 주도권을 확보할 수 있는 가장 효율적인 방법이라고 생각합니다.

 
3️⃣ MVP 단계에서의 비용 효율

많은 글에서 Firebase는 비싸다고 하지만, 사용자 1,000명 이하의 MVP 단계에서는 무료 플랜으로 충분합니다. Firestore 무료 플랜은 일일 읽기 50,000건, 쓰기 20,000건을 제공하는데, 제 프로젝트의 초기 사용 패턴으로는 전혀 부족하지 않죠.​
오히려 Supabase는 무료 플랜이 500MB로 제한되어 있어, 카드 이미지 같은 에셋이 많은 프로젝트에서는 금방 결제가 필요할 수 있습니다. Firebase Storage는 5GB까지 무료라 여유가 있어요.

 

 

 

3/ Supabase의 장점

• SQL 기반 구조: 복잡한 관계형 데이터를 다룬다면 유리
• 비용 예측성: 확장 시, 정액제라 예산 관리 편리
• 오픈소스: 자체 호스팅이 가능한 데이터 주권

만약 제가 개발자였다면, 혹은 SQL에 익숙한 팀원이 있었다면 Supabase를 선택했을 수도 있습니다. 하지만 디자이너 혼자, 노코드 툴로, MVP를 빠르게 만드는 상황에서는 Firebase가 더 나은 선택이었습니다.

 

 

 

4/ 그럼에도 불구하고: Firebase 리스크와 대응 전략

물론 Firebase가 완벽한 선택은 아니겠죠. 가장 큰 리스크는 앱이 성공했을 때의 비용 부담입니다. 사용자 수십만 명 규모로 확장되면, 종량제 기반인 Firebase의 비용이 Supabase나 자체 서버에 비해 비싸질 수 있습니다.

하지만 이것은 “계산된 리스크“로 보고 있습니다.

1. 리스크 관리: 비용이 부담될 정도로 증가했다는 것은, 이미 수십만 명의 사용자를 확보했고 앱이 수익을 창출하고 있다는 의미입니다. 이것은 명백한 성공의 증거 🎉
2. 전략적 대응: 비용 청구가 시작되는 시점부터는 데이터 최적화(#4 Firestore 콜렉션 구조 이해)와 캐싱 전략으로 비용 절감을 진행할 것입니다.
3. 향후 확장성: 이후 더 복잡한 서버 로직이나 비용 효율 극대화가 필요한 때가 오면, Firebase Authentication은 유지하면서 복잡한 쿼리의 분리 이관(Hybrid) 또는 개발자 고용 등의 방법을 생각하고 있습니다.

가장 빠르고 확실하게 시장 검증에 도달하는 것이 최우선 목표이고, 가장 효율적인 Firebase를 선택한 것이죠!

 

 

 

5/ 결론: 나에게 맞는 선택

Firebase를 선택한 건 "더 좋은 기술"을 고른 게 아니라, "내 상황에 맞는 도구"를 선택한 것입니다.​

• 비개발자도 가능한 난이도의 러닝 커브
• FlutterFlow와의 완벽한 통합
• 유연한 DB 구조
• MVP에 충분한 무료 플랜
• 풍부한 한국어 자료와 커뮤니티

 

 

다음 글: 진짜 Firebase 시작!

✦ 디자이너(비개발자)의 Firebase 셋업

├ 1 ✦ Firebase 프로젝트 생성
├ 2 ✦ Blaze 요금제 완전 가이드
├ 3 ✦ Google Authentication 로그인 연결

├ 4 ✦ Google Auth FlutterFlow 연동 준비
└ 5 ✦ Apple Authentication 로그인 연결

 

다음 글은 디자이너의 Firebase 셋업 ✦ 총 5편입니다.

디자이너(비개발자)의 Firebase 셋업 ✦ 총 5편