Firebase Hosting 에뮬레이터는 Hosting 서비스의 충실도 높은 로컬 에뮬레이션을 제공하며 프로덕션 Hosting의 기능을 대부분 제공합니다. Hosting 에뮬레이터를 사용하면 다음 작업을 할 수 있습니다.
스토리지 또는 액세스 비용 발생 없이 정적 사이트 및 웹 앱의 프로토타입 제작
호스팅 사이트에 배포하기 전에 HTTPS 함수 프로토타입 제작, 테스트, 디버그
컨테이너화된 지속적 통합 워크플로에서 사이트와 웹 앱 테스트
Firebase 프로젝트 선택
Firebase Local Emulator Suite은 단일 Firebase 프로젝트의 제품을 에뮬레이션합니다.
에뮬레이터를 시작하기 전에 사용할 프로젝트를 선택하려면 CLI로 작업 디렉터리에서 firebase use를 실행합니다. 또는 --project 플래그를 각 에뮬레이터 명령어에 전달합니다.
Local Emulator Suite은 실제 Firebase 프로젝트 및 데모 프로젝트의 에뮬레이션을 지원합니다.
프로젝트 유형
특징
에뮬레이터와 함께 사용
실제
실제 Firebase 프로젝트는 주로 Firebase 콘솔을 통해 만들고 구성한 프로젝트입니다.
실제 프로젝트에는 데이터베이스 인스턴스, 스토리지 버킷, 함수 또는 해당 Firebase 프로젝트에 설정한 기타 리소스와 같은 라이브 리소스가 있습니다.
실제 Firebase 프로젝트로 작업할 때는 지원되는 제품 일부 또는 전부를 에뮬레이션할 수 있습니다.
에뮬레이션하지 않는 제품의 경우 앱과 코드가 데이터베이스 인스턴스, 스토리지 버킷, 함수 등 라이브 리소스와 상호작용합니다.
데모
데모 Firebase 프로젝트에는 실제 Firebase 구성이 없으며 라이브 리소스도 없습니다. 이러한 프로젝트는 일반적으로 Codelab 또는 기타 튜토리얼을 통해 액세스합니다.
데모 프로젝트의 프로젝트 ID에는 demo- 프리픽스가 있습니다.
데모 Firebase 프로젝트로 작업할 때는 앱과 코드가 에뮬레이터와만 상호작용합니다. 앱이 에뮬레이터에서 실행 중이지 않은 리소스와 상호작용하려고 하면 코드가 실패합니다.
가능한 한 데모 프로젝트를 사용하는 것이 좋습니다. 장점은 다음과 같습니다.
손쉬운 설정: Firebase 프로젝트를 만들지 않고도 에뮬레이터를 실행할 수 있습니다.
강력한 안전성: 코드에서 실수로 에뮬레이션되지 않은(프로덕션) 리소스를 호출하더라도 데이터 변경, 사용, 청구 등이 발생할 가능성이 없습니다.
오프라인 지원 향상: SDK 구성을 다운로드하기 위해 인터넷에 액세스할 필요가 없습니다.
핵심 프로토타입 제작 워크플로
빠르게 반복 작업을 수행하거나 앱이 에뮬레이션된 백엔드 프로젝트 리소스와 상호작용하도록 하려면 Hosting 콘텐츠 및 구성을 로컬로 테스트할 수 있습니다. 로컬로 테스트할 때 Firebase는 웹 앱을 로컬로 호스팅된 URL로 제공합니다.
(선택사항) 기본적으로 로컬로 호스팅된 앱은 에뮬레이션된 것이 아니라 실제 프로젝트 리소스(함수, 데이터베이스, 규칙 등)와 상호작용합니다.
그 대신 선택적으로 사용자가 구성한 에뮬레이션된 프로젝트 리소스를 사용하도록 앱을 연결할 수 있습니다. 자세히 알아보기:
Realtime Database |
Cloud Firestore |
Cloud Functions
로컬 프로젝트 디렉터리의 루트에서 다음 명령어를 실행합니다.
firebase emulators:start
CLI에서 반환된 로컬 URL로 웹 앱을 엽니다(일반적으로 http://localhost:5000).
변경사항으로 로컬 URL을 업데이트하기 위해 브라우저를 새로고침합니다.
다른 로컬 기기에서 테스트
기본적으로 에뮬레이터는 localhost의 요청에만 응답합니다. 즉, 컴퓨터의 웹브라우저에서는 호스팅된 콘텐츠에 액세스할 수 있지만 네트워크의 다른 기기에서는 액세스할 수 없습니다. 다른 로컬 기기에서 테스트하려면 firebase.json을 다음과 같이 구성합니다.
지속적 통합 워크플로가 Firebase 호스팅을 사용하는 경우 firebase emulators:exec를 실행하려면 토큰을 사용하여 로그인해야 합니다. 다른 에뮬레이터에는 로그인이 필요하지 않습니다.
토큰을 생성하려면 로컬 환경에서 firebase login:ci를 실행합니다. 이 작업은 CI 시스템에서 수행하면 안 됩니다. 안내에 따라 인증하세요.
토큰은 빌드 간에 유효하므로 프로젝트당 한 번만 수행하면 됩니다. 토큰은 비밀번호처럼 비밀로 유지해야 합니다.
CI 환경에서 빌드 스크립트에 사용할 수 있는 환경 변수를 지정할 수 있으면 값이 액세스 토큰 문자열인 FIREBASE_TOKEN이라는 환경 변수를 만들면 됩니다. Firebase CLI가 자동으로 FIREBASE_TOKEN 환경 변수를 선택하고 에뮬레이터가 올바르게 시작됩니다.
마지막 수단으로 빌드 스크립트에 토큰을 포함할 수 있지만 신뢰할 수 없는 사용자가 액세스할 수 없도록 해야 합니다. 이 하드 코딩된 방식의 경우 firebase emulators:exec 명령어에 --token "YOUR_TOKEN_STRING_HERE"를 추가할 수 있습니다.
[null,null,["최종 업데이트: 2025-08-12(UTC)"],[],[],null,["\u003cbr /\u003e\n\nBefore you start prototyping and testing your web app with the\nFirebase Hosting emulator, make sure that you [understand the overall Firebase Local Emulator Suite workflow](/docs/emulator-suite/connect_and_prototype?database=Firestore),\nand that you [install and configure](/docs/emulator-suite/install_and_configure)\nthe Local Emulator Suite and review its [CLI commands](/docs/emulator-suite/install_and_configure#startup).\n\nYou should also be familiar with the features and implementation workflow\nfor Firebase Hosting. Start with the\n[introduction to Firebase Hosting](/docs/hosting).\n\nWhat can I do with the Firebase Hosting emulator?\n\nThe Firebase Hosting emulator provides high-fidelity local emulation of\nHosting services, providing much of the functionality found in\n[production Hosting](/docs/hosting/quickstart). The Hosting emulator\nlets you:\n\n- Prototype your static sites and web apps without incurring storage or access charges\n- Prototype, test and debug HTTPS functions before deploying to your Hosting site\n- Test sites and web apps in containerized, continuous integration workflows.\n\nChoose a Firebase project\n\nThe Firebase Local Emulator Suite emulates products for a single Firebase project.\n\nTo select the project to use, before you start the emulators, in the CLI run\n`firebase use` in your working directory. Or, you can pass\nthe `--project` flag to each emulator\ncommand.\n| **Note:** It's generally a good practice to use one project ID for all emulator invocations, so the Emulator Suite UI, different product emulators, and all running instances of a particular emulator can communicate correctly in all cases. In fact, by default, the Local Emulator Suite will warn on detecting multiple project IDs in use, though you can override this behavior. For guidance on setting and managing project IDs, see the [Installation and configuration guide](/docs/emulator-suite/install_and_configure#project_id_configuration).\n\nLocal Emulator Suite supports emulation of *real* Firebase projects and\n*demo* projects.\n\n| Project type | Features | Use with emulators |\n|--------------|-------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------|------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------|\n| Real | A real Firebase project is one you created and configured (most likely via the Firebase console). Real projects have live resources, like database instances, storage buckets, functions, or any other resource you set up for that Firebase project. | When working with real Firebase projects, you can run emulators for any or all of the supported products. For any products you are not emulating, your apps and code will interact with the *live* resource (database instance, storage bucket, function, etc.). |\n| Demo | A demo Firebase project has no *real* Firebase configuration and no live resources. These projects are usually accessed via codelabs or other tutorials. Project IDs for demo projects have the `demo-` prefix. | When working with demo Firebase projects, your apps and code interact with emulators *only*. If your app attempts to interact with a resource for which an emulator isn't running, that code will fail. |\n\nWe recommend you use demo projects wherever possible. Benefits include:\n\n- Easier setup, since you can run the emulators without ever creating a Firebase project\n- Stronger safety, since if your code accidentally invokes non-emulated (production) resources, there is no chance of data change, usage and billing\n- Better offline support, since there is no need to access the internet to download your SDK configuration.\n\n| **Note:** If you want to emulate cross-service interactions such as database-triggered Cloud Functions or Rules that rely on Authentication you must make sure that the project ID in your code (in `initializeApp()`, etc.) matches the project ID used by the Firebase CLI.\n\nCore prototyping workflow\n\nIf you're making quick iterations or you want your app to interact with\nemulated backend project resources, you can test your Hosting content and\nconfig locally. When testing locally, Firebase serves your web app at a locally\nhosted URL.\n\n1. *(Optional)* By default, your locally hosted app will interact with *real* ,\n not *emulated* , project resources (functions, database, rules, etc.).\n You can instead optionally connect your app to use any *emulated* project\n resources that you've configured. Learn more:\n [Realtime Database](/docs/emulator-suite/connect_and_prototype?database=RTDB) \\|\n [Cloud Firestore](/docs/emulator-suite/connect_and_prototype?database=Firestore) \\|\n [Cloud Functions](/docs/emulator-suite/connect_functions)\n\n2. From the root of your local project directory, run the following command:\n\n ```\n firebase emulators:start\n ```\n3. Open your web app at the local URL returned by the CLI (usually\n `http://localhost:5000`).\n\n4. To update the local URL with changes, refresh your browser.\n\nTest from other local devices\n\nBy default, the emulators only respond to requests from `localhost`. This\nmeans that you'll be able to access your hosted content from your computer's web\nbrowser but not from other devices on your network. If you'd like to test from\nother local devices, configure your `firebase.json` like so: \n\n \"emulators\": {\n // ...\n\n \"hosting\": {\n \"port\": 5000,\n \"host\": \"0.0.0.0\"\n }\n }\n\nGenerate auth tokens for continuous integration workflows\n\nIf your continuous integration workflows rely on Firebase Hosting, then you will\nneed to log in using a token in order to run `firebase emulators:exec`. The\nother emulators do not require login.\n| **Note:** If you have configured hosting in `firebase.json` but do not need it in CI test setups, use the `--only` flag to `emulators:start` or `emulators:exec` to include only the emulators that you need.\n\nTo generate a token, run `firebase login:ci` on your local environment; this\nshould not be performed from a CI system. Follow instructions to authenticate.\nYou should only need to perform this step once per project, since the token will\nbe valid across builds. The token should be treated like a password; make sure\nit is kept secret.\n\nIf your CI environment allows you to specify environment variables that can be\nused in the build scripts, simply create an environment variable called\n`FIREBASE_TOKEN`, with the value being the access token string. The\nFirebase CLI will automatically pick up the `FIREBASE_TOKEN` environment\nvariable and the emulators will start properly.\n\nAs a last resort, you can simply include the token in your build script, but\nmake sure that untrusted parties do not have access. For this hard-coded\napproach, you can add `--token \"YOUR_TOKEN_STRING_HERE\"` to the\n`firebase emulators:exec` command.\n\nWhat next?\n\n- Run a quickstart using the Hosting emulator by following the [Firebase web\n codelab](/codelabs/firebase-web).\n- Understand how to prototype HTTPS functions using the Hosting emulator as described in the [Hosting guides for functions](/docs/hosting/functions).\n- For a curated set of videos and detailed how-to examples, follow the [Firebase Emulators Training Playlist](/learn/pathways/firebase-emulators)."]]
