함수형 프로그래밍에서 Side Effect란 함수가 입력 → 출력만 하는 순수 계산 외에 외부 상태를 변경하거나 외부 세계와 상호작용하는 것을 말합니다. Compose에서 Side Effect는 어떤 의미일까요?

Compose Side Effect

Compose는 선언형 UI이기 때문에 컴포저블 함수는 UI를 그리는 선언만 하고, 외부 상태 변경이나 일회성 동작은 직접 하지 않는 것이 원칙입니다. 그런데 현실적으로는 스낵바 표시, 화면 이동, 로깅, 데이터 로드 요과 같은 일이 필요합니다. 이런 작업들은 컴포저블 함수 외부에서 일어나는 동작이므로 Compose에서는 'Side Effect'라고 부릅니다. 즉, 컴포즈에서 Side Effect란 UI를 선언하는 것 외에 앱의 상태를 변경하거나 외부와 통신하는 모든 부가적인 작업을 의미합니다. 이러한 작업은 리컴포지션 시점과 생명 주기에 맞춰 Side Effect API(LaunchedEffect, SideEffect, DisposableEffect 등)를 통해 안전하게 수행해야 합니다.

Side Effect API는 왜 필요할까?

컴포저블 함수는 리컴포지션이 자주 일어납니다. 따라서 컴포저블 함수 내부에서 전역 변수를 바꾸거나 API를 호출하는 등을 하면 예기치 않은 중복 실행이나 메모리 누수가 생길 수 있습니다. Side Effect API는 이러한 부수 효과를 안전하고 예측 가능한 방식으로 실행할 수 있도록 도와주는 장치입니다.

다음과 같이 코드를 작성하면 어떻게 될까요?

UserProfileScreen()은 상태 변경, 화면 회전 등 다양한 이유로 리컴포지션됩니다. 그때마다 사용자 정보를 가져오는 API인 fetchUser()가 계속해서 호출됩니다. 그러면 서버에 불필요한 요청으로 부하를 주고 앱 성능 또한 저하됩니다. Side Effect API는 이러한 작업을 컴포저블의 생명 주기(Lifecycle)에 맞추어 안전하게 실행할 수 있는 통제된 환경을 제공합니다.

주요 Side Effect API

1) LaunchedEffect

LaunchedEffect는 해당 컴포저블이 컴포지션에 진입할 때(UI 트리에 처음 포함될 때), 그리고 지정한 key 값이 변경될 때마다 코루틴을 실행합니다. key 값이 변경되지 않으면 해당 컴포저블이 다른 이유로 아무리 많이 리컴포지션 되어도 LaunchedEffect는 재실행되지 않습니다. key가 변경되면 기존 코루틴은 즉시 취소되고 새로운 코루틴이 시작됩니다. key를 Unit이나 변하지 않는 값으로 주면 컴포지션 진입 시 한 번만 실행됩니다. LaunchedEffect는 컴포지션 생명주기에 맞춰 동작하므로 해당 컴포저블이 컴포지션에서 제거(UI 트리에 빠질 때)되면 코루틴도 자동으로 취소됩니다.

LaunchedEffect의 파라미터 중에 key1이라는 파라미터가 있습니다. 최초에 LaunchedEffect 블록이 실행된 후에 key1이 변경되면 다시 LaunchedEffect 블록이 실행됩니다. 위 예제처럼 Unit을 넘기면 변경되는 일이 없어서 최초 한 번만 실행하게 됩니다. 따라서 print문은 'LaunchedEffect 0'을 한 번 출력하고 그 후에는 Text 컴포저블에 1초마다 증가한 값이 표시됩니다. seconds 상태가 1초마다 변하기 때문에 리컴포지션도 1초마다 발생합니다.

seconds 변경 → 리컴포지션 → 새로운 값 표시

컴포저블이 화면에서 사라지면(엄밀하게는 UI 트리에 빠지면) 코루틴 자동 취소

만약 key1에 상태가 변하는 값을 넘기면 어떻게 될까요? 현재 지속적으로 상태가 변하는 것은 senconds입니다. 이것을 key1에 할당해 보겠습니다.

LaunchedEffect 0

LaunchedEffect 1

LaunchedEffect 2

...

key1 값이 1초마다 변경되기 때문에 LaunchedEffect 내부에서는 1초마다 기존 코루틴이 먼저 취소된 뒤 새 코루틴이 시작됩니다. 이 경우 key 변경 → 기존 코루틴 취소 → 새 코루틴 시작 사이에 아주 짧은 공백이 생깁니다. 이 공백 동안 delay(1000) 주기가 끊기기 때문에 재시작 시마다 수 밀리초~수십 밀리초 정도의 오차가 누적될 수 있습니다. 이게 반복되면 장기적으로는 타이머가 실제 시간보다 조금씩 늦어질 수 있습니다. 따라서 이런 경우에는 LaunchedEffect(Unit)처럼 한 번만 실행되도록 해야 합니다.

2) rememberCoroutineScope

LaunchedEffect는 컴포지션 시점에 자동으로 실행됩니다. 하지만 버튼 클릭 등 사용자 상호작용 시점에 코루틴을 실행해야 하는 경우가 있습니다. 이때 rememberCoroutineScope를 사용합니다. 이 API는 해당 컴포저블의 컴포지션 생명 주기에 연결된 CoroutineScope를 반환하며, 컴포저블이 UI 트리에서 제거되면 이 범위(scope)에서 실행된 모든 코루틴이 자동으로 취소되어 메모리 누수를 방지합니다. 다음과 같은 예제로 간단하게 사용해 볼 수 있습니다.

(버튼 클릭)

[rememberCoroutineScope] Run

(5초 후)

[rememberCoroutineScope] Finish

3) rememberUpdatedState

rememberUpdatedState는 컴포저블이 리컴포지션되더라도 Side Effect 블록 안에서 항상 최신 값을 참조할 수 있도록 해줍니다. LaunchedEffect나 DisposableEffect는 key가 바뀌지 않으면 재시작하지 않습니다. 하지만 그 안에서 참조하는 값이 바뀌면 오래된 값을 계속 쓰게 되는 문제가 발생합니다. rememberUpdatedState를 사용하면 Side Effect는 재시작하지 않으면서도 내부에서 항상 최신 값을 읽을 수 있습니다.

다음 예제 코드를 볼까요? 조금 길어서 복잡해 보일 수 있지만 버튼 2개로 이뤄진 간단한 코드입니다. 결제 수단이 표시된 결제 버튼이 있고 해당 버튼을 누르면 3초 후 결제가 됩니다. 그 사이에 결제 수단 변경 버튼으로 결제 수단을 변경할 수 있습니다. 실제 서비스에서 이런 시나리오는 어색한 것이겠지만 학습용으로 생각해 주세요. 먼저 rememberUpdatedState를 사용하지 않은 상황입니다.

(결제 버튼 클릭)

결제 수단: 카드

3초 뒤 결제를 완료합니다.

(결제 수단 변경 버튼 클릭)

결제 수단: 현금

결제 완료: 카드

결제 수단이 변경되었지만 rememberCoroutineScope로 생성된 코루틴은 오래된 값을 가지고 있어서 최신 값을 반영할 수 없는 문제가 있습니다. 따라서 결제 완료 정보에 이전 정보인 카드가 출력됩니다. 이것을 개선하기 위해서 rememberUpdatedState을 사용하면 됩니다.

(결제 버튼 클릭)

결제 수단: 카드

3초 뒤 결제를 완료합니다.

(결제 수단 변경 버튼 클릭)

결제 수단: 현금

결제 완료: 현금

rememberUpdatedState을 통해서 Side Effect 내부, 즉 rememberCoroutineScope의 내부에서 최신 값을 참조할 수 있게 되었습니다. 결과적으로 변경된 결제 수단으로 결제 완료가 된 것을 확인할 수 있습니다.

4) DisposableEffect

DisposableEffect는 등록과 해제와 같이 한 쌍으로 관리가 필요한 작업을 컴포지션 생명 주기에 맞춰 동작할 때 유용한 API입니다. 컴포저블이 컴포지션 되면 내부 블록이 실행되어 등록 작업을 하면 됩니다. 컴포지션에서 제거되거나 key가 바뀌면 onDispose { ... }가 호출됩니다. 이때 해제 작업을 해주면 됩니다.

DisposableEffect도 key 값이 바뀌지 않으면 다른 이유로 리컴포지션이 발생해도 재실행되지 않습니다. LaunchedEffect와 동작 원리가 동일합니다.

DisposableEffect가 필요한 이유는 화면 이동 등으로 컴포저블이 리컴포지션 되거나 제거(Dispose) 될 수 있기 때문입니다. 만약 리스너 등록, BroadcastReceiver, Sensor, Callback 등을 그냥 두면 메모리 누수, 중복 등록, 잘못된 콜백 발생 위험이 있습니다. 이것은 비단 컴포저블의 문제가 아니라 프로그래밍을 하면서 지켜야 할 사항이기도 합니다. DisposableEffect는 이 문제를 편리하게 해결하는데 유용합니다.

다음 예제는 DisposableEffect를 사용하여 BroadcastReceiver의 등록과 해제를 구현한 것입니다.

배터리 상태 정보는 Sticky BroadcastReceiver로 리시버 등록 시 한 번 수신하게 됩니다.

[Battery] registerReceiver!

[Battery] status changed!

[Battery] level: 96, scale: 100, battery: 96.0%

[Battery] status changed!

[Battery] level: 97, scale: 100, battery: 97.0%

(앱 종료)

[Battery] onDispose!

5) SideEffect

SideEffect는 컴포저블이 컴포지션 또는 리컴포지션에 성공하여 UI 트리에 반영된 후 실행됩니다. 이러한 특징 때문에 주요 용도는 Compose의 내부 상태를 외부에 알리는 것입니다. 예를 들면 현재 화면의 상태(로딩, 성공, 에러)를 로깅할 때 사용할 수 있습니다. 보통 Firebase Analytics나 자체 로깅 시스템을 사용할 겁니다. 여기서는 간단하게 컴포지션 완료된 후 상황을 print문으로 확인해 봅니다.

위 예제는 별도의 화면 상태를 가지지 않지만 컴포저블이 정상적으로 컴포지션 되면 SideEffect가 실행되어 print문이 출력됩니다. 내부 상태는 외부에 알린다는 거창한 역할에 매몰되지 않아도 됩니다. SideEffect의 코드 블록은 LaunchedEffect처럼 특별한 능력을 가진 환경이 아닙니다. 그냥 일반 코드 블록입니다. SideEffect의 진정한 가치는 코드 블록의 특징이 아니라 '실행되는 시점'에 있습니다. 컴포저블이 컴포지션 된 후에 실행되기 때문에 내부 상태를 외부에 알리기 좋은 시점이기 때문에 그러한 역할로 적합한 것입니다.

6) derivedStateOf

derivedStateOf는 하나 이상의 상태 객체로부터 파생된 상태(derived state)를 만들 때 유용합니다. 파생 상태는 다른 상태로부터 새로운 상태를 만듭니다. 의존하는 원본 상태가 변경되면 파생 상태를 다시 계산합니다. 계산 결과가 이전 값과 동일하면 해당 파생 상태를 읽는 컴포저블은 리컴포지션되지 않습니다. 이를 통해 불필요한 리컴포지션을 방지하고 성능을 최적화할 수 있습니다. 또한 리컴포지션마다 새로운 derivedStateOf 객체가 생성되는 것을 방지하려면 remember 안에서 사용해야 합니다.

Counter is recomposed.

CountText is recomposed.

(Button 클릭)

Counter is recomposed.

CountText is recomposed.

위 예제는 Button을 클릭하여 count 값을 증가시킬 때마다 Counter, CountText 컴포저블 함수 모두 리컴포지션 됩니다. 현재 count의 상태 변화를 UI에 반영하는 것은 CountText 컴포저블 함수입니다. 따라서 굳이 Counter 컴포저블 함수는 리컴포지션 하지 않아도 됩니다. 그러면 두 컴포저블 함수가 동시에 리컴포지션 되도록 하는 상태인 count의 파생 상태를 만들어서 CountText 컴포저블 함수만 리컴포지션할 수 있습니다.

Counter is recomposed.

CountText is recomposed.

(Button 클릭)

CountText is recomposed.

파생 상태는 원본 상태가 변경되면 다시 계산되어 자신의 상태를 갱신합니다. 따라서 count의 값이 1 증가하는 상태 변경이 발생하면 newCount는 내부의 count 값이 1 증가되는 것을 계산하고 자신의 상태가 변경된 것으로 갱신합니다.

derivedStateOf { count }는 State<Int> 타입을 반환합니다. count는 이미 MutableIntState 형태의 상태 객체입니다. derivedStateOf { count }는 이 count를 읽어서 다른 State 객체를 만듭니다. 즉, 원본 상태(count)를 기반으로 파생된 상태(newCount)를 만든 것이죠.

derivedStateOf 결과도 State이므로 원본 상태를 또 다른 상태 객체로 감싼 셈입니다. 단순히 래핑만 하는 게 아니라 계산 로직을 거쳐서 값이 결정됩니다. 지금은 { count }라서 계산이 없지만, 실제로는 { count * price }처럼 연산이 들어갈 수 있습니다. 그래서 derivedStateOf는 '원본 상태를 그대로 감싸는 래퍼'라기보다, 원본 상태를 기반으로 계산된 결과를 상태로 제공하는 도구라고 보는 게 더 정확합니다.

사실 위 예제는 derivedStateOf에 대한 예제로 적절하지 않습니다. 휴먼 할루시네이션입니다. Counter 컴포저블 함수가 리컴포지션 되지 않은 것은 count 상태 값을 다루고 있지 않고, 상태(State<Int>) 그 자체로 다루고 있기 때문입니다. 따라서 count를 MutableIntState 타입으로 즉, 상태로 그 자체로 다루면 리컴포지션이 일어나지 않습니다.

Counter is recomposed.

CountText is recomposed.

(Button 클릭)

CountText is recomposed.

반대로 derivedStateOf를 사용해도 State<Int>가 아닌 value를 꺼내서 사용하면 Counter와 CountText 모두 리컴포지션이 됩니다.

Counter is recomposed.

CountText is recomposed.

(Button 클릭)

Counter is recomposed.

CountText is recomposed.

또는 동일한 의미를 가지는 아래와 같은 형태로 작성할 수도 있습니다.

val newCount by remember { derivedStateOf { count } }
...
CountText(newCount)
...

Compose에서 리컴포지션이 일어나는 조건은 상태(State)의 값(value)이 변경되는 것입니다.

컴포저블이 어떤 State.value를 읽는다. → Compose 런타임이 '이 컴포저블은 이 상태를 의존한다' 하고 구독 관계를 맺습니다.

그 value가 바뀐다. → 런타임이 해당 컴포저블(구독자)을 찾아 리컴포지션을 요청합니다.

흔히 상태가 변경되면 리컴포지션이 된다고 표현하는데 그 이면에는 '상태의 값'이라는 의미가 담겨 있다고 봐야 합니다.

derivedStateOf 예제는 더 좋은 아이디어가 떠오르면 보강하겠습니다. 최대한 쉬우면서 짧은, 그렇지만 코드 스니펫은 아니어야 하는 예제가 잘 떠오르지 않네요.

마무리

이외에 produceState, snapshotFlow와 같은 API도 있습니다. Compose의 Side Effect API는 컴포지션 생명 주기에 맞춰 동작하지만 실제 앱에서는 그 컴포지션이 언제 시작되고 끝나는지가 액티비티/프래그먼트의 생명주기, 내비게이션 구조, 태스크 재사용 방식에 크게 영향을 받습니다. 그래서 설계할 때는 두 부분을 같이 봐야 합니다.

Compose Side Effect - 하루 10분 Compose (11)

댓글