창업가로서 서비스를 구상하고 MVP(Minimum Viable Product)를 기획하다 보면 항상 '리소스의 한계'라는 벽에 부딪힌다. 아이디어를 빠르게 시장에서 검증해야 하는 프로토타이핑 단계에서, 사용자가 마주할 프론트엔드에 더해 인증, 데이터베이스, API 서버, 파일 스토리지까지 갖춘 '제대로 된' 백엔드를 구축하는 것은 많은 시간과 인력을 요구한다.
우리 팀의 조건
기술을 고르기 전에 조건부터 적어 두면 이렇다.
- 클라이언트는 Flutter 앱 하나였다. 저장소의 첫 커밋이 2025년 2월이고, 소수의 인원이 앱과 콘텐츠를 함께 만들고 있었다.
- 백엔드를 전담할 사람이 따로 없었다. 서버를 만들면 그 서버의 배포, 모니터링, 장애 대응도 같은 사람이 떠안는다.
- 가장 급한 질문은 "사람들이 이 게임을 끝까지 하는가"였다. 트래픽을 버티는 구조는 그다음 문제였다.
이 조건에서 "서버를 직접 만들 것인가"는 기술 선택이라기보다 시간 배분의 문제였다.
'서버가 없는' 백엔드는 어떻게 가능할까?
Firebase의 가치는 백엔드 코드를 '거의' 작성하지 않고도 필요한 기능을 갖춘 앱을 만들 수 있다는 점이다.
여기서 근본적인 질문이 하나 생긴다. '클라이언트(브라우저, 앱)에서 바로 데이터베이스를 조회하고 수정까지 한다니, 보안에 문제가 생기는 것 아닐까?'
이 질문에 답하는 것이 Firebase를 이해하는 출발점이다. '서버가 없다(Serverless)'는 말은 물리적인 서버가 없다는 뜻이 아니라, 우리가 직접 그 서버 코드를 개발하고 유지보수할 필요가 없다는 의미다. 보안 문제는 선언적인 '보안 규칙(Security Rules)'으로 푼다.
- Firebase Authentication: 이메일/패스워드, 혹은 구글 같은 소셜 로그인으로 사용자를 '인증(Authentication)'한다.
- Firestore Security Rules: 인증된 사용자를 기준으로 '인가(Authorization)'를 처리한다. "인증된 사용자만, 자신의 uid와 일치하는 문서만 읽고 쓸 수 있다" 같은 규칙을 Firebase 전용 규칙 언어로 선언한다.
지금 우리 서비스의 규칙 파일에 있는 함수를 그대로 옮기면 이런 모양이다.
function isOwner(uid) {
return isSignedIn() && request.auth.uid == uid;
}
match /users/{uid} {
allow read: if isOwner(uid);
}
Express나 Spring으로 API 엔드포인트를 만들고, JWT 토큰을 검증하고, 요청자가 그 데이터에 접근할 권한이 있는지 코드로 확인하던 일을 이 몇 줄의 규칙이 대신한다.
다만 규칙을 쓰다 보면 "누가 읽을 수 있는가"보다 "누가 어떤 필드를 쓸 수 있는가"가 더 까다롭다. 예를 들어 프로모션 자격 판단에 쓰이는 가입 시각은 서버만 기록해야 한다. 클라이언트가 자기 문서를 수정할 수 있더라도 이 필드만은 규칙에서 따로 막아야 했다. 서버 코드를 안 쓰는 대신, 서버 코드가 하던 검증을 규칙으로 빠짐없이 옮겨야 한다는 뜻이다.
스타트업을 위한 올인원 백엔드
Firebase가 프로토타이핑에 유리한 이유는 인증과 데이터베이스만 주는 것이 아니기 때문이다. 서비스 하나를 운영하는 데 필요한 백엔드 기능 대부분을 한곳에서 제공한다.
Firestore: 실시간 동기화가 가능한 NoSQL 데이터베이스.
Authentication: 강력한 사용자 인증 솔루션.
Storage: 이미지, 영상 등 사용자가 업로드하는 파일을 위한 보안 저장소. (이 역시 Security Rules로 제어된다.)
Hosting: 프론트엔드 정적 파일(JS, CSS, HTML)을 배포하고 전 세계 CDN을 통해 빠르게 제공하는 호스팅 솔루션.
우리 앱은 여기에 Remote Config(앱 배포 없이 설정 바꾸기), Cloud Messaging(푸시), App Check(정상 앱에서 온 요청인지 확인)까지 붙여 썼다. MVP를 올리는 데 필요한 것은 이 안에서 대부분 해결됐다.
서버에서만 돌아야 하는 로직을 위한 Cloud Functions
그래도 서버에서만 실행되어야 하는 민감한 로직은 생긴다. 결제 처리, 데이터베이스의 특정 데이터가 바뀌었을 때 실행되어야 하는 트리거, 관리자만 부를 수 있는 API가 그런 경우다.
이때 쓰는 것이 Firebase Cloud Functions다. 소량의 서버 사이드 코드를 Firebase 환경에 배포해 두면, 특정 이벤트(DB 쓰기, 파일 업로드 등)에 반응하거나 HTTP 요청으로 실행된다. 우리는 비즈니스 로직 중 꼭 서버에 있어야 하는 부분만 여기에 두고, 나머지 인프라는 Firebase에 맡겼다. 초기 결제 로직도 이 Callable Function 위에 있었다.
로컬 개발 에뮬레이터(Local Emulator) 도 잘 갖춰져 있어서, 클라우드에 배포하거나 비용을 내지 않고도 로컬에서 Firestore, Auth, Functions를 함께 띄워 테스트할 수 있다.
덧붙임 (2026년): 그 시점은 넉 달 뒤에 왔다
이 글을 쓰고 약 넉 달 뒤, 위에서 말한 "옮겨야 하는 시점"이 실제로 왔다. 예상대로 한 번에 오지 않고 부분별로 왔다.
| 시기 | 떼어낸 것 | 목적 |
|---|---|---|
| 2026년 3월 초 | 클라이언트의 LLM 직접 호출 → FastAPI 서버 | API 키 노출과 프롬프트 인젝션 경로를 서버 뒤로 숨기기 위해 |
| 2026년 3월 중순 | Storage URL → GCS 버킷 직접 호출 | Firebase 계층을 거치는 이미지 로딩이 느려서 |
| 2026년 3월 말 | Callable Function 결제 → Cloud Run REST API | 스토어 영수증 검증, 멱등 지급, 트랜잭션을 갖춘 결제 API로 다시 짜기 위해 |
세 경우 모두 Firebase를 버린 것은 아니다. 인증과 Firestore는 지금도 쓰고, 새 서버들도 Firestore를 저장소로 쓴다. 떼어낸 것은 "Firebase가 대신 판단하던 부분"이었다. 각각의 과정은 아래 글에 따로 적었다.
- [스타트업/기술] FastAPI와 클라우드 네이티브 | 클라이언트 LLM 호출의 한계와 백엔드 전환기 (Part 1)
- [스타트업/기술] Firebase Storage 이미지 로딩 최적화 | GCP Bucket 직접 호출을 통한 Latency 개선
- [스타트업/기술] Node.js & Google Play 인앱결제 | 결제 시스템 아키텍처 설계 (Part 1)
돌아보면 처음 선택을 후회하지는 않는다. 다만 "필요해지면 옮기면 된다"에도 비용이 있었다. 클라이언트가 Firestore를 직접 읽는 구조라 서버 쪽 구조를 바꾸면 앱 코드도 같이 바뀌어야 했다. 이미지 경로를 바꿀 때는 문서에 저장된 URL을 일괄로 고쳐야 했고, 가격을 카탈로그로 옮길 때는 앱의 가격 표시 로직을 따로 고쳐야 했다.
