abulaphiaa

Keep Yourself Social

Archive for the ‘HTML5’ Category

HTML5 모바일 App.의 대해부

with 17 comments

최근 Financial Times가 Apple의 IAP(In-App-Purchase) 정책과 User Data에 대한 접근 제한 등을 이유로 App. Store에서 스스로 철수하고 대신 HTML5 기반의 Web App.으로 비즈니스의 중심 축을 변경했습니다. 비단 Financial Times뿐만 아니라 Playboy나 Boston Globe 등 대형 출판 기업들 또한 1) Apple의 경직된 정책으로부터 비즈니스의 독립성을 유지하고 2) Web을 기반으로 다양한 플랫폼을 지원하고 3) 웹을 통한 기능추가나 변경 등 업그레이드가 용이하기 때문에 HTML5 표준 기술을 활용한 Web App.으로 방향을 전환하고 있습니다.

  • An FT spokesman said the company was encouraging subscribers to migrate to the Web-based app, which uses the open HTML5 standard that can be read by any browser, and is already being used by most mobile subscribers (Reuters, 2011년 8월 31일).

이와같이 HTML5는 특정 Device에 대한 종속성에서 탈피하여 Cross-Platform을 지원하기 위한 기술적 대안으로 각광받고 있으며, 많은 사람들에게 HTML5 표준 기술을 사용하여 웹을 개발하면 어떤 플랫폼에서든지 유연하게 대처할 수 있는 “만병통치약”으로 인식되고 있으나 실제로는 어떨까요?

Mobile Web 개발 전문 기업인 pinch/zoom의 창업자인 Brian Fling는 이 질문에 대해 “HTML5로 일을 할 수 있다. 그러나 1) 서버 사이드에서 Device Detection을 할 수 있어야 하고 2) 퍼포먼스 증대와 Offline 모드를 지원하기 위해 App Cache와 싱크를 고려해야 하며 3) HTML5 페이지를 모아서 렌더링할 수 있고 Device별로 Native한 동작을 에뮬레이션할 수 있는 Javascript가 필요하고 4) Native App.과 같은 Look을 지원하기 위해 CSS를 적절히 활용해야 하는데, 이 모두를 Platform별로 최적화할 필요가 있기 때문에 비용과 시간이 훨씬 더 많이 소요된다”라고 결론을 맺고 있습니다.

개인적으로 개발자는 아니지만 HTML5에 관심은 많은 기획자들의 이해를 돕기 위해 ” HTML5의 전체적인 구조와 구성요소들”에 대해 쉽게 설명하고 있는 Brian Fling의 글을 번역해 보았습니다.

The Anatomy of HTML5 Mobile App.<-여기 원문 클릭

지난 몇년간 나는 HTML5 Mobile App.들을 열심히 개발해 왔습니다. 일반적으로 HTML5는 확장성있고 유연하게 크로스 플랫폼을 지원할 수 있는 모바일 앱 전략(a scalable and flexible cross-platform mobile app strategy)이라는 인식이 지배적입니다. 나는 원칙적으로 웹 테크놀로지가 모바일 단말의 중요한 플랫폼이라는 점에 대해 확신을 가지고 있으나 우리가 아직까지는 거기에 이르지 못하고 있다고 생각합니다.

내가 보기에 사람들이 모바일에서 HTML5로 직접 개발을 시작하기 전에 이것이 얼마나 많은 공수가 필요한지에 대해 과소평가하는 경향이 있습니다. 모바일 App.을 HTML5로 개발하는 것의 장단점에 대한 논쟁을 할 때면 “Volcano”라는 영화에서 Waturi씨가 전화로 대화하는 유명한 장면이 떠오릅니다.

  • I know HTML5 can get the job but can HTML5 DO the job? I’mNOT arguing that with you. I’m not arguing that with YOU. I’m notARGUING that with you. I’m not ARGUING that with you Harry! Harry… Harry… Yeah Harry… but can HTML5 DO the job. I know HTML5 can GET the job but can HTML5 do the job?

솔직히 말해서 지난 1년 내내 나는 모바일 플랫폼으로서 HTML5의 실체에 대해 고객을 교육시키는데 공을 들여왔습니다. 지루하게 순환되는 Waturi의 전화 논쟁처럼 그동안 HTML5가 무엇을 할 수 있는지에 대한 논란은 증거보다는 신념의 차원에서 이루어져 왔다고 생각합니다.

우리는 모두 HTML5가 일을 할 수 있다는데 동의합니다. 그런데 그것이 실제로 일을 할 수 있나요 ? (We all agree HTML5 can get the job, but can it DO the job ?).

그동안 내가 일해 왔던 백그라운드에 대해 좀 더 설명을 하면, 나는 10년이 넘도록 웹 기술을 활용하여 모바일 프로덕트를 개발해 왔습니다. 오늘날 까지도 나는 모든 모바일 웹의 변화에서 중요한 역할을 해 오고 있습니다 (I’ve been a vocal part of every mobile web movement to date). 심지어 나는 베스트 셀러인 ” how to design and development mobile web apps“라는 책의 저자이기도 합니다. 지난 2년 동안 pinch/zoom은 지구상에서 가장 큰 몇몇 대기업들을 위해 모바일에서 HTML5로 많은 일을 해 왔습니다. 수년 동안 우리는 많은 것을 배워 왔습니다.

그래서 HTML5로 작업을 할려면 무엇이 필요한가요 ?  오늘날 많은 회사들이 스스로에게 이런 질문을 던지고 있다는 것을 우리는 알게 되었습니다. 이 질문에 답하기 위해  HTML5 Mobile App과 HTML5 Mobile App. 개발을 위한 스택을 한번 해부해 보도록 합시다.

Overview of HTML5 Mobile Web App.Structure

Overview of HTML5 Mobile Web App.Structure

위 그림은 Cross Platform Mobile Web Strategy를 수립하는데 필요한 툴과 테크놀로지에 관한 초보자용 로드맵(Starter Roadmap)이라는 점을 일단 말씀 드립니다. 바로 이것 때문에 HTML5 Mobile App.은 어렵습니다.  많은 경우 여러분들은 아래 Diagram의 모든 파트를  직접 만들어낼 필요가 있습니다. 만약 당신이 이것을 만들어 내지 못한다면 빌려서 할 수 있겠지만 그렇다 하더라도 당신은 각각 파트를 하나씩 세부적으로 테스트하고 디버그해야 합니다.

Setting up the Server


HTML5 Mobile App.을 지원하기 위한 서버구조

모든 것은 모바일 단말에서 User가 컨텐트를 보기 위해 리퀘스트를 날리는 것으로부터 시작합니다.  이것은 보통 어떤 종류의 HTTP Request로서 웹서버로 전달됩니다. 대부분의 경우 HTTP Request로 인해 컨텐트가 동적으로 생성됩니다 (Dynamically Generated Content).  컨텐트를 App에서 렌더링할려면 적어도 두가지가 필요한데, 하나는 데이타이고 다른 하나는 이 데이타를 의미있게 만다는 방식, 즉 우리의 HTML5 App입니다.

Do you have a device detection solution?

모든 디바이스는 이런 저런 이유로 Unique한 점들을 가지고 있으므로 여러분들은 서버 사이드에 Device Detection Solution을 설치해 놓으라고 추천해 드립니다. Device Detection에는 여러가지 다양한 방식이 존재합니다. 이것을 사용하면 단말에 대한 보다 자세한 정보와 성능을 알 수 있습니다.

여기에서 기본 전제는 모든 단말이 동일하게 취급되어야 한다는 점입니다. 그러나 이것은 매우 단순한 경험 (Simple Experience)에만 적용됩니다. 다년간 나의 현장경험에 비추어 볼 때 대부분의 프로젝트에서 이 이론은 현실에 거의 적용되지 않습니다.

