'ria'에 해당되는 글 2건

  1. 2008.04.24 RIA를 알려주다
  2. 2008.04.24 RIA
RIA란 데스크톱 응용 프로그램의 특징과 기능을 가지는 웹 응용 프로그램
 
일반적으로 페이지의 새로 고침 없이 한 페이지에서 동작하는 웹 응용 프로그램
 
 

2.0이 인터넷 기술의 새로운 이슈로 등장하고 있다. 2.0과 관련된 여러 기술들 중 RIA는 웹 2.0을 완성하기 위한 사용자와의 접점으로서 많은 주목을 받고 있다.

 

백문이 불여일견! 우선 RIA로 구현된 사이트를 간단히 살펴보도록 하자.

RIA가 적용된 첫 번째 사례는 2002TravelClick(http://www.travelclick.net)에 의해 제작된 BroadMoor 호텔(http://www.broadmoor.com) OneScreen이라는 예약 시스템이다.


 


[브로드무어 호텔의 OneScreen 예약 시스템]

 

플래시와 콜드퓨전(CFML)로 만들어진 이 시스템은 기존의 5단계 페이지를 거쳐서 진행되었던 예약 업무를 플래시의 화려한 그래픽 사용자 인터페이스를 이용하여 한 페이지로 구현한 것이었다. 이것은 그 당시까지의 여러 페이지를 거쳐 시스템을 구현하던 웹 사용자 인터페이스의 새로운 전환을 가져오게 한 사건이었다.

 

국내 사례를 한번 살펴보자. Adobe의 플래시(Flash)를 이용하여 구현된 CGV 영화관(http://www.cgv.co.kr)의 예매 서비스로 페이지의 전환 없이 한 페이지에서 영화 정보 확인 및 예매를 할 수 있다.

 

 


[CGV 극장 영화 예매 시스템]

 

사용자 인터페이스의 향상과 더불어 사용의 편리성까지 제공할 수 있는 것이 바로 RIA의 가장 강력한 힘인 것이다.

 

 

RIA를 구현하려면

RIA를 구현하기 위해 다양한 웹 브라우저에서 동작하면서 개발자의 편의를 제공하려는 시도는 여러 업체들에 의해 지금도 계속 중이다. RIA를 구현할 수 있는 기술들을 살펴보면 다음과 같다.

 

l       AJAX/DHTML: 자바 스크립트와 XML을 이용한 비동기 호출을 사용하는 방식으로 웹 2.0에서 많은 주목을 받고 있는 기술의 조합이다. 현재 많은 업체에 의해 AJAX를 쉽게 개발할 수 있도록 툴 킷들이 공개되고 있다.

l       플래시(Flash): Adobe(이전 Macromedia)의 대표적인 벡터 방식의 그래픽 환경으로 현재 대부분의 브라우저에서 동작한다. 화려한 사용자 인터페이스를 구현하고, 액션스크립트(ActionScript)를 이용하여 비즈니스 로직을 구성할 수 있다.

l       플렉스(Flex): Adobe가 소개한 엔터프라이즈 개발을 위한 플랫폼으로 플래시의 SWF로 그 결과물을 출력하나 플래시와는 완전히 다른 새로운 기술이다.

l       오픈라즐로(OpenLaszlo): Laszlo System에 의해 시작된 오픈소스 플랫폼으로 RIA 구현을 위해 사용할 수 있으며, LZX라는 새로운 인터페이스 언어를 사용한다. 그 결과물은 플래시 플레이어에서 동작하는 SWF 파일로 출력된다.

l       WPF: Microsoft에서 새롭게 소개하는 차세대 벡터 방식의 그래픽 환경으로WPF/E를 활용하여 RIA를 구현할 수 있으며, XAML Jscript의 기반한 프로그래밍 모델을 가진다.

l       XUL: XML 기반의 사용자 인터페이스 마크업 언어(User Interface Markup Language)로 모질라(Mozilla) 기반의 웹 브라우저에서 HTML/XHTML을 대신하여 사용할 수 있다.

l       액티브X(ActiveX): 윈도우 응용 프로그램을 웹 페이지상에 실행할 수 있는 기술로 마이크로소프트에 의해 소개되었다. 인터넷 익스플로러(IE)에만 동작하는 단점을 가지고 있다. 또한 다른 방식의 RIA 구현과는 다르게 일반적으로 클라이언트에 설치되어 실행하기 위해서는 공인 인증서를 발급(유료)받아야 하는 번거로움이 있다. 물론 브라우저 설정에 따라 이런 과정 없이 설치 및 실행할 수 있으나 클라이언트의 자원을 제어할 수 있는 보안의 취약성이 큰 문제를 발생하기도 한다.

l       스마트클라이언트(SmartClient): Microsoft의 닷넷(.NET) 기반의 윈도우 프로그램을 웹 상에서 실행할 수 있는 기술이다. 보안설정과 클라이언트에 닷넷 프레임워크의 설치가 필수이다.

l       자바 애플릿(Java applet): 자바 응용 프로그램을 웹 페이지 상에서 실행할 수 있는 기술로 오래 전부터 사용되었다. 다양한 클라이언트의 제어를 할 수 있는 장점에도 불구하고, 느린 속도와 대체 가능한 기술들에 의해 그 사용이 점점 줄어들고 있는 상황이다.

l       자바 응용프로그램(Java application): 자바 웹 스타트(Java Web Start)는 자바 응용 프로그램 자체를 웹을 통해 클라이언트에서 실행할 수 있도록 허용한다. 웹을 통해 자바 응용 프로그램을 실행하는 방식으로 RIA를 구현할 수 있다.

 

이들 중 현재 주류를 이루는 RIA 기술로는 HTML 기반의 RIA 구현에 주로 사용하고 있는 AJAX/DHTML과 화려한 사용자 인터페이스를 구현할 수 있는 플래시가 있다. 새로운 RIA 시장을 선도하기 위해 경쟁적으로 펼치고 있는 새로운 개발 툴의 출시는 정말 흥미진진하게 보인다. 어떤 RIA 기술이 일반 사용자들에게 매력을 줄 것인지, 어떤 개발 툴이 가장 많이 선택 받을지 관심을 가지고 지켜보도록 하자.

 

 

RIA(Rich Internet Application)?

Rich Internet Application(RIA)이란 전통적인 데스크톱 응용 프로그램의 특징과 기능을 가지는 웹 응용 프로그램이다. 웹 응용 프로그램의 많은 장점에도 불구하고 웹 초창기부터 서버/클라이언트 환경의 윈도우 프로그램에 비해 사용자 인터페이스가 부족하다고 지적되어왔다. 이런 단점을 극복하기 위해 Macromedia(현재 Adobe) 2002년 리치 인터넷 애플리케이션(RIA)을 처음으로 소개하였다.

 

RIA를 한 마디로 표현한다면 한 페이지로 구현된 웹 응용 프로그램이라 할 수 있다. 실제 많은 비즈니스 로직이 존재하지만 사용자는 한 페이지를 이용하여 모든 기능을 이용하게 된다. 일반적인 웹 페이지의 페이지 이동과 새로 고침의 깜박임 없이 모든 내용의 확인과 기능을 이용할 수 있는 RIA. 매력적이지 않은가?

 

 

RIA인가?

그러면 RIA를 왜 사용하는 것일까? 그 첫 번째로 우리는 웹 응용 프로그램이 가지는 한계점에 대해서 먼저 이해해야 한다. 전통적인 웹 응용 프로그램의 모델은 서버를 중심으로 모든 처리가 수행되고, 사용자의 웹 브라우저를 통해 그 결과를 출력하는 구조로 이루어진다. 우리는 이를 씬 클라이언트(thin client)라 부른다. 즉 클라이언트는 단순히 결과의 디스플레이에만 사용하는 것이다. 그렇기 때문에 서버에서 많은 작업 프로세스가 있는 경우 사용자는 결과가 처리될 때 무작정 기다려야만 하고, 서버의 처리시간이 길어지는 경우 서버와의 통신이 끊어져 더 이상 프로그램을 이용할 수 없는 상황이 발생할 수 있다. 이런 단점을 보안하고, 사용자 인터페이스를 향상하기 위한 시도가 바로 RIA인 것이다.

 

그렇다면 RIA를 사용하여 얻을 수 있는 장점이 과연 무엇일까?

 

대표적으로 리치(rich)한 클라이언트 사용자 인터페이스 제공이 있다. RIA 방식으로 구현하면 사용자에게 HTML 위젯(widget)을 사용하는 효과 이상의 보다 그래픽적인 사용자 인터페이스를 공급할 수 있다. 예를 들어, 웹 페이지에서 드래그 & 드롭(drag & drop)이 가능하고, 슬라이드 바를 이용하여 데이터 변경이 가능하게 된다. 또한 클라이언트에 비즈니스 로직 부분을 구현하여 복잡한 계산을 서버가 아닌 클라이언트에서 수행할 수 있다. 그렇기 때문에 일반적으로 보다 향상된 서버의 응답을 구현.할 수 있는 것이다.

 

이처럼 RIA를 사용하면 사용자 인터페이스의 향상뿐만 아니라 성능 향상의 장점을 가질 수 있다. RIA에서는 서버와 클라이언트 사이의 부하의 분산이 가능하게 되어 서버의 성능 향상에 도움을 주는 것이다. 또한 비동기 통신(asynchronous communication)을 이용하여 사용자에게 보다 빠른 응답속도를 보이는 것처럼 구현할 수 있다. 사용자가 클릭 하였을 때 그 결과를 미리 비동기 통신으로 저장한 뒤 바로 보여줄 수 있으므로 사용자가 느끼는 체감 속도는 상당히 빨라지고, 서버의 응답 이전에 다른 작업을 수행할 수 있다. 이는 구글 맵(Google Maps)에서 쉽게 확인할 수 있는 방식으로 사용자가 지도를 드래그하면 바로 처리가 되는 것을 확인할 수 있다.

 

 


[구글 맵 서비스 (http://maps.google.com)]

 

마지막으로 네트워크 효율성이 있다. 전통적인 웹 응용 프로그램의 방식은 새로운 결과를 표현하기 위해 전체 페이지의 정보를 전달하고 그 결과를 클라이언트에 다시 보여준다. 하지만 RIA 방식을 이용하면 해당 페이지에서 실제 필요한 일부분의 데이터만 서버로 전달하고, 그 결과를 클라이언트 페이지의 일부 영역에 반영할 수 있기 때문에 네트워크 자원의 사용량도 감소하는 것이다.

 

더불어 RIA 방식은 초기 프로그램 구동에 시간이 소요된다는 단점이 있지만, 반면에 프로그램 설치가 필요 없다는 장점을 갖고 있다. 그렇기 때문에 사용자들은 어디에서나 쉽게 사용할 수 있고, 프로그램의 버전이 올라가더라도 쉽게 배포할 수 있는 것이다.

 

이처럼 RIA는 사용자 인터페이스 개선 및 성능 향상이라는 두 마리의 토끼를 잡을 수 있는 현재 진행형의 기술이다. 물론 개발의 난이도가 높아지는 문제가 있지만 사용자들은 이런 개발자들의 고충은 모른다. 자신들이 사용하기 쉽고, 매력적인 프로그램을 선택할 것은 뻔한 이야기라는 것이다.

 

-------------------------------------------------------------------------------------------------------

RIA의 역사

RIA 2002Macromedia에 의해 소개되었지만 개념적으로 유사한 내용들은 이전에도 있었다. 1998 Microsoft Remote Scripting을 소개하였고, 2000 Forrester Research X Internet을 소개하였다. 더불어 리치 클라이언트, 리치 웹 클라이언트 또한 RIA와 유사한 기술적인 분류로 이야기할 수 있다.

 

그러던 중 2002년에야 비로서 RIA의 실제 적용사례가 소개된다. 앞서 이야기한 플래시와 콜드퓨전(CFML)을 이용한 TravelClickBroadmoor 호텔의 OneScreen이라는 예약 시스템이었다.

 

2004년에는 Macromedia는 플렉스를 엔터프라이즈 개발자를 위한 새로운 플랫폼으로 소개하였다. 기존 플래시가 가졌던 단점을 해결하고 새로운 RIA 개발 환경을 위해 새로운 서버 제품으로 출시하였다. 현재 2.0 버전까지 출시되었으며, 국내외 여러 적용 사례들이 있다.

 

이러던 중 RIA2005년 구글에 의해 사용자들에게 강렬한 인상을 남기게 된다. 바로 구글 맵(http://maps.google.com/) 서비스를 통해 웹 지도에서 드래그, 줌 인/줌 아웃이 구현하였고, 부드러운 화면 전환 및 스크롤을 제공하였다. 이는 마치 윈도우 프로그램을 사용하고 있다는 착각을 가지게 한 아주 충격적인 사건이었다.

 

이후 웹 2.0에 대한 소개와 실제 구현 사례들을 통해 RIA는 웹 비즈니스의 중요한 요소로 성장하였다. ‘사용자의 눈을 만족시키지 못하는 서비스는 성공하기 힘들다는 이야기처럼 지금도 사용자들에게 새로운 모습을 보여주기 위하여 여러 웹 사이트들이 RIA를 채택하고 발전을 위한 노력을 계속하고 있는 것이다.

-------------------------------------------------------------------------------------------------------

 

도스 환경에서 윈도우 프로그램을 처음 사용하였을 때의 GUI 변화에 대한 충격을 기억하는가? 내년에는 윈도우 XP에서 윈도우 Vista로의 새로운 GUI 환경 변화가 우리를 기다리고 있다. 또 얼마나 많은 충격과 변화가 일어날지 아직까지는 느낄 수 없을 것이다. 하지만 분명 변화는 이미 시작되었다는 것이다.

 

사용자에게 보다 멋진 GUI 환경을 제공하려는 시도는 운영체제, 웹의 구분 없이 계속 될 것이다. 이와 함께 사용자 경험에 아주 밀접한 관계가 있는 RIA는 향후 웹 비즈니스 구현에 가장 중요한 기술로 거듭 자리매김을 할 것이다. 지금의 RIA는 과도기의 모습이다. AJAX와 같은 기술은 잠시 스쳐 지나가는 하나의 흐름일 뿐이다. 앞으로 웹 환경은 벡터 그래픽 환경이 기본이 되고, 3D를 이용한 실제 체험이 가능한 모습으로 변화할 것으로 필자는 확신한다. 쇼핑몰을 이용하면서 자기의 3D 캐릭터에 직접 옷을 입혀본 뒤 제품 구매를 선택하고, 다양한 각도에서 실제 물건 보듯이 살펴볼 수 있는 서비스가 바로 눈앞에 있는 것이다. 여러분들은 RIA와 웹의 미래 모습이 어떨 것이라 생각하는가?

 

출처: 스마트플레이스

Posted by euNey^0^
TAG ria

댓글을 달아 주세요

RIA

computer engineering 2008.04.24 10:58 |

출처:http://www.ibm.com/developerworks/kr/library/dwclm/20070612-2/
글쓴이: 김도형

RIA(Rich Internet Application)는 웹 서비스의 장점은 유지하면서 기존 웹 브라우저 기반 인터페이스의 단점인 늦은 응답 속도, 데스크톱 애플리케이션에 비해 떨어지는 조작성 등을 개선하기 위한 기술을 말한다. 원래 2002년에 매크로미디어(2005년에 어도비가 매크로미디어를 인수했다)가 자사의 플래시를 활용한 웹 인터페이스를 지칭하기 위해 만들어낸 용어지만, 관련된 시도는 이미 1990년대 말부터 있었으며 지금은 AJAX, 플래시, 자바 애플릿 등 얼핏 연관 없어 보이는 기술을 통칭하는 느슨한 용어로 쓰이고 있다. 최근 마이크로소프트는 실버라이트(Silverlight)라는 RIA 기술을 소개하면서 Rich Interactive Application이라고 풀어 쓰기도 하니 참고하자.
원래 문서 형태로 공유하기 위해 만들어진 웹이 졸지에 애플리케이션 플랫폼 역할까지 하다 보니 여러 장점에도 불구하고 슬슬 사용성 등에서 불만이 터져 나올 때가 되기는 했다. 이런 상황에서 최근 업계에서는 RIA라는 이름 하에 다양한 솔루션을 내어 놓고 있지만 가만히 살펴보면 각양각색이다.
구글은 AJAX를 바탕으로 가능한 브라우저 기반 서비스를 개발하는 것으로 유명하다. 특별한 경우가 아니면 플래시 사용까지도 자제한다. 최근에는 아예 브라우저에 없는 요소를 추가로 개발, 공개해 개발자를 자기 편으로 끌어 모으는 좀 더 적극적인 전략을 펴고 있다. 한편 플래시라는 훌륭한 무기를 가지고도 어딘지 밀리는 느낌이 들었던 어도비도 최근 자사 소프트웨어 일부를 오픈소스로 풀면서 상황 반전을 꾀하고 있고, 썬으로 대표되는 자바 진영, 그리고 마이크로소프트도 본격적으로 RIA 시장에 뛰어들었다.
그야말로 차세대 애플리케이션 플랫폼 정복을 위한 RIA 전쟁의 시작이라 해도 과언이 아닐 것이다. 하지만 RIA를 외치는 오늘에는 그에 이르게 한 과거와 배경이 있고, 각 해법에는 자기 입장대로의 꿍꿍이 속이 있고 허점이 있기 마련이다. 이 시점에서 오늘에 이르게 된 배경을 살피고 그를 바탕으로 각 기술의 장단점과 허점을 조명해 보는 것은 나름대로 의미가 있을 것이다.



위로



서비스 구조 변천사

개인용 컴퓨터의 성능이 비약적으로 발전한 오늘날도 우리는 여전히 서버에 접속하고 있다. 초기에는 혼자 쓰기에는 컴퓨터가 너무 비싸서 공유해야 했고, 컴퓨터가 어느 정도 대중화된 후에도 기업 내에서 정보를 통합 관리하고 공유할 필요가 있었다. 이 때문에 서비스를 제공하는 컴퓨터와 사용자가 접하는 단말까지를 어떻게 구성해야 하는가에 대해 다양한 시도가 있어 왔다.

터미널 시대
1970년대에 등장해 메인프레임 내지 서버에 직렬 통신으로 연결돼 서버가 전달하는 문자나 제어 문자를 해석해 화면에 뿌려주고 사용자가 입력하는 키를 서버로 전달해 주던 텍스트 터미널이나, 1990년대 전성기를 맞아 얼마 간의 CPU와 메모리, 흑백 내지 컬러 그래픽 장치와 키보드, 마우스를 장비하고 그저 LAN으로 연결된 서버가 보내는 명령을 해석해 그림을 그리고 키/마우스 입력을 서버로 보내기만 했던 X 터미널(X11 기반)은 그저 단말 가격조차 부담스럽던 시절, 단말의 기능을 최소화하려는 노력이었다.
하지만 이런 구조는 웹 애플리케이션과 마찬가지로 단말 관리가 쉽고 애플리케이션을 갱신하는 부담이 없다는 숨은 장점이 있었다. 거기다 조작성도 좋았다. 이 때문에 씬 클라이언트(thin client) 개념이 대두되면서 윈도 터미널의 등장으로 한번 더 조명을 받게 되는데 불행히 그 장점만 내세우기에는 시대가 한참 앞서나간 후였다.

팻 클라이언트 시대
그 후 클라이언트/서버 구조, 다운사이징이 화두가 되면서 굳이 다수가 공유하는 정보가 있거나 서버만 처리할 수 있는 특수한 일이 아니면 업무를 클라이언트 측에서 분산 처리하게 됐다. 그러다 보니 클라이언트 애플리케이션이 오늘날의 데스크톱 애플리케이션과 마찬가지로 작성돼야 했다. 따라서 최소한 응답성과 사용성은 비교적 만족스러웠다. 하지만 패키지 소프트웨어와 달리 서비스를 위해서는 전용 애플리케이션이 있어야 했고 변경이 잦아야 했기에 파워빌더, 델파이, 비주얼 베이직 같은 RAD(Rapid Application Development)가 전성기를 누렸다.

웹 애플리케이션 시대
이러던 것이 웹이 등장하면서 웹 브라우저를 범용 클라이언트로 사용하는 웹 애플리케이션 개념이 주목을 받기 시작했다. 웹 브라우저는 많은 사람들이 익숙한 클라이언트였고 OS 등 플랫폼을 타지 않았다. 굳이 별도로 애플리케이션을 배포, 갱신할 필요도 없었으며 무엇보다도 정형화된 시스템 구조와 개발 절차를 제시함으로써 서버 및 클라이언트 쪽 모두를 아우르는 전체 시스템 개발과 테스트 복잡도를 낮춰주었다. 또한 적절한 규모의 기업 시스템은 물론이고 대규모 인터넷 서비스에도 잘 맞았다. 하지만 결국 다시 사용성과 응답성이 문제가 되기 시작했고, 네트워크가 끊어졌을 때도 사용할 수 있었으면 좋겠다는 요구가 자연히 머리를 들게 되었다. 이 때문에 나온 개념이 RIA다.

웹을 건너뛸 수도 있었던 자바
이런 흐름 속에서 놓쳐서는 안 되는 것은 자바의 등장과 데스크톱에서의 실패다. 물론 자바 UI 수요가 없다는 말은 아니니 민감하게 반응하지 말자. 하지만 자바 초기에 썬은 분명 모든 자원을 서버 쪽에 쏟았고 그 때문에 데스크톱 플랫폼으로서 자바는 분명히 부족했으니 말이다.
사실 자바는 제대로만 움직였다면 “X 인터넷”에서 이야기하는 실행 가능한 객체로 구성된 인터넷 시대의 만국 공통어가 됐을지도 모른다. 개인적으로는 1995년 자바 애플릿을 처음 접했을 때 HTML을 중심으로 하는 웹의 종말을 머리에 떠올렸다. HTML 기반의 밋밋한 웹 페이지(당시 HTML은 특히 그랬다)를 화려하게 바꿔 놨던 자바 코드는 알고 보면 웹 브라우저의 테두리를 벗어나서도 존재할 수 있었고, 클라이언트 소프트웨어 배포 문제를 해결함과 동시에 웹 브라우저의 제한된 틀을 언제든지 깨어버릴 수 있는 잠재력이 있었다. 막말로 HTML이 맘에 안 들면 뭔가 다른 형식을 만들고 그 브라우저를 자바로 만들어 배포하면 그만이 아닌가.
실제 썬은 순수하게 자바로 작성되고 확장 가능한 핫자바(HotJava)라는 브라우저와 함께 자바를 세상에 데뷔시켰고, 자바로 애플리케이션을 돌리는 디스크 없는 네트워크 컴퓨터를 만들어 이러한 기대를 일부 현실화하려고 노력했다. 물론 실패했지만 말이다. 이러한 자바의 실패에서는 배울 점이 많다. 뒤에 언급하겠지만 요즘 RIA 바람을 타고 자바도 이 분야에서 재기를 노리고 있다. 하지만 성공 여부는 미지수다.

미래는?
2000년 시장 조사 회사인 포레스터(Forrester Research, Inc.)는 "X 인터넷"이라는 개념을 주창했다. 문서를 교환하는 웹의 시대는 가고 실행 가능한 객체에 기반한 더 나은 상호작용과 더 풍부한 경험을 얻을 수 있는 새로운 인터넷의 시대가 올 거라고 예측했다(http://www.forrester.com/ER/Marketing/0,1503,214,00.html). 흔히 "X 인터넷"을 RIA 개념을 최초로 제시한 것으로 보기도 해서 RIA와 “X 인터넷”을 동의어로 취급하기도 한다. 하지만 자세히 읽어 보면 자바 같은 모델에 가까운 좀 더 구체화된 비전 제시라고 볼 수 있다. 그렇다면 오늘날 RIA가 만족시켜야 할 요구사항은 무엇일까? 포레스터의 예측처럼 실행 가능한 인터넷의 시대가 올까? 아니면 기존 웹의 틀을 가능한 지키되 보완해 나가는 형태가 될까?



위로



RIA가 갖춰야 할 덕목

과거와 현재까지 이어지는 흐름을 볼 때 새로 등장하는 RIA 전쟁의 승자는 어떤 덕목을 갖춰야 할까?

애플리케이션의 쉬운 배포
클라이언트 쪽에 많은 기능이 실리기 시작하면서 굳이 별도로 배포할 실체가 없던 이전 터미널 시대에는 겪지 못했던 문제가 대두했으니 바로 “애플리케이션 배포” 문제다. 다양한 형태와 구성의 단말에 항상 최신 소프트웨어 패키지를 배포, 설치하는 것은 생각보다 골치 아픈 문제다. 여기서 몇 년에 한번씩 업그레이드되는 패키지 소프트웨어를 떠올렸다면 곤란하다. 서비스 애플리케이션은 항상 새로운 요구 사항, 오류 등으로 지속적으로 갱신되기 마련이다. 웹 애플리케이션이 각광을 받기 시작한 이유 중 하나는 브라우저만 설치돼 있으면 별도로 애플리케이션을 배포하거나 설치할 필요가 없기 때문이었다.

조작성, 빠른 반응 속도
사실 기존 웹 애플리케이션의 조작성과 반응 속도는 이전 터미널이나 데스크톱 애플리케이션에 가까운 팻 클라이언트(fat client)에 비해 좋지 않았던 것이 사실이다. 마우스로 링크나 버튼을 클릭하고 폼을 채워 넣어야 하는 구질구질한 인터페이스는 그렇다고 치고, 항상 뭔가 변화를 보기 위해서는 서버에 접속해 처리한 후 결과를 가져와야 한다. 이런 단순한 모델은 웹을 작은 조직을 대상으로 한 서비스부터 인터넷을 매개로 한 거대한 규모의 서비스까지 두루 적용할 수 있게 한 힘이었지만 가장 큰 약점이 되기도 했다. 데스크톱 애플리케이션 수준의 조작성과 반응 속도 개선은 다름아닌 RIA를 대두시킨 주된 모멘텀 중 하나다.

오프라인 사용성
최근 네트워크 사정이 괜찮아졌다지만 그와 동시에 사람들은 더 이상 컴퓨터를 책상 위에 놔 두지만은 않게 됐다. 개인용 컴퓨터 시장의 대세는 노트북 컴퓨터고 이동성이다. 네트워크만 달랑 끊어지면 속수무책이 되어서는 이런 시대에 살아 남기가 난감하다. 개인적으로 무료면서 쓸만한 일정 관리 프로그램을 찾으면서도 구글 캘린더 같은 온라인 서비스를 이용하지 않는 이유는 바로 오프라인 사용이 불가능하기 때문이다. 물론 이런 상황은 최근 구글이 발표한 구글 기어의 등장으로 나아질 기미는 보이고 있다.

풍부한 미디어
PC와 웹의 발전이 상호 견인한 가장 큰 변화는 그 어느 때보다 미디어가 풍부한 환경을 대중화했다는 점이다. 개인 영역은 물론이고 업무 영역에서도 동영상, 애니메이션 등을 수반하는 풍부한 미디어가 일상적이게 되었다.

플랫폼 독립성
이제 더 이상 PC 하나만을 지원해서는 안 되는 시대가 왔다. 리눅스, 맥 등 다른 플랫폼을 사용하는 삶들도 존중 받아야 한다. 또 요즘 휴대전화에는 대부분 WAP 브라우저와 자바가 탑재되어 있고, 최근에는 HTML 4.01을 지원하거나 일반 웹 사이트를 브라우징 할 수 있도록 풀 브라우징(full browsing) 개념까지 들어가고 있다. DTV에도 휴대전화보다는 데스크톱에 가까운 자바와 HTML 브라우저가 탑재되고 있다. 그뿐 아니라 최근 나오는 HD-DVD는 XHTML에 SMIL 등이 탑재되어 있으며, 경쟁자인 블루레이(Blu-Ray)에는 DTV와 비슷한 형태의 자바가 탑재된다. 앞으로는 동일한 서비스를 휴대전화는 물론이고 PDA, TV 등 다양한 형태의 똑똑한 단말에서 사용할 수 있어야 할 것이다.

콘텐츠 친화적인 구조
보통 RIA는 “X 인터넷”에서 제시한 미래와는 달리 HTML 기반의 웹을 대체하는 수단으로 거론되고 있지는 않다. 문서 교환 구조인 웹과는 달리 애플리케이션 플랫폼으로서 별도의 영역을 구축할 것이라는 것이 일반적인 예측이다. 하지만 개인적으로는 RIA도 상당 경우 문서나 각종 미디어 콘텐츠를 담게 될 것이고 이런 경우 기존 웹만큼이나 검색, 링크에 의한 외부 참조 등이 중요해질 것이라고 생각한다.

웹 인프라의 활용
소규모에서 전세계적인 규모의 서비스까지 가능하게 한 웹 서비스의 단순한 구조적인 특성은 당연히 살려야 할 것이다. 단말 내부에서 어떤 형식으로 서비스가 구현되든 서버와의 연결은 기존 웹 서비스의 틀을 지켜야 할 것이다.



위로



어떤 요소가 필요한가?

앞서 언급한 덕목을 갖추기 위해서는 단순히 단말 쪽에 그럴 싸 해 보이는 그래픽을 표시하는 것만으로는 부족하다. RIA를 둘러싼 환경에 어떠한 요소가 필요할지를 생각해 보자.

저작 도구
뜬금 없이 저작 도구가 튀어 나와 어리둥절해 할지도 모르겠다. 개발 도구도 아닌 저작 도구다. 콘텐츠가 아닌 웹 애플리케이션의 경우인데도 개발 과정에 UI 전문가, 디자이너 등 개발자가 아닌 다양한 사람이 참여하는 것이 일반적이다. 더욱이 일반적인 데스크톱 애플리케이션과 과거 팻 클라이언트가 명백히 차이를 보였듯이 서비스를 위한 RIA는 계속 새로 만들어지고 더 자주 변경될 것이 분명하다. 기획 단계에서 UI 동작 때까지 복잡한 하부 로직이 붙기 전의 UI는 굳이 프로그래머가 참여하지 않더라도 쉽게 작성하고 동작해 보고 피드백 받을 수 있어야 한다. 또한 앞서 언급했듯이 풍부한 미디어가 어우러져야 하는 것은 당연하다. 이런 상황에서 도구 지원이 부실해서는 시작하기도 전에 지는 셈이 될 것이다.

플랫폼 독립적인 고속 실행 엔진
자바와 같은 플랫폼 대비 웹 브라우저의 장점은 상대적으로 단순하면서도 플랫폼 독립적이고 어디서나 비교적 동일하게 동작한다는 점이었다. 하지만 그건 웹 초기의 이야기일 뿐이다. 이미 최근 웹 애플리케이션이 브라우저를 혹사하는 수준은 도를 넘었다. 브라우저마다 다른 온갖 기능을 다 끌어다 쓰고 어마어마한 분량의 스크립트가 브라우저에서 실행된다.
주요한 하나 이상의 브라우저에서 제대로 표시되는 웹 페이지를 만들라 치면 사실상 브라우저 별로 페이지를 따로 작성하는 것과 마찬가지가 되는 경우가 허다하다. AJAX를 화려하게 구사하는 구글 서비스들도 사실 알고 보면 쉬운 일을 무척 고통스럽게 하고 있다고 볼 수도 있다(http://skyul.tistory.com/175).
그뿐인가? 이제 브라우저에서 실행되는 로직의 복잡도가 높아져 그저 스크립트 몇 줄만 실행하면 될 거라고 생각하고 만들어 놓은 스크립트 엔진들의 성능에도 빨간 불이 켜지고 있다. 최근 모질라에서는 어도비에서 기증 받은 코드로 이른바 자바스크립트 가상기계라는 것을 만들어 자바처럼 기계어로 JIT(Just-In-Time) 컴파일도 한단다. RIA 내에서는 말 그대로 포맷이 있는 문서를 표시할 일이 있는 경우가 아니라면 스크립트를 빼곡히 박아 넣은 HTML 페이지는 배제해야 하지 않을까 한다. 논쟁의 여지가 있겠지만 개인적으로는 자바나 .NET CLR(Common Language Runtime) 같은 플랫폼 독립적인 고속 실행 엔진과 잘 디자인된 라이브러리를 기반으로 하되 UI 설계시는 XML 등으로 구성된 보조적인 문법을 지원하는 편이 맞는 방향이라고 생각한다.
이는 오프라인 사용성 측면에서도 마찬가지인데 오프라인에서 동작하려면 필연적으로 단말 단의 처리 로직이 복잡해질 수 밖에 없다. 이런 경우 프로그램 로직 작성을 위한 튼튼한 기반을 가지고 있는 편이 아무래도 유리하다. 원래 서버 쪽에서 많은 처리를 하는 웹 애플리케이션이 오프라인 상태에서 동작할 때 서버 쪽 로직까지 가져올 수는 없는 법이다. 단순히 일부 자원을 단말 쪽에 가져다 둔다고 만사 해결되는 것은 아닐 테니까 말이다.

작은 플랫폼
RIA 플랫폼도 널리 퍼지려면 어쨌든 배포를 해야 한다. 이를 위해서는 RIA 플랫폼이 공룡이 되어서는 곤란하다. 초기 자바는 기능이 너무 부족해서, 그리고 오늘날에 와서는 수십 MB짜리 공룡이 된 것이 RIA 플랫폼으로 눈에 들지 못하는 것이 아닐까 한다. 어디까지가 적절한 선인지는 단언할 수 없지만 RIA에서 접근 가능한 라이브러리는 신중하게 작게 유지되어야 할 것이다. 또, 플랫폼이 커지면 거기에 수반하는 어려움이 있기 마련이다. OS가 바뀌거나 했을 때 미묘하게 다르게 동작한다거나 기능이 확장됐을 때 모든 플랫폼을 지원하기가 어려워지기도 한다. RIA 플랫폼은 데스크톱의 모든 애플리케이션을 작성할 수 있는 만능 플랫폼일 필요는 없다.

UI 및 기타 프레임워크 및 컴포넌트
RIA를 만드는 사람들은 맥가이버가 아니다. UI나 네트워킹, 데이터 처리 등의 동작을 하기 위한 컴포넌트들이 잘 디자인된 프레임워크 위에 풍부하게 제공되어야 한다. 이런 프레임워크의 존재는 다양한 컴포넌트들이 추가로 개발되고 공유될 수 있는 토양을 마련해 준다는 점에서 매우 중요하다.

미디어 엔진
풍부한 미디어는 RIA에서 필수적인 덕목이 되었다. 이런 관점에서 최소 비디오, 오디오의 효율적인 통합이 불가능해서는 게임이 되지 않는다. 최근 플래시의 약진이 다름 아닌 유튜브(YouTube) 등이 사용해 널리 알려진 플래시 비디오에 있다는 점을 잊지 말자.



위로



각 기술들의 허와 실

최근 많은 RIA 플랫폼이 출사표를 던졌다. 개인적으로 제한된 경험과 지식으로 이들을 판단하고 누군가의 손을 들어주기에는 무리가 있을 것이다. 또한 기술적인 면 이외에 플랫폼의 성공에 영향을 끼칠 수 있는 다양한 요소가 있으니 이 글에서의 평가는 그저 개인적인 평가라고 생각하고 참고만 하길 바란다.

어도비 플렉스/아폴로
RIA라는 말을 먼저 만들어 낸 어도비는 플래시라는 든든한 배경을 바탕으로 일찌감치 플렉스(Flex)라는 제품으로 RIA 시장에 뛰어들었다. 플렉스는 플래시 플레이어를 런타임 엔진으로 사용하며, 개발시 이미 만들어진 풍부한 컴포넌트를 MXML이라는 마크업 언어와 액션스크립트로 배치하고 이어 붙여 두면 최종적으로 플래시 파일 형식으로 컴파일된다. 그뿐 아니라 웹 서비스 등 다양한 데이터 소스와 UI 컴포넌트에 쉽게 연결할 수도 있다.
어도비의 장점은, 저작 도구에 가까운 도구를 가장 잘 만든다는 점과 최상의 RIA 플랫폼이라고 하기 어렵지만 버전 9까지 오면서 꾸준히 발전시켜 왔고 인터넷에 연결된 PC의 97%에 설치되어 있다는 점을 자랑하는 플래시 플레이어라는 플랫폼을 가지고 있다는 점이다. 플래시는 비디오 등 미디어 지원에 있어서도 뛰어나다.
하지만 반면에 어도비는 프로그래밍 도구나 제대로 된 단말 플랫폼, 서버 제품 등을 만드는 데는 아무래도 약점이 있다. 이런 탓에 어도비는 부쩍 오픈소스 커뮤니티와의 연대를 꾀하고 있다. 지난해 11월에는 플래시 플레이어 9에 들어 있는 액션스크립트 엔진인 AVM2(ActionScript Virtual Machine 2)를 모질라 쪽에 기여해 타마린(Tamarin)이란 이름의 프로젝트(http://www.mozilla.org/projects/tamarin)를 시작하더니, 결국 4월에는 플렉스까지 오픈소스로 공개했다.
거기다 올 초 DEMO 07에서 아폴로(Apollo)라는, 브라우저가 별도로 필요 없는 RIA 플랫폼을 데모했는데 그 자체가 오픈소스는 아니지만 내부 HTML 엔진은 오픈소스인 웹킷(맥의 사파리, KDE의 KHTML 브라우저에 사용하는 HTML 툴킷이다)을 사용하고 있으며 아폴로 개발에 따른 결과를 역으로 기여도 할 예정이란다.
이 플랫폼은 RIA 내에서 HTML을 자유롭게 사용하고 PDF 등 어도비가 가지고 있는 자원을 다 통합할 예정이다. 또, 궁극적으로 파일 I/O 등의 API를 추가해 완전한 런타임 시스템으로 거듭나려고 하고 있다.
개인적으로는 저작 도구의 지원이라는 측면에서 HTML, 플래시를 비롯한 많은 도구를 가지고 있다는 점에서 비교적 높은 점수를 주고 싶다. 하지만 궁극적으로 컴포넌트를 확장하는 사람이 늘고 단말 쪽 로직이 복잡해질 경우는 필연적으로 전문 프로그래밍 도구에 대해 목마르기 마련이다. 이런 경우 결정적인 약점이 드러나게 될 것이다. 또 한 가지 약점은 그저 벡터 그래픽에 부수적으로 붙어 있는 스크립트를 수행하기 위한 아주 기본적인 스크립트 엔진에서 시작해 큰 비전없이 확장해 온 플래시 엔진이다. 과연 얼마나 복잡한 일을 단말 측에서 하게 될 지가 관건이지만 과연 액션스크립트를 돌리는 가상 기계가 궁극적으로 성능이나 멀티쓰레딩 등을 수반하는 프로그래밍 모델에서 JVM이나 .NET CLR과 경쟁을 할 수 있을지는 의문이다. 연계된 문제점으로서는 애당초 완전한 플랫폼으로 시작하지 않은 플래시가 파일 I/O 등 API들을 붙여 나간다고 했을 때 이미 완전한 API를 정의해 충분한 시간 동안 발전해 온 타 플랫폼에 비해 역부족이지 않을까 한다.
개인적인 평을 하자면, 어도비의 접근법은 웹 상에서 플래시 플레이어의 궁극적인 경쟁자가 나타나 승승장구하지 않는 한 웹사이트의 UI를 풍부하게 하는 용도로는 활발하게 사용될 것이라고 본다. 하지만 브라우저 밖으로 벗어나는 아폴로 같은 접근법은 그다지 성공할 것 같아 보이지 않는다. 아울러 플래시도 계속해서 약점을 보강해 나가지 않는다면 어느 이상의 복잡도를 가진 웹 UI에서조차 선두를 빼앗길 수 있을 것이다.

마이크로소프트 실버라이트
한편 4월 30일부터 5월 2일까지 미국 라스베가스에서 열린 마이크로소프트의 MIX 컨퍼런스를 전후해서는 실버라이트라고 부르는 기술이 선보였다. 윈도 비스타에 포함된 WPF(Windows Presentation Foundation)의 축소판으로 코드명이 WPF/E(E는 Everywhere)였던 실버라이트 1.0은 XAML과 JScript 기반으로 벡터 그래픽 기반의 화려한 UI를 갖추고, 윈도 미디어를 통합, 답답한 버퍼링 없이 매끈하게 돌아가도록 했다. XAML은 일면 플렉스의 MXML과 비슷한 면도 있어서 플래시의 경쟁자임과 동시에 플렉스가 가진 속성까지 동시에 갖추었다. 윈도는 물론 맥OS X에서도 사용할 수 있고 인터넷 익스플로러 외에도 파이어폭스, 오페라, 사파리 등 다양한 브라우저를 지원한다.
마이크로소프트는 이에 한발 더 나아가 .NET CLR의 축소 버전을 포함시킨 1.1 버전까지 들고 나왔다. .NET CLR의 지원은 실행 엔진과 라이브러리 등의 면에서 최소 플래시와 기반이 다른 환경이라는 것을 의미한다. 1.0에 대해서는 MIX 전에 언급이 있었지만 1.1에 대해서는 “Technology X”라는 말로 궁금증만 돋우었다. 그만큼 .NET CLR의 탑재는 무게가 다르다. 전체 다운로드 크기가 .NET CLR을 포함하고도 4~5MB 수준인 만큼(윈도 기준) 무거운 자바나 .NET 풀 버전과 차별화되는 균형 감각도 보인다.
전통적으로 마이크로소프트는 단말 쪽 플랫폼과 개발 도구 쪽으로는 강점이 있고 서버 쪽도 강하다. 물론 실버라이트는 서버 측에서 마이크로소프트 제품을 사용하지 않고도 동작하도록 되어 있지만 기본적으로 개발 도구, 기반 런타임 엔진, 라이브러리, 서버 모든 면에서 충분한 지원을 제공할 수 있다는 점에서 초기 확산에는 도움이 될 것이다. 문제는 저작 도구인데 이 부분에 있어서 잘하고 있다고는 평가하기에 이르나 나름대로 해법은 내어 놓고 있다. 익스프레션 블렌드 2(Expression Blend 2)와 익스프레션 디자인(Expression Design)이라는 디자이너 도구를 내놨다. 블렌드는 플래시에 플렉스 빌더(Flex Builder)를 합쳐 놓은 것 같은 도구고 디자인은 일러스트와 포토샵을 합쳐 놓은 것 같은 도구다. 개인적으로 도구를 사용해 볼 기회는 없었는데, 디자인은 모르겠지만 블렌드의 경우 어차피 RIA를 새로 구축하는 입장이라면 충분히 승산은 있지 않을까 한다. RIA에서는 애니메이션 등의 그래픽적 요소보다는 컴포넌트를 배치하고 상호작용과 데이터를 연결하는 작업이 우선이기 때문이다.
개인적인 평가로는 현존하는 기술로는 1.1 버전을 놓고 보면 가장 막강한 RIA 환경이라고 평가한다. 마이크로소프트는 이 환경을 통해 .NET CLR, XAML 등 자사 기술의 영역을 넓혀 궁극적으로 윈도를 비롯해 모든 제품군의 입지를 다지는 계기로 삼으려는 의도가 있을 것으로 생각한다.

JavaFX
자바 쪽에서도 가만히 있지는 않았다. 올 5월 열린 자바원 컨퍼런스에서는 JavaFX가 이슈가 됐다. JavaFX는 통합 브랜드로 JavaFX 스크립트(예전의 F3 스크립트)는 자바로 플래시와 유사한 현란한 UI를 쉽게 만들 수 있도록 하는 스크립트 언어이고, JavaFX 모바일은 예전 SavaJe라는 회사의 기술을 썬이 인수해 만든 자바 기반의 휴대전화 플랫폼이다. JavaFX 스크립트는 오픈소스로 공개되어 있다.
사실 자바는 데스크톱 환경에서 RIA 플랫폼으로 의미를 가지기에는 JRE(Java Runtime Environment) 자체가 너무 크고 애플리케이션 시동이 늦는 등 몇 가지 치명적인 단점들이 있는데 이를 해결하기 위해 수 MB로 최소한의 JRE만 내려 받은 후 애플리케이션 별로 필요한 API는 필요할 때 추가로 내려 받는 등의 해법을 제시한 Consumer JRE도 함께 소개 됐다. 썬의 자바 홈페이지 우측에는 JavaFX가 Java SE/EE/ME와 나란히 걸려 있어 나름 썬의 진지함을 엿볼 수 있다. 여기서는 RIA라는 관점에서 JavaFX 스크립트와 Consumer JRE에 대해서만 살펴 보도록 하자.
우선 저작 도구나 개발 도구 측면에서 보면 여전히 부족하다. JavaFX 스크립트는 그저 그래픽 표현이 쉬운 자바의 대체 문법일 뿐 아직은 저작 도구는 차치하고 개발 도구 지원도 미흡하다.
플랫폼 자체로 봐서는 Consumer JRE가 전형적인 Swing 애플리케이션 실행을 위해 3~4MB 다운로드만 필요로 하도록 줄이고, 디스크 캐시에 미리 자바를 올려 두고, 윈도에서 좀 더 그래픽을 가속화하는 등의 노력으로 작은 플랫폼으로서의 면모를 달성하면 상황은 많이 좋아질 것이다. 거기다 야금야금 필요한 API를 받아오다 보면 궁극적으로 실버라이트와 달리 어느 플랫폼보다 풍부하고 방대한 라이브러리에 접근할 수 있게 된다. 하지만 약점은 엉뚱한 곳에 있다. 비디오, 오디오 등 멀티미디어 지원 면에서는 현재 자바는 플래시나 실버라이트에 비할 바가 못 된다.
개인적인 평가로는 지금 같은 접근법으로는 썬이 자바로 RIA 시장에서 두각을 나타내기는 어려워 보인다.

구글 방식
구글은 고집스럽게 브라우저 자체를 고집하는 것으로 유명하다. 하지만 앞서 언급했듯이 이미 웹 애플리케이션은 브라우저를 한계까지 밀어 붙이고 있다. AJAX를 구현하는 몇 가지 방법 중 하나인 XMLHttpRequest 객체의 경우 마이크로소프트가 추가한 것을 다른 브라우저에서 지원하기 시작하더니 W3C에서 표준화까지 되고 있는 경우다. 이 같이 브라우저 기능 확장은 피할 수 없는 대세다.
마찬가지로 구글은 최근 구글 기어라는 브라우저 확장을 내 놓고 이를 이용해 오프라인 동작이 가능하고 멀티쓰레드를 활용, 좀 더 반응성이 있는 AJAX 애플리케이션을 만들 수 있도록 하고 있다. 한 가지 중요한 것은 기어가 엄연히 플랫폼마다 포팅되어야 하는 브라우저 확장이라는 점이다.
이러한 시도는 구글 서비스를 활용하거나 하는 경우에는 활발히 사용될 수는 있겠지만 궁극적인 해결책은 되지 못할 것이라는 점이다. 특히 RIA라는 용어의 정의를 앞서 언급한 바와 같이 확장할 경우 현 업계의 요구 사항을 만족시키기는 어려울 것이다.



위로



마치면서

   소셜 북마크

   mar.gar.in mar.gar.in
    digg Digg
    del.icio.us del.icio.us
    Slashdot Slashdot

RIA라는 흐름은 피할 수 없는 움직임일 것이다. 아마도 위에 언급한 기술 중 한 두 가지는 분명히 열세를 면치 못할 것이다. 하지만 유력한 몇 기술은 시간을 두고 공존하지 않을까 생각한다. 개인적으로는 플래시와 더불어 실버라이트는 분명히 자기 자리를 잡을 것이라고 생각한다.
불행히도(?) 지금까지 언급한 기술들은 얼마간은 특정 회사의 자산이며, 열린 기술이라고 하기는 어렵다. 하지만 구현이 하나인 편이 분명한 장점은 있으니 다음과 같은 조건이 만족된다면 우리는 앞으로 더욱 향상된 인터넷을 사용할 수 있게 되지 않을까 한다.

  • 리눅스, 맥 등 윈도 이외의 플랫폼에서도 항상 최신 버전의 RIA 엔진을 만날 수 있어야 할 것이다. 참고로 플래시 플레이어조차도 리눅스 버전이 나오는 건 항상 늦다.
  • 플랫폼 내에 문서와 같은 콘텐츠를 포함할 수 있도록 지원이 향상되고 이런 요소에 대해 검색 엔진이 검색하고 해당 부분에 대해 RIA 자체에서 문제가 되지 않는 범위 내에서는(로긴이 필요하다든지 하는 문제) 직접적인 링크를 걸 수 있는 방법에 대한 표준이 정해져 서로 다른 형태의 RIA 플랫폼 간에서 공히 지켰으면 한다.
  • 기왕이면 많은 기술 요소가 공개되고 가능하면 오픈소스화 되었으면 한다. 각 기술을 개발한 개발사가 기본적으로 챙겨야 하는 이득 외에는 과감하게 공개해야 해당 기술도 살고 플랫폼 활용도도 높아지지 않을까 한다.
Posted by euNey^0^
TAG ria

댓글을 달아 주세요

티스토리 툴바