[iOS] 우리가 몰랐던 진짜 MVC이야기(2)

이번글은 지난 글인 우리가몰랐던진짜MVC이야기(1)에 이은 두번째글입니다
실질적인 MVC에대한 이야기는 지난 글에서 마무리지었고 이번글은 MVC에서 파생된 MVP그리고 MVVM에 대한 이야기를 진행하며 마무리할것 같습니다

이번글도 마찬가지로 나름 열심히 노력해서 많이 정보를 수집하고 정리했지만 당연히 틀린부분 혹은 다른 의견이 있을수있기때문에 언제든지 태클 혹은 토론의 여지가있는 의견이 생긴다면 계속해서 수정해나갈 예정입니다

---

Testable의 중요성 대두

이전 블로그를 보신분들이라면 MVC라고 했을때 애플의 Cocoa MVC를 떠올리시게될겁니다. 마지막으로 소개한 MVC니까요ㅎㅎ.. 하지만 지금부터는 MVC라고 하면 Cocoa MVC 대신 전통적인 MVC(small talk MVC)를 떠올려주시면 좋을거같습니다. 그 이유도 뒤에서 설명드릴게요!

아무튼 MVC라는 GUI아키텍처를 통해서 개발자들은 복잡한 혹은 어려운 문제를 풀고 만들어나갈때 Model View Controller라는 계층을 통해 해결해나갈 수 있었습니다. 그런데 문제가 발생합니다. 기존의 MVC는 View와 Model이 observable디자인패턴으로 소통을 하기때문에 객체가 완전히 분리되어있지 않았습니다. 당연히 재사용성이 떨어지는문제가 생기고 가장큰 문제는 테스트하기가 참 어렵다는거였습니다

(혹시나 헷갈리시는 분들을 위해 전통적인 MVC를 가져와봤습니다)

초기 MVC는 세가지 계층이 어떤식으로든 참조를 하고있었기때문에(완전히 분리가 되어있지 않았기때문에) 테스트하기가 참 어려웠습니다

그리고 view의 상태를 controller에다가 둬야할지 view에다가 둬야할지도 정해진게없었습니다(예를들어 button이 보여지는 상태변수를 view에다 둬야하는지 controller에다 둬야하는지가 정해지지않은거죠)

어떤 개발환경은(어떤언어는이 나은표현일수있겠네요) view가 상태변수를 가지고있어도 그 상태를 추적해서 UI를 그릴수있어서 view에다가 둘수도 있지만 그렇지 않은 개발환경에서는 view의상태 변수를 view가들고있으면 안되는 경우도 있었을겁니다

그리고 동시에 시간이지나면서 어플리케이션이 점점더 복잡해지고 고도화되면서 테스트의중요성이 대두되기 시작합니다.

즉, 당시에 MVC에서 해결해야할 가장 큰 문제는 MVC가 테스트하는데 어려운 아키텍처라는점이었습니다

그래서 당시 개발자들은 이런생각을 합니다

1. 지금 MVC가 테스터블하지않은 이유는 View와 Model이 완전히 분리되지않아서가 아닐까?
2. 만약에 테스트가 가능한 관계로 만들면 UI는 테스트하기 어려우니까 테스트 가능한 객체에다가 view의 상태관련 코드를 모아놓으면 되는게아닐까?

그래서 이런 생각들을 통해 기존 MVC구조를 변형시키는 구조들이 몇가지 등장하게됩니다

Passive View

그중에서도 해당 문제를 모두 해결한 방식이 있었는데 Passive view의 등장입니다
GUI아키텍처에대해 공부하다보면 매번 언급되는 마틴파울러의 Passive View의 글을 보면 passive view에 관한 자세한 내용을 알 수 있습니다

1. MVC의 변형

이 패턴은 MVC의 또 다른 변형이라고 이야기합니다.
Passive View라는 개념의 중요한 점은 3가지가 있습니다

1. view가 완전히 수동적이라는것(그래서 passive라는 접두사가 붙었습니다), 오로지 view의 변화는 controller로부터 온다는것
2. view는 더이상 model로부터 자체적인 업데이트가 불가능하다는것
3. view의 변화는 controller로부터오는 수동적인뷰이기때문에 뷰의 상태로직이 전부 controller에 있다는 것

2. 테스트 가능성

Passive View를 사용하는 주요 이유는 테스트 가능성을 높이기 위한 것입니다.

