모델-뷰-컨트롤러(Model-View-Controller MVC)

컴퓨터 프로그램을 개발하면 흔히 MVC 구조, MVC 패턴,  MVC 아키텍처라는 단어를 많이 듣게 된다. 그리고 그 뒤에 간단한 설명이 뒤 따른다.

 

MVC에서 모델은 애플리케이션의 정보(데이터)를 나타내며, 뷰는 텍스트, 체크박스 항목 등과 같은 사용자 인터페이스 요소를 나타내고, 컨트롤러는 데이터와 비즈니스 로직 사이의 상호동작을 관리한다. (출처-위키피디아)

 

뭐 간단히 정리하면 프로그램을 구성하는 요소들을 데이터, 화면, 컨트롤로 나누어서 각자의 역할을 부여해고, 각자 일에만 충실히 수행하자는 말이된다. 결국 각각이 가진 특징들을 이해해, 구성 요소들이 할일만 구현하면, 다른 요소를 수정하지 않으면서 유지보수가 편해진다고 한다.

 

그런데 직접 개발을 하면서 드는 의구심은 이렇다.

 

- 정말 다른건 수정안해도 되나?
- 각각의 역할이 정확히 뭐지??
- 구성 요소들을 알맞게 분류한게 맞을까?
- 컨트롤이 하는 역할은 어디까지 해야하나?
- 컨트롤하는 역할은 너무 많은데..? 이게 정말 맞는거야?

 

이렇게 수많은 궁금증들이 떠오르곤 한다. 수많은 책에서 MVC 구조라고 말하며, MVC의 구성요소들을 설명하면서 스스로 반성을 해보면 스스로 MVC가 무엇이야? 그리고 어떻게 해야 MVC 구조인거야? 라고 묻지만 단순하게 MVC 구성요소와 그 역할들만 설명할 수 있을 거 같다. 그래서 MVC의 각 구성 요소에 대한 가이드 라인정리 하고자 한다.

 

실제로 MVC 아키텍처로 개발된 Framework를 사용한다며, 소스들의 적절한 위치 및 역할을 지키지 않고 개발된다면, 실제 MVC 구성 요소들의 힘이 제대로 발휘되지 않을 것이다. 결국 다시 코드들을 찾아서 죄다 수정하는 평소로 되돌아 갈테니 말이다.

 

정리에 대한 MVC에 가이드라인은 Eclipse Graphical Editing Framework(GEF)에 대한 개념 설명 글을 바탕으로 작성함을 밝힌다.(GEF의 이해[한글][영문])

 

모델(Model)

---

데이터를 가진 객체를 모델이라 지칭한다.  데이터는 내부에 상태에 대한 정보를 가질 수도 있고, 모델을 표현하는 이름 속성으로 가질 수 있다.

 

모델은 다음 규칙을 가지고 있음을 이해해야 한다.

1) 사용자가 편집하길 원하는 모든 데이터를 가지고 있어야만 한다.

즉, 화면에 네모 박스 안에 글자가 표현 된다면, 네모 박스의 화면 위치 정보, 네모 박스의 크기 정보, 글자 내용, 글자의 위치, 글자의 포멧 정보 등을 가지고 있어야 한다.

 

2) 뷰(View)나 컨트롤러(Controller)에 대해서 어떤 정보도 알지 말이야 한다.

 데이터 변경이 일어 났을때, 모델에서 화면 UI(View)를 직접 조정해서 수정할 수 있도록 뷰를 참조하는 내부 속성값을 가지면 안된다는 말이다.

 

3) 변경이 일어나면, 변경 통지에 대한 처리 방법을 구현해야만 한다.

모델의 속성 중 텍스트 정보가 변경되면, 이벤트를 발생시켜 누군가에게 전달해야 하며, 누군가 모델을 변경하도록 요청하는 이벤트를 보냈을때 이를 수신할 수 있는 처리 방법을 구현해야 한다. 이는 모델이 변경되는 방법을 다른 구성 요소들에게 알려주게 되는 방법이다.

 

 

뷰 (View)

---

화면에 표시되는 글자, 체크박스, 윈도우와 같은 UI라는 시각적 요소를 지칭한다.

 

