[CS] MVC 패턴 바로알기

들어가며

지난 시간에는 소프트웨어 아키텍처 패턴이 무엇인지 알아보았습니다. 소프트웨어 디자인 패턴을 함께 알아보며, 소프트웨어 설계에서 사용하는 두 패턴의 개념을 잡을 수 있었습니다.

아키텍처 패턴에 관한 이전 포스팅은 아래를 참고해주세요!

[CS] 아키텍처 패턴 딥다이브하기(feat. 디자인 패턴)

 

아키텍처 패턴에 대한 글을 올린 후 MVVM에 관한 글을 마저 작성하려 했습니다만, MVC와 MVP를 떼어놓고 설명하기 어렵다고 판단했습니다. MVVM의 기반이 된 MVC와 MVP 패턴을 먼저 알아두는 것이 좋을 것 같아, MVVM에 앞서 두 패턴에 대해 설명하려 합니다. 미루니 아닙니다.

 

이번 포스팅은 MVC 패턴을 다룹니다.

사실 MVC는 정말 유명하고 많이 사용하는 패턴인 만큼 MVC를 설명하는 글이 많습니다. 저는 기본 정의에 나아가, 어쩌다 MVC가 만들어졌는지 그 배경도 함께 살펴보려 합니다.

 

목차

글은 MVC의 정의와 그 탄생 배경, 장점과 단점, 마지막으로 안드로이드에서는 어떻게 적용되는지 알아보는 순서로 진행됩니다.

1. MVC 패턴
  1.1. 정의
  1.2. 구조
2. 왜 MVC를 사용할까?
  2.1. 탄생 배경
    2.1.1. MVC 패턴 설계 목적
    2.1.2. MVC의 탄생
    2.1.3. 초기 MVC의 구조
  2.2. MVC 패턴의 장점
    2.2.1. 사용자와 프로그램(데이터) 사이 간극 완화
    2.2.2. 유지보수가 용이한 소프트웨어 설계
    2.2.3. 테스트가 용이하도록 구현
    2.2.4. 개발자 간 원활한 커뮤니케이션
3. MVC가 해결하지 못한 문제점
  3.1. MVC의 문제점
    3.1.1. Model-View의 완전한 의존성 분리 불가
    3.1.2. Controller의 역할 과잉 가능성
  3.2. 안드로이드 프레임워크에서는 어떨까?
    3.2.1. Activity(Controller + View)의 역할 과잉
  3.3. MVC의 현재

 

 

1. MVC 패턴

1.1. 정의

Model–view–controller

Model–view–controller - Wikipedia

모델-뷰-컨트롤러

모델-뷰-컨트롤러 - 위키백과, 우리 모두의 백과사전

MVC는 Model-View-Controller 3가지 요소로 구성된 소프트웨어 디자인(또는 아키텍처) 패턴입니다.

소프트웨어에서 서로 관련있는 프로그램 로직(비즈니스, UI 로직 포함)을 모델-뷰-컨트롤러라는 3개의 요소로 분리해 사용자 인터페이스(User Interface, UI)를 개발할 때 사용합니다.

MVC가 디자인 패턴이기도 하면서 아키텍처 패턴인 이유는, 시간이 지나면서 MVC 패턴의 용도와 범위가 디자인 패턴에서 아키텍처 패턴으로 확장되었기 때문입니다. 해당 글에서는 MVC를 디자인 패턴, 아키텍처 패턴 구분 없이 모두를 아울러 설명합니다.
디자인 패턴과 아키텍처 패턴의 차이점을 알고싶으신 분은 이전 포스팅을 참고해주시기 바랍니다.

 

1.2. 구조

MVC 패턴에서 각 구성 요소의 역할은 아래와 같습니다.

1. Model : 도메인, 비즈니스 로직을 추상화하여 나타낸 객체
   • 도메인, 비즈니스 로직과 이에 필요한 데이터를 관리한다.
   • Controller에 의해서 데이터, 이벤트를 전달받거나 변경된다.
2. View : 사용자에게 보여지는 것
   • 사용자가 보고자 하는 정보와 데이터를 보여 준다.
   • 사용자 인터페이스(UI)를 구현한다.
     • 상황, 환경에 따라 사용자 입력을 담당하기도 한다. (e.g. 모바일 환경)
