들어가며
모바일 애플리케이션을 개발을 하다보면 소프트웨어 아키텍쳐 패턴이라는 것을 접하게 되고, 특히 모바일 앱의 경우 MVC, MVP, MVVM 패턴이라는 것을 접하게 됩니다. 오늘은 MVC, MVP, MVVM 패턴에 대해서 알아보고 장단점을 간단하게 정리해보겠습니다.
소프트웨어 아키텍쳐 패턴이란?
어떠한 프로젝트에 대한 문제를 정의한 후 이러한 문제에 대한 솔루션을 위해서 아무런 설계도 하지 않은 상태에서 구현만을 위한 코드를 작성한다고 해봅시다.
코드는 아무런 제약 조건도 존재하지 않기에 작성자가 본인의 철학, 스타일, 그리고 구현만을 위해 작성한 코드는 코드 작성자도 수일이 지나면 코드를 읽는데 큰 어려움을 겪을 수 있습니다. 특히나, 프로젝트의 규모가 크면 클수록 이러한 문제가 더 빈번히 발생할 것이고, 팀 프로젝트인 경우 팀원들의 코드 스타일의 맞추어 코드를 각각 해석해야 되는 경우도 발생할 것입니다.
이러한 경우 코드 유지보수작업 또는 인수인계과정에서 비용이 크게 발생할 수 있겠죠. 그리고 신규 기능을 추가하기 위해 새로운 코드를 작성할 때에도 큰 어려움이 생길 것입니다.
아무래도 이러한 문제점을 미리 방지하기 위해서는 코드 작성 가이드라인을 만들거나 팀원 간의 코드 스타일 통일화, 그리고 확장성 및 유지보수성, 가독성, 테스트성 등을 고려하게 됩니다.
이러한 문제를 해결하기 위해서 소프트웨어 아키텍쳐 패턴이라는 것이 등장했습니다. 소프트웨어 아키텍쳐 패턴을 통해서 개발자간의 코드를 쉽게 공유할 수 있으며, 이미 소프트웨어 아키텍쳐 패턴은 수많은 시간동안 다양한 개발자들에 의해 고안되고 검증이 진행되었기에 또 다른 프로젝트에도 기존 프로젝트의 코드를 사용하는 등 재사용성 또한 크게 증가됩니다.
MVC, MVP, MVVM 패턴
소프트웨어 아키텍쳐 패턴은 여러 종류가 있습니다. 하지만, 모바일 애플리케이션에서는 기본적으로 MVC, MVP, MVVM 패턴을 이해하는 것이 중요하다고 생각합니다. 가장 오래전부터 사용된 MVC 패턴부터 단점들을 개선하기 위해 등장한 MVP, MVVM 패턴을 이해한다면 프로젝트 또는 실무에서 소스코드 분석 및 구현에서 큰 도움이 될 것입니다.
MVC 패턴
MVC 패턴은 가장 대중적으로 많이 사용되는 소프트웨어 아키텍쳐 패턴으로 모델(Model), 뷰(View), 컨트롤러(Controller)로 분리하여 소프트웨어를 개발하는 아키텍쳐 패턴입니다.
- 모델(Model) : 뷰의 표현되는 데이터입니다. 그리고 사용자의 입력에 따른 이벤트 비즈니스 로직을 담당하는 클래스의 집합입니다.
- 뷰(View) : 사용자에게 보여지는 UI입니다. 데이터의 변경을 전달받아 변경 데이터를 조회하여 UI를 갱신합니다.
- 컨트롤러(Controller) : 사용자의 입력을 전달받아 처리합니다. 모델과 뷰의 연결을 담당합니다.
- 장점 : 가장 단순하고 오랫동안 사용된 패턴으로 여러 분야에서 사용하기에 많은 자료가 존재합니다.
- 단점 : 프로젝트의 규모가 커질수록 모델과 뷰의 의존성이 점점 높아집니다.
MVP 패턴
MVP 패턴은 MVC 패턴의 단점을 최소화하기 위해 탄생한 아키텍쳐 패턴으로 모델(Model), 뷰(View), 프레젠터(Prasenter)로 분리하여 개발합니다. 프레젠터는 뷰에서 필요한 데이터를 준비하고, 사용자 입력을 처리하지만, 뷰는 단순히 데이터를 표시하는 역할을 맡습니다.
- 모델(Model) : 뷰의 표현되는 데이터입니다. 사용자의 입력에 따른 비즈니스 로직을 포함합니다.
- 뷰(View) : 사용자에게 보여지는 UI입니다. 뷰는 데이터의 변화를 감지하고 변경된 데이터를 조회합니다.
- 프레젠터(Presenter) : 사용자의 입력을 뷰로부터 전달받아 처리합니다. 그리고 모델 뿐만 아니라 뷰도 함께 갱신하는 역할을 담당하여 뷰와 모델의 의존성을 낮춥니다.
- 장점 : MVC의 단점을 보완한 아키텍쳐 패턴입니다. 모델과 뷰의 의존성이 MVC 패턴보다 낮습니다.
- 단점 : 프로젝트의 규모가 커질수록 뷰와 프레젠터와의 의존성이 높아집니다.
MVVM 패턴
MVC, MVP 패턴의 단점을 보완하기 위해서 가장 최근에 등장한 아키텍쳐 패턴으로 모델(Model), 뷰(View), 뷰 모델(ViewModel)로 분리하여 개발합니다. 모델과 뷰는 MVC, MVP와 동일한 역할을 담당하며, 뷰 모델은 뷰와 1:N 관계를 맺게 되어 뷰모델은 어떤 뷰가 자신을 참조하는지 알 수 없고, 뷰와의 완전한 독립적인 관계를 맺게 됩니다.
- 모델(Model) : 뷰의 표현되는 데이터입니다. 사용자의 입력에 따른 비즈니스 로직을 포함합니다.
- 뷰(View) : 사용자에게 보여지는 UI입니다. 뷰는 데이터의 변화를 감지하고 UI를 갱신합니다.
- 뷰 모델(ViewModel) : 사용자의 입력을 뷰로부터 전달받아 모델을 갱신시키고 데이터를 전달받습니다. 이러한 변화를 뷰가 감지하여 UI를 갱신합니다. 뷰와의 1:N 관계를 맺기 때문에 뷰로부터 독립됩니다.
- 장점 : 각각의 의존성이 굉장히 낮고 명확한 역할을 담당합니다.
- 단점 : 뷰모델의 설계가 복잡해지고, 초보자는 쉽게 접근하기 어렵습니다.
