발표 순서와 두레이 소개
발표 진행 순서를 안내하고 업무용 협업툴 두레이를 소개한다. 프로젝트·메신저·메일·위키를 한 번에 제공해 데이터가 많고 복잡한 로직과 잦은 상태 변화가 발생한다는 앱 특성을 짚으며, 이 특성이 뒤에 나올 문제점의 뿌리임을 예고한다.
기존 두레이 앱이 쓰던 MVVM의 데이터 흐름을 설명하고, 업무 등록 시 프로젝트 하나를 바꾸면 마일스톤·태그·담당자·권한이 서로 바인딩된 채 연쇄로 갱신되는 사례를 든다. 흐름의 출발점을 판단하기 어려워 디버깅이 난해했고, 앱 특성이 MVVM 한계를 증폭시켰다고 정리한다.
새 패턴으로 선택한 MVI를 소개한다. Model·View·Intent로 구성되며 이벤트와 데이터가 단방향으로 흐른다. 여기서 Model은 MV 시리즈의 모델과 달리 오직 앱 상태(State)를 표현하는 값이며, View는 이 모델만 보고 화면을 구성한다는 점을 강조한다.
MVI 구현에 사용한 프레임워크 ReactorKit을 설명한다. RxSwift 기반 단방향이며 View↔Reactor 관계만 정의한다. 이벤트는 Action으로, Reactor 내부는 Mutate·Mutation·Reduce로 나뉘고, 스트림을 벗어나는 API·DB·IO 작업은 Side Effect로 처리한다는 개념을 도입한다.
파일 업로드 동작으로 MVI 흐름을 따라간다. Action이 Reactor의 Mutate로 전달돼 인디케이터 표시→파일 업로드→목록 갱신→인디케이터 제거의 Mutation이 순차 방출되고, 각 Mutation이 Reduce를 거쳐 State가 되어 View를 갱신한다. `concat`으로 비동기를 순서대로 수행하는 코드도 함께 제시한다.
MVI 적용으로 얻은 세 가지 개선을 정리한다. 단방향 데이터 흐름으로 로직이 단순해지고, 화면 표현에 필요한 값이 단 하나의 불변 State로 관리돼 디버깅과 테스트 코드 작성이 쉬워졌으며, Mutate와 Reduce를 나눠 비동기·멀티스레드 상황에서도 스레드 안정성이 높아졌다고 설명한다.
MVI ReactorKit의 단점을 짚는다. Action·Mutate·Mutation·Reduce·Side Effect 등 요소가 많아 러닝커브가 높고 신규 입사자 온보딩이 어렵다. 또 단순한 화면 전환이나 데이터 변경에도 새 State·Action·Mutation을 만들어야 해 작은 변경에 코드량이 크게 늘어난다는 점을 인정한다.
토스트·얼럿·내비게이션처럼 한 번만 일어나는 일회성 이벤트 처리가 MVI에서 모호하다는 점을 다룬다. State로 관리하는 방법과 Side Effect로 외부에 위임하고 아무 동작도 하지 않는 값을 리턴하는 방법을 비교하며, 두레이는 토스트·내비게이션을 Side Effect로 처리하고 있다고 밝힌다.