데스크탑 = 나

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 (비디오)

아직 소식을 듣지 못하신 분들은 보도자료를 여기서 보실 수 있습니다. 스코블이 Flex 팀원들과 독점 인터뷰를 한 동영상도 있습니다. 발표에서는 실제 오픈소스화가 6월에 조금씩 시작하여 2007년 말에 완료될 것이라고 이야기하고 있습니다. (Adobe의 Flex SDK 오픈소스화에 관하여 더 자세히 알고 싶은 점이 있다면 이에 관한 토론을 위해서 만든 구글 그룹을 통하여 질문할 수 있습니다. 현재 몇가지 궁금한 내용들을 Adobe에서 답변을 달아준 내용들이 있군요.)

현재 버젼 2까지 나온 Adobe Flex라는 제품은 Flash를 기반으로 하는 RIA를 제작할 수 있는 프레임웍입니다. 이 Flex라는 프레임웍은 Flex SDK와 Eclipse를 기반으로 한 Flex Builder라는 이름의 개발툴 그리고 FDS(Flex Data Services, LDS) 와 Flex Charting등을 포함하며 MXML이라는 마크업과 ActionScript 3.0을 기반으로 합니다. 이 중에서 Flex SDK에는 주요 프레임웍 라이브러리와 Flash를 생성/제어(Control, Layout, Styles)하고 인터페이스할 수 있는 등의 컴포넌트들과 컴파일러를 포함한 툴들이 포함되어있습니다. 오픈소스화되는 부분은 이 SDK 부분이고 현재는 무료로 배포되고 있습니다.

Adobe에서는 이미 Tamarin(AS3용 VM)을 Mozilla에 기부하여 오픈소스화 했고, FA Bridge(Flex-AJAX Bridge)도 Adobe Labs에서 (javascript이므로 당연히)코드 라이브러리로 제공하고 있습니다.

Flex SDK의 오픈소스화는 몇가지를 시사하고 있습니다.

첫째로, Adobe의 플랫폼 비즈니스로의 전환에 뒤늦었지만 개발자 커뮤니티 포섭이라는 카드가 중요하다는 것을 깨달은 이후에 그 방법을 조금씩 배워 있다는 증거입니다. 깨달았다는 사실 하나만으로 공격적이라고는 할 수 없었지만, 그 이후의 방향선회로 이제는 개발자의 이목을 집중시키는 방법을 알아가고 있다는 것입니다. 이것이 매크로미디어의 인수 영향인지, 아니면 그 이전에 그런 안목을 가지고 매크로미디어를 인수하고 시작한 것인지는 알 수 없지만 말이죠.

둘째로, 캐시카우는 이쪽 영역이 아니라는 것입니다. 이미 알다시피 FMS(Flash Media Server)라는 비싼 서버가 있고, 정작 기업에서 사용할 FDS도 오픈소스 영역에 포함되어있지 않습니다. FDS는 Midnight Coders를 인수하여(졸다 잘못적었나보네요, 허위정보 죄송합니다;)통하여 그 기능을 강화하기도 했고, FDS의 차기버젼은 LDS(Lifecycle Data Services)로 이름이 바뀌어 Lifecycle 서버 제품군과 엮입니다. Lifecycle 서버 제품군은 또하나의 Adobe의 캐시카우로 예상되는 것중 하나입니다. (플랫폼 비즈니스에서 플랫폼 자체는 투자대상이지 수익을 낼 수 있는 곳이 아니죠.)

셋째로, 플랫폼 비즈니스의 핵심 컴포넌트인 런타임(flash/apollo)을 오픈하여 내놓을 생각은 아직 없다는 것입니다. 라이센싱을 통하여 얼마든지 플래시 플레이어의 코드를 사용할 수 있는 여건이지만, 그것은 오픈소스와는 다른 이야기입니다. 오픈소스 요구와 그렇게 될 경우에 얼마나 굉장한 플러스 효과가 있을 것인가를 이야기하는 사탕발림으로 여기저기서 이야기하지만, 정작 Adobe는 이 부분에서 손바닥을 보이고 있습니다. 가장 뻔한 이유는 소스는 필요하면 줄테지만 방향은 우리가 정해야한다는 기조일 것입니다. 여기저기서 자기네가 만들었다고 하는 플래시 아류 버젼들이 출몰하는 현상을 걱정하는 것이라는 추측 말이죠.

