2편 Android 개발자의 사고는 Compose에서 어떻게 바뀌는가

— View 중심 사고에서 State 중심 사고로

Compose를 처음 보면 많은 Android 개발자들이 이렇게 느낍니다.

“XML 대신 Kotlin으로 UI 만드는 거네?”

 

하지만 실제로 Compose의 가장 큰 변화는 문법이 아닙니다.

진짜 변화는:

객체(View) 중심 사고
→
상태(State) 중심 사고

로의 이동입니다.

 

이 변화는 생각보다 훨씬 큽니다.

왜냐하면 Android 개발자들은 오랫동안:

• View 객체를 만들고
• 직접 수정하고
• 이벤트를 연결하고
• Lifecycle을 따라 상태를 관리하는 방식

에 익숙해져 있었기 때문입니다.

Compose는 이 흐름 자체를 바꾸려고 합니다.

---

기존 Android 개발 방식

전통적인 Android UI는 기본적으로:

“화면 객체(View)를 직접 조작”

 

하는 방식이었습니다.

예를 들어 로그인 버튼 활성화.

---

기존 View 방식

button.isEnabled =
    idEditText.text.isNotBlank() &&
    passwordEditText.text.isNotBlank()

우리는 자연스럽게:

Button 객체를 직접 수정

합니다.

즉 사고 흐름이:

현재 UI 객체 상태를 어떻게 변경할까?

입니다.

---

Compose의 사고 방식

Compose에서는 완전히 다르게 접근합니다.

@Composable
fun LoginScreen() {

    var id by remember { mutableStateOf("") }
    var pw by remember { mutableStateOf("") }

    val enabled = id.isNotBlank() &&
                  pw.isNotBlank()

    Column {

        TextField(
            value = id,
            onValueChange = { id = it }
        )

        TextField(
            value = pw,
            onValueChange = { pw = it }
        )

        Button(
            enabled = enabled,
            onClick = {}
        ) {
            Text("로그인")
        }
    }
}

여기서는:

button.enable()

같은 코드가 없습니다.

Compose에서는:

“현재 상태가 무엇인가?”

만 정의합니다.

---

가장 중요한 사고 변화

Compose를 배우며 가장 중요한 변화는 이것입니다.

---

기존 Android 사고

UI를 어떻게 조작할까?

---

Compose 사고

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

---

이 차이는 단순 문법 차이가 아닙니다.

Architecture 전체에 영향을 줍니다.

---

RecyclerView 사고 vs LazyColumn 사고

Android 개발자들이 가장 크게 체감하는 변화 중 하나입니다.

---

기존 RecyclerView 사고

우리는 오랫동안 이런 구조에 익숙했습니다.

RecyclerView
 └ Adapter
     └ ViewHolder

그리고 주요 고민은:

• View 재사용
• notifyDataSetChanged()
• partial update
• payload
• ViewHolder 최적화

였습니다.

즉:

리스트를 어떻게 효율적으로 갱신할까?

에 집중했습니다.

---

Compose 방식

Compose에서는:

LazyColumn {

    items(users) { user ->

        Text(user.name)
    }
}

처럼 작성합니다.

여기서 핵심은:

“어떻게 갱신할까?”

가 아니라

“현재 데이터가 무엇인가?”

입니다.

---

사고 흐름 비교

기존 Android

데이터 변경
→ Adapter notify
→ View 갱신

---

Compose

State 변경
→ Recomposition
→ UI 재계산

---

Compose에서는:

UI 갱신을 직접 지시

하지 않습니다.

상태가 바뀌면 UI가 자동으로 다시 계산됩니다.

---

Fragment Navigation 사고 변화

이 부분도 매우 중요합니다.

---

기존 Android Navigation

우리는 오랫동안:

Activity
 └ Fragment A
      └ Fragment B

구조에 익숙했습니다.

그리고:

fragmentManager.beginTransaction()

중심으로 사고했습니다.

즉:

“화면 객체를 이동”

하는 개념입니다.

---

Compose Navigation 사고

Compose에서는:

현재 App State가 무엇인가?

관점으로 접근합니다.

예:

sealed class Screen {

    object Home : Screen()

    object Detail : Screen()
}

when(screen) {

    is Screen.Home -> HomeScreen()

    is Screen.Detail -> DetailScreen()
}

즉:

화면 이동

보다

현재 화면 상태 변화

에 가깝습니다.

---

화면 회전 대응 사고 변화

Android 개발자들이 오랫동안 고생한 부분입니다.

---

기존 Android

회전 시:

onSaveInstanceState()

를 많이 다뤘습니다.

Lifecycle 중심 사고였습니다.

---

Compose

Compose에서는:

rememberSaveable

같은 상태 보존 메커니즘을 사용합니다.

예:

var text by rememberSaveable {
    mutableStateOf("")
}

즉 사고가:

Lifecycle 대응

에서

상태 보존 전략

으로 이동합니다.

---

비동기 처리 사고 변화

이 변화도 매우 큽니다.

---

기존 Android

기존에는:

• callback
• listener
• handler
• LiveData observer

중심이었습니다.

즉:

Event 처리

가 핵심이었습니다.

---

Compose

Compose에서는:

val uiState by
    viewModel.uiState.collectAsState()

처럼:

상태 Stream을 관찰

합니다.

예:

when(uiState) {

    is Loading -> LoadingUI()

    is Success -> SuccessUI()

    is Error -> ErrorUI()
}

즉:

비동기 이벤트 처리

보다

Reactive State Flow

가 중심이 됩니다.

---

Compose의 핵심은 UI가 아니다

많은 사람들이 Compose를:

새로운 UI Toolkit

으로만 생각합니다.

하지만 실제 핵심은:

Data Flow Architecture 변화

입니다.

---

기존 Android 사고 vs Compose 사고

기존 Android	Compose
View 조작	State 선언
notifyDataSetChanged	자동 recomposition
Fragment 이동	Screen state
callback 중심	reactive stream 중심
imperative UI	declarative UI
mutable object	immutable state 지향
lifecycle callback	state-driven UI

---

Android 전문가가 처음 헷갈리는 이유

Android 경험이 깊을수록 처음엔 Compose를 보며:

“이건 그냥 DSL UI 아닌가?”

처럼 느끼기 쉽습니다.

왜냐하면 처음엔:

• Text()
• Button()
• Column()

같은 문법만 보이기 때문입니다.

하지만 실제 핵심은:

UI = f(state)

라는 철학입니다.

즉:

“UI를 함수처럼 생각하기”

입니다.

---

Compose를 이해하는 가장 중요한 문장

Compose를 이해하는 가장 중요한 문장은 이것입니다.

현재 상태가 바뀌면
UI는 다시 계산된다.

Compose 개발은 결국:

상태 흐름을 설계하는 작업

에 가깝습니다.

---

실전에서 가장 추천하는 연습

Compose 학습에서 가장 중요한 건:

State 흐름 체감

입니다.

그래서 단순 Counter보다:

• 로그인 화면
• 검색 리스트
• 실시간 대시보드
• 채팅 UI
• 운전 점수 Dashboard

같은 예제가 훨씬 좋습니다.

---

예를 들어 운전 Dashboard는:

• GPS Stream
• 속도 변화
• 위험 이벤트
• 리스트
• Flow
• recomposition
• Lifecycle
• Hybrid UI

전부 경험할 수 있습니다.

---

마무리

Compose의 진짜 변화는:

XML → Kotlin

이 아닙니다.

실제로는:

View 중심 사고
→
State 중심 사고

로의 이동입니다.

그리고 이 변화는:

• UI 구조
• Architecture
• Data Flow
• Navigation
• 비동기 처리
• 상태 관리

전체를 바꿉니다.

그래서 Compose를 제대로 배우려면:

“Composable 문법”

보다

“상태 흐름을 어떻게 설계할까?”

를 먼저 고민해야 합니다.

다음 글에서는:

“Compose에서 반드시 이해해야 하는 핵심 개념들”

을 실제 코드와 함께 정리해보겠습니다.