작년말 올해초에 걸쳐서, 여러 인터넷 매체와 블로그들을 통해서 "웹 브라우져 시장의 뜨거운 경쟁"에 대해서 이야기되고 논의되어 왔다.

이와 더블어 한국에서는 절대로 빼어 놓고 이야기 할 수 없는 부분이 있는데, 이는 "Active X의 지원"에 대한 이야기이다. 웹 표준은 계속해서 발전 또는 변화하고 있기 때문에, 과거와 현재의 브라우져가 동일한 결과들을 사용자에게 제공하지 못한다. (여기서 내가 변화라는 단어를 사용한  이유는 완벽한 호환성을 제공할수 없기 때문이다. 어떠한 이유에서 인지, 기존에 제공되었던 기능들이 사라지거나 제거 되고 있다.)

10년전에도 비슷한 상황들이 있었지만, 그때만 해도 Microsoft의 IE와 Netscape의 Nevigator 브라우져의 싸움이었다. 이당시에는 브라우져가 지원하려는 기능들이 지금의 것보다 제한되어 있고, 지금만큼 네트워크 망이 안정적이고, 빠르게 구성되어져 있지 않기 때문에, "표준화된 스펙을 따르기 보다는, 조금도 많은 기능들을 추가하고 좀더 빠르게 사용자에게 제공할 수 있을까?"가 경쟁의 주요 포인트 였었다.
이러한 관점에서 마이크로소프트는 자신들의 모든 역량을 브라우져 개발에 집중하였었고, 브라우져의 기능적인면과 속도의 향상적인 측면에서 넷스케이프를 압도할 수 있었다.

당시에는 두 회사의 기술적인 차이는 늦게 웹부라우져 시장에 진입한 마이크로소프트사의 주도면밀한 기능의 추가와 전략들을 선보였다. 이중에도 HTML4를 IE4에서 지원하기 시작한 것이 가장 이상적인 것이었고, 웹 브라우져를 ActiveX 컨트롤(OLE)의 컨테이너로 사용하는 것이 두번째로 인상적인 것이었다. 세번째는 브라우져와 OS가 하나의 시스템을 구성하고 있기 때문에 절대로 분리할 수 없다는 것으로, 지금도 나는 믿지 않고 있지만, 같은 시스템의 리소스를 사용하고 있다는 것이다.

이때에 벌어지기 시작한 기술적인 변화와 차이들은 두 브라우져의 간극을 더 크게 벌리기 시작하였다. (이 외에도 제품의 시장성에 대한 부분도 있지만, 이야기가 길어져서 논하지 않으련다. 당시만 해도 넷스케이프는 돈을 받고 파는 제품이었다.)
왜냐하면, 이때는 과도기였기 때문에 개발자와 사용자들이 표준화보다는, 자신이 원하는 기능들을 쉽게 개발해서 제공하 수 있었기 때문이다. 사용자들은 새로운 환경으로 적응하는 단계였기에, 기존에 PC 애플리케이션 만큼의 기능들을 웹에서 구현해서 사용하기를 원했다. (제한된 네트워크 속도와 사용성 측면에서 웹이 독립 애플리케에션을 따라가기는 쉽지 않았다.)

일례로, 1998년경에 PC통신 서비스를 웹 기반의 서비스로 만들 회사들이 있다. LG에서 만든 채널아이와 SK에서 만든 넷츠고 라는 회사였는데, 이 회사들은 웹 기반이라고 하지만, 내부는 PC 애플리케이션에서만 볼수 있는 "데이타 그리드"를 사용하여 사용자로 하여금 쉽게 사용할 수 있도록 만들어 주었다.
아마도 그때 이들 프로그램을 사용했던 사용자들은 쉽게 기억할 수 있을 것이다. 

최근의 웹 브라우져 시장에서의 경쟁은 Firefox로 부터 비롯되었다고 해도 과언이 아니다. Firefox는 첫 번째 버전부터, 사람들에게 많은 관심을 끌기 시작하였는데, 이는 몇가지 눈에 띄는 개선 사항들 때문이다.
기존 넷스케이프코드의 속도는 항상 관심사하이었지만 관심 밖이었다. 너무 브라우징 속도가 늦다는 것을 알고는 있었지만, 변경한다는 것이 쉽운 일이 아니었다. 이를 가감히 버리고 새로 브라우징 엔진을 제작한 것이 Firefox였고, 이 결정은 성공적인 결과물들을 만들어 내고 있다. 그리고, Addon 애플리케이션의 지원이 또한 이전과 차별화된 개선 사항이다. 오픈소스 개발자들이 만들어진, 질 좋은 Application들을 쉽게 찾고 사용할 수 있도록, Echo System을 갖추어 놓았다는 것이 사용자와 개발자들을 머무르고 지속적으로 사용하도록 만든다. 

Apple의 사파리 브라우져 역시 빠른 브라우징 속도와 사용자 경험을 무기로 내세워서 조금씩 사용자들에게 알려지기 시작하고 쓰이고 있는 중이다. 최근에 속도를 내면서 버전업을 하고 있는 구글 크롬 브라우져 역시 애플과 비슷한 전략을 취하고 있지요.

중요한 점은 이들 새로운 브라우져들이 특징으로 HTML5를 지원하려 한다는 것이다. 따라서 앞으로 새로운 웹 표준을 지원하기 원한다면, HTML5의 지원이 선행되어져야 하는데, 이를 사용한다는 것은 호환성을 보장 받지 못한다는 의미가 될수도 있다. 앞서도 이야기 되었지만, 기존에 지원되던 기능들이 여러 이유들로 인해서 삭제되고, 사용할 수 없는 것들이 있기 때문이다. 반대로 생각하면, 좀더 쉽게 개발할 수 있는 기능들도 같이 새로 들어 가기 때문에 좀도 쉽게 개발할 수 있다는 의미로 받아 들일 수도 있다.
아래 링크를 보면, HTML5의 신규 기능들을 볼 수 있다.
속도와 새로운 기능들로 무장한 새로운 브라우져들이 우리 앞에 나타났고, 현재 유럽에서는 IE의 시장 점유율이 40%대로 떨어졌다고 한다. 여기에는 많은 브라우져들의 노력이 있지만, IE에 대한 MS의 지속적인 지원들이 없었던 것에도 기인한다고 할 수 있다. 마치 우리가 잘아는 토끼와 거북이의 우화 처럼 말이다.

아래의 이미지는 온전한 HTML5를 지원하는 브라우져를 만날 시점들을 브라우져의 버전별로 정리한 표이다. (참조: http://www.hagenburger.net/2009/05/4-useful-html5-browser-support-overviews

 
위 내용으로 보면 IE는 9.(2010년경)에서나 겨우 만나 볼 수가 있을 것이다. (붉은 색으로 표시된 것은 준비가 안된 상태임).

최근 브라우져 시장은 여러 브라우져들을 출중한 기능들로 인해서, 굉장히 복잡하고 어떤식으로 진행될지 예측하기가 어렵다. 하지만, 이로 인해서 덕을 보는 사람들은 사용자와 개발자(?)들인데, 이전까지 경험하지 못한 새로운 것들을 쉽게 접할수 있고, 이로 인한 즐거움은 역시 즐기고자 하는 사람들이다.

브라우져 개발사는 개발사대로 열심 있어야 하지만, 개발자들은 개발자 나름대로 준비를 해야 한다. 새로 변경되고 바뀌는 것에 대해서 제대로 알고 있어야, 원하는 서비스를 잘 만들수 있기 때문이다.

MS의 최근 고민은 ActiveX를 죽이는 것에만 있는 것이 아니다. MS는 IE6 버전을 죽이기(?)위에서 애를 쓰고 있다, 최근 10년간 표준 처럼 사용되었던 IE는 근 1~2년 사이에서 3개의 새로운 버전을 개발해서 시장에 내보내고 있다. 결국은 유지보수와 호환성 그리고 보안성의 이슈가 나오기 마련인데, IE6를 현재까지 사용하는 사람들이 아직도 많기 때문이다. (관련 기사: http://www.etnews.co.kr/news/detail.html?portal=001_00001&id=200909100186)

새로운 기능을 탐재한 브라우져들이 계속해서 나오고 있다. 개발자의 관점에서 보면, 이들 브라우져들 모두를 지원하기 위해서 좀더 많은 노력과 시간이 들어간다고 투덜거릴수도 있지만, 결과적으로는 좋은 방향으로 흘러갈 것이다. 그렇게 때문에 새로운 게임의 법칙이 만들어 지거나, 온전한 표준화가 진행되어져야만 브라우져를 만드는 개발사들과 이를 통해서 서비스를 제공해야 하는 개발자와 이를 즐기는 고객들이 행복해 질수 있을 것이다.
Posted by 행복상자

이번 주는 여는 때와 달리 인터넷을 통해서, 몇가지 이슈들을 일으킬 만한 것들이 소개되었다. 특히 Google에서 몇가지 눈여겨 볼만한 것들을 내 놓았는데, 여기도 우리과 같이 한해를 마무리 하기 전에 프로젝트들을 정리하나 보다. (지금 내가 진행하는 프로젝트도 1.0 버전을 다음주까지 마무리 할 계획이다. 많은 우여곡절 끝에 여기까지 왔다. 그러나 높은 점수를 줄 수 없다. 개인저으로 많은 부분이 만족 스럽지 않기 때문이다.)

구글이 이번주에 발표한 내용중에, 특이 사항으로는 "Native Client"라는 것을 발표 하였는데,웹 브라우져를 통해서, OS가 가지고 있는 리소스를 최대한 사용할 수 있도록 도와줄 수 있고, 브라우져 상에서 애플리케이션을 빠르게 실행시키고, 이는 마치 데스크탑 Application 처럼 사용할 수 있다고 한다.

이미 Google의 도구들을 아는 사람은 유사한 것으로 Google Gears를 생각할 것이고 Googl 크롬을 떠 올릴 것이다. 그리고, RIA 관련 기술로는 MS의 Silverlight와 Adobe의 Flash 그리고 또 아직까지는 많은 사람들의 관심을 끌지는 못하고 있는 Sun의 Java FX가 있다.

이들의 유사점은 모두 Web 브라우져를 지원하지만, 웹 브라우져를 벋어 나려고 한다는 것이다. 내가 이전에 작성했던 글들에도 여러차레 언급 하였지만, 현재의 PC시장 보다는 Mobile 시장이 훨씬 크고, 앞으로의 성장가능성도 휠씬 높다.

위에서 언급하였던, RIA 관련 솔루션을 제공하는 MS, Adobe, Sun과 Google의 "Native Client"는 기술적인 관점에서 유사성이 많다. 왜냐하면, MS의 IE 브라워져의 관점에서 보면 Active X 기술을 사용할 수 밖에 없기 때문이다. 좀더 쉽게 설명하면 IE와 같은 웹 브라우져에서 동작할 수 있는 Application Container를 개발자와 개발업체에 제공하고, 이들이 만든 Software를 이 Application Container에서 동작시키는 것이다. 웹 브라우져에 Software를 구동시킬 수 있는 Layer를 두는 것인데, 이는 Adobe의 Flash Player를 생각하면 쉽게 이해가 될 것이다. RIA Application을 개발하고 이를 Adobe의 Flash Player(Application Container)를 통해 동작시키는 것이다. 이는 기술적으로는 다른지 모르겠지만, Layered Design 관점에서 보면, MS의 실버라이트, Adobe의 Flash, 그리고 Sun의 Java FX가 동일하다. 이렇게 한다면, 브러우져의 종속성을 크게 줄일 수 있는데, 만약 웹 브라우져의 스펙에 이러한 부분들이 반영되어 있고 표준화 되어 있다면, 이들 회사가 이러한 Container를 제공할 필요도 없었을 것이다. 

"Native Client"에 대해서 눈여겨 보아야 하는 이유는 어제는 Google의 크롬 브라우져가 정시으로 Release되었다. Google Gears도 그렇지만, 인터넷 또는 netwrok이 되지 않는 환경에서도 Application을 실행하고 사용자가 원하는 작업을 할 수 있도록, Google은 관련 기술들을 만들어 내고 있다. 이러한 연장 선상에서 기술의 흐름을 이해하는 것이 중요하다.

"Native Client"는 지난 3일 전에 발표되었지만, 아직 자세히 살펴 보지는 못하였다. 이번 주말에 짬짬히 살펴볼 예정인데, 아래 몇가지 링크와 동영상이 있다. 이해 하는데 도움이 될 거라 생각한다.

 
 1. ZdNet에 소개된 기사 
  
 2. Google Native Client
 
 3. Google's Reserch Paper
   





 

Posted by 행복상자

최근에 구글 크롬을 설치를 하였다. 집에서와는 달리, 회사에서는 몇가지 이유로 설치가 제대로 되지 않아서, 설치와 제거를 수 차례 반복하였다. 결국 설치 후 방치해 놓고 사용하지 않다가, 최근에 해결 방법을 찾아서 사용하고 있다.

내가 사용하고 있는 브라우져는, 맥북에서 사파리 3과 Firefox 3, 그리고 윈도우즈에서는 IE6와 7을 같이 사용하고 있다. 대부분 나는 IE를 사용하고 있는데, 이는 금융거래와 인증서 때문이고, 회사의 인트라넷 역시 IE에서만 동작하기 때문이다.

내가 Google의 크롬에 관심을 가졌던 이유는 내가 IE를 사용하는 이유와 동일하다. 최근에 Crom을 발표할 때 한국의 사용자들의 위하여 CROM에서 ActiveX 지원할 거라는 발언을 들었기 때문이다.
크롬에서 지원하는 AcitveX-Plugin은 다음 링크에서 찾아 볼수 있다. (구글 크롬 ActiveX Plugin) 이미 진행되어지고 있는 프로젝트 중에 하나이다.

ActiveX를 사용하는 것은 한국에서만 진행하고 있는 특이한 상황으로 볼수 있지만, 최근의
MS에서는 새로 개발하고 있는 IE 8에서는 웹 표준을 지원하겠다고 공언하고, ActiveX의 지원을 없애거나, 최소한으로 줄이려는 움직임을 보이고 있다.

이는 MS의 지금까지의 ActiveX를 바라보는 관점이 상당히 달라졌다는 반증이다.
아는 사람들은 알겠지만 ActiveX라는 기술의 탄생은 계획보다는 우연에 가깝다. 약 10년전에 자바 진영에서 Java Applet를 가지고 나와 웹을 동적으로 만드는 기술을 내 놓았을때 MS는 자신들이 가지고 있는 기술중에 가장 이와 유사한 기술을 가지고 내 놓은 것이었다. (사실은 OLE 또는 COM 기술이었다.) 이는 MS의 OS인 윈도우의 리소스를 쉽게 사용할 수 있었끼 때문에 개발 생산성과 효율성은 아주 높았다. 사실 웹 브라우져는 단지 COM 기술의 Container 역할만 할 뿐이었다.

이때 까지마 해도, 자바는 속도가 아주 느리고, 낮은 사양에서는 사용하기 어려운 기술이었기 때문에 개발자들이 선듯 내세우기 힘들었다. 반면 MS는 많은 Intranet환경에서 ActiveX를 이용한 솔루션이 개발되고, 만들어지면서 IE의 사용율을 높여갈 수가 있었다.

MS가 새로운 브라우져에서는 표준을 지향한다고, 이야기 하고 Vista를 비롯하여 IE8에서는 ActiveX의 지원을 하지않겠다고 공공연하게 이야기 하고 있다. 우리나라와 같이 AciveX를 많이 사용하는 나라에서는 갑작으로 방향 전환에 도무지 이해가 안하는 상항인데, MS의 입장을 알면 이해가 되는 부분이다.

최근 몇년 사이에 이러한 것(ActiveX)들을 대체할 수 있는 기술들이 나타나기 시작했는데, 이들은 어느새 웹 개발자들 사이에 표준처럼 사용되고 있기 때문이다.  Ajax와 Flash가 이들을 대표한다고 할 수 있다. 그리고 새로운 브라우져들이 MS의 시장 점유율을 눈에 띄게 줄이기 시작했다. (Firefox, Safari...)
Adobe의 Flash의 경우는 모바일과 윈도우 Application 영역마져도 침범하고 있다. Flash의 경우는 MS의 ActiveX와 마찮가지로 IE를 단지 컨테이너로 밖에 생학하지 않는 독립적을 Architecture를 가지고 있기 때문이다.

그리고, 이제는 웹과 Application의 경계마져도 허물어지고 데스크탑과 모바일의 경계마져도 허물어지고 있는 시점에 다달았고, 이에 부응하여 새로운 패러다임의 전환과 새로운 수익원을 찾아야 하는 때가 되었기 때문이다.

그러면 왜 AciveX를 버리려고 할까?
MS는 윈도우즈를 살리기 위해서 MS-DOS 버려야만 했다. 사람들이 새로운 제품으로 이동하지 않는다면, 윈도우즈가 살아남을 수가 없기 때문이다.
이와 유사하게 Silverlight가 살기 위해서는 ActiveX를 버려야만한다. 지금의 ActiveX는 오르지 윈도우와  IE에서만 작동을 하고 있기 때문에 새로운 패러다임에는 맞지 않는다.

제품의 라이프 사이클이라는 측면에서는 새로운 기술이 적용된 제품이 나오면, 자연스럽게 기존 제품이 사라져야 하지만, ActiveX의 경우는 결코 쉽지 않다. MS의 입장에서는 기존과 마찮가지로 그대로 유지하기에는 사용되는 비용도 결코 만만치 않기 때문에, 결국은 ActiveX를 죽일수 밖에 없다.

며칠 전에 Silverlight 2의 발표가 임박했다는 기사를 보았었다.
개인적으로는 Silverlight는 MS에서 방향을 잘 잡았다고 생각을 하고, 이전 보다 Open된 Platform의 모습을 갖춰가나고 있다고 생각한다. Ruby와 Python과 같은 Dynamic language를 지원하는 것을 봐도 .Net Framework 1.0을 발표 할 때와 사뭇 다른 태도를 보이고 있다는 것을 알 수가 있다. (그때는 수많은 VB 개발자들과 지지자들을 너무나도 쉽게 버렸었다.)

그리고, 기대를 하고 있다. 개발 생산성을 바라지는 않지만,  앞으로도 많은 기능 개선과 개발자 지원으로 인터넷 비쥬얼 베이직으로 자리잡을 수 있기를 바란다. Silverlight 2의 새로운 컴포넌트를 보면, 마치 Visual basic의 툴 컨트롤이 연상이 되기 때문이다.
(Visual Basic은 내가 좋아하는 개발 툴이어서 애착이 많이 간다.)



'공부하는 것' 카테고리의 다른 글

Spring 3.0 Preview  (0) 2008.10.21
Silverlight 2 Released  (0) 2008.10.15
Silverlight 2.0 발표 즈음하여...  (0) 2008.10.15
MS SQL 2005서버에서 유니코드 사용하기  (0) 2008.10.08
Cocoa Programming을 시작하며...  (0) 2008.10.07
Spring Dynamic Modules 1.1.2 Released  (0) 2008.10.05
Posted by 행복상자