1. Intro

: iOS 관련 개발 블로그나 세미나/행사에서 Architecture 주제를 다룰 때, 종종 하는 이야기가 있다. MVC의 C가 비대해져서 MVVM을 도입해보고, VM이 비대해져서 VIP를 도입했다는 것. 예전에는 이런 이야기를 의심없이 받아들였으나, 개발을 할수록 의문이 쌓여갔다. C가 비대해서 도입한 MVVM에서, VM이 비대해졌다면... MVC로 개발하면서 발생한 문제를 잘못 짚은게 아닐까.

 개발을 하다보면 Model을 단순한 Data Structure로 작성한 코드를 많이 보았다. 그런 코드에서 Business Logic은 Controller나 ViewModel에 작성되어 있었다. 그러니까, Controller나 ViewModel에서 HTTP 통신을 하고, UserDefault나 내부 DB에서 Data를 가져오거나 저장하는 것이다. 당연히 Controller나 ViewModel은 비대해질 수 밖에 없어보이는데, 이상하지 않은가?

 마틴(Robert C Martin)은, 여러 공학에서 Model을 만들어서 검증하는 사례를 이야기하며 Model은 '추상화한 것'이라고 이야기한다(UML 책 참고). 나는 이 이야기에 크게 공감하며, ViewModel은 View를 추상화해야 하고 Model은 Business를 추상화해야 한다고 생각한다. 그래서 Business Logic은 Controller나 ViewModel에 작성하는 것이 잘못됬다고 생각한다. 

 Model을 단순한 Data Structure로 작성할 수도 있다. 문제는 왜 Business Logic을 Controller나 ViewModel에 작성하냐는 것이다. 이런 고민을 하면서, MVC나 MVVM을 처음 이야기한 사람은 어떻게 생각했는지 궁금해졌다. 그래서 이번 포스트에서는 MVC를 처음 고안한 사람의 Report를 읽은 후 요약해보고, 향후 다른 포스트에서는 다른 Architecture에 대해서도 정리해보고자 한다.

2. The original MVC reports - Trygve Reenskaug

2.1. Intro

: 옛날 1978-79년에, Tregve Reenskaug는 Xerox Palo Alto Research Laboratory (PARC)에서 연구원으로 재직하던 때에, MVC reports를 작성하고 구현했었다. MVC는, 여러 관점에서 사용자들이 Data를 통제할 수 있게 하는 일반적인 문제에 대한 솔루션으로 만들어졌었다. MVC에서 가장 어려웠던 문제 중 하나는, Architecture를 구성하는 Component들의 이름을 정하는 것이다. 처음에는 Thing-Model-View-Editor라고 이름을 지었었다(1979년 5월 12일). 하지만 긴 논의 끝에, Model-View-Controller로 이름을 바꾸게 되었다(1979년 12월 10일).

2.2 Thing-Model-View-Editor (1979년 5월 12일)

=> Thing-Model-View-Editor는 중요한 부분이 아니라고 생각해서, 아주 간략하게 각 컴포넌트의 정의부분만 정리하고자 한다.

- Thing

: 사용자가 관심을 가질만한 것.

- Model

: Computing System에서, Model은 Data의 형태로 추상화의 표현. Data를 다루는 방법도 함께 제공되는 Collection으로 보자.

- View

: View는 Model을 표시하는 역할을 한다. Thing-Model-View-Editor를 고안해낸 당시, 저자는 Model을 하나 이상의 View에 부착(Attach)시키고 싶었던 것 같다.

- Editor

: 사용자와 View간 인터페이스 역할을 한다.

2.3 Model-View-Controller (1979년 12월 10일)

- Model

: Model은 지식(Knowledge)을 나타낸다. Model은 단일 객체일 수 있고, 객체들의 구조체일 수 있다. Model의 Node는 문제에서 식별가능한 부분으로 나타날 수 있어야 한다. => 말이 좀 어려운데, '문제'가 의미하는 것은 개발로서 해결해야 하는 것으로 생각하면 될 것 같다.

 Model의 Node는 모두 같은 문제 레벨에 있어야 한다. => 이것도 역시 말이 어렵다. 나는, 개발할려는 시스템 또는 시스템의 부분을 여러 Layer로 나눈다고 가정할 때 'Model들은 같은 Layer에 있어야 한다'정도로 이해했다(Robert C Martin의 Clean Archtecture의 Entity Layer에 대한 설명을 보고, 이렇게 생각하게 됬다).

- View

: Model의 시각적 표현. View는 View의 Model에 부착(Attach)되고, Model을 표현하기 위해 Model로부터 Data를 얻는다.

- Controller

: Controller는 사용자와 System을 잇는 역할을 한다. 사용자에게 출력할 것을 적절한 Message로 바꾸어서 하나 이상의 View에 전달한다던지, 화면에 View들을 적절하게 배치하여 사용자에게 입력을 위한 수단을 제공한다던지 해서, Controller는 사용자에게 필요한 입출력 인터페이스를 제공한다.

 Controller는 View를 보완하지 않는 것이 좋다(원 글에선, Controller가 서로 다른 View 끼리 연결을 하지 말라고 하였음). 그리고 View는 사용자의 입력(마우스 동작, 키보드 입력)을 몰라야 한다. 이를 위해, Message를 View로 보내는 Method는 Controller에 구현한다.

- Editor

: Controller는 모든 View에 연결되어 있다. 어떤 View는 Editor라는 특별한 Controller를 제공하는데, Editor는 View에 표시된 정보를 사용자가 수정할 수 있게 한다.

3. 읽은 후, 생각 정리

: The Original은 1979년대에 Trygve Reenskaug가 Xerox에서 사용자를 위한 시스템을 개발할 때, 작성된 글이다. 그래서 The Original MVC에서 제안하는 내용 중 일부는 공감되지 않을 수 있는데, 지금과 그 당시의 시대적 차이를 고려해보자(지금 개발중인 앱과, 당시에 개발중인 시스템의 복잡도는...).

 View와 Model이 부착(Attach)된다고 표현한 것이 조금 아쉬웠다. 요즘은, View가 Model의 존재를 몰라야 한다는 것이 일반적으로 받아들여지기 때문이다.

 Thing-Model-View-Editor에서의 Model과 Model-View-Controller에서 Model에 대한 역할이나 설명이 크게 달라지지 않았는데, 문서에서 설명한 것처럼 Model에서 Data를 다루는 방법도 제공한다면, 이 당시의 Controller는 역할이 방대하지 않았을 것으로 추측된다.

 여담이지만, 일하다보면 ViewController(많은 iOS 개발자들이 MVC의 Controller 역할을 부여함)에서 Network나 Local Database를 통해 Data를 가져오는 코드를 많이 보게 된다. 하지만 The Original MVC에 설명된 내용에 따르면 Data를 다루는 Model의 역할을 Controller에게 넘긴 것으로, Controller의 역할 분배를 잘못한 것으로 볼 수 있지 않을까? 바람직하지 않은 것 같다.

4. Reference

1)Trygve Reenskaug: The original MVC Reports, Oslo, February 12, 2007