안드로이드 개발자 노트

[Android] MVI 패턴

어리둥절범고래 — Tue, 7 Apr 2026 01:32:11 +0900

MVVM은 안드로이드에서 많이 사용되는 아키텍처이지만, 화면이 복잡해질수록 상태가 여러 LiveData나 StateFlow로 나뉘어 관리되는 경우가 많습니다.

이렇게 되면 현재 화면 상태를 한눈에 파악하기 어렵고, 상태 변경 흐름을 추적하거나 디버깅하는 것도 복잡해질 수 있습니다.

또한 DataBinding이나 양방향 바인딩을 함께 사용할 경우, View와 ViewModel 사이의 상태 변경 흐름이 분산되어 유지보수가 어려워질 수 있습니다.

예를 들어 로그인 화면에서 ViewModel이 여러 LiveData로 상태를 나눠서 View와 상호작용하는 경우는 아래처럼 볼 수 있습니다.

class LoginViewModel : ViewModel() {

    private val _email = MutableLiveData("")
    val email: LiveData<String> = _email

    private val _password = MutableLiveData("")
    val password: LiveData<String> = _password

    private val _isLoading = MutableLiveData(false)
    val isLoading: LiveData<Boolean> = _isLoading

    private val _errorMessage = MutableLiveData<String?>(null)
    val errorMessage: LiveData<String?> = _errorMessage

    private val _loginSuccess = MutableLiveData(false)
    val loginSuccess: LiveData<Boolean> = _loginSuccess

    fun onEmailChanged(value: String) {
        _email.value = value
    }

    fun onPasswordChanged(value: String) {
        _password.value = value
    }

    fun login() {
        val currentEmail = _email.value.orEmpty()
        val currentPassword = _password.value.orEmpty()

        _isLoading.value = true
        _errorMessage.value = null

        if (currentEmail == "test@test.com" && currentPassword == "1234") {
            _loginSuccess.value = true
        } else {
            _errorMessage.value = "로그인에 실패했습니다."
        }

        _isLoading.value = false
    }
}

View에서는 각각의 LiveData를 따로 관찰하면서 UI를 업데이트합니다.

class LoginActivity : AppCompatActivity() {

    private lateinit var binding: ActivityLoginBinding
    private val viewModel: LoginViewModel by viewModels()

    override fun onCreate(savedInstanceState: Bundle?) {
        super.onCreate(savedInstanceState)
        binding = ActivityLoginBinding.inflate(layoutInflater)
        setContentView(binding.root)

        binding.emailEditText.doOnTextChanged { text, _, _, _ ->
            viewModel.onEmailChanged(text.toString())
        }

        binding.passwordEditText.doOnTextChanged { text, _, _, _ ->
            viewModel.onPasswordChanged(text.toString())
        }

        binding.loginButton.setOnClickListener {
            viewModel.login()
        }

        viewModel.isLoading.observe(this) { isLoading ->
            binding.progressBar.isVisible = isLoading
            binding.loginButton.isEnabled = !isLoading
        }

        viewModel.errorMessage.observe(this) { message ->
            binding.errorTextView.text = message.orEmpty()
            binding.errorTextView.isVisible = !message.isNullOrEmpty()
        }

        viewModel.loginSuccess.observe(this) { success ->
            if (success) {
                startActivity(Intent(this, HomeActivity::class.java))
            }
        }
    }
}

반면, MVI는 상태를 단일 소스로 관리하고 단방향 데이터 흐름을 따르는 것으로 상태 관리의 일관성을 유지하고 디버깅을 용이하게 합니다.
또한, MVI는 Intent를 통해 사용자 행동을 처리합니다. 이는 View와 ViewModel 간의 상호작용을 단일화하여, 코드의 가독성과 유지보수를 향상시킵니다.

MVI는 세 가지 주요 구성 요소로 이루어져 있습니다.

Intent: Intent는 사용자의 행동이나 이벤트를 나타냅니다. 버튼 클릭, 스크롤, 또는 데이터 입력 등
State: State는 애플리케이션의 현재 상태를 나타냅니다. UI를 렌더링하는 데 필요한 모든 데이터를 포함
Reducer: Reducer는 이전 상태와 Intent를 받아 새로운 상태를 생성하는 함수입니다. Reducer는 현재 상태와 전달된 Intent를 받아 새로운 상태를 생성하는 역할을 하며, 상태 변경 규칙을 한 곳에 모아 관리할 수 있도록 해줍니다.

// 사용자의 행동을 Intent로 정의합니다.
sealed interface LoginIntent {
    data class EmailChanged(val value: String) : LoginIntent
    data class PasswordChanged(val value: String) : LoginIntent
    data object LoginClicked : LoginIntent
    data object LoginSucceeded : LoginIntent
    data class LoginFailed(val message: String) : LoginIntent
}

// 화면 상태를 하나의 객체로 정의합니다.
data class LoginUiState(
    val email: String = "",
    val password: String = "",
    val isLoading: Boolean = false,
    val errorMessage: String? = null
)

// 한 번만 처리되어야 하는 이벤트를 SideEffect로 정의합니다.
sealed interface LoginSideEffect {
    data object NavigateToHome : LoginSideEffect
    data class ShowToast(val message: String) : LoginSideEffect
}

// Reducer는 이전 상태와 Intent를 받아 새로운 상태를 생성합니다.
fun reducer(
    oldState: LoginState,
    intent: LoginIntent
): LoginState {
    return when (intent) {
        is LoginIntent.EmailChanged -> {
            oldState.copy(
                email = intent.email,
                errorMessage = null
            )
        }

        is LoginIntent.PasswordChanged -> {
            oldState.copy(
                password = intent.password,
                errorMessage = null
            )
        }

        LoginIntent.LoginClicked -> {
            oldState.copy(
                isLoading = true,
                errorMessage = null,
            )
        }
    }
}

class LoginViewModel(
    private val repository: LoginRepository = LoginRepository()
) : ViewModel() {

    private val _uiState = MutableStateFlow(LoginUiState())
    val uiState: StateFlow<LoginUiState> = _uiState.asStateFlow()

    private val _sideEffect = Channel<LoginSideEffect>()
    val sideEffect = _sideEffect.receiveAsFlow()

    fun onIntent(intent: LoginIntent) {
        when (intent) {
            is LoginIntent.EmailChanged,
            is LoginIntent.PasswordChanged -> {
                _uiState.value = reducer(_uiState.value, intent)
            }

            LoginIntent.LoginClicked -> {
                login()
            }
        }
    }

    private fun login() {
        val currentState = _uiState.value
        if (currentState.email.isBlank()) {
            viewModelScope.launch {
                _sideEffect.send(LoginSideEffect.ShowToast("이메일을 입력해주세요."))
            }
            return
        }
        if (currentState.password.isBlank()) {
            viewModelScope.launch {
                _sideEffect.send(LoginSideEffect.ShowToast("비밀번호를 입력해주세요."))
            }
            return
        }
        _uiState.value = reducer(_uiState.value, LoginIntent.LoginClicked)
        val snapshot = _uiState.value
        viewModelScope.launch {
            repository.login(
                email = snapshot.email,
                password = snapshot.password
            ).onSuccess {
                _uiState.value = reducer(_uiState.value, LoginIntent.LoginSucceeded)
                _sideEffect.send(LoginSideEffect.NavigateToHome)
            }.onFailure { throwable ->
                val message = throwable.message ?: "로그인에 실패했습니다."
                _uiState.value = reducer(_uiState.value, LoginIntent.LoginFailed(message))
            _sideEffect.send(LoginSideEffect.ShowToast(message))
            }
        }
    }
}

@Composable
fun LoginScreen(
    viewModel: LoginViewModel,
    onNavigateToHome: () -> Unit
) {
    val uiState by viewModel.uiState.collectAsState()
    val context = LocalContext.current

    LaunchedEffect(Unit) {
        viewModel.sideEffect.collect { effect ->
            when (effect) {
                LoginSideEffect.NavigateToHome -> onNavigateToHome()
                is LoginSideEffect.ShowToast -> {
                    Toast.makeText(context, effect.message, Toast.LENGTH_SHORT).show()
                }
            }
        }
    }

    Column(
        modifier = Modifier
            .fillMaxSize()
            .padding(24.dp),
        verticalArrangement = Arrangement.spacedBy(12.dp)
    ) {
        OutlinedTextField(
            value = uiState.email,
            onValueChange = { viewModel.onIntent(LoginIntent.EmailChanged(it)) },
            label = { Text("이메일") },
            modifier = Modifier.fillMaxWidth(),
            enabled = !uiState.isLoading
        )

        OutlinedTextField(
            value = uiState.password,
            onValueChange = { viewModel.onIntent(LoginIntent.PasswordChanged(it)) },
            label = { Text("비밀번호") },
            visualTransformation = PasswordVisualTransformation(),
            modifier = Modifier.fillMaxWidth(),
            enabled = !uiState.isLoading
        )

        uiState.errorMessage?.let { message ->
            Text(
                text = message,
                color = MaterialTheme.colorScheme.error
            )
        }

        Button(
            onClick = { viewModel.onIntent(LoginIntent.LoginClicked) },
            modifier = Modifier.fillMaxWidth(),
            enabled = !uiState.isLoading
        ) {
            if (uiState.isLoading) {
                CircularProgressIndicator()
            } else {
                Text("로그인")
            }
        }
    }
}

위 내용만 보면 Compose에서 MVI를 사용하지 않을 이유가 없어 보이지만 몇 가지 단점도 있습니다.

보일러플레이트 증가: 화면마다 State, Intent, SideEffect 등을 별도로 정의해야 해 코드량이 늘어난다.
복잡성 증가: 단순한 화면이나 작은 앱에서는 구조가 과할 수 있고, 불필요한 복잡성을 만들 수 있다.
성능 오버헤드 가능성: 상태를 불변 객체로 관리하기 때문에 변경 시마다 새로운 객체가 생성된다.
러닝 커브: 개념이 많아 처음에는 진입장벽이 있을 수 있다. 다만 개인적으로는 라이브러리를 활용하면 MVVM보다 더 빠르게 적응할 수 있었다.

Orbit의 등장 배경

MVI는 상태 변화 흐름을 명확하게 관리할 수 있다는 장점이 있지만, 직접 구현하려고 하면 State, SideEffect, Reducer, Flow, Channel 등을 반복해서 작성해야 해 보일러플레이트가 많아집니다. 또한 화면마다 비슷한 패턴을 계속 구현해야 하므로 코드 일관성을 유지하기도 쉽지 않습니다.

이러한 문제를 줄이기 위해 등장한 것이 Orbit으로, MVI 패턴을 Android 환경에서 보다 간결하게 사용할 수 있도록 도와주는 라이브러리이며 상태 관리와 사이드 이펙트 처리를 일관된 방식으로 구현할 수 있게 해줍니다.

Orbit의 핵심 키워드