넷째로, OpenLaszlo등의 RIA 프레임웍들의 영역을 이전보다 심각한 경쟁상대로 인식하고 있음을 추측할 수 있습니다. 서드파티로 인식하고 있는 것과는 각도가 사뭇 다른 것이죠. 시각을 돌려서 이야기하면 비즈니스 영역이 대부분 겹치게 되었다는 말이 되겠구요. 심각하다고 큰 위협으로 생각하느냐는 추측하기 힘들지만, 사실 이는 새로운 이야기는 아닙니다. 매크로미디어 시절(2004년) open laszlo를 베껴서 Flex의 전신인 Flex Presentation Server를 만들었다는 이야기가 있었기 때문이죠. (반대로 "아싸"를 외치면서 어부지리를 블로깅하는 회사도 있습니다.^^)

여하튼 Adobe의 행보는 분명 플랫폼 비즈니스라는 사실에 대해서 굳히기에 들어갔습니다. PC가 아닌 핸드폰이나 디바이스들까지 포함하여 OS에 종속적이지 않은(Cross-Platform) 플랫폼 - 이전에는 플랫폼으로 생각하지 않았지만 - 을 가지고 있는 기업으로는 유일하기에 이를 leverage하는 전략은 어쩌면 당연하다고 할 수 있겠습니다만, 그 쪽 비즈니스의 경험이 많지 않기 때문에 침착하게 잘 지켜보면서 행보를 정하고 있다고 할 수 있겠습니다. 그런 입장에서 마이크로소프트와의 전쟁은 불가피한 것이겠습니다. 브라우저 전쟁 이후로 재미난 진행을 기대해봅니다.

이야기는 98년도로 거슬러 올라갑니다. 마이크로소프트는 지금은 AJAX라는 방식이 생기게 된 계기인 XMLHttpRequest라는 녀석을 포함하여 브라우저의 방식으로 인한 한계를 극복할 수 있는 새로운 것을 넣고자하는 방법을 고심하면서 나온 여러가지 부가 기술들을 생각해냅니다. XMLHttpRequest와 다른 기술들은 당시 다양한 방식의 아이디어들을 들고 나온 수많은 업체들을 양산하지만, 이 기술들은 사용자들에게는 결국 티핑포인트를 만나지 못하고 어필하지 못하게 되고 그런 업체들도 빛을 보지 못하고 역사의 뒤안길로 사라져버리거나 방향을 바꾸게 됩니다. 이런 기술의 사용률과는 반대로 때마침 브라우저 점유율은 올라가고 이 두가지 상반된 데이타로 인해서 고심 끝에 내린 결론은 여러가지 주변 여건과 웹브라우저의 역사적인 문제들을 총괄해볼때 브라우저에 새로운 것들을 넣는 것보다는 브라우저 바깥 세상을 통해서 웹을 접근하는 것이 괜찮지 않겠냐는 생각이었습니다. 당시의 수치로는 그것이 IE(인터넷 익스플로러)에게는 맞는 것처럼 보이는 선택이었습니다.

그리고는 그 이후 수년동안. 가라앉은 Netscape(넷스케이프)와는 대조적으로 전체적으로 정비를 가다듬은 아들 Mozilla(모질라)는 그간의 실수를 바탕으로 FF(FireFox, 파이어폭스)라는 브라우저를 만들어내고 다시 점유율 탈환에 나서게 됩니다. IE의 이전 결정이 오래가자 변화없음에 싫증과 불편함을 느낀 유저들은 새로움과 신선함의 냄새가 나는 FF를 취향에 따라 골라서 사용하기 시작하고 이런 현상으로 변해가는 점유율과 이전에 내렸던 결론과 다른 방향으로 가는 수치는 움직이지 않던 IE를 움직이게 만듭니다. FF는 배타적이기보다는 IE에서 성공한 기술들도 수용함과 동시에 표준을 통하여 이종 브라우저간의 간극도 조절하자는 운동을 동반하여 브라우저가 더 앞으로 나아 갈 수 있는 모습을 보여주게 됩니다. 이전과는 다르게 이런 상생의 길이 더 뚜렷해지자, IE는 빠른 시간내에 7번째 버젼을 만들어내고 차세대 버젼들에 관한 약속들을 하게 됩니다.

