Android DI(의존성 주입) - 개요

구글의 Android 권장 아키텍처(Architecture Guidelines) 에서는 Android 계층 구조 안에서 결합도를 낮추고, 테스트 가능성과 재사용성을 높이기 위해 DI 사용을 권장한다고 한다.

그렇다면, DI를 알아보자

 

의존성 주입(DI)  : 클래스가 스스로 의존 객체를 생성하지 않고, 외부에서 주입받는 방식

 

먼저 "의존성"이란 어떤 객체가 다른 객체를 사용할 때 그 객체에 '의존'한다는 의미

class Car {
    private val engine = Engine()  // Car는 Engine에 의존하고 있음
}

 

 

이게 뭐가 문제인가?

1. 테스트 어려움

Engine()을 직접 생성하므로, 테스트할 때 FakeEngine을 넣기 힘듦

 

2. 유지보수 어려움

Engine에서 TurboEngine으로 바꾸려면 모든 코드를 수정해야 함

 

3. 재사용성 저하

Car가 항상 Engine을 직접 생성하므로, 다양한 엔진을 사용하는 Car를 만들 수 없음

 

그렇다면 해결 방법은?

외부에서 객체를 생성해서 넣어준다, 이것이 바로 의존성 주입(Dependency Injection, DI)

val fakeEngine = FakeEngine() 
val car = Car(fakeEngine) // FakeEngine 같은 테스트 전용 객체를 쉽게 넣을 수 있다.

val turboCar = Car(TurboEngine()) // Engine을 바꾸고 싶을 때, Car 코드를 건드릴 필요가 없다.

 

 

이렇게 외부에서 의존성을 넣어주는 방법은 세가지로 나뉜다. (다음 예시는 Hilt 기반이다.)

 

1. 생성자 주입 방식

class Car @Inject constructor(private val engine: Engine)

 

2. 필드 주입 방식

class Car {
    @Inject
    lateinit var engine: Engine
}

3. 메서드 주입 방식

class Car {
    lateinit var engine: Engine

    @Inject
    fun setEngine(engine: Engine) {
        this.engine = engine
    }
}

 

 

그리고, 이런 의존성 주입을 도와주는 DI 라이브러리들이 있으며 Android에서 주로 사용하는 DI 라이브러리는 다음과 같다.

 

Hilt (구글 공식 DI)

• Dagger 2 기반의 Android 특화 DI 라이브러리
• Google의 Jetpack 라이브러리들과 완벽하게 통합
• 어노테이션 기반 자동 주입 (@Inject, @HiltViewModel, @AndroidEntryPoint 등)
• 권장 아키텍처에서 기본으로 사용하는 DI 프레임워크
• 생명주기 범위 관리도 자동 지원 (@Singleton, @ActivityScoped 등)

---

Dagger 2 (Hilt의 기반 기술)

• Java와 Kotlin에서 사용 가능한 컴파일 타임 DI 프레임워크
• Hilt 없이도 쓸 수 있지만, 구현이 복잡하고 boilerplate가 많음
• 고성능, 정적 코드 분석 기반 → 런타임 성능 최상
• 더 많은 제어와 커스터마이징이 가능하지만, 복잡한 그래프 구성 필요
• Hilt를 도입하지 못하는 레거시 프로젝트나 멀티플랫폼 프로젝트에서 여전히 사용됨.

---

Koin

• Kotlin에 특화된 경량 DI 프레임워크
• 어노테이션이 아닌 DSL 기반 설정 (코드가 매우 간단함)
• 컴파일 타임이 아니라 런타임에 주입되기 때문에 유연함
• Hilt보다 진입 장벽이 낮고 테스트도 간단하게 작성 가능

---

각각의 세부 내용은 다음 포스팅에서 정리 되어있다.

 

결론적으로, 의존성 주입의 핵심은

"필요한 객체를 클래스 안에서 만들지 않고, 외부에서 받아서 사용하는 것"

즉, 객체의 생성 책임을 분리해서 코드의 유연성을 높이는 것이 목적이다.