뷰가 완전히 수동적인 역할이 된다면 뷰를 테스트하지 않아도 괜찮다고 이야기합니다. 이말은 우리가 controller를 잘 테스트한다면 어차피 view는 controller에 의해서만 랜더링되기때문에 view테스트가 없어도 된다는거죠

---

MVP의 등장

결론적으로 기존 MVC구조에서 좀더 테스터블한 구조로의 변경에대한 필요성이 생겼고 그결과 여러 변형중 Passive View라는 개념이 많은 동의를 받아서 Controller라는 계층이 Presenter라는 계층으로 대체된 MVP라는 디자인패턴이 등장하게 됩니다

MVP구조를 보면 presenter가 View를 inferface로 들고있기때문에 mocking이 용이하고 view와 presenter가 강하게결합되어있지않기때문에 presenter테스트가 용이해진 구조라고 볼 수 있습니다

그리고 기존 MVC는 Model의 변화를 옵저버패턴으로 View에게 알려줘 View가 새로운 값으로 랜더링이 가능했습니다. 어떤 action의 결과로 model이 변하면 presenter를 거치지 않아도 view가 바뀔수있었죠

근데 MVP와서는 presenter에 의해서만 바뀌는 완전히 수동적인 view가 되었기때문에 presenter에의한 수동 바인딩을 통해서만 view가 바뀔수있게되었습니다

MVC와 MVP의 차이는 이렇게 정리해볼수있습니다

MVC와 MVP의 차이

1. MVC는 View와 Model이 관찰자패턴으로 소통이 가능해 testable하지 않지만 MVP는 view와 Model이 완전분리되어있고 Presenter(Controller)와도 interface로 연결되어있어 mocking이 가능해 testable한 아키텍처이다
2. MVC는 View가 Model의 변화에 반응해 랜더링할수있었지만 MVP는 View가 완전히 Passive해져 Presenter의 요구없이는 데이터변경에도 랜더링이 안된다. 따라서 presenter가 view에게 명령을 내리는 방식이 수동적으로 구현이되어야한다
   즉, 모든 변화에 전부 delegate나 setter를 구현해줘 view에게 알려줘야하기에 구현하는 코드자체가 많아질 수 있다

Cocoa MVC...?

제가 처음에 MVC에대해 이야기할떄 Cocoa MVC를 떠올리지 말아주세요라고 이야기했던 이유는 MVP에대한 정리가 끝나고 이야기를 하고 싶었기 때문입니다. 분명히 MVP관련 내용을 보시고 이런 생각이 드신분도 있을겁니다

이거 Cocoa MVC랑 계층구조가 똑같은데...?

맞습니다. 솔직히 Cocoa MVC와 Passive View의 MVP의 형태가 거의 일치하는걸 알 수 있습니다

그리고 실제로 동작하는 방식도 생각을 해보면 어떤 모델이 바뀌면 didset같은걸로 controller가 새로 view를 그리라고 명령을 하죠. 동작방식도 어떤 관점에서는 MVP와 유사한 측면이 많습니다

그런데 왜 애플은 본인들이 새로정의한 아키텍처를 MVP가 아니라 MVC라고 했을까요?

(여기서부턴 제 개인적이 뇌피셜입니다! 언제든지 반박해주셔도 좋습니다ㅎㅎ)
어떤 현상의 결과는 그 현상의 원인이라고 볼수는 없다고 생각합니다. 결과적으로 MVP라는 아키텍처의 동작형태만보면 애플의 Cocoa MVC와 많이 많이 비슷하다고볼수있습니다

하지만 MVP가 나오게된, 등장하게된 배경과 이유중 가장 큰 이유는 테스트가능한 구조의 필요성이었습니다. 결국 MVP구조입니다라고 하기위해서는 적어도 MVP가 해결하려한 테스트가능한 아키텍처, 그중에서도 controller역할을하는 계층이 테스트가 가능해야한다라는 가정을 무조건 만족해야합니다

하지만 애플의 ViewController는 view자체를 강한결합으로 가지고 있다는점 view자체를 소유하고있기때문에 controller자체가 UI와 결합되어있어서 controller 계층이 테스트가능해야한다는 MVP라고 보기는 어렵다는결론을 내리지 않았을까하는 생각을 하게되었습니다

