RIA 개발 환경 비교 (GWT, Flash, Silverlight)

몇 해 전에 회사 내에서 연구원들 간에 정보를 공유하고  협업을 유도할 수 있도록 개발 프로세스를 정비하는 프로젝트를 시작하게 되었습니다. 프로세스를 손보려다 보니, 시스템이 필요하다는 걸 알았고, 여기에 딱 맞는 상용 솔루션이 없어서, 직접 개발을 시작하게 되었습니다. 프로그래밍 경력이 대학교 때 숙제 하던 것까지 포함해서 무려 10년이나 됨에도 불구하고, 창피하게도 database를 이용해본 적도 없다는 것, 그리고 그간의 인터넷 광풍에도 웹사이트 구축 한 번 안해봤다는 것이 컴플렉스여서, 이 참에 공부하면서 직접 해보아야겠다고 마음 먹었습니다.

먼저 당시 유행하던 Web 2.0에 맞춰, 웹사이트를 Ajax 형태로 하기로 가져가기로 했습니다. Ajax를 구현할 수 있는 Client와 Server 솔루션을 찾아 보았지요. Server 환경은 고민을 크게 안했습니다. 제가 리눅스 경험도 일천한지라, 서버쪽은 MS 윈도우 환경으로 가기로 했습니다. MS의 .Net Framework 상에서 동작하도록 하게 하고, 언어는 제게 익숙한 Java하고 비슷하다는 C#을 배워서 하기로 했습니다.

문제는 Client 쪽인데, JavaScript로 하나하나 코딩을 할 생각을 하니 막막하더군요. JavaScript가 상당히 low-level이라 해줘야 할 작업들이 많을 것 같았고, 또 MS의 훌륭한 개발 툴인 Visual Studio에 spoil이 될 대로 된지라, 맘에 드는 툴도 없을 것 같았습니다. 그래서 대안을 좀 찾아 보던 중에, Google에서 만든 Google Web Toolkit을 검토해보게 되었습니다.

1. Google Web Toolkit

Google Web Toolkit(GWT)은 Google에서 만든 Javascript library 및 code generator라고 할 수 있습니다. Java로 코딩을 하고, GWT 컴파일러를 돌리면, Javascript 코드가 생성이 됩니다. 또, Google에서 debugger까지 제공을 하니, VS만큼이나 쉽게 코딩을 할 수 있겠구나라고 생각을 하게 되었습니다.

자, 이렇게 Server와 Client의 솔루션을 정해졌고, 두 모듈 사이의 통신은 SOAP(Simple Object Access Protocol)을 이용해서 처리하기로 했습니다. SOAP도 처음 써보았는데, .Net Framwork이 이를 완벽히 지원해주었습니다. 서버에서 제공할 API를 SOAP으로 공개하는 것부터 client와 통신하는 것 모두 자동으로 해주니, 이건 뭐 Windows application 개발 할 때 dll 만들어서 다른 모듈에서 link하는 것보다 더 쉬웠습니다.

개발을 시작했습니다. 2명이서 개발을 했고, 저는 주로 서버 쪽을 맡았습니다. 아! MS는 역시 개발 툴에서는 끝내줬습니다. 예전 MFC와 C++을 이용해서 코딩하던 것과 비교해서 .Net Framework와 C#의 조합은 생산성이 3~4배는 좋아진 것 같았습니다. Eclipse 환경에서 Java, Python 등의 언어도 써봤지만, 이 친구들이 도저히 당해낼 수 없는 생산성 같습니다.

문제는 client 개발 툴인 GWT였습니다. GWT 좋은 점도 있습니다.

  1. JDK의 상당수의 class를 그대로 사용할 수 있다. (String, Xml Parser 등)
  2. Gmail 삘(feel)이 나는 UI control을 그대로 사용할 수 있다.

하지만, 단점들을 무시할 수 없었습니다. 참고로 다음은 GWT 1.5버전 기준입니다.

1. 라이브러리의 완성도가 떨어진다.

버그가 많고  게다가 이 버그를 피해 가는 게 어렵습니다. Code가 generate되는 방식이기 때문에, generate된 코드를 수정해서 버그를 피해간다고 한 들, 다음 번에 컴파일 하면 다시 다, 모조리 원복됩니다. –_-

또, 라이브러리의 완성도가 떨어져서 직접 해줘야 할 것이 많습니다. 예를 들어 XML parser가 XPath를 제대로 지원 안 해서, 다 만들어줘야 합니다.

2. 개발 환경이 별루다.

개발 환경, 특히 debug환경이 좋지 않아서 개발 생산성을 잡아 먹습니다. 또, WYSIWYG방식의 편집이 안되다 보니 컨트롤들 레이아웃 잡는 것이 무쟈게 불편합니다.

3. 결과물의 동작이 느리다.

generate된 Javascript 코드가 의외로 느립니다.

이 당시 시스템을 초기 버전부터 사용자들에게 공개하고 의견을 받아가며 개발하는 iterative한 개발 방식을 취했습니다. 처음에 비교적 기능이 간단했을 때는 GWT로도 큰 문제 없이 할 수 있었습니다. 하지만, 기능이 추가될수록 GWT가 발목을 잡았고, 뭔가 수를 내야겠다고 생각했습니다.

이 와중에, 앞서 개발한 시스템이 회사에서 히트(?)를 치게 되면서, 다른 조직에서 유사한 시스템을 만들어달라는 요청이 들어와서, 번외로 작업을 시작하게 되었습니다.

안그래도 GWT가 맘에 안들었는데, 이 참에 다른 client 솔루션을 도전해보기로 하고 검색에 들어갔습니다. 개발 툴도 괜찮고, 생산성도 좋으며, 속도도 빠른 것이 뭐가 있을까 찾아보다가 Adobe Flex를 발견했습니다.

2. Adobe Flex(Flash)

Adobe Flex는 Flash  파일을 제작을 하는 라이브러리 입니다. Flash 파일은 Flash 프로그램을 통해서 제작할 수 있습니다. 하지만, Flash 프로그램을 통해서는 주로 애니메이션 등의 화려한 효과를 만들 때 사용하는 데는 좋지만, tree control, combo box 등으로 구성된 응용 프로그램 모양을 갖춘 RIA 클라이언트를 만드는 데는 적합하지 않습니다. 그래서 Adobe에서 새로 만든 것이 Adobe Flex입니다. Flex로 만든 결과물은 Flash로 만든 결과물과 똑같이 swf 파일입니다. swf 파일은 브라우저에서 Flash Plug-in을 설치하면 바로 실행이 가능합니다.

Flex에서는 view와 control이 분리되어 있습니다. view(또는 presentation)은 MXML이라는 mark-up 언어를 이용해서 표현을 합니다. 그리고 control(또는 action) 부분은 이미 Flash 때부터 널리 사용되어온 ActionScript를 사용합니다. 쉽게 생각하면, HTML이 MXML에 해당하고, JavaScript가 ActionScript에 해당한다고 볼 수 있습니다.

Notepad에서 Adobe Flex 라이브러리를 사용해서 코딩하고, command-line 컴파일러를 이용해서 직접 swf 파일을 만들 수도 있지만, Adobe Flex Builder라는 개발환경에서 좀더 편하게 만들 수도 있습니다. 최근에는 Adobe Flex Builder가 이름이 Adobe Flash Builder로 바뀌었네요.

Adobe Flex는 GWT와 비교해서 다음과 같은 장점이 있었습니다.

  1. WYSIWYG한 레이아웃 편집환경

GWT는 버튼 같은 컨트롤을 만들 때 다음과 같이 코드에서 직접 처리해야 하고, 컴파일해서 돌려보기까지는 정확한 layout을 확인하기 어려웠습니다.

Button button = new Button(); 

button.SetPosition(100, 200);

그런데 Flex에서는 저와 같은 spoil된 개발자를 위해 다음과 같이 아름다운 WYSISYG한 편집 환경을 제공합니다

flex

2. GWT 대비 훌륭한 라이브러리 및 개발 환경

GWT대비해서 Adobe Flex Builder의 개발환경은 훌륭합니다. 각종 라이브러리 class들이 많아 웬만한 거는 다 있는 것 같습니다. 또, 개발 환경, 특히 디버거가 훨씬 편해서 개발 생산성이 쭉쭉 올라갑니다.

3. 빠른 속도

Javascript와는 다르게 컴파일된 binary 형태의 swf 파일이 브라우저의 flash plug-in(virtual machine) 상에서 동작하는 것이라 그런지 속도가 빠릅니다. 특히 사용자 중에 Internet Explorer 6 사용자가 많아서 JavaScript로 만들었을 때는 많이 느렸는데, flash는 무쟈게 빨랐습니다.

아.. 그런데 완벽해 보여 결혼해서 같이 살고 싶을 것만 같던 Flex도 같이 좀 지내보니 단점이 슬슬 보였습니다.

먼저 컴파일러가 안 좋습니다. 프로젝트 규모가 작을 때는 몰랐는데, 소스가 커지면서 컴파일 타임이 exponential하게 늘었습니다. 개발 초기에는 그냥 default 스타일(theme)을 사용하다가, 별도 css를 만들어서 스타일을 바꾸어주었습니다. 그리고, 코드 양도 늘어서 파일 20~30개에 약 10,000라인 정도의 소스 규모가 되었습니다. 이렇게 스타일 바꾸고 소스가 커지니 컴파일을 하는데, 예전 1분 미만에서 5분 넘게 걸리기 시작했습니다. Incremental compile 기능이 지원이 안되서, 한 줄 고치고 5분씩 기다리자니 spoil된 저로서는 짜증이 솟구치더군요.

그리고, 개발 생산성이 좋아지기는 했으나 아직 서버 쪽의 그것과는 차이가 났습니다.

결국 Flex에게 헤어지자고 해야 할 것 같았습니다.

3. Microsoft Silverlight

Flash 관련 기술을 보다 보니, MS의 Flash 대응 기술인 Silverlight에 눈이 갔습니다. Silverlight는 Flash와 아주 유사했습니다. 먼저 Presention을 위해서 XAML이라는 mark-up 언어를 사용합니다, 그리고, action은 C#을 통해서 정의하구요. 정리하면 다음과 같다고 할 수 있습니다.

Presentation(View) Action (Control) IDE
HTML + JavaScript HTML JavaScript
Flex MXML ActionScript Flex Builder(Flash Builder)
Silverlight XAML C# (or Visual Basic) Visual Studio + Expression Blend

역시 Silverlight는 다음의 단점을 제외하고는 앞 솔루션들을 압도합니다.

1. Visual Studio와 Expression Blend의 이원 체제

Visual Studio를 통해서 C# 파일 뿐만 아니라, XAML 파일을 에디팅할 수 있지만, XAML 관련해서 좀더 파워풀한 작업을 위해서는 Expression Blend 라는 별도의 에디터를 이용해야 합니다. 보통 큰 사이트 구축 시에는 Designer와 Programmer가 분리되어 있어서 이렇게 툴을 별도로 사용하는 것이 오히려 장점이 될 수 있지만, 저의 경우처럼 프로그래머가 알아서 다하는 경우에는 조금 귀찮습니다. –_-

2. Silverlight VM 설치

Flash의 경우에는 대부분의 사용자 컴퓨터에 plug-in이 설치되어 있기 때문에 부담이 되지 않았는데, Silverlight는 아직 minor인지라 브라우저에 Silverlight VM(plug-in)을 설치한 경우가 매우 드물었습니다. 사용자들에게 6메가 정도되는 VM부터 설치하게 하는 건 아무래도 쪼금 미안한 일입니다.

하지만 이런 단점에도 불구하고, 개발 생산성과 결과물의 품질 등을 생각해보면, RIA 솔루션 중에 Silverlight는 압도적으로 훌륭합니다. 특히, 일반 사용자를 대상으로 한 웹 서비스가 아니라, 특정 사용자나 또는 저와 같이 인트라넷용이라면 Silverlight는 최적의 선택이 아닐까 합니다.

지금은 결국 GWT로 되어 있던 것을 Silverlight로 바꾸었습니다. 그리고 이렇게 바꾸면서 재미있는 기능들도 많이 추가할 수 있었습니다. Silverlight으로 바꾼 직후 설문 조사를 통해 사용자 만족도를 조사했는데, 63%에서 78%로 상승하였습니다.

마치며…

최근에 HTML 5가 대세인 듯 합니다. Google, MS, Apple 모두 HTML 5에 배팅을 하고 있는 것 같습니다. Canvas, Video, Web worker 등등 놀랄만한 feature로 새롭게 무장한 HTML 5는 이전 버전의 HTML과는 확연히 차원이 다릅니다. Flash와 Silverlight에 뒤지지 않는 HTML 5로 만든 현란한 사이트, 게임 등이 선보이면서, 어떤 사람들은 Flash와 Silverlight는 이제 없어질 거라고 조심스럽게 예상합니다.

하지만, 개발자 입장에서 보면, Silverlight나 Flash가 제공하는 사용자 경험(User Experience)을 HTML 5로 구현하려면, 작업량은 적어도 5배 이상은 될 듯 합니다. Google 같이 훌륭한 프로그래머 군대를 갖추고 있는 경우면, 어느 솔루션이든 사용자에게 1%라도 좋은 것으로 선택을 하겠지요. 그러나, 한정된 개발 resource를 가지고 어느 정도 이상의 결과물을 만들어야 하는 대부분의 개발 조직의 경우에는 아직도 HTML 5가 요원해 보입니다. 때문에 아직 Flash나 Silverlight 등을 무시할 수 없는 것이 아닐까 합니다.

One thought on “RIA 개발 환경 비교 (GWT, Flash, Silverlight)

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s