데스크탑 = 나

아직 소식을 듣지 못하신 분들은 보도자료를 여기서 보실 수 있습니다. 스코블이 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라는 브랜드 입니다.