Device Dealing 문제에 관하여 좀 더 자세하게 살펴보고 싶은 분들은 pinch/zoom의 개발자인  Scott Gledhill의 모바일 토픽에 관한 짧은 튜터리얼인 Mobile Bits를 참고하세요.

 

모바일 App.을 개발해 보신 분들은 이미 충분히 경험해 보셨을 것이기 때문에 Device Fragmentation에 대해 좀더 살펴보면,  Scott Gledhill이 말하는 Device Fragmentation의 원인은

  • 서로 다른 OS, 서로 다른 브라우저 버전을 지원하는 다양한 Hardware
  • 같은 OS를 사용한다 하더라도 – 특히 안드로이드의 경우 – 폰버전에 따라 OS와 브라우저의 버전이 매우 다양
  • 모바일의 급속한 진화로 6개월만에 Upgrade
  • 소프트웨어 및 하드웨어의 다양한 변종 : Screen Resolution, Screen Size, Hardware Input (Anddroid)  vs Software Input (iPHone) 등 Device별로 차이가 있는 많은 기능들
  • Project에 하나의 Device가 추가될 때마다 설계와 개발의 복잡도가 Exponential하게 증가하는데, 가장 중요한 것은 지원하고자 하는 Multiple Device 들 각각의 단말에서 어플리케이션을 테스트해야 한다는 점

Device Fragmentation에 대해서는 스티브잡스가 iPhone은 단 2가지 버전으로 동일한 User Experience를 제공하는데 반해 Android는 제조업체별로 차별화를 위해 전용의 U/I를 추가한 결과 244개의 단말에 100여개의 서로 다른 소프트웨어 버전이 존재하기 때문에 개발이 매우 어렵다면서 “Android Fragmentation (AppleInsider, 2010년 11월 19일)” 문제를 본격적으로 이슈화했습니다. 그에 따르면

  • Unlike Windows, where PCs have the same interface, Android is very fragmented.
  • HTC and Motorola install proprietary user interfaces to differentiate themselves. The user left to figure it out. Compare this to iPhone where every handset works the same.
  • Twitter client developer “had to contend with 100 different versions of software on 244 different handsets. That’s a daunting challenge. Many Android apps work only on selected handsets, or selected Android versions. This is for handsets that shipped 12 months ago. Compare with iPhone, where are two versions to test against, the current and most recent predecessor.

그러나 다양한 Android 단말에 TweetDeck 클라이언트를 적용해 본 개발자에 따르면, 안드로이드 Application 개발이 Jobs가 지적한 바와 같이 악몽 (a nightmare developing on Android) 수준은 아니라면서 안드로이드 TweetDeck 개발에 단 2명이 필요했다고 합니다.

실제 개발경험상 확실히 “Android Fragmentation”에 대한 Jobs의 비판은 과장된 측면이 없지 않으나 Application 개발시 iPhone보다는 훨씬 더 많은 공수가 필요한 것은 사실이긴 합니다.

What is your plan to deal with offline data?

2011년 5월 Localitics가 발표한 자료에 따르면 모든 모바일 App.의 15%가 오프라인 상태에서 실행됩니다 (15% of all mobile apps launch when they the device is offline). 그래서 여러분들은 Offline Data Experience 문제에 대해서도 다루어야만 합니다. 여러분들의 데이타 아키텍쳐는 거의 대부분이 인터넷을 통해 페이지를 전달하는 구조로 설계되어 있습니다. 그러나 인터넷 접속이 불가하다면 어떻게 될까요?

네트워크 접속이 끊긴 상태에서 User Data Needs에 대해 당신은 어떤 계획을 가지고 있나요? 그들에게 뛰어난 Offline Experience를 제공하고 나중에 네트워크에 접속할 때 모든 것을 한방에 싱크할 수 있도록 할 건가요? (How do you plan to anticipate the users data needs while they are online, provide them with a great offline experience, then sync everything together when they are back?)

Cache Manifest에 대해서는 잠시 후에 더 애기하겠지만, 여기에서는 캐쉬 매니페스트를 사용할 경우 일이 더 복잡해 질 수 있다는 점만 일단 지적해 두고자 합니다.  데이타 싱크도 다룰려면 컨텐트 위에 어떤 종류의 RESTfull API가 필요하게 될 것입니다.

※ Wikipedia의 Cache Manifest에 대한 정의를 좀더 살펴보면

  • HTML5에서 Cache Manifest는 네트워크 커넥션이 없는 상태에서도 Web Application에 접근이 가능하도록 하는  Software Storage Feature이다.
  • Web Application은 보통 네트워크에서 다운로드가 필요한 웹페이지들로 구성된다. 이렇게 하기 위해서는 반드시 네트워크 커넥션이 필요하다.
  •  HTML5는 어떤 이유로든지 User가 네트워크에 접속할 수 없는 상황에서 캐쉬 메니페스트를 사용하여 웹 어플리케이션에 접근이 가능하도록 한다.
  • Web Application은 웹 주소들의 리스트로 구성된다. 웹 어플리케이션이 렌더링 될려면  HTML, CSS, JavaScript, 이미지 등웹주소들을 구성하는 비롯한 다양한 소스들이 필요하다.
  • 웹 어플리케이션의 렌더링에 필요한 다양한 주소들 또는 URL들은 매니페스트 파일에 복사되는데, 웹 어플리케이션 개발자들은 새로운 웹 주소들이 추가되거나 삭제될 때 매니페스트 파일을 정기적으로 업데이트한다.
  • 네트워크를 통해 최초로 접속할 때 웹 브라우저는 HTML5 매니페스트 파일을 읽은 후 주어진 리소스를 다운로드 받고 그것들을 로칼에 저장한다.
  • 이렇게 하면 네트워크에 접속되지 않은 상태에서 웹 브라우저는 서버가 대신 로칼 카피를 불러 들이고, 웹 어플리케이션의 오프라인  렌더링을 지원할 수 있게 된다.

The HTML5 App

HTML5 App.의 구조

HTML5 App.의 구조

손안에서 Data와 Device를 어떻게 다룰지 계획을 수립했다면, 다음 단계는 HTML5 App.을 만드는 일을 해야 합니다. 이것이 아마 가장 쉬운 부분일 것입니다.  HTML5는 지금도 진화중인 테크놀로지로서 만약 여러분이 HTML을 안다면 HTML5에서 새로운 것이 무엇인지 한시간 안에 이해할 수 있을 것입니다.

What Does HTML5 Do ?

What Does HTML5 Do ?

 

HTML5에서 무엇이 새로운지 신속한 오버뷰를 원한다면 아래 두가지 훌륭한 리소스를 참고하시기 바랍니다.