하지만, 이런 현 시점에서 브라우저들의 개발 방향은 새로운 기술의 고안이나 혁신과는 사뭇 다른 길이라는 것이 명백해집니다. XMLHttpRequest의 업그레이드 기능 같은 것을 넣는다고 한들 다른 플랫폼, 다른 브라우저들이 지원하지 않는다면 이전보다 효용가치가 떨어지는 것은 분명하다는 것을 이미 배운 상태입니다. 새로운 기능은 모두가 동의할 수 있는 표준이라는 합의를 통해서 구현하여 넣는 길고 긴 방식을 택할 수 밖에 없는 상황인 것입니다.

이 이야기에 첫번째 조미료로 ActiveX(액티브엑스) - 이는 마케팅 용어로 사실은 OLE/COM을 기반으로 한 개발 방식과 기술을 통칭하는 말입니다 - 라는 말이 등장합니다. 그 기술 중에서도 IE 브라우저를 통해서 볼 수 있는 웹응용프로그램을 확장하는 기술로 바뀐 ActiveX Control(컨트롤)이라는 것이 또하나의 아픈 경험이 되어줍니다. 남용되는 사례가 많이 발생하여 특히나 우리나라에서는 마치 그 기술 자체가 마이너스적인 이미지가 큰 기술로 남게되었지만, 그 남용은 기술 자체의 문제보다는 사용자가 기술적인 부분들을 알지 못하면 막는 장치가 소용이 없는 구현 방식에 있었던 것이었습니다. 예를 들어, 믿을 수 없는 사이트에서 받는 컨트롤은 실행되지 못하거나 사용자에게 묻도록 막았지만, 실상 사용자는 필요에 의해서 혹은 사이트의 편의에 의해 지칭되어 이를 끄거나 묻더라도 무조건 yes를 누르는 습관을 조장한 결과가 되었습니다. 비유하자면 동물들을 기르기 위해서 굉장히 넓은 목초지를 제공했지만, 울타리를 원하는대로 세울 수 있도록 한 것이 되려 울타리를 허술하게 세운 농장주를 조장할 꼴이 된 것입니다. 그 덕에 목초지를 제공한 것 자체도 잘못된 것으로 틀리게 인식하는 결과가 되었습니다. 만일 이런 기술이 없었다면 우리는 브라우저에서 동영상을 보는 것은 틀린 일일것이고, 자바애플릿도 돌릴 수 없는데다가, 흔히 사용하는 Flash 애니메이션도 없었을 것입니다.

두번째 조미료로 이런 브라우저 자체의 움직임과는 별도로 브라우저의 능력을 최대한도로 발휘하거나 넘어서고자 하는 RIA(Rich Internet Application) 기술들이 여러차례 시도되고 만들어집니다. 여러가지가 있었지만, 대표적으로 그 중에서도 95년에 만들어진 이후로 굉장한 점유율을 차지하게된 Flash(플래시)라는 기술을 합치고자 하는 주류와 Flash를 브라우저의 일부로 인정하지 않는 AJAX 주류로 나뉘어지게 됩니다. AJAX는 이미 표준격이 된 기술들을 사용함으로써 이종 브라우저와 플랫폼에서 비슷한 효과를 보여줄 수 있는 이점이 있는 경우이고, Flash의 경우에는 IE에서는 ActiveX Control 기술을 사용하여 FF나 Safari(사파리)에서는 나름대로의 플러그인 기술들로 다르게 구현을 하였지만, 공통 분모인 Flash 런타임이 이런 다른 브라우저간에도 비슷한 동작을 할 수 있도록 보증을 하고 있는 경우입니다. 지금 UCC라는 이름으로 화두가 되고 있는 동영상(Media)같은 것을 사용하기 위해서는 후자 혹은 AJAX+타기술을 사용할 수 밖에 없기 때문에 사실상 Flash의 미래가 더 밝은 편이라는 분위기인 것은 명백한 사실입니다. 동영상 포맷이나 코덱을 하나로 표준화하여 브라우저의 기본기능으로 제공할 것이라는 생각이 호응을 얻을 수 있을지는 미지수겠습니다.

