[Android] JetPack Compose ViewModel이 필수적인 이유/UI에 상태 관리하면 생기는 문제

 Composable은 'UI만 그린다'

 

부작용은 ViewModel이나 외부에서 처리한다

Composable 안에서 직접 SharedPreferences나 DB를 만지지 말라

 

이게 안드로이드의 권장 방식이다.

권장 방식은 따르는 게 맞다.

 

 

 

 

부작용이란?

= UI를 그리는 것 외에, 다른 것을 변경하는 작업

예) SharedPreferences 쓰기, ViewModel 데이터 수정 등.

 

로컬 변수의 값 변경

예) Compose함수 안에서 items++ 후 이 값을 UI에 표시

 

 

 

부작용을 왜 Composable에서 하면 안되는가?

한 파일에 하면 편하지 않나 의문이 들 수 있다.

하지만, 

Composable이 디자이너,

ViewModel이 개발자라고 생각하면 편하다.

 

 

화면 디자인 업무를 맡은 사람에게 데이터 저장, DB 설계, 상태관리까지 요구하면 어떻게 되는가.

과부하가 온다.

할 게 너무 많으니 우선 디자인부터 하고 저걸 하면 느리다.

그래서 역할을 나눈 거다.

Compose함수는 애니메이션 등 자주 실행되는 함수이기에 속도가 빨라야 하는데 부작용을 실행하면

느려지거나 이상한 동작을 할 수 있기 때문이다.

 

 

Composable에서는 UI만 그리고, UI에서 업데이트해야할 데이터와 상태는

ViewModel에서 업데이트된 경우에만 Composable에서 재구성하여 반영한다.

 

 

전체적인 흐름

ViewModel이 외부에서 가져온 데이터를 Composable에 전달해서 받은 후

Composable에서 콜백 함수 또는 값을 전달하면 즉, 이벤트를 발생시키면 ViewModel이 저장하고 처리함.

상태가 바뀌었으니 Compose가 다시 재구성함 → UI 자동 반영

 

결론은 Composable에서 상태를 변경하는 게 아니라

ViewModel에서 변경된 상태를 Composable에서 인식 후 자동 반영한다는 것이다.