XML 에서 Copose로 전환하면 좋은 이유

1. UI와 로직의 통합

기존의 XML 방식은 UI와 로직을 분리되었을때의 문제점은 다음과 같습니다.

1-1. 데이터 바인딩의 실행 순서 문제

XML에서 DataBinding을 활용하여 UI와 데이터를 연결하는 경우, XML이 먼저 실행되고 로직이 나중에 실행됩니다. 이로 인해 다음과 같은 문제가 발생합니다.

• 초기 상태 비정상: UI 컴포넌트가 초기 상태를 올바르게 반영하지 못하거나, 데이터가 준비되기 전에 XML이 렌더링되어 잘못된 값을 표시할 수 있습니다.
• 복잡한 상태 관리: XML의 뷰 상태와 로직의 데이터 상태를 일치시키기 위해 추가적인 코드가 필요합니다.

1-2. 레이아웃 측정의 제약

XML에서 커스텀 뷰를 만들거나 동적으로 뷰의 크기를 변경해야 하는 경우, onMeasure와 같은 메서드에서 크기를 측정하거나, 잘못된 초기 크기로 인해 레이아웃을 다시 그려야 할 필요가 있습니다. 이로 인해 다음과 같은 문제가 발생합니다.

• 불필요한 리소스 소모: 여러 번의 invalidate 호출로 인해 성능이 저하됩니다.
• 복잡한 코드 작성: 크기를 조정하기 위한 추가 코드와 조건 처리가 필요합니다.
• 정확한 크기 설정 어려움: 커스텀 뷰의 크기가 초기 단계에서 정해지지 않아 제대로 렌더링되지 않는 경우가 발생합니다. 이는 추가적인 크기 재측정 로직을 필요로 하며, 전체 뷰 계층 구조에 영향을 미칠 수 있습니다.

1-3. 동적 UI 구성의 제한

XML은 정적인 UI 설계를 염두에 두고 만들어졌기 때문에, 동적으로 UI를 생성하거나 구성하려면 ViewGroup과 LayoutInflater를 조작해야 합니다. 이로 인해 다음과 같은 문제가 발생합니다.

• 코드 복잡도 증가: 동적 UI 생성을 위한 추가적인 코드 작성이 필요합니다.
• 런타임 성능 저하: 런타임에 동적으로 레이아웃을 처리하는 과정에서 성능 문제가 발생할 수 있습니다.

2. 호환성과 일관성 문제 해결

XML 기반 UI에서 특히 그림자 효과나 그라데이션을 구현할 때, 안드로이드 OS 버전에 따라 다르게 동작하거나 추가적인 처리가 필요할 때가 많습니다. 특히 READING & 과 같이 Android 6.0(Marshmallow)부터 Android 14까지와 같이 넓은 범위를 지원해야 하는 경우, 다음과 같은 문제가 발생합니다.

2-1. 그림자 효과의 제약

XML에서 elevation 속성을 사용해 그림자를 설정하는 경우, Android 5.0(Lollipop) 이상에서만 제대로 동작합니다. 하위 버전에서는 그림자가 렌더링되지 않거나, 대체 방법(예: 9-Patch 이미지)을 사용해야 합니다.

• 문제점:
  • 하위 버전에서 elevation이 지원되지 않아 그림자가 나타나지 않음.
  • 대체 방법으로 9-Patch 이미지를 생성하거나, 커스텀 뷰를 만들어야 하는 번거로움.

2-2. 그라데이션의 복잡성

XML에서는 GradientDrawable을 사용해 그라데이션을 정의해야 합니다. 하지만 OS 버전에 따라 색상이나 방향이 제대로 렌더링되지 않을 수 있으며, 런타임 동적 변경은 추가적인 코드가 필요합니다.

• 문제점:
  • 런타임에서 동적 변경이 어려움.
  • 일부 하위 버전에서 그라데이션 렌더링이 깨지거나 비정상적으로 보임.
  • GradientDrawable은 유지보수가 어렵고, XML 코드가 복잡해짐. (OS 6에서는 그라데이션 효과가 나오지 않고 통일된 색상으로 보임)

3. 생산성 향상

• 코드 줄 수 감소
  Jetpack Compose는 선언형 UI 방식으로, XML 및 Activity/Fragment 기반 UI 설계보다 코드의 양을 크게 줄일 수 있습니다. JetBrains의 연구에 따르면 Compose를 사용하면 동일한 UI를 구성하는 데 필요한 코드 줄 수가 약 30-40% 감소한다고 합니다.
• 빌드 시간 단축
  Compose의 Hot Reload/Hot Restart와 Live Preview 기능 덕분에 UI 변경 사항을 실시간으로 확인하고 수정할 수 있습니다. 반면 XML 기반 UI는 레이아웃 변경 시 앱을 다시 빌드해야 할 때가 많습니다.
  Google 내부 테스트에 따르면, Compose를 사용하면 UI 변경 및 테스트 시간에서 평균 20-30% 절약이 가능합니다.
• Jetpack Compose 도입 사례
  • Twitter: Compose 도입 후 UI 개발 시간이 약 50% 단축되었습니다.
  • Airbnb: Compose를 사용하여 UI 변경 사항을 더 빠르게 적용할 수 있었습니다.
  • Google 내부 사례: 동일한 UI를 구현할 때 개발 시간 비교 결과는 아래와 같습니다:
    • XML 기반: 평균 3-5시간
    • Compose 기반: 평균 1-2시간