Flash는 위에서 언급했다시피 Flash Runtime이라는 울타리를 수년동안 잘 갖춰놓았고, 또한 모바일 플랫폼을 포함한 여러 플랫폼으로의 포팅도 성공적으로 진행하고 있는 현재의 몇 안되는 브라우저의 확장 대안으로 떠오르는 녀석입니다. 이런 분위기에 편승해서 Adobe도 이전의 전략을 수정하여 Flash를 활용할 수 있는 환경을 꾸미는 여러가지 각도에서 공격적으로 세를 넓히고 있는 중입니다. Flash의 사례와 같이 브라우저 위에 한 층을 꾸밈으로써 그 아래의 브라우저와 플랫폼을 신경쓰지 않아도 되는 크로스 플랫폼/브라우저 방식이 사용자들에게 어필하고 있다는 점은 마이크로소프트에게는 또하나의 배울 점이었습니다.

마이크로소프트에서는 이런 여러가지 문제점들을 뼈저리게 경험해보고 새로운 진화를 위한 방법을 모색하기 위해서 다른 회사/기술들이 저지른 실수들의 문제점들을 모아모아 앞으로 갈 길을 분석에 분석을 하기 시작합니다. 그 전략으로 IE의 개선과 함께 AJAX의 수용을 위해서 수년전부터 개발하여 최근 출시한 ASP.NET AJAX를 일부 소스 공개와 함께 했고, 데스크탑에서의 Rich 응용프로그램 개발의 혁신을 위하여 WPF(Windows Presentation Foundation, 윈도우 프리젠테이션 파운데이션)을 XP/2003/Vista에 정렬하여 내놓았습니다. 이 양극의 중간을 메꿀 필요가 있음은 위에서 설명을 했고 이를 위한 전략의 일부로

"다양한 브라우저와 다양한 플랫폼에서 사용할 수 있고 + 기존의 웹브라우저에서는 할 수 없지만 사용자의 요구가 있는(Media, Richness, Transparency, Programmability) 것들이 포함되면서도 기존의 기술들과 쉽게 연동되고 + 사용자가 쉽게 사용할 수 있으면서도 제대로된 튼튼한 울타리가 지어져 있으며 + 이전의 패러다임보다 나은 패러다임들이 반영된 차세대의 웹의 모양을 만들기 위한"

새로운 플랫폼으로 만들어낸 결과가 바로 SilverLight라는 브랜드 입니다.

그냥 주절댔던 이야기라 좀 Update하고 싶지만, 게을러서 스크랩.ㅡ,.ㅡ;;

--

원문 링크(2006/4/16 작성)

어울리지도 않는 기능들을 포함한 소셜하지 않은 응용프로그램의 똑같은 기능을 굳이 웹 환경으로 다시 구현해서 서비스하는 이유가 무엇일까를 생각해본다. 웹의 커넥션 혹은 링크를 응용한 것이 아니라면 그냥 독립적인 응용프로그램과 다를바가 없는 것들을 왜 제한된 웹브라우저 환경으로 만들어서 사용자를 헷갈리게 만들까. 혹은, 소셜한 기능들/커넥티비티를 응용하는 기능들만 연동하도록 하여 그에 해당하는 부분만 웹화하면 안될까. 또, 왜 그걸 써서 서비스하는 사람들이 또 만들게 하는 순환이 이어질까. 그 이유만 명확하다면 다시 굳이 기능들을 억지로 만들 이유가 없지 않을까.

물론 서비스를 만드는 입장에서는 "우리 마음이다. 쓸놈있으면 만든다."일테지만, 결국 사용자가 있다는 것이다. 그것도 (나도 포함한) 아주 많이. 단순히 구글 캘린더를 예로 들어보자. 굳이 온라인 캘린더 서비스를 사용하는 이유는? 스케줄링 응용프로그램이 후져서는 절대 아닐 것이다. 기능이 훨씬 많고 좋다는 것은 분명하다. 게다가 온라인 서비스를 만들때처럼 무지막지한 서버인프라도 필요 없을 것이고, 브라우저마다 다른 마크업/css 조율을 할 필요도 없을 것이고, AJAX노가다를 할 필요도 없을 것이고, 게다가 한 웹응용프로그램에서 생각해야할 크로스플랫폼도 고민이 아닐 것이다(각기 따로 만들면 되니까…요건 약간 논외). 굳이 필요없는 트래픽 유발할 필요도 없고, 삐까번쩍한 효과는 식은죽 먹기일 것이다. 회사 네트웍이 다운돼도 잘 쓸 수 있고, 네트웍이 느려서 기다리는 일도 없을 것이다. 공유기능들과 연동기능들만 응용프로그램에 구현해 넣어서 웹으로 제공할 수 있게 하면 되는 것이 아닐까?