뷰에서도 다음 규칙을 이해하고, 사용해야 한다.

1) 모델이 가지고 있는 정보를 따로 저장해서는 안된다.

화면에 글자를 표시 하기 위해, 모델 정보를 전달 받게 될텐데, 그 정보를 유지 하기 위해서 임의로 뷰 내부에 저장하면 안된다는 말이다. 단순히 네모 박스를 그리라는 명령을 받으면, 화면에 표시하기만 하고, 그 화면을 그릴때 필요한 정보들은 저장하지 않는 다는 것이다.

 

2) 모델이나 컨트롤러과 같이 다른 구성 요소를 몰라야 된다.

모델과 같이 자기 자신의 빼고는 다른 요소는 참조하거나 어떻게 동작하는지 알아서는 안된다. 그냥 뷰는 데이터를 받으면, 화면에 표시해주는 역할만 가진다고 보면된다. 각자 이기적이라고 보면 된다. '난 화면에만 그리고 그때 쓴 데이터는 쓰레기 통에 버릴꺼야' 하는 이기적인 녀석 말이다.

 

3) 변경이 일어나면, 변경 통지에 대한 처리 방법을 구현해야만 한다.

모델과 같이 변경이 일어났을때 이에 누군가에게 변경을 알려줘야하는 방법을 구현해야 한다. 뷰에서는 화면에서 사용자가 화면에 표시된 내용을 변경하게 되면 이를 모델에게 전달해서, 모델을 변경해야 할 것이다. 그 작업을 하기 위해 변경 통지를 구현한다.

 

뭐 이쯤 읽었으면 이에 대한 처리 방법을 왜 구현해야 하는지 짐작할 수도 있을것이다. 이는 모델이나 뷰에서 변경이 일어났을때, 이를 컨트럴로에게 알리고, 컨트롤러는 어떻게 처리할지 결정해 다시 다른 구성 요소에서 변경을 알려주는 중재자 같은 역할을 위해 변경 통지 관련 처리 방법을 구현하는 이유이다.

 

 

컨트롤러 (Controller)

---

모델과 뷰를 연결해 주는 역할을 한다. 주로 비즈니스 로직(문제를 해결하기 위한 과정)이 이 컨트롤러에서 구현되어 있는 것이다. 음식 재료와 음식을 예를 들면, 음식 재료가 있고 이를 조리법을 이용해 음식을 완성한다고 했을때, 음식 재료들은 데이터가 될터이고, 조리법은 컨트롤러, 그리고 완성된 음식은 뷰로 표현할 수도 있을것 같은데... 예를 들고 보니 조금은 부적절하다는 생각도 들지만, 필자의 지식 수준이 여기까지라고 생각하고 글을 읽어주길 바란다.

 

컨트롤러는 다음 규칙을 이해해야 합니다.

1) 모델이나 뷰에 대해서 알고 있어야 한다.

모델이나 뷰는 서로의 존재를 모르고, 변경을 외부로 알리고, 수신하는 방법만 가지고 있는데, 이를 컨트롤러가 중재하기 위해 모델과 그에 관련된 뷰에 대해서 알고 있어야 합니다.

 

2) 모델이나 뷰의 변경을 모니터링 해야 한다.

모델이나 뷰의 변경을 통지 받으면, 이를 해석해서 각각의 구성 요소에게 통지를 해야 하는것입니다.

 

끝맺음

몇 가지 기준을 세우고, MVC 패턴을 이해하고 사용한다면, 왠만한 Framework를 익히는 기초가 될꺼라 생각됩니다. 사실 '좋은 말 한마디가 천금보다 낫다'는 말처럼 개발자에게는 긴 글 보다 한줄의 코드로 이해하기 쉬울 수도 있을텐데....사실 이 글은 스스로에게 알려주는 글이다 보니, 태생적 한계가 존재하게 되었습니다.

 

요즘 기초적인 부분을 정리하면서 드는 생각들은, 수많은 개발 기술들이 세상에 나오고, 활용 되는 것을 보면, 그 내용들은 기초에서 파생되어 발전된 내용이라는 것을 알게됩니다. 기초는 모르고 써도 되지만, 결국 한계에 다다르지요.