프론트엔드 웹애플리케이션 아키텍쳐 비교분석 : MVC와 MVVM

개요

함수와 객체가 미시적인 수준까지 코드 재사용과 모듈 방식을 허용해 개발자의 효율성을 높인 것처럼, 애플리케이션 아키텍처는 거시적인 수준에서 방대한 코드의 상호작용을 정리하거나 추상화하거나 제한해 개발팀의 효율성을 높였다.

본 보고서는 현재 널리 쓰이는 자바스크립트 애플리케이션 아키텍처를 개략적으로 살펴보고 센차가 지원하는 최신 애플리케이션 아키텍처인 모델-뷰-뷰모델(MVVM)을 심층 분석하고자 한다.

소개

센차 Ext JS 프레임워크는 종합적인 위젯 라이브러리, 강력한 데이터 패키지와 견고한 툴링을 갖춘 덕분에 기업형 웹 애플리케이션 개발에 있어 업계 표준이 되었다. 확장성이 높고 커스터마이징이 쉬운 Ext JS는 포춘 지가 선정한 100대 기업의 60%와 전 세계 200만 이상의 개발자가 사용하고 있다.

2007년 Ext JS 1.0이 처음 출시된 후로, 이 업계는 여러 면에서 달라졌다. 웹 애플리케이션은 그 어느 때보다 규모가 크고 더 복잡해졌다. 2010년 센차는 터치 1.0를 통해 모델-뷰-컨트롤러 패턴(MVC)을 지원하는 자바스크립트 프레임워크를 업계 최초로 선보이고 대기업의 웹 애플리케이션이 자주 직면하는 문제들을 처리했다. 뒤이어 2011년에는 그 기능을 Ext JS 4.0에 적용해 새로워진 기업형 웹 앱의 애플리케이션 코드를 정리하도록 도왔다.

최근 센차는 MVVM 아키텍처 패턴을 최적 지원하는 Ext JS 5.0을 출시했다. Ext JS 5에는 양방향 데이터 바인딩과 선언적 환경설정 같은 기능이 포함되었다. 기업형 웹 애플리케이션은 유형이 무척 다양하므로 성공을 보장하기 위해서는 무조건 프로젝트 초기에 올바른 아키텍처를 선택해야 한다. 기업형 웹 애플리케이션 구축에 자주 쓰이는 자바스크립트 프레임워크 가운데서도 MVC와 MVVM을 동시에 지원하는 Ext JS 5는 가장 유연하다고 할 수 있다.

기업형 애플리케이션의 진화

초창기 인터넷은 단순한 HTML 페이지들이 링크로 연결된 것에 불과했다. “웹 애플리케이션”이라는 용어는 아직 존재하지도 않았다. 웹 기술(브라우저, 툴링은 물론 다듬어지지 않은 언어로 작성된 명세서까지)은 오늘날 우리가 아는 “애플리케이션”을 전혀 예측할 수 없었기 때문이다.

자바스크립트는 1995년부터 폼 필드 유효성 검사와 이미지 롤오버 정도에 유용하게 쓰이기 시작했다. 당시 많이 사용하던 서버 측 언어(CGI, PHP, ASP, 콜드퓨전Cold Fusion 등)은 정적인 HTML 페이지를 전송했다. 사용자가 링크를 클릭하거나 폼을 작성할 때마다 서버는 완전히 새로운 페이지를 뱉어냈다. 포토샵 같은 도구를 이용해 그래픽 디자이너가 만든 아주 멋진 웹사이트에서도 제대로 된 기능이나 상호작용은 찾아볼 수 없었다.

약간의 자바스크립트는 DOM 노드에 기본적인 기능을 부여할 뿐이었다. HTML 마크업과 자바스크립트 코드는 같은 파일에 존재했다. 이렇게 코드가 체계 없이 엉망이니 종종 메모리 누수가 나타날 수밖에 없었다.

브라우저 전쟁: 1995-2008

이러한 웹 페이지 아키텍처는 새로운 브라우저들이 등장하고 기술이 발전하며 전반적인 인터넷 연결이 빨라지며 바뀌기 시작했다.

1995년: 인터넷 익스플로러 1.0이 출시되었고 유일한 경쟁자는 넷스케이프 내비게이터 1.0뿐이었다.
2003년: 애플이 사파리를 최초로 출시했다.
2004년: 모질라가 파이어폭스를 최초로 출시했다.
2006년: 제이쿼리가 전 세계 시장에 처음 등장했다.
2007년: 애플이 진정한 최초의 “모바일” 브라우저가 탑재된 아이폰 1세대를 출시했다.
2008년: 구글이 크롬을 최초로 출시했다.

브라우저가 늘어나면서 일관성 있는 웹사이트를 전달하기는 더 힘들어졌다. 자바스크립트와 렌더링 엔진이 제각각이었기 때문이다. 그래서 브라우저 간의 차이를 막기 위해 새로운 자바스크립트 라이브러리가 몇 가지 등장했다. 모든 플랫폼에 통하는 코드를 작성해야 한다고 느낀 개발자들은 제이쿼리jQuery, 프로토타입 Prototype, YUI를 모두 애용했다.

자바스크립트와 AJAX의 부상

새로운 브라우저마다 보이는 행동은 달랐지만 브라우저 전쟁은 모든 브라우저에 새로운 기능을 추가하고 성능을 개선했다는 성과를 올렸다. 모든 브라우저가 CSS 명세서 등을 동일하게 구현하지 않았지만 대부분 같은 작업을 할 수 있다는 사실을 변하지 않았다.

하지만 2005년 2월 구글 맵스(일반 대중을 겨냥한 최초의 에이잭스 애플리케이션)가 나온 직후, 인터넷은 백팔십도 달라지기 시작했다. 과거의 월드와이드웹은 정적인 웹 페이지가 대부분이었다. 하지만 이제 “웹 애플리케이션” 제작 방식과 관련한 패러다임은 완전히 바뀌었다.

에이잭스를 사용하자 서버에서 페이지를 완전히 재렌더링할 필요가 없었다. 그 대신 클라이언트 측 애플리케이션이 서버 API와 REST 엔드포인트에 직접 데이터를 요청하고 DOM을 직접 관리했다.

2006년 즈음, 기업들은 웹의 잠재력을 깨달았다. 기업의 웹사이트는 더 이상 정적으로 상품을 나열하는 목록이 아니었다. 웹사이트가 곧 상품이 되었고 고객은 어디서든 기업의 애플리케이션에 로그인할 수 있기를 기대했다.

인터넷의 목적이 변하기 시작하자 그 웹사이트를 만드는 개발팀의 목적도 바뀌었다. 디자인에 인터랙션과 비즈니스 논리를 더해 애플리케이션을 만들 수 있는 숙련된 개발자들이 나타나며 그래픽 디자이너의 수가 늘어났다.

하지만 이상하게도 새로운 웹 애플리케이션의 근본적인 코드는 불과 몇 해 전 정적인 웹사이트에서 봤던 코드와 큰 차이가 없었다.

HTML 페이지는 프레임, 폼의 군살을 제거했다. 에이잭스가 부상하며 HTML 파일의 크기는 실제로 줄어들기 시작했다. 클라이언트 측 애플리케이션이 서버 API와 REST 엔드포인트에서 직접 데이터를 요청할 수 있기 때문이다.

자바스크립트는 더 많은 DOM을 관리했다. 제이쿼리 같은 라이브러리가 있었기에 여러 브라우저에 맞는 앱을 만드는 수고를 상당히 줄어들었다는 사실은 틀림없다. 하지만 여전히 코드의 대부분은 체계가 없었다. 자바스크립트는 아직도 DOM 노트에 붙어 있었고 자주 메모리 누수를 유발했다. 모든 논리를 하나의 파일에 쑤셔 넣는 바람에 크기만 크고 뒤죽박죽인 스파게티 코드가 나왔고, 난해하게 연결된 메서드 탓에 코드를 관리하기도 힘들었다.

애플리케이션 크기가 작고 웹사이트가 단순하다면 아키텍처를 이해하기 어려워도 골치만 조금 아플 뿐, 일을 그르칠 정도는 아니었다. 하지만 기업형 애플리케이션 얘기라면 아주 큰 문제였다.

대기업은 새로운 브라우저와 새로운 웹 기술을 신속하게 채택하지 않았다. 하지만 애플리케이션을 웹으로 옮기면서 제이쿼리 같은 라이브러리로는 대규모 애플리케이션을 구축할 때의 문제를 해결할 수 없다는 것을 알아차렸다.

제이쿼리의 에이잭스/CSS 유틸리티는 분명 유용했다. 하지만 자바스크립트 아키텍처가 아예 존재하지 않아 개발과 장기 유지 면에서 많은 문제가 나타났다. 메모리 누수로 애플리케이션이 제 기능을 하지 못했고, 기능을 추가하려면 몇 주가 아니라 몇 달씩 걸렸다. 새내기 개발자에게 예전의 코드를 가르치기도 불가능했다. 간단히 말해, 기존의 자바스크립트 라이브러리를 이용해서는 기업형 웹 애플리케이션의 규모를 확장할 수 없었다.

그리고 대기업은 애플리케이션 구축 방법을 표준화해야 했다. 일관성 있는 API와 서버 측 아키텍처는 개발과 유지 비용을 절감했다. 하지만 클라이언트 측에는 그런 것들이 없었기에 기업은 마땅한 방법을 찾으려고 애를 썼다.

기업은 웹 애플리케이션의 질서를 잡아줄 해결책이 절실히 필요했다. 물론 정말로 앱의 규모가 큰 기업은 엉망진창인 코드를 정리해야 했지만 그에 못지 않게 일관성 있는 애플리케이션 구축 패러다임이 필요했다. 여러 개발팀에 두루 교육이 가능하고 새로운 기능이 추가될 때마다 확장되는 패러다임 말이다.

2007년 4월 Ext JS 1.0이 출시되었다. 위와 같은 기업의 문제를 해결하려는 최초의 자바스크립트 프레임워크였다.

Ext JS는 2006년 초 YUI 라이브러리(“yui-ext”라고 부름)의 확장 기능으로 출발했지만 이내 독립적인 라이브러리로 성장했다. 당시에는 나머지 자바스크립트 라이브러리처럼 Ext JS 1.0도 위젯 라이브러리. 그것을 이용해 개발자는 모든 브라우저에 일관적으로 기능하는 리치 인터넷 애플리케이션을 만들 수 있었다. 그러다 2007년 하반기에 독립적인 프레임워크가 된 Ext JS 2.0은 더 많은 위젯, 더 우수한 도큐멘테이션과 모범 사례, 자체 베이스 크로스 브라우저 추상화 계층까지 포함했다.

2007년의 Ext JS는 다른 자바스크립트 라이브러리와 아주 달랐다. Ext JS는 임의의 자바스크립트를 DOM 노드에 부착하는 대신, HTML이 아닌 자바스크립트에 개발의 초점을 맞추며 웹 애플리케이션에 객체 지향적 프로그래밍과 계승으로 접근했다. 이로써 애플리케이션 프로그래밍의 개념화가 가능해져 끝도 없던 클로저와 스파게티 코드의 패러다임을 끝내고 메모리 누수도 뿌리를 뽑았다.

Ext JS에서 가장 혁신적인 부분은 컴포넌트 생명주기 였다. 프레임워크 위젯마다 고유의 생명주기가 있어서 개발자는 커스텀 이벤트로 손쉽게 컴포넌트 상태를 수정할 수 있게 되었다. 컴포넌트가 사라지면 이벤트 논리가 적절하게 청소되기 때문에 메모리 누수를 걱정할 일이 없어졌다. 컴포넌트가 DOM에 긴밀히 연결되지 않아 이제 개발자는 HTML와 자바스크립트의 스파게티 코드 관리보다는 기능 추가에 더 많은 시간을 쏟았다.

2009년에 출시된 Ext JS 3.0은 REST 커뮤니케이션, 차트 만들기 패키지, 더 많은 위젯을 완벽하게 지원했다. 2011년 센차는 MVC 아키텍처를 지원하고 데이터 패키지를 수정하고 차트 라이브러리를 점검해 Ext JS 4.0를 내놓았다. 단지 센차 프레임워크에 국한되지 않고 다른 프레임워크와 비교해서도 그야말로 혁명적인 사건이었다. 왜냐하면 Ext JS는 기업형 웹 애플리케이션의 문제를 바로잡고자 하는 최초의 해결책이었기 때문이다.

2014: Ext JS 5

Ext JS 5 출시를 맞이해 센차는 전략을 조금 바꾸었다. 고객이 기존 앱에 들인 노력을 허무하게 만들지 않는 선에서 기업형 애플리케이션의 요구를 충족하는 제품을 신중히 제작하고 싶었다.

한편으로는 Ext JS 5가 Ext JS 4의 MVC 아키텍처로 구축한 애플리케이션과 완전히 후방 호환되기를 바랐다. 또 한편으로는 개발자의 생산성을 높이고 코드를 덜 복잡하게 만들고 싶었다. 바로 그 목적으로 센차는 MVVM 아키텍처 지원을 추가한 것이다.

요약하자면 지난 몇 년 간 Ext JS는 진화를 거듭하며 기업형 웹 애플리케이션의 아키텍처 문제를 해결하게 도왔다. 지금부터 MVC와 MVVM 패턴을 더 심층적으로 분석하며 Ext JS가 어떤 문제를 해결하는지 상세히 알아볼 것이다.

MVC와 MVVM 이해하기

애플리케이션 아키텍처는 실제 클래스와 프레임워크 코드로 애플리케이션에 구조와 일관성을 제공한다. 우수한 아키텍처를 구축하면 몇 가지 중요한 혜택을 누릴 수 있다.

모든 애플리케이션이 동일하게 작동하므로 한 번만 배우면 된다.
여러 앱이 어렵지 않게 코드를 공유한다. 모두 같은 방식으로 작동하기 때문이다.
개발자들이 서로 중복되고 상충되는 기능을 만들기 어려워졌다.

이런 혜택은 개발팀의 규모가 크고 다양한 대기업(전 세계에 수백 명의 개발자가 있을 가능성 높다)에 특히 중요하다. 이런 “팀”들은 수시로 바뀌고 프로젝트 기간도 짧게는 몇 주에서 길게는 몇 년까지 다양하다. 그러니 소프트웨어 개발 주기에 많은 시간과 비용을 투자하는 기업은 애플리케이션 구축을 표준화하고 싶은 것이 당연하다.

애플리케이션 아키텍처 패턴은 여러 가지 있지만 지난 몇 년 동안에는 MVC와 MVVM 두 가지가웹 개발에 가장 많이 사용되었었다. 언뜻 비슷하지만 둘은 미묘하게 서로 다르다. 그 차이를 제대로 이해하지 않으면 애플리케이션의 아키텍처가 엄청나게 달라질 위험이 있다.

우선 MVC와 MVVM이 무엇인지 설명한 후, 기업이 Ext JS 5로 어떻게 특정한 아키텍처 문제를 해결하는지 살펴볼까 한다.

MVC란 무엇인가?

모델-뷰-컨트롤러(MVC)는 소프트웨어를 만드는 아키텍처 패턴이다. 애플리케이션의 사용자 인터페이스를 세 가지로 뚜렷하게 나눔으로써 기능에 따라 코드베이스를 정리해 정보를 논리적으로 표시하게 돕는 역할을 한다.

원래 1970년대에 고안된 MVC는 최초로 프로그램의 부분마다 “역할” 개념을 도입해 소프트웨어를 만들려 했다. 처음 도입된 이후 MVC는 진화하며 여러 가지 변형(예: MVP, MVVM 등)을 낳았다.

이렇듯 형태가 다양해졌기 때문에 MVC가 정확히 무엇으로 구성되었느냐에 의견이 분분하다. 하지만 핵심은 다음과 같다.

모델: 애플리케이션에 사용되는 데이터의 일반적인 포맷이다. 비즈니스 규칙, 유효성 검사 논리, 그 밖의 다양한 기능을 포함할 수도 있다.
뷰: 사용자에게 데이터를 나타낸다. 다수의 뷰는 같은 모델 데이터를 다양하게 표시할 수 있다(예: 차트와 그리드).
컨트롤러: MVC 애플리케이션의 핵심이다. 애플리케이션의 이벤트를 리스닝해 모델과 뷰 사이의 명령을 위임한다.

MVC 아키텍처에서 프로그램의 모든 객체는 모델, 뷰, 컨트롤러 중 하나이다. 사용자는 뷰와 상호작용을 하고 뷰는 모델에 있는 데이터를 표시한다. 컨트롤러는 이런 상호작용을 감시하며 필요할 때 뷰와 모델을 업데이트한다.

업데이트 지시는 전적으로 컨트롤러의 역할이기 때문에 뷰와 모델은 서로를 대부분 인식하지 못한다. 대개 뷰에는 비즈니스 논리를 아주 소수 들어 있고, 모델은 데이터의 단순한 인터페이스이다. 그 말은 MVC 애플리케이션 내에서 컨트롤러가 애플리케이선 논리를 거의 다 갖고 있다는 뜻이다.

MVC 아키텍처로 웹 애플리케이션을 만들 때 최고의 장점은 스파게티 코드로 가득한 방대한 파일이 나올 리 없다는 것이다. MVC 는 애플리케이션 각 부분의 역할을 분명히 정의하려 한다. 모든 클래스(예: 모든 파일)마다 분명히 정의된 역할이 있기 때문에 더 큰 환경은 관심을 두지 않는다. 그 덕에 앱의 테스트와 유지가 더 쉬워지고 코드를 재사용할 수 있다.

MVVM은 무엇인가?

모델-뷰-뷰모델(MVVM)은 소프트웨어를 만드는 또 다른 아키텍처 패턴이고 MVC 패턴에 크게 의존한다. MVVM은 모든 비즈니스 논리와 GUI 환경설정이 명백하게 분리된 마틴 파울러의 프레젠테이션 모델 디자인 패턴을 특수화하자는 계획으로 탄생했다.

MVC와 MVVM의 결정적인 차이를 꼽자면 MVVM에는 뷰의 추상화 기능(뷰모델)이 있다는 것이다. 뷰모델은 모델의 데이터와 뷰의 데이터 표시 사이의 변화(예: 데이터 바인딩)를 관리한다. 예전의 MVC 애플리케이션에서는 관리하기 힘들었던 부분이다.

그 결과 뷰를 직접 조작하는 애플리케이션 논리가 최소화되거나 아예 사라져 모델과 프레임워크가 최대한 많은 작업을 할 수 있다.

MVVM 패턴은 다음과 같이 구성된다.

모델: MVC 패턴처럼 애플리케이션에서 사용하는 데이터의 일반적인 포맷을 말한다.
뷰: MVC 패턴처럼 사용자에게 데이터를 표시한다.
뷰모델: 뷰와 관련 모델 사이의 변화를 조정하는 뷰의 추상적인 개념이다. MVC 패턴에서 는 특수 컨트롤러의 역할이었지만 MVVM에서는 해당 뷰가 사용하는 데이터 바인딩과 공식을 뷰모델이 직접 관리한다.

Ext JS 6의 MVC와 MVVM

이론으로 MVC와 MVVC를 간단히 설명했으니 이제 센차 애플리케이션이 MVC와 MVVM을 어떻게 구현하는지 이야기하려 한다. MVC의 단점은 무엇이고 MVVM가 이런 문제를 어떻게 해결하는지도 살펴볼 것이다.

Ext JS의 MVC

클라이언트 측 vs. 서버 측

기업은 아파치 스트럿츠Apache Struts와 ASP.NET MVC 같은 서버 측 프레임워크로 성공을 거두었다. 그래서 센차도 이 패러다임을 따라 MVC에 접근했다. 하지만 MVC와 MVP, 관련 아키텍처 패턴에 대한 설명을 읽다 보면 분명해지는 사실이 있다. MVC에 대해 모든 이가 동의하는 한 가지 정의는 없다는 것이다.

2011년 센차가 Ext JS 4에 MVC를 처음 지원했을 때, 예상했던 대로 초기에는 혼란이 있었다. Ext JS는 클라이언트 측 애플리케이션 프레임워크이다. 따라서 센차 “애플리케이션”은 전통적인 서버 측 아키텍처를 따라 “뷰” 안에서 작동된다.

센차 프레임워크는 서버 측과 무관하기 때문에 센차는 “서버에 대한 아키텍처”에서 “클라이언트에 대한 아키텍처”의 개념을 분리하려 했다. 궁극적으로 센차 애플리케이션은 프로젝트의 하위 계층에 관심을 두지 않기 때문이다.

Ext JS 애플리케이션 아키텍처

Ext JS는 웹 애플리케이션 개발에 보편적인 소프트웨어 플랫폼 역할을 한다는 점에서 진정한 “프레임워크”이다. 애플리케이션 코드를 구조화하는 아키텍처 패러다임일 뿐만 아니라 여러 가지 확장 가능한 위젯과 유틸리티로 데이터를 조작한다. 프레임워크가 애플리케이션 생명주기를 통제하기 때문에 개발자는 프로그램의 기능에 집중할 수 있다.

Ext JS의 MVC 애플리케이션에서는 특정한 클래스가 컨트롤러(Ext.app.Controller)와 모델(Ext.data.Model)을 관리하지만 뷰는 프레임워크의 위젯(전부 Ext.Component에서 상속)을 확장해 정의한다.

MVC 애플리케이션의 모델, 뷰와 컨트롤러는 분명하게 정의된 명명 규칙을 따르고(예: MyApp.model.User) 이 이름은 파일시스템 안에서의 위치와 관련이 있다(예: ~/app/model/User.js).

Ext JS 프레임워크는 실시간으로 모든 애플리케이션 종속성을 동적 로딩한다(배포를 위해 선택적으로 컴파일링할 수도 있다).

컨트롤러: 장점과 단점

MVC는 잘 정돈된 코드로 기업형 애플리케이션을 만들게 도왔지만 몇 가지 단점도 발견되었다.

센차의 전문 서비스 및 지원 팀은 고객 애플리케이션 안에 있는 소수의 컨트롤러에서 수천 행의코드가 뻗어 나간다는 현상을 보고했다. 이런 문제가 있으면 앱의 성능이 떨어지고 장기적으로 유지하기가 힘들어진다.

또한 센차의 MVC에서는 컨트롤러의 범위가 애플리케이션 전체에 미쳤다. 그래서 뷰, 모델, 그 밖의 객체를 참조하려면 비즈니스 논리가 추가로 있어야 했다. 컨트롤러는 어느 시점에서든 어느 객체를 감시할 수 있었으므로, 컨트롤러에 뷰 A와 뷰 B에 대한 논리가 모두 들어 있기 쉬웠다. 이는 가뜩이나 복잡한 대규모 애플리케이션을 더 혼란스럽게 만들었다.

마지막으로, MVC 애플리케이션에는 단위 테스트를 하기 어렵다는 단점이 있었다. 모델, 뷰와 컨트롤러가 느슨하게 연결되어 있어야 했지만, 실상 컨트롤러를 테스트하려면 관련 모델과 뷰에 대한 지식이 필요했다. 컨트롤러는 다수의 뷰에 걸친 이벤트를 리스닝할 때가 많다. 그래서 고객이 개별적인 “단위”를 테스트하려면 이런 종속성 때문에 전체 애플리케이션을 실행해야만 했다.

쉽게 말해 MVC 아키텍처는 웹 애플리케이션에 아주 유용하고 Ext JS 6는 향후에도 이 패턴을 지원할 것이다. 하지만 분명 몇 가지 단점이 존재하기 때문에 Ext JS 6는 MVVM을 지원함으로써 이런 문제에 대처한다.

Ext JS 6의 MVVM

앞에서 설명한 것처럼 전역적인 (분리형) 컨트롤러는 이론상으로 훌륭해 보일 뿐 실제 적용하니 다루기 까다롭다는 커다란 단점이 있었다. MVVM은 뷰를 특정한 뷰모델(그리고/또는 뷰컨트롤러) 인스턴스와 연결해 문제를 해결했다.

Ext JS 애플리케이션 아키텍처

Ext JS 6이 MVVM을 지원한다 해도 전반적인 아키텍처는 별로 달라지지 않았다. 모델은 여전히 Ext.data.Model을 확장하고 뷰는 여전히 프레임워크의 특정한 위젯을 확장한다. 뷰모델은 Ext.app.ViewModel라는 새로운 클래스를 이용해 본질적으로 같은 작업을 한다.

MVVM 애플리케이션의 모델, 뷰와 뷰모델도 예전처럼 명료하게 정의된 명명 규칙을 따른다. 가령 MyApp.model.User는 ~/app/model/User.js와 연결되는 식이다.

그러므로 Ext JS 4.x로 작성된 애플리케이션은 아무런 아키텍처 문제 없이 Ext JS 5.x로 업그레이드할 수 있어야 한다.

뷰모델

MVC와 MVVM의 가장 큰 차이는 뷰모델이다. 높은 계층에서 MVC 컨트롤러와 MVVM 뷰모델은 아주 흡사하다. 하지만 뷰모델은 이벤트가 아니라 데이터 바인딩을 통해 모델과 뷰의 업데이트한다는 차이가 있다.

