Compose는 상태에 따라 UI를 자동으로 갱신하도록 구현하는 것이 중요합니다. 이때 UI 갱신이 제대로 이뤄지지 않으면 원하는 화면을 그릴 수 없습니다. 이것은 곧 앱에 치명적인 문제로 이어집니다.

리컴포지션(Recomposition)이란 무엇인가?

리컴포지션은 상태가 변경되었을 때 해당 상태를 참조하는 컴포저블 함수나 람다 블록을 다시 실행하여 UI를 갱신하는 과정입니다. Compose는 선언형 UI입니다. UI는 상태에 따라 결정되며 상태가 변경되면 UI를 다시 그려야 합니다. 이때 Compose는 전체 UI를 다시 그리는 것이 아니라 변경된 상태를 참조하는 컴포저블만 다시 그립니다.

다음 예제는 상태 관리에서 리컴포지션이 되었을 때 상태를 기억하지 못 해서 제대로 화면 갱신이 되지 않은 코드입니다. Button을 클릭하면 count 값이 증가하여 상태가 0에서 1로 변경됩니다. 상태가 변경되었으니 리컴포지션이 발생하여 Counter() 컴포저블 함수가 재호출 됩니다. 처음부터 다시 실행되다 보니 count 변수가 0으로 초기화되어 실제 UI에 반영되는 값은 0이 됩니다.

이번에는 위 코드에서 6라인의 Text() 컴포저블 함수를 없애고 Button()의 자식 컴포저블인 9라인의 Text()에서 상태를 보여주도록 바꿔보겠습니다.

이렇게 버튼 내부에서 상태를 표시하도록 변경이 되었습니다. 이때 리컴포지션 관점에서 가장 큰 변화는 무엇일까요? 상태를 참조하는 범위의 변화입니다. 변경 전에는 count라는 상태를 Counter() 컴포저블 함수 최상위에서 참조하고 있습니다. 하지만 변경 후에는 Button() 컴포저블 함수 내부에 전달된 content 람다 블록에서 참조하고 있습니다. 이 경우 리컴포지션 범위도 달라집니다. 전자는 Counter() 컴포저블 함수 자체가 리컴포지션됩니다. 후자의 경우 Button() 컴포저블 함수의 람다 블록만 리컴포지션됩니다. 따라서 변경된 코드는 remember를 사용하지 않았지만 화면이 잘 갱신됩니다. Counter() 컴포저블 함수가 리컴포지션되지 않으므로 count 변수가 다시 초기화될 일이 없기 때문입니다.

이러한 방식으로 상태 변경 시 해당 상태를 참조하는 컴포저블만 리컴포지션하는 방법을 스마트 리컴포지션(Smart Recompositon)이라고 합니다.

스마트 리컴포지션의 장점은 무엇일까요? 바로 성능 향상에 도움이 됩니다. 개발자가 상태를 최소한의 범위에서만 참조하도록 설계하면 나머지는 Compose가 알아서 최적화합니다.

다음과 같이 정리할 수 있습니다.

변경 전: 불필요하게 넓은 범위(Counter 전체)가 리컴포지션되어 성능 저하의 원인이 될 수 있습니다.

변경 후: 상태 변경의 영향을 받는 범위를 최소한(Button의 람다 블록)으로 격리하여 리컴포지션을 꼭 필요한 곳에서만 일어나게 합니다. 이것이 바로 Compose가 추구하는 선언형 UI의 성능 최적화 원리입니다.

그러면 remember 없이 이렇게만 사용해도 충분할까요? 아닙니다. 이 예제에선 클릭 시 Button의 content 람다만 리컴포지션되어 Counter 본문이 스킵되고, 그 결과 count 초기화가 겉보기엔 일어나지 않습니다. 그래서 지금은 문제없이 동작하는 것처럼 보이죠. 하지만 이러한 최적화에 기대는 건 불안정합니다. 일단 가독성에 문제가 있습니다. 스마트 리컴포지션은 코드에 명확히 드러나지 않습니다. 따라서 팀원이나 미래의 자신이 의도를 파악하기 어렵습니다. 또한 사소한 변경(파라미터 변경, 구성 변경 등)만 있어도 Counter 본문이 재실행되어 count가 0으로 초기화됩니다. 특히 변경 전과 같이 Button 외부에 Text가 존재해야 하는 디자인 가이드를 지키려면 반드시 remember를 사용해야 합니다.

그렇다고 해서 항상 remember를 사용해야 하는가? 그건 또 아닙니다. 상태를 외부에서 관리하거나 전달받는 경우엔 불필요합니다. 이것은 다른 주제에서 좀 더 이야기하도록 하겠습니다.

Compose에서 리컴포지션이 어떻게 동작하는지 알고 싶다면 내부 구조를 살펴보면 도움이 됩니다.

Compose 내부 구조: SlotTable, Group, RecomposeScope

SlotTable

SlotTable은 컴포저블 함수의 호출 구조와 그 안에서 사용된 데이터(remember 상태, 파라미터 값 등)를 저장하는 데이터 구조입니다. 컴포지션이 실행될 때 생성된 UI 노드, 각 노드의 파라미터, remember로 기억된 값 등 모든 것을 순서대로 기록합니다. 마치 컴포저블 트리의 전체 설계도나 목차와 같습니다. 간단히 말해, SlotTable은 '어떤 컴포저블이 어떤 순서로 호출되었고 각각 어떤 데이터를 가지고 있는가?'를 모두 기록하는 장부입니다.

Group

Group은 SlotTable에 기록되는 정보의 단위입니다. Compose 컴파일러가 컴포저블 함수를 분석하여 생성하며 관련된 데이터들을 하나의 묶음으로 만듭니다. 특정 컴포저블 호출에 대한 정보를 그룹화하여 SlotTable에 저장합니다. 예를 들어 Text("Count")를 호출하면 Text에 해당하는 그룹이 생성되고 이 그룹 안에는 Count라는 파라미터 정보가 담깁니다. 이 Group들이 모여 SlotTable 내에서 논리적인 트리 구조를 형성하며, 이는 실제 UI의 계층 구조와 일치합니다. 즉, Group은 SlotTable이라는 목차를 구성하는 각각의 항목(챕터, 문단 등)과 같습니다.

RecomposeScope

RecomposeScope는 특정 상태가 변경되었을 때, '정확히 어디서부터 어디까지를 다시 실행해야 하는지'에 대한 범위(Scope)를 정의하는 객체입니다. 이것이 바로 Compose의 스마트 리컴포지션의 핵심입니다. 컴포저블이 상태 값을 읽을 때 Compose 런타임은 해당 상태와 그 값을 읽은 코드 블록(범위)을 RecomposeScope에 등록합니다. 나중에 상태 값이 변경되면 해당 상태에 연결된 RecomposeScope를 찾아 등록된 범위에 해당하는 코드만 다시 실행(리컴포지션)합니다. RecomposeScope 덕분에 상태 변경과 관련 없는 부분은 건너뛰고(skipping), 오직 변경이 필요한 최소한의 범위만 리컴포지션할 수 있습니다.

도넛 홀 스키핑 (Donut Hole Skipping)

도넛 홀 스키핑은 부모 컴포저블이 리컴포지션될 때, 변경 사항이 없는 자식 컴포저블의 실행은 건너뛰어 마치 도넛의 구멍처럼 중간 부분의 리컴포지션을 피하는 최적화 원리입니다.

위 예제의 동작을 하나씩 살펴보겠습니다.

1) 상태 변경 감지: Button을 클릭하면 Middle 안에 있는 count 상태가 변경됩니다.

2) 리컴포지션 대상 식별: Compose 런타임은 이 count 상태를 직접 읽고 있는 가장 가까운 범위를 찾습니다. 바로 Middle 컴포저블입니다.

3) 최적화된 실행: Parent는 상태 변경과 아무런 관련이 없습니다. 따라서 불필요하게 Parent를 다시 실행하지 않고 변경이 필요한 Middle만 다시 호출(리컴포지션)합니다.

따라서 발생한 로그는 아래와 같습니다.

최초 실행 시

Parent Composable is called

Middle Composable is called

Button Composable is called

Child Composable is called

버튼 클릭 시

Middle Composable is called

이처럼 변경 범위를 찾아내어 관련 없는 상위 컴포저블의 리컴포지션을 건너뛰는 것이 스마트 리컴포지션의 핵심입니다. 그런데 이때 Middle이 리컴포지션 되었는데 Child는 실행되지 않았습니다. 왜 그럴까요? 리컴포지션되는 Middle 내부에서 상태 변화와 아무 관련 없는 Child의 리컴포지션을 건너뛰기 때문입니다. 이것이 바로 도넛 홀 스키핑입니다.

즉, 앞선 예제에서는 두 단계의 최적화가 발생합니다.

1단계 (스마트 리컴포지션): 상태와 무관한 Parent를 건너뛰고 Middle만 실행합니다.

2단계 (도넛 홀 스키핑): 실행된 Middle 내부에서 상태와 무관한 Child를 건너뜁니다.

리컴포지션 처리 담당자: Compose Runtime, Composer

지금까지 살펴본 리컴포지션은 상태 변경에 반응하여 UI를 최소한의 비용으로 업데이트하는 과정입니다. 이 과정은 Compose 런타임이 조율하고 Composer가 실행하며 그 결과는 SlotTable에 기록됩니다.

(Compose 런타임) 상태 변경이 발생하면 Compose 런타임은 Snapshot 시스템을 통해 상태 변경을 감지하고 영향을 받는 RecomposeScope를 무효화(Invalid)합니다. 무효화된 범위는 다음 렌더링 프레임에 다시 실행하도록 예약됩니다.

(Composer) 이 시점에 Composer가 투입되어 SlotTable에 저장된 이전 값과 현재 값을 비교합니다. 그 후 변경된 컴포저블만 선택적으로 다시 실행하고 그 결과는 SlotTable에 반영됩니다. Composer가 SlotTable를 업데이트하면 리컴포지션 단계는 종료됩니다.

(Compose 런타임) 리컴포지션 결과는 Compose의 렌더링 트리인 LayoutNode에 적용됩니다. 이 과정에서 측정(Measure), 배치(Layout), 그리기(Draw) 단계가 필요에 따라 다시 실행되며 최종적으로 화면이 갱신됩니다.

전체 흐름 요약

Compose 런타임: 상태 변경 감지 → RecomposeScope 무효화 → 리컴포지션 예약

Composer: SlotTable 비교 → 변경된 컴포저블만 리컴포지션 → SlotTable 업데이트

Compose 런타임: LayoutNode 트리 반영 → Measure/Layout/Draw → UI 갱신

Compose 리컴포지션

댓글