나같은  HTML5 초보자들의 이해를 돕는 차원에서 Scott Gledhill Mark Pilgrim이 정리한 HTML5에 추가된 기능의 주요 개념을 좀 더 설명하면,

  • Native Audio and Video Support : Flash Killer로 유명한데 HTML5를 사용해서 비디오와 오디오를 표준화하면 플래쉬를 지원하지 않는 iOS 단말에서 당신의 비디오를 동작시킬 수 있습니다. 당신의 웹페이지에 비디오를 임베딩할수 있게 하기 위해 HTML5는 <video>라는 새로운 요소를 정의하고 있습니다. 이전에는 Apple QuickTime®이나  Adobe Flash®처럼 3rd Party Plugin이 없다면 비디오를 웹페이지에 embedding할 수 없었습니다.  그러나 브라우저들마다 지원하는 Codec이 다르기 때문에 HTML5 video가 어떤 브라우저에서나 동작하지는 않습니다. Kroc Camen이 만든 “Video For Everybody“이라는 솔루션을 사용하면 JavaScript를 전혀 사용하지 않고도 모바일 브라우저를 포함하여 거의 모든 브라우저에서 비디오의 동작을 지원한다고 합니다.
  • Local Storage : HTML5 Storage는 특정 웹사이트에 있는 정보를 컴퓨터에 저장하고 나중에 retrieve할 수 있는 방법을 제시합니다. 이 컨셉은 cookie와 유사하지만 쿠키보다 보다 많은 양의 정보를 저장할 수 있도록 설계되었습니다. 쿠키의 사이즈는 제한되어 있습니다. 당신의 브라우저는 새로운 페이지를 리퀘스트할 때 마다 웹서버에 쿠키를 전송하기 때문에 더 많은 시간과 귀중한 badnwidth를 낭비하게 됩니다. 그러나 HTML5 페이지는 당신의 컴퓨터에 남아 있으며, 웹 사이트들은 페이지가 로드된 이후에 JavaScript로 그것에 접근할 수 있습니다. Local Storage는 HTML5 메인 스펙에 포함되어 있었으나 일부 Working Group에서 HTML5의 덩치가 너무 커진다는 불만을 제기함에 따라 별도의 스펙으로 분리되었습니다.
  • Offline Storage : 인터넷에 연결되지 않은 상태에서도 당신의 Web App.으로 컴퓨터나 모바일 단말에 저장된 컨텐트에 접근할 수 있도록 함으로써 당신의 WebApp이 보다 Native Application처럼 동작할 수 있도록 하고, 간헐적으로 인터넷 접속이 끊기는 환경에서도 효과적으로 동작할 수 있도록 지원합니다. Gmail이나 Google Docs가 오프라인 모드를 지원하는 대표적인 Web App.입니다.
  • Canvas : 그래프나 게임 그래픽, 또는 기타 비쥬얼 이미지들 등 JavaScript를 사용하여 무엇이든지 브라우저에서 바로 그려낼 수가 있습니다.“a resolution-dependent bitmap canvas that can be used for rendering graphs, game graphics, or other visual images on the fly.”
  • Geolocation : 당신이 신뢰하는 웹사이트에 위치를 공유하면, 당신의 현재 위치에 기초하여 모든 종류의 Cool한 서비스를 제공할 수 있습니다.
  • Enhanced Form Control : JavaScript를 사용하지 않고도 아래와 같이 placeholder text, autofocus, regular expressions, basic form validation, required fileds support 등이 가능합니다.
  • Input Type : 웹의 회원가입이나 검색 등 정형화된 양식을 구성하는 필드값들을 정의할 때 사용되는 Input Type에 10여가지가 HTML5에 추가되었습니다. <input type=” ? “> 형식인데 ? 안에는 “search” “number” “range” “color” “tel” “url” “email” “date” “month” “week” “time” “datetime” “datetime-local” 등을 삽입해서 사용하면 됩니다.
  • Placeholder Text : input field에 포커스가 없으며 아무것도 채워지지 않은 상태인 경우 placeholder text를 표시해 줄 수 있습니다. 예를 들면,  Facebook의 Status update창에 “what’s on your mind”라는 글자가 “Placeholder Text”인데, user가 입력창을 선택하면 이 placeholder text는 바로 사라집니다.
  • Form Autofocus :  기존 웹사이트에서는 JavaScript를 통해 특정 Input Filed에 커서가 자동으로 옮겨지는 Autofocus 기능을 구현했습니다. 예를 들면, google.com 페이지에 접속하면 User가 선택하지도 않았는데 커서 검색창에 Default로 위치된 상태로 페이지가 로딩됩니다. 그러나 페이지가 로딩되고 있을 때 User가 다른 Input Field로 포커스를 이동시켰을 경우 로딩이 완료되면 친절하게도 원래 Field로 포커스를 자동으로 옮겨버리는 문제가 발생합니다. 그래서 엉뚱한 필드에 잘못된 정보를 쳐 넣기도 하는 불편을 해소하기 위해 HTML5는 모든 web form control에 autofocus attribute를 도입했습니다. Autofocus attribute를 사용하면 원래 의도했던 인풋 필드에만 적용되기 때문에 포커스를 다른 필드로 옮길 수 있습니다. 그러나 이것은 스크립트가 아니라 markup이기 때문에 전체 웹사이트에 일관성있게 적용됩니다. 어떤 브라우저는 User가 오토포커싱 기능을 disable시킬 수 있는 옵션을 제공하기도 합니다.
  • Web Workers : 브라우저가 백그라운드에서 JavaScript를 실행시키기 위한 표준화된 방식입니다. Web Workers를 사용하면 multiple thread를 거의 동시에 동작시킬 수 있습니다. 메인 웹페이지가 User의 scroll, clicking, typing 등에 반응하는 동안  이 “background threads”는 복잡한 수학적 계산을 수행하거나, 네트워크 리퀘스트를 처리하거나, 또는 로칼 스토리지에 접근할 수 있습니다.
  • Inline Document Editing : 오로지 HTML markup만을 사용하여 브라우저에서 바로 웹페이지를 직접 편집할 수 있습니다.
  • Microdata : 당신의 웹페이지에 추가적인 Symantic을 제공하기 위한 표준화된 방법입니다. Microdata를 사용하면 당신은 웹페이지에 있는 특정 사진에 대해 이것을 사용할려면 “Creative Commons license”가 필요하다고 표시해 둘 수 있습니다. Microdata를 사용해서 “About Me” Page를 mark up할 수 있습니다. 각종 브라우저. 브라우저 익스텐션, 검색엔진은 당신이 추가해 놓은 HTML5 microdata mark up을 연락처 공유를 위한 표준 포맷인 vCard 형태로 변환할 수 있습니다.
위와 같이 HTML5에는 많은 유용한 기능이 새롭게 추가되었으나 까놓고 애기하면 적어도 Markup의 관점에서 볼 때 5년전에 우리가 Mobile App을 만들던 방식과 지금 만들고 있는 방식간에는 큰 차이가 없습니다.  JavaScript와 CSS3를 사용하는 HTML5로 우리는 무지하게 많은 것들을 만들어 낼 수 있으나  markup 자체는 여전히 태그로 쌓여져 있어서 의미를 가지게 되는 컨텐트에 불과합니다. 

 

The Cache Manifest

아마도모바일용으로  HTML5에 추가된 최고의 기능 중 하나로 Cache Manifest(또는 App Cache)를 꼽을 수 있을 것입니다.  Cache Manifest는 당신이 로칼에 캐쉬하고 싶어 하는 파일들의 리스트를 저장하고 있는 간단한 텍스트 파일입니다. 이것은 당신의 App.이 디바이스 메모리에서 사용하고자 하는 일반적인 JavaScript, CSS, 이미지 파일들을 저장하는데 편리한 방법입니다.  이리하여  App.이 구동되는데 필요한 인터페이스 요소들을 네트워크 접속이 끊긴 상태에서도 사용할 수 있게 됩니다.

당신의 App이 오프라인 모드를 지원한 계획이 없다 하더라도 캐쉬 매니페스트를 사용하면 필요한 네트워크 커넥션 수를 줄이는데 효과적입니다.  Dynamic Data Caching은 전혀 다른 문제인데 이 경우에는 Cache Manifest가 아니라 JavaScript를 사용하여 데이타를 싱크시키는 것이 전형적입니다 (즉, 데이타의 변경이 자주 일어나는 경우 데이타 싱크를 위해서 Cache Manifest보다는 JavaScript를 일반적으로 많이 사용한다).

어느 정도 선까지 오프라인 모드에서 App의 동작을 지원하는 것은 App. Store에 등록된 거의 모든 App.의 필수사항이라는 점을 명심하십시요. 이 단계를 간과하지 않도록 확실히 챙기시기 바랍니다.

What is your fallback strategy?

