안녕하세요. 여기어때컴퍼니 iOS개발팀 토리입니다.저는 지난 5년간 여기어때 iOS 앱의 변화를 경험하며, iOS 아키텍처의 진화과정을 함께 했습니다. 최근에는 SwiftUI 도입에 적합한 아키텍처를 모색하며 또 다른 전환의 시기를 맞이하고 있습니다.모텔 검색에서 시작해 해외 숙소까지 아우르는 종합 숙박 플랫폼으로여기어때 앱의 초창기 모습을 기억하시나요? 중소형호텔(모텔) 검색 서비스로 시작했던 여기어때 앱은 이제 해외 숙소 예약까지 포괄하는 종합 숙박 플랫폼으로 성장했습니다. 이 과정에서 앱과 팀의 규모는 커지고, 기술적 요구사항 또한 복잡해졌습니다. 이러한 변화에 대응하기 위해 앱의 아키텍처 또한 끊임없이 진화해왔습니다.이 글에서는 여기어때 iOS 앱의 아키텍처가 변화해온 여정과, 현재 도입 시작중인 SwiftUI에 적합한 MVI 패턴에 대해 이야기하려고 합니다. MVI를 구현하는 다양한 방법을 예제코드와 함께 알아보겠습니다.지금부터 여기어때 iOS 앱의 변천사 여정을 떠나볼까요?🚀😆여기어때의 아키텍처 변천사: MVC, MVVM, MVIMVC(Model-View-Controller): 2014년 여기어때 앱 출시초창기 여기어때 iOS 앱은 MVC 패턴을 채택하여 개발했습니다. 왜 MVC를 당시 채택할 수 밖에 없었는지 이해하기 위해 2014년 당시의 상황을 한번 보시죠.먼저, 2014년 당시 애플은 공식 개발 문서와 튜토리얼을 통해 MVC 패턴을 권장하고 있었습니다. 그로 인해 당시 대부분의 iOS 앱은 MVC 패턴을 기반으로 개발되었습니다.여기어때 앱 로고또한, 당시 여기어때는 스타트업으로, 빠른 기능 구현과 최적화된 사용자 경험이 최우선이었을 것입니다. 개발팀은 작은 규모로 구성되어 있었고, 이러한 환경에서는 엄격한 아키텍처보다는 속도와 유연성이 중요한 의사결정 요소로 작용했을 가능성이 큽니다.MVC는 당시 목표를 달성하는 데 적합한 선택이었고, 빠른 개발과 기능 구현에 유리한 구조였습니다. 그러나 시간이 지나면서 MVC의 한계가 드러나게 됩니다.MVC 패턴의 한계MVC는 코드의 역할을 명확히 분리하여 개발 초기의 속도와 단순성을 보장하는 데 효과적이었습니다. 그러나 MVC의 구조적 한계는 많은 개발자들이 익히 알고 있을 것입니다. 특히, ViewController가 지나치게 비대해지는 Massive ViewController 문제가 있습니다. ViewController가 비대해지면서 유지보수 편의성과 코드 재사용성이 떨어졌습니다.MVVM(Model-View-ViewModel)+RxSwift 도입2015년 RxSwift의 등장과 함께, 반응형 프로그래밍(Reactive Programming)이 iOS 개발자들 사이에서 점차 주목받기 시작했습니다. MVVM은 데이터 바인딩과 상태 관리를 보다 명확하게 분리할 수 있도록 설계되어, 앞서 말씀드린 Massive ViewController문제를 해결할 수 있습니다.여기어때 iOS팀은 2019년 초부터 RxSwift + MVVM 패턴을 본격적으로 도입하기 시작했습니다. 특히, 호텔타임 앱에

