주의: 극히 개인적인 의견입니다.

앞으로 RIBs에 대해 포스팅을 하기전 쓰려는 이유부터 정리하고 써나가면 좋을 듯 싶어서

시작은 사용하려는 이유를 포스팅하기로 하였다.

MVC 그리고 MVVM을 지나서 RIBs로 가게된 내 생각의 흐름이랄까?

컨퍼런스 참석하는 것을 좋아해서, 2016년정도부터 였을까?

단체 카톡방을 통해 정보를 얻고 자주 참석했었다.

RxSwift와 자주 나오는 세션이 있었다.

그건 바로 MVVM

MVVM

“MVC의 M은 메시브래!”

하는 말을 이제는 많은 iOS 개발자가 들었을 것 같다.

음 그렇구나 ViewController가 하는게 너무 많구나 싶었다.

비즈니스 로직, 데이터 소스, UI컨트롤 처리 등등 많이 하긴 했다.

그 와중에 RxSwift는 MVVM은 거의 한 몸 아닌가 싶을정도로

세션들에서 자주 같이 등장했다.

비동기식 프로그래밍을 할 수 있는 RxSwift를 쓰면

MVVM을 좀 더 잘 쓸 수 있게 도와주는 그런 요소인 것이었다.

한 몸까진 아니었다. 안 쓰면 불편할 뿐,,

MVC 대신 MVVM이 좋았던 점은

ViewController는 이벤트 컨트롤과 데이터 뿌리는 정도만 하고,

데이터 소스나 비즈니스 로직들은 ViewModel에게 넘긴다는 점이 좋았다.

ViewModel로 만들면 테스트도 용이해진다! 라는 말이 나왔다.

그쯤부터였을까? TDD도 많이 나오기 시작하면서 테스트의 붐에 가속이 붙은 것 같았다.

나도 어느샌가 대열에 합류했다.

자동화 테스트에도 관심이 많이 생기고,

MVVM & RxSwift 스터디도 하면서 시간을 많이 투자했다.

그런데, MVVM을 할수록 어려워졌다.

날 혼란스럽게 한 것은 자료들마다 MVVM에 대한 설명이 제각각이었다는 점이다.

MVVM의 어려움

MVVM 자료는 많았다. 정말 정말 많았었다.

그치만 왜인지 설명들의 큰 틀은 같았으나, 세부적으로 갈수록 자기들만의 스타일이 있었다.

왜 그렇게 하는지는 대충 이해는 됐지만, 이해가 된게 더 무서웠다.

이것도 저것도 말이 된다는건 룰이 없다는 것 같았기 때문이다.

개인적으로 화면이 복잡해지고 코드가 길어질수록 나중에 봤을때 느낀게 있었다.

MVVM한테 입력을 주는 경우가 있고, MVVM이 출력을 하는 경우도 있을 때,

먼 훗날 보면 이건 입력이야 출력이야..? 하는 경우가 있었다.

다시 말해,

Rx에 Subject들은 Observer & Observable이다.

즉, 방출과 구독을 어찌하냐에 따라 MVVM 입장에선 입력이 될 수도, 출력이 될 수도 있었다.

나와 같은 생각을 한 해외 개발자가 있었다.

이를 명확하게 해줄 수 있도록 input, output을 프로토콜로 정의하고

이를 ViewModel 프로토콜이 준수하는 형태였다.

어느 정도 해소 되긴 했지만 뭔가 먼길로 돌아간다는 느낌이 떨쳐지진 않았다.

그러다가 RIBs를 처음 봤을땐

오 이 부분을 해소할 수 있겠는데? 싶었다.

하지만 첫만남은 거기서 끝났다.

보다보니 든 생각은 이랬다.

“이렇게까지 해야해?”

MVVM에서 메시브 뷰컨트롤러가 보이다.

ViewModel을 보다보니 이전의 ViewController가 생각났다.

MVVM 이후로 ViewController는 상당히 단순해졌다.

그래서 그럴까?

ViewModel가 메시브해지는거 같단 생각이 들었다.

데이터 소스 역할도 하랴, 비즈니스 로직도 하랴,,,

그래서 조금씩 다른 것들이 보이기 시작했다.

Interactor와 Coordinator

RIBs를 잠깐 보았을 때, Interactor라는 요소가 눈여겨졌다.

비즈니스 로직을 전담을 했다는 장점이 보여서

MVVM과 Interactor를 찾아보았더니 역시나 있었다.

MVVM-I 라는 식으로 불리우는 듯 했고,

이를 도입하면서 ViewModel의 비즈니스 로직은 해결이 된 듯 했다.

그리고 화면 이동에 관해서도 어느 귀인의 조언도 듣고,

찾아보니 Coordinator라는게 있었고 이를 통해 화면 이동 관련 부분을 도려내서

다이어트 했던 ViewController를 좀 더 다이어트시킬 수 있었다.

그리고 이는 MVVM-C라 불리고 있었다.

결론적으로 Interactor와 Coordinator를 통해 기존 MVVM보단 더 다이어트 할 수 있었다.

근데 이렇게하고 보다보니

이전에 RIBs에서 느꼈던 “이렇게까지 해야해..?” 를 내가 찾아서 하고 있다는 생각이 들었다.

