Firebase Remote Config은 서버에서 새 값을 가져와 앱에서 활성화하는 방법과 시기를 원하는 대로 설정하는 기능을 제공하므로 구성을 시각적으로 변경하는 시기를 제어하여 우수한 최종 사용자 환경을 보장할 수 있습니다. fetchAndActivate()를 사용하여 애플리케이션 실행 시 새 값을 가져올 수 있으며, 실시간 Remote Config을 보완 메서드로 사용해서 Remote Config의 버전이 게시된 후 최신 파라미터 값을 자동으로 가져올 수 있습니다.
이 가이드에서는 몇 가지 로딩 전략을 살펴보고 앱에 가장 적합한 옵션을 선택하기 위해 주로 고려할 사항을 설명합니다.
전략 1: 로드 시 가져와 활성화
이 전략에서는 앱을 처음 시작할 때 fetchAndActivate()를 호출하여 Remote Config에서 새 값을 가져와 로드가 완료되는 즉시 활성화합니다. 이 간단한 방식은 UI 모양이 크게 변경되지 않는 구성 변경에 적합하지만, 사용자가 사용하는 동안 UI가 눈에 띄게 변경될 수 있는 상황에서는 사용하지 말아야 합니다.
앱이 fetchAndActivate()를 호출한 후 addOnConfigUpdateListener를 호출하여 실시간으로 매개변수 값 업데이트 리슨을 시작할 수 있습니다. 이 메서드는 매개변수 값에 대한 서버 측 업데이트 리슨을 시작하고 자동으로 가져온 후 리스너를 호출합니다. 간단한 전략으로 리스너에서 새 값을 활성화할 수 있습니다. 그러나 fetchAndActivate()에서 언급했듯이 민감한 UI의 경우 즉시 활성화하지 않는 것이 좋습니다.
전략 2: 로딩 화면 뒤에서 활성화
전략 1에서 발생할 수 있는 잠재적인 UI 문제를 해결하기 위해 로딩 화면을 사용할 수 있습니다. 앱을 즉시 시작하지 않고 로딩 화면을 표시하고 완료 핸들러에서 fetchAndActivate를 호출합니다.
그런 다음 즉시 콜백 또는 알림을 다시 사용하여 로딩 화면을 닫고 사용자가 앱과 상호작용을 시작할 수 있도록 합니다.
이 전략을 사용하는 경우 로딩 화면에 제한 시간을 추가하는 것이 좋습니다. 우수한 앱 시작 환경을 기대하는 사용자에게 원격 구성의 제한 시간 1분은 너무 길 수도 있습니다.
이 전략에서는 addOnConfigUpdateListener를 호출하여 실시간 Remote Config 업데이트를 리슨하는 것이 좋습니다. 로딩 화면이 표시될 때 리스너를 추가한 다음 Remote Config 값으로 인해 눈에 띄게 변경되지 않을 앱의 하나 이상의 지점에서 activate()를 사용합니다.
전략 3: 다음 시작 시 새 값 로드
효과적인 전략으로 새 구성 값을 로드하여 앱의 다음 시작 시 활성화하는 방법이 있습니다. 이 전략에서 앱은 시작 시 가져온 값을 활성화한 후 새 값을 가져오며 새 구성 값을 이미 가져왔더라도 아직 활성화하지 않았다고 가정하고 작동합니다. 이 전략의 작업 순서는 다음과 같습니다.
시작 시 이전에 가져온 값을 즉시 활성화합니다. 이전 세션에서 서버로부터 다운로드한 모든 값을 적용하며 이 과정이 거의 즉각적으로 이루어집니다.
사용자가 앱과 상호작용하는 동안 가져오기 간격 최솟값(기본값)에 따라 비동기 호출을 시작하여 새 값을 가져오고 실시간 구성 업데이트 리스너를 추가합니다. 실시간 리스너는 앱이 실행되는 동안 서버에 게시된 모든 값을 자동으로 가져옵니다.
실시간 업데이트는 가져오기 간격 최솟값 설정을 우회합니다.
가져오기 호출의 완료 핸들러 또는 콜백에서는 아무 작업도 하지 않습니다.
앱은 다운로드한 값을 다음에 앱을 시작하여 활성화할 때까지 그대로 유지합니다.
이 전략에서는 사용자 대기 시간이 크게 줄어들지만 앱 수명 주기에서 필요에 따라 가져오기 및 실시간 리스너 전략을 activate() 호출과 결합하면 사용자가 앱과 상호작용할 때 Remote Config의 최신 값을 사용할 수 있습니다.
피해야 할 로딩 전략
위에서 설명한 로딩 전략의 장단점에서 알 수 있듯이 피해야 할 몇 가지 사용 패턴이 있습니다.
방금 종료한 프로모션과 관련된 옵션을 삭제하는 것과 같이 분명한 앱 또는 비즈니스 이유가 있는 경우 외에는 사용자가 UI를 보거나 상호작용하는 동안 UI 모양을 업데이트하거나 전환하지 마세요.
동시 가져오기 요청을 대량으로 보내지 마세요. 서버에서 앱을 제한할 수 있습니다. 업데이트를 자주 가져와야 하는 경우 실시간 Remote Config을 사용하세요. 대부분의 프로덕션 시나리오에서는 제한이 발생할 위험이 적지만 개발 과정 중에는 문제가 될 수 있습니다. 실시간 Remote Config은 이러한 사용 사례에 맞게 설계되었습니다. 제한 안내를 확인하세요.
Remote Config 값을 가져올 때 네트워크 연결에 의존하지 마세요.
인앱 파라미터 기본값을 설정하여 앱이 항상 예상대로 동작하도록 합니다. 다운로드한 템플릿 기본값을 사용하여 주기적으로 앱 및 Remote Config 백엔드 기본값을 동기화할 수 있습니다.
다음 단계
이 3가지 기본 전략으로 구성 값을 로드하는 모든 방법을 나타낼 수는 없습니다. 필요에 따라 훨씬 정교한 전략을 고안할 수 있습니다.
구성 값을 가져오고 활성화하는 특정 호출에 대해 자세히 알아보려면 플랫폼별 API 참조를 확인하세요.
[[["이해하기 쉬움","easyToUnderstand","thumb-up"],["문제가 해결됨","solvedMyProblem","thumb-up"],["기타","otherUp","thumb-up"]],[["필요한 정보가 없음","missingTheInformationINeed","thumb-down"],["너무 복잡함/단계 수가 너무 많음","tooComplicatedTooManySteps","thumb-down"],["오래됨","outOfDate","thumb-down"],["번역 문제","translationIssue","thumb-down"],["샘플/코드 문제","samplesCodeIssue","thumb-down"],["기타","otherDown","thumb-down"]],["최종 업데이트: 2025-09-04(UTC)"],[],[],null,["\u003cbr /\u003e\n\nFirebase Remote Config provides lots of flexibility for how and when to\nfetch new values from the server and activate them in your app, allowing you to\nensure a quality end user experience by controlling the timing of any visible\nconfiguration changes. You can fetch new values on application launch using\n`fetchAndActivate()`, and use\n[real-time Remote Config](/docs/remote-config#how_it_works)\nas a complementary method to automatically fetch the latest parameter values\nafter a new version of your Remote Config is published.\n\nThis guide looks at a few loading strategies and\ndiscusses key considerations for picking the best option for your app.\n\nStrategy 1: Fetch and activate on load\n\nIn this strategy, your app would call `fetchAndActivate()` when your app first\nstarts up to fetch new values from Remote Config and activate them as soon\nas they are done loading. This simple approach works well for configuration\nchanges that don't cause\nany dramatic visual changes in your UI. It should be\navoided in any situation where your UI could change noticeably\nwhile users are in the middle of using it.\n\nAfter your app calls `fetchAndActivate()`, it can start listening for parameter\nvalue updates in real time by calling `addOnConfigUpdateListener`. This method\nstarts listening for any server-side updates to parameter values, fetches them\nautomatically, then calls the listener. A simple strategy is to activate the new\nvalues in the listener. However, as mentioned for `fetchAndActivate()`,\nactivating immediately should be avoided for sensitive UIs.\n\nStrategy 2: Activate behind loading screen\n\nAs a remedy to the potential UI issue encountered in strategy 1, you could rely\non a loading screen. Instead of starting up your app right away, show a loading\nscreen and call `fetchAndActivate` in your completion handler.\nThen right after that --- again using a callback or a notification\n--- dismiss the loading screen and allow the user to start interacting with\nyour app.\n\nIf you use this strategy, it's recommended to add a timeout to the loading\nscreen. Remote Config's\none-minute timeout may be too long for a quality app startup experience for\nusers.\n\nListening for real-time Remote Config updates by calling\n`addOnConfigUpdateListener` works well with this strategy. Add the listener when\nthe loading screen is displayed, then use `activate()` at one or more points in\nyour app where Remote Config values won't cause dramatic visual changes.\n| **Note:** If you are loading values for an [A/B Testing](/docs/ab-testing/abtest-config) experiment, this strategy is very strongly recommended. With A/B Testing, additional time is required as the user is placed into an experiment and the experimental values are applied.\n\nStrategy 3: Load new values for next startup\n\nAn effective strategy is to load new configuration values to\nactivate on your app's *next* startup. In this strategy, your app activates\nfetched values on startup before attempting to fetch new ones, operating on the\nassumption that it may have already fetched --- but not yet activated\n--- new configuration values. The order of operations for this strategy is:\n\n1. On startup, immediately activate previously fetched values. This applies any values you've downloaded from the server in a previous session, and is nearly instantaneous.\n2. While the user interacts with your app, kick off an asynchronous call to fetch new values according to the default minimum fetch interval and add a real-time config update listener. The real-time listener will automatically fetch any values that are published on the server while your app is running. Real-time updates bypass the minimum fetch interval setting.\n3. In the completion handler or callback for the fetch call, do nothing. Your app will keep the downloaded values until you activate them the next time the app starts.\n\nWith this strategy, user wait time is greatly minimized. Combining the fetch\nand real-time listener strategies with `activate()` calls as needed in the app lifecycle makes sure users\nhave the latest values from Remote Config as they interact with your app.\n| **Tip:** Use `fetch()` and `addOnConfigUpdateListener()` as complementary methods. It's recommended to call fetch once per app launch, then start listening for updates in real time and activate them as needed. Listening for real-time updates makes it possible to get the latest parameter values without calling fetch frequently.\n\nLoading anti-strategies\n\nAs you may have understood from the above discussion of loading pros and cons,\nthere are a couple of usage patterns to avoid.\n\n- **Don't** update or switch aspects of the UI while the user is viewing or interacting with it --- *unless* you have strong app or business reasons for doing so, like removing options related to a promotion that has just ended.\n- **Don't** send mass numbers of simultaneous fetch requests, which could result in the server throttling your app. If you need to fetch updates frequently, use [real-time Remote Config](/docs/remote-config#how_does_it_work). While the risk of throttling is low in most production scenarios, it can be an issue during active development---and real-time Remote Config is designed for this use case. Check out the [throttling\n guidance](/docs/remote-config/get-started#throttling).\n- **Don't** rely on network connectivity to obtain Remote Config values. **Do** set in-app default parameter values so that your app always behaves as expected. You can periodically keep app and Remote Config backend default values in sync using [downloaded template\n defaults](/docs/remote-config/templates#download_template_defaults).\n\nNext steps\n\nThese three basic strategies do not by any means comprise a complete list of the\nways to load configuration values. Depending on your needs, you could devise\nmuch more sophisticated strategies.\n\nCheck out the API reference for your platform to learn more about the specific\ncalls for fetching and activating configuration values."]]
