데스크탑 = 나

첫 글에서는 탄생 배경을, 두번째 글에서는 Media Side Story에 관해서 이야기를 했습니다. 그런데 이런 이야기를 하면서 드는 의문이 있을 것입니다. SilverLight를 그렇데 대단한 것으로 이야기한다면 마이크로소프트의 전략은 지금의 웹과 그 기술들을 넘어서 퇴색시키려는 전략을 이야기하는 것일까요? 아주 먼 미래라면, 굳이 마이크로소프트의 기술이 아니더라도 지금과는 어떤 다른 것을 생각할 수 있을 것이겠고, 단기간내의 기술이라면 그렇게 하고 싶다고 하더라도 가능하지 않은 시나리오일 것입니다.

마이크로소프트의 Presentation 기술들을 X,Y축을 Rich와 Reach로 하여 그려보면 그 모습은 한눈에 보입니다:

Rich란 더 풍부한 사용자 경험을 위한 기술을 이야기하고 Reach는 더 많은 사용자들에게 닿을 수 있는 성격을 말합니다. Future라고 표시되어있는 부분은 아직 미지의 영역이라는 뜻이고 RIA의 방향성과 비슷한 영역일 것입니다. 왼쪽 아래의 영역은 굳이 갈 필요가 없는 영역이겠죠. (참고로 Adobe의 Mike Chambers가 그린 그래프 같은 경우는 시각적으로 Adobe의 기술이 우월해보이는 모습을 위해서 Desktopiness와 Webiness를 한 축에 넣은 이상한 방식을 썼지만 - 마치 WPF가 한쪽 구석에 쪼그리고 앉은 것 같죠^^, Desktopiness의 능력이 한정되어있는 것같이 보이는 이런 모양은 비교자료로는 썩 적합하지 않은 것 같습니다. 왜냐하면 기술의 용도나 기술 자체를 속성이 아닌 겨우 웹과 데스크탑이라는 주관적인 기준으로 제한한 것일 뿐이고 데스크탑 기술이 성장할 수 있는 방향성을 전혀 보여주지 않으니까요.)

위 표에서 Future라는 대형 업체들이 군침을 흘리는 영역을 마이크로소프트가 가기 위해서는 WPF가 Reach를 늘리는 방법이 있거나, HTML/CSS가 Richness의 도약을 하는 두가지 방법을 생각할 수 있겠지만, 이는 불가능한 것은 아니라고 하더라도 이미 단기간에 이루기에는 쉽지 않다는 것을 많은 사례들이 증명해줬습니다.

SilverLight는 이 간극을 최대한 줄여줄 수 있는 기술로 만들어진 것은 이전에도 설명을 했었습니다. 한쪽 속성을 가지는 기술로 현재로써는 상충되는 다른 속성을 가지게 하는 것이 어렵다면, 아예 처음부터 두가지 속성을 가진 기술을 만들어서 그 다음을 생각하기 쉽게 하자는 것입니다. 가능하다면 어느쪽 기술과 합쳐질 수 있다면 금상첨화일테니 그럴 "가능성"만은 남겨두고 말이죠. SilverLight는 태생부터가 위 표의 Future 영역으로 뻗어나갈 수 있는 여지를 위해서 만들어진 기술입니다. 마케터라면 "누구나 쓰는 HTML/CSS + 풍부한 경험의 WPF = 누구나 쓰는 풍부한 경험"을 지향한다고 이야기하겠죠.

SilverLight는 그런 이유로 WPF의 여러가지 성격 외에 ASP.NET과 ASP.NET AJAX가 잘 조화를 이룰 수 있는 형태로 만들어졌습니다. SilverLight의 XAML이 Text 형태인 것은 그리고 XML 형태인 것은 굳이 ASP.NET 뿐만 아니라 PHP든 Java든 어떤 언어라도 쉽게 생성하고 수용하기 쉽게 해줍니다. (누군가가 라이브러리를 만들어주리라 기대합니다.^^) ASP.NET Futures라는 이름으로 ASP.NET (AJAX)에서 SilverLight와의 연동을 위한 기술을 조금 선보이기도 했습니다. XAML DOM을 브라우저에서 접근할 수 있는 것과는 반대로 SilverLIght에서 HTML DOM을 Access할 수 있는 방법도 잘 제공하고 있습니다. 이런 것이 유용한 예로 Jon Udell이 GreaseMonkey에서 SilverLight를 접근할 수 있음을 이야기합니다. 만들어놓고 연동되도록 Bridge를 만든 것이 아니고 애초부터 연동을 생각해서 설계를 했다는 이야기.

