iOS 개발에 있어, 수백줄~수천줄에 이르는 거대한 ViewController를 만나는 것은 결코 어려운 일이 아닙니다. 이런 일은 너무나 잦아서, 마치 ViewController가 거대해지는 것은 필연처럼 느껴질 정도입니다. Apple의 MVC패턴이 너무나 낡았고, 그 낡은 사고방식이 이런 거대한 ViewController를 야기한다는 취지의 이야기를 듣는 것도 어려운 일이 아니죠.
그래서 우리는 이 거대한 ViewController를 어떻게든 해보기 위해, MVP나 MVVM같은 새로운 아키텍처를 적용해보기도 합니다. 하지만 ViewController가 어떻게 거대해졌는지 근본적인 원인을 이해하지 못한 상태에서는, 그저 거대한 Presenter, 거대한 ViewModel을 재생산하는 수준에 그칠 수 밖에 없습니다.
저는 앞으로 몇 개의 포스팅을 통해, 우리가 MVC에 갖고 있었던 오해들을 풀어보고, 그 오해들이 어떻게 거대한 ViewController들을 야기했는지, 나아가 어떻게 거대한 ViewController를 피해 볼 수 있는지 이야기 해 보려 합니다. 그 첫 시작인 만큼, 오늘은 가장 기본적인 오해부터 시작해보겠습니다.
MVC 패턴에서, ViewController는 Controller다?
위 문장은 전적으로 오해라고 볼 수는 없습니다. ViewController는 분명 Controller니까요. 하지만 결코 ViewController == Controller는 아니라는 점이 핵심입니다. ViewController는 그저 Controller의 일종일 뿐입니다. 애플의 문서는 이 점을 분명히 하고 있습니다.
One can merge the MVC roles played by an object, making an object, for example, fulfill both the controller and view roles — in which case, it would be called a view controller.
즉, ViewController는 View이면서 Controller인 객체입니다. 애플에서는 ViewController뿐만이 아니라 다른 종류의 Controller들에 대해서도 많이 언급하고 있습니다. 대표적으로 ModelController가 있죠.
In the same way, you can also have model-controller objects. …(중략)A model controller is a controller that concerns itself mostly with the model layer. It “owns” the model; its primary responsibilities are to manage the model and communicate with view objects.
여기까지만 해도 벌써 우리가 얼마나 ViewController에 지나친 책임을 부여했는지 공감 하는 개발자분들이 계실겁니다. ViewController는 “View”입장에서의 Control을 주로 담당했어야 하는 객체인데, 그런 ViewController에게 우리는 ModelController로써의 역할까지 부여하고 있었던 것이지요.
대표적으로, ViewController에서 네트워크 API콜을 하고, 응답을 받고, 그 결과를 파싱해서 저장하는 것 까지 ViewController에서 이루어지는 예시를 생각 할 수 있을 것입니다. 애플의 권장사항에 의하면, 모델 객체들을 불러오고 소유(저장)하는 것은 모두 Model Controller의 역할입니다. 그리고 이렇게 확보/정제된 모델들을 ViewController에게 전달하기만 하는 것이죠.
이상의 이야기를 그림으로 풀어보면 아래와 같습니다.
애플에서 만든 ModelController에는 대표적으로 NSDocumentController 가 있습니다. 해당 문서와 API를 잘 살펴보면 ModelController의 역할에 대해 더 감을 잡으실 수 있을 것입니다.
아마 위 그림을 보고, ModelController의 역할이 MVVM의 ViewModel과 굉장히 비슷하다고 느끼신 분들도 있으실 것입니다. 사실 그렇습니다. 물론 둘 사이의 상호작용 방식에 있어서 다소의 차이는 있을 수 있지만, “책임”이라는 차원에서만 놓고 본다면 그 둘은 매우 유사합니다. 관련 내용은 “MVVM is MVC Done Right”라는 포스트에서 더 자세히 다루고 있습니다.
결론
얼마전 포스팅에서 “MVP는 사실 Cocoa MVC다” 라는 내용을 다뤘었지요. 이번에는 결론적으로 MVVM도 사실 Cocoa MVC다 라는 내용이 되어버렸네요. Cocoa MVC가 물론 만병통치약은 아닙니다. 모든 프로젝트에 적절하지 않을 수도 있지요. 하지만 거대한 ViewController 문제를 해결 할 때, “요즘 유행하는 최신” 아키텍쳐를 적용하기보다는, 다시 한 번 Cocoa MVC를 자세히 뜯어보고, Apple 플랫폼에서 사용하는 언어/개념들로 문제를 해결하는 쪽이 아마 훨씬 빠르고 수월하지 않을까요?