모든 모바일 디바이스가 동일하지는 않다는 점을 잊지 마세요. 당신이 하나의 플랫폼만 지원할 계획이라 하더라도 디바이스별, 버전별, 캐리어별로 수많은 특징들(a lot of uniques)이 존재합니다.  무엇인가 기대한 대로 동작하지 않는 경우 모바일에 bulletproof code를 삽입해 놓는 것이 가장 좋은 대비책입니다. 다른 말로 하면 디바이스의 지원이 빈약하거나 잘 알려지지 않은 경우 최신 테크닉을 사용하기 보다는 단순성을 유지하는 것이 유리합니다. 우리는 이것은 “우아한 후퇴 (graceful degradation)”라고 부릅니다.

HTML5의 경우 내가 해줄 수 있는 최고의 조언은 코드를 매우 시맨틱하게 유지하라는 것입니다. CSS나 JavaScript를 사용하기 전에 우선 모든 markup을 먼저 짜십시요. 이렇게 생성된 markup은 가장 낮은 폼에서도 완벽하게 사용될 수 있습니다 (In the case of HTML5 my best advice is to keep code very semantic. Write all your markup first without any CSS or Javascript. The resulting markup should always be perfectly usable in its lowest form).

그리고 Fling은 다양한 Web Browser상에서 WebApp.의 동작을 지원하기 위해 “Graceful Degradation” 또는 “Progressive Enhanment” 방식을 제안합니다.
Progressive Enhancement

Progressive Enhancement

 

Progressive enhancement는 어떤 웹 브라우저에서든지 그것의 성능과 상관없이 당신의 컨텐트에 대한 접근을 보장해 주기 위해 웹 테크닉들을 Layered Fashion으로 사용하는 방법입니다. 이것은 “우아한 후퇴 (Graceful Degradation)”이라고도 하는데, 당신이 한가지 상황에서 이상적인 경험(one ideal experience) 뿐만 아니라 누가 컨텐트를 보느냐에 따라  다양한 환경에서 덜 이상적일 수도 있는 경험을 창조해 낸다는 것을 의미합니다.

Progress Enhancement는 브라우저에서 렌더링했을 때 어떤 스타일도 정의되지 않았거나 markup된 것만 보이는 경험이 중심에 있습니다. 여기에서 기본 가정은 어떤 단말에서든지 이 정도 수준의 Presentation은 보여줄 수 있다는 것입니다. 그러나 이것이 잘 동작하려면

  • markup이 시맨틱(symantic)하게 짜여져야 한다는 점, 다른 말로 하면 presentation이 없는 환경에서도 markup이 쓸모있는 상태를 유지해야 한다는 점입니다.
  • 다음 단계에서 우리의 markup과 가장 기본적인 스타일링 테크닉을 지원하는 최저 사양의 단말( lowest common denominator devices)에 적용하기 위해 기본적인 스타일링 테크닉을 추가합니다.
  • 우리는 외부에서 최상의 가능한 경험에 도달할 때까지 계속해서 layer를 추가합니다.  나는

나는 가능한 한 컨텐트의 수정 (content adaptation)없이 여러분의 프로젝트를 시작하라고 항상 권고하지만, 어떤 경우 컨텐트의 수정이 필요할 때도 있습니다. 갑작스럽게 하나의 사이트의 Multiple Version을 만드는 것보다는 우아하게 후퇴할 수 있는 One Code Base로 시작하는 것이 훨씬 쉽고 빠릅니다.

Progressive Enhancement 방식을 사용해서 개발하면 당신의 사이트에 데스크탑 레이어를 추가할 수 있다는 점도 덧붙이고 싶습니다.  모바일 컨텍스트용으로 설계된 Layer 위에 데스크 탑 레이어를 구축할 수 있기 때문에 이러한 접근방식에는 아무런 문제도 없습니다.  이것은 사실 아래 그림에서 보듯이 내가 오리지날 Mobile 2.0 이벤트 사이트 개발시 적용한 방식입니다. 일단 유용한 Mobile Experience를 창조한 후 서로 다른 Viewing Context를 지원하기 위해 multiple layer를 쌓아가면서 데스크탑에서 끝나게 됩니다.

Progressive Enhancement Case

Progressive Enhancement Case

만약에 당신이 데스크탑에서 먼저 시작한 후 그로부터 유용한 모바일 Experience를 만들어 내는 방식으로 거꾸로 일을 진행하면 문제가 발생할 것입니다. 이렇게 하면 열에 아홉은 어색하고 거의 쓸모없는 사이트의 버전이 탄생하여 로딩하는데 속도도 느려지고 비용도 많이 소요되게 될 것입니다.

Mobile Progressive Enhancement

모바일 웹 초기 개발시부터 내가 사용해 왔던 팁과 트릭에 대해 좀더 말씀 드리면,

  • 당신의 markup을 항상 Symantic하게 짜세요. 나는 코딩한 대로 페이지가 렌더링되는지 내가 직접 눈으로 확인하기 위해 live preview window를 항상 열어놓고 작업합니다. 나는 이런 방식으로 스타일쉬트가 전혀 적용되지 않았을 때에도 페이지가 항상 usable한지 확인합니다.
  • Device 계획을 수립하세요. 코딩을 시작하기 전에 어떤 device class들을 지원하고 싶은지 정확히 인지하고 있어야 합니다. Device Plan에 따라 당신이 페이지를 코딩하는 방식이 달라질 수 있습니다.
  • 당신이 코딩을 시작하기 전에 최저 사양과 최고 사양의 단말에 적합하게 미리 설계하고, One Code Base로 두가지 버전을 만들어 내는 방식을 Visualize해보세요.
  • 서로 다른 모바일 단말에서 시작부터 끝까지 테스트하는 방식으로 당신의 단계적으로 작업 (incremental work)이 의도된 단말에서 정확하게 디스플레이되는지를 확인하세요.
  • 데스크 탑 레이어를 추가할 계획이라면 항상 모바일 버전을 먼저 만드세요.

The Javascript

JavaScript의 구조

JavaScript의 구조

좋습니다. 이제 가장 중요한 부분이 Javascript에 대해 살펴봅시다. 내가 몇년 전 “Mobile Design and Development“라는 책을 썼을 때만 하더라도 cross-platform Javascript에 관해서는 거의 논의가 이루어지지 않았습니다. 이것은 HTML5도 마찬가지 입니다.  그 이후 많은 일이 벌어졌는데, 불과 2년만 해도 Javascript는 (iPhone 이외의) 모바일 단말 지원시 사용되는 대수롭지 않은 툴에 불과했으나 (spotty mobile support) 지금은 User에게 데이타와 로직, interaction을 제공하기 위해 우리가 사용하는 일차적인 수단(primary means)이 되었습니다.

이러한 상전벽해는 HTML5로의 이행과 동시에 이루어졌습니다. 다른 말로 하면 HTML5는 많은 새로운 기능들을 가지고 있으나 JavaScript가 없다면 사용할 것이 거의 없습니다.  User의 물리적 위치를 look up하고 싶나요? JavaScript로 할 수 있습니다. 오프라인 스토리지에 데이타를 저장하고 싶은가요? Javascript로 하십시요.

어떤 사람들은 이러한 구별(distinction)이 별것 아니라고 생각하지만 나는 큰 의미가 있다고 믿습니다. Scriptaculous, Prototype, MooTools. 그리고 jQuery와 같은 Javascript 프레임워크가 없었던 시절을 생각해 보세요. 나는 JavaScript 짜는 일을 좋아하는 사람을 본 적이 거의 없습니다. 그것은 허드렛일이었습니다. 이러한 프레임워크들로 인해 우리의 삶은 의심할 여지 없이 훨씬 쉬워졌으며  Web의 얼굴 자체도 변화되었습니다. 반면 이러한 프레임워크들의 도움없이 Javascript를 짤 수 없는 개발자들도 많아 졌습니다 (can’t write Javascript without the aid of these frameworks).

