클라우드가 서비스가 정지되면?

모 바일 분야에서 최근 각광받는 모바일 웹과 모바일 클라우드 그리고  소프트웨어를 패키지가 아닌 서비스 형태로 제공하는 SaaS(Software As A Service ) , 클라우드 컴퓨팅  등 이러한 새로운 개념의 서비스들은 모두 웹 상에서 무정지로 운영되는 서비스를 기반으로 하여 작동된다. 만약 이러한 클라우드 서비스가 정지되면 많은 문제가 발생할 것이다. 

최 근 이러한 기술적 흐름을 주도하고 있는 업체들에서 클라우드의 장애가 발생하여 많은 우려를 낳고 있다. 클라우드 서비스에 관한 한 가장 우수한 기술과 엔지니어를 보유한 회사인 구글도 서비스를 운영하면서 많은 장애가 발생하고 있다. 실제 최근 들어 9월 24일 부터 9월 26일간 구글 e-mail 서비스에 부분적인 장애가 발생하였다(Google Apps Status Dashboard를 통해 관련 장애 내용을 확인할 수 있다).  구글 뿐만 아니라 페이스북은 15만명 가량의 고객 데이타를 날려버렸다. 그 결과 많은 사용자들이 계정에 로그인할 수 없었으며 일부 프로파일을 잃어버렸다.


최근에 발생한 가장 큰 클라우드 장애는 T모바일에서 제공하는 MS모바일기기인 사이드킥에 서 발생했다. 2002년 출시된 사이드킥은 MS가 지난해 인수한 데인저사가 디바이스 생산과 서버 관리를 맡고 있다.  사이드킥 서비스의 핵심은 사용자의 주소록과 일정표,사진 등 각종 데이터를 단말기 자체 대신 인터넷에 연결된 서버에 저장해 기기가 바뀌어도 언제든 데이터를 볼 수 있도록 해주는 것이다. 당연히 네트웍이 항상 연결되어 있거 서버만 건강하다면 최적의 상태에서 서비스를 이용할 수 있을 것이다. 그러나 이번처럼 서비스에 장애가 발생하여 사용자들이 서버 클라우드 상에 존재하는 자신의 데이타를 이용하지 못한 다면 아무런 쓸모가 없다.


현재 이 문제의 원인은 공식적으로 알려지지 않았지만 떠도는 루머중 가장 신뢰할 만한 루머는 사이드킷의 SAN 스토리지를 업그레이드하던 중 해당 업체인 히타치가 이전 데이타의 백업을 받지 않았다는 것 이다. 상황이 이렇다면 이전 백업본 까지의 데이타를 복구를 하겠지만 유실되는 데이타가 상당히 존재하는 것은 분명하다. 현재 사이드킥 고객들은 소송을 시작했고 개인적으로는 당연히 승소할 것으로 본다.

위의 상황을 보면 클라우드 서비스의 미래가 밝지만은 아닌 것 같다. 과연 그럴까? 최근 IDC는 "클라우드 서비스 전망" 이란 보고서에서 2013년  전체 IT관련 지출의 10%인 442억달러(약43조원)의 비용을 클라우드서비스에 지출할 것이라고 전망했다. 실제 현재 세계 경기가 불경기 임을 고려할 때 클라우드 서비스의 초고속 성장을 예측한 셈이다.

                             [출처] IDC’s New IT Cloud Services Forecast: 2009-2013

아 마도 위의 사실을 종합해 보면 다소 어리둥절 할 수 있다. 유명 IT 기업 조차도 안정성을 보장하지 못하고 있는 서비스를 유명한 시장 조사 기관에서는 초고속 성장을 할 것이라고 예측한다는 사실이 그것이다. 과연 진실은 무엇일까? 위의 상황을 고려해 보면서 몇가지 중요한 사실을 고민해 보자. - 어떤 시스템이든 장애가 없을 수는 없다.


모 든 시스템을 설계,개발할 때는 무장애를 목표로 하지만 장애없는 시스템은 있을 수 없다. 실제 사내에서 사용하는 메일 시스템도 사소한 문제로 인해 장애가 생기거나 천재지변에 의해 장애가 발생할 수 있다. 그러나 이 때 중요한 것은 이 장애를 얼마나 신속하게 대처하고 복구하느냐 이다. 이러한 것을 해당 서비스의 QoS(Quality of Service)라 할 수 있다. 장애가 발생하더라고 고객과 약속된 수준의 서비스를 유지할 수 있도록 운영해야 하는 것이다. 구글 , 세일즈포스 , 아마존은 고객에게 해당 서비스의 상태를 직접 조회할 수 있는 대쉬보드를 제공한다. 이러한 수준의 서비스 품질 관리와 장애 조취를 제공할 수 없다면 클라우드 서비스라 할 수 없다. 앞서 T모바일의 사이드킥 서비스의 경우  정상적으로 일일 단위의 백업과 데이타 이중화가 구성되어 있었다면 신속히 해결할 수 있는 일반 장애중 하나 였을 것이다.

- 안정적인 운영과 장애 대처 능력을 갖추어야 한다.

클 라우드 서비스를 상용화 제품으로 구축할 경우 많은 투자가 수반될 수 밖에 없다. 따라서 많은 클라우드 서비스들은 오픈소스 등을 활용하여 클라우드를 구축한다. DBMS, WAS , Web Server를 비롯하여 Cache Server , 로드밸런서, 성능 관리, 형상 관리  등 클라우드를 구축하는 데 필요한 많은 솔루션과 기술을 오픈소스를 통해 조달받는다. 이러한 오픈소스 기술을 채택할 경우 다양한 운영 테스트를 통해 운영 노하우와 유지보수 및 장애 조치를 신속하게 할 수 있는 기술 및 프로세스와 기술자를 확보해야 만 한다. 오픈소스 외에 상용 제품을 사용할 경우에도 마찬가지이다. 비록 해당 제품의 기술 지원과 유지보수는 해당 업체를 통해 제공받을 수 있지만 그 외에 운영 노하우와 장애 조치를 위한 프로세스 및 조직, 그리고 숙련된 개발자는 미리 확보를 해야 한다. 따라서 어떠한 클라우즈 서비스이건 안정적인 운영을 위한 조직과 프로세스, 그리고 숙련된 개발자를 확보하고 엄격한 프로세스에 의해서 서비스를 운영해야 한다.

- 오프라인일 경우를 대비해야 한다.

클라우드를 기반으로 하는 서비스는 온라인상에 연결되어 있다는 것을 전제로 한다. 그러나 항상 온라인상에 연결되어 있을 수 는 없다. 만일 온라인 상에서 중요한 업무를 클라우드 기반으로 수행하다 갑자기 네트웍이 중단되었다고 하자. 지금껏 열심히 작성한 메일이나 문서는 모두 소용없게 된다. 따라서 클라우드 기반의 서비스는 오프라인일 경우를 대비해야 한다.

현재 클라우즈 기반의 서비스 개발시 가장 많이 사용하는 방법은 구글 기어를 이용하여 브라우져상에서 오프라인시 직접 데스크탑상의 스토리지에 해당 정보를 적는 것이다. 웹 오피스 업체인 조호를 비롯하여 많은 서비스들 역시 이 기능을 이용하여  오프라인시 해당 서비스를 사용하게 해준다. 다행스럽게도 이러한 오프라인시 대처할 수 있는 이 기능이 W3C에서 추진하고 있는 HTML5에 포함되어 제공될 예정이다. 클라우드 기반의 서비스들은 이러한 오프라인 지원 기능을 이용하여 클라우드에 연결되지 못하더라도 작업을 계속 수행할 수 있어야 하며 데이타를 정합성을 유지해야 만 한다. 실제, 구글 Docs와 구글 메일은 구글 기어를 사용해서 클라우드에 연결되어 있지 않더라도 오프라인 상에서도 작업 내용을 수행할 수 있게 해준다. 이러한 기능은 클라우드 기반 서비스의 기본 기능이 돼야 한다. 이는 모바일 클라우드에도 마찬가지이다. 만일 MS의 사이드킥 서비스가 디바이스상에서 클라우드에 있는 데이타와 동기화( 실제 백업 )되고 클라우드에 연결되지 않더라도 최소한의 기본 기능 만이라도 작동되도록 설계되었다면 위와 같은 문제는 없었을 것이다.