Container: Orbit에서 상태와 사이드 이펙트를 보관하고 관리하는 중심 객체이다. 현재 State와 SideEffect의 흐름을 하나의 단위로 관리한다.
ContainerHost: ViewModel이 Orbit의 상태 컨테이너를 가지도록 해주는 인터페이스이다. Orbit을 사용하는 ViewModel은 보통 ContainerHost<State, SideEffect>를 구현한다.
State: 화면을 그리는 데 필요한 현재 상태이다. Compose에서는 이 State를 구독하여 UI를 렌더링한다.
SideEffect: 한 번만 처리되어야 하는 이벤트이다. 예를 들어 화면 이동, Toast 표시, Snackbar 출력 등이 여기에 해당한다.
Intent: 사용자의 입력이나 이벤트를 처리하는 블록이다. Orbit에서는 intent { ... } 형태로 상태 변경이나 비즈니스 로직을 수행한다.
Reduce: 현재 상태를 새로운 상태로 변경하는 역할을 한다. Orbit에서는 reduce { state.copy(...) } 형태로 불변 상태를 갱신한다.
postSideEffect: 일회성 이벤트를 방출할 때 사용하는 함수이다. 상태와 분리해서 처리해야 하는 UI 이벤트를 전달할 때 사용한다.

import androidx.lifecycle.ViewModel
import org.orbitmvi.orbit.ContainerHost
import org.orbitmvi.orbit.viewmodel.container
import org.orbitmvi.orbit.syntax.simple.intent
import org.orbitmvi.orbit.syntax.simple.reduce
import org.orbitmvi.orbit.syntax.simple.postSideEffect

class LoginViewModel(
    private val repository: LoginRepository = LoginRepository()
) : ViewModel(), ContainerHost<LoginUiState, LoginSideEffect> {

    override val container = container<LoginUiState, LoginSideEffect>(LoginUiState())

    fun onEmailChanged(value: String) = intent {
        reduce {
            state.copy(
                email = value,
                errorMessage = null
            )
        }
    }

    fun onPasswordChanged(value: String) = intent {
        reduce {
            state.copy(
                password = value,
                errorMessage = null
            )
        }
    }

    fun onLoginClicked() = intent {
        if (state.email.isBlank()) {
            postSideEffect(LoginSideEffect.ShowToast("이메일을 입력해주세요."))
            return@intent
        }

        if (state.password.isBlank()) {
            postSideEffect(LoginSideEffect.ShowToast("비밀번호를 입력해주세요."))
            return@intent
        }

        reduce {
            state.copy(
                isLoading = true,
                errorMessage = null
            )
        }

        repository.login(
            email = state.email,
            password = state.password
        ).onSuccess {
            reduce {
                state.copy(
                    isLoading = false,
                    errorMessage = null
                )
            }
            postSideEffect(LoginSideEffect.NavigateToHome)
        }.onFailure { throwable ->
            val message = throwable.message ?: "로그인에 실패했습니다."

            reduce {
                state.copy(
                    isLoading = false,
                    errorMessage = message
                )
            }
            postSideEffect(LoginSideEffect.ShowToast(message))
        }
    }
}

import android.widget.Toast
import androidx.compose.foundation.layout.Arrangement
import androidx.compose.foundation.layout.Column
import androidx.compose.foundation.layout.fillMaxSize
import androidx.compose.foundation.layout.fillMaxWidth
import androidx.compose.foundation.layout.padding
import androidx.compose.material3.Button
import androidx.compose.material3.CircularProgressIndicator
import androidx.compose.material3.MaterialTheme
import androidx.compose.material3.OutlinedTextField
import androidx.compose.material3.Text
import androidx.compose.runtime.Composable
import androidx.compose.runtime.getValue
import androidx.compose.ui.Modifier
import androidx.compose.ui.platform.LocalContext
import androidx.compose.ui.text.input.PasswordVisualTransformation
import androidx.compose.ui.unit.dp
import org.orbitmvi.orbit.compose.collectAsState
import org.orbitmvi.orbit.compose.collectSideEffect

@Composable
fun LoginScreen(
    viewModel: LoginViewModel,
    onNavigateToHome: () -> Unit
) {
    val uiState by viewModel.collectAsState()
    val context = LocalContext.current

    viewModel.collectSideEffect { effect ->
        when (effect) {
            LoginSideEffect.NavigateToHome -> onNavigateToHome()
            is LoginSideEffect.ShowToast -> {
                Toast.makeText(context, effect.message, Toast.LENGTH_SHORT).show()
            }
        }
    }

    Column(
        modifier = Modifier
            .fillMaxSize()
            .padding(24.dp),
        verticalArrangement = Arrangement.spacedBy(12.dp)
    ) {
        OutlinedTextField(
            value = uiState.email,
            onValueChange = viewModel::onEmailChanged,
            label = { Text("이메일") },
            modifier = Modifier.fillMaxWidth(),
            enabled = !uiState.isLoading
        )

        OutlinedTextField(
            value = uiState.password,
            onValueChange = viewModel::onPasswordChanged,
            label = { Text("비밀번호") },
            visualTransformation = PasswordVisualTransformation(),
            modifier = Modifier.fillMaxWidth(),
            enabled = !uiState.isLoading
        )

        uiState.errorMessage?.let { message ->
            Text(
                text = message,
                color = MaterialTheme.colorScheme.error
            )
        }

        Button(
            onClick = viewModel::onLoginClicked,
            modifier = Modifier.fillMaxWidth(),
            enabled = !uiState.isLoading
        ) {
            if (uiState.isLoading) {
                CircularProgressIndicator()
            } else {
                Text("로그인")
            }
        }
    }
}

멀티 모듈 앱에서 Dagger 사용

어리둥절범고래 — Tue, 24 Feb 2026 09:02:28 +0900

멀티 모듈 프로젝트에서는 보통 app 모듈이 Application을 가지고 있고, core나 base 모듈에 공통 코드가 들어갑니다. app 모듈은 앱 전역에서 공유되는 객체를 제공하는 컴포넌트를 두기에 적절합니다.

구조 잡는 기준

멀티 모듈에서 같은 레벨의 모듈끼리는 서로 의존하지 않는 것이 일반적인 규칙입니다. 같은 레벨에서 의존이 생기면 공통 로직을 상위 모듈로 올리거나, 상위 모듈을 확장하는 새 모듈을 만들고 두 모듈이 그 모듈에 의존하도록 리팩터링하는 방식을 권장합니다.

컴포넌트를 모듈에 만드는 경우는 보통 두 가지입니다. 필드 주입이 필요하거나, 특정 흐름에서 객체를 스코프 처리해야 할 때입니다. 둘 다 아니라면 컴포넌트 대신 @Provides나 @Binds를 가진 Dagger 모듈을 노출하는 방식이 더 단순합니다.

멀티 모듈에서 Subcomponent를 그대로 쓰기 어려운 이유

단일 모듈 예제에서는 Activity에서 MyApplication의 appComponent를 가져와서 서브컴포넌트를 만드는 방식이 자연스럽습니다.

class LoginActivity: Activity() {
  ...

  override fun onCreate(savedInstanceState: Bundle?) {
    // Application 그래프에서 로그인 그래프를 생성
    loginComponent = (applicationContext as MyDaggerApplication)
                        .appComponent.loginComponent().create()

    // LoginActivity의 @Inject 필드를 주입
    loginComponent.inject(this)
    ...
  }
}

하지만 login 같은 기능 모듈에서는 MyApplication이나 appComponent가 있는 모듈을 직접 알지 못할 수 있어서 이 코드가 그대로는 동작하지 않습니다.

이 경우 기능 모듈 안에 컴포넌트를 제공하는 인터페이스를 하나 두고, Application이 그 인터페이스를 구현하는 형태로 풀 수 있습니다.

interface LoginComponentProvider {
    fun provideLoginComponent(): LoginComponent
}

LoginActivity는 Application을 이 인터페이스로 캐스팅해서 컴포넌트를 받습니다.

class LoginActivity: Activity() {
  ...

  override fun onCreate(savedInstanceState: Bundle?) {
    loginComponent = (applicationContext as LoginComponentProvider)
                        .provideLoginComponent()

    loginComponent.inject(this)
    ...
  }
}

Application은 실제로 appComponent에서 LoginComponent를 만들어 반환합니다.

class MyApplication: Application(), LoginComponentProvider {
  val appComponent = DaggerApplicationComponent.create()

  override fun provideLoginComponent(): LoginComponent {
    return appComponent.loginComponent().create()
  }
}

이 방식은 일반적인 멀티 모듈 프로젝트에서 서브컴포넌트를 사용하는 방법으로 소개됩니다.

feature module에서는 component dependencies를 사용

feature module이 들어가면 모듈 의존 방향이 반대로 되는 경우가 많습니다. app 모듈이 feature module을 포함하는 구조가 아니라, feature module이 app 모듈에 의존하는 구조가 됩니다. 이 구조에서는 app 모듈이 feature module 안에 정의된 서브컴포넌트를 빌드 경로에서 볼 수 없어서, 부모 컴포넌트의 서브컴포넌트로 연결하는 방식이 깨집니다.

이 문제를 해결하기 위해 Dagger의 component dependencies를 사용합니다. 서브컴포넌트처럼 부모 자식 관계를 만드는 대신, 자식 컴포넌트가 부모 컴포넌트에 의존하도록 만들고, 부모가 그래프에서 제공하는 타입을 자식이 소비하는 방식입니다.

component dependencies 예제

app 모듈에 UserRepository가 있고 AppComponent에 스코프되어 있다고 가정합니다.

class UserLocalDataSource @Inject constructor() { ... }
class UserRemoteDataSource @Inject constructor() { ... }

@Singleton
class UserRepository @Inject constructor(
    private val localDataSource: UserLocalDataSource,
    private val remoteDataSource: UserRemoteDataSource
) { ... }

@Singleton
@Component
interface AppComponent { ... }

class LoginViewModel @Inject constructor(
    private val userRepository: UserRepository
) { ... }

이때 LoginActivity를 주입할 LoginComponent를 만들되, AppComponent에 의존하도록 선언합니다. 서브컴포넌트가 아니라 @Component로 선언하는 것이 포인트입니다.

@Component(dependencies = [AppComponent::class])
interface LoginComponent {
    fun inject(activity: LoginActivity)
}

의존 컴포넌트는 생성할 때 부모 컴포넌트 인스턴스를 넘겨야 하므로 Factory를 둡니다.

@Component(dependencies = [AppComponent::class])
interface LoginComponent {

    @Component.Factory
    interface Factory {
        fun create(appComponent: AppComponent): LoginComponent
    }

    fun inject(activity: LoginActivity)
}

LoginActivity에서는 MyApplication에서 appComponent를 가져온 뒤, LoginComponent를 생성하고 inject를 호출합니다.

class LoginActivity: Activity() {

    @Inject lateinit var loginViewModel: LoginViewModel

    override fun onCreate(savedInstanceState: Bundle?) {
        val appComponent = (applicationContext as MyApplication).appComponent

        DaggerLoginComponent.factory().create(appComponent).inject(this)

        super.onCreate(savedInstanceState)
    }
}

의존 컴포넌트에서의 스코프 규칙

의존 관계로 연결된 두 컴포넌트는 같은 스코프 애노테이션을 공유할 수 없습니다. LoginComponent가 AppComponent 인스턴스를 사용하기 때문입니다.