3. Controller : Model과 View 사이 매개체 역할
   • 좀 더 넓은 의미에서는, 사용자와 시스템 사이 매개체 역할을 한다.
   • View를 생성 및 관리한다.
   • 사용자 입력을 받아 처리한다.
     • 사용자 입력을 전달 받아 Model(데이터)에게 넘겨준다.
     • 경우에 따라 Model(데이터)을 직접 변경하기도 한다.
   • 변경된 Model의 값을 View에게 전달한다.
     • 경우에 따라 View가 Model을 직접 관찰하는 경우도 있다. (e.g. Java Swing, AWT의 MVC 구현)

비즈니스 로직 : 컴퓨터 프로그램에서 실세계의 규칙에 따라 데이터를 생성·표시·저장·변경하는 부분 (출처 - 위키백과)

 

 

아래 그림은 MVC 패턴을 구성요소의 특징과 역할에 따라 간단하게 도식화한 것입니다.

(각 구성 요소들이 어떻게 동작한다는 자세한 동작이 아닌, 구성 요소들 간의 관계만을 나타낸 것입니다.)

Smalltalk-80의 MVC 도식화 (출저-위키백과)

 

이 구조를 가진 시스템은 아래와 같은 과정으로 동작합니다.

1. 사용자는 View를 통해 Model의 데이터를 확인합니다.
2. 사용자는 Controller를 이용해 Model을 가공, 변경합니다.
3. Model은 Controller에게서 받은 입력에 따라 값이나 상태를 변경합니다.
4. Model의 변경이 View에게 전달되어, View에서 보여주는 값이 업데이트됩니다.
5. 사용자는 변경된 데이터를 View를 통해 확인합니다.

 

 

2. 왜 MVC를 사용할까?

왜 이러한 구조로 소프트웨어를 설계하는 것일까요?

이전 글에서 알아보았듯, 디자인 패턴은 소프트웨어 개발에서 일반적인 문제를 해결하기 위해 고안된 설계 기법입니다. MVC 패턴이 처음 만들어진 이유도 어떤 문제를 해결하기 위함이었을 것입니다. 당시 문제가 무엇이었고 어떻게 만들어졌는지 그 탄생 배경을 먼저 알아보고, MVC 패턴의 사용 이유 및 장점을 이해해보겠습니다.

 

2.1. 탄생 배경

MVC는 트라이브 린스케이지(Trygve Reenskaug)가 처음으로 고안한 디자인 패턴입니다.

때는 1978년도로 거슬러 올라갑니다.

더 자세한 이야기가 궁금하시다면 아래 문서를 참고해주세요.

Trygve/MVC

2.1.1. MVC 패턴 설계 목적

트라이브 린스케이지(이하 트라이브)는 1978년부터 1년간 제록스 팔로알토 연구소(Xerox PARC)에서 방문 연구원으로 근무했습니다. 당시 그가 속한 팀은 Dynabook과 SmallTalk를 연구하고 있었습니다.

Dynabook은 일종의 휴대용 컴퓨터이며, 아이들을 위한 교육용 기기였습니다. 흡사 태블릿 또는 블랙베리처럼 생겼습니다.

1972년 고안된 Dynabook (출처 - 위키백과)

 

Trygve/MVC - Dynabook에 대한 설명

Very importantly, these data included the programs the owner used to manipulate them. The owner/user should be able to understand and write the programs, thus gaining ascendancy over the computer.

 

이 컴퓨터에는 사용자가 이해하고 조작할 수 있는 프로그램이 담겨야 했습니다. 아무래도 교육용 기기였기 때문에, 아이들도 프로그램을 쉽게 이해하고 사용할 수 있어야 했을 것입니다.

"오잉, 왜 뜬금없이 교육용 기기 이야기인가요?" 🤷‍♂️
➡️ 초기 MVC의 탄생 이유를 알 수 있는 중요한 배경 지식이기 때문입니다!

2.1.2. MVC의 탄생

MVC는 이 당시인 1978년, 트라이브가 SmallTalk 언어 개발에 참여하던 중 처음으로 고안해내며 탄생했습니다.

(다만 처음부터 MVC였던 것은 아니고, 3가지 이외에 Editor라고 하는 구성 요소가 더 존재했다고 합니다.)

Trygve/MVC - MVC의 주요 목적

The essential purpose of MVC is to bridge the gap between the human user's mental model and the digital model that exists in the computer. The ideal MVC solution supports the user illusion of seeing and manipulating the domain information directly.

(중략) MVC was conceived as a general solution to the problem of users controlling a large and complex data set.

 

MVC: 사용자 멘탈 모델과 컴퓨터 디지털 모델을 연결 (출처 - Trygve/MVC)

 

MVC의 원래 주 목적은 사용자 멘탈 모델과 컴퓨터 안에 존재하는 디지털 모델 사이의 간극을 줄이기 위함입니다.