곰곰히 생각해 보면 클라우드가 아니더라도 우리는 기존의 인트라넷 환경이나  데스크탑 환경에서도 항상 장애를 경험했다. 내부에서 사용하는 인트라넷 메일 서버가 이유없이 중단되거나 윈도우 데스크탑 환경하에서 문서를 작성하던 중 알 수 없는 이유로 인해 해당 문서를 유실하기도 했으며  알지도 못하는 사이 설치된 ActiveX 프로그램로 인해 브라우져가 수도 없이 다운되는 경험도 가지고 있다.

클라우드 컴퓨팅에서 장애란 아주 치명적인 것이지만 다양한 이유로 인해 언제든 발생할 수 있다. 물론 장애를 사전에 발생하지 않게 하는 것이 첫번째 운영 능력이지만 , 장애 발생시 어떻게 대응하여 피해를 최소화하여 신속하게 복구할 것인가가 중요하다.  이것이 바로 클라우드 서비스 업체의 능력이고 기술이라 할 수 있을 것이다.

앞서 구글의 경우 장애 발생시 이를 사용자와 대쉬 보드를 통해 공유하며 조취를 취했고 데이타 유실 등의 문제는 없었다. 그러나 페이스북과 데인저사가 관리하는 사이드킥 서비스는 데이타를 유실하면서 실제 고객에게 피해를 주고 말았다. 결국 , 이러한 차이가 클라우드 업체들의 서비스 품질과 기술 차이일 것이다. 현재 MS는 사이드킥 문제로 인해 직접적으로는 고객들에게 고소를 당했으며 간접적으로 애저(Asure) 클라우드 플랫폼과 사이드킥의 차기 버전으로 알려진 핑크 폰의 출시에 많은 영향이 있을 것으로 보인다. 이처럼 클라우드 서비스에서 장애와 이에 대한 대응은 서비스의 신뢰도에 직결하는 생존의 문제이다.

정리를 해보자. 클라우드 서비스의 장애는 언제 어디서나 다양한 이유로 발생할 수 있다. 중요한 것은 이러한 것을 사전에 예방하고 , 발생시 최대한 신속하게 복구하는 프로세스와 능력이다. 이러한 것이 보장되지 못한다면 결코 클라우드 서비스 시장에서 생존하지 못할 것이다. 따라서 클라우드 서비스 개발 업체는 초기 설계 및 개발에서 부터 철저하게 장애와 복구를 고민해서 시스템을 설계하고 개발해야 한다. 또한 개발보다 더욱 중요한 것이 운영이라는 사실을 명심해야 한다. 마지막으로 사용자는 이러한 클라우드 서비스 선택시 운영 능력과 장애 조치에 대한 사항을 SLA(Service Level Agreement)를 읽고 판단해야 한다. 일반적으로 유료화된 클라우드 서비스는 SLA에 운영 및 장애 조취에 대한 보증 내용을 명시하고 있으며 이를 지키지 못할 때의 보상 문제 또한 명시되어 있다. 만약 이러한 SLA가 없다면 해당 클라우드 서비스를 사용할 지 신중히 고민해 봐야 할 것이다.

Posted by 박재현

댓글을 달아 주세요


 지금은 모바일 웹을 준비해야 할 시기


모바일 시장에서 두각을 나타날 만한 아이디어를 갖고 있는 개발자가 성공적으로 투자를 받아 회사를 창업했다고 하자. 멋지게 해당 서비스를 기획하고 실제 개발을 해야 하는 상황에 직면했다. 아마도 이러한 문제에 직면할 것이다. 도대체 어떤 플랫폼용으로 만들 것인가? 라는 문제이다. 앱스토아라는 애플리케이션 마켓플레이스가 가장 활성화되어 있는 애플용이 좋을 까? 아니면 전 세계에서 가장 많은 핸드폰을 판매하고 있는 노키아나 삼성의 핸드폰을 대상으로 할 것인가?
아마도 여러 복합적인 의사 결정에 따라 애플 아이폰 SDK나 심비안 SDK 또는 윈도우 모바일 SDK 중의 하나를 이용하여 어플리케이션을 개발하게 될 것이다. 이러한 현재의 모바일 어플리케이션 개발 환경은 개발자와 개발회사에 너무도 많은 부담을 지우고 있다.  
 
먼저 가장 근본적인 고민은 모바일 플랫폼이 너무 많다는 것이다. 
현재 공개된 대표적인 모바일 플랫폼만 하더라도 애플 아이폰 SDK, MS의 윈도 모바일 SDK , 구글 안드로이드SDK , 심비안 SDK , 팜의 Mojo SDK 등 다수이다. 이들 SDK중 하나를 선택하는 것도 쉬운 일은 아니다. 설령 , 여러가지 상황을 고려해서 플랫폼을 선택했다고 하더라고 해당 플랫폼에 최적화된 어플리케이션을 개발하기 위해서는 해당 플랫폼에 정통한 모바일 어플리케이션 개발자가 필요하다. 일반적으로 웹이나 PC 플랫폼상에서 어플케이션을 개발하는 것보다 모바일 플랫폼에서 개발할 때  디바이스 자체의 특성을 잘 이해해야 좋은 성능과 품질의 어플리케이션을 개발할 수 있다.

일단 여러 우여곡절 끝에 하나의 모바일 어플리케이션을 개발했다고 치자. 시장 확대를 위해서는 다른 플랫폼용으로 해당 모바일 어플리케이션을 포팅해야 한다. 말이 포팅이지 거의 새롭게 개발하는 수준이다. 이를 위해서는 숙련된 개발자를 확보해야 하는 등 많은 비용이 든다. 개발 후에는 유지보수를 위해 또 비용이 발생한다. 참으로 비극적인 상황이 아닐 수 없다. 실제 더 우울한 것은 동일한 모바일 플랫폼이라고 하더라도 버전에 따라 호환이 안되는 경우도 다수 발생하기 때문에 많은 버전을 개발하고 관리해야 만 한다.

이러한 상황을 해결하고 보다 손쉽게 모든 모바일 플랫폼상에서 구동되는 모바일 어플리케이션을 개발할 수 없을까?

물론 몇가지 방법을 상상할 수 있을 것이다. 먼저 모바일 플랫폼을 하나로 통합하고 이 기반하에 개발하는 것이다. 마치 PC 플랫폼이 윈도우로 통일되었듯이 모바일 플랫폼들을 하나의 특정 플랫폼으로 통합하는 것이다. 그러나 이 방법은 불가능하다. 사용자도 플랫폼 통합에 관심이 없겠지만 업체들 입장에서도 이해관계가 다양하기 때문에 통합은 불가능하다. 

또 하나 생각해 볼 수 있는 방법으로는 모든 모바일 플랫폼상에서 구동되는 통합된 API를 이용하는 것이다. 마치 노키아가 심비안 상에 S60 플랫폼을 통해 개발하듯이 모든 모바일 플랫폼상에 운용되는 어플리케이션을 개발할 수 있는 SDK를 개발한 후 이용하는 것이다. 그러나 이 방법도 하부에 있는 모바일 플랫폼에 의존적이기 때문에 완벽한 이식성을 제공하기 어려울 뿐만 아니라 이러한 공통 API를 설계 개발하는 것은 무척 어렵다. 왜냐하면 모바일 플랫폼은 디바이스 의존적인 부분이 강하기 때문이다. 현재 차이나모바일, 소프트뱅크, 보다폰 세개의 이동통신사업자가 만든  컨소시엄인 JIL(Joint Innovation Lab)은 이러한 접근 방법을 사용한다. JIL(www.jil.org)JIL JavaScript Extension을 이용하여 모바일 디바이스를 제어하는 위젯을 개발하고 이를 구동하는 런타임 환경을 제공한다.  이 위젯은 모바일 플랫폼과는 무관하게 구동된다. 그러나 JIL은 모바일 어플리케이션을 위한 것이 아니라 위젯 개발을 위한 개발 환경이다.


또 하나의 방법은 개발과 포팅 환경을 통합하여 하나의 통합된 개발 환경에서 개발을 하고 이를 바탕으로 원하는 플랫폼으로 보다 손쉽게 포팅을 하게 해주는 것이다. 무척 현실적인 방법이나 모바일 플랫폼간의 포팅은 쉽지 않아보인다. 실제 이클립스 펄서(Pulsar)는 이러한 접근 방법을 사용한다. 이클립스 펄서는 이클립스 툴 기반의 모바일 어플리케이션 개발 환경으로 모바일 업체들이 자체 SDK를 펄서 명세에 맞춰 공급하면 플러그인 방식으로 다운로드하여 사용할 수 있다. 현재 모토로라에서 제공하는 자바 ME SDK과 노키아 포럼의 S60 SDK, 그리고 모바일용 eRCP(embeded Rich Client Platform)를 제공하고 있다. 현재 수준은 모바일 플랫폼 업체들의 SDK를 이클립스 기반으로 통합하여 단일 환경에서 개발할 수 있게 해주는 수준이다.
 
지금까지 고민해 본 방법은 마치 데스크탑상의 윈도우 플랫폼에서 구동되는 윈도우 프로그램을 개발하는 것처럼 모바일 디바이스 상에서 구동되는 모바일 어플리케이션을 개발하는 것이다. 그러나 생각을 좀 바꿔 보면 특정 모바일 플랫폼 종속에서 벗어나는 모바일 어플리케이션을 개발할 수 있다. 바로 웹 기반의 모바일 어플리케이션을 개발하는 것이다.

모바일 웹 어플리케이션은 모바일 다바이스상 설치되어 운영되는 모바일 어플리케이션이 아니라 네트웍을 통해 언제 어디서나 접속하여 다운로드를 받은 후 웹 브라우져를 통해 사용할 수 있다. 이러한 방법을 모바일 클라우드 기반의 어플리케이션이라고도 한다.

이러한 클라우드 기반의 모바일 웹 어플리케이션 개발에 있어 해결해야 할 문제로 모바일 어플리케이션의 킬러 분야인 게임 분야에서 우수한 프로그램의 개발이 가능한가? ,  네트웍이 불가능한 상황에서 웹 어플리케이션을 어떻게 구동할 것인가?, 그리고 웹 프로그래밍을 통해 디바이스의 제어가 가능한가? 등이 있다.

먼저 결론을 말하자면 이러한 문제들은 일부는 해결되었고 일부는 해결되어 가고 있으며 모바일 웹이 모바일 플랫폼의 주류중 하나가 될 것이다. 먼저 이러한 흐름의 중심에는 W3C의 HTML5 표준이 있다. 기술적인 내용을 살펴보는 것에 앞서 표준은 산업체간의 이해관계가 걸린 전쟁이라는 것을 이해해야 한다. 단순히 업체간의 협의에 의해 결정되는 것이 아니라 철저한 이해관계에 의해 움직인다. 현재 HTML5 표준을 강력하게 추진하고 있는 업체는 구글과 애플, 그리고 팜 , 오페라 등을 들 수 있다. MS의 반대 진형이 강력히 추진하고 있는 상황이라고 할 수 있다. 물론 실세는 구글이며 W3C 표준에 자신들의 기술을 반영하여 웹 표준을 리드하고 있다.

Gears이러한 HTML5에는 앞서 언급한 모바일 웹 어플리케이션을 개발할 때 발생하는 문제점들의 해결 방안을 상당수 포함하고 있다. 대표적인 것이 게임 처럼 복잡한 그래픽 처리를 가능하게 하는 Canvas 태그와 네트웍이 불가능한 상황에서도 디바이스상의 스토리지를 이용할 수 있여 응용 프로그램을 구동하고 이를 온라인시 동기화 시키는 것을 가능하게 하는 기능 등이 포함되어 있다. 이 스펙은 구글의 오픈소스 프로젝트인 구글 Gears를 HTML5에 포함시킨 것이다. 또한 최근에 W3C는 Device API Working Group을 발족하여 웹이나 가젯 등의 어플리케이션에서  다바이스를 제어하는 표준API를 제정에 착수하였다.

