fromm 채팅 리뉴얼: UI 특성을 고려한 Compose 컴포넌트 설계

들어가며

안녕하세요, 노머스 Android 팀의 양수진입니다. 지난 2월, 저희 팀의 상아님께서 채팅 리뉴얼: MVI 도입 및 성능 개선이라는 포스트를 통해 2024년 하반기부터 올해 초까지 진행한 채팅 시스템의 대규모 개선 작업을 소개해주셨습니다.

풀버전이 궁금하신 분들은 👉 [fromm 채팅 리뉴얼: MVI 도입 및 성능 개선] 바로 가기

저는 이번 채팅 리뉴얼 작업에서 UI 레이어 작업을 주로 맡아 진행했습니다. 새로 작성한 Compose UI 컴포넌트 코드만 해도 5000줄이 넘을 정도로 채팅 기능은 상당히 큰 범위의 작업이었습니다. 또한, 채팅 리뉴얼 프로젝트의 목적이 유지보수와 기능 확장을 용이하게 하기 위함이었기 때문에 UI 컴포넌트 또한 그 목적을 충족하고자 했습니다. 오늘은 앞선 글에서 미처 다루지 못했던 Jetpack Compose 마이그레이션 과정에서의 고민들을 공유해보려 합니다.

1. Slot API 적극 활용하기 — 부품 조립식 UI 구성

fromm에서 아티스트 분들은 다양한 타입의 메시지를 보낼 수 있습니다.

🤫 아티스트 분들의 프라이빗 메시지를 보호하기 위해 본 포스트에 첨부된 메세지들은 개발 환경 아티스트의 캡쳐본으로 대체합니다. 개발 환경 아티스트가 누구냐고요? 바로 접니다 ㅎ

이미 눈치 채신 분들도 계시겠지요? 다른 타입의 메시지더라도 동일한 구조를 가지는 부분이 있습니다. 저는 메시지 UI들을 아래와 같이 구조화 했습니다.

그래서 Jetpack Compose의 Slot API 개념을 적극 활용해 공통 UI 구조를 만들고, 각 타입별로 차이 나는 부분만 끼워 넣는 방식으로 조립했습니다. 실제로 채팅 리뉴얼 이후 특정 부분의 UI 변경이 생겼을 때, 최소한의 수정으로도 다양한 타입에 일괄 적용되어 작업 시간이 단축되었습니다. 그리고 새로운 메시지 타입이 생겼을 때에도, 그저 빈칸에 들어갈 컴포넌트만 새로 짜서 조립하기만 하면 끝이었습니다.

물론 단점도 있었습니다. 컴포넌트를 잘게 나누다 보니 컴포넌트의 depth가 깊어졌고, 디버깅이나 Preview 작업이 조금 번거로워지기도 했습니다. 실제로 ‘채팅방 글씨 크기’ 옵션을 중간 컴포넌트에는 내리고, 실제 사용하는 하위 컴포넌트에 내리지 않은 것을 알아채지 못한 실수도 한 번 했습니다.

하지만 구조적인 이점이 훨씬 크게 느껴졌기 때문에 구조를 바꾸기 보다는 단점을 상쇄할 수 있는 방법을 고민했습니다.

2. CompositionLocal — 특정 범위에 암시적으로 데이터 전달

fromm 앱에서는 채팅방에 ‘테마’를 적용할 수 있습니다. 테마를 적용하면 채팅방 배경, 메시지 배경, 메시지 텍스트 등 다양한 영역의 색상이 변경됩니다. 처음에는 테마 속성들을 상위 컴포저블에서 하위로 줄줄이 파라미터로 넘기고 있었습니다. 컴포넌트가 겹겹이 싸인 형태이다보니, 직접 사용하는 값이 아님에도 하위로 넘기기 위해 받는 컴포넌트도 다수 존재했습니다. 그리고 테마로 인해 파라미터의 개수가 많아졌기 때문에 컴포넌트의 가독성도 떨어졌습니다. 아래 도식도와 같은 현상이 받은 메시지/보낸 메시지 * 텍스트/사진/동영상/음성메시지/+@ = 약 10가지가 넘는 컴포넌트에서 반복되는 것입니다.

여기서 선택한 해법이 바로 CompositionLocal이었습니다.

CompositionLocal은 암시적으로 컴포지션을 통해 데이터를 전달하는 도구입니다. 암시적으로 객체를 전달하기 때문에 남용하게 된다면 CompositionLocal은 컴포저블의 동작을 추론하기 어렵게 만들 수 있습니다. 실제로 공식 문서에서는 CompositionLocal 사용 여부를 결정하는 가이드 항목까지 존재합니다. 채팅방 테마 적용 시나리오가 정말로 적합한지 한번 점검해보겠습니다.

✅ 매개변수가 크로스 커팅이고 구현의 중간 레이어가 그 존재를 인식해서는 안 되는 경우 👉 지금 문제 상황과 똑같음

✅ 적절한 기본값이 있어야 함 👉 테마 색상 미지정시, 기본 색상을 적용하는 규칙이 있음

✅ 잠재적으로 일부 하위 요소가 아닌 모든 하위 요소에서 사용할 수 있을 때 적합 👉 채팅방 내 컴포넌트의 90%에 테마가 적용

따라서 저는 CompositionLocal이 해법으로 적합하다 판단했습니다.

val LocalChatThemeColors: ProvidableCompositionLocal<ChatThemeColors?> = compositionLocalOf { null }

//...

CompositionLocalProvider(
  LocalChatThemeColors provides state.chatTheme?.toChatThemeColors()
) {
    FanChatRoomContent()
}

채팅방 계층 구조가 시작되는 Screen 컴포넌트에서 CompositionLocal 인스턴스에 테마 색상 값을 가진 객체를 바인딩 했습니다. 이제 중간 컴포넌트에서 파라미터를 전달하지 않고, 실제로 테마 색상 값이 적용되는 곳에서 암시적으로 흐르는 채팅방 테마 객체를 취득하여 색상을 적용할 수 있습니다.

하지만 적용하고 난 후, 또 고민해야 할 지점을 발견했습니다.

처음에 무심코 사용하다보니 어디에선 하위 컴포넌트에서 값을 CompositionLocal.current로 바로 꺼내 쓰고 있고, 또 어디에서는 상위 컴포넌트에서 하위 컴포넌트로 파라미터로 넘겨서 사용하기도 했습니다. 일관성 없이 사용했더니 어디에서 값을 누락해도 알아채기도 힘들뿐더러, 누락시킨 부분을 찾는 것도 일이었습니다. 위에서 말한 depth가 깊은 컴포넌트의 디버깅이 힘들다는 단점이 더욱 강해져 버린 것입니다.

그래서 규칙을 정했습니다:

• 실제 사용하는 가장 하위 컴포넌트에서 CompositionLocal.current를 호출하되
• Preview와 UI Test를 위해 외부에서 파라미터로도 받을 수 있게 열어둘 것.

@Composable
internal fun ReceivedBubbleBox(
    //...
    color: Color = FrommTheme.colors.surfaceBasic03,
    content: @Composable () -> Unit
) {
    Box(
        modifier = modifier
            .background(color = LocalChatThemeColors.current?.receivedMessageBackground ?: color,),
        content = {
            content()
        }
    )
}

이렇게 규칙을 정하여 적용하니 실수가 방지되고, 디버깅도 용이해졌습니다. 특정 색상이 적용되지 않았다? 그러면 그 색상이 적용되어야 하는 컴포넌트에서 빼먹은게 분명해졌으니까요. 윗 단락에서 언급한 실수인 ‘채팅방 글씨 크기’ 옵션 또한 채팅방 테마와 똑같은 성격을 가졌기 때문에 같은 방식을 채택함으로서 개선했습니다.

3. LazyColumn 구워삶기 — 스크롤과의 전쟁

reverseLayout

결론부터 말하자면, LazyColumn의 reverseLayout 옵션을 주어 거꾸로 사용했습니다. ‘채팅’이라는 기능의 특징을 잘 생각해봅시다. 보통 채팅을 할때 가장 오래 머무는 부분은 어디일까요? 바로 최신 메시지가 있는 부분입니다. 그렇다면 최신 메시지는 어디에 있을까요? 바로 리스트의 제일 아랫쪽입니다!

처음에는 LazyColumn 기본 설정으로 개발을 했습니다. 리스트에 오름차순으로 메시지를 넣고, 리스트 마지막에 최신 메시지를 추가하는 형태이지요. 개발을 하면서 여러 문제에 부딪히고 채팅의 특성에 대해 고민해보았습니다. 그때 reverseLayout을 적용해보면 어떤가 하는 생각이 스쳐지나갔습니다. domain 레이어에서부터 메시지를 내림차순으로 가져올 수 있도록 대규모 수정을 해야만 했지만 이점이 더 크다고 생각하여 확 뒤집어 버렸습니다.

그래서 어떤 이점이 있었냐고요?

입장 시 스크롤이 자연스럽다

• 채팅방 진입 시, 최신 메시지 리스트를 가져옵니다. 이때 100개를 가져온다고 가정한다면?
• before
  • 진입과 동시에 가장 최신 메시지인 100번째 메시지으로 스크롤 이동
  • 순간적으로 초기 스크롤인 1번째 메시지에서 100번째 메시지로 덜커덩! 스크롤이 변하는 모습이 눈에 보임
• after
  • 가장 최신 메시지는 1번째 메시지
  • 스크롤 하지 않아도 이미 최신 메시지가 최하단에 위치

새 메시지 수신 시 스크롤 부담 감소

• before
  • 새 메시지 수신 시, 아래로 스크롤을 밀어야 함
  • 최신 메시지의 높이가 늘어나는 케이스가 있음. 이때 늘어난 만큼 하단에 메시지가 잘려 보이기 때문에 또 스크롤을 밀어야 함
• after
  • 1번째 메시지까지 내려가 있는 상태라면 그대로 스크롤을 유지하면 됨
  • 최신 메시지의 높이가 늘어나도 위쪽으로 밀리기 때문에 스크롤 신경 쓸 필요가 없어짐

사용자 액션 처리 간결화

• 채팅방은 메시지 전송, FAB 버튼으로 이동 등의 액션으로 최하단 이동이 자주 일어나는 환경입니다.
• before
  • 최신 메시지로 이동시, 리스트에 있는 총 메시지 개수를 알아야 이동 가능
  • lazyListState.scrollToItem(messages.lastIndex)
• after
  • 아.묻.따 0번째 인덱스로 스크롤을 내리면 그게 최신 메시지
  • lazyListState.scrollToItem(0)

스크롤 책임 분리

지금까지 최하단으로 스크롤하는 경우에 대해 언급을 했지만, 최하단 뿐만 아니라 특정 메시지로 이동하는 경우도 존재합니다.

대표적인 예시로 ‘검색 기능’이 있습니다. 검색 결과가 있으면 메시지를 화면에 표시하고, 하단의 버튼으로 이전 혹은 다음 검색결과로 이동할 수 있습니다. 기능 자체는 심플해 보이지만 로직을 풀어쓰면 상당히 복잡한 편입니다.

1. 검색 결과에 해당하는 메시지가 메모리에 있는가?

• 있으면 그 메시지로 스크롤 이동

2. 메모리에 없다면 db에 저장된 메시지 중 검색어가 포함된 메시지를 찾는다.
3. 2번에서 찾은 메시지 앞뒤로 메시지들을 가져온다.
4. 화면에 3번에서 가져온 메시지들을 뿌리고, 2번에서 찾은 메시지로 스크롤 이동한다.
5. 더이상 검색결과가 없을 때까지 이전/다음 버튼을 누를때마다 1~4번의 과정을 반복한다.

사실 UI 에서는 이 모든 과정을 알고 싶지 않습니다. ‘어떤 메시지들을 화면에 뿌릴지’, ‘어떤 메시지로 스크롤 이동할지’만이 관심사입니다. 여기서 잠깐! 채팅 리뉴얼 1편인 상아님의 포스트의 제목에서 알 수 있듯, 저희 팀은 MVI 패턴을 적용하여 UI 업데이트를 관리하고 있습니다. 아직도 읽지 않았다면?! 지금 당장 👉 [fromm 채팅 리뉴얼: MVI 도입 및 성능 개선] 바로 가기

이때 스크롤을 State와 Effect 중 무엇으로 관리해야 할까요?

• 초간단 설명
  • State: UI의 현재 모습을 나타내는 데이터
  • Effect: 상태 변경과 별도로 처리해야 하는 일회성 동작

✅ 저희는 Effect로 관리하기로 결정했습니다. ‘어디로 스크롤을 이동해라’라는 이벤트가 발생하면 LazyListState의 스크롤 이동 메서드를 호출하는 일회성 동작으로 간주하는 겁니다. 상아님 포스트의 도식도를 빌려 검색 기능을 표현한다면 아래와 같이 됩니다.

• 책임이 명확히 분리되었습니다. 어떤 메시지로 이동해야 하는지의 판단은 ViewModel에서 처리하고, 실제 UI에서의 스크롤 동작은 Composable에서 단순히 ‘지정 인덱스로 스크롤’만 수행합니다.
• 단방향 데이터 흐름으로 UI 변화를 예측하기 용이합니다.

데이터 초기화와 scroll 이벤트 타이밍이 어긋날 때

검색 결과를 보여줄 때, 메시지 데이터 초기화와 동시에 스크롤을 이동하기 때문에 종종 LazyColumn의 데이터가 업데이트 되기 전에 스크롤 동작이 시작되어 엉뚱한 메시지로 스크롤이 이동되는 현상을 겪었습니다. 이럴때는 잘 알려진 LazyListState의 scrollToItem()이나 animateScrollToItem() 메서드 대신 requestScrollToItem() 메서드를 활용해보세요!

requestScrollToItem()은 즉시 스크롤하지 않고, 다음 remeasure 시점에 리스트를 특정 항목으로 스크롤하도록 요청합니다. 리스트 데이터가 변경되었다면, 변경된 데이터를 기준으로 index에 해당하는 데이터로 스크롤 됩니다. 즉, 데이터 업데이트 → 스크롤 이동 순서가 보장되어 데이터가 아직 준비되지 않았는데 스크롤이 먼저 발생하여 싱크가 맞지 않는 문제를 방지할 수 있습니다.

마무리하며

이번 포스트로 다룬 내용 외에도 많은 Compose에서의 시행착오와 고민들이 있었지만, 모두 다룰 수는 없어 UI 특성을 고려하여 설계하고 구현한 내용으로 준비해 보았습니다. 이렇게 큰 범위의 UI를 설계하는 것은 처음이었는데도 불구하고 메시지 기능을 고도화하고 있는 지금, 개발 효율이 크게 향상됨을 실감하고 있습니다. 앞으로 새로운 기능을 더욱 빠르고 안정적으로 선보일 수 있는 기반이 마련되었으니, 지속적으로 발전하는 채팅 경험을 기대해주시기 바랍니다!

현재 fromm Android팀은 인재 영입 중입니다! 저희와 함께 더 나은 코드를 만드는 것에 관심이 있으시다면?! 👉 채용 공고 보러 가기