모바일 세계에서 이것은 문제입니다. 모바일 web app 개발에서 가장 어렵고 시간이 많이 소요되는 일은 테스트하는 것입니다.  당신이 사용한 모든 테크놀로지 하나하나를 테스트할 수 있게 만들어야 합니다. 무엇이 어떻게 동작하는지를 잘 모른다면 단순한 버그를 발견하는데 수백줄의 코드를 들여다 봐야하는 등 당신의 시간과 노력을 잡아먹는 블랙홀을 만들게 됩니다.

만약 당신이 하나의 플랫폼만 지원할 계획이라면 이것은 그럭저럭 참아 낼 수 있지만 다양한 플랫폼을 지원하려면 복잡성으로 인해 개발과 테스트에 훨씬 더 많은 시간(order of magnitude)이 소요됩니다.

나는 Murphy의 법칙이 모바일 개발과 테스트에 적용되는 원칙이라고 절대적으로 확신하고 있습니다. pinch/zoom에서 우리는 모바일 테스팅에 관한 사실상의 규칙을 가볍게 생각한 적이 없습니다 – 만약에 우리가 무엇인가를 사용하기로 했다면 만약 그것에 문제가 생겼을 때 그것을 고치는데도 그만큼 헌신해야만 했습니다.

이제 Javascript 스택의 3가지 파트를 살펴 보겠습니다.

Hybrid Scripts

이 스크립트들은 코어 스크립트와 Device SDK간 갭을 줄여 줍니다 (bridge the gap between core scripts and device SDK). 하이브리드 스크립트는 당신이  HTML5 App을  UIWebViewPhoneGap같은 네이티브 래퍼(native wrapper)로 싸려 할 때 필요한 스텝입니다.  당신은 하이브리드 스크립트를 당신이 지원하고자 하는 각각의 플랫폼에 최적화시킬 필요가 있습니다. 내가 아는 한 이와 같은 하이브리드 컨텍스트에서 phonegap.js는  다양한 플랫폼에서 동작을 지원하는 유일한 일반적인 스크립트입니다.

Core Scripts

코어 스크립트는 당신의 앱중에서 모든 플랫폼에서 사용되는 공통의 컴포넌트(common component of you app available in every platform)입니다.  웹브라우저를 통해 App에 접근했을 때 코어 스크립트는 native SDK가 해야할 Function까지 수행하는 이중의 역할을 하게 됩니다(serve double duty). 이것은 당신의 App.이 HTML5 페이지들을 어셈블하고 렌더링하는데 필요한  내부의 로직(internal logic)같은 것이라고 생각하면 됩니다. 이때 jQuery같은 풀 프레임워크를 편리하게 사용할 수 있으나 대개의 경우(tyupically) 우리는 대부분의 job을 수행함에 있어  micro frameworks의 사용을 추천드립니다.

Device Scripts

마지막으로 Device Script는 Device Native Behaviour를  Javascript로 에뮬레이션하는 일을 합니다.  Device Script의 가장 좋은 사례로  jQTouch가 내 머리 속에 떠오르는데, 이것은 jQuery를 사용하여  iPhone의 native behaviour와 애니메이션을 흉내 냅니다.  jQTouch는 Device를 구별하지 않으므로 iOS의 메소드를 안드로이드를 비롯한 다른 모바일 플랫폼에도 그대로 사용하는데, 다른 플랫폼의 User들은 이것을 별로 좋아하지 않습니다. 그러므로 우리가 지원하고자 하는 각각의 플랫폼별로 unique하게 device script를 짤 필요가 있는지를 사전에 판단해야 합니다.

The CSS

CSS의 구조

Presentation Layer로서 CSS의 구조

CSS는 당신의 App의 Presentation Layer입니다. 개발자들은 CSS를 컴퓨터 랩의 art student들과 같이 어플리케이션 개발시 디자이너들이 생성해야 할 허드렛일 정도로 생각합니다. 그러나 Presentation은 HTML5 모바일 App.에서 가장 중요한 부분입니다. Apple, Nokia, Miscrosoft와 같은 회사들은 뛰어난 모바일 User Experience를 창조해 내기 위해 수백만달러를 쏟아 붙습니다. 물론 우리는 이렇게까지 할 필요는 없지만 어떤 사람들은 의도적으로 이것을 건너 뛰기도 합니다. 이것은 HTML5 모바일 App 개발시  당신은 자신만의 Experience를 맨땅에 헤딩하면서 창조해낼 필요가 있다는 것을 의미합니다.

오늘날 Mobile Experience에 대한 고객의 요구를 수용하는 것은 그렇게 사소한 문제가 아닙니다. CSS는 이러한 고객의 높은 기대를 충족시키기 위해 당신이 사용하는 코드입니다.

만약 당신이 만드는 HTML5 App.을 차에 비유한다면, CSS는 외관, 모델, 칼러 그 이상이며 인테리어 디테일까지도 포함합니다.  당신이 차에 타면 패브릭이냐 가죽이냐만 눈에 띄지 않을 것입니다. 우리는 디테일에도 주목하게 됩니다. 운전대가 손에 잡히는 느낌, 대쉬보드의 디자인, 스테레오 컨트롤을 위한 거리 등을 알아채게 됩니다. 이 모든 것들이 우리의 driving experience에 영향을 줍니다.

Javascript는 결정적으로 우리의 App. Experience에 영향을 주지만 그것은 우리의 눈으로는 보이지 않는 방식으로 정교하게 동작합니다. 우리는 Javascript가 절대로 필요하지만 Top Gear Fan들의 말처럼 후드 밑에 감춰져 있는 파워가 우리의 Powerful Experience와 항상 동일한 것은 아닙니다 (Jeremy’sreview of the Ferrari 599 GTO).

Performance와 Presentation은 상호 조화롭게 동작해야만 합니다.

jQTouch, Sencha Touch 또는 jQuery Mobile과 같은 툴의 사용에 관심있는 사람들에게 나는 이러한 프레임워크들로부터 무엇을 정확하게 얻을 계획인지 질문하곤 합니다.  그러면 실제로는 주로 iOS의 미학을 에뮬레이션하는 “Device Theme” Stylesheet에 불과한 때가 많으며 기껏해야 여기에 Javascript 몇줄을 추가해서 iOS transition을 흉내내는 CSS Transforms을 수행하면 끝인 경우가 많습니다. 다른 Device aesthetic을 에뮬레이션할 때 CSS의 사용에 관심이 있는 사람은 거의 없습니다 (try finding a  CSS template for Android).

그러나 당신 App.이 다른 App.들과 구별되기를 원할 때가 있을 것입니다. 이때 default aesthetic과 단절하고 당신 자신만의 브랜드 스타일 가이드를 충족시킬 수 있도록 툴을 수정하고 싶다면, 당신의 App.을 처음 설계할 때부터 full CSS stack의 사용을 고려해 보세요.

Device Themes

위에서 언급했듯이 CSS는 플랫폼의 aesthetic을 에뮬레이션하는데 필요합니다. 이것은 User가 익숙해져 있는 Visual Language입니다. User들은 당신이 만든 App.의 인터페이스를 학습하는 대신 이러한 언어를 사용하여 태스크를 수행합니다. 최근에 세어본 바에 따르면 각 플랫폼마다 unique한 인터페이스 요소들이 100여개가 넘습니다. 당신이 무엇을 하고 있는지 정확히 알고 있지 않다면 당신 자신만의 언어를 새로 만들지 말라고 권유드립니다 ( I wouldn’t recommend inventing your own language unless you know what you are doing).