뷰모델은 컴포넌트의 생명주기에도 관여한다. 뷰가 생성될 때마다 환경설정된 뷰모델 고유의 인스턴스도 생성된다. 연관된 뷰가 사라지면 뷰모델도 뒤이어 사라진다.

뷰컨트롤러

비록 이름은 모델-뷰-뷰모델이지만 Ext JS의 MVVM 패턴은 여전히 컨트롤러를 사용할 수 있다. 그래서어떤 이는 하이브리드 MVC+VM 아키텍처라는 이름으로 부를 수도 있다. 복잡한 머릿글자는 제쳐 두고 요점만 보자. 두 가지 방법은 각각의 메리트가 있고 Ext JS 6는 유연하게 두 가지를 모두 지원한다는 사실이다.

Ext JS 4에 도입된 MVC 컨트롤러는 애플리케이션의 전역적인 이벤트 리스너 개념이었고(예: 발행/구독 모델 또는 이벤트 버스) Ext JS 5도 그 개념을 아직 지원한다. 하지만 Ext JS에는 뷰컨트롤러라는 새로운 형태도 존재한다.

Ext JS의 뷰컨트롤러와 뷰모델는 서로 비슷하다. 둘 다 연관된 뷰를 직접 탐색하는 구조이다. 그래서 MVC에 필요했던 추가 작업을 대부분 제거해 객체 레퍼런스를 관리하고 애플리케이션 상태를 복원한다.

또한 뷰컨트롤러는 기존 Ext JS 4의 MVC 컨트롤러와 유사해서(예: 애플리케이션 전체에 범위가 미친다) 이벤트를 리스닝한 후 논리를 실행한다. 그러나 뷰컨트롤러와 전형적인 컨트롤러는 다음과 같은 점에서 크게 다르다. 뷰컨트롤러는 연관된 뷰에 따라 개별적으로 생성되는 반면, 컨트롤러는 다수의 뷰를 전역적으로 리스닝하는 하나의 구성체라는 점이다.

그리고 뷰컨트롤러 덕부네 개발자는 선언적 리스너를 작성할 수 있다. 결과적으로 애플리케이션 코드가 단순해지고 뷰는 비즈니스 논리에 얽매이지 않는다.

마지막으로, 뷰컨트롤러와 뷰모델은 컴포넌트 생명주기에 관여한다. 뷰가 생성될 때마다 환경설정된 뷰모델과 뷰컨트롤러 고유의 인스턴트도 생성된다는 뜻이다. 연관된 뷰가 사라지면 뷰모델과 뷰컨트롤러도 뒤이어 사라진다.

이렇게 뷰와 뷰컨트롤러(그리고/또는 뷰모델)가 긴밀히 연결된 결과, Ext JS 애플리케이션의 단위 테스트가 무척 쉬워졌다. MVVM으로는 비대한 전역적 컨트롤러를 작성할 필요가 없기 때문에 컴포넌트를 완전히 분리해 테스트할 수 있다.

Ext JS의 MVVM 패턴에서는 뷰컨트롤러나 뷰모델이 없는 뷰도 존재한다는 사실을 꼭 기억하자. 뷰컨트롤러와 뷰모델은 아키텍처의 선택 사항일 뿐이다.

결론

Ext JS 4는 일관적인 아키텍처를 정의해 코드를 정리함으로써 기업형 웹 애플리케이션이 MVC를 사용하도록 길을 닦아놓았다. Ext JS 6는 MVC의 성공을 기반으로 MVVM을 지원하면서 후방 호환성을 유지한다. 개발자는 Ext JS 4와 MVC로 구축한 앱을 문제 없이 최신 버전으로 업그레이드할 수 있고, 애플리케이션 아키텍처를 다시 세우지 않아도 된다.

기업형 웹 애플리케이션에 있어 클라이언트 측 MVC는 혁신적인 발전을 이룩했다. 체계가 없던 스파게티 코드를 해결하고 애플리케이션의 확장성을 높였다. 이런 MVC에 데이터 바인딩과 선언적 리스너를 통합한 MVVM은 많은 코드를 제거하고 애플리케이션의 단위 테스트를 쉽게 만들어낸 것이다!

Resources: