이 정도로 복잡한 도구를 만들 실력이라면 Firebase 대신 다른 도구를 쓰지 않는 이유가 궁금함. 웹 개발에 입문할 때는 Firebase에 많이 의존했지만, 지금은 그 단계를 벗어난 느낌임. 숙련된 개발자에게도 여전히 유용한지, 아니면 예전의 나 같은 입문자를 위해 만드는 것인지 궁금함.
Firebase 외에도 여러 서비스를 사용하지만, 2026년에도 Firebase는 본래 역할을 잘한다고 느낌. 부족한 부분은 많아도 소규모 프로젝트나 입문자가 시작하기에는 여전히 편리함.
의외로 대규모 모바일·웹 앱도 많이 사용하고 있으며, 비용 없이 로컬 개발을 하려면 에뮬레이터 제품군에 의존하게 됨. Supabase는 개발 경험 개선에 집중하는 반면 Firebase의 로컬 개발 환경은 오랫동안 그대로임. 이 환경을 개선하면 기존 프로젝트 유지보수와 신규 개발을 더 빠르고 쾌적하게 할 수 있다고 봄.
Firestore의 하위 컬렉션은 꽤 훌륭함. NoSQL 데이터베이스 중에서도 쿼리와 인덱싱이 유연해 DynamoDB보다 앱 개발에 더 적합함.
발목을 잡는 것은 개발 도구의 부족임. Prisma나 Mongoose처럼 유지보수가 이루어지는 타입 안전 쿼리 ORM/ODM이 없다는 점이 큰 약점이며, 멋진 firestorm도 놓치고 있음.
Firebase를 많이 사용하는 입장에서, 넉넉한 무료 할당량과 확장 경로가 큰 장점임. 대부분의 프로젝트를 사실상 무료로 운영하며, GCP 위의 추상화라 Firebase → Cloud Run → GKE Autopilot → GKE로 자연스럽게 이동할 수 있음. 인증 흐름용 Function을 미리 실행해 두는 등 일부 용도에만 비용을 지불함. Firebase Auth는 SSO를 붙이기 매우 쉽고, Azure·AWS의 대안보다 간편하고 실수할 여지가 적으며 대부분 무료임. 잘 설계한 Firestore 백엔드도 사이드 프로젝트에서는 사실상 무료이고, 작은 PostgreSQL 인스턴스라면 감당하기 어려울 Reddit발 트래픽 급증도 거뜬히 처리함. 무료 한도를 넘어도 가격이 합리적이라 여러 프로젝트와 블로그를 수년째 운영 중임.
별도 인프라 없이 실시간 WebSocket을 제공하고, 실시간 구독이 저장소와 긴밀하게 통합되어 있다는 점도 좋음. Cloudflare의 PartyKit은 비슷한 역할을 하지만, 마지막으로 써본 Amplify AppSync는 불안정했고 DynamoDB 위에 얹은 가짜 관계형 추상화는 대규모 운영에서 위험해 보였음. Azure SignalR, Web PubSub, Fluid Relay는 무료가 아니거나 무료 등급으로는 초기 시험 이상을 하기 어려움.
대형 클라우드에서 직접 운영하려면 Firebase가 가장 편리함. Azure에는 뚜렷한 대응 제품이 없고, AWS는 유용했던 Copilot CLI를 중단함. CosmosDB도 좋아했지만 Microsoft가 수년간 작동하는 ARM64 에뮬레이터를 내놓지 않아 Mac에서 쓸 수 없었음. 관련 이슈는 여기에서 확인 가능함. AWS·Azure·GCP 어느 계층이든 다룰 수 있지만, 필요할 때만 그렇게 하고 싶으며 Firebase는 빠르게 출시한 뒤 필요에 따라 하위 클라우드 인프라로 내려갈 수 있게 해줌.
최근까지 다른 플랫폼의 에뮬레이션 선택지도 좋지 않았음. AI 덕분에 에뮬레이터가 늘어나는 듯하지만, LocalStack은 이미 일부 기능을 유료 라이선스 뒤로 옮겼음. Firebase 에뮬레이터는 앱 개발부터 출시까지 필요한 기능을 상당히 충실하게 갖췄으며, OAuth 에뮬레이터도 여전히 훌륭함.
Firebase 에뮬레이터를 감당할 더 강력한 개발 장비를 마련하지 않은 이유는 무엇인가? 실행 성능이 경쟁 우위라면, Google이 Spanner 등에서 쌓은 수십 년의 클라우드 데이터베이스 경험으로 성능 저하를 개선하면 되는 것 아닌가?
날카로운 질문이라 조금 미안하지만, 무조건적인 찬사보다 어려운 질문을 하는 편이 더 친절하다고 믿음.
나도 Rust로 Firebase Realtime Database의 오픈소스 구현을 만들고 있음. Firenook에 Realtime Database 지원을 추가할 계획이라면 기반으로 활용할 만함. 프로젝트는 https://github.com/lark-sh/lark에 있음.
Firenook에 Realtime Database를 통합할 계획이 있어서 Lark를 꼭 살펴보겠음.
Google이 이 개발 환경을 여전히 개선하지 않는다는 사실은 놀랍지 않음. Firebase 개발자가 직접 비용을 내지 않고 앱을 만들려면 공식 Firebase Emulator Suite를 써야 한다는 대목이 그 이유를 정확히 짚어줌.
이전 직장에서도 비슷한 답답함 때문에 관리 UI를 만들기 시작했음. 개발 전용 소·중규모 앱이면 충분할 도구가 Java 관련 부산물을 쏟아내는 모습이 괴로웠음.
Firenook 콘솔 UI를 써보고 개발 경험을 개선할 수 있는 기능이 빠져 있다면 알려주길 바람.
서버 한 대에 올려서 나만의 Firebase처럼 사용할 수 있는가?
기술적으로는 가능함. 다만 지금은 에뮬레이터의 완성도에 집중하고 있음. 이후 자체 호스팅을 지원할 때 높은 신뢰성을 확보하고 운영 데이터를 안전하게 다룰 수 있도록 하려는 것임.
이걸 보니 다음 앱에서는 Supabase 대신 Firebase를 써보고 싶어짐.
에뮬레이터에서 Application Integration까지 실행할 수 있다면 팀 전체의 전환을 진지하게 고려하겠음. 엄밀히는 Firebase 밖의 기능이지만, 우리 서비스는 GCP와 Firebase를 복잡하게 뒤섞어 사용하고 있음.
클라우드 운영 서비스까지 대체할 계획이 있는가?
우선 Firenook의 로컬 실행을 완성하는 것이 목표임. 충분히 안정화되면 클라우드 버전을 검토하기 전에 자체 호스팅부터 지원하려고 생각 중임. 클라우드에서는 어떤 서비스를 대체하는 데 사용할 계획인지 궁금함.