온보딩 프로젝트를 통한 안드로이드 멀티모듈 도입기
안녕하세요 서비스 개발팀 Android 신입 개발자 Stephen 입니다.
저는 현재 안드로이드 개발을 할 때 멀티 모듈 방식을 사용하고 있으며
이번 온보딩 프로젝트(To-do List App)에 처음으로 멀티 모듈 방식을 도입하게 되었습니다.
저는 회사에 들어오기전 제가 진행했던 안드로이드개인 프로젝트나
공부에서는 모두 하나의 앱모듈에서 코드를 작성해왔습니다.
하나의 앱 모듈에 작성되어있고 패키지로만 레이어를 구분해 왔습니다.
각 레이어 별로 모듈을 나눴고 또 그 안에서 화면이나 기능 별로 나눠져 있습니다.
처음 코드를 분석하면서 특정 작업이나 화면에 대한 코드를 찾기 편리했습니다.
모듈은 소스 파일 및 빌드 설정으로 구성된 모음이며,
이를 통해 프로젝트를 별개의 기능 단위로 분할할 수 있습니다.
프로젝트에는 하나 이상의 모듈이 포함될 수 있습니다.
하나의 모듈이 다른 모듈을 종속성으로 사용할 수 있습니다.
안드로이드 프로젝트를 만들면 자동으로 생성되는 app도 하나의 모듈입니다.
Application(Phone & Tablet)
앱을 실행하기에 반드시 필요한 모듈이며 빌드의 결과로 APK 파일을 생성합니다.
안드로이드 프로젝트를 만들때 기본으로 생성되는 app 모듈 또한 Application 모듈입니다.
Android Library
안드로이드 프로젝트에서 지원되는 모든 파일 형식을 포함할 수 있습니다.
(소스코드, 리소스 파일, 매니페스트)
Android 앱 모듈의 종속 항목으로 사용할 수 있습니다.
빌드의 결과로는 AAR 파일이 생성됩니다.
Java or Kotlin Library
순수한 Java 혹은 Kotlin으로만 이루어진 모듈입니다.
안드로이드 프레임워크로 독립적인 기능을 구현할 때 사용합니다.
빌드의 결과로는 JAR 파일이 생성됩니다.
Module은 File → New → New Module로 생성이 가능하며 현재 모든 build.gradle 파일은 kts 파일로 제작 혹은 변환하였습니다. (Groovy → Kts)
의존성을 줄일 수 있습니다. (관심사 분리)
기존의 단일 모듈 방식에서는 실수로 의존성 규칙을 위반할 수 있지만
멀티 모듈 방식을 사용하면 build.gradle 파일에서 의존성을 추가하지 않으면
다른 모듈의 코드를 사용할 수 없기 때문에 의존성 규칙을 쉽게 관리 가능합니다.
빌드 시간 감소를 기대할 수 있습니다.
기본적으로 빌드를 할때 변경된 모듈만 빌드하므로 빌드 시간 감소를 기대할 수 있습니다.
하지만 모듈간 종속성이 복잡해지고 모듈의 수정이 많다면 빌드 시간이 증가될 수 있습니다.
코드 재사용성이 높아집니다.
레이어별, 기능별로 모듈을 나눠서 코드를 작성하게되면 해당 기능이 필요할때
해당 모듈에 대한 의존성을 추가해서 사용하면 되기 때문에 재사용성이 높아집니다.
모듈 단위 테스트를 할 수 있습니다.
온보딩 프로젝트는 Android Clean Architecture를 기반으로 구성되어있으며
Layer 별로 모듈을 구성했습니다.
Clean Architecture를 기반으로 3개의 모듈 + app모듈로 구성되어있습니다.
Application Module → app
Android Library → presentation, data
Java or Kotlin Library → domain
domain Module은 안드로이드 의존성을 갖지않고 Java or Kotlin 코드로만 작성되어 있어
Java or Kotlin Library Module로 만들었습니다.
app 모듈을 사용하는 이유는 매니페스트 파일 설정과 Hilt 의존성 주입, Hilt 앱설정을 위해 사용합니다.
Clean Architecture의 의존 방향처럼
Presenetation → domain ← data 형식으로 의존성을 설정했습니다.
presentation module의 build.gradle (domain 모듈에 의존하고있음)
data Module의 build.gradle (domain 모듈의 Repository 인터페이스에 의존하고있음)
domain Module의 build.gradle (아무 모듈에도 의존하지 않는 순수한 모듈)
외부 라이브러리만 사용하고 있음
app Module 의 build.gradle
(Activity정보를 알기위해 presentation모듈,
레포지토리 구현체를 만들어야 하기때문에 모든 모듈을 알고있음)
현재 domain Module에서 Repository의 인터페이스를 만들고
data Module에서 Repository의 구현체를 만들었습니다. (의존성 역전)
data Module에서 만든 구현체 (일부만 발췌)
data Module 에서 만든 Hilt Module
이렇게 Hilt를 사용하면 Multi Module 프로젝트를 좀 더 쉽게 구성할 수 있습니다.
이상으로 온보딩 프로젝트에 멀티모듈을 도입한 이유, 과정에대해 소개해드렸습니다.
추가적으로 온보딩 프로젝트에서 빌드 종속 항목을 추가할때 사용한
gradle version catalog에대해 설명드리겠습니다.
위의 코드를 보시면 기존의 빌드 종속 항목을 추가할때의 방식이 아닌 다른 방식을 사용하고있습니다.
그 방식의 이름은 gradle version Catalog입니다.
위의 방식은 기존에 종속성을 추가할때 사용하던 방식이고
아래 방식이 바로 gradle version catalog입니다.
기존에 사용하던 방식에서 gradle version catalog로 전환하면서 몇가지 장점이 존재했습니다.
하나의 파일로 여러 프로젝트 및 모듈의 버전 관리를 통합할 수 있습니다.
특히 멀티모듈을 진행하면서 같은 의존성을 모듈마다 추가해주는 경우가 있는데
이럴 경우 하나의 파일에서 버전을 쉽게 관리할 수 있습니다.
함께 사용되는 의존성들을 bundle로 묶어 사용할 수 있습니다.
ex) navigation에 해당하는 의존성들을 하나로 묶어 사용할 수 있습니다.
각 카탈로그 별로 자동 완성을 지원하여 편리하게 사용 가능합니다.
Gradle 버전 7.4 부터 정식 지원합니다. 해당 버전 미만일 경우 수동으로
toml 파일 위치를 지정해줘야합니다.
따라서 Gradle 7.4 이상을 사용하시는 것을 권장합니다 (온보딩 프로젝트에는 현재 버전 7.4 사용중입니다.)
gradle 파일 밑에 libs.versions.toml 파일을 생성합니다.
Project단위로 확인하시면 쉽게 보실 수 있습니다.
현재 사용중인 toml 파일의 일부만 발췌해 왔습니다.
versions : 라이브러리들의 버전
libraries : 라이브러리 의존성
bundles : 라이브러리들을 묶어 한번에 선언
toml 문법을 모르더라도 쉽게 읽을 수 있으며 또 작성할 수 있습니다.
이제 각 모듈 별로 catalog를 불러와 의존성을 추가할 수 있습니다.
여기서 만약 자동완성이나 추가가 안된다면 sync now를 하시는걸 추천드립니다.
여기까지 Multi Module을 도입하면서 같이 사용하면 좋을 version catalog까지 소개했습니다.
오늘보다 더 나은 개발자
꾸준히 발전하는 개발자가 되고싶은 서비스개발팀의 안드로이드 개발자 Stephen입니다.
같이보면 좋은 자료
현재 사용하고 있는 build gradle은 kts 버전으로 작성되어있습니다.
gradle version catalog : https://docs.gradle.org/current/userguide/platforms.html
build gradle groovy → kts
https://developer.android.com/studio/build/migrate-to-kts?hl=ko
참조
android Module : https://developer.android.com/studio/projects/android-library?hl=ko