W3C의 Device API외에 자바스크립트로 모바일 디바이스를 제어할 수 있도록 해주는 표준으로 BONDI(http://bondi.omtp.org)가 있다. BONDI는 이동통신 사업자들의 포럼인 OMTP(Open Mobile Terminal Platform)에서 제정한 런타임 플랫폼으로 웹 어플리케이션이나 위젯 등에서 모바일 디바이스의 기능을 안전하게 제어하게 해주는 모바일 웹 플랫폼이다.

BONDI는 HTML, JavaScript, CSS 등 표준 웹 개발 기술로 작성된 웹 어플리케이션에서 모바일 디바이스의 어플리케이션 , 카메라, 커뮤니케이션 로그, 이미지 갤러리, 위치 정보, 메시징, 스토리지, 개인정보 관리(PIMS) , 디바이스 정보 등을 제어할 수 있게 해주는 모 바일 웹 플랫폼이다. 이를 위해 BONDI는 모바일 디바이스를 제어할 수 있는 자바스크립트 EXtension를 제공한다. 현재 1.0 스펙까지 출시되었고 참조 구현체와 SDK를 배포하고 있다. 현재 BONDI API와 노키아 API가 W3C Device API에 제출되어 있는 상태이기 때문에 W3C Device API에 유사 표준이 포함될 것으로 예상된다.

이러한 HTML5, Device API,  BONDI 등의 이면에는 여러 업체들의 복잡한 이해관계가 존재한다. 물론 이러한 이해관계의 끝에는 모바일 웹 어플리케이션이 존재한다. 실제 표준을 진행하는 과정에서 자신의 기술과 스펙을 표준화시키는 것은 아주 중요하다. 바로 그것이 경쟁력이기 때문이다. 이를 위해서는 먼저 자신의 기술을 확보해야 하는 것이 필수이다.

현재 모바일 웹을 가장 적극 채용하고 있는 업체는 구글과 팜사이다. 구글은 올해 5월 구글 개발자 컨퍼런스인 Google I/O에서 HTML5를 기반 기술로 적극 추진한다고 공표했고 새롭게 개발하고 있는 Crome OS를 HTML5 기반으로 개발하고 있다. 또한 과거 PDA 황금기에 시장을 주도했었던 팜사는 Palm Pre라는 새로운 스마트폰을 출시하면서 웹 OS라는 혁신적인 개발 환경을 발표했다. 웹 OS는 Webkit과 dojo를 기반으로 한 Mojo라는 웹 SDK를 제공한다. Mojo는 CSS,HTML,Javascript만을 이용하여 모바일 어플리케이션을 개발할 수 있다.

또한 브라우져의 경우에도 파이어폭스3.5 , 오페라 9.6 , 사파리 4 등에서 동영상, 오디어 등 HTML5의 주요 기능을 제공하기 시작했으며 지원 기능은 시간이 흐를 수록 늘어날 것이다.

이러한 모바일 어플리케이션 개발 환경이 웹 중심으로 수렴되는 것은 모바일 어플리케이션 개발에 있어 기존 디바이스 의존적인 방법보다 높은 생산성을 주는 것과 더불어 긍정적인 많은 변화를 가져다 줄 것이기 때문이다. 어떤 변화들이 올 지 예상해보자.

- 중.저가형 스마트폰 시장이 보다 빠르게 형성될  수 있다.
기존 스마트폰 시장은 주로 고가 제품이 주를 이루고 있다. 모바일 어플리케이션을 구동하기 위해서는 고성능의 사양이 필요하기 때문이다. 그러나 모바일 웹 어플리케이션은 웹 브라우져가 구동되는 환경에서면 수행이 가능하기 때문에 중.저가 스마트폰 시장이 보다 빠르게 형성되고 주류가 될 수 있다.

- 모바일 웹 어플리케이션이 일반화가 되면 모바일 어플리케이션의 생태계도 변하게 된다.
애플 앱스토아를 비롯해 현재 모바일 마켓플레이스를 통해 제공되는 대부분의 모바일 어플리케이션은 디바이스에서 구동되는 순수 모바일 어플리케이션들이다. 마치 윈도우용 프로그램의 라이센스를 구매하여 사용하는 것과 동일한 방식으로 모바일 마켓플레이스에서 라이센스를 구매하고 이를 디바이스에 설치한 후 사용을 한다. 그러나 모바일 웹은 이러한 방식의 변경을 요구한다. 모바일 웹 어플리케이션은 인터넷을 통해 언제,어디서나 접속을 하여 사용할 수 있기 때문에 과금도 라이센스를 구매하는 방식이 아니라 사용한 만큼 비용을 지불하는 방식인 SaaS(Software As As Service) 모델로 전환될 것이다.
  
이에 따라 앱 스토아 같은 기존의 모바일 마켓플레이스도 많은 영향을 받을 것이며 후발 업체들의 경우 새로운 기회를 맞게 될 것이다.  이러한 측면에서 가장 개방되고 우수한 클라우드를 보유하고 있는 구글과 팜사의 웹OS가 가장 많은 기회를 얻을 수 있다.

- HTML5, CSS, 자바 스크립트로 개발된 모바일 웹 어플리케이션이 W3C의 Device API 등을 통해 직접 디바이스를 제어하게 된다면 아주 재미나고 놀라운 것들이 가능하다. 가령, 웹 서버와 Device API를 지원하는 냉장고용 제어 프로그램을 개발하면 사용자는 핸드폰의 브라우져를 통해 냉장고에 접속한 후 해당 프로그램을 사용할 수 도 있으며 특정 상품의 재고가 부족하면 자동으로 특정 웹 쇼핑몰에 주문을 내게 할 수도 있다.

HTML5 표준은 2012년 정도에 완성될 것으로 예상되고 있다. 그러나 일반적으로 표준에 앞서 관련 업체들의 모바일 웹 관련 기술은 더욱 빠르게 발전할 것이다. 과거 우리는 IBM의 호스트 환경에서 데스크탑 기반의 클라이언트/서버 환경으로, 그리고 다시 웹으로 변화를 할 때 마다 이를 미리 준비하지 못할 경우 막대한 비용을 지불해야 만 했다. 이처럼  모바일 개발자들과 디바이스 개발자들은 다가올 모바일 웹 환경을 위해 미리 준비를 해야 할 것이다.

이 글은 ZDNET에 기고한 글 입니다.

Posted by 박재현

댓글을 달아 주세요

  1. Favicon of https://emotionbank.tistory.com BlogIcon 감정은행 2009.09.01 13:30 신고  댓글주소  수정/삭제  댓글쓰기

    잘 읽었습니다. 모바일 플랫폼에 대한 고민은 정말 해결점이 없어보이네요...쩝..

  2. Favicon of http://eliot.tistory.com BlogIcon 상하이신 2009.09.02 18:16  댓글주소  수정/삭제  댓글쓰기

    좋은 글 잘 읽었습니다. 제목이 제 생각과 같아서 내용을 보니 더욱 공감이 가네요^^

  3. Favicon of http://hackperl.tistory.com BlogIcon 창민짱 2009.09.02 19:51 신고  댓글주소  수정/삭제  댓글쓰기

    훌륭한 통찰력이십니다.

  4. 하오마루 2010.11.10 15:08  댓글주소  수정/삭제  댓글쓰기

    모바일웹은 사용성이 떨어져서 단순한 화면을 가진 app에 국한 될 것으로 보입니다. html5에서 부지런히 사용성 개선을 위해서 노력중이나 html가지고 될까 하는 회의가 듭니다. 사실 모바일웹은 이전에도 있었으나 웹 스토어방식이 현저히 사용성이 좋아서 더 선호하는 것입니다. html에 canvas추가되었어도 간에 기별도 안갈것 같은데요..


사용자 삽입 이미지
오늘보니  FireFox3 RC1이 공개되었네요. 치열하게 펼쳐질 브라우져들의 경쟁이 기대됩니다. 그리고 이 포스팅을 마지막으로 XTech 2008의 정리를 마칩니다.

5. XSLT/XPath, SVG, ARIA


- Cient-side XSLT/Xpath
 
오페라는  XML 문서를 클라이언트측 스크립트로 처리하기 위해 document()를 제공하고 있다. 웹킷도 오페라에 동참 한 상태이고  IE도 같은 목적을 위해 node-set() 을 지원하고 있다.

현재 주요한 브라우져 엔진들내에는 XSLT/XPath를 포함하고 있다. - XSLTProcessor, DOMParser|loadXML , XMLSerializer.

- SVG

• 오페라에서는 강력하게 지원중이고 , 모질라는 양호하게 지원중이다.
• 웹킷의 경우 SVG 기능을 크게 향상시키고 있다. 최근에는  SMIL기반의 SVG 애니메이션까지도 지원하고 있다.
• IE7과 마찬가지로 IE8에서는 지원하지 않을 예정이다. 구글이 IE용 SVG를 만든다는 이야기가 있었는데 어떻게 되가는지..

자바 개발자들은 바틱(Batic) 라이브러리를 사용하면 SVG 를 손쉽게 다눌 수 있다. 더불어 다양한 포맷으로 출력 변환을 원할 경우 아파치 FOP (Formatting Objects Processor)를 사용하면 편리하다. 참고로 OLE 객체와 OOXML을 포함한 MS 오피스 문서를 손쉽게 처리하려면 아파치 포이 라이브러리를,  ODF 문서를 처리할 경우 ODFDOM 라이브러리를 활용하면 된다. 요즘은 정말 밑바닥 부터 개발하는 것은 어리석은 일인 것 같다. GPL/LGPL 등으로 배포되는 멋진 작품이 많기 때문이다.


6. 기타 다른 변화들


-HTML5 registerProtocolHandler()
mailto: 에 대한 처리를 특정 웹 메일 애플리케이션이 수행하게 할 경우  registerProtocolHandler()를 사용한다. Firefox 3에 구현되어 있다(2008-04).

-JavaScript Getters 와 Setters
• 데이타 필드의 암호화(encapsulation)를 가능하게 함
• Mozilla, Safari 3, Opera 9.5 betas 지원
• IE8 은 지원하지 않음

-HTML5 <video> 엘리먼트
• 비디오의 로딩과 플레이를 위한 스크립트 API
• 태그 예 : <videosrc="foo.ogg" id="foo_video">

- <video> 태그 지원 브라우져
• Safari 3.1 and WebKit nightlies
• Mozilla/Firefox trunk build + patch for bug 382267
• Opera experimental build
• IE8은 아직 지원 없음

- IE8 <meta> versioning switch
• <meta http-equiv="X-UA-Compatible" content="IE=7"/>
• IE8에서 사용할 렌더링 엔진을 지정할 수 있게 해주는 태그
• 특별히 명시하지 않으면  IE8을 기본으로 사용한다. IE8과 이전 버전의 차이가 크기 때문에  IE 렌더링 호환성을 위해서는 필요해 보인다.

- Acid2 와 IE8
• IE8은 Acid2 테스트를 통과함 
• Safari, Mozilla, Opera는 이미 오래전에 통과되었음^-^

- 브라우져에서 Acid3 지원 현황
• WebKit nightly: 100/100
• Opera dev build: 100/100
• Opera 9.5: 78/100
• Safari 3.1: 75/100
• Firefox 3/Minefield: 71/100
• IE8: 18/100

7. WebKit CSS의 멋진 기능들 , 아이폰에서 정말 멋집니니다^-^.
WebKit에서 제안한 CSS의 추가 기능들을 보면 HTML의 표준을 유지하면서 멋진 스타일과 효과를 제공할 수 있는 혁신적인 기능이 포함되어 있습니다.

Reflections: -webkit-box-reflect
• Alpha masks: -webkit-mask
Canvas images: -webkit-canvas
• Gradients: -webkit-gradient
• Transitions: -webkit-transition
• Transforms: -webkit-transform
   
Web on the Move, 플랫폼으로서의 웹이 모바일과 기존 데스크탑, 그리고 기타 플랫폼을 하나로 아우르는 플랫폼으로 자리잡아 가면서 웹 브라우져 또한 보다 다양한 기능과 패러다임으로 발전하고 있습니다. 웹 브라우져는 기존의 단순히 HTML을 렌더링하기 위한 응용 프로그램이 아니라 HTML5,ARIA,CSS, XML 기술 등 다양한 클라이언트 개발 기술을 사용하여 클라인트측의 웹을 개발할 수 있는 독립적이자 스마트한 플랫폼으로 진화하고 있는 것이 지금의 현실로 보입니다.  참! 할수 있는 게 너무 많아지는 뭘 해야 할 지 고민되는 세상입니다.^-^


Posted by 박재현

댓글을 달아 주세요