Sencha Touch, jQuery Mobile 등의 툴을 사용하면 이런 일을 할 수 있습니다. 이경우 당신의 App.은 플랫폼과 비슷하게 보이긴 하겠지만 당신 자신만의 look처럼 보이지는 않을 것입니다. 그러나 시작할 때 이런 툴을 사용하는 것이야 말로 당신 자신만의 언어를 만들기 위한 가장 좋은 방법이 될 수 있습니다 (using these tools as a starter can be the best route if you plan to construnct your own language).

Core Theme

Core Theme은 당신의 애플리케이션에서 재사용이 가능한 “가구”와 유사합니다. 이것은 당신이 필요로 하지만 보통은 눈에 잘 띄지 않는 특징이 있습니다. 나는 reset, layouts, typography, color 또는 image handling과 같은 presentation essential을 unique한 stylesheet로 분리시켜 놓고, 그것을 나의 코어 또는 브랜드 테마로 이용하는 것을 좋아합니다. 이러한 요소들은 당신이 어떤 플랫폼을 사용하든지 상관없이 항상 동일해야 합니다.  간단한 예를 들어 보면,  당신의 로고는 항상 동일한 방식으로 presentation되어야 합니다. 아마 당신의 툴바 칼라는 브랜드 칼라를 따라갈 것입니다. 브랜드와 툴바의 칼라 모두 당신의 Core Theme에 정의되어 있어야 합니다. 그러나 Device Theme에서 iOS용으로 툴바에 gradient effect를 추가했는데 이것이 안드로이드에서는 없는 효과일 수도 있다는 점에 대해 주의를 기울여야 합니다.

App Theme

마지막으로 App Theme은 당신의 App.에만 존재하는 presentation element를 의미합니다. 많은 프로젝트에서 이러한 요소들을 하나의 스타일쉬트에 통합시킵니다. 좋긴 합니다만 나는 당신의 Core와 App. element를 적어도개념적으로는 분리해서 유지하라고 추천드립니다. 이렇게 하면 나중에 디버깅할 때 편리합니다.

Conclusion

HTML5는 일을 할 수 있나요? 물론입니다. 나는 그것에 대해 논쟁하고 싶지 않습니다. HTML5로 일을 할 수 있나요 ? 당근입니다. 그러나…

  • 시간이 필요합니다. 당신이 이전에 해왔던 어떤 프로젝트들보다 많은 시간이 걸린다고 보시면 됩니다.
  • 그에 따라 더 많은 예산이 소요됩니다. 이것은 웹사이트가 아닙니다. 훨씬 더 많은 비용이 소요됩니다.
  • 회사 내부에서 이것을 할 수 있는 개발인력이 존재하는지 먼저 확인하세요. 세상에서 이것을 매일매일 하는 노련한 전문가들에게도 이것이 어려운 문제라면, 당신의 팀도 당연히 어려울 것입니다.
  • 툴들이 항상 존재하진 않습니다.  당신 자신의 툴을 스스로 만들어야 할 때가 꽤 자주 있습니다.
  • 모든 옵션을 검토하세요. 테크놀로지에 대해 도그마적으로 접근할 경우 돈을 불필요하게 낭비하게 됩니다. 모바일에는 정답이 없습니다. 오픈 마인드를 유지하고 당신의 고객이 무엇을 원하는지에 집중하세요.

Written by abulaphia

September 8, 2011 at 12:00 pm

HTML5에 관한 11가지 냉혹한 진실

with 6 comments

Infoworld의 기고가  가 밝히고 있는 HTML5의 11가지 문제점을 간단히 번역해 본다.

※ Source : 11 Hard Truths About HTML5

HTML 5에 몇가지 강력한 기능들이 추가됨에 따라 웹프로그래밍의 패러다임이 변화할 것이라는 호들갑에도 불구하고 실제로는 Web상에서 Native-App.의 퍼포먼스를 아직까지 따라가지 못하고 있다. HTML5의 강력한 성능에도 불구하고 그것이 모든 문제를 해결할 수는 없다.  HTML5에 추가된 매력적인 기능들로 인해  Web App이 Native App. 의 강력한 경쟁자로 부상하고 있으나, 보안문제, Local Data Storage의 한계, 동기화 문제, 브라우저 벤더간 정치싸움으로 우리의 기대에는 한참 미지치 못하고 있다.

1. Security Is Nightmare

클라이언트 사이드 컴퓨팅의 근본적인 문제는 User가 궁극적으로 머신에서 동작하는 Code를 통제할 수 있다는 점이다. Web App의 경우 당신의 브라우저를 뛰어난 툴로 디버깅하면  남용하기가 훨씬 더 쉽다.

Firebug와 같은 Javascript Debugger를 사용하면 Facebook이나 Google같은 사이트가 어떻게 동작하는지 알고 싶은 사람은 누구든지 Breakpoint들을 삽입해 놓고 코드를 볼 수 있다. 이로 인해 웹사이트의 디버깅과 동작방식을 쉽게 이해할 수 있게 되지만 “보안”의 관점에서는 악몽에 가깝다.

Firebug를 비롯하여 브라우저 디버깅 툴을 사용하면 특정 변수의 값을 당신이 원하는 대로 조작할 수 있다. 즉 당신의 브라우저가 지구상에 위치해 있는 위도와 경도값 등 위치 변수를 쉽게 편집해서 친구들에게 당신의 위치를 속일 수 있다.  Web App이 제공하는 모든 기능들 역시 수정될 수 있다. Web 환경은 정상적인 Native Code에서 보다 훨씬 더 쉽게 조작이 가능하다.

보안문제가 발생하는데에는 한계가 있다. Google Web Tool Kit과 같은 JavaScript Tool은 표준 컴파일러 만큼이나 복잡하고, 이러한 툴들의 아웃풋은 측량하기가 어렵다. 그러나 운좋게도 JaveScript Deminifier같은 툴들을 사용하면 보완이 가능하다.

물론 보안상의 위험은 어플리케이션의 본성에 달려있다. 당신은 위도와 경도값을 편집해서 친구들에게 당신이 지구의 반대편에서 체크인한 것처럼 보이게 만들 수 있다. 만약 누군가 위치 조작에 의해 특정 장소의 Mayor로서의 권한을 취득하고 이것이 돈과 관련이 된다면 게임은 훨씬 더 복잡해 진다. 이러한 이유로 중요한 데이타를 수집을 위해  Client Based HTML5 App.들을 신뢰하기는 어렵다.

2. Local Data Storage Is Limited

당신의 브라우저에서 파뭍혀 동작하는 로칼 데이타 베이스는 HTML5의 가장 똑똑한 기능들중에 하나인데, 이것을 사용하면 Web App.으로 당신의 컴퓨터에 데이타를 쉽게 캐슁할 수 있게 된다. 누군가 브라우저에서 Desktop과 유사한 functionality를 기대한다면,  Local Database를 사용함으로써Bandwidth를 절약하고 퍼포먼스를 개선할 수 있다.

그러나 Desktop App.과 달리 User들은 브라우저의 Local Database에 캐슁된 데이타를 거의 통제하기 어렵다.  HTML5 Data Storage 성능은 매우 중요한 추가사항임에는 분명하지만 1) 저장된 데이타를 다른 머신으로 옮기거나,  2) 데이타를 카피하거나 3) 데이타를 백업해 놓거나 4) 다른 App.으로 열어 볼 수 없다. 이 데이타는 브라우저가 감추어 놓은 곳에 깊숙하게 파뭍혀 있다. User는 데이타를 호스팅하는 책임만 있고 그것을 컨트롤할 수 없다는 점에서 최악이라고 할 수 있다.

최근의 몇몇 브라우저들은 어떤 데이타베이스가 당신의 머신에서 생성되어 있는지를 볼 수 있게 하고 있으나, 이 정보들은 매우 제한적이다. 사파리를 사용하면 이 데이타베이스를 삭제할 수 있 수 있으나, 이 정보를 브라우징하거나 다른 머신으로 옮길 수는 없다. User가 어디를 보아야하는지 인지한 상태에서 이것을 옮기려 한다 하더라도 파일들은 쉽게 옮길 수 있도록 설계되어 있지 않다.

