플러터(Flutter) 앱, 개발과 운영 환경 완벽 분리하기 (Android & iOS)

하나의 코드로 안드로이드와 iOS 앱을 모두 만드는 플러터의 매력은 대단합니다. 하지만 개발 과정이 복잡해지면서 여러 난관에 부딪히게 됩니다. 그중 가장 대표적인 것이 바로 개발(Development), 스테이징(Staging), 운영(Production) 환경을 분리하는 문제입니다. 혹시 모든 환경에서 동일한 API 서버 주소를 사용하고 계신가요? 개발용 앱의 이름과 아이콘이 실제 출시용과 같아서 혼동을 겪고 있진 않으신가요? 개발용 테스트 데이터를 운영 DB에 전송하는 아찔한 실수를 경험한 적은 없으신가요?

이러한 문제들은 단순히 실수를 유발하는 것을 넘어, 서비스의 안정성을 심각하게 위협할 수 있습니다. 예를 들어, 개발 환경에서는 테스트 결제 모듈을 사용해야 하는데, 설정이 분리되지 않아 실제 결제가 일어나거나, 운영 환경의 사용자 데이터가 개발 중인 앱으로 유출될 수도 있습니다. 이 모든 문제를 해결하는 열쇠는 바로 '환경 분리'에 있습니다.

이 글에서는 플러터 프로젝트에서 네이티브 기능을 활용하여 안드로이드와 iOS의 개발, 운영 환경을 완벽하게 분리하는 방법을 A부터 Z까지 상세하게 다룹니다. 안드로이드의 Product Flavors와 iOS의 Xcode Schemes를 사용하여 각 환경에 맞는 앱 이름, 아이콘, API 주소, 서버 키 등을 설정하는 구체적인 방법을 코드와 함께 살펴보겠습니다. 이 가이드를 끝까지 따라오시면, 더 이상 환경 설정 문제로 골머리를 앓지 않고 안정적이고 효율적인 개발 프로세스를 구축할 수 있게 될 것입니다.

1. 왜 환경 분리가 필수적인가?

본격적인 설정에 앞서, 왜 이렇게까지 환경을 분리해야 하는지 그 중요성을 다시 한번 짚고 넘어가겠습니다. 개발자라면 누구나 공감할 만한 몇 가지 시나리오가 있습니다.

• API 엔드포인트 관리: 개발 서버는 `dev-api.myapp.com`, 운영 서버는 `api.myapp.com`을 사용해야 합니다. 코드를 배포할 때마다 이 주소를 수동으로 변경하는 것은 번거로울 뿐만 아니라, 실수할 가능성이 매우 높습니다.
• 앱 이름 및 아이콘: 하나의 기기에 개발용 앱과 운영용 앱을 동시에 설치하고 싶을 때가 많습니다. 패키지 이름이 같으면 앱이 덮어씌워지므로 불가능합니다. 또한, 앱 아이콘이나 이름으로 "My App (Dev)"와 같이 명확히 구분해주면 테스트 중 혼동을 방지할 수 있습니다.
• 인증 키 및 시크릿: Firebase, 각종 소셜 로그인, 결제 모듈 등 외부 서비스 연동 시 사용하는 API 키는 보통 개발용과 운영용이 다릅니다. 이 키들이 코드에 하드코딩되어 있거나 하나의 설정 파일에서 관리된다면, 보안에 취약하고 관리가 어렵습니다.
• 기능 플래그(Feature Flags): 특정 기능은 운영 환경에 배포하기 전에 내부 테스트용으로만 활성화하고 싶을 수 있습니다. 환경 분리를 통해 개발용 빌드에서만 특정 기능을 켜고 끌 수 있습니다.
• 로깅 및 분석: 개발 중 발생하는 수많은 로그나 분석 이벤트를 운영 환경의 분석 도구(e.g., Google Analytics, Firebase Analytics)로 보내는 것은 데이터를 오염시키고 분석을 어렵게 만듭니다. 개발용 빌드는 별도의 분석 프로젝트로 데이터를 보내도록 설정해야 합니다.