데이타가 안전한(?) 곳에 저장된다는 생각일까? 데이타가 날아가도 내 책임이 아니라고. 웃기는 소리같다, 절대 아니라고 생각한다. 온라인 서비스에서 데이타를 날릴 가능성이 없지도 않을 뿐더러, 날려도 어쩔 것인가? 소송한다고해서 날라간 데이타가 다시 돌아오나? 그건 아니다. 엄청나게 많이 쏟아지는 서비스 속에서 극히 일부 서비스들을 제외하고는 그렇게 3중4중으로 방비하는 경우가 많지 않다. (게다가 정말정말 중요한 데이타를 온라인으로 보관하세요?) 물론 내 PC의 하드가 망가져서 날라간 데이타와는 다르게 책임은 떠넘길 수 있다.

웹브라우저를 사용하면 어디든 액세스해서 사용할 수 있기 때문에? 이것도 사실은 웃기다. 해당 서비스의 해당 기능을 위해서 사용하는 장소가 회사/집 이외에서 사용하는 경우의 수가 얼마나 될까? 정말 그렇게 엄청나게 많은 서비스에 비례해서 빈도가 높을까? 노트북은 맥, 데스크탑은 윈이기 때문에? 그래서 웹브라우저를 사용하면 양쪽 다 액세스 가능해서 웹서비스를 사용하나? 어떨때는 중요할지 모르겠지만, 응용프로그램의 기능들을 포기할 정도로 매력적인 사유는 아닌 것 같다.

웹브라우저로하면 뭔가 쿨해보인다??? 그것도 뭐 이유아닌 이유일 수 있겠지만, 심리학적인 이야기같은 것은 전문가가 아니니 빼보도록 하자. 웹브라우저라는 단일한 인터페이스에 익숙한 경험(Experience)? 어쩌면 좀 맞는 이야기일 수 있겠지만, 메신저는 웹메신저를 쓰는 빈도가 높지 않다는 이유로 접어보도록 하자.

이 이야기를 보고는 "난 아닌데"하는 분들 눈에 보이고 그것에 틀렸다거나 잘못된 것이라는 이야기를 하고자하는 것이 아니다. 다수의 사용자에 대한 시나리오 혹은 한 사용자에게 자주 일어나는 시나리오가 아니지 않을까하는 것을 이야기하고자 하는 것이다.

내 생각은? 내 결론은 단순하다. 아직도 데스트탑과 웹간의 밸런싱을 이해하는 마인드/인프라/방법론/(뭐든)가 만들어지지 않았다고 생각한다. 어디까지 데스크탑에서 구현하고 어디까지 웹으로 구현해야한다는 기획 자체가/로 성공하기가 쉽지 않은 일이다. 지금 당장의 대세이자 다수 사용자의 눈높이는 웹이다. 어떻게 하면 웹을 활용할 것이고, 어떻게 하면 웹서비스에 많이 접속할 것이고, 어떻게 하면 웹에 널린 데이타를 잘 사용할 수 있을 것인가가 가장 중요하다. 웹에서 뭔가 만들었다고 하면 일단 사용자가 관심을 가지는 때이다. 어떤 웹서비스를 만들때 이 기능을 응용프로그램으로 이 기능을 웹으로 그리고 이정도는 연동하고 이 기능은 하이브리드로…처럼 기획되는 경우는 흔하지 않다. 양쪽 경력을 가지기도 쉽지도 않지만, 사용자에게 익숙하지도 않을 것이다. 예를 들어 구글 데스크탑이 없었다면, 아직도 데스크탑 검색은 웹 검색과는 융합될만한 것이 아니라는 것으로 인식하고 있을 사용자가 훨씬 많을 것이다.

