안녕하세요. 여기어때컴퍼니 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개발팀 드락입니다.iOS개발팀은 개발 플랫폼에 적용된 기술 스택이 업계 메인스트림에서 뒤쳐지지 않도록 항상 노력 중인데요, 여기어때 기술블로그라는 공간을 통해 최근에 진행한 여기어때 앱의 Network/Adapter 모듈 구조 개선에 대해 한 번 이야기해볼까 합니다.이번 구조 개선은 기술적 개선&기능적 개선 두 가지 전부 이루어졌는데요, 개선사항은 다음과 같습니다.1. Network, Adapter 모듈과 인터페이스에서 RxSwift, RxCocoa의존성 제거2. UI 레벨에서 네트워크 로딩 상태를 자유롭게 핸들링 가능한 구조로 전환우선, 첫 번째로 언급한Network, Adapter 모듈, 인터페이스에서 RxSwift, RxCocoa의존성 제거부터 살펴보겠습니다.바로 제거하기 전에 어쩌다 RxSwift에 의존하게 되었는지, 이제와서 굳이 왜 제거하려 하는지를 우선 살짝 짚고 넘어가자면..대략 2018년도 즈음.. 앱개발 씬이 ReactiveX Hype 상태일 시절, 세상이 iOS개발자에게 RxSwift & RxCocoa 스킬을 필수 소양으로 요구했었고, 저 역시 RxSwift와 RxCocoa를 익히며 앱의 코어부터 UI레벨에 거쳐 사방팔방에 Rx를 적용했습니다.그런데…이제 상황이 약간 변했습니다?우선, First-Party인 애플에서 Built-in으로 Rx대안 솔루션인 Combine을 발표했고, 지속적으로 지원해주고 있습니다. 거기에, 기존의 callback 방식을 대체하는 형태로 사용되던 RxSwift를 대체하는(..) 차세대 비동기 처리 솔루션인 Async/Await도 발표되었죠.1st-party 솔루션을 사용하는 것은 많은 부분에서 이점을 가져다줍니다.우선 신뢰도가 높고요, 플랫폼 전반에 걸친 호환성을 보장합니다.Swift 컴파일러는 당연하게도 1st-party 타입을 가장 잘 이해하고 있기 때문에, 최적화된 코드를 생성할 수 있고, IDE 에서도 가장 매끈한 개발 지원이 이루어집니다.1st-party에서 제공하는 타입들은 통상적으로 플랫폼에 최적화된 성능을 제공하며 지속적인 업데이트와 개선이 이루어집니다.Swift 개발자들 사이에서 공통된 이해를 기반으로 하기 때문에, 누구나 빠르게 코드에 접근하고 수정할 수 있습니다.요약: 1st-Party 솔루션은 3rd-party 솔루션에 비해 안정성, 성능, 유지보수, 보편성, 프로젝트 러닝커브등 여러가지를 고려했을 때 많은 이점이 있습니다.1부터 10,000까지의 값들에 2를 곱하는 작업을 RxSwift와 Combine을 활용해서 각각 100회씩 수행해 보았습니다.좌측 상단부터 시계 방향으로 - 할당된 후 해제되지 않고 계속 유지되고 있는 메모리 블록, 할당된 총 메모리의 양, 발생한 메모리 할당 횟수, 작업 완료까지 걸린 시간아무래도 근본 태생이 다른 만큼 성능 면에서도 상당한 차이가 나고 있구요..그렇다면…….우리 프로젝트도 RxSwift에 대한 의존도를 조금이라도 줄이는 방향으로 리팩토링하는 쪽이 유리하다는 판단 아래, View와 ViewModel

’24 JT로 AI Connectivity Client 팀의 신입 개발자로 합류한 정재윤입니다.팀에 합류한 신입 개발자로서 처음 맡은 프로젝트인 "Adot Simple Assistant App" 개발의 경험을 공유하고자 합니다.이 글은 특히 저와 같은 신입 개발자들이 처음 프로젝트를 시작할 때 겪는 어려움과 고민을 조금이나마 덜어줄 수 있기를 바라며 작성했습니다.저 역시 신입으로서 많은 시행착오를 겪었고, 이 과정에서 배운 점과 느낀 점을 성장 일기처럼 전하고자 합니다.첫 프로젝트를 진행하면서 많은 기술적 도전과 문제들을 마주했습니다.이 글을 통해 제가 배운 점과 성장한 과정을 나누고자 합니다.팀에서의 첫 프로젝트를 통해 겪은 저의 여정이 다른 신입 개발자들에게 조금이나마 도움이 되기를 바랍니다.Simple Assistant를 만들어가는 과정프로젝트를 처음 마주하고 가장 먼저 해야 할 일은 ‘요건이 무엇인가’를 파악하는 것이었습니다.이번 프로젝트는 기존 Adot App의 컴포넌트를 재사용하여 Adot Agent와의 대화를 통해 도움을 받을 수 있는 Simple Assistant App를 개발하는 것이었고,이에 가장 먼저 요구사항을 간략하게 정리했습니다.• None• None 최초 로그인 시, 아이디와 비밀번호를 입력하여 TID 로그인을 진행합니다.• None 이후 로그인 시, 자동 로그인이 됩니다.• None 로그인 성공 시, 메인 화면으로 이동합니다.• None• None 채팅방 입장과 동시에 선톡 메시지가 보입니다.• None 음성 입력을 실행하면 보이스 크롬 화면에 상태에 따른 UI와 발화 내용이 보입니다.• None 입력이 완료되면 SDK를 통해 서버로 요청을 보냅니다.• None 서버로부터 Adot Agent의 응답을 받고 그 내용이 음성과 화면으로 나타납니다.• None• None “w. 음악 틀어줘” 발화 시, 음악이 플레이됩니다.• None 재생, 정지, 다음 곡, 이전 곡 등 다양한 이벤트를 처리합니다.약 한 달 정도의 시간이 주어졌기 때문에 각 요구사항에 따라 개발 요건을 바탕으로 기능별로 일정을 산출하고 계획을 수립했습니다.이제 준비가 끝났습니다.요건이 정리되면 본격적으로 개발하기에 앞서 설계를 준비해야 합니다.집을 지으라는 요구사항을 만족시키기 위해 움막을 지을 수도, 주택을 지을 수도, 아파트를 지을 수도 있습니다.마찬가지로, 앱 개발에서도 다양한 아키텍처와 기술 스택을 선택할 수 있습니다.제가 참고한 기존 Adot App는 클린 아키텍처와 Hilt를 사용한 ‘호화로운 타워 팰리스’ 수준의 집이었습니다.소프트웨어가 가진 본연의 목적을 추구하려면 소프트웨어는 반드시 ‘부드러워’ 야 한다. 다시 말해 변경하기 쉬워야 한다.이해관계자가 기능에 대한 생각을 바꾸면, 이러한 변경 사항을 쉽게 적용할 수 있어야 한다. (로버트 C. 마틴, 클린 아키텍처)예를 들어, 프로젝트에서 네트워크 통신을 위해 OkHttp 라이브러리를 사용하고 있다고 가정해 봅시다.어느 날, 기술 지침에 따라 OkHttp를 Retrofit으로 변경하라는