LoginViewModel을 LoginComponent 범위로 묶고 싶다면 이전과 동일하게 커스텀 스코프를 사용합니다.

@ActivityScope
@Component(dependencies = [AppComponent::class])
interface LoginComponent { ... }

@ActivityScope
class LoginViewModel @Inject constructor(
    private val userRepository: UserRepository
) { ... }

또한 의존 컴포넌트가 필요로 하는 타입을 부모 컴포넌트가 충분히 노출하지 않으면, Dagger가 컴파일 타임에 에러를 냅니다.

정리

ApplicationComponent는 항상 app 모듈에 둔다.
필드 주입이 필요하거나 특정 흐름에서 스코프가 필요할 때 해당 모듈에 컴포넌트를 둔다.
유틸리티 성격의 Gradle 모듈처럼 그래프를 만들 필요가 없다면, 컴포넌트 대신 @Provides나 @Binds를 가진 Dagger 모듈을 공개한다.
feature module이 있는 앱에서 ApplicationComponent의 의존성을 사용해야 한다면 component dependencies를 사용한다.

Android 앱에서 Dagger 사용

어리둥절범고래 — Sun, 22 Feb 2026 14:13:21 +0900

Android에서 Dagger를 적용할 때는 Application 수명주기에 맞는 그래프를 만들고, Activity와 Fragment에는 필드 주입으로 연결하는 방식이 기본입니다. 그래프는 Dagger가 관리하는 객체 관계라고 보면 됩니다.

가능하면 생성자 주입을 사용
생성자 주입이 어려운 타입은 모듈로 제공
모듈은 컴포넌트에서 한 번만 선언하는 구조로 작성
스코프는 기능 이름보다 수명주기 기준으로 작성

Android의 Dagger

Application에 그래프 두기

Application에 컴포넌트를 만들어 두면 앱 실행 동안 그래프를 공유할 수 있습니다. 앱 전역에서 재사용할 객체는 이 그래프에 두는 것이 자연스럽습니다.

// Application 그래프 정의
@Component
interface ApplicationComponent { ... }

// appComponent는 Application 클래스에 두어서 앱 수명주기와 함께 공유합니다.
class MyApplication: Application() {
    // 앱 전체에서 사용하는 Application 그래프 참조
    val appComponent = DaggerApplicationComponent.create()
}

필드 주입

Activity와 Fragment는 시스템이 인스턴스를 만들기 때문에 생성자 주입이 어렵습니다. 이 경우 필드에 @Inject를 붙이고 수명주기 메서드에서 주입을 호출합니다. Activity는 프래그먼트 복원 과정에서 문제가 생길 수 있으므로 super.onCreate()를 호출하기 전에 주입하는 흐름으로 안내합니다. Fragment는 onAttach()에서 주입하며, super.onAttach() 호출 전후 어느 쪽이든 가능합니다.

class LoginActivity: Activity() {
    // 그래프에서 LoginViewModel 인스턴스를 제공받고 싶습니다.
    @Inject lateinit var loginViewModel: LoginViewModel

    override fun onCreate(savedInstanceState: Bundle?) {
        // LoginActivity의 @Inject 필드를 Dagger가 주입하도록 호출합니다.
        (applicationContext as MyApplication).appComponent.inject(this)
        // 이제 loginViewModel을 사용할 수 있습니다.
        super.onCreate(savedInstanceState)
    }
}

// @Inject는 Dagger에게 LoginViewModel 인스턴스를 어떻게 생성할지 알려줍니다.
class LoginViewModel @Inject constructor(
    private val userRepository: UserRepository
) { ... }

의존성은 생성자 주입으로 이어 붙이기

최종적으로 필요한 객체를 만들기 위해 Dagger는 필요한 의존성을 연쇄적으로 생성합니다. 프로젝트 내부 클래스라면 생성자에 @Inject를 붙이는 방식이 가장 단순합니다.

class UserRepository @Inject constructor(
    private val localDataSource: UserLocalDataSource,
    private val remoteDataSource: UserRemoteDataSource
) { ... }

class UserLocalDataSource @Inject constructor() { ... }

class UserRemoteDataSource @Inject constructor(
    private val loginService: LoginRetrofitService
) { ... }

Dagger 모듈

Retrofit처럼 빌더를 통해 만들어야 하는 타입은 생성자 주입으로 만들기 어렵습니다. 이때 모듈의 @Provides로 생성 방법을 제공합니다.

// @Module은 이 클래스가 Dagger Module임을 알려줍니다.
@Module
class NetworkModule {
    // @Provides는 이 함수가 반환하는 타입을 Dagger가 어떻게 생성해야 하는지 알려줍니다.
    @Provides
    fun provideLoginRetrofitService(): LoginRetrofitService {
        // Dagger가 LoginRetrofitService 인스턴스를 제공해야 할 때마다 실행됩니다.
        return Retrofit.Builder()
                .baseUrl("https://example.com")
                .build()
                .create(LoginService::class.java)
    }
}

@Provides 메서드의 파라미터는 그 타입을 만들기 위한 의존성입니다. Dagger가 먼저 파라미터를 준비한 뒤 메서드를 호출합니다.

@Module
class NetworkModule {
    // LoginRetrofitService가 OkHttpClient에 의존한다고 가정한 예시
    @Provides
    fun provideLoginRetrofitService(
        okHttpClient: OkHttpClient
    ): LoginRetrofitService { ... }
}

모듈은 컴포넌트에 포함시켜야 그래프에서 사용됩니다.

// @Component의 modules 속성은 그래프를 만들 때 포함할 Module을 Dagger에 알려줍니다.
@Component(modules = [NetworkModule::class])
interface ApplicationComponent {
    ...
}

Dagger Scope

스코프는 같은 그래프 안에서 같은 인스턴스를 재사용하기 위한 장치입니다. 앱 전역에서 하나만 유지하고 싶은 객체에는 @Singleton을 사용할 수 있습니다.

@Singleton
@Component(modules = [NetworkModule::class])
interface ApplicationComponent {
    fun inject(activity: LoginActivity)
}

@Singleton
class UserRepository @Inject constructor(
    private val localDataSource: UserLocalDataSource,
    private val remoteDataSource: UserRemoteDataSource
) { ... }

@Module
class NetworkModule {
    // Module 내부에서 제공하는 타입에도 스코프를 부여할 수 있습니다.
    @Singleton
    @Provides
    fun provideLoginRetrofitService(): LoginRetrofitService { ... }
}

로그인 흐름은 별도의 그래프로

로그인 화면과 여러 Fragment가 하나의 흐름으로 움직이면, 그 흐름 안에서는 같은 LoginViewModel을 공유하는 편이 자연스럽습니다. 하지만 앱 전체 싱글턴으로 두면 흐름이 끝나도 인스턴스가 남을 수 있습니다. 이 경우 Activity 수명주기에 맞는 하위 그래프를 둡니다.

Subcomponent 구성

처음에는 Login 전용 컴포넌트를 따로 두는 형태로 시작할 수 있습니다.

@Component
interface LoginComponent {}
@Component
interface LoginComponent {
    fun inject(activity: LoginActivity)
}

최종적으로는 @Subcomponent를 사용해서 부모 그래프 아래에 로그인 그래프를 두는 형태가 됩니다. Factory를 노출해서 새로운 로그인 그래프 인스턴스를 만들 수 있게 합니다.

@Subcomponent
interface LoginComponent {

    // 이 서브컴포넌트 인스턴스를 생성하기 위한 Factory
    @Subcomponent.Factory
    interface Factory {
        fun create(): LoginComponent
    }

    fun inject(loginActivity: LoginActivity)
}

부모 컴포넌트가 자식 서브컴포넌트를 알 수 있도록 모듈에 등록합니다.

// Module의 subcomponents 속성은 자식 Subcomponent를 Dagger에 알려줍니다.
@Module(subcomponents = LoginComponent::class)
class SubcomponentsModule {}

부모 컴포넌트는 이 모듈을 포함하고 Factory를 밖으로 노출합니다.

@Singleton
@Component(modules = [NetworkModule::class, SubcomponentsModule::class])
interface ApplicationComponent {
}
@Singleton
@Component(modules = [NetworkModule::class, SubcomponentsModule::class])
interface ApplicationComponent {
    // LoginComponent.Factory를 노출합니다.
    fun loginComponent(): LoginComponent.Factory
}

LoginActivity에서 로그인 그래프 생성과 주입

로그인 그래프의 수명은 Activity가 책임집니다. Activity가 생성될 때 그래프를 만들고, 사라질 때 함께 사라지는 형태입니다.

class LoginActivity: Activity() {
    // 로그인 그래프에 대한 참조
    lateinit var loginComponent: LoginComponent
    ...
}
class LoginActivity: Activity() {
    // 로그인 그래프에 대한 참조
    lateinit var loginComponent: LoginComponent

    // 로그인 그래프에서 주입되어야 하는 필드
    @Inject lateinit var loginViewModel: LoginViewModel

    override fun onCreate(savedInstanceState: Bundle?) {
        // Application 그래프를 이용해서 로그인 그래프를 생성합니다.
        loginComponent = (applicationContext as MyDaggerApplication)
                            .appComponent.loginComponent().create()

        // LoginActivity의 @Inject 필드를 Dagger가 주입하도록 호출합니다.
        loginComponent.inject(this)

        super.onCreate(savedInstanceState)
    }
}

ActivityScope 스코프

로그인 그래프 안에서 LoginViewModel을 공유하려면 컴포넌트와 클래스에 같은 스코프를 붙입니다. 그러면 같은 그래프 안에서 동일 인스턴스가 제공됩니다.

// ActivityScope라는 커스텀 스코프 정의
@Scope
@Retention(value = AnnotationRetention.RUNTIME)
annotation class ActivityScope

@ActivityScope
@Subcomponent
interface LoginComponent { ... }

@ActivityScope
class LoginViewModel @Inject constructor(
    private val userRepository: UserRepository
) { ... }

Fragment에서도 같은 ViewModel 공유

Fragment도 로그인 그래프에서 주입받아야 같은 LoginViewModel 인스턴스를 공유할 수 있습니다. 그래서 LoginComponent에 Fragment용 inject를 추가합니다.

@ActivityScope
@Subcomponent
interface LoginComponent {

    @Subcomponent.Factory
    interface Factory {
        fun create(): LoginComponent
    }

    fun inject(loginActivity: LoginActivity)
    fun inject(usernameFragment: LoginUsernameFragment)
    fun inject(passwordFragment: LoginPasswordFragment)
}

Fragment는 onAttach에서 주입하는 흐름을 사용합니다.

class LoginUsernameFragment: Fragment() {

    // 로그인 그래프에서 주입되어야 하는 필드
    @Inject lateinit var loginViewModel: LoginViewModel

    override fun onAttach(context: Context) {
        super.onAttach(context)

        // LoginActivity에서 로그인 그래프를 가져와 주입합니다.
        (activity as LoginActivity).loginComponent.inject(this)
    }
}
class LoginPasswordFragment: Fragment() {