당시 마주한 문제는 사용자가 컴퓨터에 담긴 데이터를 보고 처리하기 어렵다는 것이었습니다.
하긴, GUI도 아닌 CLI 환경에서 데이터를 조작하는건 여간 쉬운 일이 아니겠어요.

트라이브는 이를 해결하고자, 사용자가 크고 복잡한 데이터와 쉽게 상호작용할 수 있는 일반적인 솔루션으로 MVC 패턴을 고안했습니다.

그리하여 누구나, 심지어 아이들도 프로그램을 이해하고 컴퓨터의 데이터를 조작할 수 있도록 프로그램을 설계하고자 했을 것입니다.

2.1.3. 초기 MVC의 구조(글에서 제거될 수 있음)

초기 MVC는 Thing-Model-View-Editor 로 구성된 구조였습니다.

• Thing: 사용자가 관심있어하는 추상적인 무언가
  • 도메인과 비슷한 개념으로 이해해도 좋을 것 같습니다.
• Model: 컴퓨터 시스템에서 표현되는 데이터와 이를 처리하는 로직의 집합
  • Thing을 추상화하는 유용한 방법이라고 설명합니다.
• View: 단일 또는 그 이상의 Model을 보여주는 역할
• Editor: View와 사용자 사이에 존재하는 인터페이스
  • 메뉴와 같은 명령 집합을 제공하며, View를 화면에 구성하고 위치시킵니다.
  • 현재의 Controller와 비슷한 역할입니다.

이후 MVC와 Editor가 조합된 구조가 되었다가(여기서 Editor는 키보드, 마우스와 같은 입력 장치와 View 사이를 상호작용하는 특수한 Controller 역할을 합니다.), Smalltalk 개발자들과 논의한 끝에 지금과 같은 구조가 되었습니다. 나아가 트라이브는 Tool 이라는 개념을 추가로 도입하기도 했습니다.

• Tool: 하나 이상의 Editor(View+Controller)를 포함하며, 사용자에게 특정 작업 수행을 제공하는 역할

 

2.2. MVC 패턴의 장점

2.2.1. 사용자와 프로그램(데이터) 사이 간극 완화

위에서 이야기했듯, MVC는 사용자와 시스템의 Model(데이터 등)을 연결해주는 구조로, 사용자가 시스템을 쉽게 이해하고 조작할 수 있도록 하는 목적으로 설계되었습니다.

따라서 MVC를 적용하면 사용자에게 친화적인 시스템을 설계하는데 용이할 수 있습니다.

Tryve/MVC - MVC에 대한 설명

The ideal MVC solution supports the user illusion of seeing and manipulating the domain information directly.

이상적인 MVC 솔루션은 사용자가 직접 데이터(도메인)를 바라보고 조작하고 있다는 착각이 들게 만든다.

2.2.2. 유지보수가 용이한 소프트웨어 설계

MVC는 소프트웨어의 비즈니스 로직을 화면에 출력하는 로직과 분리하여, 각각의 관심사(화면 입출력, 비즈니스 로직)에 따라 시스템을 관리할 수 있습니다. 이는 객체와 구성 요소 간 결합도를 낮추어 유지보수가 편리한 시스템을 설계할 수 있도록 도와줍니다. 이로써 View를 다른 곳에서 재사용할 수 있고, 기능이나 화면의 추가가 유리해져 확장성을 높입니다.

MVC - MDN Web Docs 용어 사전: 웹 용어 정의 | MDN

MVC - MDN Web Docs 용어 사전: 웹 용어 정의 | MDN

소프트웨어의 비즈니스 로직과 화면을 구분하는데 중점을 두고 있습니다. 이러한 "관심사 분리" 는 더 나은 업무의 분리와 향상된 관리를 제공합니다.

안드로이드에는 MVC 아키텍처 패턴이 없다

안드로이드에는 MVC 아키텍처 패턴이 없다

Controller(이하 컨트롤러)에 의해서 View(이하 뷰)와 Model(이하 모델)가 소통하는 구조로 되어 있어서 뷰와 모델의 의존성을 제거할 수 있다. 이렇게 분리하면 각각의 책임이 명확해진다. 코드 설계를 이해하기 쉬워지고 그만큼 유지보수에도 용이하다.

2.2.3. 테스트가 용이하도록 구현

시스템의 비즈니스 로직과 사용자 인터페이스가 얽혀있지 않고 분리되었기 때문에 테스트 작성이 용이해집니다.

Model의 단위 테스트와 Controller의 통합 테스트, View의 UI 테스트로 나누어서 작성 가능합니다.