다시 보인 RIBs

위에 쓰인 대로 내가 결국에 하던게 RIBs로 향하는거였구나 싶었다.

그리고 나서 RIBs를 기반으로 강의하신 노수진님의 유료강의를 다시 보았다.

(리스펙합니다! 노수진님 팬이에요!)

가려운 부분을 명확하게 긁어 주는 아키텍쳐였다.

1. VM에게 명확하지 않던 입력, 출력이 너무 명확해졌다.

Router, Interactor, Builder

각 요소들이 역할을 잘 나누어 가졌기 때문에 많은 것들이 명확했다.

의문이 필요 없을 정도로?

2. 메시브해 보이던 것이 많이 줄었다

이 말은 MVVM보다는 그렇다는 말이다.

노수진님은 RIBs도 결국 쓰다보면 메시브해지는 감이 있어서

아키텍쳐의 문제가 아니라는 부분을 말하셨다. 다시볼때 들으니 많이 공감이 되었다.

그리고 그 부분을 잘 해소한 것을 강의로 만드셨다.

(패캠 강의 강추!)

3. 부모 리블렛이 자식 리블렛의 생명 주기를 관리한다.

일반적으로도, Coordinator 패턴도 부모가 자식을 present 또는 push하고 나면

dismiss나 pop을 하는 것은 자식 뷰컨이었다.

하지만, RIBs는 달랐다. 내가 띄운 화면은 내가 책임진다는 형태가 굉장히 마음에 들었다.

위에 말했듯 RIBs를 처음엔 피했지만,

내 아키텍쳐를 개선하다보니 어느샌가 MVVM에서 RIBs에 가까워진 모습이었고,

내가 개선한 부분도 아쉬움이 있었지만, RIBs에선 그 부분도 많이 해소되었다.

그러다보니 내 입장에선 RIBs를 하지 않을 이유가 없다.

그렇지만 단점이 아예 없는 것은 아니다.

RIBs의 단점

1. 너무 높은 러닝 커브

MVC -> MVVM은 보면

ViewController에서 일부를 떼어내서 ViewModel로 만들었기에

간단한 편이었다. (물론 처음엔 어려웠다.)

하지만, RIBs는 각 요소들도 파악하고 이해해야 할 것이 너무 많다.

화면 띄우는 것도, 데이터 주고 받는 것도, 생성하는 것도 모두 다!

Uber의 Tutorial는 처음엔 따라 가는 것 조차도 힘들었다.

Component는 뭐고,, Router는 뭔데, Routing은 또 뭐고?

튜토리얼을 마치고, 3번정도 따라 만들었다. 이제 좀 감이 왔다.

이번엔 안보고 해보자 하고 새 프로젝트 생성부터 했다.

시작을 전혀 못했다.

다른 것 할땐 아무렇지 않게 계속 해오던 프로젝트 생성과 화면 띄우기인데,

이번엔 아무것도 구현 안한 뷰컨 하나 조차를 못띄우다니!

Root 리블렛을 못 붙여서 결국 튜토리얼 파일 보면서 구조를 파악했다.

2. 기계가 된 기분이다

Uber의 첫 설명은 다음과 같다.

RIBs is the cross-platform architecture framework behind many mobile apps at Uber

프레임워크다.

정말 프레임이 잘 잡혀있고, 그 안에서만 놀다보니깐

이렇게 해볼까? 저렇게 해볼까? 고민할 틈도 없다.

그냥 정해진 규칙대로 진행하면 된다.

(물론 세부적인 요소는 논외로!)

이게 장점이기도 하지만 개인적으로 뽑은 단점으로도 볼 수 있을 것 같다.

너무 규칙적이라 나중에 개발자 자리를 AI한테 뺏겨서 없어지는거 아닌가 라는 과대 망상도 들긴 했다.

3. 테스트도 다시 익혀야한다

이제서야 어느정도 MVVM은 TDD를 지키면서 개발하는 방법을 습득했다 생각했다.

근데 RIBs에서 적용하려니 TDD엄두를 못내겠다.

Test Double도 많이 생성되어야 하고,

미숙하다보니 하나 만드는데도 생각보다 시간이 많이 걸린다!

이제 익숙해진 테스트가 다시 낯설어진 느낌이다.

그럼에도 불구하고 익히고 싶다.

위에서 말한 틀이 잘짜여져서 단점이라 하긴 했지만,

이는 사실 큰 장점이다.

구조에 대한 시간 소모는 상당한데, 이를 많이 줄여줬으니,

내가 좋아하는 UI나 다른 요소에 그만큼 투자를 할 수 있다는 점이다.

또한, 큰 기업들에서도 RIBs를 적용 하는 경우가 생각보다 많은 듯하다.

많은 이들이 투입되었을 때, 사용하기 좋은 아키텍쳐라는 증거가 아닐까 싶다.

그만큼 잘 나눠져 있다는 거겠지!

생각보다 글 길이 길어졌지만

결론은 MVC보다 잘 나눠진 MVVM도 어느샌가 아쉬움이 있어서,

개선하다보니 RIBs를 지향하고 있었기에,

러닝커브가 좀 높다해도 이제는 도전해보려고 한다.