    // 로그인 그래프에서 주입되어야 하는 필드
    @Inject lateinit var loginViewModel: LoginViewModel

    override fun onAttach(context: Context) {
        super.onAttach(context)

        (activity as LoginActivity).loginComponent.inject(this)
    }
}

그래프 구성 시 권장사항

컴포넌트를 만들 때 수명을 누가 책임지는지 먼저 정합니다. Application이 ApplicationComponent를 책임지고, Activity가 LoginComponent를 책임지는 구조가 됩니다. 스코프는 필요한 경우에만 사용합니다. scoped 객체는 내부적으로 관리 비용이 생길 수 있습니다.

테스트

단위 테스트는 Dagger 없이도 진행할 수 있습니다. 생성자로 fake나 mock을 직접 넣으면 됩니다

@ActivityScope
class LoginViewModel @Inject constructor(
    private val userRepository: UserRepository
) { ... }

class LoginViewModelTest {

    @Test
    fun `Happy path`() {
        val viewModel = LoginViewModel(fakeUserRepository)
        assertEquals(...)
    }
}

통합 테스트는 실제 모듈 대신 테스트 모듈을 끼워서 그래프를 교체합니다.

@Singleton
@Component(modules = [FakeNetworkModule::class, SubcomponentsModule::class])
interface TestApplicationComponent : ApplicationComponent {
}
@Module
class FakeNetworkModule {
    @Provides
    fun provideLoginRetrofitService(): LoginRetrofitService {
        return FakeLoginService()
    }
}
class MyTestApplication: MyApplication() {
    override val appComponent = DaggerTestApplicationComponent.create()
}

Dagger 모듈 중복 include 주의

모듈을 include로 조합하다 보면 같은 모듈이 그래프에 여러 번 포함될 수 있습니다. 문서에서는 이를 피하는 구조를 예시로 설명합니다.

@Component(modules = [Module1::class, Module2::class])
interface ApplicationComponent { ... }

@Module(includes = [ModuleX::class])
class Module1 { ... }

@Module
class Module2 { ... }
@Component(modules = [Module1::class, Module2::class])
interface ApplicationComponent { ... }

@Module(includes = [ModuleX::class])
class Module1 { ... }

@Module(includes = [ModuleX::class])
class Module2 { ... }

한 가지 방법은 공통 모듈을 컴포넌트로 올리는 것입니다.

@Component(modules = [Module1::class, Module2::class, ModuleX::class])
interface ApplicationComponent { ... }

@Module
class Module1 { ... }

@Module
class Module2 { ... }

다른 방법은 공통 부분과 모듈별 의존 부분을 분리하는 것입니다.

@Component(modules = [Module1::class, Module2::class, ModuleXCommon::class])
interface ApplicationComponent { ... }

@Module
class ModuleXCommon { ... }

@Module
class ModuleXWithModule1SpecificDependencies { ... }

@Module
class ModuleXWithModule2SpecificDependencies { ... }

@Module(includes = [ModuleXWithModule1SpecificDependencies::class])
class Module1 { ... }

@Module(includes = [ModuleXWithModule2SpecificDependencies::class])
class Module2 { ... }

정리

Application에 ApplicationComponent를 두고 앱 수명주기와 함께 사용
Activity와 Fragment는 필드 주입으로 연결
외부 라이브러리 객체는 모듈에서 제공
흐름 단위로 분리하려면 Subcomponent와 커스텀 스코프를 사용
테스트에서는 단위 테스트는 생성자로, 통합 테스트는 테스트 그래프로 교체하는 방식으로 접근
모듈 include는 중복 선언이 생기지 않도록 구성

Dagger 기본사항 정리

어리둥절범고래 — Mon, 9 Feb 2026 21:16:13 +0900

Dagger는 Java 및 Kotlin 애플리케이션에서 사용하는 정적 의존성 주입(Dependency Injection) 프레임워크입니다.
Android 환경에서 객체 생성 및 종속성 관리를 자동화하여, 유지보수성과 테스트 용이성을 향상시킵니다.

컴파일 타임 코드 생성으로 리플렉션 기반 DI보다 성능 우수
의존성 그래프 자동 생성 및 검증
Factory 클래스 생성을 통한 객체 생성 관리
스코프 어노테이션을 활용한 객체 생명주기 관리
서브컴포넌트(Subcomponent) 지원으로 특정 흐름 단위 DI 가능

주요 구성 요소

@Inject: 생성자 또는 필드에 붙여 의존성을 주입
@Module: Dagger에 바인딩을 제공하는 클래스 정의
@Provides: 생성자 주입이 불가능한 타입을 수동으로 제공
@Component: 의존성 그래프를 생성하고 주입 지점을 연결
@Singleton, @ActivityScope: 객체의 생명주기를 관리하는 스코프 어노테이션

Dagger를 사용하여 UserRepository 클래스의 간단한 팩토리를 만들어 보겠습니다.

class UserRepository(
    private val localDataSource: UserLocalDataSource,
    private val remoteDataSource: UserRemoteDataSource
) { ... }

Dagger가 UserRepository를 생성하는 방법을 알 수 있도록 @Inject 주석을 UserRepository 생성자에 추가합니다.

// Dagger는 @Inject가 붙은 생성자를 기준으로 해당 클래스의 인스턴스를 생성할 수 있습니다.
class UserRepository @Inject constructor(
    private val localDataSource: UserLocalDataSource,
    private val remoteDataSource: UserRemoteDataSource
)

UserRepository가 의존하는 클래스에도 @Inject 생성자가 필요합니다.

class UserLocalDataSource @Inject constructor() { ... }
class UserRemoteDataSource @Inject constructor() { ... }

컴포넌트는 Dagger의 의존성 그래프를 생성하는 진입점입니다.

@Component
interface ApplicationGraph {
    fun repository(): UserRepository
}

applicationGraph.repository() 호출 시 새로운 인스턴스가 반환됩니다.

val applicationGraph: ApplicationGraph = DaggerApplicationGraph.create()
val userRepository: UserRepository = applicationGraph.repository()

Dagger는 매번 새로운 인스턴스를 생성합니다.
같은 인스턴스를 재사용하려면 스코프 어노테이션을 사용해야 합니다.

@Singleton
@Component
interface ApplicationGraph {
    fun repository(): UserRepository
}

@Singleton
class UserRepository @Inject constructor(...) { ... }

위와 같이 구성하면 applicationGraph.repository()를 호출할 때마다 동일 인스턴스가 반환됩니다.

val applicationGraph: ApplicationGraph = DaggerApplicationGraph.create()

val userRepository: UserRepository = applicationGraph.repository()
val userRepository2: UserRepository = applicationGraph.repository()

assert(userRepository != userRepository2) // 새로운 인스턴스

같은 인스턴스를 재사용하려면 스코프 어노테이션을 사용해야 합니다.

@Singleton
@Component
interface ApplicationGraph {
    fun repository(): UserRepository
}

@Singleton
class UserRepository @Inject constructor(...) { ... }

필요 시 사용자 정의 스코프도 생성 가능합니다.

@Scope
@MustBeDocumented
@Retention(value = AnnotationRetention.RUNTIME)
annotation class MyCustomScope

@MyCustomScope
@Component
interface ApplicationGraph {
    fun repository(): UserRepository
}

@MyCustomScope
class UserRepository @Inject constructor(...) { ... }

@Component 인터페이스에 주석을 지정하는 데 사용된 것과 동일한 범위가 객체에 제공됩니다. 따라서 applicationGraph.repository()를 호출할 때마다 동일한 UserRepository 인스턴스를 얻습니다.

val applicationGraph: ApplicationGraph = DaggerApplicationGraph.create()

val userRepository: UserRepository = applicationGraph.repository()
val userRepository2: UserRepository = applicationGraph.repository()

assert(userRepository == userRepository2) // 동일한 인스턴스

Hilt 및 Dagger 주석 요약본

어리둥절범고래 — Mon, 9 Feb 2026 20:34:43 +0900

1. @HiltAndroidApp

Application 클래스에 붙임
Hilt의 시작점 (DI 그래프 생성됨)

@HiltAndroidApp class MyApp : Application()

2. @AndroidEntryPoint

Activity, Fragment, Service 등 Android 컴포넌트에 붙임
Hilt 주입 가능하게 만듦

@AndroidEntryPoint class MainActivity : AppCompatActivity()

3. @Inject

생성자나 필드에 붙여서 주입 받을 수 있게 함

class AnalyticsAdapter @Inject constructor(
 private val service: AnalyticsService
) { ... }

@AndroidEntryPoint
class MyActivity : AppCompatActivity() { 
 @Inject lateinit var adapter: AnalyticsAdapter
 ...
}

4. @HiltViewModel

ViewModel에 붙여서 Hilt로 생성되게 함

@HiltViewModel
class MyViewModel @Inject constructor( 
 private val adapter: AnalyticsAdapter,
 private val state: SavedStateHandle
): ViewModel() { ... }

5. @Module + @InstallIn(...)

직접 바인딩 로직 작성할 때 사용
@InstallIn(SingletonComponent::class)처럼 범위 지정

@InstallIn(SingletonComponent::class)
@Module
class AnalyticsModule { ... }

6. @Binds

인터페이스 ↔ 구현체 바인딩 시 사용 (추상 메서드 필요)

@InstallIn(SingletonComponent::class)
@Module
abstract class AnalyticsModule {
 @Binds
 abstract fun bindsAnalyticsService(
   analyticsServiceImpl: AnalyticsServiceImpl
 ): AnalyticsService
}

7. @Provides

수동으로 객체 생성할 때 사용(외부 라이브러리)

@InstallIn(SingletonComponent::class)
@Module
class AnalyticsModule {
 @Provides
 fun providesAnalyticsService(
   converterFactory: GsonConverterFactory
 ): AnalyticsService {
   return Retrofit.Builder()
     .baseUrl("https://example.com")
     .addConverterFactory(converterFactory)
     .build()
     .create(AnalyticsService::class.java)
 }
}

8. 스코프 어노테이션 (@Singleton, @ActivityScoped, 등)

주입된 객체의 생명주기 관리

@Singleton
class AnalyticsAdapter @Inject constructor(
 private val service: AnalyticsService
) { ... }

9. 컨텍스트 어노테이션

어떤 Context를 주입할지 명확히 구분

@Singleton
class AnalyticsAdapter @Inject constructor(
 @ApplicationContext val context: Context,
 private val service: AnalyticsService
) { ... }

10. @EntryPoint

ContentProvider 등 Hilt 미지원 클래스에서 의존성 접근할 때 사용

class MyContentProvider(): ContentProvider {
 @InstallIn(SingletonComponent::class)
 @EntryPoint
 interface MyContentProviderEntryPoint {
   fun analyticsService(): AnalyticsService
 }

 override fun query(...): Cursor {
   val appContext = 
     context?.applicationContext 
     ?: throw IllegalStateException()

   val entryPoint = 
     EntryPointAccessors.fromApplication(
       appContext, 
       MyContentProviderEntryPoint::class.java)

   val analyticsService = 
     entryPoint.analyticsService()

   ...
 }
}

어노테이션	용도	설명	코드 예시
@HiltAndroidApp	애플리케이션 설정	Hilt 코드 생성을 시작함. 반드시 Application 클래스에 선언	@HiltAndroidApp class MyApplication : Application()
@AndroidEntryPoint	Android 클래스에 DI 컨테이너 추가	Activity, Fragment, Service 등에 Hilt 주입 허용	@AndroidEntryPoint class MyActivity : AppCompatActivity()
@HiltViewModel	ViewModel 주입	ViewModel에 Hilt로 의존성 주입 설정	@HiltViewModel class MyViewModel @Inject constructor(...)
@Inject	생성자 / 필드 주입	어떤 생성자를 사용하고 어떤 의존성이 필요한지 명시	class Adapter @Inject constructor(service: Service)
필드 @Inject	필드에 주입	@AndroidEntryPoint 클래스 내의 lateinit var에 사용 (private 불가)	@Inject lateinit var adapter: Adapter
@Module	수동 바인딩 제공	생성자 주입이 불가능한 타입을 수동 바인딩하는 클래스	@Module class AnalyticsModule { ... }
@InstallIn(...)	바인딩 범위 지정	어떤 Hilt 컴포넌트(Singleton 등)에 바인딩할지 설정	@InstallIn(SingletonComponent::class)
@Binds	인터페이스 ↔ 구현체 바인딩	추상 메서드를 사용해 인터페이스 타입에 구현체 바인딩	@Binds abstract fun bindService(impl: ServiceImpl): Service
@Provides	수동 생성 바인딩	직접 객체 생성 로직이 필요한 경우 사용	@Provides fun provideService(): Service
스코프 어노테이션	생명주기 바인딩	@Singleton, @ActivityScoped 등으로 객체 수명 관리	@Singleton class Repo @Inject constructor(...)
@ApplicationContext@ActivityContext	컨텍스트 구분 바인딩	Context가 애플리케이션용인지, 액티비티용인지 구분	@ApplicationContext val context: Context
@EntryPoint	Hilt 미지원 클래스에 주입	ContentProvider 등 Hilt 미지원 클래스에서 주입할 때 사용	@EntryPoint interface MyEntryPoint { fun service(): Service }

Hilt 테스트 가이드

어리둥절범고래 — Tue, 3 Feb 2026 08:56:03 +0900

Hilt와 같은 종속 항목 삽입 프레임워크를 사용하여 얻을 수 있는 이점 중 하나는 코드를 더 쉽게 테스트할 수 있다는 점입니다.

테스트 Application 클래스 구성

@HiltAndroidApp이 선언된 실제 앱의 Application 클래스는 테스트에서 무시되고, HiltTestApplication이 대신 사용됩니다.

보통 Hilt 테스트용 Application 클래스는 Hilt가 기본으로 제공하는 HiltTestApplication을 Application 클래스로 사용합니다.

<application
    android:name="dagger.hilt.android.testing.HiltTestApplication"
    ... />

혹은 AndroidJUnitRunner를 확장하는 맞춤 클래스를 생성합니다.

// 테스트 전용 manifest를 따로 둘 경우 아래처럼 설정 가능:
android {
    defaultConfig {
        testInstrumentationRunner "com.example.android.dagger.CustomTestRunner"
    }
}


package com.example.android.dagger.CustomTestRunner

class CustomTestRunner : AndroidJUnitRunner() {
    override fun newApplication(cl: ClassLoader?, name: String?, context: Context?): Application {
        // 플래이버나 빌드타입에 따라 다른 Application 사용 가능
        val testAppClassName = when (BuildConfig.FLAVOR) {
            "demo" -> "com.example.DemoHiltTestApplication_Application"
            else -> "com.example.DefaultHiltTestApplication_Application"
        }

        return super.newApplication(cl, testAppClassName, context)
    }
}

그런데 만약, 아래와 같은 커스텀 Application을 사용하고 있는 경우 HiltTestApplication을 그냥 쓰면 앱 설정이 깨지게 됩니다.

class BaseApplication : Application()

이런 경우, @CustomTestApplication을 사용하면 매개변수로 전달한 애플리케이션을 확장하는 Application 클래스를 생성합니다.

@CustomTestApplication(BaseApplication::class)
interface HiltTestApplication

// 힐트 내부 코드
class HiltTestApplication_Application : BaseApplication()

테스트용 HiltRule 사용

Hilt는 테스트 시 의존성 주입을 트리거하고 Hilt 컴포넌트를 초기화하기 위한 전용 Rule을 제공합니다.

@HiltAndroidTest
class MyTest {

    @get:Rule
    val hiltRule = HiltAndroidRule(this)

    @Before
    fun init() {
        hiltRule.inject() // 주입 실행
    }
}

@HiltAndroidTest: 테스트 클래스임을 나타내는 어노테이션
HiltAndroidRule: 테스트 실행 전에 DI 그래프를 초기화
inject(): 주입 수행 (테스트용 필드에 @Inject 가능)

계측 테스트(Instrumented Test)에서 Hilt 사용

@HiltAndroidTest
@RunWith(AndroidJUnit4::class)
class LoginScreenTest {

    @get:Rule
    val hiltRule = HiltAndroidRule(this)

    @Before
    fun setUp() {
        hiltRule.inject()
    }

    @Inject lateinit var userRepository: UserRepository

    @Test
    fun testLoginSuccess() {
        // 주입된 FakeUserRepository 사용 가능
        // 테스트 UI 검증 코드 작성
    }
}

JUnit에서 @Rule은 테스트 실행 전에 필수 작업을 자동으로 해주며, @Inject로 실제 앱과 동일하게 테스트 대상에 의존성을 주입해 줍니다.

이로써 모듈만 테스트 전용으로 교체하여 유연한 테스트 구성이 가능합니다.

만약 테스트 클래스에 2개 이상의 Rule을 쓸 때 실행 순서가 꼬이면 테스트가 실패하거나 Hilt가 동작 안 할 수 있기 때문에, Hilt는 여러 기능을 제공합니다.

// RuleChain 사용
@get:Rule
var rule = RuleChain
    .outerRule(HiltAndroidRule(this)) // 먼저 실행됨
    .around(SettingsActivityTestRule(...)) // 그다음 실행

// order 속성 사용
@get:Rule(order = 0) // 먼저 실행됨
var hiltRule = HiltAndroidRule(this)

@get:Rule(order = 1) // 나중 실행됨
var activityRule = SettingsActivityTestRule(...)

테스트용 의존성 재정의 (Test Binding)

실제 앱에서는 @Module을 통해 의존성을 제공하지만, 테스트에서는 이를 재정의(override) 하여 Fake / Stub / Mock 구현을 주입해야 할 수 있습니다.

@Module
@InstallIn(SingletonComponent::class)
abstract class AnalyticsModule {

  @Singleton
  @Binds
  abstract fun bindAnalyticsService(
    analyticsServiceImpl: AnalyticsServiceImpl
  ): AnalyticsService
}

이때 Hilt는 @TestInstallIn 어노테이션을 통해, 기존 의존성을 테스트 전용 모듈로 교체할 수 있도록 지원합니다.

@Module
@TestInstallIn(
    components = [SingletonComponent::class],
    replaces = [AnalyticsModule::class] // 기존 모듈을 대체
)
abstract class FakeAnalyticsModule {

  @Singleton
  @Binds
  abstract fun bindAnalyticsService(
    fakeAnalyticsService: FakeAnalyticsService
  ): AnalyticsService
}

이 방법을 공통된 Fake 의존성이 필요한 경우에 적합하며, test/나 androidTest/ 폴더에 있는 모든 테스트에서 동일한 Fake 구현이 주입됩니다.

모든 테스트가 아닌, 특정 테스트 클래스에서만 다른 결합(Fake 등)을 사용하고 싶은 경우에는 @TestInstallIn 대신 @UninstallModules 어노테이션을 사용하는 것이 더 적합합니다.

@UninstallModules(AnalyticsModule::class) // 기존 모듈 제거
@HiltAndroidTest
class SettingsActivityTest {

  @Module
  @InstallIn(SingletonComponent::class)
  abstract class TestModule {

    @Singleton
    @Binds
    abstract fun bindAnalyticsService(
      fakeAnalyticsService: FakeAnalyticsService
    ): AnalyticsService
  }

  ...
}

또는, @BindValue를 통해 테스트 클래스 내에서 바로 의존성을 바인딩할 수도 있습니다.

@UninstallModules(AnalyticsModule::class)
@HiltAndroidTest
class SettingsActivityTest {

  @BindValue @JvmField
  val analyticsService: AnalyticsService = FakeAnalyticsService()

  ...
}

단위 테스트

단위 테스트에서는 Android Framework 클래스 접근이 불가능하기 때문에, 기본적으로 단위 테스트에서는 Hilt를 사용하는 것이 제한적입니다.

HiltAndroidTest, HiltAndroidRule, HiltTestApplication 등의 기능은 계측 테스트 환경(Instrumented Test)에서만 정상적으로 작동합니다.

단위 테스트에서는 아래와 같이 처리합니다.

Hilt를 사용하지 않고 Dagger 컴포넌트를 직접 생성
ViewModel, Repository 등은 Hilt 없이 직접 생성하여 테스트
또는, @InstallIn 대신 수동 주입으로 단위 테스트 범위 내에서 관리

Hilt 테스트 요약

항목	사용법	목적
@HiltAndroidTest	테스트 클래스에 선언	테스트 전용 DI 그래프 생성
HiltAndroidRule	테스트 실행 전 주입 처리	inject() 호출 필요
@TestInstallIn	모듈 재정의	테스트용 Fake/Mock 바인딩
HiltTestApplication	테스트 앱으로 설정	실제 Application 대체
단위 테스트	기본적으로 Hilt 미지원	수동 주입 또는 Dagger 직접 사용 필요

Jetpack 라이브러리 Hilt

어리둥절범고래 — Sun, 1 Feb 2026 14:13:26 +0900

안드로이드 앱 개발에서 ViewModel, Navigation, Compose, WorkManager와 같은 Jetpack 컴포넌트는 거의 필수적으로 사용되는 라이브러리입니다. Hilt는 이러한 Jetpack 컴포넌트들과 자연스럽게 통합되도록 설계되어 있으며, 의존성 주입을 보다 일관적이고 효율적으로 구성할 수 있도록 지원합니다.

ViewModel에 의존성 주입하기

Hilt는 ViewModel에 의존성을 주입하기 위한 전용 어노테이션인 @HiltViewModel을 제공합니다. 이를 통해 ViewModel도 다른 클래스들과 마찬가지로 Hilt의 DI 그래프에 포함시킬 수 있습니다.

@HiltViewModel
class ExampleViewModel @Inject constructor(
    private val repository: ExampleRepository
) : ViewModel() {
    ...
}

해당 ViewModel을 사용하는 Activity나 Fragment는 @AndroidEntryPoint 어노테이션을 선언하고, by viewModels() 또는 by hiltNavGraphViewModels() 같은 Hilt 지원 팩토리를 통해 ViewModel을 쉽게 가져올 수 있습니다.