User들은 파일들을 들이 파서 무엇이 저장되어 있는지를 찾아낸다 하더라도 볼 수는 없다. 물론 프로그래머들은 그것들을 분리해 낼 수 있으나 이것조차도 포맷을 먼저 공부하거나 해킹한 후에야 가능하다. Desktop App.과 달리 Local Storage에 저장된 데이타는 스프레스 쉬트나 텍스트 다큐먼트처럼 쉽게 어떤 에디터로든지 열 수가 없다 (They’re not like spreadsheets or text documents that are easy to open with any editor, making the data less resourceful than it might otherwise be in a desktop app).

3. Local Data Is Manipulated

User는 데이타에 대한 통제력이 없지만, 중앙의 웹사이트 역시 클라이언트 데이타를 처리하기가 어렵기는 마찬가지다. 만약에 User가 브라우저나 머신을 변경한다면 어떻게 될까? 많은 웹 개발자들은 이 문제에 손을 들고 단기적인 컨텐트만을 캐슁하기 위해  local data storage를 사용한다.

개발자들은 동기화문제 때문에 User들이 많은 컨텐트를 생산하지 못하도록 꼼수를 쓴다. 웹개발자들은 local database의 보안에도 신경을 써야 한다.  적절한 툴이 없기 때문에 User들이 local data를 편집하거나 권한을 업그레이드하기는 어렵지만, 중앙 서버가 데이타 조작 자체를 방지할 방법은 없다. User에게 JavaScript를 변경할 수 있도록 허용함에 따라 데이타베이스 자체가 변경될 수 있는 Security Hole도 존재한다. Local Data는 폭넓게 개방되어 있기 때문에 누구든지 Grassmonkey 스크립트나 Nativecode를 짜서 데이타를 변경할 수 있다.

4. Offline Apps Are Nightmare to Sync. 

HTML5 Local Data Storage로 인해 Web App.을 오프라인 상태에서 쓸 수 있게 되었다. 여기에서 유일한 문제는 Data Synchronization이다. 만약에 Web App.이 인터넷에 연결되어 있다면, 계속해서 데이타를 클라우드에 저장할 수 있다. 그러나 오프라인인 경우 변화가 항상 클라우드에 저장되지는 않는다.

만약에 누군가 브라우저를 변경하거나 다른 머신을 사용한다면, 복사본이 증식되어 데이타 동기화가 어려워 진다. 만약 시계가 불일치 할 경우 가장 최근에 저장된 데이타가 무엇인지를 판단하기 어렵기 때문에 문제가 더욱 심각해 진다. 물론 이러한 문제는 Native App.에서도 언제나 발생하지만 데이타 동기화의 책임 주체가 누구인지가 명확하다. 즉 사람이 파일네임과 날짜를 보고 Syncronization Trouble을 해결할 수 있다.

그러나 HTML5는 브라우저에 깊숙히 저장되어 있는 Database에 대한 통제권한을 User에게 허용하지 않기 때문에 개발자들은 동기화를 핸들링할 수 있는 User Interface를 제공해야만 한다. 이것은 완전히 통제할 수 없는 문제는 아니다. 프로그래머들은 Version Control System을 사용하여이 골칫거리를 관리하고자 한다.  이러한 문제들을 해결하기 위해 버전 관리 시스템은 더욱 정교해지고 있다. 그러나 테크놀로지가 존재한다고 해서 그것이 개발자들이 쉽게 사용할 수 있는 솔루션이라는 의미는 아니다. 다양한 GIT 레포지터리들을 머징하는데는 시간이 필요하다. HTML5 Web App의 동기화를 관리하고자 한다면 HTML5 개발자들은 이러한 이슈들을 마스터해야만 한다.

5. The Could Ows You Nothing

데이타를 클라우드에 저장할때 구조적인 문제가 발생한다고 해서 HTML5를 비난하는 것은 온당치 않으나, Cloud는 HTML5가 꿈꾸는 비전의 근본적인 부분이다. HTML5는 클라이언트 소프트웨어의 설치 및 데이타 백업 등 모든 골칫거리를 해결하기 위해 클라우드를 적극 활용하고 있다 (leverages the cloud to fix all of the headaches for installing software and backing up data).

HTML5 Local Data Storage의 한계가 존재하는 상황에서 대용량 Storage가 필요한 Web App Data (The bulk of Web app data storage)를 서버에 맡기는 방식으로 접근할 경우 파괴적인 결과가 나올 수도 있다. 최근에 Facebook은 사진을 업로드하는데 사용했던 Linux 기반의 플러그인을 제거하기로 결정했다. 최고 전문가들의 면밀한 검토가 있은 후 플러그인은 제거되었으나, 이 플러그인을 사용하여 업로드된 모든 사진들도 함께 사라졌다(With a wave of the caliph’s hand, the plug-in was gone, along with all of the photos that were uploaded using it).

이러한 스토리들은 일반적이진 않으나 어떤 이유로 점점 더 자주 발생하고 있다. HTML5 App.으로 모든 것을 무료로 제공하겠다고 약속하는 소규모 Web Start-Up들에게나 이런 문제가 몇 달 또는 몇년 후에 발생할까? 아마도 이렇게 생각하는 편이 편할 것이다. 이 문제는 점점 더 악화되고 있다.

많은 Web App.들이 이용약관에서 명확히 하고 있듯이, 데이타는 User들의 것이 아니다. 오히려 대부분의 경우 User들에게는 데이타의 복구를 요청할 수 있는 법적인 수단이 존재하지 않는다. 심지어 데이타가 아무런 이유없이 삭제될 수 있다는 것을 강제하는 보다 뻔뻔스러운 이용약관도  존재한다.

HTML5는 어떤 방식으로든 이 문제의 해결을 회피할 뿐만 아니라 구조적으로 당신의 브라우저에 캐쉬되어 있는 모든 로칼 데이타는 클라우드에 저장되도록 되어 있기 때문에 User들은 이것에 접근할 수도 없고 통제할 수도 없다. HTML5 예찬론자들은 이것을 기능이라고 부르고 있으나 오히려 자신의 모델과 상충되기 쉽다.

6. Forced upgrades aren’t for everyone

어떤 사람이 바에서 만난 사람들과의 Casual Relationship을 위해 가끔씩 Gmail로 연락을 주고 받곤 했는데, Google+ 출시 후에 이런 사람들과의 오래된 기억들이 홍수처럼 밀려오는 경험을 한 적이 있다. Google+는 이런 낡은 주소들을 Discussion Forum에 연결시키기 때문이다. 매일 오래전에 잊혀진 사람들의 이름과 얼굴이 나타나서 써클로 분류하라는 것이다. (클라이언트 업그레이드 없이도 웹을 통해 훨씬 편리하게 새로운 서비스를 출시할 수 있지만, 고객이 원하지 않는 방식으로 웹업데이트가 이루어질 수 있다는 의미)

Web App.을 업그레이드할 필요가 있을 때 그것은 모든 사람에게 동시에 적용되어야 한다. Web App.을 사용하면 User들이 소프트웨어를 굳이 인스톨할 필요가 없긴 하지만 새로 추가된 기능을 원하지 않는 User들에겐 이것이 악몽일 수도 있다. 새로운 소프트웨어는 낡은 기능들에 의존하는 다른 패키지들과 충돌을 일으킬 수도 있다.

7. Web Workers offer no prioritization

Web Wokrers는 HTML5에 추가된 좀더 매력적인 기능이다. Web 개발자들은 묵직한 JavaScrip의wait, delay, pause commands에 의존하기 보다는 코드들을 쪼개고 CPU hogs를 Web Workers로 분리시킬 수 있게 되었다. 다시 말해 HTML5 Web Workers로 인해 브라우저가 보다 OS처럼 동작할 수 있게 되었다.

그러나 불행하게도 Web Workers는 OS의 모든 기능을 복제해서 가지고 있지는 않다. Web Workers는 워크로드를 포크(fork)하고 분리해서 처리할 수 있는 방식을 제공하고 있기는 하지만, 워크로드를 효과적으로 관리하거나 우선순위를 정하는 방법은 전혀 없다. API를 사용하면 메시지를 Worker Object로 입력하거나 출력해줄 뿐이다 (The API just allows messages to be passed into and out of Worker objects). 이것이 전부이다. 나머지는 브라우저가 알아서 처리해야 한다.

만약 CPU 자원을 많이 잡아먹는 code-cracker와 같은 어플리케이션이 인기 웹사이트의 백그라운드에서 몰래 동작한다면 어떻게 될까? User들이 웹사이트의 Cycle-Stealing도 할 수 있지 않을까 ? Malware는 이미 유용한 소프트웨어에 편승하고 있기 때문에, Web Worker의 기능적 약점이 악용되는 것은 시간 문제이다.

Worker Object가 생성되거나 그것이 무엇을 하는지 트래킹할 수 없기 때문에 User들은 이러한 Malware에 대해 아무것도 할 수 없다.  Malware의 공격대상인 특정 웹페이지에 접속한 후 그들의 컴퓨터가 느려지는 현상을 경험할 뿐이다.

8. Format incompatibilities abound

HTML5는 <audio> <video> 태그를 도입,  이미지 태그처럼 쉽게 사용할 수 있고 브라우저가 데이타를 스트림해 주게 될 것이라고 자랑해 왔다. 그러나 이것이 그렇게 쉽다면 왜 내가 모든 메이저 브라우저에서 동작하는 기본 오디오 파일을 찾는데 2주나 소모했을까? 이것은 HTML5의 잘못이라기 보다는 브라우저 개발자들이 모든 오디오, 비디오 포맷을 지원하지 않기로 결정했기 때문이다.

사람들은 인간이고 인간은  지배를 위해 싸운다. 그러나 개발자들은 어떤 브라우저에서 완벽하게 동작하는 파일이 다른 브라우저에서는 동작하지 않을 때 이 문제를 다뤄야만 한다. 이것을 어떻게 테스트할까? API 개발자들은 canPlayType이라는 함수를 개발할 정도로 충분히 스마트했지만, 이것조차도 모든 브라우저가 지원하는 것은 아니다.

9. Implementations are browser-dependent

HTML5가 꿈꾸는 이상은 그것을 구현해야하는 지저분한 현실과는 큰 갭이 존재한다. 프로그래머들은 최선을 다해 아키텍트의 꿈을 실현하고자 하나 어떤 태그와 오브젝트들은 잘 동작하지 않는다. 예를 들어 HTML5의 Geo Location API와 같이 작동하지 않는 것들이 많이 있다. geolocation API는 Privacy 보호와 정확성에 대한 통제수단을 제공한다. 이것이 지속적으로 잘 동작할 때 조차도 어떤 브라우저에서는 타임아웃이 걸린다. 심지어 Desktop에서는 GPS가 존재하지 않는다는 것을 알고 있을 때 조차도 그렇다.

궁극적으로 이것은 API 자체의 구조적 문제에 대한 불만이라기 보다는 브라우저가 특정 기능이 일관성있게 동작하도록 지원하지 못하고 있다는 사실에 대한 불만이다. 웹 개발자들이 HTML5 기반 Web App의 이상을 Reality로 만들고자 할 때 브라우저 의존적인 문제점들에 직면하게 된다는 것이 냉혹한 진실이다 (This hard truth highlights the browser-dependent challenges that Web developers face in making the HTML5-based Web app nirvana a reality).

10. Hardware idiosyncracies bring new challenges

몇몇 브라우저 개발자들이 성능 개선을 위해 원래 스펙 이상을 구현했거나 덜 구현했다고 해서 불평하는 것은 불공평하지만, 아무리 좋게 개선했다 하더라도 부작용이 따르기 마련이다 (no good deed goes unpunished).

MS는 low-level의 hardware driver들과 그것을 통합시킴으로써 IE 브라우저의 Canvas Object의 Performance를 개선하는 위대한 일을 했다. MS는 이것을 과시하기 위해 pirateslovedaisies.com과  같은 게임들을 지원하기도 했다.

이제 프로그래머들은 이러한 새로운 기능을 사용할 수 있는지의 여부에 대해 면밀히 살펴 보아야 하겠지만 우리가 짠 코드가 얼마나 빨리 동작하는지를  확인할 방법이 명확하지는 않다.

예를 들어 pirateslovedaisies.com의 디자이너들은 IE가 제공하는 기능들을 킬지 끌지를 스위치로 선택할 수 있게 만들었다. 이러한 추가 기능들을 짐작해서 사용할 수 있는 API가 현실적으로 존재하지 않는다.  가장 간단한 방법은 브라우저 네임별로 테스트를 진행하고 Frame Rate를 측정하는 것이다.  나는 많은 Native Game 개발자들이 수년동안 폭넓은 범위의 하드웨어를 다루어 온 것을 잘 알고 있다. 여기서 유일한 솔루션은 혁신을 금지하는 것이지만 그렇게 된다 하더라도 웹 개발자들은 이런 상황에 적응해야만 할 것이다.

11. Policitcs As Usual

어떤 사람들은 Ian Hickson이 HTML5 표준의 창시자 (main drafter of HTML5 standards)라고 부르지만, 이것은 농담에 불과하다. Standard Wirter들은 제안을 할 뿐이고 실질적인 결정은 브라우저 회사의 코딩 천재들이 내린다. 그들이 어떤 기능을 구현할지 구현하지 말지 선택하면 웹 개발자들은 결과가 안정적인지 결정을 내린다. 그리고 몇년 후 표준 자체가 구현된 결과에 맞게 변경되는 일도 종종 발생한다.

많은 JavaScript 개발자들은 호환성의 문제를 jQuery와 같은 라이브러리를 생성한 사람들에게 떠 넘긴다. 이런 Layer들로 인해 우리는 브라우저간 차이(cross-browser differences)에 대해 크게 개의치 않고 지나가지만, 이러한 차이가 미래에도 별 문제가 안될지에 대해서는 지켜봐야 할 것이다.

이러한 이슈들은 브라우저 업계의 근본적인 문제이다. 우리같은 웹 개발자들은 브라우저간 치열한 생존경쟁의 결과로 탄생하는 풍요로운 기능과 자유, 창의성을 원한다. 브라우저 개발자들이 앞서 나가기 위해 앞다투어 새로운 기능들을 개발함에 따라 혁신의 속도가 빨라지고 있으나 대신 브라우저간 차이가 점점 더 커지고 있다.

그러나 우리는 중앙에서  플랫폼을 통제하는 독재자가 제공하는 안정성도 원한다. 세계는 권위주의와 민주주의간 전쟁을 해결하기 위한 이상적인 솔루션을 아직도 찾지 못하고 있다. 차이로 인해 발생하는 골칫거리에 대해 불평하기 보다는 하원 (House of Commons)에서 다음과 같이 연설한 윈스턴 처칠의 태도를 취하는 것이 더 나을 것이다. “실제로 사람들은 민주주의가 지금까지 때때로 시도되었던 다른 모든 체제를 제외하고  가장 나쁜 지배의 형식이다 ( “Indeed, it has been said that democracy is the worst form of government except all those other forms that have been tried from time to time.”)

Written by abulaphia

August 23, 2011 at 3:59 pm

%d bloggers like this: