클라이언트 측 웹앱 프레임워크
출처:http://blog.cornerstone.sktelecom.com/archive
배경
웹이 앱으로써 역할을 하게 되려면 오프라인 상태에서도 적절히 기능하는 것이 중요해 졌으며 특히 데스크탑보다 네트워크 상태가 변화가 심한 모바일에서 중요성이 더욱 강조됩니다. 동시에 보다 안정적인 사용자 경험을 제공하기 위해 한 페이지 웹 앱이 등장하기 시작했습니다.
한 페이지 웹 앱은 첫 페이지 접속 시 자료와 화면을 제어하는 자바스크립트를 서버로부터 받아와 초기화면과 내용, 기능을 구성한 다음 사용자의 요청에 따라 UI의 지연이 적은 비동기 방식으로 자료를 받아와 화면에 표시하게 됩니다. 여러 페이지를 가진 전통적인 방식은 각 페이지 마다 서버로부터 자바스크립트, 스타일시트 등 자원을 받아 전체 페이지를 다시 표현 하는데, 한 페이지 웹앱은 한번 구성된 상태에서 사용자의 요청에 따라 간단한 JSON방식으로 자료를 받아와 표현함으로 높은 비용을 가진 HTTP 통신을 효율적으로 사용하면서 끊김 없는 사용자 경험을 제공할 수 있습니다.
전통적인 방식은 사용자의 요청마다 서버에서 DB의 자료를 적절하게 구성하여 정적인 페이지를 제공함으로 서버 측에 논리 구조가 중점적으로 구성돼 있는 반면 오프라인에서도 기능하면서 한 페이지로 구성된 웹 앱은 클라이언트에서 사용자의 요청을 처리하고 필요 시 서버로부터 자료를 가져오게 됨으로 결론적으로 클라이언트 측에 논리 구조가 필연적입니다. 여기에 더해 보다 풍성한 사용자 경험을 끊김 없이 제공 가능함으로 클라이언트 측 코드 량과 복잡성이 증가했고 이 문제를 잘 다루기 위해 클라이언트 측 웹앱 프레임워크가 나타났습니다.
구분
클라이언트 측 웹앱 프레임워크는 다음의 몇 가지로 구분해 볼 수 있습니다.
라이브러리
단일 기능을 수행하는 자바스크립트로 가볍고 독립적이어서 대부분은 큰 어려움 없이 다른 라이브러리/프레임워크와 통합이 가능하지만 고도화된 한 페이지 웹 앱을 라이브러리로 구성하기에는 다소 코딩 량이 많습니다. 대표적으로는 다음과 같은 것들이 있습니다.
- jQuery : DOM접근, 변경과 AJAX 통신 등을 손쉽게 다루게 해주는 유틸리티
- Zepto.js : Webkit에 최적화된 jQuery 대체 유틸리티
- Underscore.js : 배열, 객체 등을 손쉽게 다루게 해주는 유틸리티
- Lo-dash : 성능에 최적화된 Underscore 대체 유틸리티
Microjs를 방문하면 다양한 라이브러리를 찾아 볼 수 있습니다.
Full Stack 프레임워크
라이브러리가 단일 기능을 위한 유틸리티 성격이 강하다면 Full Stack 프레임워크는 웹앱을 만들기 위한 기본적인 기능부터 UI까지 전부 다루는 프레임워크입니다. 모든 것을 다루려 하기 때문에 다른 기술과 함께 쓰기 어렵고 많은 부분을 새로 배워야 합니다. HTML, CSS를 자바스크립트로 추상화 하여 자바스크립트 만으로 웹앱을 만들 수 있도록 하는 경우가 많습니다. 대표적으로는 다음과 같은 것들이 있습니다.
- Sencha ExtJS : 풍부한 사용 예와 경험을 가진 프레임워크
- Sproutcore : 최근 몇년동안 활발하게 개발된 모던 웹 앱 프레임워크
- Cappuccino : Objective-C를 자바스크립트로 구현한 Object-J로 구성된 프레임워크
MVC 프레임워크
MVC 패턴을 클라이언트 측에 구현한 프레임워크 입니다. 라이브러리가 한 페이지 웹 앱을 구성하기에는 작성해야 할 코드가 매우 많고, Full Stack 프레임워크는 반면에 배워야 할 것이 너무 많다면 MVC프레임워크는 이 사이의 적절한 곳에 위치해 있어 많은 각광을 받고 있으며 그 만큼 많은 수가 만들어 졌습니다. 대표적으로는 다음과 같은 것들이 있습니다.
- Backbone.js : 클라이언트 측 MVC의 포문을 연 장본인으로 널리 알려져 있으며 상당히 가벼운 프레임워크
- Ember.js : Sproutcore의 MVC부분에서 시작되었으며, 상대적으로 Backbone.js보다 더 적은 코드로 웹앱을 작성 가능
- Angular.js : Google에서 만든 MVVM 패턴의 프레임워크로 상대적으로 Ember.js보다 더 적은 코드로 웹앱을 작성 가능
End to End 프레임워크
클라이언트에 구조를 두는 최근 흐름에서 한 발짝 더 나아가 서버와 클라이언트 모두를 제공하는 프레임워크도 나타나기 시작했습니다. 이제 한창 개발이 진행되고 있는 상태이지만 눈 여겨 볼 만 합니다. 이들 프레임워크는 HTTP통신보다는 소켓통신을 통한 실시간 스트리밍 웹 앱을 지향하고 있는데웹의 미래는 스트리밍이라는 예견을 생각나게 합니다.
- Meteor : 서버, 클라이언트가 긴밀히 통합된 가장 주목 받는 End to End 프레임워크
- Durby.js : 소켓통신을 통해 실시간 웹앱을 작성 가능하며 npm사용 가능 등 Meteor대비 상대적으로 Node.js의 여러 자원을 활용하기 유연하며 SEO에 유리
- SocketStream: 실시간 웹앱을 위한 프레임워크로 Durby.js보다 Node.js의 여러 자원을 더욱 유연하게 사용가능
- Vert.x : 자바로 구성되어 자바스크립트, 루비, 파이선, 자바 등 다양한 언어로 웹 앱 작성가능
별난 프레임워크
위의 흐름과는 별개로 한번쯤 살펴볼만한 흥미롭고 색다른 프레임워크들을 모아봤습니다.
춘추전국시대
하루가 멀다 하고 새로운 프레임워크가 나올 정도로 자바스크립트 씬의 성장이 눈부실 정도 이지만, 정작 실제 개발을 해야 하는 개발자에게는 상당히 곤란한 상황이기도 합니다. 코너스톤팀은 변화하는 웹 환경에 적절하게 대응하기 위해 다양한 프레임워크를 검토했었고 우리 실정에 알맞은 것을 골라 다듬기를 원했습니다. 고도화된 웹앱을 위해서 라이브러리는 부족한 감이 있었고 Full Stack 프레임워크는 너무 많은 학습비용을 필요로 하기에 실제 사업환경에서 적용하기에는 부담스러웠습니다. End to End 프레임워크 또한 비슷한 인상을 주었고 기술 성숙 또한 실제 서비스나 제품에 활용하기에는 아직은 부족한 면이 있어 보였습니다.
MVC 프레임워크는 코너스톤팀이 제작의 방향으로 삼았던 원하는 점진적 접근이 가능해 보였으며 안정적 구조를 제공하여 다양한 개발 능력의 편차를 가진 외부 개발자와 함께 일을 하는 상황에서 클라이언트 측 코드품질을 적절히 상향 평준화하도록 할 수 있는 가능성을 보여주었습니다.
다음 글에서는 코너스톤팀이 실제 검토했던 MVC프레임워크를 좀 더 자세히 살펴보고 코너스톤 구성 속에 어떻게 적용됐는지 살펴보도록 하겠습니다.
감사합니다.
MV* 프레임워크
MVC(Model-View-Controller) 패턴은 애플리케이션을 Model, View, Controller로 분리해서 기능과 표현을 작성하는 패턴입니다. 이 패턴은 풍부한 사용자 경험을 제공하는 그래픽 사용자 인터페이스가 중요한 애플리케이션과 같이 표현과 사용자 반응이 중요한 소프트웨어에 특히 유용합니다. 웹에서는 서버 측 프레임워크인 Ruby on Rails와 Django가 MVC패턴에 기반하여 작성되어 많은 호응을 얻었습니다.
클라이언트 측 프레임워크에서는 몇몇 MV*패턴들이 있습니다. MV*패턴이란 MVC패턴에 기초하여 파생된 유사한 패턴의 모음을 통상적으로 부르는 용어입니다. 각각의 패턴과 관련된 프레임워크를 살펴보겠습니다.
MVC 패턴
출처 : 자바스크립트로 서버, 클라이언트를 모두 다루는 동일형 구조로의 확장 - nodejitsu 블로그
MV*패턴 중에 가장 기본적인 형태입니다. 사용자 인터렉션이 뷰에 이벤트를 일으키면 컨트롤러가 모델을 조작하여 다시 뷰를 표현하는 형태 입니다. 이런 패턴은 클라이언트 측 개발에 매우 용이한데 아래의 프레임워크 예를 통해서 자세히 알아보겠습니다.
Backbone.js
출처 : 자바스크립트로 서버, 클라이언트를 모두 다루는 동일형 구조로의 확장 - nodejitsu 블로그
MV* 프레임워크의 포문을 연 대표적인 프레임워크입니다. 지금은 폭넓은 사용자층과 각종 실 서비스 적용사례와 커뮤니티, 문서, 학습서를 가지고 있습니다. 엄밀한 의미에서 MVC의 구조가 약간 바뀐 변종형태라고 할 수 있습니다.
위의 MVC패턴 그림과 비교해 보면 그림과 같이 사용자 인터렉션에 의한 이벤트와 onHashChange/PushState를 별도로 나누어 작동하고 있습니다. onHashChange/PushState는 단일 페이지 웹앱을 때 유용한 기능으로 사용자가 다녀간 이전 페이지 기록을 모아둔 것들 입니다. Backbone.js에서 사용자 인터렉션에 의한 이벤트는 뷰를 통해 HTML 문서객체모델, 즉 DOM을 변경하는데 사용되고 onHashChange/PushState 이벤트는 URL주소와 변경이력을 다루는 Router에 의해 뷰를 선택하거나 구체화하는 역할을 수행합니다.
또한 뷰가 모델을 직접 다루는데, 결론적으로 뷰에는 잘 알려진 jQuery나 Zepto.js와 같이 DOM을 다루는 라이브러리를 사용하여 웹 개발자에게 익숙한 jQuery 스타일로 HTML 문서를 다루게 됩니다.
Backbone.js를 사용하게 되면 모델, 뷰, 컨트롤러를 분리해서 코딩이 가능하며 기본적인 MVC패턴과 비교했을 때 뷰 부분이 두터워짐을 경험하게 됩니다. 이것이 이상적이지 못하다고 느낄 수도 있지만 실제로는 사용자 인터렉션을 뷰가 받아 컨트롤러로 전달하는 비효율을 제거하는 효과가 있습니다.
실질적으로는 전통적인 MVC패턴에서 컨트롤러의 역할을 거의 뷰에서 수행함으로 컨트롤러 역할이 없다고 보아도 무방하고 매우 가볍고 제약사항이 적기 때문에 MV 라이브러리라 부르기도 합니다. 배열, 객체, 컬렉션을 다루는 Underscore.js에 의존성이 있으며 Underscore.js를 사용하여 Prototype에 기반한 객체지향, 상속 구조를 좀 더 쉽게 만들 수 있습니다.
모델은 실질적으로 모델과 컬렉션으로 구성되어 있는데 모델은 개별 자료이고 컬렉션은 자료의 모음과 자료 모음에 접근할 수 있는 추상화된 API를 가지고 있어 리스트, 정렬 등을 다루기 쉽게 해줍니다. 모델, 컬렉션은 RESTful 서버와 동기화되기 쉽도록 구성되어 있고 실제로 서버 측을 RESTful하게 구성하는 것이 권장됩니다. 이렇게 서버를 구성하면 자연적으로 자료/DB와 객체의 구성을 같게 유지하는 느슨한 형태의 ORM구조를 만들게 됩니다.
전체적으로 Backbone.js는 DOM을 조작하여 내용을 표현하기 쉽게 하는 jQuery에 익숙한 웹 개발자가 자료와 표현을 분리하고자 할 때 전면적인 코드 개편이 아닌 점진적 도입이 가능한 프레임워크 입니다. 가벼운 만큼 개발자가 직접 자신의 앱에 아키텍처를 구조화 할 수 있으며 유연하여 많은 웹 서비스 회사에서 자신의 요구사항에 맞추어 사용하고 있습니다. 때때로 가볍고 유연한 만큼 작은 웹 앱을 빠르게 개발하고 싶은 개발자들은 부족함을 느끼기도 하는데 Backbone.js를 확장하여 이를 보완해 주는 프레임워크들이나 처음 Backbone.js를 시작할 때 필요한 디렉터리 구조나 기타 라이브러리, 배포 등을 한번에 관리하는 Scaffolding 도구가 다양하게 나와있습니다. 이들에 대해서는 다시 한번 다루도록 하겠습니다.
Backbone.js 강좌 한국어
Backbone.js 총정리 한국어
Maria
MVC패턴은 객체지향언어의 시작 격인 Smalltalk에서 처음 나타났는데 Maria 프레임워크는 이때 제시된 형태를 클라이언트 측에서도 사용할 수 있도록 고안된 프레임 워크 입니다. 보통 MV* 프레임워크가 실 서비스 개발을 용이하게 만드는 라우터 등 다양한 기능을 포함한 것에 비해 오직 MVC패턴을 구현하기 위한 기능에 초점이 맞추어져 있습니다. 아직까지는 광범위하게 실 서비스에 사용된다기 보다는 자바스크립트의 다양한 패턴을 익힐 때 한번쯤 살펴보면 좋을 것 같습니다.
Ember.js
어떤 면에서는 Backbone.js은 MVC 패턴을 사용하기 위한 라이브러리에 가깝다는 의견이 많을 정도로 가볍습니다. 하지만 Ember.js는 Backbone.js에 비하면 본격적인 프레임워크라고 볼 수 있습니다. Backbone.js는 유연하여 다양한 요구사항에 대응하는 구조를 갖출 수 있지만, Ember.js는 좀더 완고하게 자신의 구조를 적용할 것을 요구합니다. 여기에 더해 데스크탑 애플리케이션 수준의 웹 앱을 만들 수 있을 정도로 모듈구조, MVC패턴에 연관된 다양한 기능, DOM의 재사용을 위한 템플릿 기능과 템플릿과 뷰의 자동적인 연결, 동기화, 업데이트 등 매력적인 요소를 가지고 있습니다. 어떤 개발자들은 Backbone.js가 자바스크립트 해커를 위한 것 이라면 Ember.js는 시스템 개발자들에게 더욱 친숙할 수 있으며 알알이 꽉 찬 프레임워크라고도 합니다. 그만큼 자질구레하게 개발자가 신경 써야 할 부분이 많이 줄어 듭니다.
Apple의 MobileMe, iWorks 서비스에서 사용되어 널리 알려진 Full Stack 프레임워크 SproutCore의 핵심부분을 간소화한 Ember.js는 나름의 탄탄한 경험을 토대로 발전되어 왔으며Ruby on Rails의 핵심개발자인 Yehada katz가 참여하고 있는 등 신뢰할만한 여러 여건을 갖추고 있습니다. 아직 1.0에 이르지는 못했지만 어느 정도 문서화도 진행되어 있고 다수의 실 서비스 사용 예도 확보하고 있는 상당히 안정권에 들어있는 프레임워크 입니다.
Spine.js
자바스크립트를 컴파일 하는 커피스크립트로 구성된 MVC 프레임 워크 입니다. 모델, 뷰, 컨트롤러, 라우터 등 각각이 클래스로 모듈화 되 있고 커피스크립트가 지원하는 클래스 형식의 상속이 가능합니다. 자바스크립트로도 웹 앱을 구성 할 수 있지만 아무래도 커피스크립트를 사용하여 MVC구조를 구성하는데 더 유리합니다.
PlastronJS
Spine.js가 커피스크립트 위에서 MVC 패턴을 구현했다고 하면, PlastronJS는 구글 클로저 라이브러리 위에서 MVC 패턴을 구현했습니다. 클로저 라이브러리는 자체적인 모듈, UI 위젯, DOM 유틸리티를 가지고 있으며 지메일, 구글 지도, 구글 드라이브와 같은 다양한 구글 제품에 사용되었습니다. 자바스크립트를 매우 작고 간결하게 컴파일해주는 클로저 컴파일러와 클로저 라이브러리를 사용하면서 MVC 패턴을 활용할 때 유용합니다.
Agility.js
대다수의 MV* 프레임워크가 내용의 HTML, 모양의 CSS, 기능의 자바스크립트를 유지하여 가볍고도 유연한 상태를 유지하려 하는 반면 SproutCore, ExtJS와 같은 Full Stack 프레임워크는 자바스크립트로 HTML, CSS를 전부 다루어 대규모 웹 앱에 유리하도록 구성되어 있습니다. Agility.js는 MVC프레임워크로 가벼운 점을 계속해서 유지하려 하지만 한편으로 자바스크립트를 통해 HTML, CSS를 전부 다루도록 되어있습니다.
Backbone.js의 뷰가 DOM을 손쉽게 다루기 위해서는 jQuery로 일일이 DOM을 건드리는 것보다 템플릿을 활용하는 것이 유리한데 Underscroe.js에 있는 자체 템플릿이나 Mustache.js,Handlebars.js같은 라이브러리를 활용하는 것이 좋습니다. Ember.js는 자체적으로 Handlebars.js를 포함하여 DOM 템플릿을 지원하고 있는데 이것과 비슷하게Agility.js는 jQuery에 의존성이 있어서 jQuery를 확장하여 뷰로부터 DOM을 다룹니다.
jQuery에 의존성이 있는 만큼 jQuery문법의 시작인 $와 유사한 $$를 통해 웹앱을 작성하는 것이 흥미롭습니다. 자바스크립트의 Prototype 상속을 지원하며 Maria와 마찬가지로 원조 MVC 패턴의 구조를 잘 담고 있습니다.
CanJS
Ember.js가 Sproutcore의 경량판이라면 CanJS는 JavascriptMVC의 경량판입니다. CanJS는 가볍고 빠른 속도, 각 기능별 모듈화를 지향하는데 특별히 DOM과 뷰 사이를 연결해주는 부분같이 뷰의 속도가 Backbone.js나 Ember.js보다 유의미하게 빠릅니다. jQuery, Zepto, Dojo, Mootools와 잘 어울릴 수 있도록 별도의 지원이 있으며 이들을 확장하여 사용할 때 유용합니다.
Stapes.js
Backbone.js을 필두로 시작된 모던 프론트엔드 자바스크립트 프레임워크는 가볍고 유연함을 이점 중에 하나로 강조하는데 Stapes는 특별히 매우 가벼운 프레임워크입니다. Stapes.js는 특별히 미리 정의된 모델, 뷰, 컨트롤러가 없이 기능을 적절히 구분하고 연결, 상속할 수 있는 구조만 제공함으로 개발자는 매우 높은 자유도를 가지고 웹앱을 작성하거나 기존의 웹앱에 도입이 가능합니다. 자유도가 높은 만큼 개발자 스스로가 만들어야 할 부분 또한 많다고 볼 수 있습니다.
PureMVC
ECMA 스크립트의 방언이자 자바스크립트의 친척인 Adobe의 액션스크립트로 부터 시작된 MVC 프레임워크 입니다. Flash, Flex, Adobe Air에서 PureMVC를 사용해 본 개발자라면 자바스크립트에서도 무리 없이 PureMVC를 사용 할 수 있습니다. C#, JAVA, PHP등 다양한 언어에서 적용이 가능한 프레임워크입니다.
Olives
Olives는 특이하게 클라이언트-서버간 실시간 통신규격인 HTML5 소켓통신을 자바스크립트 서버환경인 Node.js로 쉽게 구현한 Socket.IO의 클라이언트 부분을 내장하고있어 Node.js 서버와 손쉽게 실시간으로 대화하는 웹앱을 만들기 좋습니다. 자바스크립트 모듈화 방식인 AMD/CommonJS 둘 다를 지원하며 이를 통해 자료구조를 만드는 Emily라이브러리에 의존성이 있으며, 자연스럽게 AMD/CommonJS 방식으로 모듈화된 웹앱을 작성가능합니다.
Serenade.js
HTML를 단순화 하여 템플릿으로 쉽게 사용 가능하게 하는 전처리 라이브러리 Slim, Jade, HAML에 영향 받은 자체 라이브러리를 가지고 있는 게 특색 있습니다. MVC 패턴의 고민은 뷰를 컨트롤러와 분리하기가 쉽지 않고 뷰가 무거워지는데 있습니다. 특히 뷰에 HTML를 재사용하기 위한 템플릿이 뷰를 무겁게 하는데 Serenade.js는 이 부분을 자체 템플릿 엔진을 사용해 해결하고자 노력하고 있습니다. 앞으로 살펴볼 MVP/MVVM 패턴은 뷰와 논리구조를 분리하기 위해 HTML자체를 사실상 템플릿으로 활용하는 방식을 취하는데 Serenade.js는 이 둘 사이 중간 정도에 위치한 해결법으로 보입니다.
Model2 MVC 패턴
출처 : 자바스크립트로 서버, 클라이언트를 모두 다루는 동일형 구조로의 확장 - nodejitsu 블로그
Model2는 MVC 패턴의 활용방법 중 하나라고 볼 수 있습니다. 대부분 Ruby on Rails, JAVA 서버 개발과 같이 서버 측에서 사용되고 있습니다. 기본적으로 HTTP 요청에 따른 상태를 뷰에 남길 수 없으며 이 상태를 세션 쿠키에 남기게 되는데 이러한 구조는 의도한대로 컨트롤러가 모델, 뷰에 단 반향으로 접근하여 깔끔한 논리구조를 가지지만 클라이언트 측 개발에는 적합하지 못합니다.
MVP패턴
출처 : 자바스크립트로 서버, 클라이언트를 모두 다루는 동일형 구조로의 확장 - nodejitsu 블로그
MVP패턴은 모델-뷰-프레젠터로 구성된 패턴으로 위의 그림과 같이 MVC패턴의 일반적인 콘트럴러가 프레젠터로 교체된 형태 입니다. 프레젠터가 뷰와 모델의 이벤트를 모두 받아 상호작용을 관장합니다. MVC 패턴이 실질적으로 뷰와 컨트롤러가 분리되기 어려운 점을 어느 정도 완하합니다. MVP를 자처하는 프레임워크는 많지 않은데 Backbone.js과 같은 대다수 MVC 프레임워크가 한편으로는 MVP 패턴으로 해석이 가능하기 때문일 듯 합니다. 반면에 다음에 소개할 MVVM 패턴의 프레임워크는 MVC 패턴의 프레임워크와는 많은 차이를 보여줍니다.
Epitome
클래스 형식의 상속과 객체를 다루는 다양한 유틸리티, DOM을 다루는 종합적인 Full Stack 프레임워크인 MooTools에 클래스와 이벤트 모듈에 기반한 MVP 프레임워크 입니다.
MVVM패턴
출처 : 자바스크립트로 서버, 클라이언트를 모두 다루는 동일형 구조로의 확장 - nodejitsu 블로그
위의 MVP 패턴 다이어그램과 MVVM 패턴 다이어그램을 비교해보면 사실상 다를 바가 없어 보입니다. MVVM 패턴이 실질적으로 클라이언트 측 프레임워크로 구현될 때 가장 큰 특징은 HTML문서 자체를 템플릿화 하여 뷰로 만들고 이를 뷰모델과 연결하는데 있습니다.
MVC 패턴의 프레임워크들이 양방향/단방향 자료 바인딩의 구현에 상당한 공을 들이는 반면 MVVM 패턴의 프레임워크는 HTML자체를 뷰와 템플릿으로 활용하고 뷰모델과 연결시킴으로 별다른 어려움 없이 바인딩을 구현하고 있고 이는 손쉽게 웹앱을 작성하게 해줍니다.
MVVM 패턴에 대해서… 한국어
AngularJS
구글에서 만든 프레임워크로 MVVM 패턴 중에 가장 주목 받는 것 중 하나입니다. AngularJS는 스스로 MV Whatever 패턴이라고 이야기하는데 MVC/MVVM 패턴이 조금씩 변형되었으나 전통적인 MVVM 패턴보다는 오히려 개발자에게 더 친숙한 면이 있습니다. 현재까지 클라이언트 측 MVVM 패턴의 프레임워크 중 가장 최적의 구현을 보여줍니다. jQuery와 함께 사용되기 쉬우며 MVVM 패턴의 특징대로 양방향 자료 바인딩이 손쉽게 됩니다. 매우 간단하고 쉽고 적은 코드로 웹 앱을 작성하게 해 줍니다.
AngularJS 강의 한국어
예제
KnockoutJS
전통적인 MVVM 패턴을 구현할 수 있는 프레임워크 입니다. MVVM 패턴이 마이크로소프트의 실버라이트, WPF와 같은 환경을 위해 탄생한 장점을 살려 닷넷 환경과 잘 통합되도록 되어있습니다. AngularJS에 비하면 좀 더 해야 하는 일이 많은데 AngularJS의 자료 바인딩은 엄청 간단한 반면 KnockoutJS는 약간의 설정이 필요합니다.
KnockoutJS 소개 한국어
KnockoutJS 핵심 한국어
예제
Knockback.js
Backbone.js에 KnockoutJS현태의 MVVM 패턴을 구현한 Backbone.js 확장 프레임워크 입니다. Backbone.js은 이런 형태의 다양한 확장 형 프레임워크가 있는데 이는 별도로 소개해 드리겠습니다.
Batman
커피스크립트를 통해 MVVM 패턴을 사용하는 프레임워크 입니다. 커피스크립트의 클레스 형식 상속을 사용하여 객체를 다룰 수 있습니다.
rAppid.js
일반적인 MVVM 프레임워크가 HTML자체를 템블릿/뷰로 사용할 때 rAppid.js는 마이크로 소프트에서 닷넷 프레임워크 환경을 위해 만든 XML에 기반한 마크업 언어인 XAML를 사용합니다.
기타
MV* 계열의 프레임워크라 보기는 힘들지만 이들과 서로 영향을 주고 받은 프레임워크 입니다.
Dijon
클라이언트에서 IoC/DI를 구현하여 웹앱을 사용하게 해주는 프레임워크입니다. MV*와는 다른 접근으로 웹앱을 작성할 수 있습니다.
Sammy.js
Sammy는 Backbone.js등에서 말하는 라우터만 있는 라이브러리 입니다. 단일 페이지 웹앱을 매우 가볍게 만들 때 한번쯤 도입 해볼만하며 특별히 문서형태의 DB인 CouchDB와 잘 어울립니다.
결론
수많은 MV*계열 프레임워크가 웹앱작성을 용이하게 하기 위해 만들어 지고 있습니다. 이중 현재 시점에서 가장 주목 받으면서 실질적인 서비스환경에 사용할 만하거나 사용되고 있으며 동시에 안정적인 커뮤니티와 개발진을 가진 프레임워크는 Backbone.js, Ember.js, AngularJS입니다.
출처 : 프레임워크비교 - BAOBAB, Snappy Performance Apps with Ember.js - MarakanaTechTV
코너스톤 팀은 이중 다양한 서버 환경과도 무리 없이 어울리면서 점진적으로 도입이 가능한 점, 협업과 분업이 가능한 모듈구조와 이를 증명하는 대규모 웹앱 사례를 가진 Backbone.js를 선택하였습니다. 하지만 위의 언급대로 Backbone.js만으로 웹앱을 만들기에는 여전히 필요한 것들이 있는데 다음 글에서는 이 부분에 대해서 다루겠습니다.
감사합니다.
Backbone.js을 확장한 프레임워크
Backbone.js는 가벼운 만큼 다양한 플러그인과 Backbone.js 자체를 확장한 프레임워크가 있습니다. 우리는 이러한 것들을 조사하면서 좀더 Backbone.js의 가능성과 실제 우리 개발 환경에 필요한 것들을 만들 수 있으리라 생각하였습니다.
Backbone Boilerplate
Backbone Boilerplate는 프레임워크라기보다 Backbone을 곧장 사용할 수 있도록 밑바탕을 펼쳐놓는 Scaffolding 도구에 가깝습니다. 자바스크립트 빌드 도구인 Grunt에 기반하여 기본적인 디렉터리 구조, 파일 등을 생성해 주어서 곧바로 코딩에 들어갈 수 있도록 해 줍니다.
Chaplin
Backbone Boilerplate에서 자바스크립트를 압축해주고 배포환경으로 만들어주는 빌드 도구인 Grunt를 썼다면 Chaplin은 Brunch.io와 함께 쓰기가 좋도록 구성되어 있습니다. 이외에도 클래스 형태의 상속구조 지원과 객체의 메모리 관리, 모듈화를 통한 캡슐구조, Mediator, Publish/Subscribe 패턴의 지원 등 좀더 본격적으로 웹앱을 만드는데 적합한 다양한 기능을 가지고 있습니다.
Thorax
Backbone.js를 사용하여 웹앱을 개발하다 보면 필연적으로 뷰를 재활용하게 되는데, 이때 클라이언트 측에서 템플릿 처리를 해주는 것이 유용합니다. Backbone.js와 같은 MV* 프레임워크에서는 모델/컨트롤러에서 자료를 구성하고 처리한 다음 뷰는 HTML에 삽입하는 형태가 권장되는데 클라이언트 템플릿 유틸리티 중 논리구조를 배제하고 템플릿 기능에만 집중한 종류가 여기에 적합하며 Mustache가 유명합니다. Mustache는 Ruby를 비롯한 다양한 언어에서 사용하기 적합하도록 되어 있는데 최근 자바스크립트 개발에서는 Handlebars.js를 많이 쓰고 있고, 참고로 Backbone.js가 의존성을 가지고 있는 Underscore.js도 간단한 템플릿 기능을 가지고 있습니다.
Thorax는 Backbone.js에 Handlebars.js를 편안히 사용하도록 구성돼있고 이는 우리 코너스톤의 구성과 매우 유사합니다. 코너스톤을 기획할 당시에는 아직 이런 형태가 없었으나 최근 이런 모습의 프레임워크가 나타나는 것을 보면 우리 코너스톤의 방향이나 작업이 의미 있다는 점을 다시 한번 확인시켜 주고 있다고 보고 있습니다.
Backbone.Marionette
Backbone.Marionette는 Backbone을 확장시킨 프레임워크 중 가장 많은 주목을 받고 있습니다. 미리 준비된 다양한 뷰 패턴과, 모듈화된 구조, 구조적인 이벤트 처리와 이벤트 바인딩, 메모리 관리, 뷰를 확장한 레이아웃 등 실전에 필요한 다양한 구성을 갖추어 다양한 실 서비스 예시도 확보하고 있습니다. Chaplin과 마찬가지로 메모리관리는 하는데 Backbone.js에서 뷰를 사용하다 보면 자연히 메모리에 사용하지 않는 뷰가 남게 되어 이를 적절히 해지하는 것이 필요합니다. 이 두 프레임워크는 이를 어느 정도 자동화 시켜 놓고 있습니다.
기타 확장된 프레임워크, 플러그인
Backbone.js는 jQuery와 같이 매우 많은 개발자가 플러그인, 확장된 프레임워크를 만들어 내 놓고 있습니다. Backbone.js의 위키를 살펴보면 위에 언급된 프레임워크 이외에도 다양한 플러그인과 프레임워크를 확인할 수 있습니다. 이곳에 플러그 인들은 코너스톤의 MV*를 선정할 때 Backbone.js를 선정하게 된 결정적인 계기가 되었습니다. 코너스톤이 제공하는 기능 이외에도 필요에 따라 Backbone.js기반 플러그 인을 활용하여 코너스톤을 다양하게 확장할 수 있습니다.
CSS 프레임워크
HTML개발시 스타일은 이미지가 아니라 CSS로 만들 것을 권장하지만 국내에서는 개발 시 시간과 한글과 한글 글꼴처리의 어려움 때문에 이미지를 쓰는 경우가 많습니다. 하지만 모바일에서 CSS를 적절히 활용하면 하드웨어 가속을 통해 빠른 웹, 웹앱을 만들 수 있어 CSS로 스타일을 구성하는 것이 표준을 준수하는 것 이상으로 중요해 지고 있습니다. CSS 역시 자바스크립트처럼 코드로 구성되어있고 갈수록 크기가 늘어나기 때문에 적절한 구조화와 추상화가 개발 시 많은 도움이 됩니다.
자바스크립트를 모듈화하는데 AMD/CommonJS가 있다면 CSS를 구조화하고 모듈화하는 방법론으로는 OOCSS와SMACSS가 있습니다. OOCSS는 Object-Oriented CSS의 약자로 말 그대로 스타일링을 객체지향으로 하는 방법론입니다. 이미 재활용 성, 속도, 읽기 쉬운 구조 등으로 많은 찬사와 활용이 되어지고 있습니다. SMACSS는 공통, 레이아웃, 모듈, 상태의 4가지 구분으로 스타일을 작성하는 방법으로 많은 예제와 사용을 확보하고 있습니다. OOCSS는 좀더 대형 프로젝트에 적합하고 중/소규모에는 SMACSS가 적합하다는 의견이 있습니다.
자바스크립트 개발자에게 모듈화는 AMD/CommonJS, 구조화는 MV*가 있다면 퍼블리셔, CSS개발자에게는 OOCSS/SMACSS가 있고 이들만 적용해도 프로젝트를 안정적으로 확장이 가능할 것이라 생각됩니다. 여기에 더해 아래의 프레임워크를 고려한다면 높은 생산성, 안정적인 확장과 동시에 CSS 속도 또한 확보할 수 있으리라 기대됩니다. CSS 또한 웹앱의 속도에 영향을 미치는 커다란 요소로 본격적으로 고품질의 웹앱을 작성한다면 여기에 대한 대비도 필요합니다.
OOCSS 소개 한국어
OOCSS + SASS = 최상의 CSS 사용법 한국어
SMACSS 연재 한국어
inuit.css
inuit.css는 OOCSS를 곧바로 사용할 수 있도록 해 줍니다. CSS 전처리기로 추상화, 상속, 계산 등의 기능을 갖춘 SASS로 구성되어 있으며 꼭 SASS를 사용할 필요는 없습니다. OOCSS와 동시에 BEM 형식의 이름을 사용하는데, BEM은 블록-엘리먼트이름-변형이름의 형태로 CSS 클레스 이름을 짓는 방식입니다. UI가 필요 없이 CSS구조가 필요한 개발자와 퍼블리셔에게 적합합니다.
960 Grid
CSS를 작성할 때 큰 고민 중 하나는 기본적인 그리드 체계를 만드는 것인데 960 Grid는 많은 사용 예를 확보한 그리드 프레임워크로 기본적으로 12개 혹은 필요에 따라 16/24개의 열로 그리드를 구성하는 방식입니다. 디자인에 손쉽게 적용이 가능한 PDF도 제공하고 있습니다.
normalize.css
브라우저마다 HTML테그를 그리는 기본값이 다르기 때문에 이를 초기화 시키는 경우가 많습니다. 최근에는 과도하게 값을 조정하는 CSS 초기화 보다는 브라우저의 기본값을 살리면서 HTML5를 필두로 한 최근 개발 동향에 적합하게 일반화 시키는 방법을 쓰고 있습니다. normalize.css를 사용하면 최소한의 지정으로 적절하게 다양한 브라우저의 기본 스타일 상태를 일치 시킬 수 있어 여러 브러우저를 지원하는데 매우 유용합니다.
Typeplate
Typeplate는 웹에서 글자와 문장을 미려하게 표현할 수 있도록 구조를 만들어줍니다. 글이 중심이 되는 페이지를 스타일링 할 때 매우 유용합니다.
Foundation
Foundation은 다양한 화면크기에 대응하는 반응형 구조, 응용 UI를 갖춘 종합적인 UI프레임워크 입니다. Inuit.css는 기반이 제공되고, 960 Grid가 그리드체계를 제공한다면 Foundation은 곧장 스타일링에 들어 갈 수 있는 기본적인 모든 요소를 제공합니다.
bootstrap
bootstrap는 기본적인 그리드 체계, 반응형 그리드 체계, CSS3기반의 버튼 등 곧장 개발에 사용할 수 있는 기반과 응용UI를 갖춘 종합적인 UI프레임워크입니다. 너무나 많은 사용 예와 도구를 확보하고 있습니다. 최근에는 국내의 오픈소스 CMS인 XE에 사용되기도 했으며 코너스톤에도 적용되었습니다.
결론
웹앱을 작성하기 위한 다양한 프레임워크와 코너스톤의 선택을 살펴보았습니다. 코너스톤의 설계와 기획에 여러 대안과 최종 선택의 과정을 설명 함으로 코너스톤을 활용하는데 도움이 되리라 기대하였습니다. 코너스톤은 다양한 방식으로 확장가능하고 적용된 오픈소스 커뮤니티의 문서와 지원을 받을 수 있는 선택을 하여 웹앱을 작성하는데 매우 좋은 시작점이 됩니다.
실제 웹앱을 위한 기술스택을 정하는데 프레임워크가 핵심적인 역할을 하지만 그 외에도 좀더 고려해야 할 것이 많습니다. 다음에는 현대적인 웹앱을 위한 기술스택에 대해 이야기 하겠습니다.
감사합니다.