[안드로이드] UI 상태 관리: 상태 생성

안드로이드 앱을 만들다 보면  UI 상태(UI state)를 어떻게 관리할지 고민이 많아진다. 특히 상태를 어디서 만들고, 누가 책임지고, 어떻게 UI와 연결할지가 중요하다. 

 

UI 상태란?

앱 화면(UI)은 기본적으로 데이터에 따라 바뀐다. 예를 들어 로딩 중일 때는 스피너가 돌고, 데이터가 로드되면 리스트를 보여주고, 에러가 나면 메시지를 보여주는 식이다.

이처럼 화면을 구성하는 데 필요한 데이터를 UI 상태(UI State)라고 부른다. 보통 다음 세 가지 상태가 있다.

• 로딩 상태 (Loading)
• 성공 상태 (Success)
• 에러 상태 (Error)

그리고 이 상태는 단방향 데이터 흐름(Unidirectional Data Flow) 안에서 관리되어야 한다. 즉, 데이터는 한 방향으로만 흘러가야 예측 가능하고 버그가 줄어든다.

 

UI 상태를 어디서 만들어야 할까?

상태를 만드는 곳을 UI 상태의 생산지(state producer)라고 한다. 보통 세 가지 위치 중 하나에서 상태가 만들어진다.

1. UI 자체에서 만드는 경우 (View/UI State as Source of Truth)

이 경우에는 UI 컴포넌트(예: Fragment, Activity, Compose 등)가 직접 상태를 만든다. 예를 들어 remember { mutableStateOf(...) }나 LiveData를 UI에서 선언하는 방식이다.

이 방식은 단순한 화면에서는 괜찮지만, 로직이 복잡해지면 문제가 많아진다.

문제점:

• 상태가 UI에 묶여 있어 재사용이나 테스트가 어려움
• 화면 회전 등 생명주기 변화에 취약
• 여러 UI에서 동일한 데이터를 공유하기 어려움

언제 괜찮을까?

• 매우 단순한 UI
• 일회성 이벤트 처리 등

 

2. ViewModel에서 상태를 만드는 경우 (Recommended)

가장 권장되는 방식이다. 상태를 ViewModel에서 생성하고 관리하면서 UI는 이를 구독만 한다. 예를 들어

val uiState: StateFlow<UiState> = _uiState

ViewModel이 StateFlow나 LiveData 등을 통해 UI 상태를 만들어 내고, UI는 이를 collectAsState() 혹은 observe() 등으로 감지해서 화면을 갱신한다.

장점:

• ViewModel은 생명주기와 독립적이기 때문에 UI가 재생성되어도 상태 유지 가능
• 테스트와 유지보수에 유리
• 복잡한 UI 로직도 깔끔하게 분리 가능

 

3. Repository 또는 Domain Layer에서 만드는 경우

일부 앱에서는 상태를 Repository에서 만드는 경우도 있다. 예를 들어 서버 통신 결과를 Resource<Success, Error, Loading> 등의 형태로 내보내는 방식이다.

 

하지만 Repository는 데이터 소스의 진실된 소스(Source of Truth)가 되어야지, UI 상태의 생산지가 되어선 안 된다.

왜냐하면 UI 상태는 UI와 밀접하게 연관되어 있어서, 앱의 UI 정책에 따라 상태 구조가 달라질 수 있기 때문이다.

 

예를 들어 로딩 상태를 UI에서만 보여줄지, 여러 종류로 구분할지 등은 UI 설계의 문제다.

Repository는 도메인 데이터만 관리하고, UI 상태는 ViewModel에서 생산해야한다.

 

UI 상태를 어떻게 표현할까?

보통 UI 상태는 sealed class나 data class로 표현한다. 예를 들어:

sealed interface UiState {
    object Loading : UiState
    data class Success(val data: List<Item>) : UiState
    data class Error(val message: String) : UiState
}

이렇게 하면 각 상태별로 분기 처리를 할 수 있어 안전하고 명확하다.

Compose에서는 when(uiState)로 상태에 따라 다른 UI를 보여주면 된다. 예:

when (val state = uiState) {
    is UiState.Loading -> CircularProgressIndicator()
    is UiState.Success -> ItemList(items = state.data)
    is UiState.Error -> Text("에러 발생: ${state.message}")
}

 

 

단방향 데이터 흐름을 지키자

UI 상태를 제대로 관리하려면 단방향 데이터 흐름(Unidirectional Data Flow, UDF)을 지켜야 한다.

흐름은 다음과 같다:

1. UI가 사용자 입력을 받는다
2. ViewModel이 입력을 받아 상태를 변경한다
3. 변경된 상태를 UI가 구독하고 렌더링한다

즉, UI는 상태를 만들지 않고, ViewModel이 상태를 생산하고 UI는 반응만 한다.

이 패턴을 따르면 앱이 커져도 유지보수가 쉬워진다. 버그가 적고, 테스트도 용이하다.

 

결론

• UI 상태는 화면을 구성하는 모든 데이터를 말한다
• 상태의 생산지는 ViewModel이 가장 이상적이다
• Repository는 데이터 원천으로서 역할만 수행하고, UI 상태를 만들지 않는다
• 단방향 데이터 흐름을 유지해야 앱이 예측 가능하고 안정적이다
• sealed class를 이용해 상태를 명확히 표현하고, UI에서 분기 처리 해야한다

앱의 규모가 커질수록 UI 상태 관리는 핵심이 된다. 결국 중요한 건, 누가 상태를 만들고 누가 반응할지를 명확히 나누는 것이다.