<div id="readability-page-1" class="page"><div id="ArticleView"> <h3>Compose 등장 배경</h3>XML을 사용하는 기존 안드로이드 View로도 여전히 좋은 앱을 개발할 수 있다. 하지만 처음 안드로이드가 등장한 후 많은 시간이 흐르며 개발 패러다임 또한 변했다. 초기 안드로이드 개발에서는 아키텍처라고 할만한 것이 없었다. 현재는 데이터와 UI의 역할을 명확히 분리하는 MVVM이나 클린 아키텍처와 같은 개념이 표준처럼 여겨지고 있다. 또한 개발 언어가 Java에서 Kotlin으로 전환된 것도 큰 변화였다. 이러한 흐름 속에서 View 자체가 상태를 가지는 기존 방식은 최신 아키텍처와 결합할 때 불필요한 복잡성을 야기한다. 따라서 최신 아키텍처에 기반한 새로운 UI 개발 도구의 필요성이 대두되었고 그 결과 Jetpack Compose가 등장했다.<h3>Compose 주요 특징</h3>선언형 UICompose와 기존 XML 방식의 View의 가장 뚜렷한 차이점은 Compose는 선언형 UI라는 것이다. 선언형 UI는 상태가 UI를 결정하도록 하는 것이다. 이에 대해서는 여러 가지 표현이 있다. 상태가 UI로 변환된다.상태에 따라 UI를 그린다.결국 말하고자 하는 것은 같다. 상태를 구독하고 그 상태가 변경되면 자동으로 화면이 갱신되는 것이다. 예를 들어 버튼 클릭 시 단순히 숫자를 증가시키는 카운팅 UI를 Compose로 구현하면 다음과 같다.<div data-app="{&quot;type&quot;:&quot;gridGallery&quot;,&quot;caption&quot;:&quot;&quot;,&quot;displayOption&quot;:&quot;InnerCenter&quot;,&quot;images&quot;:[{&quot;url&quot;:&quot;http://t1.daumcdn.net/brunch/service/user/2Kn8/image/PkbB8wd_0_4ExNjTOKB-Spja-L4.png&quot;,&quot;width&quot;:&quot;300&quot;,&quot;height&quot;:&quot;669&quot;,&quot;originalName&quot;:&quot;Screenshot_20250823_014735.png&quot;}]}"><img alt="Screenshot_20250823_014735.png" src="https://img1.daumcdn.net/thumb/R1280x0.fpng/?fname=http://t1.daumcdn.net/brunch/service/user/2Kn8/image/PkbB8wd_0_4ExNjTOKB-Spja-L4.png"> </div>10라인과 11라인을 보면 된다. 11라인에서 count++로 count의 상태를 변경한다. 그러면 변경된 값이 10라인의 텍스트를 그려주는 Text()라는 함수를 통해서 UI에 반영된다. 사실상 Compose의 주요 장점들은 선언형 UI의 장점이기도 하다.<blockquote>상태를 구독하고 UI에 반영하는 것은 기존 XML 방식에서 DataBinding을 사용하면 충분히 가능하다. 하지만 DataBinding은 선언형 형식을 차용한 기존 View 시스템에서 돌아가는 라이브러리일 뿐이다. 따라서 겉으로는 선언형처럼 동작하지만 결국 내부적으로는 기존 View 객체를 찾아 setText() 같은 메서드를 호출한다. 반면 Compose는 기존 View 시스템을 대체하는 완전한 선언형 UI이다.</blockquote>버그 감소만약 카운팅 UI를 XML 방식 View로 구현하면 어떻게 될까? 일단 XML을 정의해야 한다. 일단 여기서부터 UI 작업을 위한 코드의 파편화가 발생한다는 단점이 있다.다음으로 Activity에서 값을 증가시키고 변경된 상태를 UI에 반영하도록 한다.여기서 13라인을 주목하자. counterText.text는 결국 setText() 메서드를 호출하는 것이다. 즉 개발자가 직접 UI 업데이트를 위한 함수를 일일이 호출해야 한다. 이때 업데이트 누락 등의 실수를 하면 버그가 발생한다. 버그 발생 가능성이 높아지는 것이다.잠깐! Compose에서 Text(text = "$count", fontSize = 30.sp)는 개발자가 직접 UI 업데이트를 위한 함수를 호출한 것이 아닌가? 여기서 또 선언형 UI의 특징에 대해 추가적으로 알아야 할 사항이 있다. 바로 리컴포지션이다.리컴포지션(Recomposition)선언형 UI는 상태를 UI로 변환한다고 했다. 대신 UI는 변경할 수 없고 한 번 생성하면 업데이트가 불가능하다. 이것이 기존에 그려진 UI 요소를 직접 수정하는 방식이 아니라는 의미와 같다. 왜냐하면 선언형 UI인 Compose는 상태가 바뀔 때마다 새로운 상태에 맞는 UI를 다시 그려서 기존 UI를 대체하기 때문이다. 이것을 리컴포지션이라고 한다.XML 방식에서 setText()를 호출하여 명령을 내리는 것은 결국 TextView 객체를 찾아가서 객체의 상태를 직접 수정하는 것이다. 즉 객체의 내부 값만 바뀌는 것이다. 비유하면 보고서 문서의 특정 단어를 수정하는 방식이다. 하지만 Compose는 상태가 변경된 부분만 효율적으로 갱신한다. 보고서 문서를 재검토하면서 변경된 단어만 변경하여 갱신한다.얼핏 보면 동일한 방식 같다. '특정 단어를 수정하는 방식'이나 '변경된 단어만 변경하는 것'이나 같은 말을 두고 말장난하는 것이 아닌가 싶을 것이다. 하지만 여기서 중요한 두 가지 차이점이 있다.1) 보고서 결재 라인이 다르다.보고서의 글자 하나를 수정했지만 기존 XML 방식과 Compose는 결재 라인이 다르다. XML 방식은 이사급 결재가 필요하다면 Compose는 팀장급 결재만 필요하다. View 렌더링 과정을 생각해 보면 된다. XML 방식은 invalidate() 혹은 requestLayout()까지 호출되어 사소한 변경하나로 인해 뷰 계층 전체에 걸친 연산을 발생할 수 있다. 반면 Compose는 상태와 연결된 함수를 다시 호출(리컴포지션)한다. 해당 함수 내에서 실제 변화가 있는 Text()만 실제 UI 변경이 적용된다. 이 과정이 기존 XML 방식 View보다 경량화되어 있다.2) Compose는 특정 상태에 대한 UI 형태다.앞서 UI는 변경할 수 없고 한 번 생성하면 업데이트가 불가능하다고 했다. 이것은 실제로 개발자가 UI를 커스텀할 수 없다는 말이 아니다. 이미 완성된 하나의 UI 코드에 대한 이야기다. 위 예제 코드에서 Counter() 함가 완성된 하나의 UI 코드이다. 이 코드 내부를 수정하여 버튼을 추가하거나 텍스트 위치를 옮길 수 없다는 말이 아니라는 것이다. 대신 Counter()가 완성된 후에는 어떻게 화면에 그려질지 확정된다. 확정된 상황에서는 상태에 따라 확정된 결과를 보여줄 뿐이다. 그리고 상태가 변경되면 변경된 UI 객체를 업데이트(수정) 하는 방식이 아니라 새로운 UI를 그려서 교체하는 방식이다. 반면 XML 방식은 앞서 말했듯 객체의 속성이 변한다. 즉 기존 UI를 직접 수정하는 방식이다.확정된 상황에서 상태에 따라 확정된 결과를 보여주는 것은 무엇인가? 개발자에겐 익숙한 바로, 함수다. f(x) = x + 1라는 함수가 있으면 x의 값(상태)에 따라 x + 1이라는 확정된 결과를 보여준다. 그러면 다시 돌아가서 Text(text = "$count", fontSize = 30.sp)는 개발자가 직접 UI 업데이트를 위한 함수를 호출한 것인가 아닌가? 아니다. 특정 상태에 대한 UI 형태를 표현한 것이지 리컴포지션은 개발자가 직접 하는 것이 아니라 상태 변경에 따라 프레임워크에서 해주는 것이다. 그렇기 때문에 개발자는 UI를 어떻게 변경할지(명령형) 지시하지 않고, UI가 어떤 모습이어야 하는지(선언형)만 작성하면 된다.성능 개선리컴포지션에서 잠시 이야기했지만 기존 방식의 View 렌더링 과정은 비용이 높다. 특히 이것이 문제가 되는 상황은 바로 과도하게 중첩된 레이아웃이 존재할 때다. 일명 장풍 쏘는 XML 구조다. 이때 기존 View 방식은 View 계층이 깊어질수록 레이아웃 측정(measure), 배치(layout), 그리기(draw) 비용이 증가한다. 하지만 Compose는 경량화된 UI 트리를 생성한다. 이 트리 구조로 이뤄진 것을 컴포지션(Composition)이라고 한다. 컴포지션은 앱 UI를 구성하는 구조를 의미하며, UI를 정의하는 함수를 실행해서 생성된다. UI를 정의하는 함수는 컴포저블(Composable) 함수라고 한다. 리컴포지션은 이 트리 구조를 갱신하는 것이다.Preview실제 앱을 에뮬레이터 또는 기기에 실행하지 않고도 Android Studio 내에서 UI가 어떻게 보일지 미리 볼 수 있게 해주는 기능이다. 이 기능을 사용하면 UI에 관한 즉각적인 피드백을 받을 수 있어 개발 속도가 빨라지고 생산성이 향상된다. 사용 방법은 다음과 같이 @Preview 애노테이션을 사용하면 된다.상호 운용성기존 XML 방식 View와 Compose를 혼합하여 사용할 수 있다. 기존 View에 Compose를 포함할 수 있고, Compose에서 기존 View를 호스팅 할 수도 있다. 기존 View에 Compose UI를 포함시키기 위해서는 ComposeView를 사용하고, 컴포저블 함수 내에서 기존 View를 포함시키기 위해서는 AndroidView 컴포저블을 사용한다. 이를 통해 점진적인 마이그레이션이 가능하다.이 외에도 대표적으로 쉬운 난이도, 생산성 증가, 유연성, 재사용성 등이 Compose의 장점으로 여겨진다. 난이도와 생산성은 상대적인 것이라 다소 애매한 영역이다. 하지만 Preview 기능만으로도 생산성이 증가될 것은 분명하다. View를 위해 XML을 별도로 만들지 않아도 되고 그로 인해 좀 더 직관적인 상태 관리가 가능한 점도 난이도와 생산성에 영향을 줄 것으로 생각한다. 반면 유연성과 재사용성은 명확하다. 컴포저블이 특정 클래스를 상속받는 복잡한 객체가 아닌 단순한 Kotlin 함수이기 때문이다. 이 부분은 추후 컴포저블과 연결 지어 살펴보는 것이 효과적이라고 생각하여 지금은 다루지 않는다. </div></div>

서준수

Compose 등장 배경 XML을 사용하는 기존 안드로이드 View로도 여전히 좋은 앱을 개발할 수 있다. 하지만 처음 안드로이드가 등장한 후 많은 시간이 흐르며 개발 패러다임 또한 변했다. 초기 안드로이드 개발에서는 아키텍처라고 할만한 것이 없었다. 현재는 데이터와 UI의 역할을 명확히 분리하는 MVVM이나 클린 아키텍처와 같은 개념이 표준처럼 여겨지고

Compose 개요

댓글