fromm 채팅 리뉴얼: MVI 도입 및 성능 개선

들어가며

안녕하세요. 노머스 모바일팀에서 안드로이드 개발을 맡고 있는 오상아입니다. 저희 회사에서 운영하는 fromm 앱은 아티스트와 팬이 소통하는 플랫폼으로, 채팅 기능이 서비스의 중심적인 역할을 합니다. 하지만 출시 초기, 4개월이라는 짧은 개발 기간 내에 빠르게 앱을 완성하다보니 성능이나 확장성, 유지보수성 등을 충분히 고려하지 못했던 아쉬움이 있었습니다.

이에 따라 2024년 하반기에는 기존 구조의 복잡성을 개선하고 지속적인 기능 확장과 원활한 유지보수를 위해 채팅 시스템의 근본적인 개선 작업을 진행하게 되었습니다. 서버 API 변경뿐만 아니라 안드로이드 앱의 전체적인 아키텍처 변경, 모든 UI를 Jetpack Compose로 재구성하는 등 많은 변화가 있었습니다. 이번 글에서는 이러한 대규모 개선 작업 중에서도, 특히 기존 프로젝트의 채팅방 메시지 관리 방식에서의 구조적, 성능적 문제들을 어떻게 해결했는지에 대해 소개해보고자 합니다.

기존 채팅 시스템의 구조적 문제점과 성능 저하

1. God Class 문제: ChatManager의 과도한 책임

기존 채팅 시스템에서의 가장 큰 문제는 ChatManager라는 거대한 Singleton 객체였습니다.

ChatManager는 다음과 같은 다양한 역할을 맡고 있었습니다.

• 채팅방 목록 관리
• 모든 채팅방의 메시지 로드
• 수신된 메시지 업데이트
• 메시지 삭제 및 숨김 처리
• 번역 기능 관리
• 채팅 연결 및 해제 관리

이처럼 ChatManager는 채팅과 관련된 거의 모든 로직을 관리했습니다. 문제는 ChatManager가 Singleton 객체로 구현되어 전역적으로 접근이 가능했기 때문에, 코드 곳곳에서 ChatManager에 의존하게 되었다는 점입니다. 이는 ChatManager의 책임이 더욱 비대해지는 결과를 초래했습니다. 결과적으로, ChatManager는 ‘God Class’가 되어, 작은 변경에도 전체 시스템에 영향을 미칠 수 있는 위험을 내포하게 되었습니다. 또한, 각 역할이 독립적으로 관리되지 못하고 ChatManager에 종속되어, 코드의 재사용성과 테스트 용이성도 크게 떨어졌습니다. 이러한 구조는 시간이 지날수록 코드의 복잡성을 증가시켜, 유지보수와 기능 확장을 점점 더 어렵게 만들었습니다.

2. 단일 Map 기반의 상태 관리와 메모리 비효율성

특히 ChatManager 는 모든 채팅방의 메시지를 아래와 같은 chats 라는 변수에 담아 관리했습니다. 이 변수는 채팅방 ID(String)를 키로, 해당 채팅방의 메시지 리스트(List<ChatDto>)를 값으로 가지는 Map 형태였습니다.

private val _chats = MutableStateFlow<Map<String, List<ChatDto>>>(mapOf())
val chats = _chats.asStateFlow()

이러한 구조는 과도한 메모리 사용과 성능 저하라는 두 가지 문제를 야기했습니다. 먼저, 모든 채팅방의 메시지를 하나의 Map에 저장하는 방식은 메모리 사용량 증가로 이어졌습니다. 채팅방 수와 각 채팅방의 메시지 수가 증가할수록, chats에 저장되는 데이터의 양도 늘어나게 됩니다. 예를 들어, 사용자가 10개의 채팅방에 참여하고, 각 채팅방에 10,000개의 메시지가 있다면, chats에는 10만 개의 메시지가 저장되는 것입니다. 특히 ChatManager는 Singleton 객체로, 앱이 실행되는 동안 계속 메모리에 올라가고, chats 또한 앱이 종료될 때까지 유지됩니다. 따라서 사용자가 채팅방을 나간 후에도, 해당 채팅방의 메시지 데이터는 chats에 계속 남아있게 되고, 더 이상 사용되지 않음에도 불구하고 메모리를 차지하게 됩니다. 이러한 현상이 반복되면, 앱의 메모리 사용량은 계속해서 증가하게 되고, 결국 메모리 누수(Memory Leak)로 이어질 위험이 있었습니다.

또한, chats 변수에 저장된 메시지 데이터가 많아질수록, 메시지를 검색하거나 업데이트하는 데 필요한 시간도 증가하여 성능 저하를 일으켰습니다. 특히 기존 페이징 방식은, 사용자가 스크롤할 때마다 메시지를 제한 없이 기존 리스트에 추가하는 방식이었기 때문에, 사용자가 스크롤을 많이 하고 채팅방을 오래 사용할수록 메시지 리스트는 계속해서 커졌습니다. 이로 인해 사용자에게 보이지 않는 과거 메시지까지 메모리에 유지해야 했고, 메시지 리스트가 커질수록 메시지 탐색이나 조작에 더 많은 시간이 소요되었습니다.

결과적으로, 이러한 비효율적인 상태 관리와 페이징 방식은 사용자 경험을 저하시키는 주요 원인이 되었습니다.

3. 복잡한 데이터 흐름과 불필요한 연산의 반복

ChatManager와 ChatViewModel 간의 데이터 흐름 또한 복잡했습니다.

(편의를 위해 usecase, repository 를 거치지 않고 직접 DB 에서 데이터를 가져오는 것으로 표현했습니다.)

위의 다이어그램은 채팅방에서 메시지를 불러오는 과정을 간략히 보여주는데, 데이터가 불필요하게 여러 단계를 거치며 비효율적으로 흐르는 것을 확인할 수 있습니다. 특히 ViewModel은 View에서 전달받은 액션을 직접 처리하지 않고 ChatManager에 위임하는 단순 중개 역할만을 수행하고 있었습니다. 또한, ChatManager 가 StateFlow 로 방출한 데이터를 다시 View 를 통해 전달받아 매핑하고 있었습니다. 이처럼 ChatManager와 ViewModel의 역할이 명확히 분리되지 않아 데이터 흐름이 복잡해지고, 데이터 관리 주체가 여러 개로 분산되는 문제가 발생했습니다.

이에 더해, 데이터가 업데이트 될 때마다 ChatManager 의 List<ChatDto> 를 ChatViewModel 의 UI 모델인 List<ChatMessage> 로 변환하는 과정에서 불필요한 연산이 반복적으로 수행되는 문제도 있었습니다. 일부 메시지만 추가, 삭제, 업데이트되더라도 리스트 전체를 새로운 객체로 다시 생성하여 모든 메시지를 다시 매핑하는 구조였기 때문입니다. 그러다보니 날짜 구분선 추가와 같은 UI 관련 로직을 처리할 때도 동일한 데이터를 기반으로 이미 수행한 연산을 또다시 처리해야 해서 비효율성은 더욱 늘어났습니다.

새로운 아키텍처 도입 및 성능 개선

1. MVI 패턴 및 Reducer 도입

채팅 리뉴얼을 진행하면서 가장 중요하게 생각한 점은 책임을 명확히 분리하고, 상태 관리를 단순화하는 것이었습니다. 기존에는 ChatManager와 ChatViewModel이 복잡하게 얽혀 있어 데이터 흐름을 파악하기 어려웠고, 상태 변경이 여러 곳에서 발생하여 예측하기 힘들었습니다. 이러한 문제를 해결하기 위해 MVI(Model-View-Intent) 패턴과 Reducer를 도입하여 데이터 흐름을 개선했습니다. MVI 패턴은 단방향 데이터 흐름을 통해 상태 변화를 예측 가능하게 만들고, Reducer는 이전 상태와 새로운 액션을 기반으로 새로운 상태를 생성하는 순수 함수로, 상태 업데이트 로직을 명확하게 분리하는 데 도움을 줍니다.

(편의를 위해 usecase, repository 를 거치지 않고 직접 DB 에서 데이터를 가져오는 것으로 표현했습니다.)

개선된 아키텍처의 다이어그램을 살펴보면, 메시지를 가져오는 데이터 흐름이 이전보다 훨씬 간결해진 것을 확인할 수 있습니다. View는 더 이상 여러 개의 StateFlow를 구독하는 대신, 오직 하나의 UiState만을 관찰하여 UI를 업데이트하는 역할에 집중합니다. 또한, 기존에는 ViewModel이 ChatManager에 의존하여 데이터를 가져왔기 때문에 데이터 흐름이 복잡하고 ChatManager의 역할이 과중되는 문제가 있었습니다. 하지만 개선된 구조에서는 ViewModel이 더 이상 ChatManager를 거치지 않고 직접 데이터를 가져오도록 변경되어, 데이터 흐름이 대폭 단순화되었습니다. 또한 UI 상태를 업데이트하는 로직은 Reducer가 담당하도록 변경되어, 새로운 메시지가 도착하면 Reducer는 기존 메시지 목록과 새로운 메시지를 결합해 새로운 UiState를 생성합니다. 이처럼 상태 업데이트 로직이 Reducer라는 하나의 장소로 집중되면서, 상태 변화를 예측하고 관리하기가 훨씬 용이해졌습니다. 이러한 변화를 통해, 기존에 거대하고 복잡했던 ChatManager는 자연스럽게 제거되었고, 복잡했던 데이터 흐름은 단방향 순환 구조로 단순화되었습니다.

2. 메모리 사용 최적화: 리스트 크기 제한

나아가, 채팅 메시지들을 관리하는 방식을 근본적으로 개선했습니다. 기존에는 모든 채팅방의 메시지를 chats라는 하나의 Map 변수에 담아 관리하는 방식이었기 때문에, 특정 채팅방의 메시지를 찾거나 업데이트하는 데 어려움이 있었습니다. 또한, 채팅방과 메시지가 쌓일수록 메모리 사용량이 증가하는 문제도 있었습니다.

이러한 문제를 해결하기 위해, 개별 채팅방의 ViewModel에서 메시지 데이터를 독립적으로 관리하도록 구조를 변경했습니다. 이제 각 채팅방의 ViewModel은 자신의 메시지 데이터들을 독립적으로 관리하므로, 메시지 관리가 훨씬 효율적이고 명확해졌습니다. 그리고 메시지 데이터들을 용도에 맞게 세분화하여 관리할 수도 있게 되었습니다.

data class ChatRoomState(
    val poolMessages: List<ChatMessage>,
    val recentMessages: List<ChatMessage>,
    val sendingMessages: List<SendingChatMessage>,
    ...
) : State

각각의 역할은 다음과 같습니다.

• poolMessages: 최근 메시지 이전의 오래된 메시지들을 저장하는 리스트입니다. 자유롭게 메시지를 추가하거나 제거할 수 있는 메시지 풀 역할을 하며, 크기는 2000개로 제한됩니다.
• recentMessages: 사용자가 아직 읽지 않은 메시지나, 새롭게 추가된 메시지들을 저장하는 리스트입니다. 이 리스트를 통해 사용자는 새로운 메시지를 빠르게 확인할 수 있습니다.
• sendingMessages: 사용자가 현재 전송 중인 메시지들을 저장하는 리스트입니다. 이 리스트를 통해 메시지 전송 상태를 관리하고, 전송 실패 시 재전송 등의 처리를 할 수 있습니다.

특히 poolMessages에서 채팅방 스크롤에 따라 사용자에게 보이지 않는 데이터는 메모리에서 제거하고, 필요 시 다시 추가하는 방식으로 메모리 사용을 최적화했습니다. 예를 들어, 사용자가 채팅방을 위로 스크롤하여 과거 메시지를 확인하는 경우, poolMessages에 없는 메시지는 서버로부터 가져와 추가하고, 이 때 리스트의 크기가 POOL_MESSAGE_LIMIT 보다 크다면 화면에 보이지 않는 최근 메시지들을 제거합니다.

    data class AddPoolMessages(val messages: List<ChatMessage>, val isPrepend: Boolean) : ChatRoomReducer(
        reducer = { state ->
            val dropSize = messages.size - POOL_MESSAGES_LIMIT
            val poolMessages = messages
                .takeIf { it.size <= POOL_MESSAGES_LIMIT }
                ?: if (isPrepend) messages.dropLast(dropSize) else messages.drop(dropSize)

            state.copy(
                poolMessages = poolMessages
            )
        }
    )

이러한 방식을 통해, 사용자가 채팅방을 활발하게 사용하더라도 필요 이상의 데이터를 메모리에 유지하지 않아 메모리 사용량이 과도하게 증가하는 것을 방지할 수 있게 되었습니다.

3. 효율적인 연산 처리 및 역할 분리

앞서 설명한 개선 사항들을 통해, 모든 채팅방의 메시지를 담고 있던 ChatManager의 chats 변수가 더 이상 필요 없어지면서, 불필요한 연산 또한 대폭 감소했습니다. 기존에는 일부 메시지만 추가되거나 수정되더라도 리스트 전체를 새로 생성하고 다시 매핑해야 했지만, 이제는 기존 리스트에 새로운 메시지만 추가하거나 제거하는 방식으로 변경되어, 더 이상 전체 메시지를 다시 매핑할 필요가 없어졌습니다. 이로 인해 불필요한 리스트 변환 연산이 크게 줄어들었고, 성능이 향상되었습니다.

더 나아가, ViewModel은 데이터 레이어에서 메시지를 가져오고, 삭제하고, 번역하는 등의 비즈니스 로직 수행과 상태 관리에 집중하도록 개선하고, UiState로의 매핑이나 날짜 구분선 추가와 같은 UI 관련 작업은 다른 클래스로 분리하였습니다. 이로써 복잡하게 얽혀 있던 ViewModel의 역할이 분산되면서 각 클래스의 책임이 명확해졌고, 코드의 가독성과 유지보수성이 크게 향상되었습니다.

마무리하며

이번 fromm 채팅 시스템 리뉴얼을 통해 안정성과 성능, 확장성, 유지보수성 등 많은 측면에서 개선을 하였습니다. 이제 새로운 구조를 바탕으로 더욱 효율적이고 빠르게 기능을 추가하고 유지보수 할 수 있기를 기대합니다. 앞으로도 지속적인 개선을 통해 더 나은 사용자 경험을 제공하고 더 좋은 서비스를 만들기 위해 계속해서 발전해 나가겠습니다. 감사합니다!