리액티브 프로그래밍(Reactive Programming) 개념을 정리해본다.• None 리액티브 프로그래밍에 대해서 알아본다.• None 리액티브 프로그래밍의 핵심원칙 및 키워드를 알아본다.• None 리액티브 프로그래밍의 장점을 간단하게 알아본다.• None 리액티브 프로그래밍의 구현도구및 라이브러리를 알아본다.오늘은 리액티브 프로그래밍에 대한 정리및 저의 생각을 간단하게 공유 하고자 합니다.리액티브 프로그래밍은 최근 몇 년 동안 소프트웨어 개발의 핵심 개념 중 하나로 떠오르고 있는데요...이 개념은 비동기성과 반응성을 통해 더욱 효율적이고 유연한 애플리케이션을 구축하는 혁신적인 방법을 우리에게 제공하고 있습니다.그리고 아래 4가지 내용은 머릿속에 정리해두시면 좋을것 같아서 한번 말씀드려보고자합니다.리액티브 프로그램의 개념 / 리액티브 프로그래밍의 핵심원칙및 키워드 / 리액티브 프로그래밍의 장점 / 구현도구와 라이브러리그럼 차근차근 정리해보도록 할께요~리액티브 프로그래밍의 개념을 정리해보자면요.리액티브 프로그래밍은 데이터 스트림과 변화에 반응하는 시스템을 구축하기 위한 프로그래밍 패러다임이라고 정의해 볼 수 있고요.즉,리액티브 프로그래밍은 데이터의 흐름에 초점을 맞추어 동작하며, 리액티브 프로그래밍을 하면서 데이터를 비동기적으로 처리하고,이벤트 기반 아키텍처를 통해 실시간으로 데이터의 변화에 반응할 수 있게 프로그래밍이 가능하다고 설명 드리고 싶네요~리액티브 프로그램의 핵심원칙 및 키워드 4가지리액티브 프로그래밍관련 핵심원칙을 간단하게 정리해보자면 아래와같이 4가지 키워드로 정리해볼 수 있을것 같습니다.• None 리액티브 시스템은 이벤트 또는 데이터 스트림을 비동기적으로 처리합니다. 이를 통해 다른 작업을 동시에 수행하거나 블로킹을 피할 수 있습니다.• None 리액티브 시스템은 실시간으로 데이터의 변화에 반응합니다. 사용자 요청이나 외부 이벤트에 빠르게 응답할 수 있습니다.• None 리액티브 시스템은 부하나 실패에 유연하게 대응할 수 있습니다. 시스템의 자원을 동적으로 조절하여 확장성과 견고성을 제공합니다.• None 리액티브 시스템은 메시지 기반 아키텍처를 기반으로 동작합니다. 컴포넌트 간에 비동기적으로 메시지를 교환하여 상호작용합니다.내가 생각하는 리액티브 프로그램의 장점제가 생각하는 리액티브 프로그래밍은 다음과 같은 장점을 가지고 있는 것 같습니다.• None 리액티브 시스템은 비동기적으로 동작하고, 병렬성을 통해 성능과 확장성을 향상시킵니다. 다수의 이벤트를 동시에 처리할 수 있으며, 필요에 따라 시스템을 확장할 수 있습니다.• None 리액티브 시스템은 실시간으로 데이터의 변화에 반응하여 빠른 응답 시간을 제공합니다. 이는 사용자 경험을 향상시키는 데 도움이 됩니다.• None 리액티브 시스템은 장애가 발생하더라도 탄력적으로 대응할 수 있습니다. 오류를 격리시키고, 다른 컴포넌트에 영향을 주지 않으면서 정상 동작을 유지할 수 있습니다.그외에도 여러가지 장점이 있을 수 있겠죠?리액티브 프로그래밍의 구현 도구 및 라이브러리