프로덕션 앱의 경우 특히 1명 이상이 앱에서 작업하고 있다면 명확한 개발 워크플로를 설정해야 합니다. 개발 워크플로에는 일반적으로 여러 환경을 설정하고 관리하는 작업이 포함됩니다.
Firebase는 개발자 워크플로 및 구성요소 환경에 대한 다양한 지원 수준을 제공합니다. 이 페이지의 개발자 워크플로 용어와 가정을 숙지한 후 일반 권장사항 및일반 보안 가이드라인(Firebase 프로젝트 및 앱 설정)을 확인하세요.
환경 정보
소프트웨어 개발에서 환경은 애플리케이션 또는 애플리케이션 시스템의 인스턴스를 실행하는 데 필요한 모든 하드웨어 및 소프트웨어입니다.
일련의 환경은 사용자에게 영향을 미치지 않고 소프트웨어 개발 및 테스트를 위한 격리를 제공합니다. 아래 다이어그램과 같이 상위 수준의 환경은 사전 프로덕션 또는 프로덕션으로 간주되며 사전 프로덕션 환경은 필요한 만큼 최대한 많이 사용할 수 있습니다. 또한 각 환경 유형과 관련된 일반적인 관행과 기능도 설명합니다.
이러한 환경을 통해 기능이나 출시를 처리하는 프로세스를 배포 파이프라인이라고 합니다.
환경 유형
환경은 애플리케이션, 코드, 데이터를 실행하고 지원해야 하는 기본 인프라로 구성됩니다. 다음 각 용어를 확장하여 각 환경 유형에 사용되는 데이터 유형에 관한 팁 등 일반적인 환경에 대한 설명을 검토하세요.
개발(dev) 환경
모든 개발자는 개발 환경, 즉 빌드 중인 변경사항을 테스트할 수 있는 안전하고 격리된 공간이 필요합니다. 팀의 모든 개발자가 자체 개발 환경에 액세스하는 것이 이상적입니다. 또한 개발 환경이 로컬 인스턴스인 경우 개발자는 훨씬 더 빠르게 반복할 수 있습니다.
개발 환경의 데이터는 일반적으로 프로덕션 데이터와 유사하지만 실제 사용자의 데이터를 포함해서는 안 됩니다. 매우 긴 문자열과 같이 과거에 버그를 유발한 데이터도 포함될 수 있습니다.
테스트 및 QA 환경
자동 테스트가 필요한 경우 이러한 테스트를 실행할 환경이 필요하며 테스트 환경을 가동할 때마다 데이터를 재설정해야 합니다.
QA 엔지니어가 있다면 모두 사용하는 하나의 환경이 필요하거나 새 출시 버전 후보를 테스트하는 데 개별 환경이 필요할 수 있습니다.
테스트 및 QA 환경의 데이터에는 일반적으로 프로덕션 데이터를 잘 나타내는 품질 데이터와 함께, 예전에 버그를 발생시킨 데이터의 특수한 경우와 사례를 나타내는 데이터로 시드됩니다.
스테이징 환경
프로덕션 환경에서 출시 버전이 작동하는 방식을 현실적으로 테스트하려면 프로덕션 인프라를 최대한 모방하는 스테이징 환경이 필요합니다. 구체적인 통합을 개별적으로 테스트해야 하는 경우 스테이징 인스턴스가 여러 개 있는 것이 일반적입니다.
스테이징과 프로덕션의 일반적인 차이점은 다음과 같습니다.
스테이징에는 부작용을 일으킬 수 있는 일부 기능 또는 통합이 누락될 수 있습니다. 예를 들어 스테이징이 이메일을 보내지 않도록 설정할 수 있습니다.
스테이징에는 익명처리된 데이터가 있을 수 있습니다. 데이터는 가짜일 수 있지만 현실적이어야 합니다. 스테이징은 문제를 안전하게 디버그하는 공간이므로 프로덕션 데이터보다 스테이징 데이터에 광범위한 팀 액세스 권한을 부여할 수 있습니다. 따라서 사용자 개인 정보 보호를 위해 스테이징에 실제 사용자 데이터를 사용해서는 안 됩니다.
프로덕션(prod) 환경
유지관리하는 애플리케이션마다 하나의 프로덕션 환경이 필요합니다. 이것은 사용자가 상호작용하는 인스턴스입니다.
데이터를 변경, 삭제 또는 다시 만들 수 있는 다른 환경과 달리 프로덕션 환경의 데이터는 매우 중요합니다. 프로덕션 데이터를 분실하거나 변경하면 사용자에게 직접 영향을 미칩니다.
Firebase 콘솔에서 프로덕션 환경과 연결된 Firebase 프로젝트에 "production" 환경 유형으로 태그를 지정하는 것이 좋습니다. 이 태그를 사용하면 팀원에게 변경사항이 연결된 프로덕션 앱과 데이터에 영향을 줄 수 있음을 알릴 수 있습니다.
다음 단계
Firebase 프로젝트 설정에 관한 일반적인 권장사항을 검토합니다. 이 가이드에서는 Firebase 프로젝트 계층 구조, 앱 변형 버전 등록 방법, 멀티테넌시와 관련된 질문에 대해 답합니다.
다양한 환경의 일반 보안 가이드라인을 검토합니다. 각 환경과 데이터가 안전한지 확인하려고 합니다.
[null,null,["최종 업데이트: 2025-08-04(UTC)"],[],[],null,["For production apps, you need to set up a clear development workflow, especially\nif you have more than one person working on your app. A development workflow\nusually involves setting up and managing multiple environments.\n\nFirebase has varying levels of support for developer workflows and the\nconstituent environments. Once you're familiar with the developer workflow terms\nand assumptions on this page, check out our\n[general best practices](/docs/projects/dev-workflows/general-best-practices)\nand\n[general security guidelines](/docs/projects/dev-workflows/general-security-guidelines)\nfor setting up a Firebase project and your apps.\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\nAbout environments\n\nIn software development, an ***environment*** is all the hardware and software\nthat are required to run an instance of an application or system of\napplications.\n\nA series of environments provides isolation for developing and testing software\nwithout impacting users. As shown in the diagram below, environments at a\nhigh-level are considered either *pre-production* or *production* , and you can\nhave as many pre-production environments as needed. The diagram also describes\ncommon practices and features associated with each\n[type of environment](#types).\n\nThe process of progressing a feature or release through these environments to\nproduction is called a ***deployment pipeline***.\n\nTypes of environments\n\nAn environment is composed of the underlying infrastructure that you need to run\nand support your application, its code, and its data. Expand each of the\nfollowing terms to review descriptions of some common environments, including\ntips on the types of data used in each environment type.\n| **Key Point:** Every app should have at least one *pre-production* environment that's isolated from production data and resources.\n\n\u003cbr /\u003e\n\n**Development (dev) environments**\n\n\u003cbr /\u003e\n\nEvery developer needs a development environment --- a safe, isolated place to test\nchanges as they're being built. Ideally, every developer on your team has access\nto their own dev environment. Also, if the dev environment is a local instance,\na developer can iterate much faster.\n\nThe data in a dev environment is seeded with data that generally resembles the\nproduction data, but should never contain any real users' data. It may also\ncontain data that has caused bugs in the past, like very long strings.\n\n\u003cbr /\u003e\n\n\u003cbr /\u003e\n\n\u003cbr /\u003e\n\n**Test and QA environments**\n\n\u003cbr /\u003e\n\nIf you have automated tests, you need an environment in which to run those\ntests, and you need to reset the data each time you spin up the test\nenvironment.\n\nIf you have QA engineers, they may need one environment that they all use, or\nthey may need individual environments to test a new release candidate.\n\nThe data in test and QA environments is seeded with quality data that's\ngenerally representative of the production data, along with data that represents\ncorner cases and examples of data that have caused bugs in the past.\n\n\u003cbr /\u003e\n\n\u003cbr /\u003e\n\n\u003cbr /\u003e\n\n**Staging environments**\n\n\u003cbr /\u003e\n\nFor realistic tests of how a release will work in production, you need a staging\nenvironment that mimics production infrastructure as closely as possible. It's\ncommon to have multiple staging instances if you need to test specific\nintegrations in isolation.\n\nHere are common differences between staging and prod:\n\n- Staging may be missing some features or integrations that could cause side\n effects. For example, staging may be set to not send email.\n\n- Staging may have anonymized data; the data can be fake, but it should be\n realistic. Because staging is a place to safely debug problems, you might give\n broader team access to staging data than production data. So, to protect user\n privacy, you shouldn't use actual user data in staging.\n\n\u003cbr /\u003e\n\n\u003cbr /\u003e\n\n\u003cbr /\u003e\n\n**Production (prod) environments**\n\n\u003cbr /\u003e\n\nFor each application that you maintain, you need a single production\nenvironment. This is the instance with which your users interact.\n\nUnlike the other environments where you can change, delete, and/or recreate\ndata, the data in your prod environment is very important; losing or altering\nyour prod data will directly affect your users.\n\nIn the Firebase console, we recommend tagging the Firebase project associated\nwith your production environment as a\n[\"production\" environment type](/support/faq#set-environment-type). This tag\ncan help remind you and your teammates that any changes could affect your\nassociated production apps and their data.\n\n\u003cbr /\u003e\n\n\u003cbr /\u003e\n\n| **Tip** : Integrations with analytics services, including Google Analytics, often require special attention when you're setting up a new environment. You also don't want your tests from pre-production environments to impact production analytics.\n|\n| We recommend not setting up analytics for most pre-production environments,\n| unless you want to specifically test analytics integrations, like making\n| sure the right parameters are being sent to your analytics service.\n\nNext steps\n\n- Review our [general best practices](/docs/projects/dev-workflows/general-best-practices)\n for setting up Firebase projects. This guide answers questions about Firebase\n project hierarchy, how to register your app variants, and multi-tenancy.\n\n- Review the [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)."]]