@AndroidEntryPoint
class ExampleFragment : Fragment() {
    private val viewModel: ExampleViewModel by viewModels() // or hiltNavGraphViewModels()
}

Hilt는 ViewModel을 ViewModelComponent 라는 독립된 컴포넌트에서 관리합니다.
이 컴포넌트는 @InstallIn(ViewModelComponent::class)를 통해 특정 의존성을 ViewModel 범위로 설정할 수 있습니다.

Navigation과 함께 사용하기

Navigation 구성에서 화면 전환 간 ViewModel을 공유하려면 navigation-graph-scope를 기반으로 하는 ViewModel 접근이 필요합니다. 이를 위해 Hilt는 hiltNavigationGraphViewModels() 라는 확장 함수를 제공합니다.

private val viewModel: ExampleViewModel by hiltNavGraphViewModels(R.id.nav_graph)

이 방식을 통해 특정 네비게이션 그래프 범위 내에서 ViewModel 인스턴스를 공유할 수 있습니다.

WorkManager와 함께 사용하기

WorkManager는 백그라운드 작업을 수행할 때 사용하는 Jetpack 구성요소입니다.
Hilt는 @HiltWorker와 @AssistedInject를 활용하여 Worker 클래스에도 의존성을 주입할 수 있도록 지원합니다.

// Worker 정의
@HiltWorker
class ExampleWorker @AssistedInject constructor(
    @Assisted appContext: Context,
    @Assisted workerParams: WorkerParameters,
    private val repository: ExampleRepository
) : Worker(appContext, workerParams) {
    
    override fun doWork(): Result {
        repository.doBackgroundTask()
        return Result.success()
    }
}

Application 클래스에서는 HiltWorkerFactory를 설정하여 WorkManager가 주입 가능한 Worker 인스턴스를 생성할 수 있도록 구성해야 합니다.

// WorkerFactory 설정
@HiltAndroidApp
class MyApplication : Application(), Configuration.Provider {

    @Inject lateinit var workerFactory: HiltWorkerFactory

    override fun getWorkManagerConfiguration() =
        Configuration.Builder()
            .setWorkerFactory(workerFactory)
            .build()
}

SavedStateHandle 사용하기

Hilt는 SavedStateHandle을 ViewModel 생성자에 주입하는 것도 지원합니다.
Navigation-Compose와 함께 사용할 때 route argument를 처리하는 데 특히 유용합니다.

@HiltViewModel
class DetailViewModel @Inject constructor(
    savedStateHandle: SavedStateHandle
) : ViewModel() {
    val itemId: String = savedStateHandle["itemId"] ?: ""
}

이 기능을 통해 프로세스 종료 후 복원 상황에서도 필요한 데이터를 안정적으로 관리할 수 있습니다.

Jetpack Compose에서 Hilt 사용하기

Compose에서도 ViewModel에 Hilt를 통한 의존성 주입이 가능하며, hiltViewModel()을 통해 @HiltViewModel이 붙은 ViewModel을 직접 사용합니다.

@Composable
fun HomeScreen() {
    val viewModel: HomeViewModel = hiltViewModel()
    val state by viewModel.state.collectAsState()

    Text(text = state.message)
}

@AndroidEntryPoint가 선언된 Activity나 NavHost 내에서 이와 같은 방식으로 ViewModel을 직접 주입할 수 있으며,
내비게이션 목적지 내에서도 동일하게 사용할 수 있습니다.

composable("login") {
    val viewModel: LoginViewModel = hiltViewModel()
    LoginScreen(viewModel)
}

Hilt 멀티 모듈

어리둥절범고래 — Sun, 1 Feb 2026 13:43:32 +0900

모듈화를 통해 기능별로 코드를 분리하면 코드의 응집도와 재사용성이 높아지고, 테스트 및 배포가 용이해지는 장점이 있습니다.

일반적으로 Hilt가 코드를 생성하려면, Hilt를 사용하는 모든 Gradle 모듈에 접근할 수 있어야 합니다.

앱 모듈은 다른 모듈에서 정의된 모든 Hilt 모듈(@Module) 및 생성자 주입 클래스(@Inject) 들이 전이 종속성(Transitive Dependency)으로 포함되어 있어야 합니다.

전이 종속성(Transitive Dependency)이란, 어떤 모듈이 직접 의존하는 다른 모듈이 다시 또 다른 모듈을 의존하고 있을 때, 최초의 모듈이 해당 모듈을 직접 선언하지 않았음에도 불구하고 간접적으로 의존하게 되는 관계를 의미합니다.

Feature 모듈 구조에서는 의존성 방향이 일반적인 방식과 정반대로 흐릅니다.

구분	일반 Gradle 모듈	Feature 모듈
의존성 방향	상위(App) 모듈이 하위 모듈을 참조함	상위(App) 모듈을 참조하는 의존성 역전 구조
컴파일 타임 가시성	App 모듈이 모든 하위 코드를 볼 수 있음	App 모듈이 Feature 모듈의 코드를 볼 수 없음
Hilt 주석 처리	@AndroidEntryPoint 등 표준 주석 사용 가능	Hilt 자동 주입을 사용할 수 없으므로, 수동으로 구성하는 Dagger 방식을 사용

@EntryPoint는 Hilt가 직접 관리할 수 없는 영역(Feature 모듈 등)에서 Hilt의 의존성 그래프에 접근할 수 있도록 열어둔 특별한 게이트웨이입니다. Feature 모듈은 App 모듈을 의존하고 있으므로, App 모듈 내에 구축된 Hilt의 SingletonComponent에서 필요한 객체를 참조하겠다고 명시하는 것과 같습니다. 이는 Hilt의 자동 주입 혜택을 받지 못하는 환경에서도 의존성 그래프의 연속성을 유지해 줍니다.

Feature 모듈 내 LoginActivity에서 Hilt의 의존성을 주입받는 예시입니다.

:app
├── di/
│   └── AppModule.kt                  // UserRepository 제공
├── entrypoint/
│   └── LoginModuleDependencies.kt   // EntryPoint 인터페이스
└── App.kt                            // @HiltAndroidApp

:feature_login
├── di/
│   └── LoginComponent.kt            // Dagger 컴포넌트 정의
├── data/
│   └── LoginAnalyticsAdapter.kt     // @Inject 사용 클래스
└── ui/
    └── LoginActivity.kt             // 의존성 주입 수행

1. App 모듈에 @EntryPoint 인터페이스 선언

Feature 모듈이 App 모듈의 그래프에서 무엇을 꺼내올지 정의하는 계약(Contract)을 만듭니다. 이 인터페이스는 Hilt가 접근 가능한 app 모듈 내에 위치해야 합니다.

// app 모듈 내 LoginModuleDependencies.kt
@EntryPoint
@InstallIn(SingletonComponent::class) // Hilt의 Singleton 범위를 사용하도록 지정
interface LoginModuleDependencies {
    // Feature 모듈에서 가져다 쓸 의존성을 메서드 형태로 정의
    @AuthInterceptorOkHttpClient
    fun okHttpClient(): OkHttpClient 
}

2. Feature 모듈 내에서 Dagger 구성요소 생성

Feature 모듈 내부에서는 Hilt의 @AndroidEntryPoint를 사용할 수 없으므로, 표준 Dagger(@Component)를 사용하여 위에서 정의한 엔트리 포인트와 협업하는 브릿지를 만듭니다.

// login Feature 모듈 내 LoginComponent.kt
@Component(dependencies = [LoginModuleDependencies::class]) // 엔트리 포인트를 의존성으로 지정
interface LoginComponent {
    fun inject(activity: LoginActivity)

    @Component.Builder
    interface Builder {
        fun context(@BindsInstance context: Context): Builder
        // Hilt 그래프에서 추출한 엔트리 포인트를 전달받는 통로
        fun appDependencies(loginModuleDependencies: LoginModuleDependencies): Builder
        fun build(): LoginComponent
    }
}

3. EntryPointAccessors를 사용하여 실제 객체 인스턴스 획득
이제 LoginActivity에서 Hilt 그래프를 직접 열고 객체를 추출합니다. 여기서 EntryPointAccessors.fromApplication은 Hilt가 관리하는 Application 컨텍스트에서 우리가 정의한 엔트리 포인트를 찾아오는 역할을 합니다.

// login Feature 모듈 내 LoginActivity.kt
class LoginActivity : AppCompatActivity() {
    @Inject lateinit var loginAnalyticsAdapter: LoginAnalyticsAdapter

    override fun onCreate(savedInstanceState: Bundle?) {
        // 1. EntryPointAccessors를 통해 Application 범위의 Hilt 그래프에서 엔트리 포인트 계약(Contract)을 추출
        val dependencies = EntryPointAccessors.fromApplication(
            applicationContext,
            LoginModuleDependencies::class.java
        )

        // 2. 추출한 엔트리 포인트를 수동으로 구성한 Dagger Component에 전달하여 주입 수행
        DaggerLoginComponent.builder()
            .context(this)
            .appDependencies(dependencies) // Hilt에서 꺼내온 의존성 주입
            .build()
            .inject(this)

        super.onCreate(savedInstanceState)
    }
}

Hilt를 사용한 의존성 주입

어리둥절범고래 — Tue, 27 Jan 2026 01:27:51 +0900

구성요소에 모듈을 설치하면 이 구성요소의 다른 바인딩 또는 구성요소 계층 구조에서 그 아래에 있는 하위 구성요소의 다른 바인딩의 종속 항목으로 설치된 모듈의 바인딩에 액세스할 수 있습니다. Hilt는 Android 앱에서 의존성 주입(DI)을 쉽게 구현할 수 있도록 도와주는 라이브러리입니다. 내부적으로는 Dagger를 기반으로 하며, Android 컴포넌트와의 통합에 초점을 맞춰 개발자의 생산성을 높여줍니다.

Android 개발에 특화된 DI 자동화

Android의 주요 컴포넌트에 DI 컨테이너를 자동 연결
컴포넌트의 수명 주기를 고려한 의존성 관리 지원
@HiltAndroidApp, @AndroidEntryPoint 등을 통한 간결한 DI 설정
DI 패턴을 표준화하여 팀 개발 및 테스트 코드 작성에 유리

Dagger 기반의 성능과 안정성

컴파일 타임에 의존성 그래프를 생성하여 런타임 성능이 뛰어남
컴파일 시 오류 검출로 안정성 향상
유연한 모듈화와 확장성 제공

Android 클래스 주입과 @AndroidEntryPoint

Hilt를 사용하는 앱은 @HiltAndroidApp이 적용된 Application 클래스를 반드시 포함해야 하며, 이 애노테이션을 통해 애플리케이션 전체에서 사용하는 최상위 DI 컨테이너가 생성되며, Application의 수명 주기에 맞춰 관리됩니다.

@HiltAndroidApp
class ExampleApplication : Application() { ... }

Hilt 사용 시 주요 특징 요약

