멀티모듈 알아보기 (2) - Build-logic 모듈 설계 (1)

Build-logic 이란?

빌드 로직 모듈이란, 여러 모듈의 버전 및 라이브러리를 한 번에 관리할 수 있는 모듈 설계이다.

모든 모듈은 매번 버전이나 라이브러리 변경 및 추가 시 일일히 추가해줘야하는 단점이 있다.

하지만, 모듈의 갯수가 많아질수록, 이 방법은 매우 비효율 적이다.

그래서 나타난 것이 build-logic 모듈이다.

 

아래는 nowinandroid의 설명에서 발췌한 글을 해석해 보았다.

nowinandroid/build-logic at main · android/nowinandroid

컨벤션 플러그인 해당 build-logic폴더는 공통 모듈 구성에 대한 단일 진실의 소스를 유지하는 데 사용되는 프로젝트별 컨벤션 플러그인을 정의합니다. 이 접근 방식은 https://developer.squareup.com/blog/herding-elephants/ 와 https://github.com/jjohannes/idiomatic-gradle 에 크게 기반을 두고 있습니다 . 컨벤션 플러그인을 설정하면 디렉토리 의 함정 없이 build-logic중복된 빌드 스크립트 설정과 지저분한 구성을 피할 수 있습니다  build-logic루트에 구성된 대로 포함된 빌드입니다 settings.gradle.kts. 내부에는 모든 일반 모듈이 스스로를 구성하는 데 사용할 수 있는 플러그인 세트를 정의하는 모듈이 build-logic있습니다  build-logic또한 플러그인 자체 간에 로직을 공유하는 데 사용되는 파일 세트도 포함되어 있으며 Kotlin, 이는 공유 코드로 Android 구성 요소(라이브러리 대 애플리케이션)를 구성하는 데 가장 유용합니다. 이러한 플러그인은 추가적이고 구성 가능 하며 단일 책임만 달성하려고 합니다. 그런 다음 모듈은 필요한 구성을 선택할 수 있습니다. 공유 코드가 없는 모듈에 대한 일회성 논리가 있는 경우 build.gradle모듈별 설정으로 컨벤션 플러그인을 만드는 것보다 모듈의 에서 직접 정의하는 것이 좋습니다..

 

번역기를 돌린 내용이라 두서가 없지만, 요약해보면

컨벤션 플러그인을 설정하면 중복된 빌드 스크립트 설정과 지저분한 구성을 피해 보일러 플레이트 코드를 제거할 수 있고,

특히 라이브러리와 애플리케이션을 나누어 구성하는 데 유용하다고 한다.

단일 책임 구성 원칙 (SRP)를 달성하는 것이 가장 주된 목적이며, 일회성으로 이용하는 부분들은 플러그인으로 만드는 것 보다는 각 모듈에서 직접 정의하는 것이 좋다는 내용이다.

 

 

Build-logic 이해하기

나는 이해력이 느려서 이 부분에서 정말 오래 공부하며 머물렀던 것 같다.

하지만, 한 번 이해하면 어떤 내용인지 확실하게 알 수 있으며, 내가 스스로 이해했던 과정에서 어려웠던 부분을 최대한 이해하기 쉽게 풀어 써보려 한다.

 

안드로이드에서 모듈을 생성하려 하면 아래와 같이 많은 종류가 나오게 된다.

 

이 중 가장 많이 쓰는 부분은 Java or Kotilin Library 와, Android Library이다.

 

 

Java or Kotlin Library와 Android Library의 차이

두 라이브러리의 차이는 다음과 같다.

	1. Java/Kotlin 모듈	2. Android 라이브러리 모듈