물론 View와 Model을 완전히 분리함으로써 view자체의 재사용성을 높이긴했지만 이건 MVP가 해결하고자하는 핵심 문제는 아니었습니다. 그래서 MVC에서 문제인 view의 재사용성은 애플에서도 중요하다고 생각해 controller를 mediating controller로 정의한 MVC의 변형이다라고 발표한게아닐까요?

MVC의 또 다른 변형, Presentation Model

MVC의 문제인 View와 Model이 의존관계를 가지고 있다는 문제와 특수한 경우 View의 상태로직을 view가 표현하지 못하는 환경에서 이 로직들을 어떤 계층에 둬야하는가라는 문제가 있었습니다

지금까지는 이러한 문제를 해결하게해준 MVC의 변형인 MVP에 대해 말씀드렸었지만 MVP의 경우에 문제로 지적받는 부분이 한가지 있습니다

바로 View와 Presenter간의 의존성입니다

view에서 유저의 input이 들어오면 view는 presenter에게 알려야합니다
view는 presenter에 의존하게됩니다

반대는 어떨까요 presenter가 input을 해석해서 model을 변경하고 그변경에따른 view의 변경을 위해 view에게 명령을 해야합니다. UI를 수동으로 업데이트해야합니다
presentre는 view에 의존하게됩니다

두 계층이 의존관계에 있게됩니다. 좀더 쉽게말해서 view는 presenter를 알아야하고 presenter는 view를 알아야합니다

MVC의 변형중에는 presentation model이라는 변형패턴이 존재했습니다. 이 패턴은 MVC의 문제인 View와 Model이 의존관계를 가지고 있다는 문제와 특수한 경우 View의 상태로직을 view가 표현하지 못하는 환경에서 이 로직들을 어떤 계층에 둬야하는가를 해결할 수 있는 패턴이었습니다

이 패턴이 MVP에 비해 가지는 장점은 view와 presentation model사이에 의존성이 없다는겁니다

왜 view와 presentation Model사이에는 의존성이 없나요?

-> presentation model은 view를 추상화한 객체이기때문입니다
해당 내용에대해서 의미를 이해할수있는 블로그글을 가져와보겠습니다(원문이 궁금하다면)
ViewModel을 presentation model이라고 바꿔읽으시면됩니다

원문 내용
ViewModel은 View를 추상화한 것이라고 했다. 그리고 이것이 ViewModel의 핵심 개념이라고 얘기했다.
View를 추상화 했다.... 이거 어떤 의미 일까? 개발에서 일반적으로 추상화라는 단어를 사용한다면, 특히 C# 이라는 언어에서 사용한다면 abstract 키워드를 이용한 클래스와 멤버를 작성하는 정도라고 느낌이 올 것이다. 하지만 여기서 추상화란 좀 더 원론적인 개념에 가깝다고 보면된다.
말 그대로 어떤 실체가 있는 대상을 두고 그 속성이나 기능들을 쪼개고 분리해 구체적인 실체를 숨기고 그 구체적 실체 속에 녹아있는 성격을 정리하는 것이라고 설명할 수 있다. 그리고 이 성격의 표현은 다형성 측면에서도 유사한 성격을 가진 실체들이 공유하거나 이용할 수 있다. 좀 더 쉬운 예를 들어 이야기 해보자면 어떤 View를 형태와 실체가 있는 대상이라고 본다면 ViewModel은 그 View가 가진 속성(Property)이나 행위(Behavior), 동작(Command) 따위만을 뽑아내서 정리하고 유지하는 클래스 정도라고 할 수 있다.
그리고 이것은 비단 View가 가지는 UI 적인 속성만이 아닌, View가 표현해내고 의미를 가지게 되는 Model의 속성을 가지는 것도 함께 의미한다. 이것이 View의 추상화라는 개념을 간단히 훑어내는 수준의 정리이다.
그렇기 때문에 이렇게 추상화된 View, 즉 ViewModel은 구체적인 View와 특별한 의존성을 가지지 않게 되는 것이고 다형성 측면에서도 View 가 ViewModel의 형식에 대한 의존성을 가지지 않을 수 있게 되는 것이다. 왜냐하면 View는 특별한 형식이 아닌 단지 추상화된 내용만을 가진 ViewModel 을 사용하게 되고 어떤 위치라도 ViewModel은 그냥 ViewModel로서 의존성 없이 존재할 수 있게 되기 때문이다.
이러한 표현이 너무 어렵다면 반대로 접근해보면 해답이 보일 수도 있다. 그러니까 ViewModel이 View의 추상화라는 것보다 이미 만들어진 ViewModel이 특별한 View를 통해 구체화될 수 있다 라는 개념으로 받아들이면 ViewModel이 결국 상대적으로 View를 추상화 했다 것과 같은 개념이라고 말할 수 있게된다.
이전에는 controller계층이 view를 직접 업데이트해줘야해서 view에 뭐가있는지 알아야했다면 presentation model이라는 controller계층은 그냥 값을 바꾸기만 하면 시스템단에서 제공해주는 data binding을통해 view가 값이 바뀐걸 알아채고 알아서 UI를 업데이트할수있게됩니다

프레젠테이션 모델에 대해 궁금하다면? 이 글을 참고해주세요

그러면 이제부턴 view와 controller 계층의 의존관계가 있는게 무슨 문제가 있었는지에대해서 알아보겠습니다

개발자와 디자이너의 병렬작업

예전에 UI작업은 개발자의 역할이아니었던 시절이있었다고 합니다...허허

근데 당연히 디자이너는 전문 개발자가 아니기에 UI작업코드에 복잡한 로직을 포함시킬수는 없었을겁니다. 그런건 개발자의 영역이었을테니까요

결국 디자이너가 UI를 그리고 개발자가 로직을 짜는 작업이 병렬적으로 이뤄지기위해서는 두계층 UI계층과 로직계층의 의존관계가 없었어야했을겁니다

디자이너입장

👩🏻‍🎨 모르겠고 UI코드를 짜고 바뀌는건 이 변수바뀌면 UI바뀐다고 명시만 해줘야겠다

개발자입장

🧑🏻‍💻 UI는 모르겠고 이런 동작이 들어오면 이 변수를 바꾸면되겠다
(짜피 시스템이 이변수 바뀌면 이 변수 바뀌었다고 view계층에게 알려줄테니까)

만약에 두 계층에 의존관계가 있다면

디자이너입장

👩🏻‍🎨 유저가 버튼을 누르면 로직 계층에다가 보내줘야겠다(여긴 문제없음)

개발자입장

🧑🏻‍💻 디자이너님 이 변수 바뀌면 UI바꿔야하는데 그 바뀌는쪽 UI코드 다 짯어요?
👩🏻‍🎨 아니요.. 아직 못짰어요 ㅠㅠ
🧑🏻‍💻 디자이너님이 완성해주셔야 코드가 완성될거같은데요 ㅠㅠ

이런 상황이 되겠죠 아마도 병렬적으로 개발이 될거같지는 않습니다. 그래서 이 상황에서 두계층관계에 의존관계가 없는 프레젠테이션 모델 패턴이 선택되게됩니다. 물론 이렇게 프레젠테이션모델패턴이 유의미했던이유는 당시환경에서 데이터바인딩을 제공해줬기때문이었을겁니다

그럼 이런 환경에서 중요한건 결국 view와 controller가 서로 의존하지 않아야합니다
MVP는 안타깝게도 View와 Presenter가 서로 의존하고 있기때문에 이런 상황에서 적합하지 않습니다
그래서 View와 Controller역할을하는 계층간에 의존관계가 없는 MVC의 presentation model이 적합하다는 생각을 했을수도 있습니다(옛날일이라서 그랬을수도있겠다고 말하는게 맞을것같네요 ㅎㅎ...)

MVVM의 등장

마이크로 소프트가 말하는 MVVM의 등장배경이 궁금하다면?

지금부터는 제 뇌피셜이 아닌 실제 마이크로소프트에있는 MVVM의 역사에 관한 위 글을 요약정리해보겠습니다

---

2004년에 Martin Fowler는 프레젠테이션 모델(PM)이라는 패턴에 관한 기사를 발표했습니다. PM 패턴은 뷰를 해당 동작 및 상태와 분리한다는 점에서 MVP와 유사했습니다.

-> 다만 위에서말했던것처럼 MVP는 View와 Presenter가 수동으로 binding을 해야하기에 두 계층간에 강한 의존성을 가지고 있지만 PM의 경우엔 presentation model과 view사이에 의존성이 없습니다. MVP에 비해서 디자이너와 개발자사이의 병렬작업에는 두 계층의 의존성이없는 PM이 적절한 아키텍쳐였던거죠

---

