Build Variants & 멀티 모듈 구조

1. 빌드 변형(Build Variants)이란?

 

1.1 개념 이해

 

빌드 변형이란, 여러 가지 빌드 설정을 한 프로젝트 내에서 손쉽게 전환하며 앱을 생성하는 방식이다.

안드로이드에서는 흔히 Build Type(예: debug, release)과 Product Flavor(예: free, paid)를 결합해 다양한 Build Variant를 만든다.

• Build Type

• 보통 debug와 release가 기본으로 제공된다.

• debug 빌드는 디버그 용도(디버그gable=true, ProGuard 미적용), release 빌드는 실제 배포 용도(프로가드/R8 적용, 난독화 등)로 구분된다.

• Product Flavor

• 비즈니스 요구사항에 따라 무료 버전, 유료 버전, 특정 클라이언트 전용 버전 등으로 나눌 수 있다.

• 서로 다른 애플리케이션 아이디, 리소스, 코드 등을 Flavor별로 관리한다.

 

1.2 빌드 변형 활용 예시

• 무료/유료(Free/Paid) 버전: 특정 기능 차단, 광고 모듈 사용 여부 등

• 버전별 API 엔드포인트 달리 적용: 개발(Dev), 품질관리(QA), 운영(Prod) 서버로 분리

• 클라이언트 커스텀 앱: B2B(Business to Business) 형태에서 로고, 스플래시 색상 등이 다른 여러 앱을 빠르게 빌드

---

2. Gradle 설정으로 살펴보는 예시

 

2.1 Product Flavors 예시

 

아래는 app/build.gradle에서 Product Flavor를 정의한 단순 예시다.

android {
    compileSdk 33
    
    defaultConfig {
        applicationId "com.example.myapp"
        minSdk 21
        targetSdk 33
        versionCode 1
        versionName "1.0"
    }
    
    buildTypes {
        debug {
            applicationIdSuffix ".debug"
            versionNameSuffix "-debug"
        }
        release {
            // 사인(Signing)과 난독화 설정 등 배포용 세팅
            minifyEnabled true
            proguardFiles getDefaultProguardFile('proguard-android.txt'), 'proguard-rules.pro'
        }
    }
    
    flavorDimensions "version"
    productFlavors {
        free {
            dimension "version"
            applicationIdSuffix ".free"
            versionNameSuffix "-free"
        }
        paid {
            dimension "version"
            applicationIdSuffix ".paid"
            versionNameSuffix "-paid"
        }
    }
}

1. flavorDimensions: Flavors를 구분하는 **차원(Dimension)**을 정의한다. 여기서는 version 하나만 사용했다.

2. productFlavors: free, paid 두 가지 Flavor를 선언했다. 각각 applicationIdSuffix, versionNameSuffix 등이 다르게 붙는다.

3. buildTypes: debug와 release 빌드를 선언하고, 난독화, 사인 설정 등을 적용한다.

 

이렇게 Flavor와 Build Type을 정의하면, Build Variants로 freeDebug, freeRelease, paidDebug, paidRelease 총 4가지가 자동 생성된다.

 

2.2 Flavor별 리소스 및 코드 관리

• app/src/free/ 폴더 내에 전용 리소스(레이아웃, 문자열 등)를 배치해, 무료 버전만의 UI를 구성할 수 있다.

• app/src/paid/ 폴더에선 유료 버전 전용 기능이나 리소스를 포함할 수 있다.

• 마찬가지로, app/src/debug/ 폴더를 만들어 디버그 전용 로깅이나 테스트코드를 포함할 수도 있다.

---

3. 멀티 모듈 구조로 빌드 효율 극대화

 

3.1 멀티 모듈이 필요한 이유

프로젝트가 커질수록, 모든 코드를 한 app 모듈에 몰아넣으면 다음과 같은 문제가 발생한다.

