abulaphiaa

Keep Yourself Social

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

17 Responses

Subscribe to comments with RSS.

  1. Great blog!! You should start many more. I love all the info provided. I will stay tuned🙂

    best socket wrenches

    September 12, 2011 at 3:19 am

  2. 실례지만 이 문서의 원문 링크를 알수 있을까요?
    ref 형태나 문서 초반에 추가 부탁드립니다.

    neocoin

    September 16, 2011 at 11:05 am

  3. 멋진 글이네요~~ 역시~ 우리의 주님이십니다

    Tahu Lee

    September 16, 2011 at 11:25 am

    • 타후 어케 찾아 왔네 ㅎㅎ

      abulaphia

      September 17, 2011 at 1:02 am

  4. 오~ 정말 코피를 흘리면서 쓰는 열정이 드러나는 글이군요… HTML5 App에 대한 개념이 팍팍 들어옴니다~~

    Yong-wook Cho

    September 16, 2011 at 11:59 am

  5. 번역 감사합니다. 고생하셨어요.
    오타 : 다른 하나는 이 데이타를 의미있게 만다는(만드는) 방식, 즉 우리의 HTML5 App입니다

    KTH는 요즘 너무 멋져요 …..

    webmadeup

    September 16, 2011 at 1:57 pm

    • 오타가 있었군요. 지적해 주셔서 감사합니다

      abulaphia

      September 17, 2011 at 12:59 am

  6. 궁금했던 HTML앱에 대해 개념이 확 돋네요. 페북으로 공유하겠습니다. 감사합니다.

    한정일

    September 16, 2011 at 10:09 pm

  7. […] HTML5 모바일의 App.의 대해부 […]

  8. 이런…. 정말 주님강림하셨습니다.

    장회수

    September 20, 2011 at 1:16 am

  9. 잘 정리해 주시고, 번역해 주셔서 감사히 읽고 갑니다.
    잘 모르는 부분은 좀 더 음미(?)하면서 보겠습니다. ^^

    jepiros2000

    September 20, 2011 at 9:28 am

  10. 잘 읽었습니당….감사합니다.

    김승현

    September 20, 2011 at 5:56 pm

  11. 좋은 번역 감사합니다. 그런데 아래 부분은 따옴표와 같이 고치는게 맞지 않을까요? (즉, HTML5가 프로젝트 수주에 좋다는 약간 시니컬한 의미 같은데요.. ^^)

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

    .

    cesia

    September 30, 2011 at 11:13 am

    • 아 그렇게 볼 수 있겠네요. 이거이 제가 정확히 이해 못하고 대충 이런 의미겠지라고 때려 맞췄서 한글로 쓴 건데 감사합니다..

      abulaphia

      September 30, 2011 at 11:37 pm

  12. 정말 감사합니다. 그동안 Native app 만으로 service 을 개발하는 것이 너무 힘들었습니다. 창업한 이후 혼자서 모든 것을 할 수 없는 문제 시간과 비용의 한계등으로 저희와 같은 작은 스타트 기업은 Cross Platform 이나 Hybrid 에 필연적으로 다가서야 했는데 개념 잡고 HTML5을 어떻게 시작하고 진행해야되는지 어려웠는데 이렇게 정리 해주시니 계획 세우는데 너무 큰 도움이 되네요. 도움 주신 정보로 무럭 무럭 능력을 키워야겠네요. 정말 감사합니다.

    Joohyun Oh

    July 9, 2012 at 12:18 am

    • HTML5 기반의 WebApp.이 Device Fragmentation 대처방안으로 각광을 받고 있긴 하지만,Native보다 더 쉽거나 손이 덜 가거나 하지는 않은 것 같습니다.

      게다가 단말 사이즈에 최적화하기 위해 Responsive하게 디자인할려면 더 많은 노하우가 필요한 것 같아요.

      만약 내부에 경험 많은 웹개발자나 디자이너가 있다면, 구현하고자 하는 서비스의 기능과 컨셉에 적합한 wordpress용 responsive web theme을 구입한 후 이것을 customizing하는 것도 나뿌지는 않은 것 같습니다.

      그러나 적합한 테마를 찾는 것 자체가 매우 어렵고, 많은 개발자들은 구입한 테마를 customizing하는 것에 대해 자신이 개발하는 것보다 부담스러워 하더라구요.

      어쨋든 님의 행운을 빕니다.

      abulaphia

      July 12, 2012 at 11:19 am

  13. […] HTML5 모바일 App.의 대해부 – 원문 : Anatomy of a HTML5 Mobile Application […]


Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s

%d bloggers like this: