이 질문 뒤에 면접관이 확인하려는 것은 따로 있습니다.
iOS 앱에서 네트워크 응답과 UI 상태를 연결하는 데 RxSwift를 처음 썼습니다. 여러 비동기 이벤트를 Observable 체인으로 조합하면서 콜백보다 코드 흐름이 선형적으로 읽히는 장점을 실감했습니다. disposeBag을 뷰 컨트롤러와 생명주기를 맞춰 관리하지 않으면 메모리 누수가 조용히 쌓이는 문제를 경험했고, 이후 Rx 관련 코드에는 항상 구독 해제 시점을 명시하는 습관이 생겼습니다.
BehaviorRelay로 ViewModel과 View를 단방향으로 연결하는 MVVM 패턴을 적용했고, UI 상태 관리가 예측 가능해졌습니다. 러닝 커브가 가파르지만 비동기 이벤트가 많은 앱에서 코드 응집도가 올라가는 경험이 인상적이었습니다.
RxSwift를 처음 도입한 것은 실시간 검색 기능에서 사용자 입력 이벤트를 다뤄야 하는 상황이었습니다. 사용자가 타이핑할 때마다 API를 호출하면 과도한 요청이 생겼고, 디바운싱 로직을 명령형으로 구현하면 타이머 관리 코드가 뷰 컨트롤러에 흩어졌습니다.
debounce(dueTime:) 오퍼레이터 한 줄로 입력 이벤트가 300ms 이상 멈췄을 때만 API를 호출하도록 처리했고, distinctUntilChanged()로 같은 검색어를 중복 호출하는 케이스도 걸렀습니다. 6개월 운영하면서 검색 API 호출 수가 입력 이벤트 대비 약 70% 줄었습니다. 이벤트 스트림 관점으로 생각하면 시간과 조건을 조합하는 로직이 훨씬 간결하게 표현된다는 것을 이 경험에서 배웠습니다.
RxSwift에서 처음 실수했던 패턴은 flatMap을 네트워크 요청에 연결할 때 응답 순서를 보장하지 않는다는 것을 몰랐던 것입니다. 사용자가 빠르게 탭을 전환할 때 먼저 보낸 요청의 응답이 나중에 도착해 화면이 잘못된 데이터를 표시하는 버그가 있었습니다.
flatMapLatest로 교체해서 마지막 요청만 구독하도록 바꾼 뒤 해결했지만, 오퍼레이터 선택 하나가 버그를 만드는 구조 자체가 진입 장벽이라고 느꼈습니다. 최근엔 Swift Concurrency(async/await)가 같은 패턴을 더 명시적으로 표현할 수 있어, 신규 프로젝트에서 RxSwift를 도입하는 것이 맞는지 팀 내에서 논의가 생겼습니다.
RxSwift는 강력하지만 팀 전체가 오퍼레이터를 이해하는 데 투자 비용이 상당하다는 점은 인정합니다.
답변에서 흔히 빠지는 것들 — 빠져 있으면 꼬리질문이 깊어집니다.
이 질문에 이어 무신사 모바일 면접관이 던질 가능성이 높은 후속 질문.
이 페이지의 질문·답변·꼬리질문은 유사 직군 채용 시장의 공개된 면접 후기·커뮤니티 게시물을 분석해 구성한 학습 자료입니다. 특정 회사가 실제로 이 질문을 출제했다는 것을 보장하지 않으며, 모든 예시는 우문현답이 직접 작성한 창작물입니다. 해당 회사의 공식 입장과는 무관합니다. 회사 측의 정정 요청이 있을 경우 24시간 이내에 응답·수정합니다.