이처럼 환경 분리는 단순한 편의성 문제를 넘어, 프로젝트의 안정성, 보안, 생산성과 직결되는 핵심적인 개발 문화입니다. 이제 플러터에서 이 중요한 작업을 어떻게 수행하는지 본격적으로 알아보겠습니다. 먼저 안드로이드부터 시작합니다.

2. 안드로이드: Product Flavors로 환경 다루기

안드로이드에서는 Product Flavors라는 강력한 기능을 제공합니다. 이는 동일한 코드 베이스를 사용하면서도 앱의 패키지 이름, 아이콘, 리소스, 상수 값 등을 다르게 설정하여 여러 버전의 앱을 생성할 수 있게 해주는 Gradle의 기능입니다. 우리는 이 기능을 활용하여 `development`와 `production`이라는 두 가지 맛(Flavor)을 만들어 보겠습니다.

2.1. `android/app/build.gradle` 파일 설정

가장 먼저 해야 할 일은 안드로이드 모듈의 `build.gradle` 파일을 수정하여 우리가 사용할 Flavor들을 정의하는 것입니다. 프로젝트의 `android/app/build.gradle` 파일을 열어 `android { ... }` 블록을 찾으세요.

기본적으로 플러터 프로젝트에는 `buildTypes` (debug, profile, release)만 정의되어 있습니다. 여기에 `flavorDimensions`와 `productFlavors`를 추가해야 합니다.

1. `flavorDimensions` 추가: Flavor들을 그룹화하는 역할을 합니다. 여러 차원의 Flavor 그룹을 만들 수 있지만, 보통 환경 분리 용도로는 하나만 사용합니다. 우리는 'env' (environment)라는 이름의 dimension을 만들겠습니다.
2. `productFlavors` 블록 추가: 이 블록 안에 우리가 원하는 환경들, 즉 `development`와 `production`을 정의합니다.

아래 코드를 `android { ... }` 블록 내, `buildTypes { ... }` 블록 위쪽에 추가합니다.

// android/app/build.gradle

...
android {
    ...
    // 이 부분을 추가합니다.
    // 1. Flavor를 그룹화할 차원을 정의합니다.
    flavorDimensions "env"

    // 2. 각 Flavor의 구체적인 설정을 정의합니다.
    productFlavors {
        // 개발(development) 환경 Flavor
        development {
            dimension "env"
            // 개발용 앱은 패키지 이름 뒤에 .dev를 붙여 운영용과 구분합니다.
            applicationIdSuffix ".dev"
            // 개발용 앱은 버전 이름 뒤에 -dev를 붙입니다.
            versionNameSuffix "-dev"
            // resValue를 통해 개발용 앱 이름을 정의합니다.
            resValue "string", "app_name", "내 앱 (개발용)"
            // buildConfigField를 통해 Dart 코드에서 사용할 수 있는 상수를 만듭니다.
            buildConfigField "String", "BASE_URL", '"https://dev-api.example.com/"'
        }
        // 운영(production) 환경 Flavor
        production {
            dimension "env"
            // 운영용은 별도의 suffix를 사용하지 않거나, 필요 시 정의할 수 있습니다.
            // applicationIdSuffix ".prod" // 필요하다면
            resValue "string", "app_name", "내 앱"
            buildConfigField "String", "BASE_URL", '"https://api.example.com/"'
        }
    }

    buildTypes {
        ...
    }
}
...

android/app/build.gradle 파일에 flavorDimensions와 productFlavors를 추가한 모습

각 설정 항목의 의미를 자세히 살펴보겠습니다.

