[IT/이론] RIA(Rich Internet Application)란

출처 : http://www.datanet.co.kr/market/read.html?cd=3202&N_cate1=2&N_cate2=17&tk=1178598980

 

웹 2.0의 대표 주자, RIA에 ‘관심 집중’

 

생산성·민첩성·의사결정 능력 향상 … ‘보안·관리·확장성’ 유의해야

RIA(Rich Internet Application)는 차세대 웹의 기반을 형성하며, 생산성, 민첩성, 의사결정 능력 및 지원의 편의를 향상시켜 줄 수 있다. 그리고 어도비, 도조 파운데이션 및 구글은 데이터를 보다 효율적으로 지원하는 데 있어 각자 다른 방식으로 접근하고 있다. 이들에 대해 알아야 할 것들을 정리해 보았다.


웹2.0에는 수많은 차세대 인터넷 기술들이 포함돼 있다. 그리고 그 가운데서도 보다 두드러지는 개념으로 RIA(Rich Internet Application)가 있다. 적절히 이행되기만 하면 RIA는 캐싱에 의해 제공되는 효율성을 넘어 웹 브라우저가 웹 서버와 보다 동등한 파트너가 될 수 있게 해준다.
사용자는 서버에 의해 데이터 페이지 전체가 전송이 되고, 브라우저에 의해 디스플레이되기를 기다릴 필요가 없다. 대신 데이터는 필요에 따라 검색 및 디스플레이된다. 웹 브라우저 이용은 이제 데스크톱 애플리케이션을 사용하는 것과 보다 비슷해졌다. 기업에서 RIA는 보다 확실하고 응답성이 뛰어난 인터페이스로 인한 생산성 향상 등 많은 혜택을 약속하고 있다.
하지만 RIA는 덕트 테이프와 달리 어두운 면도 갖고 있는데, 바로 RIA의 성공을 가로막고 있는 보안, 관리 및 확장성 문제다. 데이터를 공급하기 위해 서버가 더 부지런히 돌아가기 때문에 메시징과 자원에서 오버헤드가 늘어날 것이다. 또한 웹 서버로 더 많은 접속이 필요하기 때문에 로딩 문제가 야기될 수도 있다.
RIA 프로젝트가 성공하기 위해 처리돼야 할 브라우저들간의 차이도 많으며 이들은 알아차리기 힘든 경우도 많다. 다행히도 어도비, 도조 파운데이션 및 구글 등 업체들이 이러한 부담을 덜어주기 위한 제품을 내놓고 있는데, 이들이 문제에 접근하는 방식은 각자 다르다.
구시대 인터넷에서는 웹 서핑이 대부분 웹 브라우저와 서버간을 오가는 간단한 춤추기 정도였다. 일반적으로 브라우저가 서버로 요청을 하면 서버가 자원을 모으고, 데이터를 조작하고, 텍스트를 포맷팅하고, 이미지를 로딩해서, 최종적으로 결과물을 브라우저로 보내며, 그러면 브라우저는 이것을 보여주기 위해 렌더링될 수 있었다.

과거와 현재
사용자는 가끔씩 무료함을 달래기 위해 쓸데없이 마우스에 놓인 손가락을 퉁기며 인내심을 갖고 기다린다. 그러다 결국 사용자는 어떤 항목이나 링크가 새로 고침이 필요하다고 판단하기도 한다. 이럴 때는 브라우저가 다시 요청을 포맷해서 이것을 서버로 보낸다. 그리고 서버는 또 다시 자원을 모으고, 데이터를 조작하고, 텍스트를 포맷하고, 이미지를 로딩한 다음 그 결과를 전송한다. 그리고 역시 사용자도 다시 앉아서 기다린다. 이러한 ‘페이지별’ 브라우징 모델은 많은 인터넷 사이트에 최적화된 그래픽(어떤 사람들은 이것을 사라진 예술이라고도 한다), 간단한 데이터, 그리고 정적 HTML 콘텐츠가 포함됐던 시절에는 잘 통했으며, 최소한 견딜만 했다.
하지만 웹 페이지가 복잡해지고 데이터 전송량이 늘어나면서, 사용자들은 과도한 대기시간에 참을성을 잃어가고 있다. 광대역조차 이러한 고통을 덜어주는 데는 역부족이다. 웹 페이지는 하나의 항목이 서버에서 업데이트될 때마다 매번 전체 페이지가 갱신되도록 하기에는 너무 덩치가 커졌다.
궁극적으로 사용자들이 원하는 것은 데스크톱 애플리케이션과 같은 속도와 응답성, 그리고 느낌을 주는 웹 브라우징 경험이다. 이러한 목표를 달성하기 위한 최초의 노력으로 마이크로소프트의 액티브X, 마이크로미디어(현재는 어도비)의 플래시, 넷스케이프의 라이브커넥트, 자바 애플릿 등이 있었으나 이들은 절반의 성공에 그치고 말았다.
기술과 기법의 통합을 통해 개발자에게는 웹 브라우징 속도를 높이는 데 필요한 몇 가지 툴이 주어졌다. 주로 자바스크립트를 이용한 클라이언트쪽 스크립팅과 DOM(Document Object Model)은 넷스케이프 내비게이터의 초창기 시절부터 브라우저에서 사용돼 온 것들이다. CSS(Cascading Style Sheets)는 이 개발자들에게 웹 페이지를 표현하는 데 대한 훨씬 세부적인 제어 능력을 주고 있다. 이런 기술들에 DHTML(Dynamic HTML)이 결합되면, 웹 페이지는 훨씬 더 생기를 띠며, 사용자 입력에 대한 응답성이 향상된다. 하지만 지금까지는 핵심적인 부분이 빠져 있다.
XML과 XMLHTTRequest 객체의 채택으로, 오늘날 우리가 알고 있는 RIA 개발에 지평이 열렸다. DOM, CSS, HTML 및 자바스크립트 등을 포함한 DHTML에다 XML까지 가세를 하여 표준 에이잭스(Ajax) 툴박스가 구성됐다. 이런 기술들이 함께 모이면 웹 페이지가 한번에 모두가 아니라 섹션별로 업데이트될 수 있다. 다시 말해 개발자는 페이지의 작은 섹션을 바꿀 수 있으며, 그 변화에 필요한 데이터만 웹 서버로 요청할 수가 있다. 더 이상 사용자는 웹 서버에 의해 중복되는 부분이 많은 전체 페이지가 함께 모여서 전송되고, 브라우저에 의해 디스플레이될 때를 필요가 없게 됐다.
RIA가 엔터프라이즈에 의해 채택이 되면, 어떤 개발 방안이 사용돼야 할까? 불행히도 이행안들간에는 호환성이 거의 없기 때문에 하나를 선택하면 오랫동안 그 솔루션만 사용해야 할 것이다. 각 방안의 이점과, 어디서 내 시스템과 맞을지, 얼마나 성숙한지, 그리고 이것이 사용자와 백 오피스에 얼마나 많은 영향을 미치게 될지 등을 고려해야 한다. 분명 서로 다른 툴키트가 같은 개발 환경과 같은 웹 서버에 함께 존재할 수는 있지만, 각각에서 만들어진 코드는 역시 호환되지 않을 것이다.

공통의 라이브러리
지금까지 개발자들의 마음을 사로잡은 방안으로는 세 가지가 있다. 첫 번째는 도조 파운데이션의 도조 툴키트가 대표적이며, 브라우저에 의해 제공되는 툴들, 즉 자바스크립트, DOM, DHTML 및 CSS만 사용한다. 도조 툴킷은 가장 일상적인 웹 개발 툴인 HTML과 자바스크립트를 기반으로 하며, 클라이언트 측 데이터 스토리지와 몇 가지 표준 준수 데이터 전송 메커니즘도 또한 제공하고 있다. 게다가 도조 툴키트는 많은 주요 인터넷 및 엔터프라이즈 업체들의 지지를 받고 있다.
자바스크립트와 HTML을 이용한 개발이기 때문에 결과적으로 브라우저에 의한 변경이 없이 실행되는 코드가 만들어진다. 이러한 방법론은 오픈에이잭스 얼라이언스(OpenAjax Alliance)에서 받아들이고 있는데, 이 동맹의 멤버들로는 BEA시스템즈, 볼랜드소프트웨어, IBM, 라즐로시스템즈, 모질라, 노벨, 오라클, SAP 등이 있다. 이 집단은 상호운용이 가능한 에이잭스 기술의 채택을 장려하기 위해 만들어졌다. 공통의 자바스크립트 라이브러리 세트에 대한 주장이 나오고 있기 때문에, 라이브러리가 업체 전용성과 이행의 전용성을 벗어남에 따라 에이잭스 개발도 활기를 띠게 될 것으로 기대된다. 도조 파운데이션은 오픈에이잭스 얼라이언스의 일원으로서 대표적인 툴키트를 이행하고 있다.
도조 툴킷은 브라우저의 기능성과 개발 니즈를 중심으로 한 자바스크립트 라이브러리로 구성돼 있다. 라이브러리에는 기본적인 필요를 위한 코어 라이브러리와 사용자 인터페이스 엘러먼트, 데이터 인터페이싱, 그래픽, 도표, 국제화, 이벤트 프로세싱 등을 전담하는 추가 라이브러리가 있다. 도조 툴키트는 표준 HTML에 대한 익스텐션인 도조ML을 사용하는데, 이것은 자바스크립트 라이브러리가, 그리고 익스텐션에 따라 개발자가 조작할 수 있는 위젯을 규정한다.
도조 툴키트는 비교적 간편하게 사용할 수 있다. 원하는 자바스크립트 라이브러리는 태그를 이용해 웹 페이지에 추가되며, 필요에 따라 도조ML이 삽입된다. 이 단계까지만 가도 많은 기능성을 사용할 수 있다. 그리고 개발자는 데이터 검색 및 조작이나 사용자 입력 프로세싱 같은 특수 기능을 수행하기 위해 자바스크립트 코드를 추가할 수 있다. 개발이 완료되면 그 결과물인 라이브러리와 HTML이 최종 애플리케이션의 일부로 배포가 된다.
개발을 한층 수월하게 하기 위해 이클립스(Eclipse) 같이 기존의 환경에 맞는 플러그인이나 몇 가지 IDE(Integrated Development Environment)가 만들어졌다. 여기서 언급된 모든 툴키트는 간단한 문서 편집기를 이용해 코딩이 가능하지만, 현명한 개발자라면 정지점(breakpoints), 변수 주시(variable watching), 스택 추적(stack trace) 같은 수법을 이용해 코드를 만들 것이다.
원격 데이터 접속은 XML 오버 HTTP를, 혹은 RPC 요청으로 이뤄진다. 로컬에서 툴키트는 사용자가 플래시 셰어드오브젝트(Flash SharedObjects) 코드나 파이어폭스용 왓 WG 스토리지 프로바이더(WHAT WG Stroage Provider for Firefox)를 이용해 데이터를 저장할 수 있게 해준다. 로컬 데이터 스토리지는 비록 RIA 패러다임에 속하지는 않지만 로컬 구성 설정, 서버로부터 대신해서 다시 로딩될 객체 카피들, 그리고 문서나 이미지 같은사용자 전용 데이터 등을 저장하는 데 유용하다.

선택의 언어
두 번째 RIA 방안은 GWT(Google Web Toolkit)로 대표되는 것으로 자바 지식을 활용하며, RIA가 자바스크립트와 HTML을 이용해 배치되는 동안 개발자가 자바로 코딩을 할 수 있게 해준다. 코딩은 구글이 제공하는 특수 툴을 이용해 보다 쉽게 이뤄질 수 있다. GWT는 보다 편리한 애플리케이션 유니트 테스팅을 위해 자바 기반의 제이유니트(JUnit) 테스트 프레임워크를 통합시켰다. 하지만 데이터 전송은 RPC와 JSON으로 제한되며, 로컬 데이터 스토리지도 전혀 사용할 수 없다.
GWT에서도 자바스크립트는 역시 DOM, DHTML 및 CSS에 연관된 호출을 이용해 브라우저에서 실행되지만, RIA를 만드는 데 사용되는 툴은 자바스크립트 라이브러리가 아니다. 여기서는 RIA 저작에 다른 언어로 다른 툴세트가 사용되고 있다. 어떤 경우에는 선택의 언어가 자바가 될 수도 있고, ASP.NET이 되는 경우도 있다. 툴세트가 무엇이든 관계없이 코드는 자바스크립트로 컴파일링이 되며, 이것이 클라이언트로 배포돼 실행된다.
GWT로 작업하는 RIA 개발자들은 자바 언어의 서브세트를 이용해 브라우저 인터페이스 엘러먼트를 만들고, 데이터 요청을 처리하며, 이벤트를 다룬다. 구글은 또한 사용자 인터페이스 엘러먼트를 만드는 데 쓸 수 있는 위젯 세트도 제공하고 있다. 특수 브라우저가 JRE(Jaa Runtime Environment)에서 자바 코드를 실행하기 때문에 간단한 디버깅과 테스팅이 가능하다.
IDE를 이용하자(우리는 이클립스를 사용했다) 개발 속도가 빨라지고 훨씬 편리해졌다. 제이유니트도 또한 코드기반에 포함돼 있어 코스 테스팅 및 디버깅이 향상된다. 코딩이 완료됐을 때, 혹은 원하는 때 언제든 포함된 컴파일러를 통해 소스 자바가 실행될 수 있기 때문에 자바를 자바스크립트나 HTML로 전환할 수 있다.
한 가지 주의의 말을 덧붙이자면, 구글이 많은 코어 자바 라이브러리를 복제하긴 했지만 아직 남은 게 많다는 것이다. java.lang과 java.util 패키지는 표준 자바 라이브러리와 거의 완벽하게 호환이 된다. 하지만 다른 자바 클래스들은 컴파일러에 의해 번역이 되지 않을 수 있으며, 따라서 RIA를 만들 때 사용돼서는 안 된다.
GWT 웹 페이지를 보면 어떤 클래스가 번역이 가능한지, 그리고 어떤 것을 피해야 하는지에 대해 상세히 나와 있다. 포함된 자바 클래스에서 필요한 기능성을 제공하지 않을 경우, 개발자는 개발 과정에서 자바 코드에 자바스크립트가 포함될 수 있게 해주는 기법인 JSNI(JavaScript Native Interface)를 활용할 수 있다.
자바스크립트는 개발 과정에서 자바 코드와, 그리고 컴파일링될 때 결과물인 자바스크립트 코드와 상호작동할 수 있기 때문에, 기능을 불러오고 예외적인 것들을 버린다. 하지만 이것은 신중하게 사용돼야 한다. 결과물 코드는 브라우저들간에 이식성이 떨어지는 경우가 많고, 메모리 노출을 발생시킬 수 있으며, 컴파일러가 최적화하기에 힘이 들기 때문이다.
GWT는 JSON(JavaScript Object Notation)과 (JSNI를 통해) RPC 데이터 접속을 제공한다. 개발 작업을 단순화시키고, 실행 속도를 높이기 위해 생성되는 데이터 접속의 수는 낮게 유지된다. 웹 서비스로 액세스를 제공하는 방법이 제공되거나, 직접 코딩할 수도 있다.

플렉스 툴킷
세 번째 방안은 어도비에서 앞장서고 있는 것으로 CSS, DOM, DHTML 및 자바스크립트가 전혀 필요 없다. 어도비의 플렉스 툴킷은 플래시 객체를 만들며, 이 객체가 RIA를 봉입(encapsulate)한다. 개발은 액션스크립트(ActionScript)와 특수 마크업(markup) 코드를 이용해 이루어지며, 데이터 액세스는 전용을 포함한 많은 메쏘드를 통해 제공이 된다.
배치가 완료되면 코드는 브라우저 안에서 실행되는 바이트 코드로 컴파일링되며, 이는 CSS, DHTML 및 DOM에 매우 독립적이다. 이러한 방식은 ‘순수’ 에이잭스로부터는 가장 멀리 일탈된 것이지만, RIA 범주 안에는 해당이 된다.
어도비는 최근의 매크로미디어(Macromedia) 인수에서 얻은 기술을 기반으로, 플렉스 툴키트를 발표했다. 이 키트에서 개발자는 액션스크립트, ECMA 스키립트 준수 언어, 그리고 XML 기반의 마크업 언어인 MXML을 이용해 코딩해야 한다. 코딩은 명령어 라인에서, 혹은 다른 툴키트에서 우리가 선호했던 것처럼 IDE(그렇다. 여기서도 이클립스다)에서 수행될 수 있으며, 결과물 코드는 플래시 객체로 컴파일링 및 변환된다. 그러면 이 플래시 객체는 RIA로서 웹 플래시 객체로 배포가 된다.
이 객체는 모든 플래시 콘텐츠와 마찬가지로 웹 브라우저에 의해 호스팅되는 플레시 플레이어(Flash Player) 안에서 실행이 된다. 사용자 인터페이스 엘러먼트, 그래픽, 이미지 프로세싱, 이벤트 처리 및 다른 대부분의 작업들이 플래시 플레이어에 의해 처리된다. 플래시 플레이어는 거의 모든 웹 브라우저용으로 사용 가능하기 때문에 RIA 배포는 대부분의 경우 브라우저의 종류나 버전에 방해받지 않는다.
이것은 자바스크립트 기반의 RIA용으로는 문제가 될 수도 있겠지만, 자바스크립트가 성숙해지고 업체들이 웹 표준을 보다 완벽히 준수함에 따라 자바 스크립트를 사용해 실행되는 RIA와 플래시를 사용해 실행되는 RIA들간의 실질적인 차이는 거의 사라질 것으로 기대된다.
배치를 간소화하고 유니트 테스팅 자동화를 도모하기 위해, 제이유니트를 본떠 만든 테스팅 프레임워크인 플렉스 유니트(Flex Unit)를 포함시켰다.
플렉스 툴키트는 데이터 접속용으로 가장 많은 옵션을 제공하고 있다. 표준 플렉스 툴키트는 다른 툴키트와 유사한 데이터 전송 방식을 제공하긴 하지만, 별도 가격을 붙여 어도비에서는 플렉스 데이터 서비스(Flex Data Services) 2 애플리케이션을 판매하고 있다. 이 패키지는 자바 EE 애플리케이션 서버에 놓이며, 원격 객체(액션 메시지 포맷), MS, 혹은 플래시 플레이어에 의해 지원되는 맞춤 프로토콜인 RTMP(RealTime Message Protocol)를 이용해 플렉스로 데이터를 공급한다.