반응형
RIA의 시대는 저물었을까
월간 마이크로소프트웨어 2011년 12월호
아이폰에 비해 상대적으로 뒤늦게 시작한 안드로이드의 앱 생태계에서 플래시로 만든 콘텐츠를 볼 수 있다는 것은 매우 매력적인 장점으로 내세울 수 있었다. 2010년 가을 삼성전자에서 갤럭시 탭을 출시할 때에도 어도비와 긴밀하게 마케팅 행사를 진행했다. 이미 셀 수 없을 만큼 엄청난 분량의 미디어와 게임, 콘텐츠가 플래시 형식으로 만들어져있고 아무런 변환 작업 없이 모바일 디바이스의 브라우저에서 이를 사용할 수 있다는 것은 후발주자로서의 약점을 충분히 보완할 수 있는 조건이었다. 안드로이드 디바이스는 시장에서 상승세를 타기 시작했고 애플이 결국에는 플래시를 받아들이게 될 것이라는 루머가 애플의 새로운 발표가 있을 때마다 반복됐다.
하지만 이런 루머는 오래 가지 않았다. 지난 11월 10일 어도비에서는 공식적으로 더 이상 추가적인 모바일 버전 플래시 플러그인(안드로이드를 포함한 모바일 브라우저에서 사용하는 플래시 플레이어)을 개발하지 않겠다고 발표했다. 2001년 매크로미디어 시절 처음 공개됐던 플래시 라이트가 NTT DoCoMo 505i에 처음 적용된 이후 수많은 사용자의 손 위에서 다양한 콘텐츠를 전달하고 즐기기 위해 사용되었으며 스마트폰 이전의 화려한 UI를 피처폰에서 경험할 수 있었던 것은 모두 플래시 덕분이었다. 하지만 10여년 만에 그 자리를 스스로 내려와야 했다. 노후한 기술이 자리를 다른 기술로 물려주고 떠난 것이라고 생각하면 특별할 것이 없는 소식이지만 오랫동안 애플에서 문제로 삼았던 것처럼 모바일 디바이스에서의 플래시 기술이 적절하지 못하다는 것을 스스로 인정하는 것처럼 보였으며 어도비가 애플에 백기를 들어 올린 것처럼 비춰지는 사건인지라 수많은 매체에서 이 소식을 주요 뉴스로 다루었다. 일부 기사에서는 고인이 된 스티브 잡스의 이야기를 다루면서 마치 삼국지에 나온 죽은 공명이 산 사마중달을 달아나게 한 사건(死孔明 走 生仲達)을 비유로 들기도 했다.
(그림 1. 어도비 TV에 소개된 갤럭시탭)
그리고 12일에는 어도비 플렉스 팀 블로그에서 플렉스 SDK를 오픈 소스 그룹에 이관할 계획을 가지고 있다는 공지를 했다. 이미 2007년 오픈소스로 공개되었지만 그동안은 어도비에서 별도의 팀을 운영해 제품을 관리했었는데 공식적으로 프로젝트 자체를 이관하겠다는 내용이 포함됐다(처음 공지에서는 구체적인 방안이 없었고 15일 업데이트된 내용에서 아파치 재단과 접촉하고 있다는 내용을 추가 공개했다). 일반적인 상황이었다면 이런 결정이 기업의 아름다운 사회 환원 정도로 포장될 수 있었지만 여러 주변적인 상황과 맞물려 어도비에서 새로운 생태계 구성을 위해 재고정리를 하고 있는 것이 아닌가 하는 의심을 사기도 했다.
다른 시각으로 바라본다면 PC 시장에서 지속적으로 플래시 기술이 업데이트되고 있으며 다양한 시장 특히 게임이나 미디어 분야에서는 콘솔 게임 시장에 도전할 만큼 성장세를 이어가고 있다. 그리고 어도비 AIR 기술을 가지고 다양한 디바이스 시장에 진출할 수 있고 브라우저의 제약을 넘어 네이티브 앱에 가까운 기능이나 성능을 가져갈 수 있다. 하지만 며칠간의 발표는 개발자보다는 투자자를 위한 조치라는 인상이 강했고 많은 이들을 혼란에 빠지게 만들었다.
기술 환경의 변화로 인해 어느 하나를 선택해야 하는 것은 기업 입장에서 충분히 있을 수 있는 일이다. 하지만 이번 발표에 커뮤니티 진영에서 특히 많은 반발을 하는 이유는 이런 변화에 대해 충분한 정보를 제공하고 대화를 했었어야 한다는 의견이다. 개발자 커뮤니티를 확대하고 제품의 도움말을 제공하는 영역마저 커뮤니티에 오픈했던 어도비가 이번 발표에 대해 너무 미숙하게 대응했다는 것이다. 마치 트위터에서 다양한 분야의 사람들과 의견을 나누었던 유명인사가 자신에게 불리한 사건이 생기자 아무런 말도 없이 계정을 폐쇄해버린 것 같은 그런 느낌일 수도 있다. 개인이라면 갑작스럽게 닥친 사건에 대해 어떻게 대처할지 몰라 당황했을 수도 있다. 기업 내부에서도 말하고 싶어도 그렇게 하지 못할 사정이 있다는 것은 이해할 수 있다. 하지만 에반젤리스트나 제품매니저가 지속적으로 개발자들과의 관계를 가져왔었으며 이런 경험을 바탕으로 좀 더 개발자를 고려한 대응이 필요했었을 것이다.
RIM의 선택, WebWorks
이미 어도비에 우호적이던 모바일 진영에서도 다른 대안을 준비하고 있었다. 대표적인 업체 중 하나가 리서치 인 모션(RIM)이다. 올해 초 어도비의 월드 투어 행사에 같이 참여하며 플래시 플레이어와 어도비 AIR가 플레이북을 위한 콘텐츠를 개발하는 주요 전략이라는 것을 내세웠다. 하지만 생각보다 훨씬 적은 판매실적으로 인해 태블릿 분야의 사업 중단 이야기까지 나왔고 이를 해결할 수 있는 선택이 필요한 시점에서 차세대 플랫폼인 BBX를 발표했다.
지난 10월 블랙베리 DevCon 2011 행사에서 공개한 블랙베리 스마트폰과 태블릿을 위한 차세대 플랫폼 BBX는 오픈소스 기반으로 2010년 인수한 차량용 모바일 기술 업체 QNX(플레이북 태블릿에 적용했던)의 운영체제와 블랙베리 운영체제의 장점만을 결합해서 만들어졌다고 공개했다. BBX환경에서 WebWorks에서 HTML5 기술을 기반으로 쉽게 콘텐츠를 만들 수 있으며 Ripple이라는 에뮬레이터로 다양한 시뮬레이션을 동작해볼 수 있게 된다. 올해 초까지만 해도 어도비 AIR나 자바 기술을 강조했지만 이제는 다양한 블랙베리 운영체제에서 동작하는 앱을 만들기 위해서는 WebWorks를 사용해야 하고 그러기 위해서는 HTML5를 선택해야 하는 상황이 만들어진 것이다. 그렇게 만들어진 콘텐츠는 블랙베리 운영체제에 종속적이긴 하지만 내부의 콘텐츠를 분리해 다른 하이브리드 앱 프레임워크에서 재활용할 수도 있기 때문에 HTML5가 다양한 선택을 하기 위한 필수 조건이 되어버린 것이다.
(그림 2. 블랙베리 WebWorks 메인 사이트)
데스크톱이라면 HTML5를 당장 적용하기 어려운 브라우저 환경 때문에 다양한 상황을 고려해야 한다. 실제 개발 과정에서 IE6에서부터 크롬까지 사용 환경을 염두에 두고 적절한 대비책을 지원해주어야 하며 사용자의 환경에 따라 성능의 심각한 차이가 있음을 사용자에게 인지시켜주어야 한다. 하지만 모바일 디바이스에서는 게임의 규칙이 조금 달라진다. HTML5를 적극적으로 지원하는 브라우저가 항상 최신 버전으로 업데이트될 수 있는 환경이 마련되어 있고 수많은 개발자들이 모바일 시장에서 치열하게 살아남기 위해 새로운 시도를 적용하고 있어 생각보다 빠른 속도로 변해가고 있다.
돌아온 탕자, JavaFX
오라클에서 썬 마이크로시스템을 인수하면서 가장 애매한 상황에 빠진 기술 중 하나가 JavaFX 이었다. 야심차게 RIA 시장에 후발주자로 시작했지만 커뮤니티의 기대만큼 성과를 내지 못한 결과를 보여주었다. 자바라는 거대한 배경을 가지고 있음에도 자신의 위치를 제대로 찾지 못했고 결국 시장에서도 개발자에게도 선택받지 못하는 도구가 되어버렸다. 기업이 아닌 소비자가 기술 변화를 주도한다는 맥락은 읽었지만 그 가운데 서 있는 개발자들의 마음을 읽지 못한 결과였다. 유연한 개발 방법론으로 JavaFX Script를 제안했지만 개발자들이 원하는 것은 어설프게 추가된 언어가 아니라 자바 언어와 자연스럽게 통합된 형태로 사용되기를 원했던 것이다. 하지만 그렇게 시장에서 사라지는가 했던 JavaFX는 지난 JavaOne 2011 행사에서 새로운 2.0 버전을 발표하며 자바 로드맵의 주요 축으로 다시 돌아왔다.
이전 버전에서는 자바 개발자들의 요구사항을 받아들여 이전에 만들어진 스크립트를 100% Java API로 제공하기 때문에 기존의 애플리케이션과 쉽게 연동할 수 있으며 자바를 기반으로 하는 다른 언어로 쉽게 포팅할 수 있게 됐다. 또한 XML기반의 FXML 마크업을 추가적으로 제공하며 웹킷을 기반으로 하는 웹 컴포넌트를 포함하고 있다. 웹 컴포넌트를 포함하고 있다는 것은 기존 시장에서 구현된 자바 애플리케이션과 새로 만들어지는 웹 콘텐츠가 자연스럽게 연동될 수 있다는 것을 의미하고 있으며 그동안 기업용 시장에서 불편하게 느꼈던 점을 정확하게 지원해주고 있다.
(그림 3. JavaFX 1.2 2009년)
2012년 중에 Scene Builder 라는 개발 지원 도구를 공개할 예정이고 리눅스까지 지원될 예정이다. JavaFX의 경쟁상대는 플렉스나 실버라이트가 아니라 어도비 AIR와 같은 다양한 디바이스를 타켓팅하는 기술이라고 할 수 있다. 그런 점에서 어도비 AIR가 시장력이 없다며 포기한 리눅스에 대한 지원까지 포함한다면 여전히 ‘Write Once, Run Anywhere’라고 이야기할 수 있는 유일한 기술이 될 수 있을 것이다. 구글 트렌드(http://www.google.com/trends)의 기록을 살펴보면 2009년까지는 국내에서 상당히 많은 관심을 가지고 있었는데 2010년이 되면서 수치가 급격하게 떨어지기 시작했다. 지금은 어디에서도 관련 자료를 찾아보기 어렵다. 2.0 버전과 함께 돌아온 JavaFX는 개발자들에게 신뢰를 다시 찾는 것이 우선적인 과제일 것이다.
중심에서 멀어진 Apache Pivot
JavaFX가 주춤하고 있던 사이에 오히려 주목받은 기술이 Pivot 이라는 RIA 프로젝트다. 2007년 VMware 내부 연구 프로젝트로 시작해서 2008년에 오픈소스로 공개했고 2009년에 아파치 인큐베이터 프로젝트로 편입되고 바로 탑레벨 프로젝트로 공개됐다. 아파치 인큐베이터는 새로 추가된 프로젝트가 아파치 라이선스에 적합한지, 커뮤니티에서 지속적인 지원을 받을 수 있는 지등을 판단하고 지원하는 과정이라고 볼 수 있다. 현재 아파치 인큐베이터 프로그램에 참여하고 있는 프로젝트는 59개로 오픈오피스나 JSPWiki와 같은 프로젝트도 인큐베이터 프로그램으로 참여하고 있다. 인큐베이터 프로그램에 참여한다고 해서 모두 성공적으로 유지가 되는 것은 아니다. 중간에 프로젝트가 중단되기도 하고 다른 형식으로 프로젝트를 진행하기도 한다.
Pivot 프로젝트의 경우 인큐베이터 프로그램에서 1년이 안되어 탑레벨 프로젝트로 공개된 것까지는 이슈가 되었지만 아쉽게도 그 이상의 관심은 받지 못했다. Pivot 프로젝트의 부진 역시 대상을 잘못 선정한 것을 하나의 원인으로 볼 수 있다. FAQ를 참조해보면 HTML, CSS 자바스크립트에 익숙한 웹개발자를 대상으로 하고 있는데 그들에게 자바라는 환경이 낯설고 실제 사용자가 가질 수 있는 다양한 문제에 대처하기 힘들었을 것이다. 결국 자바 개발자도 놓치고 대상으로 했던 시장에도 제대로 진입하지 못한 결과를 만들었다. 어도비 AIR 역시 처음 선보였을 때에는 PHP나 Ajax 개발자를 대상으로 전략적인 접근을 했지만 결국에는 플래시 개발자로 다시 포커스를 맞추게 된 것처럼 낯선 환경에 만들어지는 진입 장벽을 낮추기가 쉬운 일은 아니다.
이제는 다시 돌아온 JavaFX와의 경쟁 구도까지 가져가게 되면서 프로젝트 자체가 흔들릴 수도 있다. 오픈소스 프로젝트만의 문제는 아니지만 주목받던 기술이 한순간에 잊어질 수 있다는 것을 다시 한 번 생각해보게 한다.
HTML5에서 3D를 구현하기는 힘들까
2010년 마이크로소프트는 실버라이트 파이어스타트라는 행사에서 실버라이트 5에 대한 계획을 발표했다. 예정대로라면 2011년 정식으로 출시가 되어야 했지만 4월에 베타 버전을 발표한 이후 아직 정확한 일정이 나오지 않고 있다. 11월중에 RTM이 공개될 예정이라는 소문과 함께 이번 버전이 마지막 실버라이트 버전이 될 것이라는 이야기도 떠돌고 있다.
하지만 2010년까지만 해도 마이크로소프트의 입장은 HTML5, Silverlight, WPF를 사용자의 필요에 따라 선택적으로 제공하는 것이라는 자세를 취했고 실버라이트에서는 3D, 외부기기연동, 미디어 등의 이슈가 있는 경우 강력한 도구로 선택될 것이라고 자신하고 있었다(어도비 역시 2011년 10월 폰갭을 만드는 니토비를 인수하면서 비슷한 이야기를 했다). 그리고 키노트에서 최신 기술이 적용된 3D 데모로 인체 시뮬레이션을 보여주었을 때 실버라이트는 여전히 강력한 도구로 사용될 것이라 생각할 수 있었다. 하지만 1년도 못되어 이러한 기대는 여지없이 무너지고 있다.
(그림 4. HTML5 3D BioDigital Human)
바이오디지털(BioDigital)이라는 의학용 3D 기술을 서비스하는 기업으로 2002년 만들어진 이 회사는 오랜 기간 동안 3D 시각화에 대한 경험을 가지고 있었고 이미지나 동영상을 판매하는 서비스를 제공하기도 하는 곳이다. 최근 ‘BioDigital Human‘이라는 서비스를 베타 버전으로 공개했는데 소개 동영상을 아무런 설명 없이 봤다면 플래시와 같은 기술을 사용해서 만들어진 이미지가 아닐까 싶지만 설명을 보면 HTML5와 Web-GL을 사용한 서비스라고 한다. http://www.biodigitalhuman.com/ 주소로 접속해보면 현재 사용하는 브라우저를 체크하고 해당 서비스가 이용가능한지에 대한 정보를 제공한다.
IE9의 경우에는 해당 브라우저에서 지원되지 않는 HTML5 태그를 사용하고 있기 때문에 서비스를 제공받을 수 없고 크롬 브라우저의 경우에는 기능은 가능하지만 그래픽 속도를 지원하지 못해 실행되지 않는다(크롬의 경우는 그래픽 카드의 지원여부에 따라 결과는 달라질 수 있다. 테스트한 그래픽카드는 NVIDIA GeForce GT 425M이었다. 동일한 환경에서 파이어폭스는 정상적으로 동작했다).
실제 조작에 있어서는 성능상의 차이가 조금 있긴 하지만 2개의 동영상을 동시에 보여준다면 어느 것이 실버라이트를 사용한 것이고 어느 것이 HTML5를 사용한 것인지 구별하지 못할 것이다. 이제는 HTML5는 아직 3D 같은 영역에 도달하지 못할 것이라는 이야기는 시장에서 적용되지 않을 것이며 그 간격은 점점 더 작아질 것이다.
HTML5 는 누가 개발해야 하는 걸까
HTML를 가지고 뭘 할 수 있을까 들어보면 서로 다른 그림을 그리고 있는 것을 발견할 수 있다. 보수적인 입장에서는 자바스크립트, CSS는 사용자 환경에 따라 적용되지 않을 수도 있기 때문에 기본 웹 개발의 범위에서 벗어나는 것이라고 이야기하는 경우도 있고 일반적인 경우에는 HTML5와 관련된 자바스크립트 API를 HTML5라고 이야기하고 있다.
비디오를 예로 든다면 태그만으로는 비디오를 보여주는 것까지 구현이 가능하지만 사용자의 입력에 따라 상세한 조정을 하고자 한다면 자바스크립트를 가지고 제어할 수 있는 함수를 구현해주어야 한다. 단순하게 내 사이트에 비디오를 삽입하고 보여주기만 하면 되는 경우에는 HTML5가 제공하는 도구를 올려놓는 것만으로 작업이 끝나지만 추가적인 기능을 원한다면 적절한 솔루션을 구매하거나 직접 만들어야 한다. 브라이트커브에서 서비스하는 HTML5 비디오 역시 보이지 않는 영역에서 수많은 서비스를 제공하고 있기 때문에 단순한 비디오 태그를 사용하는 것과 차별화된 서비스를 가져갈 수 있다.
이렇게 확장된 기능은 역할을 어떻게 나눌 것인지에 대한 논란으로 이어진다. 일반적인 웹개발팀이라면 기획, 디자인, 개발 3가지를 담당할 수 있는 멤버가 필요한데 CSS만으로 지원할 수 있는 기능이 확대되면서 기획, 디자인만으로 작업이 끝나는 경우도 생길 수 있다. 그리고 이런 과정에서 역할에 대한 논란이 생길 수 있다. 어도비나 마이크로소프트웨어의 경우 카탈리스트나 스케치플로우와 같은 도구를 가지고 프로토타입이나 인터랙션 디자인을 설계할 수 있는 방법론을 제시하였으며 디자인 도구에서 만들어진 결과물을 코드로 자동화되어 반영시킬 수 있는 기능을 어느 정도까지 지원하고 있다. 하지만 여전히 디자이너에게는 개발과 관련된 코드가 붙는 것이 어렵고 개발자에게는 잘 정돈되지 않은 스타일과 이미지를 다루기가 어렵다. HTML5에서도 이런 이슈는 여전히 남아 있을 것이고 최근 엔터프라이즈 애플리케이션을 공개된 라이브러리를 가지고 개발하는 경우 중간에 퍼블리셔 역할을 배정해 디자인 작업을 기본적인 코드로 작업해주는 프로세스를 추가하는 경우도 있다.
기업에서 HTML5 어떻게 준비해야 할까
어도비 플렉스 팀의 발표 중에서 HTML5가 엔터프라이즈 애플리케이션 개발을 위한 최선의 기술이 될 것이라는 언급이 포함되어있었다. 이 부분 때문에 커뮤니티의 오해를 불러일으켰는데 이런 말속에 담긴 의미를 제대로 이해하려면 실제 HTML5가 어느 정도 엔터프라이즈 시장에 가까이 가고 있는지 살펴보는 것이 좋을 듯하다.
추가적으로 공개한 자료를 보면 내부적으로 2012년까지 계획을 가지고 MXML(플렉스에서 사용하는 마크업 언어)과 액션스크립트를 HTML과 자바스크립트로 만들어주는 Falcon이라는 코드명의 크로스 컴파일러를 준비하고 있다고 언급했다. 개발 단계에서 RIA 프레임워크를 사용하는 것은 다양한 기능을 쉽게 구현할 수 있다는 점에 있다. 드래그앤드롭, 애니메이션, 데이터 바인딩 등의 복잡한 내부 작업은 프레임워크에서 담당하고 개발자는 비즈니스에 집중할 수 있게 한다는 것이 대부분 RIA 프레임워크의 공통점이다.
(그림 5. 오픈라즐로 구성도)
하지만 이런 방식은 이미 만들어진 프레임워크가 존재하고 있다. 오픈 라즐로(http://www.openlaszlo.org)가 유사한 형식으로 LZX로 선언된 문서를 필요에 따라 플래시, 어도비 AIR, HTML5 그리고 폰갭 기반의 하이브리드 앱으로 컴파일해주고 있으며 투비소프트의 엑스플랫폼 역시 XFDL로 선언된 문서를 Ajax 버전이나 하이브리드 형태로 내보낼 수 있는 기능을 제공하고 있다. 이 중간과정에서 컴파일러가 자리를 차지하고 있으며 컴파일러에 의한 최적화는 자유로운 확장에는 제약이 있지만 각 환경에 맞는 최적화를 제공해줄 수 있는 장점을 가질 수 있다.
참고자료
1. Goodbye JavaFX Script, hello JavaFX 2.0
2. 아파치 인큐베이터와 오픈오피스 그리고 Libre Office
3. Apache Incubator
4. Your Questions About Flex
5. BioDigital Human Intro: Explore the Body in 3D!
6. 실버라이트 파이어스타트 키노트
http://channel9.msdn.com/Series/Silverlight-Firestarter/Silverlight-Firestarter-2010-Keynote-with-Scott-Guthrie
728x90
