— Compose는 UI Toolkit이 아니라 패러다임 전환이다

Compose를 처음 접하면 보통은 이렇게 생각하기 쉽습니다.

“XML 대신 Kotlin으로 UI 만드는 기술”

실제로 처음 보이는 것도:

Text()
Button()
Column()

같은 UI 함수들입니다.

그래서 처음에는:

"새로운 UI DSL"

정도로 느껴질 수 있습니다.

하지만 Compose를 조금 깊게 사용하기 시작하면 점점 다른 느낌이 옵니다.


Compose를 쓰며 느끼는 변화

어느 순간부터 개발 흐름이 바뀌기 시작합니다.

예전에는:

View를 어떻게 조작할까?

를 고민했다면,

Compose에서는:

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

를 고민하게 됩니다.

그리고 이 변화는 단순 UI 기술 변경이 아닙니다.

실제로는:

  • Architecture 변화
  • Data Flow 변화
  • 상태 관리 방식 변화
  • Navigation 사고 변화
  • UI 설계 방식 변화

까지 이어집니다.


Android UI는 원래 어떤 구조였을까

Android의 전통적인 UI 시스템은 기본적으로:

Mutable Object Tree

기반이었습니다.

즉:

View 객체 생성
→ 속성 수정
→ invalidate()
→ redraw

구조입니다.

예:

textView.text = "Hello"
button.visibility = View.GONE

우리는 오랫동안:

“화면 객체를 직접 수정”

하는 방식으로 UI를 개발했습니다.


이 방식의 장점

이 구조는 매우 직관적입니다.

특히 Android 초기에는:

  • 단순 화면
  • 로컬 상태
  • 적은 비동기 처리

환경에서는 잘 동작했습니다.

그리고 Android Framework는:

  • Lifecycle
  • View hierarchy
  • Adapter
  • Fragment

등을 중심으로 발전했습니다.


하지만 앱이 복잡해졌다

문제는 앱 구조가 점점 복잡해졌다는 것입니다.

현대 앱은:

  • 실시간 데이터
  • streaming UI
  • AI 응답
  • 지도
  • reactive stream
  • 멀티 디바이스
  • 비동기 이벤트

가 매우 많아졌습니다.

예:

채팅
뉴스 피드
실시간 운전 정보
AI Assistant
Video Streaming

이런 구조에서:

View를 직접 수정하는 방식

은 점점 복잡해졌습니다.


Compose가 바꾼 것

Compose는 이 흐름을 바꾸기 시작했습니다.

핵심 철학은 단 하나입니다.

UI = f(state)

즉:

“현재 상태를 기반으로 UI를 계산한다”

입니다.


중요한 변화

Compose는:

UI 객체를 조작

하는 것이 아니라

상태를 선언

합니다.


예:

기존 Android

button.isEnabled = true

Compose

Button(
    enabled = canSubmit
)

Compose는:

현재 상태가 무엇인가?

만 보고 UI를 다시 계산합니다.


Compose의 진짜 핵심

많은 사람들이 Compose의 핵심을:

Declarative UI

라고 말합니다.

물론 맞는 말입니다.

하지만 실제 더 중요한 변화는:

Control 중심 Architecture
→
State 중심 Architecture

입니다.


기존 Android 사고

기존 Android에서는:

화면을 어떻게 조작할까?

가 중심이었습니다.


Compose 사고

Compose에서는:

현재 상태를 어떻게 모델링할까?

가 중심이 됩니다.


그래서 Flow와 Compose가 잘 맞는다

Compose를 쓰다 보면 자연스럽게 이런 구조로 갑니다.

Repository
   ↓
Flow
   ↓
ViewModel
   ↓
StateFlow
   ↓
Compose UI

왜냐하면 Compose는:

상태(State)를 기반으로
UI를 다시 계산하는 시스템

이기 때문입니다.


Compose는 함수형 UI에 가깝다

Compose는 결국:

UI를 함수처럼 생각하는 방식

입니다.

즉:

UI = f(state)

입니다.


기존 View 시스템

기존에는:

mutable object

를 직접 수정했습니다.


Compose 시스템

Compose에서는:

현재 상태 → 함수 실행 → UI 계산

입니다.

즉:

UI가 “객체”보다 “계산 결과”에 가까워집니다.


React / SwiftUI / Flutter와의 공통점

흥미로운 점은:

  • React
  • SwiftUI
  • Flutter
  • Compose

모두 비슷한 방향으로 이동하고 있다는 것입니다.

공통 철학은:

State-driven UI

입니다.


왜 이런 흐름이 생겼을까

현대 UI는:

  • 비동기 이벤트
  • 실시간 데이터
  • 네트워크 상태
  • 사용자 상호작용

이 계속 변화합니다.

즉:

UI가 "고정된 화면"

이 아니라:

계속 변화하는 상태의 흐름

이 되었습니다.

그래서:

상태를 중심으로
UI를 계산하는 구조

가 더 자연스러워졌습니다.


Compose를 배우며 다시 보이는 Android Architecture

Compose를 깊게 사용하다 보면 기존 Android Architecture도 다시 보이기 시작합니다.

예:

  • Fragment는 상태 컨테이너처럼 보이고
  • RecyclerView는 state rendering 문제처럼 보이고
  • Navigation은 route state처럼 보이고
  • Lifecycle도 state transition처럼 보입니다.

즉:

Android Architecture 전체를
상태 흐름 관점으로 다시 보게 된다

는 변화가 생깁니다.


Compose가 중요한 이유

Compose의 진짜 의미는:

XML 제거

가 아닙니다.

실제로는:

Android 개발 사고방식 자체 변화

에 가깝습니다.


Android 경험자는 왜 유리한가

기존 Android 경험이 깊다면:

  • Lifecycle
  • Threading
  • Performance
  • Navigation
  • Multimedia
  • Reactive stream

경험이 이미 있기 때문에 Compose에서도 강점이 있습니다.

특히:

  • Flow
  • Coroutine
  • 상태 변화
  • 이벤트 흐름

에 익숙하다면 Compose를 훨씬 빠르게 이해할 수 있습니다.


하지만 가장 어려운 변화

Compose에서 가장 어려운 것은 결국 이것입니다.

View 중심 사고를
버리는 것

입니다.


Compose를 잘한다는 것

Compose를 잘한다는 것은:

Fancy UI를 만드는 것

보다:

상태 흐름을 명확하게 설계하는 것

에 가깝습니다.


앞으로 Android는 어떻게 될까

개인적으로 Compose 이후 Android 개발은 점점:

Reactive
+
State-driven
+
Function-oriented

방향으로 갈 가능성이 높다고 생각합니다.

그리고 이는 단순 Android만의 흐름이 아닙니다.

전체 UI 개발 생태계가 같은 방향으로 이동하고 있습니다.


Compose와 AI 시대

흥미로운 부분은 Compose의 구조가 AI 시대와도 잘 맞는다는 점입니다.

왜냐하면 AI 시스템 역시:

상태(State)
+
Event
+
Stream
+
Reactive Flow

중심으로 움직이기 때문입니다.

예를 들어:

  • Streaming Text
  • Tool Execution State
  • AI Agent Workflow
  • Real-time Suggestion UI

등은 모두:

State 변화 기반 UI

와 잘 맞습니다.


Compose를 한 문장으로 정리하면

Compose는 단순히:

새로운 Android UI Toolkit

이 아닙니다.

실제로는:

상태(State)를 중심으로
UI와 Architecture를 다시 설계하는 방식

에 가깝습니다.


시리즈를 마무리하며

이번 시리즈에서는:

  1. Compose는 왜 등장했는가
  2. Android 개발자의 사고는 어떻게 바뀌는가
  3. Compose 핵심 개념
  4. 예제로 배우는 Compose
  5. 실무 Compose Architecture
  6. Compose를 배우며 다시 생각한 Android Architecture

흐름으로 Compose를 정리해보았습니다.

결국 Compose의 핵심은:

UI를 어떻게 만들까?

보다

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

에 있습니다.

그리고 이 변화는 단순 UI 기술 변화가 아니라:

Android 개발 사고방식 자체의 변화

라고 볼 수 있습니다.

+ Recent posts