오늘 트위터 타임라인을 보다가 임정욱님(@estima7)의 다음과 같은 글을 발견했다.
아이패드 전용 콘텐츠앱보다 사파리로 보는 것을 더 선호한다는 유명블로거 프레드윌슨의 포스팅 http://bit.ly/daFgKP
프레드 윌슨이 최근 아이패드 애플리케이션을 출시한 후 첫날 24,000부를 팔아 화제가 된 Wired 앱을 사용해 본 후 올린 리뷰이다. 왜 아이패드 전용 앱보다 아이패드에서 사파리로 읽는 것을 좋아하는가에 대해 8가지 이유를 들어 설명하고 있다. 몇 가지 눈에 띄는 주장은 다음과 같다.
i don’t like the various different user interfaces i have to get to know. i am used to the web browser interface. i know where everything is. if there was one standard magazine app UI and one standard newspaper app UI, i might feel differently. but for now, i can’t be bothered learning a new UI for every piece of content i want to consume. (나는 매번 새로운 유저 인터페이스를 배워야 한다는 것이 싫다. 웹에서는 어떤 메뉴가 어디에 있는지 이미 알고 있다.)
web is free, apps are often paid. it’s not really about the actual money to me. it is about the transactional overhead and the principal of it. why would i pay for something i can get for free? (웹은 공짜지면 앱은 종종 돈을 내야 이용할 수 있다. 돈 내는거야 상관 없지만 왜 공짜로 볼 수 있는 것에 내가 돈을 지불해야 하는가?)
you can’t search content apps for what you are looking for with google. (애플리케이션들은 구글에서 검색이 안된다.)
나름 일리가 있는 말이다. 나도 이 주제에 대해 요즘 많이 생각해보고 있다. 특히 아이패드를 사용하기 시작하면서부터이다. 아이폰, 안드로이드폰 등의 스마트폰에서는 사실 답이 명확했다. 화면이 작기 때문에 앱(App)을 선호하는 것이 당연하다. 브라우저를 이용해서 어떤 페이지든 볼 수 있지만 가끔 플래시(Flash)가 지원 안되어 불편할 때도 있고, 글자가 작게 나오므로 자꾸 확대/축소하다보면 귀찮고, 또 무엇보다 항상 페이지 전체를 로드하기 때문에 전용 앱에 비해 웹 브라우징은 항상 시간이 많이 걸린다. 실제로 어떻게 다를까? 이를 알아보기 위해 1:1 비교를 해보았다.
| 아이폰 전용 애플리케이션 | 웹 페이지 | |
|---|---|---|
| 뉴욕 타임즈 |    |
   |
| 빠른 로딩(3초). 글자가 크다. 아래 툴박스가 있어서 “최근 기사”, “인기 있는 기사”, “저장된 기사”, “검색” 등의 메뉴에 바로 접근할 수 있다. 마음에 드는 기사를 저장해둘 수 있다. 화면이 아이폰에 최적화되어있기 때문에 확대와 축소를 반복할 필요가 없다. | 우선, 광고를 포함해서 페이지 전체를 로드해야하기 때문에 Wifi에서도 10초 가량의 시간이 걸린다. 게다가 브라우저의 렌더링(rendering) 속도에도 병목이 있다. 마음에 드는 기사를 저장해두는 기능이 없다. 비디오의 경우 클릭하면 전체 화면으로 전환된다. 마음에 드는 기사를 찾아 읽기 위해 확대와 축소를 반복해야 한다. | |
| IMDB (영화 정보 사이트) |     |
    |
| 처음 시작하면 현재 위치에서 가장 가까운 극장 정보를 주기 위해 현재 위치 정보를 이용하겠느냐고 물어본다. 화면에 불필요한 광고가 없다. UI는 320×480 크기의 화면에 최적화되어 있다. 사진을 보는 화면이 마음에 든다. 사진을 아주 빠르게 불러오고, 클릭하면 전체 화면으로 볼 수 있다. | 일단, 로딩이 느리다. 플래시로 된 광고가 위와 오른쪽에 있는데, 크기가 작아서 광고 효과가 별로 없고 불편함만 준다. 마찬가지로 사진을 보는 화면이 있기는 하지만 느린데다가 사진을 클릭해도 전체 화면으로 보이지 않는다. 두 손가락을 써서 사진을 확대해야만 한다. | |
| 구글 맵 |   |
   |
| 속도가 빠르고 군더더기 없이 깔끔하다. 특히 두 번째 스크린의 메뉴 인터페이스가 정말 마음에 든다. | 웹 버전 역시 GPS를 사용한 현재 위치를 알아낼 수 있다. 성능도 꽤 좋다. 애플리케이션으로 하던 것들을 대부분 할 수 있다. 주소 자동 완성도 된다. 심지어 두 손가락을 사용해서 지도를 확대하고 축소할 수도 있다. 네이티브 앱(native application)만큼은 아니지만 이정도라면 웹 버전을 사용할 수도 있겠다는 생각이 든다. | |
| 페이스북(Facebook) |     |
    |
| 두번째 사진에서 보이는 빠른 액세스 메뉴를 사용하면 많이 사용하는 중요한 기능 (새로운 피드, 프로필, 친구 정보, 편지함 등) 에 곧바로 접근할 수 있다. 특히 사진 보기 화면이 마음에 든다. 아주 빠르게 사진 데이터를 불러온다. | 페이스북 원래 페이지가 아닌 모바일 화면에 최적화된 페이지이다. 아이디와 암호를 한 번 입력하면 그 다음부터는 저장이 되어 있어 다시 입력할 필요가 없다. 네이티브 앱에서 할 수 있었던 것들을 거의 동일하게 할 수 있지만, 여전히 속도는 그에 비해 느리다. | |
| 블룸버그 (Bloomberg) |   |
   |
| 툴바 메뉴를 이용해서 News, Markets, My Stocks, Stock Finder 등의 메뉴에 곧바로 접근할 수 있다. 특히 주식 그래프가 아주 마음에 든다. 화면 가득 크게 나오는데다, 하루, 한달, 6개월, 1년, 5년동안의 주가 변화 그래프 사이를 아주 빠르게 전환할 수 있다. | 네이티브 애플리케이션과 비슷한 정보와 경험을 제공하지만, 앞서 다른 예와 마찬가지로 로딩이 느리다. 네이티브 앱과는 달리 주가 정보를 하루, 6개월, 1년 등의 다양한 스케일로 볼 수 있는 기능이 없다. | |
| 날씨 채널 (The Weather Channel) |     |
    |
| 아이폰에 최적환 버튼들이 있어 섹션과 섹션을 아주 쉽고 빠르게 왔다갔다할 수 있다. 맵 뷰(map view)는 직관적이고 빠르다. 손가락으로 쉽게 지도를 확대/축소하고 조작할 수 있다. | 맵 뷰(map view)의 경우, 확대/축소하는 기능이 없어 불편하다. 지도에서 이동할 수는 있지만 네이티브 앱만큼 직관적이지는 않다. | |
| 아바타(Avatar) 게임 |  |
|
| OpenGL 라이브러리를 사용한 멋진 3D게임이다. | 이러한 성능의 게임을 웹에서 구현할 수 있는 방법은 현재로서는 없다. |
그런데, 아이패드가 나오면서 상황이 달라졌다. 무엇보다, 페이지 전체를 한 눈에 볼 수 있기 때문에 두 손가락을 이용해서 화면을 확대했다 축소했다 하며 시간을 보낼 필요가 없어졌다. 게다가 웹페이지에 있는 비디오를 화면 전환 없이 바로 재생할 수 있고, 비디오가 나오는 상태에서 화면을 돌리고, 확대하고 축소할 수 있기 때문에 사파리로 컨텐트를 보아도 별다른 불편이 없다. 아래에 아이패드 앱과 웹 페이지를 비교했다.
| 이름 | 아이패드 앱(Native Applications) | 웹 페이지(Web Applications) |
|---|---|---|
| 뉴욕 타임즈 |  |
 |
| IMDB |  |
 |
아이패드에서도 여전히 웹보다는 아이패드용 앱을 사용하는 것이 더 편한 것은 사실이지만, 애플리케이션을 설치하지 않고 그냥 사파리로 보아도 큰 차이는 없겠다는 생각이 든다. 그럼에도 불구하고 웹의 한계는 여전히 존재한다. 가장 큰 한계는 속도이다. 앱에서는 아이패드에 이미 최적화된, 필요한 컨텐트만 서버에서 바로 받아와 화면에 그리면 되지만, 원래 데스크탑을 목표로 해서 만들어진 웹페이지는 로딩에 시간이 많이 걸린다. 최근에는 많은 경우 클라이언트에 따라 다른 정보를 전송하기는 한다. 그럼에도 불구하고, forward와 backward를 반복하다보면 확실히 앱에 비해 시간이 많이 걸리는 것은 사실이다. 왜 그런 차이가 있을까? 이를 설명하는 한 가지 방법은 OSI Layer를 살펴보는 것이다. 다음 그림을 보자.
네이티브 앱의 경우 아래에서 네 번째 단계에 있는 “Transport Layer”를 통해 정보를 전송한다. 하지만 웹의 규약인 HTTP 프로토콜은 가장 윗단계인 “Application Layer”를 통해 정보를 전송한다. 그만큼 전송해야 할 정보가 많아질 수밖에 없다. 게다가 HTTP는 매번 페이지를 로드할 때마다 접속했다가 접속을 끊는데, 이렇게 연결을 설정하고 해제하는데 시간이 상당히 많이 걸린다. 여기에 또 한가지 성능에 영향을 미치는 것이 화면에 그리는 속도이다. 브라우저가 화면에 표현하는 속도는 웹킷(WebKit)과 자바스크립트 엔진의 성능에 의존하는데, 아직 네이티브 애플리케이션에 비해 속도가 느리다.
두 번째 한계는 사용자 인터페이스이다. 예를 들면 웹 애플리케이션의 경우 두 손가락 또는 그 이상을 사용하는 멀티 터치를 지원하지 않거나 지원하더라도 웹페이지 자체를 스크롤하는 기능과 섞여서 조작이 다소 불편하다. 또 하나는 롱 클릭(long click)인데, 예를 들어, 아마존 킨들(Amazon Kindle) 앱의 경우 단어를 길게 누르고 있으면 노트를 입력하거나 하이라이트할 수 있는 메뉴가 뜨지만, 웹 기반에서는 길게 누르고 있으면 브라우저가 디폴트로 제공하는 “Copy”라는 메뉴가 뜰 뿐이고, 개발자가 이걸 바꿀 수 없다.
| 네이티브 애플리케이션(아마존 킨들)에서 단어를 오랫동안 클릭하면 나타나는 컨텍스트(context) 메뉴 | 웹 브라우저에서 단어를 오래 클릭했을 때 나타나는 메뉴 (http://m.yahoo.com) |
|---|---|
 |
 |
세 번째로, 하드웨어 접근이다. 웹 페이지에서 GPS를 이용하여 현재 위치를 불러올 수는 있지만, 카메라를 시작시킨다든지, 컴파스 정보를 가져온다든지, 단말기에 저장된 사진을 불러온다든지 하는 것은 아직은 불가능하다. 많은 애플리케이션들이 이것을 사용하고 있기 때문에 그런 앱의 경우 웹으로는 동일한 경험을 제공해줄 수 없다.
하지만, 상황이 달라지고 있다. 웹의 한계를 극복하여 획기적인 변화를 가져오고 있는 것이 바로 HTML5의 등장이다. 이번에 Google I/O 2010에서 가장 크게 다룬 주제인데, 구글은 키노트에서 그동안 개발한 HTML5의 새로운 기술을 통해 웹의 미래를 보여주었다. 이에 대해서는 다음 편에서 설명해 보겠다.
업데이트: 그림으로 봐서는 웹이나 앱이나 사용자 경험(User Experience)이 비슷할 것이라고 생각될 수 있는데, 실제로 손에 잡고 사용해보면 차이가 큽니다. 해당 기기에 최적화되어 속도 빠르고 깔끔한 앱과는 달리 웹은 아무래도 좀 어수선하고 느린 경우가 많습니다. 모바일에 최적화된 웹페이지를 따로 제공하는 경우에는 좀 낫긴 합니다만, 여전히 아쉬운 부분은 ‘뒤로가기’버튼을 눌렀을 때의 경험입니다. 이미 읽은 페이지인데도 다시 불러오느라고 5초 가량을 기다리게 만듭니다. 그 시간이 참 지루하지요. 앱에서는 이미 캐시가 되어 있기 때문에 0.1초면 앞 페이지로 넘어갑니다.
업데이트: 블로그를 포스팅한 이후에 트위터에서 많은 분들이 이 주제에 대해 의견을 표해 주셨습니다. 여기에 그 일부를 게재합니다. 90%가 웹을 지지하는데, 저는 아직은 앱이 있으면 무조건 앱을 선호합니다. 돈을 약간 내야 하더라도 말입니다. 속도가 빠르다는 것이 주된 이유이지요.
조성문의 블로그 