안녕하세요. 여기어때컴퍼니 iOS개발팀 레이너입니다.여기어때 앱은 오랜 시간 UIKit 기반으로 안정적으로 구축되어 왔는데요, 최근 몇 년간 SwiftUI가 점차 성숙해지면서 앱 주요 화면을 SwiftUI로 전환해 보는 시도를 시작하게 되었습니다. SwiftUI는 선언형 구성을 통해 코드를 간결하게 만들고, 유지 보수도 더 쉬워질 가능성을 제공해 주죠. 이번 변화의 첫 발걸음으로 Home 화면을 SwiftUI로 재구성해, 기존 UIKit 방식과의 차이를 실험해 보고자 했습니다.이번 글에서는 SwiftUI를 적용하면서 경험한 다양한 인사이트와 해결해야 했던 과제들, 그리고 전환을 통해 얻은 변화와 기대 효과를 공유드리려 합니다. SwiftUI 도입을 고민 중이신 분들께 저희의 경험이 작은 도움이 되기를 바랍니다.1. SwiftUI 도입 배경과 목표여기어때 앱은 그동안 다양한 기능을 추가하며 점진적으로 UIKit 기반의 안정적인 구조를 다져왔습니다. 하지만 앱의 규모가 커지고, 유지보수의 복잡도가 높아지면서 보다 간결하고 선언형 방식에 적합한 프레임워크의 필요성을 느끼기 시작했습니다. SwiftUI는 Apple이 제안한 선언형 UI 프레임워크로, 코드 작성이 간편할 뿐만 아니라, UI와 로직이 보다 명확하게 분리되어 관리됩니다.SwiftUI의 적용을 통해 기대한 목표는 크게 두 가지입니다. 첫 번째는 코드의 단순화입니다. SwiftUI는 UI 상태에 따라 UI를 자동으로 갱신해주는 구조를 갖추고 있어, 기존에 UIKit에서 다뤘던 수많은 이벤트 관리 코드나 인터페이스 상태 관리에 관한 로직을 간소화할 수 있습니다. 두 번째는 향후 확장성과 유지 보수성 향상입니다. SwiftUI는 시간이 지나면서 Apple 생태계 내에서 더 확장될 것으로 기대되고 있어, 여기어때 앱의 다른 화면에도 SwiftUI를 점차 확장해 나가는 데 이번 초기 도입 경험이 좋은 밑거름이 될 것으로 기대하고 있습니다.2. UIKit과 SwiftUI의 차이점UIKit과 SwiftUI는 UI를 구성하는 방식부터 완전히 다른 접근법을 사용합니다. UIKit은 명령형 방식으로, 모든 UI 요소의 변화에 대해 직접적인 업데이트를 가해야 하는 반면, SwiftUI는 선언형 방식으로 앱 상태 변화에 따라 UI가 자동으로 재구성됩니다.이 차이는 코드 구성 방식에 큰 영향을 미쳤습니다. UIKit에서는 뷰 컨트롤러에서 UI를 갱신하기 위한 상태를 추적하고 그에 맞는 이벤트를 처리해야 했습니다. 반면, SwiftUI는 상태(State)와 데이터 바인딩을 통해 화면의 일관된 상태를 관리합니다. 이러한 구조 덕분에 개발자는 더 적은 코드로도 동일한 인터페이스를 구현할 수 있고, UI 상태와 비즈니스 로직을 깔끔하게 분리할 수 있습니다.3. Home 화면에서 SwiftUI 적용 과정1) SwiftUI에 ReactorKit을 사용하기여기어때 앱은 기존에 UIKit 기반의 ReactorKit을 활용하여 상태를 관리하고 로직을 분리해왔습니다. 하지만 SwiftUI는 UIKit과 근본적으로 다른 선언형

안녕하세요. 오랜만에 돌아왔습니다.올리브영 모바일앱 개발팀에서 근무하고있는 럭셔Lee💍 입니다.그동안, 올리브영 앱의 내부에선 많은 변화가 있었는데요. 이번에는 올리브영 앱에 도입한 프레임워크 ReactorKit에 대해서 소개해보겠습니다..🏃🏃‍♀왜 ReactorKit을 사용했나요?모바일앱 개발팀에서는 자체적으로 필요한 내용을 공부하고 공유하는 자리를 갖고 있습니다.이번에 공부할 주제를 찾아보던 중, 저의 이목을 끄는 한 가지가 있었습니다.사용법도 간단하고, 유지보수 및 테스트에 강점이 있는 아키텍처 구조인 ReactorKit 프레임워크인데요. 제가 ReactorKit을 사랑할 수 밖에 없는 이유를 공개해 보겠습니다.• 특정 부분에만 적용할 수 있음. (전체 적용이 전제되지 않아요.)• 테스트하기 쉬움. (Reactor와 View에 대해 의존성이 없기 때문이에요.)• 코드가 간결해짐 (ViewController에 있는 로직을 분리하면 간결해지겠죠?)이렇게 장점이 많은 ReactorKit, 사용하지 않을 이유가 없잖아요? 올리브영 앱의 네이티브 영역을 리팩토링하면서, 바로 실전에 적용해 보았습니다.ReactorKit은 RxSwift와 함께 사용되는 프레임워크에요. 따라서, ReactorKit을 사용하려면 RxSwift에 대한 이해와 Swift 언어의 기본 지식은 필수적으로 선행되어야 합니다.ReactorKit의 핵심 개념은 Reactor입니다. Reactor는 Rx의 개념인 Observable과 함께 사용하여 비동기적으로 데이터를 처리하고, UI와의 상호 작용을 쉽게 관리할 수 있는 구조를 만듭니다.즉, MVVM 모델의 뷰 모델(ViewModel)과 같은 역할을 하며, 비즈니스 로직을 처리하고 뷰(View)와 상호 작용하는 방법을 제공합니다.이를 통해 UI 관련 코드와 비즈니스 로직을 분리하고, 코드의 재사용성을 높일 수 있습니다.다음 그림을 통해, ReactorKit의 작동 방식을 간단하게 알아봅시다.사용자의 Action은 Reactor로, Reactor에서 방출된 State는 View로 Observable 스트림을 통해 전달됩니다.이러한 흐름은 단방향적입니다.View는 Action만 방출 할 수 있으며, Reactor는 State만 방출 할 수 있습니다.단방향적 흐름으로, View와 비즈니스 로직을 분리 할 수 있으며 모듈 간 결합도가 낮게 개발할 수 있습니다.다음 그림을 통해 , ReactorKit의 작동 방식과 사용법을 상세하게 알아봅시다~~!View는 Reactor로 받는State를 통해 UI를 보여주는 역할과, 사용자 인터랙션을 추상화하여 Reactor로 전달하는 역할을 수행합니다.그림을 통해 보시면, View는 Reactor를 향해 Action을 방출하고 있으며, Reactor는 View를 향해 State를 방출해주고 있습니다.이를 적용하기 위해선, 프로토콜을 적용해야하며, 그 안에 프로퍼티와 메서드를 반드시 정의해주어야 합니다.내부에는, Reactor로 보낼 Action과, Reactor로부터 수신할 State를 작성하면 됩

