이 페이지에서는 Firebase 프로젝트를 설정하고 프로젝트에 앱을 등록하는 일반적인 권장사항을 간략히 설명합니다. 이 내용을 토대로 고유한 환경을 사용하는 개발 워크플로를 명확하게 이해할 수 있습니다. 이 페이지의 권장사항을 숙지한 후 일반 보안 가이드라인을 확인하세요.
Firebase 프로젝트의 계층 구조 이해하기
이 다이어그램은 Firebase 프로젝트의 기본 계층 구조를 보여줍니다. 키 관계는 다음과 같습니다.
Firebase 프로젝트는 모든 앱 및 프로젝트에 프로비저닝된 리소스와 서비스를 위한 컨테이너와 같습니다.
Firebase 프로젝트에는 하나 이상의 Firebase 앱을 등록할 수 있습니다(예: 앱의 iOS 및 Android 버전 또는 앱의 무료 버전과 유료 버전 모두).
동일한 Firebase 프로젝트에 등록된 모든 Firebase 앱은 프로젝트에 프로비저닝된 모든 동일한 리소스와 서비스를 공유하고 여기에 액세스할 수 있습니다.
예를 들면 다음과 같습니다.
같은 Firebase 프로젝트에 등록된 모든 Firebase 앱은 Firebase Hosting, Authentication, Realtime Database, Cloud Firestore, Cloud Storage, Cloud Functions와 같은 동일한 백엔드를 공유합니다.
동일한 Firebase 프로젝트에 등록된 모든 Firebase 앱은 동일한 Google 애널리틱스 속성과 연결되며, 여기서 각 Firebase 앱은 해당 속성에서 별도의 데이터 스트림입니다.
Google Cloud 프로젝트는 이 계층 구조에서 어떤 위치에 적합한가요?
위 다이어그램에 표시되지 않은 Firebase 프로젝트 계층 구조의 한 가지 측면은 Google Cloud 프로젝트와의 관계입니다. Firebase 프로젝트는 실제로는 사용 설정된 Firebase 관련 구성과 서비스가 추가적으로 포함된 Google Cloud 프로젝트입니다.
동일한 Firebase 프로젝트에 등록된 모든 앱도 동일한 Google Cloud 리소스 및 서비스를 공유하고 액세스할 수 있습니다.
Firebase 프로젝트에 등록된 모든 앱이 최종 사용자의 관점에서 동일한 애플리케이션의 플랫폼 변형인지 확인합니다. 동일한 앱 또는 게임의 iOS, Android, 웹 버전을 동일한 Firebase 프로젝트에 등록합니다.
동일한 Firebase 리소스를 공유할 수 있는 빌드 변형이 여러 개 있는 경우동일한 Firebase 프로젝트에 변형을 등록합니다. 몇 가지 예로 동일한 프로젝트의 블로그 및 웹 앱, 동일한 프로젝트에 있는 동일한 앱의 무료 및 유료 버전이 있습니다.
이미 출시 상태 기준인 여러 빌드 변형이 있는 경우 위와 같은 일반적인 최종 사용자 활동 또는 액세스 대신 각 변형을 별도의 Firebase 프로젝트에 등록합니다. 한 가지 예는 디버그 빌드와 출시 빌드를 비교하는 것입니다. 이 경우 각 빌드를 자체 Firebase 프로젝트에 등록합니다.
디버그 데이터가 오염되거나 프로덕션 데이터가 재정의될 위험이 있으므로 출시 상태를 기반으로 한 빌드는 동일한 Firebase 리소스를 공유해서는 안 됩니다.
각 빌드 변형의 플랫폼 변형은 동일한 Firebase 프로젝트에 있어야 합니다. 예를 들어, iOS와 Android 디버그 빌드를 둘 다 'dev' Firebase 프로젝트에 등록합니다. 둘 다 동일한 비프로덕션 데이터 및 리소스와 상호작용할 수 있기 때문입니다.
멀티테넌시 방지하기
멀티테넌시로 인해 의도하지 않은 애널리틱스 집계, 인증 공유, 지나치게 복잡한 데이터베이스 구조, 까다로운 보안 규칙 등 구성 및 데이터 개인 정보 보호와 관련해 심각한 문제가 발생할 수 있습니다.
일반적으로 여러 앱에서 동일한 데이터와 구성을 공유하지 않으면 각 앱을 서로 다른 Firebase 프로젝트에 등록하는 것이 좋습니다.
예를 들어 화이트 라벨 애플리케이션을 개발하는 경우 독립적으로 라벨이 지정된 각 앱마다 자체 Firebase 프로젝트가 있어야 하며, 해당 라벨의 iOS 및 Android 버전은 동일한 Firebase 프로젝트에 있어야 합니다. 독립적으로 라벨이 지정된 각 앱은 개인 정보 보호를 위해 데이터를 서로 공유하지 않아야 합니다.
다음 단계
다양한 환경의 일반 보안 가이드라인을 검토합니다. 각 환경과 데이터가 안전한지 확인하려고 합니다.
[null,null,["최종 업데이트: 2025-08-04(UTC)"],[],[],null,["This page provides general, high-level best practices for setting up Firebase\nprojects and registering your apps with a project so that you have a clear\n[development workflow](/docs/projects/dev-workflows/overview-environments) that\nuse distinct environments. Once you're familiar with the best practices on this\npage, check out our\n[general security guidelines](/docs/projects/dev-workflows/general-security-guidelines).\n| **Key Point:** We recommend reading our guides thoroughly, but here's the top takeaway about development workflows: \n| **Firebase recommends using a *separate* Firebase project for *each* environment\n| in your development workflow.**\n\nUnderstanding the hierarchy of Firebase projects\n\n\nThis diagram shows the basic hierarchy of a Firebase project. Here are the key\nrelationships:\n\n- A **Firebase project** is like a container for all your apps and any resources\n and services provisioned for the project.\n\n- A Firebase project can have one or more **Firebase Apps** registered to it\n (for example, both the iOS and Android versions of an app, or both the free\n and paid versions of an app).\n\n- All Firebase Apps registered to the same Firebase project **share and have\n access to all the same resources and services provisioned for the project**.\n Here are some examples:\n\n - All the Firebase Apps registered to the same Firebase project share the same\n backends, like Firebase Hosting, Authentication, Realtime Database, Cloud Firestore,\n Cloud Storage, and Cloud Functions.\n\n - All Firebase Apps registered to the same Firebase project are associated\n with the same Google Analytics property, where each Firebase App is a\n separate data stream in that property.\n\nWhere does a Google Cloud project fit into this hierarchy?\n\nOne aspect of the Firebase project hierarchy that's not shown in the diagram\nabove is the relationship with a Google Cloud project. **A Firebase project is\nactually just a Google Cloud project that has additional *Firebase-specific*\nconfigurations and services enabled for it.**\nNote that all the apps registered to the same Firebase project also share and\nhave access to all the same Google Cloud resources and services, too.\n\nLearn more about the Firebase and Google Cloud relationship in\n[Understand Firebase projects](/docs/projects/learn-more#firebase-cloud-relationship)\n\nRegistering app variants with Firebase projects **Key Point:** All the apps registered to a Firebase project share and can access the same data as well as the resources and services provisioned for the project, which includes database instances, storage buckets, functions, etc.\n\nHere are some important tips for registering your app variants with a Firebase\nproject:\n\n- Ensure that all apps registered to a Firebase project are **platform variants\n of the same application** from an end-user perspective. Register the iOS,\n Android, and web versions of the same app or game with the *same* Firebase\n project.\n\n- If you have **multiple build variants that could *share the same Firebase\n resources*** , register the variants with the *same* Firebase project. Some\n examples are a blog and a web app in the same project, or both the free and\n paid versions of the same app in the same project.\n\n- If you have **multiple build variants that are *based on release status***\n (rather than on common end-user activity or access, like above), register each\n variant with a *separate* Firebase project. An example is your debug vs\n release build -- register each of these builds in its own Firebase project.\n\n - Builds based on release status should not share the same Firebase resources\n because that risks your debug data polluting or even overriding your prod\n data.\n\n - The *platform* -variants of each of these build variants should be in the\n *same* Firebase project. For example, register both the iOS and the Android\n debug builds in a \"dev\" Firebase project because they can both interact with\n the same non-prod data and resources.\n\n| **Note:** For each Android app, if you provide a SHA-1 key for the app, you need to provide a package name and SHA-1 key combination that is globally unique across all of Google Cloud.\n\nAvoiding multi-tenancy **Key Point:** Connecting several different logically independent apps and/or web sites to a single Firebase project (often called \"multi-tenancy\") is not recommended.\n\nMulti-tenancy can lead to serious configuration and data privacy concerns,\nincluding unintended issues with analytics aggregation, shared authentication,\noverly-complex database structures, and difficulties with security rules.\n\nGenerally, **if a set of apps don't share the same data and configurations,\nstrongly consider registering each app with a different Firebase project.**\n\nFor example, if you develop a white-label application, each independently\nlabeled app should have its own Firebase project, and the iOS and Android\nversions of that label should be in the same Firebase project. Each\nindependently labeled app shouldn't (for privacy reasons) share data with the\nothers.\n\nNext steps\n\n- Review the\n [general security guidelines](/docs/projects/dev-workflows/general-security-guidelines)\n for different environments. You want to make sure each environment and its\n data are secure.\n\n- Review the [Firebase launch checklist](/support/guides/launch-checklist)."]]