Javascript에는 수많은 프레임워크 혹은 라이브러리가 있습니다.(프레임워크와 라이브러리의 경계라는 것이 좀 애매하긴 하지만 그냥 저 혼자만의 생각으로 기반을 제공해 주는 것들은 프레임워크로 분류하고 단일 기능이나 프레임워크를 활용해서 제공된 것들을 라이브러리 정도로 분류하고 있습니다. 저혼자 임의로요... )

그동안은 prototype.js를 중심으로 써왔고 최근에는 대세인 jQuery를 공부하고 있었습니다. 이번에는 개인적인 프로젝트를 하느라고 한달반정도 Ext JS를 붙잡고 있었습니다. 사실 익히 알려진 JS프레임워크들 외에도 수많은 프레임워크들이 그중에서 유명세를 탄 것 들도 있고 아닌 것들도 있지만 각기 장단점을 가지고 발전되고 있습니다만 익숙해진 프레임워크에서 다른 것으로 갈아타는 것은 생각만큼 쉬운 일은 아닙니다.

이런 프레임워크들 중에서 Ext JS는 UI프레임워크라고 생각하고 있고 비슷한 류로는 Yahoo!의 YUI가 있습니다. 웹서비스들이 인터렉티브하고 화려해진 이후에 UI작업은 상당히 노가다 작업이라고 할 수 있는데 Grid, Drag n Drop, date picker 등등 이전에는 단독으로 만들어졌던 기능들을 총체적으로 모아놓고 제공하고 있습니다. "그리드 만들어 놓고 제목클릭하면 컬럼별로 소팅! "하기 만들려면 어렵고 쉽고를 떠나서 엄청난 작업이 필요하지만 이런 Rich한 UI를 미리 다 만들어 놓고 설정바꾸어서 사용할 수 있도록 제공한다고 할 수 있습니다.

구경정도는 전에 해본적이 있지만 실제 제대로 사용해 본것은 이번이 처음이라고 할 수 있습니다. 그동안 안써본 것은 실 업무에서 이런식의 Rich한 UI을 쓸일이 없었고 Ext JS는 라이센스 문제가 있어서 사용으로 쓰거나 만들어진 소스를 GPL로 공개를 해야하기 때문에 사용상의 제약이 조금 있다고 할 수 있습니다. 머 한달반 써보고 무언가 평가(?)를 한다는 것은 조심스러운 일이지만 그냥 느낀바를 점 정리해 볼까 합니다. 그것도 일정의 압박으로 깊게 파악하면서 쓰기보다는 당장 구현하는데 급급했기 때문에 일부 틀린 느낌일 수도 있습니다. ㅎㅎ



전반적인 인상
Ext JS는 EXt Core와 Ext JS로 나누어진다고 할 수 있습니다. Ext Core는 흔히 쓰는 JS프레임워크들처럼 DOM을 탐색하거나 스타일,어트리뷰트설정하는 등의 기능을 가지고 있고 UI적인 역할을 하는 것은 Ext JS에 모두 들어 있습니다. Ext JS를 쓰려면 컴포넌트를 이해하는 것이 최우선인듯 합니다. 거의 대부분이 컴포넌트 기반으로 되어 있어서 예를 들면 JsonStore컴포넌트로 데이터를 가져와서 DateView컴포넌트나 Grid컴포넌트에 바인딩시켜서 표현하고 이걸 또 패널컴포넌트등에 넣어서 배치하는 등의 구조로 되어 있습니다. 이런 것을 보면서  ASP.NET같은 느낌이었습니다.  그래서 초기에 어떤 기능의 컴포넌트들이 있는지 모르다 보니 많이 헤매게 되었습니다.(이런 부분은 Rhio Kim님이 만드신 Ext JS 3.1 Designed Class Diagram RC0이 한눈에 볼 수 있어서 꽤 도움이 됩니다.)


처음에 가장 어려웠던 점은 어떤 컴포넌트가 있는지 모른다는 것이었습니다. 어느거나 새로운 것에 적응하려면 마찬가지인 부분이기는 하지만 컴포넌트라는 Ext JS의 특성을 많이 타다보니 어떤 상황에서 어떤 것을 가져다 써야할지가 상당히 어려웠습니다.  고민도 기본적인 것을 알아야 하죠.. 이런 부분은 컴포넌트의  config option에서도 마찬가지였습니다. 공통적인 부분들도 있었지만 컴포넌트별로 특징적인 config도 많기 때문에 사실 개발하면서 API문서를 항시 띄워놓고 개발할 수밖에 없었습니다. 어떤 개발을 하던지 API문서는 중요하지만 Ext JS는 특히 많이 의지하게 되더군요.

이건 좀 애매한 부분이긴 한데 진입장벽이 약간 높지 않나 생각이 듭니다. 머 예제들이 어느 정도 제공되고 있기 때문에 따라서 작성하면 그리 어렵지 않게 붙힐수 있기는 하지만 기존의 일반적으로 익숙할 Function, Class형태의 서로 호출하고 로직장석해 나가는 흐름과는 다르게 대부분의 코드가 Literal형식의 컴포넌트 설정값 지정해주고 그 컴포넌트의 조립으로 구성되기 때문에 익숙치 않아서 초반에 많이 고생하게 되더군요.



Debugging의 어려움
글로만 설명하려니 좀 어렵긴 하지만 Ext JS는 일반적인 로직의 흐름으로 흘러가는 식으로 소스를 짜지 않고 컴포넌트에 config설정값 지정해주고 안에 넣을 내용 지정해주고 리스너 등록해 놓는 식입니다. 이런 코드들은 JSON과 동일한 구조의 Literal형식으로 지정되고 이렇게 정의된 컴포넌트들이 서로를 감싸는 구조로 작성됩니다. 당연히 다른 소스들도 들어가지만 이렇게 되다보니 계속된 "name":"value"의 나열로 이어지게 되어서 소스가 좀 읽기 어렵더군요.(뭐 나중엔 익숙해 지긴 하지만요..) 물론 요즘은 Literal형식으로 많이 코딩을 하기는 하지만 적절히 config와 fucntion이 섞여진 구조와는 다르게 거의 모든 것이 Literal방식으로 강제되어 있다보니 흐름을 쫓기가 초반에 쉽지 않았습니다.

그냥 짜고 보고 하는건 시간지나면 익숙해지고 하지만 디버깅할 때는 특히 어려웠습니다. 디버깅할때 일반적으로 많이 하는 것이 중간에 값을 찍어보는 것일 겁니다. alert()로 찍어본다던지 console.log()로 정확히 어떤 값이 넘어갔고 내가 생각하는 순서대로 호출이 되고 있는지 확인해 보면서 어떻게 동작되는지 파악하고 버그 찾아내고는 하는데 Ext JS는 Literal구조로 되어 있어서 중간에 로그를 찍어볼수가 없어서 제공되는 Event Listener를 등록해서 찍어봐야해서 좀 번거롭기도 하고 상황에 따라서는 원하는 때에 찍어보기도 좀 어려운 부분이 있고 그러더군요.

기본적으로 제공되는 ext-all.js는 압축버전이기 때문에 개발단계에서는 ext-all-debug.js파일을 이용하게 됩니다. 그래야 주석도 있고 들여쓰기도 되어 있어서 읽기가 편하니까요. 근데 ext-all-debug.js이 4만4천라인에 용량이 1.1메가 입니다. 파이어버그에서 오류추적하다가 ext-all-debug.js파일을 열어서 볼라고 하면 잘못하면 파이어폭스가 얼어버립니다. 디버킹 특성상 여기열었다 저기열었다 해야되는데 너무 커서 그러기가 쉽지 않아서 나중에는 파이어버그로는 거의 extjs는 열지 않고 열어야될때는 이클립스에서 보고 추적을 하게 되더군요. 요즘 윈도우가 불안정해서 그런지 ext-all-debug.js파일은 종종 저의 이클립스까지 얼려버리더군요. ㅠ..ㅠ JS파일의 용량이 너무 크다보니 왠만하면 extjs까지 들어가보지 않고 해결하는 기술을 습득하게 되더군요 ㅡ..ㅡ(정 안될때만 extjs 소스 열어보고요. ㅎ)



디자인과 퍼블리싱과 개발의 모호한 경계
이번 개발을 하면서는 별도의 디자이너나 퍼블리셔가 없이 개발자가 전부 수행했기 때문에 그나마 괜찮았지만 이녀석도 RIA같은 UI를 제공하고 있기 때문에 RIA에서의 고민도 그대로 넘어오게 됩니다. RIA쪽이 크니까 RIA에 비교하긴 했지만 사실 웹의 UI가 인터렉티브해지면서 생겨난 여러가지 고민들과 동일합니다. 기존의 SB로 인터렉티브한 UI를 그려내기가 어려워서 포스트잇등 다양한 얘기들이 인터넷에서 오가곤 했었습니다만 디자인파일가지고 HTML만들고 거기에 개발소스 입히는 종전의 과정과는 다르게 디자인과 개발이 상당히 겹쳐있다고 할 수 있습니다. 그래서 Adobe와 MS도 Blend나 Thermo라는 개발과 디자인의 중간단계의 툴을 만든것 같습니다.

RIA야 새로운 툴이라 그렇다 치고 Ext JS를 다루면서는 실제 업무에서 이렇게 Rich한 UI를 사용하게 되면 디자인과 퍼블리싱과정을 어떻게 결정해야 할까하는 고민이 생기게 되더군요. 실제 상당부분의 UI를 JS에서 찍어내기 때문에 이전처럼 HTML파일받아서 그위에서 코딩하기도 상당히 애매하다고 할 수 있습니다.

그리고 대부분의 컴포넌트는 config로 class를 지정할 수도 있지만 위치나 사이즈등을 지정할 수 있습니다. 여러가지 상황에서 다이나믹하게 움직여야 하다보니 디자인과 상당히 맞물려서 되어야 하는데 그렇게 개발하다보니 대부분의 기본적인 스타일을 config로 주게되었는데 이런 것은 구조와 디자인의 분리라는 측면에서 보았을때 별로 좋아보이지 않습니다. 가장좋은 것은 클래스만 지정해주고 디자인은 CSS파일로 넘겨주는 것인데 정적이 아닌 동적인 UI를 가지고 있기 때문에 전처럼 스타일이 입혀진 HTML파일이 먼저 나오기가 어렵고 UI개발과 스타일작업이 유기적으로 같이 이루어지던지 스타일을 나중에 입히는 형태가 되어야 할 듯해서 실제 업무에서 적용하기에 여러가지 어려움이 있을듯 합니다. 제가 프론트엔드 개발자가 따로 있는 환경에서 개발을 해본적이 없어서 좀더 어렵게 느껴지는 지도 모르겠습니다.

개인적인 생각으로는 기본적인 스타일을 제공하고 있기 때문에 그걸 이용해서 수정하는게 그나마 작업하는 데 편하지 않을까 생각합니다. 컴포넌트 설정으로 동적으로 HTML 태그를 만들어 내기 때문에 스타일작업을 하는 사람도 Ext JS가 생성해내는 HTML태그에 대해서 어느정도는 파악을 하고 있어야 될듯 하더군요.



Epilogue
이런저런 안좋은 얘기들을 했지만 개발하면서 신경쓰였던 점들 위주로 적어서 그렇지 UI라이브러리인 Ext JS가 주는 이점은 상당히 강력합니다.(비슷한 종류인 YUI도 같겠지요.) 위에서 머 config설정이라 초기에 힘들다는 둥 했지만 Ext JS안쓰고 같은 UI를 순수 jQuery나 prototype.js로만 작업을 했다면 개발시간은 몇배는 더 걸렸으리라고 생각하고 있습니다. 더 강력한 기능을 가지려다보니 새롭게 익숙해 져야하는 부분이나 어느정도 감수해야할 부분이라고 생각합니다. 그 대신에 얻을수 있는 UI는 아주 강력하죠. 기본적인 스타일(Ext JS특유의 light blue톤의...)을 제공하고 있기 때문에 디자인이 그렇게 중요하지 않은 관리자 화면에서는 디자인에 대한 고민을 안해도 되기 때문에 활용도가 클것으로 보입니다.(실제로도 관리자쪽에서 많이 쓰이곤 하죠.)