RIA 플랫폼 전쟁을 바라보며…

WebPrograming관련 : 2007. 6. 13. 11:04

출처 : http://www.ibm.com/developerworks/kr/library/dwclm/20070612-2/?ca=dnn-krt-20070613

RIA 플랫폼 전쟁을 바라보며…

김도형 dynaxis@alticast.com

양방향 TV 솔루션 개발을 해 왔고 현재는 DMB를 위한 자바 규격 표준화와 제품 개발을 맡고 있다. JSR 242, JSR 272 등 방송 관련 JSR에 전문가로 참여했으며, 자바 외에 프로그래밍 언어 전반, XML 등 다양한 분야에 걸쳐 관심을 가지고 있다.

2007년 6월 12일

과학 vs 공학

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
	Digg
	del.icio.us
	Slashdot

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

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