@HiltAndroidApp으로 설정된 Application 클래스는 Hilt의 최상위 DI 컨테이너 역할을 한다
Hilt는 @AndroidEntryPoint가 지정된 Android 클래스에 의존성 주입을 제공한다
@AndroidEntryPoint는 다음 Android 컴포넌트에서 사용 가능하다
DI를 사용하는 Android 컴포넌트에는 반드시 @AndroidEntryPoint를 붙여야 한다
같은 생명주기를 공유하거나 해당 컴포넌트를 포함하는 상위 컴포넌트도 @AndroidEntryPoint로 지정되어야 한다
Hilt는 컴파일 시 생성되는 코드를 통해 의존성을 주입하기 때문에 필드가 private으로 선언되어 있으면 접근할 수 없어 오류가 발생한다.

@AndroidEntryPoint // Hilt의 주입 대상임을 @AndroidEntryPoint로 표시
class ExampleActivity : AppCompatActivity() {
    @Inject lateinit var analytics: AnalyticsAdapter // @Inject를 통해 주입
}

Hilt 바인딩 정의

Hilt에게 객체를 어떻게 생성해야 하는지를 알려주는 방법은 크게 두 가지입니다.

생성자 주입(Constructor Injection)
Hilt 모듈(Module)

생성자 주입 (@Inject)

가장 간단하고 권장되는 방법은 클래스의 생성자에 @Inject 애노테이션을 부여하는 것입니다.
이렇게 하면 Hilt는 필요한 의존성을 생성자에 자동으로 주입하고, 해당 클래스의 인스턴스를 생성할 수 있게 됩니다.

class AnalyticsAdapter @Inject constructor(
    private val service: AnalyticsService
) {
    ...
}

이 방식은 코드가 간결하고 명확하며, 주입 흐름을 이해하기도 쉬워 Hilt 사용 시 가장 먼저 고려할 수 있는 접근법입니다.

모듈 정의 (@Module)

외부 라이브러리나 인터페이스처럼, 개발자가 직접 생성자에 @Inject를 붙일 수 없는 경우에는 Hilt 모듈을 통해 의존성 생성을 정의할 수 있습니다.

Hilt 모듈을 정의할 때는 @Module 애노테이션과 함께 반드시 @InstallIn 애노테이션을 선언해야 합니다. @InstallIn은 해당 모듈이 어떤 Android 컴포넌트의 생명주기 범위(scope) 내에서 사용될지를 Hilt에 명시적으로 알려주는 역할을 합니다

@Binds: 인터페이스 바인딩

인터페이스와 구현체 간의 바인딩을 설정할 때 사용합니다.
예를 들어, AnalyticsService라는 인터페이스에 대해 AnalyticsServiceImpl을 구현체로 사용하려면 다음과 같이 정의합니다.

interface AnalyticsService {
    fun analyticsMethods()
}

// Hilt가 AnalyticsServiceImpl의 인스턴스를 어떻게
// 만들어야 할지도 알아야 하기 때문에 생성자 주입이 필요하다.
class AnalyticsServiceImpl @Inject constructor(
    ...
) : AnalyticsService {
    override fun analyticsMethods() { ... }
}

@Module
@InstallIn(SingletonComponent::class)
abstract class AnalyticsModule {

    @Binds
    abstract fun bindAnalyticsService(
        impl: AnalyticsServiceImpl
    ): AnalyticsService
}

애노테이션이 지정된 함수는 Hilt에 다음 정보를 제공합니다.

함수 반환 타입은 함수가 어떤 인터페이스의 인스턴스를 제공하는지 Hilt에 알려준다
함수 매개변수는 제공할 구현을 Hilt에 알려준다

@Provides: 외부 클래스 인스턴스 생성

생성자를 직접 제어할 수 없는 외부 클래스 (예: Retrofit, Room 등)의 경우, 인스턴스를 생성하는 로직을 함수 형태로 정의하여 제공합니다.

@Module
@InstallIn(SingletonComponent::class)
object NetworkModule {

    @Provides
    fun provideRetrofit(): Retrofit {
        return Retrofit.Builder()
            .baseUrl("https://api.example.com")
            .build()
    }
}

주석이 달린 함수는 Hilt에 다음 정보를 제공합니다.

함수 반환 타입은 함수가 어떤 타입의 인스턴스를 제공하는지 Hilt에 알려준다
함수 매개변수는 해당 타입의 종속 항목을 Hilt에 알려준다
함수 본문은 해당 타입의 인스턴스를 제공하는 방법을 Hilt에 알려준다
Hilt는 해당 타입의 인스턴스를 제공해야 할 때마다 함수 본문을 실행한다

구성 요소의 수명 주기와 범위(Scope)

Hilt는 객체가 얼마나 오래 살아있어야 하는지를 안드로이드 구성 요소와 연결하여 자동으로 관리합니다.

생성된 구성 요소	인젝터 대상	범위 애노테이션	생성 및 소멸 시점
SingletonComponent	Application	@Singleton	앱 실행 시 생성 ~ 앱 종료 시 소멸
ActivityRetainedComponent	N/A (ViewModel 지원)	@ActivityRetainedScoped	구성 변경(화면 회전 등) 시에도 유지
ViewModelComponent	ViewModel	@ViewModelScoped	ViewModel 생성 시 ~ 소멸 시
ActivityComponent	Activity	@ActivityScoped	onCreate() 생성 ~ onDestroy() 소멸
FragmentComponent	Fragment	@FragmentScoped	onAttach() 생성 ~ onDestroy() 소멸
ServiceComponent	Service	@ServiceScoped	onCreate() 생성 ~ onDestroy() 소멸

Hilt를 사용할 때, 의존성 객체는 기본적으로 범위(Scope)가 지정되지 않은 상태로 제공되며, 해당 객체가 필요할 때마다 항상 새로운 인스턴스가 생성됩니다.

특정 구성요소 범위(Component Scope)를 지정함으로써, 같은 생명주기 내에서 객체를 재사용할 수 있도록 지원합니다.

@ActivityScoped // Activity가 살아 있는 동안에는 항상 동일한 객체를 주입
class AnalyticsAdapter @Inject constructor(
  private val service: AnalyticsService
) { ... }

객체에 범위를 지정하면 메모리에 오래 유지되기 때문에, 무분별한 사용은 오히려 리소스 낭비로 이어질 수 있습니다. 따라서 구성요소 범위는 다음과 같은 경우에만 사용하는 것이 바람직합니다.

내부 상태를 유지해야 하는 객체
생성 비용이 큰 객체
스레드 동기화가 필요한 객체

@Module
@InstallIn(SingletonComponent::class)
abstract class AnalyticsModule {

    @Singleton
    @Binds
    abstract fun bindAnalyticsService(
        analyticsServiceImpl: AnalyticsServiceImpl
    ): AnalyticsService
}

@Module
@InstallIn(SingletonComponent::class)
object AnalyticsModule {

  @Singleton
  @Provides
  fun provideAnalyticsService(): AnalyticsService {
      return Retrofit.Builder()
               .baseUrl("https://example.com")
               .build()
               .create(AnalyticsService::class.java)
  }
}

구성요소 계층 구조

구성요소에 모듈을 설치하면 이 구성요소의 다른 바인딩 또는 구성요소 계층 구조에서 그 아래에 있는 하위 구성요소의 다른 바인딩의 종속 항목으로 설치된 모듈의 바인딩에 액세스할 수 있습니다.

구성요소 기본 바인딩

각 Hilt 구성요소는 Hilt가 고유한 맞춤 바인딩에 종속 항목으로 삽입할 수 있는 기본 바인딩 세트와 함께 제공됩니다.

Android 구성요소	기본 바인딩
SingletonComponent	Application
ActivityRetainedComponent	Application
ViewModelComponent	SavedStateHandle
ActivityComponent	Application, Activity
FragmentComponent	Application, Activity, Fragment
ViewComponent	Application, Activity, View
ViewWithFragmentComponent	Application, Activity, Fragment, View
ServiceComponent	Application, Service

class AnalyticsServiceImpl @Inject constructor(
  @ApplicationContext context: Context
) : AnalyticsService { ... }

class AnalyticsAdapter @Inject constructor(
  @ActivityContext context: Context
) { ... }

@HiltViewModel
class MyViewModel @Inject constructor(
    private val savedStateHandle: SavedStateHandle
) : ViewModel() { ... }

동일 타입의 여러 바인딩과 한정자(Qualifier)

예를 들어, 로그용 OkHttpClient와 인증용 OkHttpClient가 각각 필요하다면 Hilt는 어떤 것을 주입해야 할지 혼란에 빠집니다. 이때 사용하는 '이름표'가 바로 한정자(Qualifier)입니다.

@Binds 또는 @Provides 메서드에 주석을 지정하는 데 사용할 한정자를 정의합니다.

@Qualifier
@Retention(AnnotationRetention.BINARY)
annotation class AuthInterceptorOkHttpClient

@Qualifier
@Retention(AnnotationRetention.BINARY)
annotation class OtherInterceptorOkHttpClient

Hilt는 각 한정자와 일치하는 타입의 인스턴스를 제공하는 방법을 알아야 합니다. @Provides와 함께 Hilt 모듈을 사용하면 두 메서드 모두 동일한 반환 타입을 갖지만 한정자는 다음과 같이 두 가지의 서로 다른 바인딩으로 메서드에 라벨을 지정합니다.

@Module
@InstallIn(SingletonComponent::class)
object NetworkModule {

  @AuthInterceptorOkHttpClient
  @Provides
  fun provideAuthInterceptorOkHttpClient(
    authInterceptor: AuthInterceptor
  ): OkHttpClient {
      return OkHttpClient.Builder()
               .addInterceptor(authInterceptor)
               .build()
  }

  @OtherInterceptorOkHttpClient
  @Provides
  fun provideOtherInterceptorOkHttpClient(
    otherInterceptor: OtherInterceptor
  ): OkHttpClient {
      return OkHttpClient.Builder()
               .addInterceptor(otherInterceptor)
               .build()
  }
}

다음과 같이 필드 또는 매개변수에 해당 한정자로 주석을 지정하여 필요한 특정 유형을 삽입할 수 있습니다.

@Module
@InstallIn(ActivityComponent::class)
object AnalyticsModule {

  @Provides
  fun provideAnalyticsService(
    @AuthInterceptorOkHttpClient okHttpClient: OkHttpClient
  ): AnalyticsService {
      return Retrofit.Builder()
               .baseUrl("https://example.com")
               .client(okHttpClient)
               .build()
               .create(AnalyticsService::class.java)
  }
}

class ExampleServiceImpl @Inject constructor(
  @AuthInterceptorOkHttpClient private val okHttpClient: OkHttpClient
) : ...

@AndroidEntryPoint
class ExampleActivity: AppCompatActivity() {

  @AuthInterceptorOkHttpClient
  @Inject lateinit var okHttpClient: OkHttpClient
}

또한, Hilt는 안드로이드 개발의 편의를 위해 @ApplicationContext와 @ActivityContext라는 사전 정의된 한정자를 기본으로 제공합니다.

class AnalyticsAdapter @Inject constructor(
    @ActivityContext private val context: Context,
    private val service: AnalyticsService
) { ... }

Android의 의존성 주입

어리둥절범고래 — Sun, 25 Jan 2026 23:54:47 +0900