• dimension "env": 이 Flavor가 'env' 차원에 속한다는 것을 명시합니다. flavorDimensions에 선언된 이름과 일치해야 합니다.
• applicationIdSuffix ".dev": 매우 중요한 설정입니다. 기본 `applicationId` (예: `com.example.myapp`) 뒤에 `.dev`를 추가하여 최종 패키지 이름을 `com.example.myapp.dev`로 만듭니다. 이렇게 하면 운영용 앱(`com.example.myapp`)과 개발용 앱을 한 기기에 동시에 설치할 수 있습니다.
• versionNameSuffix "-dev": 버전 이름(예: `1.0.0`) 뒤에 `-dev`를 붙여 `1.0.0-dev`와 같이 표시합니다. 앱 정보에서 버전을 확인할 때 유용합니다.
• resValue "string", "app_name", "내 앱 (개발용)": 안드로이드 리소스 값을 코드로 생성합니다. 여기서는 `app_name`이라는 이름의 문자열 리소스를 "내 앱 (개발용)"이라는 값으로 동적으로 생성합니다. 이 값은 `AndroidManifest.xml`에서 `@string/app_name`으로 참조하여 앱의 이름을 변경하는 데 사용됩니다.
• buildConfigField "String", "BASE_URL", "...": 컴파일 시 `BuildConfig.java` 파일에 상수를 생성합니다. `타입`, `변수명`, `값` 순서로 지정합니다. 이렇게 생성된 상수는 네이티브 코드(Kotlin/Java)에서 `BuildConfig.BASE_URL`과 같이 직접 접근할 수 있으며, 나중에 Dart 코드에서도 이 값을 가져올 수 있습니다. API 주소나 중요한 키를 관리하는 핵심적인 방법입니다.

2.2. Flavor별 소스 폴더 생성

Gradle은 Flavor의 이름과 동일한 디렉터리를 소스 셋(Source Set)으로 인식합니다. 이를 이용해 Flavor별로 다른 리소스 파일(아이콘, 설정 파일 등)이나 소스 코드를 가질 수 있습니다.

프로젝트의 `android/app/src/` 경로 아래에, `build.gradle`에서 정의한 Flavor의 이름과 동일한 폴더를 생성합니다. 즉, `development`와 `production` 폴더를 만듭니다.

android
└── app
    └── src
        ├── main       (기존 폴더)
        ├── debug      (빌드 타입별 폴더)
        ├── profile    (빌드 타입별 폴더)
        ├── release    (빌드 타입별 폴더)
        ├── development (새로 생성한 Flavor 폴더)
        └── production  (새로 생성한 Flavor 폴더)

android/app/src 경로에 Flavor 이름과 동일한 폴더 생성

이렇게 폴더를 만들면 Gradle 빌드 시스템은 빌드 시 선택된 Flavor에 해당하는 폴더의 내용을 `main` 소스 셋과 병합합니다. 만약 `main`과 Flavor 폴더에 동일한 경로의 파일이 존재한다면, Flavor 폴더의 파일이 `main` 폴더의 파일을 덮어쓰게(override) 됩니다. 이 원리를 이용해 Flavor별로 다른 리소스를 제공할 수 있습니다.

2.3. Flavor별 리소스 제공하기 (앱 아이콘 예시)

가장 대표적인 활용 사례는 앱 아이콘을 분리하는 것입니다. 개발용 앱은 아이콘에 'DEV' 같은 표시를 추가하여 운영용 앱과 시각적으로 명확히 구분하는 것이 좋습니다.

먼저 `main` 폴더의 리소스 구조를 살펴봅니다. 앱 아이콘은 보통 `android/app/src/main/res/mipmap-*` 디렉터리에 `ic_launcher.png`라는 이름으로 존재합니다.

개발용 아이콘을 설정하려면, `development` 소스 폴더 안에 `main`과 동일한 구조로 `res` 폴더와 하위 폴더들을 만들고, 그 안에 개발용 아이콘 파일을 넣으면 됩니다.

1. 기존 `android/app/src/main/res` 폴더를 통째로 `android/app/src/development/` 폴더에 복사합니다. 이렇게 하면 모든 리소스의 기반을 `main`과 동일하게 시작할 수 있습니다.
2. `android/app/src/development/res/mipmap-*` 폴더들에 있는 `ic_launcher.png` 파일들을 개발용으로 디자인된 아이콘 파일로 교체합니다.

`development` 폴더에 `res` 폴더를 구성하여 Flavor별 리소스를 관리

