Android Academy · 강의

모듈 종속성 관리

의존성 그래프를 깔끔하고 비순환적으로 유지합니다.

모듈 종속성 관리은(는) CoddyKit의 무료 Android Academy 강의입니다. 이것은 4개 중 3번째 강의입니다. 아래에서 전체 강의를 무료로 읽을 수 있으며, 내장 코드 에디터와 24/7 AI 튜터와 함께 브라우저에서 직접 실습할 수 있습니다. 이 강의는 Android Academy 학습 경로의 일부이며, 진행 상황이 웹과 CoddyKit 앱에 동기화됩니다. Android Academy 강의에는 총 4개의 강의가 포함되어 있습니다.

의존성 그래프

모든 모듈은 자신이 의존하는 다른 모듈을 선언합니다. 이 선언을 모두 합치면 의존성 그래프가 됩니다. 건강한 그래프는 DAG(방향성 비순환 그래프)입니다. 의존성이 한 방향으로 향하며 순환을 만들지 않습니다.

이 레슨에서는 의존성을 깔끔하게 선언하고, 적절한 Gradle 구성을 선택하며, 버전을 공유하고, 순환을 방지하는 방법을 배웁니다.

모듈 의존성 선언하기

dependencies 블록 안에서 project(":path:to:module")을 사용하면 다른 모듈에 대한 의존성을 추가할 수 있습니다. 경로는 폴더 구조를 반영하며 settings.gradle.kts에서 선언한 내용과 일치해야 합니다.

// feature/profile/build.gradle.kts
dependencies {
    implementation(project(":core:data"))
    implementation(project(":core:designsystem"))
    implementation(project(":core:model"))
}

implementation과 api

선택한 구성에 따라 소비자에게 노출되는 항목이 달라집니다.

implementation: 의존성이 비공개입니다. 나에게 의존하는 모듈은 이 의존성을 볼 수 없습니다. 기본적으로 선택되는 방식입니다.
api: 의존성이 다시 노출됩니다(전이적). 공개 타입이 해당 의존성에서 제공될 때만 사용합니다.

거의 항상 implementation을 우선 사용하세요. 숨겨진 의존성이 변경되어도 소비자를 다시 컴파일할 필요가 없으므로 빌드 속도가 향상됩니다.

// core/data/build.gradle.kts
dependencies {
    // Repository signatures return :core:model types,
    // so consumers need to SEE it -> api
    api(project(":core:model"))

    // Network is an internal detail -> implementation
    implementation(project(":core:network"))
}

implementation이 빌드를 빠르게 하는 이유

implementation을 사용하면 Gradle은 숨겨진 의존성의 변경이 모듈의 공개 ABI에 영향을 줄 수 없다는 사실을 알 수 있습니다. 따라서 소비자를 다시 컴파일할 필요가 없습니다. api를 사용하면 변경 사항이 모든 전이적 소비자에게 전파됩니다.

간단한 기준은 다음과 같습니다. 의존성이 모듈의 공개 타입(반환 타입, 공개 매개변수)에 나타날 때만 api에 넣으세요. 그 외에는 implementation을 사용합니다.

// Public -> needs api
fun observeUser(): Flow<User>   // Flow and User leak out

// Internal -> implementation is enough
private val client: OkHttpClient // never exposed

버전 중앙화하기: 버전 카탈로그

모듈이 많아지면 모든 곳에 라이브러리 버전을 반복해서 작성하고 싶지 않을 것입니다. Gradle의 버전 카탈로그(gradle/libs.versions.toml)는 버전과 별칭을 한 번만 정의합니다. 모든 모듈은 동일한 별칭을 참조합니다.

# gradle/libs.versions.toml
[versions]
compose-bom = "2024.09.00"
retrofit = "2.11.0"

[libraries]
compose-bom = { group = "androidx.compose", name = "compose-bom", version.ref = "compose-bom" }
retrofit = { group = "com.squareup.retrofit2", name = "retrofit", version.ref = "retrofit" }

모듈에서 카탈로그 사용하기

그러면 모듈은 생성된 libs 접근자를 통해 라이브러리를 참조합니다. 빌드 파일에 버전 번호가 없으므로 업그레이드를 한 곳에서 처리할 수 있습니다.

// core/network/build.gradle.kts
dependencies {
    implementation(platform(libs.compose.bom))
    implementation(libs.retrofit)
}

절대 피해야 할 것: 순환

순환이란 모듈 A가 B에 의존하고 B가 직접 또는 다른 모듈을 거쳐 다시 A에 의존하는 경우입니다. Gradle은 순환 의존성이 있는 빌드를 거부합니다. 또한 이는 설계에 문제가 있다는 신호이기도 합니다. 두 모듈 사이의 경계가 잘못된 것입니다.

// :feature:cart  -> implementation(project(":feature:checkout"))
// :feature:checkout -> implementation(project(":feature:cart"))
//
// Gradle error:
// Circular dependency between the following tasks:
// :feature:cart:compile -> :feature:checkout:compile -> :feature:cart:compile

순환 끊기

순환을 끊으려면 공유 부분을 두 모듈이 모두 의존할 수 있는 더 낮은 모듈로 추출합니다. 두 기능이 서로의 데이터를 필요로 한다면 공유 계약은 어느 한 기능이 아니라 핵심 모듈에 두어야 합니다.

이렇게 하면 아래 방향의 흐름이 회복됩니다. 두 기능은 핵심 모듈을 향하고, 핵심 모듈은 다시 위를 향하지 않습니다.

// Before: cart <-> checkout (cycle)
// After:  cart -> :core:order  <-  checkout

// core/order/OrderContract.kt
data class Order(val items: List<CartItem>, val total: Double)

// feature/cart    -> implementation(project(":core:order"))
// feature/checkout-> implementation(project(":core:order"))

반전: 추상화에 의존하기

때로는 낮은 수준의 모듈이 더 높은 수준에 있는 동작을 필요로 합니다. 위쪽 모듈에 의존하는 대신 낮은 모듈에 인터페이스를 정의하고, 높은 모듈이 의존성 주입을 통해 구현을 제공하게 하세요. 이것이 의존성 역전입니다.

// core/analytics defines the contract
interface AnalyticsLogger {
    fun log(event: String)
}

// :app provides the real implementation and injects it down
@Module
@InstallIn(SingletonComponent::class)
object AnalyticsModule {
    @Provides
    fun logger(impl: FirebaseAnalyticsLogger): AnalyticsLogger = impl
}

그래프 시각화 및 보호하기

Gradle에 모듈 그래프를 출력하거나 렌더링하도록 요청할 수 있으며, 금지된 의존성이 나타나면 빌드가 실패하도록 하는 시험도 추가할 수 있습니다(예: 핵심 모듈이 기능 모듈에 의존하는 경우). module-graph 플러그인과 같은 도구는 다이어그램을 자동으로 생성합니다.

# Print the project structure
./gradlew projects

# Inspect why :feature:home pulls in a library
./gradlew :feature:home:dependencies --configuration debugRuntimeClasspath

깔끔하고 비순환적인 예

다음은 건강한 그래프입니다. 위에서 아래로 읽어 보세요. 화살표가 위로 되돌아가지 않고, 서로를 가리키는 모듈 쌍도 없습니다. 바로 이것이 목표하는 구조입니다.

// :app
//   -> :feature:home   -> :core:data -> :core:network -> :core:model
//   -> :feature:profile -> :core:data -> :core:database -> :core:model
//   -> :core:designsystem
//
// Every path ends at :core:model. No cycles. Builds in parallel.

빠른 확인

:core:network 모듈이 OkHttpClient를 내부적으로만 사용하고 공개 함수 시그니처에는 전혀 나타나지 않습니다. OkHttp 의존성을 선언할 때 어떤 Gradle 구성을 사용해야 할까요?

복습: 모듈 의존성 관리

모듈 그래프를 건강하게 유지하는 방법을 배웠습니다.

project(":path")로 모듈 의존성을 선언합니다.
기본적으로 implementation을 사용하고, 공개 영역의 타입에 필요할 때만 api를 사용합니다.
버전 카탈로그(libs.versions.toml)에서 버전을 중앙 관리합니다.
순환을 절대 만들지 마세요. Gradle은 순환을 거부하므로 공유 코드를 아래쪽으로 추출하거나 인터페이스를 사용해 역전하는 방식으로 순환을 끊어야 합니다.

다음에는 기능 사이의 결합 없이 탐색을 통해 기능을 연결합니다.

자주 묻는 질문

“모듈 종속성 관리” 강의는 무료인가요?

네 — “모듈 종속성 관리” 전체 내용을 이 웹사이트에서 무료로 읽을 수 있습니다. 인터랙티브하게 실습하려면(내장 코드 에디터와 24/7 AI 튜터), CoddyKit PRO로 업그레이드하면 Android Academy 강의 전체를 잠금 해제할 수 있습니다. Android Academy 강의에는 총 4개의 강의가 포함되어 있습니다.

“모듈 종속성 관리”에서 뭘 배우나요?

의존성 그래프를 깔끔하고 비순환적으로 유지합니다. 브라우저에서 직접 실행하는 실습 코드로 Android Academy을(를) 배우며, 24/7 AI 튜터가 강의를 진행하면서 질문에 답변해줍니다.

Android Academy을(를) 시작하는 데 경험이 필요한가요?

사전 경험은 필요하지 않습니다. CoddyKit의 Android Academy은(는) 초급자부터 고급 학습자까지를 위해 구성되어 있으므로, 여기서 시작하거나 처음부터 시작할 수 있으며 자신의 속도대로 진행할 수 있습니다. 이것은 4개 중 3번째 강의입니다.

“모듈 종속성 관리” 강의는 얼마나 걸리나요?

대부분의 CoddyKit 강의는 약 5~10분이 소요됩니다. 각 강의는 간결하고 인터랙티브하여 꾸준한 진행이 가능하며, 웹과 앱에서 중단한 부분부터 바로 시작할 수 있습니다.

이 Android Academy 강의에서 코드를 작성하고 실행할 수 있나요?

네. 모든 Android Academy 강의에는 내장 코드 에디터가 포함되어 있으므로, 브라우저에서 바로 실제 코드를 작성하고 실행한 후 즉시 AI 피드백을 받을 수 있습니다 — 로컬 설정이 필요 없습니다.

이 강의의 모든 강의

← Android Academy(으)로 돌아가기