제가 이해한게 맞는지 궁금합니다.

솔직히,, MVC나 MVP나 MVVM이나 머가 그렇게 다른지 잘 이해가 안가긴합니다..

모델과 뷰를 분리하고 이를 컨트롤하는 영역을 어떻게 처리하면 좋을까 하는데서 조금씩 차이가 있어서 구분하려는게 목적인 걸까요. 뷰모델이라 한다해도 처리해야할 복잡성이 올라가면 결국 복잡해지는 건 똑같아 보입니다.. 그럼에도 불구하고 UIKit을 사용할 때 NVVM을 쓸라고 하는건 테스트가 용이하다는 이유랑, 그냥 옵저버 패턴 쓰고 싶어서인 것 같습니다. Combine이 나온 것도 뭔가 너네가 옵저버 방식 좋아하는 것 같으니까 만들었어 같은 느낌인 것 같고,,

SwiftUI를 공부하면서 보니까 자연스럽게 Combine 쓰게되고 쓰다보니 자연스레 아래처럼 구조가 분리되는 것 같은데 이게 NVVM이 맞는 걸까요?

뷰(들어오는 데이터 대로 그려지는 뷰 구조체 모음)
모델(타입 or 인터페이스 모음)
로직(뷰의 로직 처리 함수모음)
스토어(상태 데이터모음)

안녕하세요.

아키텍처 패턴을 공부하다보면 한번쯤은 'MVC랑 MVP랑 MVVM이랑 결국 뭐가 다른거지?'라는 의문에 빠지는게 당연하다고 생각합니다. 국내에서 유명한 회사(ex. 네카라쿠배) 출신 개발자들도 발표하는 내용들을 보면 Passive View를 구현해놓고 MVC나 MVVM이라고 말하는 경우도 많아서 다른 자료들까지 보셨다면 더 혼란스러웠을 것 같습니다.

제가 강의에서 설명한 바와 같이 GUI 아키텍처들의 근간에는 PDS라는 사상이 있고, 이 사상에 따라 P를 View로 D를 Model로 환원할 수 있습니다. 여기까지는 대부분이 문제없이 이해하나, 혼란의 원인이 되는 것은 M과 V의 뒤에 붙는 C(Controller), P(Presenter), VM(ViewModel)입니다.

제가 강의 내에서 지속적으로 개발환경에 따른 차이를 강조하며 다양한 개발환경에서 존재했던 패턴들을 설명한 내용이 기억나실지 모르겠습니다. 그렇게 했던것은 C, P, VM 간의 차이를 이해하려면 결국 개발환경에 따른 차이를 이해하지 않고서는 그 차이를 구별할 수 없기 때문입니다. 초기에 Controller가 등장했던 Smalltalk 환경에서는 Controller가 유저의 입력장치(마우스, 키보드 등)로부터 들어오는 입력을 해석해주는 Input Controller였습니다.

하지만 Presenter가 등장한 Taligent나 Dolphin 등의 개발환경에서는 Smalltalk와 같은 IC를 도저히 구현할 수 없었기 때문에 다른 형태의 아키텍처를 고안할 수 밖에 없었고, 그 결과 새로운 명칭의 아키텍처가 등장한 것입니다.

ViewModel은 WPF를 설계한 아키텍트들의 의도에 맞게 디자이너들이 쉽게 접근할 수 있는 View 개발환경을 만들고, 이것을 어떻게 프로그래머들이 작업한 결과물들과 연결시킬 수 있을까라는 문제의식에서 탄생한 것입니다. 그렇다고 꼭 이름을 바꿔야 했는지, 아니면 다른 문제의식에서 탄생한만큼 이름이 다른 것이 당연하다라고 말해야 할지는 모르겠습니다.

디자이너와 프로그래머가 협업해야 한다면 뷰를 최대한 프로그래밍 지식이 없어도 개발할 수 있는 환경으로 만들어줘야 하며(ex. 마크업 랭귀지), 동시에 프로그래머가 작업해야 하는 별도의 공간을 만들어줘야 합니다. 이렇게 서로 분리된 개발환경을 연결가능하게 만들어주는 것이 데이터 바인딩(Data Binding)입니다. MVVM의 두드러지는 특징이 데이터 바인딩인만큼 이 점을 꼭 기억해주셨으면 합니다.

말씀하신 것처럼 해결해야 하는 문제가 많아지면 복잡성은 올라갈 수밖에 없습니다. 이것은 특정 아키텍처 선정만으로는 근본적으로 해소할 수 없는 문제입니다. 다만 아키텍처 패턴이 애플리케이션에 일정한 규칙을 부여함으로써 기존 코드를 파악하거나 새로운 코드를 작성할 때, 어떤 방식으로 되어 있는지 그리고 어떻게 작성해야 하는지 부담을 덜어주는 정도의 역할은 할 수 있습니다.

질문에 작성하신 형태만 보고는 MVVM인지 아닌지 파악이 어렵습니다. 일단 전역 상태를 관리하는 용도로 Store를 두는 것은 MVC에 있었던 Dependents와 유사하며 MVVM과는 상관이 없습니다. 그리고 뷰와 관련된 로직을 어디에서 처리하고 있는지는 모르겠습니다만, 만약 해당작업들을 처리하기 위해 ViewModel을 만들어 View와 데이터 바인딩으로 연결한다면 어느 정도는 MVVM과 닮아있다고 말할 수는 있다고 생각합니다.

하지만 여기서도 반드시 고민해보셨으면 하는 것은 UIKit이나 SwiftUI의 뷰(UIViewController, View)를 WPF의 XAML 같은 마크업 랭귀지로 작성된 뷰처럼 개발해야 할 이유가 무엇인가라는 점입니다. 유별나게 iOS 개발자들은 Reactive Programming을 좋아하는 사람들이 많고, 그러한 사람들이 자신들이 개발하는 방식을 MVVM이라고 부르는 경우들을 많이 보곤 합니다.

하지만 본래 MVVM과 Reactive Programming은 상관이 없습니다. Rx도 마찬가지로 마이크로소프트의 개발환경(.NET)에서 만들어진 것이지만 WPF나 Silverlight에서는 MVVM을 구현하기 위해 Rx를 쓰지 않습니다. 게다가 WPF의 아키텍트인 John Gossman은 옵저버 패턴을 활용하는 방식들에 대하여 부정적인 의견을 밝히기도 했습니다. 그런 방식에 부정적이었기 때문에 시스템에 내장된 데이터 바인딩 엔진을 만든 것이기도 합니다. 반면에 Rx는 태생부터 Iterator Pattern, Observer Pattern, Functional Programming의 영향을 강하게 받은 것이기에 오히려 본래의 MVVM의 맥락과는 배치된다고 저는 생각합니다.

답변이 되었나 모르겠습니다. 추가적인 질문이 있으면 코멘트 남겨주시면 되겠습니다.

인프런 커뮤니티 질문&답변