🤔 Android UI State, 왜 Enum이 아니라 Sealed Class/Interface일까?

🧩 선언형 UI와 상태

Jetpack Compose 같은 선언형 UI를 사용하면 개발자는 상태(State)를 기준으로 화면을 그립니다.

기존의 명령형 UI(예: findViewById, setVisibility)에서는
"버튼을 누르면 이 뷰를 숨기고, 다른 뷰를 보여준다"라는 식으로 UI 조작 로직을 직접 작성해야 했습니다.

하지만 선언형 UI에서는
👉 "현재 상태가 Loading이면 로딩 화면을 그려라"
👉 "현재 상태가 Success라면 데이터를 보여줘라"
👉 "현재 상태가 Error라면 에러 메시지를 출력해라"

즉, UI는 상태의 스냅샷을 그리는 방식으로 바뀌었습니다.
그렇기 때문에 상태를 어떻게 정의하느냐가 앱의 구조와 안정성에 큰 영향을 미칩니다.

---

❓ 왜 아주 단순한 구조인 Enum을 UI State로 사용하지 않을까

처음에는 많은 분들이 이렇게 생각합니다.
"상태를 표현한다면 Enum이 딱이지 않나? 값만 구분하면 되잖아?"

enum class NetworkStatus(val code: Int, val description: String) {
    LOADING(0, "Loading..."),
    SUCCESS(200, "Request succeeded"),
    ERROR(500, "Internal server error");
}

이 코드는 얼핏 보면 그럴싸합니다.
네트워크 요청의 세 가지 상태를 잘 표현하고 있고, 숫자 코드도 붙일 수 있죠.

하지만 실제 UI를 만들다 보면 금방 한계를 느끼게 됩니다.

🚨 한계 1: 상태별로 다른 데이터 전달이 어렵다

• SUCCESS 상태에서는 서버에서 내려준 데이터를 UI에 넘겨줘야 합니다.
• ERROR 상태에서는 단순 코드(500)뿐 아니라, 사용자에게 보여줄 메시지나 예외 객체도 필요합니다.

Enum은 모든 상수가 같은 구조를 가져야 하므로,
상태마다 다른 데이터 구조를 갖게 하기가 사실상 불가능합니다.

---

🚨 한계 2: UI 상태는 종종 “열린 집합”이 아니다

UI State는 보통 "정해진 몇 가지 상태"만 있으면 충분합니다.
예를 들어 로그인 화면이라면

• Idle
• Loading
• Success
• Error

이 정도면 끝입니다.
그런데 Enum은 본질적으로 "열린 구조"라기보다는, 상태별로 데이터까지 다루기에는 너무 단순한 틀이죠.

즉, Enum은 UI State를 표현하기엔 표현력이 부족합니다.

---

✅ Sealed Class – 상태와 데이터를 함께 표현

그래서 등장하는 게 sealed class입니다.
sealed class는 닫힌 계층 구조를 가지며, 상태와 데이터를 함께 정의할 수 있습니다.

sealed class LoginUiState {
    object Idle : LoginUiState()
    object Loading : LoginUiState()
    data class Success(val userName: String) : LoginUiState()
    data class Error(val message: String, val code: Int? = null) : LoginUiState()
}

여기서 주목할 점은,
각 상태가 자기에게 필요한 데이터만 정의할 수 있다는 것입니다.

• Loading → 별도 데이터 필요 없음
• Success → 사용자 이름 필요
• Error → 메시지와 에러 코드 필요

---

💡 Compose에서의 사용 예시

when (uiState) {
    is LoginUiState.Idle -> IdleScreen()
    is LoginUiState.Loading -> LoadingScreen()
    is LoginUiState.Success -> WelcomeScreen(uiState.userName)
    is LoginUiState.Error -> ErrorScreen(uiState.message)
}

• when 구문에서 컴파일러가 모든 상태를 강제 체크해주기 때문에,
  새로운 상태를 추가하면 분기문에서 누락된 부분을 IDE가 알려줍니다.
• 이는 런타임 에러를 컴파일 타임에 잡을 수 있다는 강력한 장점입니다.

👉 즉, sealed class는 UI State를 표현할 때 안전성과 가독성을 동시에 확보할 수 있습니다.

---

⚡ Sealed Interface – 더 유연한 확장성

sealed interface는 sealed class와 거의 비슷하지만, 다중 상속이 가능하다는 점에서 더 유연합니다.

sealed interface UiState

object Loading : UiState
data class Success(val data: List<String>) : UiState
data class Error(val message: String) : UiState

다른 인터페이스와 조합 예시

interface Loggable {
    val log: String
}

data class Error(
    val message: String,
    override val log: String
) : UiState, Loggable

이렇게 하면 Error는 UI State이면서 동시에 Loggable한 성격도 가질 수 있습니다.
즉, 상태를 다양한 맥락에서 재사용할 수 있는 확장성을 제공합니다.

---

🧩 왜 sealed가 중요한가?

여기서 핵심은 sealed라는 키워드 자체입니다.

일반 class나 interface는 어디서든 상속/구현이 가능합니다.
즉, 상태 집합이 열려(Open) 있어서 외부에서 새로운 하위 타입이 추가될 수 있죠.

UI State에선 이런 게 위험합니다.
로그인 화면의 상태는 Idle, Loading, Success, Error만 있으면 되는데,
누군가 외부 모듈에서 HalfSuccess 같은 이상한 상태를 추가해버리면?
👉 when 분기에서 처리하지 못한 상태가 생겨, 런타임 에러로 이어질 수 있습니다.

sealed를 쓰면:

• 하위 타입을 같은 파일 내에서만 정의 가능 → 상태 집합이 닫힘(Closed set)
• 컴파일러가 when에서 모든 상태를 강제 체크 → 누락 방지

📌 정리하자면, sealed의 가장 큰 의미는 “여기 정의된 상태 외에는 없다”를 보장하는 것입니다.
이 덕분에 UI State를 정의할 때 sealed class/interface가 빛을 발합니다 ✨

---

🔍 정리

• enum → 단순 상태 구분에 적합 (예: Theme { LIGHT, DARK })
• sealed class → 상태 + 데이터를 표현할 수 있어 UI State 관리에 최적
• sealed interface → 다형성과 확장성이 필요한 상황에서 유리
• sealed → 상태 집합을 닫아주고, 컴파일러가 모든 경우를 강제 체크하게 해줌

---

👉 Compose에서 UI State를 정의할 때는
enum보다 sealed class/interface를 쓰는 것이 훨씬 안전하고 표현력이 풍부합니다 💡

UI State는 곧 앱의 안정성과 직결되는 핵심 요소입니다.
작은 선택 하나가 전체 아키텍처의 품질을 크게 바꿀 수 있습니다 🚀