PM 패턴의 흥미로운 부분은 프레젠테이션 모델이라고 불리는 뷰의 추상화가 생성된다는 것입니다. 그러면 뷰는 단순히 프레젠테이션 모델의 렌더링이 됩니다.

-> 위의 왜 view와 presentation Model사이에는 의존성이 없나요?와 동일한 내용입니다

---

2005년 현재 Microsoft의 WPF 및 Silverlight 설계자 중 한 명인 John Gossman은 자신의 블로그에서 MVVM(Model-View-ViewModel) 패턴을 공개했습니다 . MVVM은 Fowler의 프레젠테이션 모델과 동일합니다. 두 패턴 모두 뷰의 상태와 동작을 포함하는 뷰의 추상화를 특징으로 합니다. Fowler는 UI 플랫폼 독립적인 뷰 추상화를 생성하는 수단으로 프레젠테이션 모델을 도입한 반면, Gossman은 WPF의 핵심 기능을 활용하여 사용자 인터페이스 생성을 단순화하는 표준화된 방법으로 MVVM을 도입했습니다. 그런 의미에서 저는 MVVM이 WPF 및 Silverlight 플랫폼에 맞게 맞춤 제작된 보다 일반적인 PM 패턴의 전문화라고 생각합니다.

-> MVVM은 presentation model과 동일한 아키텍처라고합니다 그래서 presentation model의 이름이 viewmodel로 바뀐거라고 볼수도 있죠

---

결국 MVVM은 MVC의 presentatiom model과 동일한 아키텍처이며 해결하고자한 문제는 view와 controller역할의 계층과 의존성을 분리하고자 했던것입니다

근데 좀 여기서 의문이 들수도있습니다

아니 근데 아얘의존성이 없으면 애초에 아얘 서로 모른다는건데 그러면 어떤 방식의 데이터전달이 불가능한거아닌가요?

View와 ViewModel 간 의존성을 제거하기 위해 MVVM 패턴이 도입되었지만 연결하기 위해서는 어떠한 형태로든 ViewModel 에 대한 정보를 알아야만 합니다. 그러나 특정 View나 ViewModel이 타입에 대한 의존성을 만들면 그 또한 패턴에 위배되는 것이므로 불특정 타입에 대한 의존성을 느슨하게 결합할 수 있는 형태의 그 무언가가 필요했을겁니다

그리고 이 결합을 위한 도구로 Binding이 등장하게됩니다 view가 viewmodel 자체에 의존하는것이 아닌(이러면 두 계층간에 의존성이생겨버리니까) viewmodel의 property의 binding을 이용해 view와 소통할수있게됩니다

즉 view는 viewmodel과 소통한다고 보기보다는 view의 추상화(viewmodel)의 한 문맥(property)와 소통하는 관계다라고 볼수있습니다

(디자이너입장에서는 개발자가 만들어야할viewmodel이 뭔지는 몰라도 어떤 변수가있느지만 알면 된다 그리고 개발자는 viewmodel을 만들떄 그 변수만 넣어서 구성하면된다 이런식이면 병렬작업이가능한 의존관계가된다 이렇게 생각해도 괜찮지 않을까요?)

---

MVP의 Presenter와 달리 ViewModel에는 뷰에 대한 참조가 필요하지 않습니다. 뷰는 ViewModel의 속성에 바인딩되어 모델 객체에 포함된 데이터와 뷰에 특정한 기타 상태를 노출합니다. ViewModel 객체가 뷰의 DataContext로 설정되기 때문에 뷰와 ViewModel 간의 바인딩은 구성하기가 간단합니다.

-> view와 viewmodel의 연관성에 대한이야기입니다. 위에서말했듯 view와 viewmodel은 데이터의 전달을 위한 최소한의 의존성은 있어야하는데 이는 Data context를 통한 binding이라고 이야기합니다

---

뷰는 모델이 존재하는지 전혀 모르고, ViewModel과 모델은 뷰를 모릅니다. 실제로 모델은 ViewModel과 뷰를 모릅니다. 이는 매우 느슨하게 결합된 디자인으로 여러 면에서 이점을 제공합니다.

-> 이 설명는 View가 ViewModel을 소유하고 있고 ViewModel이 Model을 소유하고있는 그림을 연상케합니다

그럼에도 불구하고 MVVM?

자 이제 iOS에서의 MVVM에대해서 고민해보면 좋을것같습니다

1. MVVM은 애초에 디자이너와 개발자간의 병렬적인 작업을 위해 만들어졌습니다
2. 당시 시스템은 간편한 binding을 통해 view와 view의 추상화객체간의 의존성을 부여했습니다

iOS개발에서 우리는 디자이너와 개발자간의 병렬적인 작업이 필요한가요? 아마도 아닐겁니다. 양보해서 UI작업과 UI관련 로직을 병렬적으로 하고싶다고 할수는 있습니다. 누군가는 UI를 짜고 누군가는 로직을짜고싶을수있죠. 굳이 디자이너와 개발자가 아니더라도 말이죠. 그러면 1번 항복은 어찌저찌 넘어갈 수 있습니다

다음은 시스템(여기서는 swift겠네요)이 간편한 data binding을 제공하나요? 만약에 모든 로직에 delegate와 notification center를 사용한다면 어떨까요 생각만해도 좀 쉽지않을것같습니다. 오히려 코드가 훨씬 복잡해지고 어려울수도있습니다 delegate는 ARC를 신경써야하고 notification center를 사용하면 해제시점을 고려해야합니다. 두 도구 모두 데이터바인딩을 할때 가장먼저 떠오르는등 편하게 쓸만한 친구는아닙니다

combine이 있다고 할수있겠지만, combine은 애초에 애플 공식문서에서 비동기처리를 위한 프레임워크라고 말하고있습니다 data binding용도로 잘쓰고있지만 툴자체가 data binding을 위한 툴은아닙니다. 하지만 그럼에도 불구하고 combine이 나 rxswift를 쓰면 data binding이 가능은 하니 2번도 좀 찜찜하지만 그럴수있다정도로 넘어갈만 합니다

delegate혹은 notification center로는 데이터바인딩이 쉽지않다라고 하면 MVVM은 애초에 combine이나 rxswift를 다루지못하면 의미를 가지기 어려운 아키텍처라고 말하는사람들도 있습니다. 그렇기때문에 iOS에서 일반적인 제네릭한 아키텍처라고 보기어렵다고 생각합니다

마무리

우리는 왜 MVVM을 쓰는가에대해서 고민을 해봐야한다는 생각이들어서 인터넷에 존재하는 많은 글들을 봤고 정리했습니다 그러다보니 제가 태어났을때의 문서까지 들여다보며 공부했네요 ㅎㅎ...

지금까지 MVC부터 MVVM까지의 역사를 보면 MVVM은 MVC의 발전된 버전이 아닙니다. 그저 파생된 다른 하나의 MVC였죠

누군가가 말하는 MVC가 Massive하다는건 애플의 cocoa MVC 특성상 어쩔수없었던것이었고 애플이 예상못한 부분은 아니었습니다(uiviewcontroller의 역할을 보면 알 수 있죠) 과연 이게 진짜 문제라고 말할수있는걸까요?

MVC에 문제가있어서 MVVM이라는 발전된 아키텍처가 생긴건 더더욱 아니었습니다. 다만 매번 MVC를 적용하기 어려운 순간이나 부분이생겨 그 부분을 포용하기위해 MVC의 변형된 버전이 생겨났을뿐인겁니다

MVC와 MVVM에대한 공부를 하면서 이 두 아키텍처에대한 결론을 내리겠다는 그런 안일한생각은 점점 하지않게되었습니다ㅎㅎ... 그저 제가 공부한 내용을 제대로 정리하고 전달해드리기위한 긴시간과 노력을 들여 공부를 했다고 생각합니다.

어떤 아키텍처를 선택해야할까에 대한 결론은 개발을 하는 모든 분들이 각자 내려야한다고 생각이 들었습니다. 그리고 그 결론을 내리는데 있어서 정리한 역사(?)의 흐름이 조금이나마 도움이 되었으면 좋겠네요:)

MVVM에 대한 사용을 멈추자!를 이야기하자는건 아닙니다! 다만 자주 듣는 MVC로하면 ViewController가 Massive해진다니까 이걸 해결해주는 MVVM을 쓰자!는 맹목적인 믿음은 위험할수도있다는 제 생각을 전달하고싶었습니다

이번 주제는 여기서 마무리해보려합니다
글을쓰다보니 두서없었을수있는데 끝까지 읽어주셔서 감사합니다
수정과 추가에는 언제든지 열려있으니 피드백은 환영입니다:)

그럼20000!