Gradle Kotlin 컨벤션 플러그인을 사용한 모듈 관리 -1 멀티모듈의 도입

TRASALBY·2024년 4월 23일
0

Android

목록 보기
8/10
post-custom-banner

기능단위의 모듈 구분

새로운 프로젝트를 시작하면서 컴포즈와 함께 feature단위의 멀티모듈을 도입해 보기로 했다. 그리고 그 선택은 쉽지 않을 길이었다...

우선 수많은 github의 코드를 참고하며 모듈의 구분 단위를 고민해 보았고 그 결과 우선적으로

app, data, domain
core:ui, core:model, core:designsystem
feature:...

로 구분해 보고 이후 개발에 들어가면서 구조를 수정해보기로 했다. (첫 시도기 때문에 분명 나중에 수정될 것이다...)

수많은 보일러플레이트 코드

우선 왕창 모듈들을 생성하고 세팅을 해보려고 하니 뭔가 이상했다.

1. 컴포즈를 사용하는 모듈이 하나 추가 될 때마다 수많은 컴포즈 관련 dependency가 추가되어야 한다.

2. feature모듈에서 공통으로 사용할 목적으로 만든 core 모듈들을 매번 각 feature에서 추가해주어야 한다.

이건 뭔가 이상하다고 느꼈다.. 분명 공통적인 부분을 밖으로 빼낼 수 있는 무언가가 있을거야

buildSrc...? build-logic...?

사실 이전에도 공통된 dependency를 밖으로 빼서 처리를 하긴 했었다. buildSrc 모듈을 통해 모든 모듈에서 사용되는 dependency들을 코틀린 변수로 관리하고 버전의 변경이 생기면 한번에 수정하도록 말이다. 하지만 결국 각 dependency에 대해서는 하나씩 implementation을 선언해 주어야 하는 귀찮음이 있었다.

사실 feature모듈의 기본적인 구조는 모두 같을 것이기에 이를 한번에 추가할 수 있는 무언가를 찾다가 build-logic을 사용해 커스텀 plugin을 생성하고 사용하는 방법을 확인할 수 있었다!

Plugin

사실 안드로이드 개발을 하면서 plugin은 계속 사용해 오고 있었다.

plugins {
    id("com.android.application")
    id("org.jetbrains.kotlin.android")
}

익숙한 코드이다. 매번 안드로이드 프로젝트를 생성하고 자동으로 만들어진 gradle파일을 보면 제일 위에 위치하고있는 코드이다.

사실 부끄럽지만 plugin이 어떤 역할을 하는지 잘 모르고 있었다. 매번 필요할 때 추가만 했을 뿐... 이번 기회에 알 수 있게 되어서 다행이다.

post-custom-banner

0개의 댓글