1. 빌드 시간 증가: 코드 변경이 조금만 생겨도 전체 프로젝트를 다시 빌드해야 하므로 비효율적이다.

2. 코드 관리 복잡: 기능별로 코드가 섞여 의존관계가 뒤얽힐 수 있다.

3. 재사용성 떨어짐: 공통 로직을 다른 프로젝트에서 재활용하기 어렵다.

 

3.2 멀티 모듈 설계 개요

아래는 간단한 예시 구조다.

project-root
 ├─ build.gradle (프로젝트 루트)
 ├─ settings.gradle
 ├─ app (메인 앱 모듈)
 ├─ featureA (기능 A 모듈)
 ├─ featureB (기능 B 모듈)
 └─ core (공통 유틸리티/라이브러리 모듈)

• app: 실제 실행 가능한 안드로이드 애플리케이션(launcher) 모듈

• featureA, featureB: 화면이나 기능을 특정 영역으로 분리한 모듈

• core: 공통 코드, 네트워크나 DB 헬퍼, 모델 클래스 등을 담아둘 수 있는 라이브러리 모듈

 

3.3 멀티 모듈 구현 시 고려 사항

1. settings.gradle에서 여러 모듈을 포함 선언

include(":app", ":featureA", ":featureB", ":core")

 

2. app 모듈의 build.gradle에서 다른 모듈을 의존성으로 추가

dependencies {
    implementation project(":featureA")
    implementation project(":featureB")
    implementation project(":core")
}

 

3. 각 모듈은 플러그인 적용 방식이 다를 수 있음

• 라이브러리 모듈: com.android.library 플러그인 적용

• 앱 모듈: com.android.application 플러그인 적용

 

3.4 장점

• 모듈별 빌드: 변경된 모듈만 Incremental build가 가능하므로 빌드 시간이 줄어든다.

• 코드 분리: 기능이나 레이어별로 코드를 격리해 유지보수성과 가독성이 높아진다.

• 재사용성: 코어 라이브러리 모듈을 여러 앱에서 재사용할 수 있다.

---

4. Build Variants와 멀티 모듈의 결합

 

Build Variants는 앱 모듈뿐 아니라, 라이브러리 모듈(예: featureA)에도 적용할 수 있다.

• 특정 모듈에서만 다른 Flavor 설정이 필요하다면, 각 모듈의 build.gradle에서 Flavor를 정의할 수 있다.

• 멀티 모듈 구조와 Build Variants를 잘 조합하면, 대규모 프로젝트에서도 개발·배포 효율을 극대화할 수 있다.

---

5. 간단 실전 예시

 

가령 “app” 모듈에는 debug/release Build Type과 dev/prod Flavor가 존재하고, “featureA” 모듈에는 무료/유료 Flavor만 있다면, 아래처럼 구성할 수 있다.

• app 모듈

android {
    buildTypes {
        debug { ... }
        release { ... }
    }
    flavorDimensions "env"
    productFlavors {
        dev { dimension "env" }
        prod { dimension "env" }
    }
}

 

• featureA 모듈

android {
    flavorDimensions "productTier"
    productFlavors {
        free { dimension "productTier" }
        paid { dimension "productTier" }
    }
}

 

 

각 모듈에서 Flavor Dimension 이름이 다르므로 충돌 없이 다른 목적의 Flavor를 관리할 수 있다.

---

마무리

 

Build Variants(빌드 변형)를 통해 여러 버전의 앱을 쉽게 관리하는 방법과, 멀티 모듈 구조로 프로젝트 규모가 커져도 유지보수성을 높이는 전략을 다뤄보았다.

• Build Variants: Build Type(debug, release)와 Product Flavor(free, paid, dev, prod) 등을 조합해 다양한 빌드를 자동 생성한다.

• 멀티 모듈 구조: 여러 기능 모듈(Feature), 코어 모듈(Core)로 분리해 빌드 시간 단축, 코드 구조 개선, 재사용성을 꾀한다.