2.2.4. 개발자 간 커뮤니케이션 원활

팀 단위로 개발할 때, MVC 패턴 사용을 합의하면 효율적인 개발을 이어갈 수 있습니다.

새로운 기능을 추가하는 상황에서도 MVC 패턴에 따라 개발을 진행하면 되므로 빠른 구현이 가능합니다.

대부분의 코드가 동일한 구조에 따라 동작하므로 다른 팀원이 담당했던 코드도 이해가 빠릅니다. 또한 MVC 패턴은 널리 알려진 아키텍처(및 디자인) 패턴이기에, 팀에 처음 합류한 신입 개발자도 시스템 구조와 동작 방식을 이해하는데 도움이 됩니다.

---

 

이렇듯 MVC는 사용자와 컴퓨터 시스템을 가까이 연결해주려는 목적으로 최초 설계되었고, 시간이 흐르며 상황과 환경에 따라 다양한 변화를 거쳐왔습니다. 대표적 예로, 트라이브가 남긴 MVC에 대한 문서에 존재하던 Editor와 Tool이란 개념이 현재는 사용되지 않습니다.

 

점차 GUI 환경의 컴퓨터와 기기가 상용화되었고, 나아가 웹 브라우저 개발에서도 활용되면서 MVC 패턴이 인기가 많아지고 대중화되었습니다. 비교적 단순하면서 간단한 구현 방식이고, Model과 View의 분리로 유지보수가 용이하다는 점 때문에 지금까지도 널리 사용하는 패턴인 것 같습니다.

 

 

3. MVC가 해결하지 못한 문제점

MVC는 여러 장점을 가지고 있지만, MVC도 여전히 해결해주지 못한 문제들이 있습니다.

3.1. MVC의 문제점

3.1.1. Model-View의 완전한 의존성 분리 불가

Model과 View의 의존성을 완전히 분리시키기 어렵습니다. Model과 View는 Controller를 통해 소통하는데, 어째서 의존성이 남아있다는 것일까요?

일반적으로 View는 Controller와 연결되어 화면을 구성하며, Model은 Controller를 통해 View와 연결됩니다. 복잡한 구조의 애플리케이션은 하나의 Controller에 여러 개의 View와 Model이 연결됩니다. 즉, 한 요소에 발생한 수정이 다른 구성 요소에 영향을 끼칠 가능성이 높습니다.

따라서 시스템의 규모가 커지거나 복잡해질수록 Model과 View 사이의 의존성이 강하게 연결될 수 있습니다.

3.1.2. Controller의 역할 과잉 가능성

규모가 크고 복잡한 프로젝트의 경우, 한 Controller 안에 너무 많은 Model과 View가 들어갈 수 있습니다. 이에 Controller가 하는 역할이 너무 많아져 유지보수가 어려워질 수 있습니다. 이런 문제점으로 인해, MVC 패턴은 Massive-View-Controller 라고 놀림을 받기도 합니다.

Massive-View-Controller 란?
대규모 MVC 애플리케이션에서 나타날 수 있는 현상입니다. 복잡하고 많은 수의 화면을 구성하는 시스템에서는, View를 관리하고 데이터를 전달해주는 Controller가 겉잡을 수 없이 복잡해집니다. Controller는 복잡한 View를 주로 다루는 ViewController로 의미가 퇴색되어버리고 그 크기와 복잡성이 증가하기 때문에, MVC는 Massive한 ViewController라는 문제가 있다고 비판받기도 합니다. 이렇듯 규모가 크고 복잡한 애플리케이션의 경우 Controller가 비대해지는 것을 피하기 어렵습니다.
관련 링크: https://www.infoq.com/news/2014/05/facebook-mvc-flux/

 

3.2. 안드로이드 프레임워크에서는 어떨까?

안드로이드 시스템에서 MVC를 적용하면 어떻게 될까요?

안드로이드 애플리케이션 개발에서는 Controller에 대한 문제점이 더욱 명확해집니다.

3.2.1. Activity(Controller + View)의 역할 과잉

안드로이드 에서는 XML과 Activity로 화면을 구성합니다. 특히 Activity는 View 객체를 생성하고, 입출력을 관리하는 역할을 합니다.

• 입력에 대한 동작을 관리한다.
  • 이벤트 리스너를 등록하여, 입력에 대한 동작을 수행한다. (e.g. onClickListener 등)
  • 키보드 입력에 따른 데이터 처리를 담당한다. (e.g. TextWatcher 구현 등)