사용자는 사실 속고 있는 것이다. 우리가 많이 접하는 ActiveXControl을 사용하는 것은 웹브라우저의 일부 기능으로 사용하는 것처럼 속이지만, 사실은 웹브라우저의 일부가 아니라 그냥 데스크탑 프로그램이다. 그렇지 않다고 생각하는 경우라도, 많은 ActiveXControl들이 내부 프로세스(프로그램)을 설치해버리는 경우도 많다. ActiveXControl은 웹(브라우저)와 데스크탑(응용프로그램)과의 하이브리드를 위한 방편이다. 그 밸런싱이 쉬운 일이 아니기 때문에 브라우저라는 기준을 만들어주면 훨훨훨씬 그 하이브리드를 만들기 쉬운 것이다. 이 때문에 샌드박스 형태가 아니었으며 자유도를 한참 높임으로써 보안 타겟이 될 수 밖에 없는 형태였다. 플래시 플레이어가 브라우저의 일부일까? 절대 아니다. 브라우저에서 지원하는 표준을 사용하지도 않을 뿐더러, 어도비에서 그 기능을 제어한다.(그럴리는 없겠지만 예를 들어서) 어느날 어도비가 플래시플레이어에서 gif이미지를 지원하지 않겠다고 하면 지원이 안되는 것이다.

보안이라는 커다란 문제에 봉착하게 되었지만, 사실 이 보안이라는 문제는 브라우저의 문제라고 단순하게 단정할 수 없다. 웹페이지에 가서 감염이 되었기에 브라우저의 문제로 보이지만, 본질적으로는 플랫폼과 사용자 모두의 문제이다. 브라우저가 엄청나게 많이 사용되기 때문에 이슈가 된 것이지만(그렇다고 브라우저가 보안에 취약해도 괜찮다는 말은 아니다), 내 PC에서 돌아가는 모든 프로그램이 가진 똑같은 책임과 의무이다. 아무튼 이런 보안 문제는 또 다른 이야기로 남겨두고, 하고자 하는 이야기는 이 마치 브라우저의 일부라고 생각하는 것들을 통해 데스크탑으로 가고자 하는 것이 지금의 기술이 발전하는 방향이라는 것이다.

아주 단순화시키면, RIA는 브라우저의 일부로 보이는 것들을 일부가 아닌 것으로 보이게 하는 방법이고, WPF는 플랫폼 자체를 웹브라우저처럼 보이게 하는 방법이다. FF 익스텐션은 모질라 응용프로그램이 브라우저를 벗어나기 위한 움직임으로 사용될 발판이다. DHTML/AJAX같은 것들은 기존보다 뭔가 향상되기는 했지만 분명 사용자의 욕구를 채워주기에는 턱없이 부족한 도구이다. 자꾸 이런 Rich(Rich가 절대 복잡성을 대변하는 것이 아니다)한 기능들이 브라우저 자체에 들어가면 들어갈수록 응용프로그램화 되어가는 것 뿐이고 가는 방향만 명백해지는 것이다. 웹(혹은 웹이라는 말)이 만능이 절대 아니다. 웹표준을 지키면 많은 것들이 편해지고 좋아지겠지만, 데스크탑 위에서의 삶 자체도 편해지는 것이 아니다. 미래에는 웹브라우저에서 3D가 돌아가고 게임을 하게 될 것이라는 말을 한다면 거짓말을 하는 것이다. 얼마든지 웹브라우저 유무와 상관없이 지금 누리고 있는 것들이다. 데스크탑은 데스크탑이다. 웹이 플랫폼이라는 말은 웹이 OS라는 말로 혼동하게하는 말하기 좋아하는 사람들은 믿지 말자. 뭘 꿔다 맞춰도 웹이라는 말을 붙이면 호응을 얻을것이라고 생각하는 속셈일 뿐이다.

내가 생각하는 웹 응용프로그램들은 사용자들을 한단계 앞으로 갈 수 있도록 교육시켜주는 도구이다. 특히나 Mass를 대상으로 하는 기술이 갑자기 한단계 건너뛰고 등장하는 것은 실패의 확률이 높다. 왜냐하면 사용자가 익숙하지 않을 것이고, 그렇다면 사용하지 않을 것이고, 결국 사용하지 않는 서비스는 어딘가에 전시하는 것 이외에는 의미가 없는 것이다. 사용자들이 블로깅하도록 만드는데 도대체 몇년이나 교육을 한 것인가 생각해보라. 그 웹 응용프로그램이라는 서비스들은 결국 브라우저를 박차고 나오거나 브라우저를 박차고 나오지 않은척하면서 나와있을 것이다. 그렇지 않으면 뒤쳐져있을 것이니까.