Android 권장 아키텍처는 관심사 분리를 위해 코드를 역할별 클래스로 나누고, 이 과정에서 여러 작은 클래스들이 서로 의존성으로 연결됩니다. 이런 관계는 화살표로 표현한 의존성 그래프로 나타낼 수 있으며, 의존성 주입(DI)을 사용하면 의존성 연결과 테스트용 구현(가짜/모의 객체) 교체가 쉬워집니다.

의존성 주입(DI)은 프로그래밍에 널리 사용되는 기법으로, 의존성 주입을 구현하면 다음과 같은 이점을 누릴 수 있습니다.

코드 재사용 가능
리팩터링 편의성
테스트 편의성

의존성 주입(Dependency Injection, DI)

클래스가 스스로 의존성을 만들거나 찾지 않고, 필요한 것을 주입받아 사용하는 방식입니다.

DI을 실행하는 두 가지 주요 방법은 다음과 같습니다.

생성자 삽입: 클래스의 의존성을 생성자에 전달
필드 삽입(또는 setter 삽입): 의존성은 클래스가 생성된 후 인스턴스화

// 생성자 삽입
class Car(private val engine: Engine) {
    fun start() {
        engine.start()
    }
}

fun main(args: Array) {
    val engine = Engine()
    val car = Car(engine)
    car.start()
}

// 필드 삽입
class Car {
    lateinit var engine: Engine

    fun start() {
        engine.start()
    }
}

fun main(args: Array) {
    val car = Car()
    car.engine = Engine()
    car.start()
}

자동화된 의존성 주입

수동 DI는 라이브러리 없이 개발자가 의존성을 직접 생성, 전달, 관리하는 방식으로 다음과 같은 문제가 존재합니다.

앱 규모가 커질수록 상용구 코드가 급증
다층 구조 아키텍처에서는 상위 객체를 만들기 위해 하위 레이어의 모든 의존성을 계속 전달해야 함
의존성의 생명주기를 관리하는 컨테이너(그래프)를 직접 유지해야 함

이 문제를 해결하기 위해 의존성을 생성하고 제공하는 과정을 자동화해주는 라이브러리들이 있으며, 크게 두 부류로 나뉩니다.

리플렉션 기반: 런타임에 의존성을 연결
정적 방식: 컴파일 타임에 의존성 연결 코드를 생성

의존성 주입의 대안

서비스 로케이터는 DI의 대안으로, 의존성을 미리 생성·보관해두고 필요할 때 클래스에 제공해 구현체와의 결합을 줄이는 패턴입니다.

object ServiceLocator {
    fun getEngine(): Engine = Engine()
}

class Car {
    private val engine = ServiceLocator.getEngine()

    fun start() {
        engine.start()
    }
}

fun main(args: Array) {
    val car = Car()
    car.start()
}

DI는 의존성을 주입받는 방식이라 의존성이 명시적으로 드러나는 편이고, 서비스 로케이터는 의존성을 조회해 가져오는 방식이라 편리할 수 있지만 의존성이 숨겨져 안티패턴으로 보기도 합니다.

DI와 비교

테스트가 어려움: 전역 로케이터를 여러 테스트가 공유해 서로 영향을 줄 수 있음
의존성이 숨겨짐: 생성자/파라미터에 드러나지 않아 클래스가 무엇을 필요로 하는지 파악이 어려움
런타임 오류 위험: 로케이터/의존성 구성이 바뀌면 참조가 깨져 실행 중 오류나 테스트 실패로 이어질 수 있음
스코프 관리가 어려움: 앱 전체가 아닌 특정 화면/흐름 등 “일부 기간”만 살아야 하는 객체의 생명주기 관리가 복잡함

수동 의존성 주입

다음과 같은 그래프의 의존성을 수동 주입을 통해 직접 구현해보도록 하겠습니다.

그래프의 Repository 및 DataSource 클래스는 다음과 같습니다.

class UserRepository(
    private val localDataSource: UserLocalDataSource,
    private val remoteDataSource: UserRemoteDataSource
) { ... }

class UserLocalDataSource { ... }
class UserRemoteDataSource(
    private val loginService: LoginRetrofitService // Retrofit
) { ... }

LoginActivity가 LoginViewModel을 만들기 위해 필요한 의존성들을 직접 생성해서 차례대로 연결합니다.

class LoginActivity : Activity() {

    private lateinit var loginViewModel: LoginViewModel

    override fun onCreate(savedInstanceState: Bundle?) {
        super.onCreate(savedInstanceState)

        // LoginViewModel이 필요로 하는 의존성들을 수동으로 생성/연결하는 예시

        // 1) 네트워크 API(LoginService) 생성
        val retrofit = Retrofit.Builder()
            .baseUrl("https://example.com")
            .build()
            .create(LoginService::class.java)

        // 2) Repository가 필요로 하는 DataSource 생성
        val remoteDataSource = UserRemoteDataSource(retrofit) // 원격 데이터 소스(서버)
        val localDataSource = UserLocalDataSource()           // 로컬 데이터 소스

        // 3) Repository 생성 (local + remote 조합)
        val userRepository = UserRepository(localDataSource, remoteDataSource)

        // 4) ViewModel 생성 (Repository 주입)
        loginViewModel = LoginViewModel(userRepository)
    }
}

이 접근 방식은 다음과 같은 문제가 있습니다.

상용구 코드가 많고 중복됨
생성 순서가 강제됨
재사용과 테스트가 어려워짐

컨테이너로 의존성 관리

객체 재사용 문제를 해결하려면 의존성을 가져오는 데 사용하는 자체 의존성 컨테이너 클래스를 만들면 됩니다.

// 앱 전체에서 공유할 객체(의존성)들을 담는 컨테이너
class AppContainer {

    // UserRepository가 필요로 하는 의존성들을 컨테이너 안에서 한 번만 생성
    private val retrofit = Retrofit.Builder()
        .baseUrl("https://example.com")
        .build()
        .create(LoginService::class.java)

    private val remoteDataSource = UserRemoteDataSource(retrofit)
    private val localDataSource = UserLocalDataSource()

    // 외부에서 사용할 의존성만 공개(예: userRepository)
    val userRepository = UserRepository(localDataSource, remoteDataSource)
}

Application은 앱 프로세스 동안 살아있는 객체로, 싱글톤 패턴을 쓰는 게 아니라 Application이 AppContainer 인스턴스 하나를 들고 있는 구조입니다.

// AndroidManifest.xml에 등록해야 하는 커스텀 Application
class MyApplication : Application() {
    // 앱 전체에서 하나만 만들어서 모든 Activity가 공유
    val appContainer = AppContainer()
}

Activity는 더 이상 Retrofit → DataSource → Repository를 직접 만들지 않고, 컨테이너에서 이미 만들어진 userRepository를 꺼내 쓰기만 합니다. 결과적으로 중복 코드가 줄고, UserRepository도 앱 전체에서 재사용할 수 있습니다.

class LoginActivity: Activity() {

    private lateinit var loginViewModel: LoginViewModel

    override fun onCreate(savedInstanceState: Bundle?) {
        super.onCreate(savedInstanceState)

        // 애플리케이션의 AppContainer 인스턴스에서 userRepository를 가져옵니다
        val appContainer = (application as MyApplication).appContainer
        loginViewModel = LoginViewModel(appContainer.userRepository)
    }
}

UserRepository를 싱글톤으로 만들기보다, 앱 전역의 AppContainer가 필요한 객체를 만들어 공유합니다.
LoginViewModel을 여러 곳에서 쓰게 되면 생성 방식을 한 곳에 모으기 위해 Factory로 ViewModel을 생성합니다.

// 특정 타입의 객체를 만드는 팩토리 인터페이스
interface Factory<T> {
    fun create(): T
}

// LoginViewModel을 생성하는 팩토리
// LoginViewModel은 UserRepository가 필요하므로, 팩토리가 UserRepository를 들고 있다가 생성 시 주입해준다.
class LoginViewModelFactory(private val userRepository: UserRepository) : Factory<LoginViewModel> {
    override fun create(): LoginViewModel {
        return LoginViewModel(userRepository)
    }
}

AppContainer에 LoginViewModelFactory를 포함하여 LoginActivity에서 사용하게 할 수 있습니다.

class AppContainer {
    // (이미 만들어 둔 의존성들)
    val userRepository = UserRepository(localDataSource, remoteDataSource)

    // ViewModel을 만들 “공식 경로”
    val loginViewModelFactory = LoginViewModelFactory(userRepository)
}

class LoginActivity : Activity() {

    private lateinit var loginViewModel: LoginViewModel

    override fun onCreate(savedInstanceState: Bundle?) {
        super.onCreate(savedInstanceState)

        val appContainer = (application as MyApplication).appContainer
        loginViewModel = appContainer.loginViewModelFactory.create()
    }
}

여전히 다음과 같은 문제를 고려해야 합니다.

여전히 개발자가 AppContainer를 직접 설계/관리하면서 모든 의존성을 수동으로 생성
여전히 상용구 코드가 많으며, 객체의 재사용 여부에 따라 수동으로 팩토리나 매개변수를 만들어야 함

애플리케이션 흐름에서 의존성 관리

흐름이 다양하면 객체가 해당 흐름의 범위에만 있기를 원할 수 있습니다.
흐름에 따라 필요하지 않은 인스턴스를 삭제해야 합니다.

AppContainer 내에 FlowContainer 객체를 만들면 가능합니다.

AppContainer: 앱 전체 수명(프로세스) 동안 재사용할 것들([UserRepository)
LoginContainer: 로그인 흐름 동안만 살아야 하는 것들(LoginUserData, 로그인용 ViewModel/Factory)

// FlowContainer
class LoginContainer(val userRepository: UserRepository) {

    // 로그인 흐름 동안 공유할 데이터(새 흐름이면 새 인스턴스)
    val loginData = LoginUserData()

    // 로그인 흐름에서 쓸 ViewModel 생성 도구
    val loginViewModelFactory = LoginViewModelFactory(userRepository)
}

class AppContainer {
    val userRepository = UserRepository(localDataSource, remoteDataSource)

    // 로그인 중이 아닐 땐 null
    var loginContainer: LoginContainer? = null
}

class LoginActivity: Activity() {

    private lateinit var loginViewModel: LoginViewModel
    private lateinit var loginData: LoginUserData
    private lateinit var appContainer: AppContainer


    override fun onCreate(savedInstanceState: Bundle?) {
        super.onCreate(savedInstanceState)
        appContainer = (application as MyApplication).appContainer

        // 로그인 흐름 시작 → LoginContainer 생성해서 AppContainer에 넣음
        appContainer.loginContainer = LoginContainer(appContainer.userRepository)

        // 흐름 컨테이너에서 필요한 것 꺼내 사용
        loginViewModel = appContainer.loginContainer.loginViewModelFactory.create()
        loginData = appContainer.loginContainer.loginData
    }

    override fun onDestroy() {
        // 로그인 흐름 종료 → LoginContainer 제거(메모리 해제 목적)
        appContainer.loginContainer = null
        super.onDestroy()
    }