목적	순수한 Java 또는 Kotlin 코드만 포함하며, 플랫폼 독립적입니다.	Android 프로젝트에서 재사용 가능한 UI 및 로직을 포함한 라이브러리 개발.
사용 예시	플랫폼에 구애받지 않는 유틸리티 코드 작성  (e.g., 문자열 처리, 데이터 변환). 백엔드와 공용으로 사용할 비즈니스 로직 작성. Gradle 멀티플랫폼 프로젝트의 공유 코드 작성.	공용 UI 컴포넌트, 레이아웃, 스타일을 포함한 모듈 작성. Android SDK를 사용하는 네트워크 호출, 데이터베이스, 권한 요청 등의 기능 구현. 앱의 기능을 캡슐화하여 재사용 가능한 라이브러리 생성.
구성	build.gradle.kts 파일에 java-library 또는 kotlin 플러그인을 사용. Android SDK에 의존하지 않으므로 Android API를 사용할 수 없습니다. Android 관련 종속성은 추가할 수 없으며, 순수 Java/Kotlin 종속성만 가능합니다.	build.gradle.kts 파일에 com.android.library 플러그인을 사용. AndroidManifest.xml 파일이 필요하며, Android 전용 API를 사용할 수 있습니다. XML 리소스 파일 (레이아웃, Drawable, Values) 및 Android 종속성을 포함할 수 있습니다.
코드 예시	plugins {     id("java-library") // 또는 id("kotlin") } dependencies {     implementation("org.jetbrains.kotlin:kotlin-stdlib") }	plugins {     id("com.android.library")     id("org.jetbrains.kotlin.android") } android {     compileSdk = 33     defaultConfig {         minSdk = 21         targetSdk = 33     } }
출력물	JAR 파일로 빌드됩니다. JAR 파일은 플랫폼에 독립적으로 사용할 수 있습니다.	AAR 파일로 빌드됩니다 (Android Archive). AAR 파일은 Android 프로젝트에서만 사용할 수 있으며, XML 리소스 및 AndroidManifest.xml을 포함합니다.
장점	가볍고 빠름: Android SDK를 포함하지 않아 빌드 속도가 빠릅니다. 재사용성: Java 또는 Kotlin 코드만 포함하므로 다양한 플랫폼에서 사용할 수 있습니다.	Android 전용 API 사용 가능: Android SDK의 기능을 자유롭게 사용할 수 있습니다. 리소스 포함 가능: XML 리소스 파일, Drawable, Styles 등을 포함하여 재사용 가능한 UI 구성 요소를 제공.

 

정리해보면, Java or Kotlin 라이브러리는 순수 언어만 포함, Anrodi Library는 UI로직을 포함한 라이브러리 개발에 특화되었다는 것을 알 수 있다.

 

 

 

Build-logic 만들어보기

그러면 이제 build-logic 모듈을 만들어보자.

 

1. File > New > New Module

 

 

2. Java or Kotlin Library로 만들어주기

 

위 과정을 거치 Pjoject 수준의 app 폴더 및에 build-logic 모듈이 추가된 것을 볼 수 있다.

 

3. 이제 convention 모듈을 만들 차례이다. 똑같은 방법으로 build-logic 아래에 convention 모듈을 만들어 주자

 

4. settings.gradle, gradle.properties 설정을 해주어야 한다. build-logic 모듈에서 build-gradle 밖에 없을 것이다.   settings.gradle, gradle.properties를 만들어준다.

 

5. gradle.properties 설정

# local.properties (build-logic Module)
org.gradle.parallel=true
org.gradle.caching=true
org.gradle.configureondemand=true

 

 

6. settings.gradle도 만들어 주어야 한다. 버전 카탈로그를 이용할 것이다.

 

버전 카탈로그란?

버전을 통합 관리 할 수 있도록 모든 라이브러리 및 버전 정보가 써져있는 파일이라고 생각하면 된다.

 

보통 프로젝트 생성 시 gradle > libs.versions.toml 이라는 파일로 정의되어 있다.

versions, libraries, plugins 등을 정의할 수 있다.

# ./gradle/libs.versions.toml

[versions]
# 버전을 정의

[libraries]
# 라이브러리 정의

[plugins]
# 플로그인 정의

 

 

그러면 settings.gradle에서 해당 파일을 지정해주는 코드를 써주겠다.

dependencyResolutionManagement {
    repositoriesMode.set(RepositoriesMode.FAIL_ON_PROJECT_REPOS)
    repositories {
        google()
        mavenCentral()
    }
    versionCatalogs {
        create("libs") {
            from(files("../gradle/libs.versions.toml"))
        }
    }
}

rootProject.name = "build-logic"
include(":convention")

 

 

7. 여기까지 완료했다면 build-logic을 전체 프로젝트에 포함시켜 줄 차례이다.

프로젝트 수준의 settings.gradle 파일안에 includeBuild를 이용하여 해당 모듈을 포함시켜준다.

pluginManagement {
    includeBuild("build-logic") //요 부분
    repositories {
        google {
            content {
                includeGroupByRegex("com\\.android.*")
                includeGroupByRegex("com\\.google.*")
                includeGroupByRegex("androidx.*")
            }
        }
        mavenCentral()
        gradlePluginPortal()
    }
}
dependencyResolutionManagement {
    repositoriesMode.set(RepositoriesMode.FAIL_ON_PROJECT_REPOS)
    repositories {
        google()
        mavenCentral()
    }
}

rootProject.name = "My Application"
include(":app")

 

만약 하단 include(":app") 부분 밑에 include(":build-logic")이나, include(":convention") 혹은, include("build-logic:convention")이 있을 경우 지워주어야 한다. (해당 모듈은 따로 관리되므로)

 

여기까지가 build-logic에 대한 기초 세팅이다.

다음 포스팅에서는 convention 모듈을 이용해 빌드 스크립트의 공통된 부분을 분리해보는 것과, 플러그인을 만들어 연결하는 것을 작성해 보겠다.