이제 `flutter run --flavor development` 명령으로 앱을 빌드하면, Gradle은 `src/development/res`의 아이콘을 `src/main/res`의 아이콘보다 우선하여 사용하므로, 개발용 아이콘이 적용된 앱이 설치됩니다. 반면 `flutter run --flavor production`으로 빌드하면 `src/production` 폴더에는 아이콘 파일이 없으므로 `src/main/res`의 기본 아이콘이 사용됩니다.

같은 원리로, `strings.xml` 파일을 Flavor별로 다르게 제공하여 앱 이름을 변경하거나, `colors.xml`을 변경하여 Flavor별 테마 색상을 다르게 적용하는 등 무궁무진한 활용이 가능합니다.

2.4. (고급) Firebase 설정 파일 분리하기

Firebase를 사용하는 프로젝트라면 `google-services.json` 파일을 Flavor별로 분리해야 합니다. 개발용 Firebase 프로젝트와 운영용 Firebase 프로젝트를 따로 사용하는 것이 일반적이기 때문입니다.

방법은 매우 간단합니다.

1. 개발용 Firebase 프로젝트에서 다운로드한 `google-services.json` 파일을 `android/app/src/development/` 폴더에 위치시킵니다.
2. 운영용 Firebase 프로젝트에서 다운로드한 `google-services.json` 파일을 `android/app/src/production/` 폴더에 위치시킵니다.
3. 기존 `android/app/` 폴더에 있던 `google-services.json` 파일은 삭제해도 좋습니다.

이렇게만 하면 Gradle이 빌드 시 현재 Flavor에 맞는 폴더에서 `google-services.json` 파일을 자동으로 찾아 사용합니다. 더 이상 파일을 수동으로 교체할 필요가 없습니다.

3. iOS: Xcode Schemes로 환경 다루기

안드로이드에서 Product Flavors를 사용했다면, iOS에서는 Xcode Schemes와 Build Configurations의 조합으로 동일한 목표를 달성할 수 있습니다. 과정이 안드로이드보다 조금 더 수동적이지만 원리는 비슷합니다.

전체적인 흐름은 다음과 같습니다.

1. 환경별(development, production)로 Build Configuration을 생성합니다.
2. 환경별로 Scheme을 생성하고, 위에서 만든 Build Configuration과 연결합니다.
3. Scheme별로 다른 값을 가질 수 있도록 User-Defined Setting을 추가합니다. (예: 앱 이름, 번들 ID 접미사)
4. `Info.plist` 파일에서 이 User-Defined Setting을 참조하여 실제 앱 설정을 변경합니다.

3.1. Build Configurations 생성하기

1. Xcode에서 프로젝트의 `ios` 폴더를 엽니다. (`open ios/Runner.xcworkspace`)
2. 왼쪽 네비게이터에서 프로젝트 파일(`Runner`)을 선택하고, 중앙 에디터에서 PROJECT의 `Runner`를 선택합니다.
3. Info 탭을 선택하고, Configurations 섹션을 확인합니다. 기본적으로 `Debug`, `Profile`, `Release`가 있을 것입니다.
4. `+` 버튼을 눌러 "Duplicate 'Debug' Configuration"을 선택하고, 새 설정의 이름을 `Debug-development`로 지정합니다.
5. 같은 방식으로 "Duplicate 'Release' Configuration"을 선택하고 이름을 `Release-development`로 지정합니다.
6. `production` 환경을 위해서는 기존 `Debug`와 `Release`를 그대로 사용하거나, 명확성을 위해 `Debug-production`, `Release-production`으로 복제하여 만들어도 좋습니다. 여기서는 편의상 기존 설정을 `production` 용으로 간주하겠습니다.

이제 우리는 `Debug-development`, `Release-development`, `Debug`, `Release` 이렇게 4개의 Build Configuration을 갖게 되었습니다.

3.2. Xcode Schemes 생성 및 연결하기

Scheme은 앱을 빌드, 실행, 테스트, 아카이브할 때 어떤 Build Configuration을 사용할지 정의하는 하나의 '레시피'입니다. 우리는 `development`와 `production`이라는 두 개의 Scheme을 만들 것입니다.

1. Xcode 상단의 Scheme 선택 메뉴 (기본값은 `Runner`)를 클릭하고 "New Scheme..."을 선택합니다.
2. 새 Scheme의 이름을 `development`로 지정하고 OK를 누릅니다.
3. 다시 Scheme 메뉴를 클릭하고 "Manage Schemes..."를 선택합니다.
4. 방금 만든 `development` Scheme을 선택하고 "Edit..." 버튼을 클릭합니다.
5. 왼쪽 메뉴에서 각 액션(Run, Test, Profile, Analyze, Archive)을 선택하고, 오른쪽의 "Build Configuration"을 우리가 위에서 만든 `development`용 Configuration으로 매핑합니다.
   • Run: `Debug-development`
   • Test: `Debug-development`
   • Profile: `Release-development`
   • Analyze: `Debug-development`
   • Archive: `Release-development`
6. `Close`를 눌러 저장합니다.
7. 기존의 `Runner` Scheme은 `production` 환경을 위해 사용할 것입니다. 이름을 명확하게 `production`으로 변경해주는 것이 좋습니다. ("Manage Schemes..."에서 `Runner`를 더블클릭하여 이름 변경)
8. `production` Scheme을 편집하여 각 액션이 `Debug`와 `Release` Configuration을 올바르게 사용하고 있는지 확인합니다. (기본값이므로 보통은 수정할 필요가 없습니다.)

3.3. User-Defined Setting으로 환경별 값 설정하기

이제 각 환경별로 다른 앱 이름이나 번들 ID를 설정할 차례입니다. 이는 "User-Defined Setting"을 통해 변수를 만들고, Build Configuration별로 다른 값을 할당하는 방식으로 구현합니다.

1. Xcode에서 프로젝트 파일(`Runner`)을 선택하고, 이번에는 TARGETS의 `Runner`를 선택합니다.
2. Build Settings 탭을 선택합니다.
3. 에디터 상단의 `+` 버튼을 누르고 "Add User-Defined Setting"을 선택합니다.
4. 새 설정의 이름을 `APP_DISPLAY_NAME`이라고 지정합니다.
5. 방금 만든 `APP_DISPLAY_NAME` 설정의 왼쪽 화살표를 눌러 펼치면, 우리가 만든 Build Configuration별로 값을 입력할 수 있는 필드가 나타납니다.
   • `Debug-development`: `내 앱 (개발)`
   • `Release-development`: `내 앱 (개발)`
   • `Debug` (production용): `내 앱`
   • `Release` (production용): `내 앱`
6. 같은 방식으로 번들 ID를 구분하기 위한 `BUNDLE_ID_SUFFIX`라는 User-Defined Setting을 추가합니다.
   • `Debug-development`: `.dev`
   • `Release-development`: `.dev`
   • `Debug` (production용): (빈 값으로 둠)
   • `Release` (production용): (빈 값으로 둠)

3.4. `Info.plist`에서 설정 값 참조하기

마지막으로, 실제 앱 설정 파일인 `Info.plist`에서 위에서 만든 변수들을 사용하도록 수정해야 합니다.

1. Xcode 네비게이터에서 `Runner/Info.plist` 파일을 엽니다.
2. Bundle display name 키의 값을 `$(APP_DISPLAY_NAME)`으로 변경합니다.
3. Bundle identifier 키의 값을 `$(PRODUCT_BUNDLE_IDENTIFIER)$(BUNDLE_ID_SUFFIX)`로 변경합니다. (`PRODUCT_BUNDLE_IDENTIFIER`는 Xcode의 기본 변수입니다.)

이제 모든 설정이 끝났습니다. Xcode에서 `development` Scheme을 선택하고 빌드하면 `내 앱 (개발)`이라는 이름과 `.dev` 접미사가 붙은 번들 ID로 앱이 빌드됩니다. `production` Scheme을 선택하면 원래의 이름과 번들 ID로 빌드됩니다.

4. 플러터에서 환경별 설정 값 사용하기

지금까지는 네이티브 레벨에서 환경을 분리했습니다. 그렇다면 가장 중요한, Dart 코드에서 현재 어떤 환경(Flavor/Scheme)으로 앱이 실행되었는지 알고, 그에 맞는 API 주소(`BASE_URL`)를 사용하려면 어떻게 해야 할까요?

두 가지 대표적인 방법이 있습니다. 바로 현대적인 `--dart-define`을 사용하는 방법과 전통적인 `MethodChannel`을 이용하는 방법입니다.

방법 1: `--dart-define`을 이용한 컴파일 타임 변수 전달 (권장)

이 방법은 `flutter run` 또는 `flutter build` 명령어 실행 시 컴파일러에 직접 변수를 주입하는 방식입니다. 네이티브 코드와의 통신이 필요 없어 간단하고, 컴파일 시점에 값이 결정되므로 성능상 이점도 있습니다. 안드로이드와 iOS 모두 동일한 방식으로 작동합니다.

1. 실행/빌드 명령어에 `--dart-define` 추가

터미널에서 앱을 실행할 때 다음과 같이 명령어를 입력합니다.

# 개발용 Flavor/Scheme 실행
flutter run --flavor development --dart-define=ENVIRONMENT=development --dart-define=BASE_URL=https://dev-api.example.com/

# 운영용 Flavor/Scheme 실행
flutter run --flavor production --dart-define=ENVIRONMENT=production --dart-define=BASE_URL=https://api.example.com/

2. Dart 코드에서 값 읽기

Dart 코드에서는 `String.fromEnvironment()` 생성자를 통해 이 값을 읽을 수 있습니다. 이 생성자는 컴파일 타임 상수이므로, `const`와 함께 사용할 수 있습니다.

// lib/config.dart

class AppConfig {
  // --dart-define으로 전달된 'ENVIRONMENT' 변수를 읽어옵니다.
  // defaultValue는 값이 없을 경우를 대비한 기본값입니다.
  static const String environment = String.fromEnvironment(
    'ENVIRONMENT',
    defaultValue: 'production',
  );

  // --dart-define으로 전달된 'BASE_URL' 변수를 읽어옵니다.
  static const String baseUrl = String.fromEnvironment(
    'BASE_URL',
    defaultValue: 'https://api.example.com/',
  );

  static bool get isProduction => environment == 'production';
  static bool get isDevelopment => environment == 'development';
}

// 사용 예시
void main() {
  print('현재 환경: ${AppConfig.environment}');
  print('API 주소: ${AppConfig.baseUrl}');
  
  // API 클라이언트 초기화
  // final dio = Dio(BaseOptions(baseUrl: AppConfig.baseUrl));
  
  runApp(const MyApp());
}

3. (선택) VS Code `launch.json` 설정

매번 터미널에 긴 명령어를 입력하는 것은 번거롭습니다. VS Code를 사용한다면 `.vscode/launch.json` 파일을 설정하여 디버그 실행을 간편하게 만들 수 있습니다.

// .vscode/launch.json
{
    "version": "0.2.0",
    "configurations": [
        {
            "name": "Flutter (Development)",
            "request": "launch",
            "type": "dart",
            "flutterMode": "debug",
            "args": [
                "--flavor",
                "development",
                "--dart-define=ENVIRONMENT=development",
                "--dart-define=BASE_URL=https://dev-api.example.com/"
            ]
        },
        {
            "name": "Flutter (Production)",
            "request": "launch",
            "type": "dart",
            "flutterMode": "debug",
            "args": [
                "--flavor",
                "production",
                "--dart-define=ENVIRONMENT=production",
                "--dart-define=BASE_URL=https://api.example.com/"
            ]
        }
    ]
}

이제 VS Code의 'Run and Debug' 탭에서 "Flutter (Development)" 또는 "Flutter (Production)"을 선택하여 간편하게 원하는 환경으로 앱을 실행할 수 있습니다.

방법 2: `MethodChannel`을 이용한 네이티브 값 가져오기 (전통적 방식)

`--dart-define`이 등장하기 전에는 `MethodChannel`을 통해 네이티브 코드에 정의된 값을 가져오는 방식이 주로 사용되었습니다. 안드로이드의 `BuildConfig` 필드나 iOS의 User-Defined Setting 값을 런타임에 가져오는 방식입니다.

1. 안드로이드 설정 (`MainActivity.kt`)

// android/app/src/main/kotlin/.../MainActivity.kt
package com.example.my_app

import io.flutter.embedding.android.FlutterActivity
import io.flutter.embedding.engine.FlutterEngine
import io.flutter.plugin.common.MethodChannel

class MainActivity: FlutterActivity() {
    private val CHANNEL = "com.example.my_app/flavor"

    override fun configureFlutterEngine(flutterEngine: FlutterEngine) {
        super.configureFlutterEngine(flutterEngine)
        MethodChannel(flutterEngine.dartExecutor.binaryMessenger, CHANNEL).setMethodCallHandler {
            call, result ->
            if (call.method == "getBaseUrl") {
                // build.gradle에 정의한 BuildConfig 필드를 반환
                result.success(BuildConfig.BASE_URL)
            } else {
                result.notImplemented()
            }
        }
    }
}

2. Dart 코드에서 호출

// lib/config.dart
import 'package:flutter/services.dart';

class NativeConfig {
  static const _platform = MethodChannel('com.example.my_app/flavor');
  static String? _baseUrl;

  static Future<String> getBaseUrl() async {
    if (_baseUrl == null) {
      try {
        final String url = await _platform.invokeMethod('getBaseUrl');
        _baseUrl = url;
      } on PlatformException catch (e) {
        print("Failed to get base URL: '${e.message}'.");
        // fallback URL
        _baseUrl = "https://fallback-api.example.com/";
      }
    }
    return _baseUrl!;
  }
}

// main 함수에서 비동기로 호출해야 함
void main() async {
  WidgetsFlutterBinding.ensureInitialized();
  
  final baseUrl = await NativeConfig.getBaseUrl();
  print('API 주소: $baseUrl');
  
  runApp(const MyApp());
}

이 방식은 `main` 함수가 `async`가 되어야 하고, 네이티브 코드를 추가로 작성해야 하는 번거로움이 있습니다. 하지만 네이티브 로직과 더 깊게 연동해야 하는 경우 유용할 수 있습니다. 대부분의 경우, `--dart-define` 방식이 훨씬 간단하고 효율적이므로 권장됩니다.

결론: 안정적인 개발의 첫걸음

지금까지 플러터 프로젝트에서 안드로이드의 Product Flavors와 iOS의 Xcode Schemes를 활용하여 개발 및 운영 환경을 완벽하게 분리하는 방법을 상세히 알아보았습니다. 이 과정을 통해 우리는 다음과 같은 이점을 얻게 됩니다.

• 안전한 개발: 개발용 API와 운영용 API를 분리하여 데이터 오염이나 잘못된 호출을 원천적으로 차단합니다.
• 효율적인 테스트: 개발용 앱과 운영용 앱을 한 기기에 동시에 설치하여 비교 테스트를 쉽게 수행할 수 있습니다.
• 명확한 식별: 앱 아이콘과 이름으로 빌드 환경을 명확히 구분하여 혼동을 방지합니다.
• 체계적인 관리: 환경별로 다른 인증 키, 설정 값들을 체계적으로 관리하여 보안을 강화하고 유지보수를 용이하게 합니다.

초기 설정 과정이 다소 복잡하게 느껴질 수 있지만, 한번 구축해두면 프로젝트가 진행되는 내내 개발팀 전체의 생산성과 서비스의 안정성을 크게 높여주는 든든한 기반이 될 것입니다. 특히 `--dart-define`을 활용한 설정 값 주입은 플러터의 크로스플랫폼 철학을 잘 살리면서도 매우 간결하게 환경 분리를 구현할 수 있는 훌륭한 방법입니다.

이제 여러분의 플러터 프로젝트에도 환경 분리를 적용하여, 더 전문적이고 안정적인 앱 개발을 시작해보세요.