오늘 트위터 타임라인을 보다가 임정욱님(@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%가 웹을 지지하는데, 저는 아직은 앱이 있으면 무조건 앱을 선호합니다. 돈을 약간 내야 하더라도 말입니다. 속도가 빠르다는 것이 주된 이유이지요.
조성문의 블로그 
형^^ 글 잘 읽었습니다.
역시 기술적인 부분을 잘 아시는 형께서 설명해 주시니까 이해가 더 수월하네요!
응 영진아. 일단 생각나는 것부터 정리해 보았는데, 좀 더 생각해보면 자세히 파고들어 생각해볼만한 내용이 많은 것 같아. 더 기술적으로 API 얘기를 해볼까 했으나 너무 깊이 들어가는 것 같아서 여기까지. ^^
전에 저도 Business Week에서 본 내용인데 굉장히 흥미로왔습니다.
애플과 구글이 다투는 것도 앱대 왭이고…
애플은 모바일에선 앱이 광고 효과가 있다고 하고 구글은 여전히 50%이상의 모바일 검색이 구글을 통해서 이루어 진다고 하고 점점 대립 관계가 고착 되는 듯 싶더군요.
뭐 구글이야 앱이됬던 웹이 됬던 상관없이 무난하게 1위 자지를 수성하겠지만 말이죠. 이 와중에 불쌍한건 마소….
Businessweek의 기사 저도 읽어봐야겠습니다. 모바일 앱에서 확실히 광고 효과가 있습니다. 모바일 웹의 광고는 보기 싫으니 옆으로 치워버리면 그만이지요. 앱에서는 치우고 싶어도 치울 수가 없으니까… 그러고보니 그것도 비교해볼만한 주제였는데 제가 놓쳤네요. 감사합니다.
Business Week 1월표지중에서 apple vs. Google 로 찾아보시면 될겁니다
앱이 웹보다 빠른 것은 당연합니다. 다만, 요즘 웹의 진화 못지 않게 모바일웹의 약진도 눈여겨 볼만합니다. 그리고, 웹브라우저들이 좀더 분발한다면 모바일 웹도 걸음마 수준을 넘어설 것입니다. 아직은, 모바일 디바이스용의 웹브라우저가 나오지 않았다고 보아야 하겠지요.
안드로이드가 버전별로 분산되어 있고, 아이폰도 3G, 3Gs, 4G 로 넘어가면서 지속적으로 버전이 산포됩니다. 따라서, 앱은 가장 최신의 버전을 기준으로 만들어지고 유포되고, 나머지 버전과 기기에 대해서는 모바일 웹으로 가는 것이 모바일 산업 전체를 그려보았을때 맞는 그림이 될 것입니다.
말씀하신대로 요즘 모바일 웹의 약진이 눈에 띕니다. 과거에 비교하면 놀랄만큼 발전했지만, 아직 네이티브 앱과 비교하면 차이가 많이 있지요. 아이폰 버전이 분화되고 Android 버전이 분화되면서 거기에 맞는 최적의 개발 프레임워크가 등장하게 되겠네요..
웹이냐 앱이냐는 이분론적 분석이나 전망과 달리, 웹앱이나 앱웹 같은 형태로 서로의 장점을 수용해가면서 구분하기 힘든 형태로 발전할꺼 같네요. 이건 마치 메인프레임이냐 PC냐 같은 논쟁 같습니다. 역사는 반복되고 그때 그때 기술과 비즈니스 필요에 의해서 형태는 달라져왔죠, 아무튼 중요한 점은 인간에게 컴퓨팅 파워라는 서비스를 제공했다는 점이겠구요. 웹이냐 앱이냐는 것은 기존 하드웨어의 집중화/분산화 문제를 사용자 관점으로 가져온 것 같습니다. 사실 기업에서도 배포나 업데이트의 문제 때문에 항상 고민하는 부분인데… 결국 끊임없이 새로운 기술이 경쟁하며 새로운 형태를 선보이게 되겠죠. 중요한 점은 역시 사용자가 원하는 서비스를 누가 더 쉽고, 강력하고, 저렴하게 제공할 수 있느냐 아닐까요?
정말 좋은 지적입니다. 이분론적으로 분석하거나 전망할 필요는 없다고 봅니다. 컴퓨터에서도, 브라우저에서 하는 것이 편한 것이 있고, 네이티브 앱을 설치해서 사용해야 편한 것이 있으니까요. 점점 더 많은 앱이 브라우저로 옮겨가고 있는 것은 사실이지만 말입니다.
혹시 Shadows Apartments에 사시나요? ^^ 예전에 거기 살았었는데-
오옷, SH님 반갑습니다. 🙂 지금 Shadows에서 살고 있습니다. 깔끔하고 manage가 잘 되고 있는 곳이라 좋아요. 전에 거기 살 때 어디서 일하셨었나요?
석사학위시절 stanford 다닐 때 살았었죠(Apt21) 근처 골프장에도 자주 갔었는데^^ 조용하고 safeway 가까워서 좋았던 기억이 납니다.
앱은 완전히 사라지지 않겠지만, 결국은 많은 부분은 웹으로 이동할것이 뻔하다는 생각입니다. 심지어는 앱이라 할지라도 XML의 API통신은 결국 웹기술을 이용할겁니다. 그편이 다양한 기계에 적용이 가능한 이유도 있죠. 개발적인 측면에서 비즈니스로직(서비스)과 프리젠테이션(단말)가 분리되는 SOA사상이 여기에 해당됩니다.
기술적인 배경으로는 네트워크속도와 H/W의 속도는 훨씬 상회하기 때문이죠. 어플리케이션을 개발할 환경의 인프라를 갖추는것이 HTML5구요.
대신 앱스토어의 유료모델은 웹에도 유효한 방식이 등장하지 않을까 합니다. 이른바 웹스토어개념이죠.
결국은 구글이 원하는데로 흘러갈 가능성이 높아보입니다.
숲속얘기님, 항상 좋은 comment 감사합니다. 말씀하신대로 presentation은 XML로 만들고, business logic은 Java 등을 이용해서 만드는 모델이 앞으로 더 널리 채용될 것 같습니다. 실제로 Android app을 개발해보면 UI를 XML로 짜기 쉽게 Eclipse에서 툴이 제공되고 있구요. 이른바 MVC (Model, View, Controller) 모델이지요.
웹스토어는 Google IO에서 보았는데, 상당히 재미있는 컨셉인데 유료화 적용하기가 얼마나 쉬울지는 잘 모르겠습니다. Native App을 돈내고 쓰는 것은 이제 익숙해 졌지만 (수년이 걸렸지요), Web App을 돈내고 쓰는 것에는 (물론 사례는 많이 있습니다만) 아직 익숙하지 않으니까요. 차차 방법을 찾아가게 되겠지요.
트랙백을 남기고 싶었는데.. 기능이 없네요.
http://blog.naver.com/fstory97/70084130830
http://blog.naver.com/fstory97/70074821366
이제야 읽어봤네요. 감사합니다. 트랙백 키능은 켜놨는데 왜 안되는지.. 잘 모르겠네요. 다시 한 번 살펴봐야겠어요.
내 의견은 짐작하겠지만 it is all about the WEB! Web is much more scalable and App is not. 특히 HTML5의 시대가 오면서 더 그럴 것이라고 믿어. BTW, 화면 캡쳐하느라 고생했다. 🙂
구글 덕분에 웹이 생각보다 빠르게 더욱 강력해지고 있네요. 특히 TV 플랫폼이 본격화되고 나면 더 그럴 것 같아요. 캡쳐하느라 시간 좀 썼습니다. 🙂 한국 일본 출장 잘 마치고 돌아오시길. 오면 파티 멋지게 함 해야죠.
저도 아이팻에서는 웹에 한 표! ㅋㅋ
지금은 앱이 편하다는 것에 동감, 하지만 웹이 점차 모바일 환경에 맞춰 진화할 것 같아요.
아이팻 잘 쓰고 있나보구나. 🙂 지금은 확실히 앱이 편하지. 웹이 진화해가는 것을 보면 정말 재미있어.
대세가 웹이라는 분들이 많은데 과문한 저로서는 공감이 잘 안가고 앱의 우세가 상당히 지속할 거라 생각합니다. 물론 아이폰과 아이패드가 차이가 있을 것입니다만…
혹시 ‘웹으로 귀결될 것’이라는 판단에는 다음과 같은 경험을 전제로한 건 아닐까요? 즉, PC의 응용어플리케이션에서 웹으로 진화된 것 말이죠. 그런데 이 때에는 프레드 윌슨의 첫번째 근거, 통일된 환경의 편리함, 즉 새로이 익히거나 배울 필요 없는 장점이 있다는 점도 있었지만 더 중요하게는 PC내의 자원(물리적 자원이나 정보모두)에 근거하던 것이 인터넷, 즉 클라우드로 전환되면서 자연스럽게 웹으로 귀결된 것으로 보아야 하지 않나 합니다. 만일 이것이 근본적이었다면 앱과 웹을 비교할 때 웹 편에서의 이런 장점은 없어집니다. 이건 모바일 환경에서는 앱도 웹과 마찬가지 구조이기 때문이죠.
그렇다면 남는 것은 사용자 편의성인데 이 측면에서는 역설적이게도 웹보다는 앱이 앞으로도 우위가 계속될 것입니다. PC시대에는 웹으로 수렴되는 것이 사람들에게 익숙하게 느껴졌겠지만 모바일 시대에는 웹과 같은 획일성보다는 오히려 디바이스의 크기나 그 디바이스가 제공하는 UI의 특성, 나아가서는 특정 응용물의 고유한 UI 특성을 반영한 앱의 UX가 훨씬 유리할 수 밖에 없을 겁니다.목적성을 따라가다 보니 자연스럽게 다양성을 가지게 되는 것이죠.
만일 웹으로 귀결되는 것의 장점을 사용자 측면이 아니라 공급자의 측면, 예를 들어 디바이스, OS 등 다양해지는 (개발)환경의 복잡성 때문에 웹으로 귀결될 것이라고 본다면 그것은 본말이 전도된 것이죠. 사용자는 디바이스나 OS 신경 안쓸 겁니다. 왜냐면 앱을 만들면서 알아서 맞추어 줄 수 밖에 없을 테니까요. 안타깝게도 웹만 만들려고하는 어떤 공급자가 좀 지나면 어쩔 수 없이 앱버전도 만들어야만 하는 사정이 될 수 있을지도,,, 공급자(개발자)의 입장에서 갑갑한 상황이지만 이건 어쩔 수 없는 일이 되지 않을까…
유료냐 아니냐는 별로 기준이 못될 것 같고, 구글 검색이 안된다? 모 이 문제는 본질은 아닌 듯, 사용자는 구글 검색이 되는지 안되는지 관심 없겠죠…
그리고 아이패드가 나오면서 웹쪽이 유리해 보이는 측면이 있지만 모 이것도 워낙 그동안 만들어져 있는 모든 정보가 웹을 기반으로 하고 있기 때문에 기존 정보자원을 활용하는데 웹방식이 유리하겠죠. 하지만 앞으로도 그리되리라는 보장은 없지 않나 싶습니다. 정보자원이라는 것은 클라우드 환경에서 다른 방식으로 축적되고 이용될 수도 있을 것이기 때문에, 예를 들어 유뷰브가 모바일 시대에 시작되었다면 웹을 베이스로 서비스 시작하지 않고 걍 모바일 디바이스에 최적화된 UI로 서비스를 시작하지 않았을까요? 전자책의 경우도 그렇고…
어찌보면 모바일에서는 그 기기 자체가 PC상의 웹으로 보는 것이 더 적절한 대비가 아닐까요. 이건 이미 웹만큼 통일 되기는 약간 글렀죠. 기기는 브랜드별로 어차피 경쟁적으로 만들 거니까요. 아이패드가 좋으면 그와 유사하게 따라가기야 하겠지만…
여하튼 웹으로 귀결될 것이라는 것에 많은 의문을 가진 사람은 소수자이니만큼 제가 무슨 생각을 잘 못하고 있나 숙고는 해 보고 있습니다. 앞으로 전개될 것도 지켜보면서 말이죠. HTML5가 정말 좋아지면 접어야 하는 주장일런지는 모르겠지만 서도… 하여튼 성문님 글은 언제나 구체적이고 실증적이어서 좋습니다. 잘 보고 갑니다.
5년이 지난 지금 대세는 님의 의견대로 앱으로 흘러가고 있습니다. 여러 지표에서 사용시간, 선호도 등등에서 앱이 웹을 능가하고 있네요. 아직까지는 현재진행형이지만요, 님의 혜안에 작은 글이라도 남기고 갑니다.
네이티브 앱의 경우 아래에서 네 번째 단계에 있는 “Transport Layer”를 통해 정보를 전송한다. -> 이 지적은 적철치 않은 것 같습니다.
앱이든 웹이든 TCP( trasport layer ) 프로토콜은 공히 이용되며 Application layer의 프로토콜이 앱방식( 앱전용 )이냐 웹방식(HTML)이냐의 차이 같습니다.
앱을 개발해 본적은 없지만 예전 client/server 환경을 생각해보면 서버와 클라이언트간의 메세지는 개발자가 최적화 할 수 있기 때문에 HTML 보다는 훨씬 부하가 적었죠.
지적 감사합니다. 말씀하신대로 앱이든 웹이든 공히 TCP 프로토콜을 사용합니다. 앱의 경우 서버-클라이언트 사이 메시지를 개발자가 최적화할 수 있고, 심지어 압축도 할 수 있기 때문에 주고받는 패킷량이 훨씬 적지요. 전에 모바일 네트워크 게임 만들 때 패킷량이 최소화되도록 많이 신경썼던 기억이 납니다. 당시에는 데이터 사용료가 무지 비쌌거든요.