이 정도라면 지금의 웹 기술을 버리는 방향이 아니라는 것은 조금 설명이 될 것 같습니다. (SilverLight만이 아니더라도 마이크로소프트의 방향이 웹을 더 수용하는 방향인 것은 근래 MIX에서 발표한 내용에서 찾아볼 수 있을 것입니다.) 웹과의 연동을 위해서 설계를 했다면 이를 최대한 활용할 수 있는 윈윈이 가장 투자한 것을 거뒤들일 수 있는(?) 방법일테니까요. 생산성의 향상과 직결된 Future의 영역을 뭔가가 메꿔주지 않으면 이전의 Software Crisis가 다시 오지 않으리라는 법도 없는 것일지도 모르겠습니다.^^

Microsoft Popfly

Windows Live Dev  Popfly (alpha) Online Tool to Create and Share Mashups

드디어 Microsoft Popfly가 (지난주에) 공개되었습니다. 주인장의 사정으로 바로 블로깅을 하지 못했지만, 반대로 조금 알려진 뒤에 하면 더 나을 수 있는 이야기를 몇자 적어봅니다.

꽤 오랫동안 Popfly의 테스팅을 해오는 와중에 Yahoo!에서 Pipe가 나와서 또한번 따라했다는 이야기를 듣는게 아니냐는 우려를 하기도 했었고, 지금 제한적으로나마 공개한 상황에서 단순한 매쉬업 서비스로 비춰질 수도 있는 상황이기에, Popfly의 기획의도가 처음부터 상당히 달랐다는 것을 조금 설명하면 수긍하지 않을까하는 생각을 합니다.

초창기 Popfly의 전신은 마이크로소프트 내부의 Visual Studio등을 만들어내는 개발 플랫폼 부서(division)에서 새로운 성격의 프로젝트를 만들기 시작하면서부터 기획되었습니다. 그 새로운 프로젝트는 Visual Studio가 Live의 성격을 가져서 할 수 있는 것들을 고민하는 역할을 하는 것이었습니다. 당시에는 마이크소프트 외부에서도 모든 제품이 라이브화된다는 과장보도에 시달리고(?) 있었고(오피스 라이브가 오피스의 동일한 라이브 버젼처럼 이야기하던때), 이 부서에서도 겪고 있던 터라 이미 여기에 눈을 돌려 투자를 생각하고 있었습니다. 이것이 본격화되기 시작하면서 다양한 시도를 생각하고 실험해왔고 다양한 모습으로 바뀌었습니다. (직접적인 산물이 아니라 다른 팀의 산물이기는 하지만 그런 시도의 영향으로 이전부터 서비스로 제공하던 gotdotnet이 소스포지와 같은 www.codeplex.com로 변신하는 모습도 제공되었죠.)

다른 것들에 대한 자세한 이야기는 언급하기 힘들지만, 이 프로젝트들을 통하여 실험한 이런 시도들 중에서는 1. Visual Studio와 온라인 서비스의 연동으로 할 수 있는 것들, 2. 웹의 소셜함을 개발과 연관시킬 수 있는 것들, 3. 웹개발을 온라인 서비스를 통해서 제공할 수 있는 방법들, 4. Microsoft의 차세대 웹과 이들을 연관시킬 수 있는 방법들 5. 웹을 통해서 프로그래밍을 더 쉽게 배울 수 있는 방법들...등이 있었습니다. 이번에 공개한 Popfly는 단순히 매쉬업에 촛점을 둔 것이 아니라 이런 요소들이 모두 들어있는 서비스라고 할 수 있습니다.

Popfly에서는 위의 내용들에 대응하는 다음의 것들을 제공합니다:

• 웹페이지를 쉽게 만들 수 있는 에디터
• 차세대 마이크로소프트 웹 플랫폼인 SilverLight를 기반으로 하여 매쉬업을 쉽게 만들 수 있는 에디터
• 쉬운 사용을 위한 튜토리얼과 문서들과 다양한 예제들
• 에디터 내에서 코드를 쉽게 사용할 수 있는 환경
• 만든 내용들에 별점을 매기고 공개/공유하고 변경하여 사용할 수 있는 장
• Popfly에서 만든 결과물 이외에 Visual Studio에서 만든 것들을 공유할 수 있는 장
• 만든 내용을 다른 사이트에서 사용할 수 있는 방법

"웹에서 비전문 혹은 비프로그래머 취미 개발자(즉, 개발자가 아니지만 개발을 하고 싶어하는 분)들이 사용/개발할 수 있는 공간을 만드는 것이 바로 이 서비스의 취지인 것이죠." 웹의 소셜 서비스에 대한 관심의 레버리지, REST 아키텍쳐의 쉬움과 간단함, OpenAPI의 티핑포인트, 그리고 마이크로소프트의 노하우와 차세대 개발 플랫폼이 어울어져서 만들어진 작품입니다. 비록 알파버젼이지만 말이죠^^ 앞으로 다른 회사들에서도 비슷한 서비스는 충분히 만들어질 것이라는 예상을 합니다만, 이런 다양한 충족조건으로 인해서 당연한 결과임을 생각해봅니다. 물론 그 결과물로 SilverLight 기술의 대표적인 RIA 예제 중 하나가 되기도 했고, 앞으로 웹이 어떤 방향으로 흐를 수 있을지를 시사하는 좋은 계기가 되는 것 같습니다.

아시는 분들은 아시겠지만, 개발툴인 Visual Studio는 Visual Studio Express라는 무료 버젼을 만들어서 공개하고 있습니다. Visual Studio Express는 이를 관장하는 팀이름(NPT)와 일맥상통하듯이 취미개발자를 위해서 무료로 공개한 것입니다. 이와 관련해서 초보자들이 쉽게 언어와 툴을 배울 수 있는 엄청나게 다양한 자료들도 제공됩니다. 이를 만드는 팀인 NPT(취미개발자팀)의 GPM인 존몽고메리가 비슷한 내용을 블로깅했으니 한번 살펴보시면 좋을 것 같습니다. 관련된 다양한 소개 링크들을 그의 다른 포스트에서 보실 수 있습니다.

미국 시간으로 화요일, 우리나라 시간으로 수요일 새벽에 JavaOne에서 JavaFX라는 브랜드로 발표한다고 합니다했습니다. (기사에 따르면) JavaFX는 AJAX나 Silverlight에 준하는 기술이라는 이야기를 합니다. JavaFX는 현재 java.net에서 개발중인 프로젝트 F3(Form Follows Function)를 중심으로 Java의 일반 소비자 제품을 위한 경험을 위해 새로 브랜딩한 이름이라고 합니다. 이에 맞춰 또 다른 하나의 언어로 발전한 F3를 JavaFX Script라고 명명하였고, Sun에서 인수한 SavaJe라는 회사에서 만든 Java를 구동하는 휴대폰을 만들던 기술을 사용하여 JavaFX Mobile이라는 이름으로 모바일 환경을 타게팅한 제품으로 공개한다고 합니다. 물론 이들은 모두 GPL2 라이센스로 오픈소스화 되고 어떤 형식일지는 모르지만 상용 라이센스도 제공할 것이라고 합니다.

F3는 GBTDS(GUI Builder That Doesn't Suck)라는 이름으로 Chris Oliver를 중심으로 시작하여 (아직은 개발중인) 스크립팅 언어로 발전하였다고 합니다. NetBeans용 GUI를 만드는 툴로 시작하여 이를 위한 문법을 만들어낸 것으로(지금은 Eclipse용 플러그인도 제공) 기존/개발중인 Java 기술들의 Gluing/Wiring 역할을 하는 기술이라고 할 수 있겠습니다. 아직은 알파단계의 기술로 일반 릴리스는 미정이라고 합니다.

언론에서는 Silverlight와 Apollo에 대응한다고 언급하고 있지만 Sun에서 이야기한 내용(아래의 비디오 링크)에서는 그보다 더 넓게 이야기하고 있습니다. Microsoft는 WPF+ASP.NET+SilverLight(+ASP.NET AJAX?), Adobe는 SWF+Flex+Apollo(+Spry?) 그리고 Sun에서 JavaFX(+Flair?)로 이야기하고 있는 것입니다. 이미 Sun은 AWT/Swing(/SWT) 혹은 Java2D등이 데스크탑에 있고, Java Applet을 가지고 있습니다. Java Web Start도 가지고 있는 자산 중 하나입니다. JavaFX Script(F3)는 이렇게 가지고 있는 자산을 사용할 수 있는 기반을 마련한 것으로 이렇게 JavaFX라는 전략을 생각해낸 것이라 할 수 있겠습니다.

하지만, 이런 전략에는 아직 많은 난관이 존재합니다. 몇가지 생각나는 것들을 들어보면:

• 풀 JRE(Java Runtime Environment, 플랫폼 별13M~20M)를 사용합니다.
  • 앞으로 Java 7이 더 Modular해지고 작아질 것이라고 이야기하지만, Java 7은 언제 나올지 모르고 나오고 얼마나 많이 성공적으로 배포될 지 이야기할 단계가 아닙니다.
  • 비록 인터넷이 빨라졌다고는 하나 다양한 이유로 일반 웹 유저들이 RIA를 구동하기 위해서 JRE를 설치하는 일은 전에도 어필하지 못했습니다. 이런 문제로 인해서 마이크로소프트에서는 .NET Framework을 작게 만들어 SilverLight에 탑재하는 전략을 사용하기로 했고, Java 진영에서도 해결해야할 문제입니다
  • 일반 non-puter 유저들에게는 다운로드가 쉽지 않습니다. 좀 더 친근한 방식으로 더 쉽게 no-brainer로 다운로드하여 실행되도록 해야합니다.
• JavaFX Script는 상대적으로 어렵습니다.
  • Class라는 개념을 그대로 사용하는데 이는 non-Programmer에게는 쉽지 않습니다. 또한 NetBeans나 Eclipse를 사용하도록 하는 것도 쉽지 않은 일입니다.
  • Lambda the Ultimate라는 언어 관련 블로그에 의하면 동적 언어가 아닌 정적 형식(Statically Typed) 언어라고 합니다. (var이 동적 Typing이 아니고 inferencing이라고합니다.) 이는 JavaScript와는 성격이 다르고 Java,C#에 가깝다는 이야기입니다.
  • Java 사용자를 일차적인 대상으로 하는 것이라는 개인적인 생각이 듭니다. (RIA 시장에 뛰어들기 위해서 타파했어야하는 부분이 아닐까 생각됩니다.)
• 레퍼런스가 부족합니다.
  • Java(JWS)를 사용하는 (java 사용자를 위한 사이트를 제외하고) "대 Mass" 사이트가 없습니다. (오늘 발표할지도 모르겠습니다만)
  • 게릴라나 입소문 마케팅이 되기에도 기존 기술이 더 어필합니다. 아래의 동영상에서는 Flash에서 되는 것이 JavaFX에서도 된다는 이야기를 하지만, 이미 설치되어있는 Flash위에 JavaFX를 사용할 메리트를 이야기하지는 않는다는 것입니다.
  • RIA 시장의 후발 주자임에는 틀림이 없죠. Infoworld의 기사에 의하면 James Gosling이 SilverLight가 비디오/스트리밍에 중점을 둔 기술이라서 JavaFX와 다르다고 이야기했다고 하는데, 잘 모르고 하는 이야기겠죠? (권위에의 호소의 오류?)

Apollo 발표 이후 SilverLight 발표, 그 이후로 또 재미난 게임을 예고하는 재미난 소식입니다.

--

참고 포스트:

Sun's JavaFX to take on AJAX, Silverlight  InfoWorld  News  2007-05-07  By Paul Krill

» Sun preparing answer to Flash, Silverlight  Ed Burnette’s Dev Connection  ZDNet.com

» Sun enters the Rich Internet Application world with JavaFX  The Universal Desktop  ZDNet.com

» JavaFX takes center stage at JavaOne  Ed Burnette’s Dev Connection  ZDNet.com

Silicon Valley Sleuth Sun goes after Adobe Apollo, Ajax, Silverlight (비디오)

부제: Media Side Story

아직도 해외 어디어디 갔더니 인터넷이 느려서 UCC 동영상은 도저히 못보겠더라는 이야기를 들으면 많은 동영상/멀티미디어 사이트들이 받는 전망들을 생각할때 갸우뚱하게 합니다. 구체적으로는, 그냥 구글이 유투브 인수하니까 그래보이는거고 인터넷 인프라가 발달한 우리나라에 국한된 이야기가 아닐까하는 의문이겠습니다. 진실은 그럴지도 모르는 일입니다. 혜택을 누리는 사람들과 그렇지 못하는 사람들의 격차가 벌어지고 있는 것인지도 모르겠습니다. 하지만, 분명히 웹을 통해서 rich media(리치 미디어 - 한글로 리치라고 하니까 꼭 leech(거머리)라는 의미같아보이기도 합니다^^)의 혜택을 받는 사용자는 분명 엄청나게 늘어나고 있고, 트래픽량과 증가추이가 이를 뒷받침해주고 있습니다. 순수한 웹브라우저만으로는 가능하지 않은 Media 시나리오들이 웹의 미래가 향한 가는 길이라는 것을 뒷받침해주고 있습니다.

(순수한 웹브라우저를 위한) 웹표준의 영역은 그 노력에 비하여 멀티미디어의 영역과는 상당히 동떨어져있습니다. 브라우저에서 음악이 나오기 위해서는 컨트롤이나 플러그인이 불가피합니다. 브라우저에서 동영상을 보기 위해서도 컨트롤이나 플러그인이 불가피합니다. 10년도 더 되는 시간동안 발전한 swf가 있는데, 이제야 만들어낸 브라우저에서 지원하지도 않는 canvas 태그같은 것으로 간단한 애니메이션을 보는데에 사용자가 만족할까요? 그리고 이것이 권고안이 될때까지 기다려야할까요? 권고안이 되면 기존의 것들을 그 방식으로 바꿔야 할까요? 그리고 정말 브라우저들이 이를 따르는 것이 모두를 위한 일일까요? swf가 표준이 아니고 회사가 소유하는 것이기 때문에 사용자는 웹표준으로 옮겨가야할까요? 동영상/음악을 위한 웹표준이 만들어진다면 어떤 포맷을 지원해줘야할까요? 모든 포맷을 다 사용할 수 있는 컨테이너 포맷이 만들어진다고 하더라도 브라우저에서는 모든 코덱을 지원해야하는 것이 될까요? 이런 것을 정하기 위해서 또 얼마나 더 오랜 시간이 걸릴까요? New Media에 맞는 웹을 위해서는 이렇게 커다란 질문들이 펑펑 쏟아져나올 수 밖에 없습니다.

반대로 생각을 해보죠. Media라는 것은 원래 웹브라우저에 한정된 것이 아닙니다. 그런데, 웹표준에 국한된 웹브라우저는 Media를 한정합니다. 간단히 접근성의 한 예를 생각해봅시다. 스크린리더를 위하여 웹페이지를 읽어줄 수 있도록 만들어야된다는 이야기는 있어도 웹페이지 자체에서 음성을 제공할 수 있는 방법은 웹표준에는 없다는 것입니다. 유일한 방법은 웹브라우저를 확장하는 방법 뿐입니다.

사실 사람들이 웹이라는 것을 바라보는 시각은 "State of Mind"일 뿐입니다. 동영상을 링크를 눌러 다운로드하여 데스크탑의 플레이어로 보는 것과 동영상이 웹페이지에서 보이는 것 두가지가 기술적으로 얼마나 다를까요. 바로보나 다운로드해서 보나. 헌데, YouTube는 엄청난 성공을 가져왔습니다. 그 성공과 함께 Flash Player의 동영상 기술도 같이 성공을 가져왔죠. 꽤 오랫동안 우리의 눈앞에 와있던 New Media를 웹을 통해서 제공하기 위한 노력은 수도 없었습니다. 이런 노력을 위해서는 (이를 거부하지 않는다면) 수없이 깔리는 컨트롤/플러그인들을 이제와서 피할 수는 없습니다.

그렇다면, 단순히 각 기능에 대해 어떤 특정한 Player(컨트롤이나 플러그인)가 아니라 이런 모든 Media를 위한 플랫폼 - 그것도 cross-browser cross-platform이고 보안도 걱정해주는 - 이라면 어떨까요? 웹페이지를 New Media에 맞게 만들 수 있는 그런 플랫폼 말이죠. 그게 요즘 웹의 미래를 그리는 사람들의 공통적인 생각중 한가지입니다. 거기에 여러 업체가 동참했고, 그 중 하나가 마이크로소프트입니다.

그리고 이를 위해 SilverLight가 탄생합니다. 이게 SilverLight의 Media Side Story입니다.

SilverLight라는 단일 플랫폼에서는 이종 브라우저와 OS에서 돌아갈 수 있는 다음의 Media들을 제공합니다:

• 벡터그래픽
• 비트맵그래픽
• 텍스트
• High-Quality (스트리밍)비디오
• (스트리밍)오디오
• 애니메이션
• 그리고 이 모든것의 통합 wiring.