소프트웨어 개발의 생명주기는 단순히 코드를 작성하는 것에서 끝나지 않습니다. 개발, 테스트, 스테이징, 그리고 최종적으로 프로덕션에 이르기까지 여러 단계를 거치게 됩니다. 각 단계는 고유한 환경과 설정을 요구합니다. 예를 들어, 개발 환경에서는 로컬 데이터베이스나 모의(mock) API를 사용하지만, 프로덕션 환경에서는 실제 사용자 데이터를 처리하는 라이브 데이터베이스와 실제 API 엔드포인트에 연결되어야 합니다. 이러한 환경별 차이를 코드에 직접 하드코딩하는 것은 재앙을 부르는 지름길입니다. 설정값이 변경될 때마다 코드를 수정하고, 다시 빌드하고, 배포해야 하는 비효율적인 프로세스를 반복하게 되며, 실수로 개발용 설정을 프로덕션 빌드에 포함시키는 끔찍한 사고로 이어질 수도 있습니다.
따라서 성공적인 애플리케이션 개발의 핵심은 이러한 환경 변수와 설정값들을 코드와 분리하여 체계적으로 관리하는 것입니다. 플러터(Flutter)는 다양한 플랫폼을 지원하는 강력한 프레임워크인 만큼, 여러 환경에 걸쳐 설정을 효율적으로 관리할 수 있는 강력한 메커니즘을 제공합니다. 이 글에서는 가장 기본적인 --dart-define 컴파일러 플래그부터 시작하여, 애플리케이션의 복잡성과 팀의 규모가 커짐에 따라 적용할 수 있는 고급 전략인 Flavors, 그리고 .env 파일을 활용한 유연한 설정 관리에 이르기까지, 플러터 프로젝트의 견고함과 확장성을 한 단계 끌어올릴 수 있는 환경 설정 관리 기법들을 심도 있게 탐색합니다.
컴파일 타임 설정의 핵심: --dart-define 이해하기
플러터에서 환경 변수를 주입하는 가장 직접적이고 기본적인 방법은 --dart-define 옵션을 사용하는 것입니다. 이는 flutter run 또는 flutter build 명령어 실행 시점에 Dart 코드에서 사용할 수 있는 상수 값을 전달하는 강력한 기능입니다.
--dart-define이란 무엇인가?
--dart-define은 Dart 컴파일러에게 "이 키(Key)를 이 값(Value)으로 정의하라"고 지시하는 플래그입니다. 이렇게 전달된 값은 컴파일 시점에 코드에 직접 포함되며, 애플리케이션이 실행되는 동안에는 변경할 수 없는 컴파일 타임 상수(compile-time constant)로 취급됩니다. 이는 런타임에 파일을 읽거나 네트워크 요청을 통해 설정을 가져오는 방식과 근본적인 차이가 있으며, 성능상 이점을 가집니다. 또한, 코드베이스 외부에서 설정을 주입하므로, 소스 코드 자체의 수정 없이 빌드 환경을 변경할 수 있다는 유연성을 제공합니다.
기본 사용법 및 구문
--dart-define의 사용법은 매우 간단합니다. KEY=VALUE 형식으로 전달하며, 공백이 포함된 값을 전달할 경우 따옴표로 감싸주어야 합니다.
# API 서버 주소를 변수로 전달하여 앱을 실행
flutter run --dart-define=API_URL=https://api.myapp.com
# 앱의 테마 이름을 전달하여 APK 빌드
flutter build apk --dart-define=APP_THEME=dark
# 동적으로 빌드 시간 주입 (원문 예시)
# 빌드 시점의 날짜와 시간을 version 변수에 할당
flutter build appbundle --dart-define=BUILD_TIME=`date +%Y-%m-%d_%H:%M`
다양한 데이터 타입 처리
--dart-define으로 전달된 모든 값은 기본적으로 문자열(String)로 취급됩니다. Dart 코드에서는 fromEnvironment 생성자를 사용하여 이 값들을 가져올 수 있습니다. 각 데이터 타입에 맞는 생성자를 사용해야 하며, 이들은 모두 const 생성자이므로 컴파일 타임 상수로만 선언할 수 있습니다.
- String:
String.fromEnvironment('VARIABLE_NAME', defaultValue: 'default')
- int:
int.fromEnvironment('VARIABLE_NAME', defaultValue: 0)
- bool:
bool.fromEnvironment('VARIABLE_NAME', defaultValue: false)
아래는 실제 코드에서 이 값들을 사용하는 예시입니다.
// --dart-define=API_URL=https://api.myapp.com
// --dart-define=USE_MOCK_API=false
// --dart-define=REQUEST_TIMEOUT=30000
class AppConfig {
static const String apiUrl = String.fromEnvironment(
'API_URL',
defaultValue: 'https://default.api.com',
);
static const bool useMockApi = bool.fromEnvironment(
'USE_MOCK_API',
defaultValue: true, // 로컬 개발 시 --dart-define을 생략하면 기본적으로 mock API를 사용하도록 설정
);
static const int requestTimeout = int.fromEnvironment(
'REQUEST_TIMEOUT',
defaultValue: 15000, // 기본 타임아웃 15초
);
}
// 사용 예시
void main() {
print('API URL: ${AppConfig.apiUrl}');
print('Use Mock API: ${AppConfig.useMockApi}');
print('Request Timeout: ${AppConfig.requestTimeout}ms');
// ... runApp(MyApp());
}
중요한 점은 fromEnvironment로 가져온 값은 반드시 const 변수에 할당해야 한다는 것입니다. 이는 컴파일 시점에 값이 결정되어야 함을 강제하며, 런타임에 변경될 수 없음을 보장합니다.
여러 변수 동시에 전달하기
실제 프로젝트에서는 여러 개의 설정값을 전달해야 하는 경우가 대부분입니다. 이 경우, --dart-define 플래그를 필요한 만큼 반복해서 사용하면 됩니다.
flutter run \
--dart-define=APP_NAME="My Awesome App (Dev)" \
--dart-define=API_URL=https://dev-api.myapp.com \
--dart-define=ENABLE_LOGGING=true
Dart 코드에서 설정값 안전하게 사용하기
--dart-define으로 값을 주입하는 방법을 알았다면, 이제 애플리케이션 전체에서 이 값들을 체계적이고 안전하게 사용하는 방법을 고민해야 합니다. 각 화면이나 위젯에서 String.fromEnvironment()를 직접 호출하는 것은 코드의 중복을 유발하고 유지보수를 어렵게 만듭니다.
전역 설정 관리 클래스 구현
가장 좋은 방법은 애플리케이션의 모든 설정을 한 곳에서 관리하는 별도의 클래스를 만드는 것입니다. 이는 싱글톤(Singleton) 패턴이나 정적(static) 멤버로만 구성된 클래스를 통해 쉽게 구현할 수 있습니다. 이렇게 하면 설정값에 대한 접근 지점이 단일화되어 관리가 용이해지고, 어떤 설정값들이 사용 가능한지 명확하게 파악할 수 있습니다.
// lib/config/app_config.dart
enum Environment {
development,
staging,
production,
}
class AppConfig {
// 환경 변수 이름들을 상수로 정의하여 오타 방지
static const _envKey = 'ENV';
static const _apiUrlKey = 'API_URL';
static const _appNameKey = 'APP_NAME';
// 환경 변수 값을 읽어오는 부분
static const String _env = String.fromEnvironment(_envKey, defaultValue: 'development');
static const String apiUrl = String.fromEnvironment(_apiUrlKey);
static const String appName = String.fromEnvironment(_appNameKey, defaultValue: 'Flutter App');
// 현재 환경을 Enum 타입으로 변환하여 제공
static Environment get currentEnvironment {
switch (_env.toLowerCase()) {
case 'prod':
case 'production':
return Environment.production;
case 'stage':
case 'staging':
return Environment.staging;
default:
return Environment.development;
}
}
// 환경에 따라 다른 로직을 수행할 수 있도록 getter 제공
static bool get isProduction => currentEnvironment == Environment.production;
static bool get isDevelopment => currentEnvironment == Environment.development;
}
이제 애플리케이션의 어느 곳에서든 AppConfig.apiUrl이나 AppConfig.isProduction과 같은 방식으로 설정값에 일관되게 접근할 수 있습니다. 이는 코드의 가독성을 높이고, 향후 새로운 설정값이 추가되거나 기존 값이 변경될 때 app_config.dart 파일만 수정하면 되므로 유지보수 효율을 극대화합니다.
기본값(Default Value)의 중요성
fromEnvironment 생성자의 두 번째 인자인 defaultValue는 매우 중요합니다. 만약 --dart-define을 통해 해당 변수가 전달되지 않았을 경우, 이 기본값이 사용됩니다. 만약 기본값이 설정되어 있지 않은데 변수가 전달되지 않으면, 타입에 따라 예외가 발생하거나(예: int.fromEnvironment) 빈 문자열이 반환될 수 있습니다. 특히 로컬 개발 환경에서 매번 모든 --dart-define 옵션을 입력하는 것은 번거롭기 때문에, 개발 환경에 적합한 기본값을 설정해두는 것이 좋습니다. 이는 개발자가 별도의 설정 없이 flutter run만으로도 앱을 즉시 실행해볼 수 있게 하여 개발 경험을 향상시킵니다.
개발 환경의 분리: Flavors와 --dart-define의 시너지
애플리케이션의 규모가 커지면 단순히 API 주소나 앱 이름을 바꾸는 것만으로는 부족해집니다. 개발, 스테이징, 프로덕션 환경별로 다른 앱 아이콘, 다른 패키지 이름(Application ID), 다른 푸시 알림 인증서 등을 사용해야 할 필요가 생깁니다. 이때 필요한 것이 바로 **Flavors(또는 iOS의 Schemes)**입니다. Flavors는 단일 코드베이스를 사용하여 각기 다른 설정과 리소스를 가진 여러 버전의 앱을 생성하는 기능이며, --dart-define과 결합했을 때 엄청난 시너지를 발휘합니다.
Android에서 Flavors 설정하기
Android에서는 android/app/build.gradle 파일에서 Flavors를 설정합니다. android 블록 내에 flavorDimensions와 productFlavors를 추가합니다.
// android/app/build.gradle
...
android {
...
// 1. Flavor를 구분할 기준을 정의합니다. 'env'라는 이름의 차원을 만듭니다.
flavorDimensions "env"
productFlavors {
// 2. 'dev' Flavor 정의
dev {
dimension "env"
applicationIdSuffix ".dev" // 패키지 이름 뒤에 .dev를 붙임 (e.g., com.example.app.dev)
versionNameSuffix "-dev" // 버전 이름 뒤에 -dev를 붙임 (e.g., 1.0.0-dev)
resValue "string", "app_name", "MyApp Dev" // Android 네이티브에서 사용할 앱 이름
}
// 3. 'staging' Flavor 정의
staging {
dimension "env"
applicationIdSuffix ".staging"
versionNameSuffix "-staging"
resValue "string", "app_name", "MyApp Staging"
}
// 4. 'prod' Flavor 정의
prod {
dimension "env"
// 프로덕션 버전은 suffix를 붙이지 않아 원래 패키지 이름을 사용
resValue "string", "app_name", "MyApp"
}
}
...
}
이렇게 설정하면 dev, staging, prod 세 가지 버전의 앱을 빌드할 수 있으며, 각 버전은 서로 다른 applicationId를 가지므로 한 기기에 동시에 설치할 수도 있습니다.
iOS에서 Schemes 설정하기
iOS에서는 Xcode의 Schemes를 사용하여 비슷한 기능을 구현합니다. 기본 `Runner` Scheme을 복제하여 각 환경에 맞는 새로운 Scheme을 생성합니다.
- Xcode에서
ios/Runner.xcworkspace를 엽니다.
- 상단 메뉴에서 Product > Scheme > Manage Schemes...를 선택합니다.
- 기존의 `Runner` Scheme을 선택하고 하단의 톱니바퀴 아이콘을 눌러 Duplicate를 선택합니다.
- 새로운 Scheme의 이름을 `Runner-dev`와 같이 환경에 맞게 변경합니다. `staging`, `prod`에 대해서도 반복합니다.
- 방금 생성한 `Runner-dev` Scheme을 선택하고 Edit... 버튼을 누릅니다.
- 왼쪽 메뉴에서 Build > Pre-actions를 선택하고, **+** 버튼을 눌러 **New Run Script Action**을 추가합니다.
- 스크립트 영역에 다음과 같이 작성하여, 빌드 시 어떤 환경 파일을 사용할지 지정합니다. 이는 Firebase 설정 파일(
GoogleService-Info.plist) 등을 분리할 때 유용합니다.
# Runner-dev Scheme의 경우
cp "${PROJECT_DIR}/Flutter/dev/GoogleService-Info.plist" "${PROJECT_DIR}/Runner/GoogleService-Info.plist"
- 또한, 각 Scheme에 대해 다른 `Display Name`이나 `Bundle Identifier`를 설정하려면, 프로젝트 설정의 **Build Settings** 탭에서 사용자 정의 변수를 추가하고 `Info.plist`에서 해당 변수를 참조하도록 구성할 수 있습니다.
이 과정은 Android에 비해 다소 복잡하지만, 한번 설정해두면 각 환경에 맞는 완벽하게 분리된 빌드를 생성할 수 있습니다.
Flavors와 --dart-define를 결합한 실행
이제 Flavors 설정이 완료되었으므로, --flavor 옵션을 사용하여 특정 환경의 앱을 실행하거나 빌드할 수 있습니다. 이때 --dart-define을 함께 사용하여 해당 환경에 맞는 설정값을 주입합니다.
# 개발 환경으로 앱 실행 (dev Flavor)
flutter run --flavor dev --dart-define=ENV=development --dart-define=API_URL=https://dev.api.com
# 스테이징 환경으로 앱 빌드 (staging Flavor)
flutter build apk --flavor staging --dart-define=ENV=staging --dart-define=API_URL=https://staging.api.com
# 프로덕션 환경으로 앱 빌드 (prod Flavor)
flutter build appbundle --flavor prod --dart-define=ENV=production --dart-define=API_URL=https://api.com
이렇게 하면 각 Flavor에 맞는 네이티브 설정(앱 아이콘, 패키지명 등)과 Dart 코드에서 사용할 설정값(API 주소 등)이 모두 완벽하게 분리되어 적용됩니다. 이는 실무에서 매우 강력하고 안정적인 환경 관리 전략입니다.
개발 생산성 향상: IDE와 스크립트를 활용한 자동화
매번 터미널에서 긴 명령어를 입력하는 것은 비효율적이고 실수를 유발하기 쉽습니다. 다행히도 VS Code나 Android Studio와 같은 IDE는 이러한 명령어들을 저장하고 재사용할 수 있는 기능을 제공하며, 쉘 스크립트를 통해 빌드 프로세스를 자동화할 수도 있습니다.
Visual Studio Code: launch.json 설정
VS Code에서는 .vscode/launch.json 파일을 통해 실행 및 디버그 구성을 정의할 수 있습니다. 이 파일을 사용하면 각 Flavor에 대한 실행 구성을 미리 만들어두고, 간단한 클릭만으로 원하는 환경의 앱을 실행할 수 있습니다.
{
"version": "0.2.0",
"configurations": [
{
"name": "Run (Dev)",
"request": "launch",
"type": "dart",
"flutterMode": "debug",
"program": "lib/main.dart",
"args": [
"--flavor",
"dev",
"--dart-define=ENV=development",
"--dart-define=API_URL=https://dev.api.com",
"--dart-define=APP_NAME=MyApp (Dev)"
]
},
{
"name": "Run (Staging)",
"request": "launch",
"type": "dart",
"flutterMode": "debug",
"program": "lib/main_staging.dart", // 스테이징용 진입점을 분리할 수도 있음
"args": [
"--flavor",
"staging",
"--dart-define=ENV=staging",
"--dart-define=API_URL=https://staging.api.com",
"--dart-define=APP_NAME=MyApp (Staging)"
]
},
{
"name": "Run (Production)",
"request": "launch",
"type": "dart",
"flutterMode": "debug",
"program": "lib/main.dart",
"args": [
"--flavor",
"prod",
"--dart-define=ENV=production",
"--dart-define=API_URL=https://api.com",
"--dart-define=APP_NAME=MyApp"
]
}
]
}
위와 같이 설정하면 VS Code의 'Run and Debug' 탭에서 "Run (Dev)", "Run (Staging)", "Run (Production)" 옵션을 선택하여 실행할 수 있습니다. toolArgs 대신 args를 사용하는 것이 최신 권장 방식입니다.
Android Studio: Run/Debug Configurations
Android Studio에서도 비슷한 설정이 가능합니다. 상단의 실행 구성 드롭다운 메뉴에서 Edit Configurations...를 선택합니다. **+** 버튼을 눌러 새로운 Flutter 실행 구성을 추가하고, 각 Flavor에 맞게 이름을 지정합니다. 그리고 'Additional run args' 필드에 --flavor dev --dart-define=...와 같은 옵션들을 입력하면 됩니다. 이렇게 여러 구성을 만들어두면 Android Studio에서도 간단하게 환경을 전환하며 개발할 수 있습니다.
CI/CD를 위한 쉘 스크립트 작성
지속적인 통합 및 배포(CI/CD) 파이프라인에서는 IDE 설정이 아닌 스크립트를 통해 빌드 프로세스를 자동화해야 합니다. 쉘 스크립트를 작성하면 빌드 과정을 표준화하고, 누구나 동일한 결과물을 생성할 수 있도록 보장합니다.
#!/bin/bash
# build.sh
# 스크립트 실행 시 오류가 발생하면 즉시 중단
set -e
# 첫 번째 인자로 환경(dev, staging, prod)을 받음
ENVIRONMENT=$1
if [ -z "$ENVIRONMENT" ]; then
echo "오류: 빌드 환경을 지정해야 합니다. (dev, staging, prod)"
exit 1
fi
echo "빌드를 시작합니다: $ENVIRONMENT 환경"
# 공통 빌드 옵션
FLUTTER_BUILD_COMMAND="flutter build appbundle --release"
# 환경별 dart-define 값 설정
if [ "$ENVIRONMENT" = "dev" ]; then
DART_DEFINES="--dart-define=ENV=development --dart-define=API_URL=https://dev.api.com"
FLAVOR_OPTION="--flavor dev"
elif [ "$ENVIRONMENT" = "staging" ]; then
DART_DEFINES="--dart-define=ENV=staging --dart-define=API_URL=https://staging.api.com"
FLAVOR_OPTION="--flavor staging"
elif [ "$ENVIRONMENT" = "prod" ]; then
DART_DEFINES="--dart-define=ENV=production --dart-define=API_URL=https://api.com"
FLAVOR_OPTION="--flavor prod"
else
echo "오류: 유효하지 않은 환경입니다: $ENVIRONMENT"
exit 1
fi
# 최종 빌드 명령어 실행
FULL_COMMAND="$FLUTTER_BUILD_COMMAND $FLAVOR_OPTION $DART_DEFINES"
echo "실행 명령어: $FULL_COMMAND"
eval $FULL_COMMAND
echo "빌드 완료: $ENVIRONMENT 환경"
이 스크립트는 ./build.sh prod와 같이 실행하여 특정 환경의 앱을 일관된 방식으로 빌드할 수 있게 해줍니다. 이는 Jenkins, GitHub Actions, Codemagic과 같은 CI/CD 도구와 통합하기에 매우 이상적입니다.
더 유연한 접근법: .env 파일 활용
--dart-define은 강력하지만, 관리해야 할 변수가 많아지면 명령어 라인이 매우 길어지고 가독성이 떨어지는 단점이 있습니다. 또한, 개발자마다 다른 로컬 설정(예: 개인 테스트용 API 키)을 사용해야 할 경우, 이를 명령어에 포함시키는 것은 번거롭습니다. 이러한 문제를 해결하기 위해 많은 개발자들이 .env 파일을 선호합니다.
왜 .env 파일을 사용하는가?
.env 파일은 KEY=VALUE 형식으로 환경 변수를 저장하는 간단한 텍스트 파일입니다.
- **가독성:** 설정값들이 파일에 명확하게 정리되어 있어 파악하기 쉽습니다.
- **로컬 최적화:** .env 파일을 버전 관리(Git)에서 제외(.gitignore에 추가)하면, 각 개발자가 자신의 로컬 환경에 맞는 설정을 자유롭게 구성할 수 있습니다.
- **보안:** 민감한 정보를 실수로 Git 저장소에 커밋하는 것을 방지할 수 있습니다.
flutter_dotenv 패키지 사용법
플러터에서는 flutter_dotenv와 같은 패키지를 사용하여 .env 파일을 쉽게 로드하고 사용할 수 있습니다.
1. **패키지 추가:**
flutter pub add flutter_dotenv
2. **
.env 파일 생성:** 프로젝트 루트 디렉토리에
.env 파일을 만들고 변수를 추가합니다.
# .env
API_URL=https://my-local-api.com
DEBUG_MODE=true
3. **assets에 추가:**
pubspec.yaml 파일에
.env 파일이 앱 번들에 포함되도록 추가합니다.
flutter:
assets:
- .env
4. **Dart 코드에서 로드 및 사용:** 앱의 시작점(
main.dart)에서
dotenv.load()를 호출하여 변수를 메모리에 로드합니다.
import 'package:flutter_dotenv/flutter_dotenv.dart';
// main 함수를 async로 변경
Future<void> main() async {
// .env 파일 로드
await dotenv.load(fileName: ".env");
runApp(MyApp());
}
// 설정값 사용 예시
class ApiService {
// dotenv.env는 맵(Map)이므로, 키를 통해 값에 접근
final String? apiUrl = dotenv.env['API_URL'];
void fetchData() {
// ...
}
}
.env 방식은 런타임에 파일을 읽어오므로 const 상수가 아니라는 점에 유의해야 합니다. 따라서 --dart-define과 사용 목적이 약간 다릅니다. 보통 로컬 개발의 편의성을 위해 .env를 사용하고, CI/CD를 통한 공식 빌드에서는 --dart-define을 사용하는 하이브리드 전략이 많이 사용됩니다.
주의사항 및 보안 고려사항
--dart-define 값은 비밀이 아니다
가장 중요하게 기억해야 할 점은 --dart-define으로 전달된 값은 컴파일된 앱 바이너리(APK, AAB, IPA)에 **평문 텍스트**로 포함된다는 것입니다. 이는 앱을 디컴파일하거나 메모리를 분석하면 누구나 이 값을 쉽게 알아낼 수 있음을 의미합니다. 따라서 다음과 같은 민감한 정보는 절대 --dart-define으로 전달해서는 안 됩니다.
- API Secret Keys
- 암호화 키
- 사용자 인증 정보와 관련된 모든 값
--dart-define은 API의 공개 엔드포인트 주소, 기능 플래그(feature flag), 환경 이름과 같이 노출되어도 보안상 문제가 없는 비민감성 정보를 관리하는 데 적합합니다.
민감 정보 관리를 위한 대안
민감 정보는 다음과 같은 더 안전한 방법을 통해 관리해야 합니다.
1. **CI/CD 환경 변수 사용:** GitHub Actions Secrets, Jenkins Credentials와 같은 CI/CD 도구의 보안 기능을 사용하여 빌드 시에만 안전하게 키를 주입하고, 이 값을 네이티브 코드(Android의 local.properties나 iOS의 `xcconfig`)에 전달합니다. 이후 MethodChannel을 통해 Dart 코드에서 이 값을 안전하게 가져올 수 있습니다.
2. **클라우드 기반 Secret Manager:** AWS Secrets Manager나 Google Cloud Secret Manager와 같은 서비스를 사용하여 런타임에 안전하게 민감 정보를 가져옵니다.
3. **코드 난독화 및 암호화:** 불가피하게 앱 내에 키를 저장해야 한다면, 최소한의 방어책으로 값을 암호화하여 저장하고, R8(Android)이나 ProGuard와 같은 도구로 코드를 난독화하여 리버스 엔지니어링을 어렵게 만들어야 합니다.
결론: 프로젝트에 맞는 최적의 전략 선택하기
플러터 애플리케이션의 환경 설정을 관리하는 방법은 하나만 있는 것이 아니며, 프로젝트의 요구사항과 복잡성에 따라 적절한 전략을 선택해야 합니다.
- 소규모 프로젝트 또는 간단한 설정:**
--dart-define만으로도 충분합니다. API 주소나 기능 플래그 몇 개를 관리하는 데는 이보다 더 간단하고 효율적인 방법은 없습니다.
- 다양한 배포 환경이 필요한 경우:**
--dart-define과 **Flavors**를 결합하는 것이 표준적인 모범 사례입니다. 이를 통해 환경별로 완벽하게 분리된 앱 패키지를 생성하여 안정성을 크게 높일 수 있습니다.
- 개발자 편의성과 유연성이 중요한 경우:** 로컬 개발 환경에서는
.env 파일을 활용하여 개발자들이 빠르고 쉽게 설정을 변경할 수 있도록 지원하고, CI/CD 파이프라인에서는 스크립트와 --dart-define을 사용하여 빌드를 자동화하는 **하이브리드 방식**이 매우 효과적입니다.
어떤 방법을 선택하든 가장 중요한 원칙은 **설정을 코드와 분리하는 것**입니다. 이 원칙을 충실히 따르면, 애플리케이션이 성장하고 변화하는 과정에서 발생할 수 있는 수많은 문제들을 예방하고, 더욱 견고하고 유지보수하기 쉬운 고품질의 플러터 앱을 구축할 수 있을 것입니다.