안녕하세요! 매스프레소에서 iOS Developer로 일하고 있는 Haskell입니다.매스프레소에서 QANDA를 개발하면서 기존 사용하고 있는 RIBs 아키텍처에 ReactorKit를 도입하게 된 이야기를 해보려고 합니다.RIBs X ReactorKit도입하게 된 이유ReactorKit를 도입을 검토할 당시 iOS팀의 구성원은 5명으로 각자 다른 TF에 소속되어 TF내에서 진행하는 iOS 개발 업무를 담당하고 있었습니다. RIBs를 기반으로 앱을 개발하면서 전체적인 구조는 통일되어 있었지만, 하나의 RIB을 개발하는 방식은 개발자마다 다른 방식으로 구현되어 다른 개발자가 개발한 RIB을 수정하기 위해서는 어떤 방식으로 개발 되었는지 파악하는 일이 선행되어야 했고 이는 생산성 저하로 이어졌습니다. 그와 함께 RIB안에서 상태 관리도 제각기 다른 방식으로 되어 있었기 때문에 Unidirectional data flow와 RIB 구현 방식의 통일된 가이드가 필요한 상황이었습니다.이를 위해 Interactor와 View(Presenter 혹은 ViewController)와 데이터 바인딩을 통해 MVVM과 유사한 방식으로 Unidirectional data flow를 구현하기로 하였습니다.이전에 Flux 개념이 적용된 MVVM 방식으로 개발했던 경험과 ReactorKit를 사용하여 개발을 진행했던 경험을 토대로 어떤 방식으로 Unidirectional data flow를 구현할지 고민하였고 아래와 같은 이유로 ReactorKit를 도입하는 방향으로 진행하였습니다.일관된 구조를 가지고 있어 코드 파악이 기존보다 개선됨.상세한 README와 여러 예제 프로젝트들로 인해 새로 팀에 입사하는 개발자도 적응 하는데 도움이 됨.유지보수가 잘 이루어지고 있음.프로토콜 기반으로 RIBs에도 적절하게 적용 가능여러 회사가 실제 프로덕트 개발에 사용하고 있음.실제 프로젝트에 적용하기까지RIBs를 사용하면서 RIB 단위로 개발을 하고 있기 때문에, 단순하게 ReactorKit를 그대로 도입하여 View마다 Reactor를 생성하여 개발을 하기보다는 RIBs에 맞는 방식으로 ReactorKit를 도입하고자 하였습니다.iOS 개발자 커뮤니티를 통해 실제 이미 RIBs와 ReactorKit를 함께 사용하고 있는 카카오 뱅크 등 여러 회사 개발자분들의 조언을 구하고 개인적으로는 샘플 프로젝트를 개발하면서 실제 개발 시 고려하여 할 점은 무엇인지 고민을 하며 현재 QANDA 프로젝트에 맞게 적용하였습니다.Uber RIBsRIBs의 구성 요소는 아래와 같습니다.https://github.com/uber/RIBs/wiki이런 구성 요소에서 우버가 사용하고 있는 Data flow는 아래와 같으며 이를 참고하여 샘플 프로젝트 개발을 진행하였습니다.Data flow in RIB상세 구현ReactorKit은 View에서 액션이 발생하면 Reactor가 이를 처리하여 State를 업데이트하고 View에서는 필요한 State를 binding하여 State가 업데이트됨에 따라 View를 업