• 데이터 출력을 담당한다.
  • View에게 화면에 보여줄 데이터를 전달한다.

즉, Activity는 이미 Controller의 역할을 수행합니다.

또한 Activity는 단순 화면 구성 뿐 아니라, 테마 변경, View의 속성 변경 등 전반적인 UI 로직도 수행할 수 있습니다. 사실상 Activity는 View의 역할도 수행한다고 볼 수 있습니다.

안드로이드 프레임워크에서 Activity는 View인 동시에 Controller이므로, 어쩌면 MVC가 아니라 Model-Activity 패턴이나 Model-Tool 패턴으로 봐야할지도 모르겠습니다.

어쩌면 Activity는 초창기 MVC에서 Tool의 역할을 하는 것이 아닐까?

 

심지어 두 가지 막중한 역할 이외에도 Activity는 여전히 하는 일이 많습니다.

• 생명주기 관리
• Context 접근 및 필요한 리소스 관리
• Application, Service, Activity 등 Android System의 구성요소와 상호작용

이렇듯 Activity가 하는 역할이 많아짐에 따라, Model-View 간 의존성을 없애기 어려워지고, Activity가 비대해져 유지보수가 매우 힘들어집니다.

이런 문제점들은 안드로이드 뿐 아니라 iOS와 같은 모바일 개발 환경에서 특히 치명적으로 나타났습니다.

 

3.3. MVC의 현재

위와 같은 문제점들을 해결하고자, MVC로부터 파생된 여러가지 패턴이 탄생했습니다. 대표적으로는 MVP, MVVM 등이 있습니다. MVP는 비대해지는 Controller(또는 Activity)의 역할을 줄여주어 문제를 해결하고자 했고, MVVM은 View와 Controller(MVP에서는 Presenter) 사이의 깊은 연결 고리를 끊어내고자 했습니다. 두 패턴은 특히 위에서 언급한 문제점으로 인해, 현재 안드로이드 개발(또는 iOS)에서 활발히 사용되고 있습니다.

그럼에도 MVC는 지금도 자주 활용되고 있습니다. MVC는 View가 복잡하지 않은 시스템에서는 너무나 유용한 아키텍처(디자인) 패턴입니다. 현재 Massive-View-Controller 라고 불리며 놀림을 받는 이유는 시간이 지나고 시대가 변함에 따라 시스템의 규모가 점점 커졌기 때문입니다. 덩치가 큰 시스템을 관리하는 경우 MVC 보다는 다른 아키텍처와 디자인 패턴을 적용하는 것이 좋지만, 아직 규모가 크지 않거나 비교적 간단한 프로그램을 만든다면 MVC 패턴은 오히려 좋은 선택이 될 것입니다.

여러 단점이 존재하고 오래된 패턴이라고 해서 무작정 기피하거나 나쁘다고 바라보는 것은 옳지 않은 것 같습니다. MVC는 시간이 지나고 상황이 바뀌면서 구조가 조금씩 바뀌고 다양한 패턴이 파생된 것 뿐, 필요한 상황에서는 MVC는 여전히 뛰어난 아키텍처 패턴입니다.

 

---

마치며

오늘은 MVC 패턴에 대해 알아보았습니다.

MVC는 Model-View-Controller라는 3개의 관심사로 소프트웨어를 분리하는 설계 방식이며, 사용자가 편리하고 쉽게 조작할 수 있는 시스템 구조를 위해 만들어졌습니다.

유지보수와 테스트 용이, 편리한 개발 방식 등 다양한 장점이 있으나, 시스템이 복잡해지면 Controller가 비대해져 오히려 유지보수가 어려워진다는 문제점이 있습니다.

 

간단하게 개념 위주로 짚고 넘어가고자 했지만, MVC의 탄생 배경과 본래 설계 이유를 함께 살펴보다보니 내용이 많아졌습니다.  사실 더 다루고싶은 내용이 있으나, 글이 너무 길어지고 주제와 멀어질 것 같아, 나중에 기회가 되면 자세히 다뤄보겠습니다.

다음 포스팅은 MVP 패턴에 대해 다뤄보겠습니다.

 

참조

https://en.wikipedia.org/wiki/Model–view–controller

https://ko.wikipedia.org/wiki/모델-뷰-컨트롤러

제임스의 블로그 - 안드로이드에는 MVC 아키텍처 패턴이 없다

여기도 MVC, 저기도 MVC! MVC 패턴이 뭐야?

https://folk.universitetetioslo.no/trygver/themes/mvc/mvc-index.html

https://developer.mozilla.org/ko/docs/Glossary/MVC