[잡담] 웹앱은 무엇을 위한 대안인가

아이폰의 국내 도입이후에 비로소 모바일웹에 대한 폭발적인 관심이 일어났던 것은 이미 모두가 알고 있는 사실이니 긴 말하지 않아도 될 것 같다. 당시 웹 기술은 거의 브라우저에 대한 것들이 많았다. 해묵은 IE에 병적으로 집착하는 대다수 사용자들과 이른바 모던 브라우저라고 하는 새로운 브라우저간의 싸움만 지겹도록 반복될 뿐이었다. 이미 HTML4 규격은 10년이 넘어가는 시점이었고 이 때문에 웹표준을 제정하는 W3C에 대해서도 불만들이 많았다.

어쨌거나 이 모바일 웹에서 시작된 붐은 모바일이 되었든, 데스크톱이 되었든 그 플랫폼을 가리지 않고 웹 표준이라든지 최신 브라우저에 대한 관심을 새로운 국면으로 접어들게 하는 큰 한 방이 될 수 있었던 것이다. 웹 표준 준수나 비 IE 환경을 지원하는 것에 대해 인색했던 국내 포털들은 폭발적으로 증가하는 모바일 트래픽에 깜짝 놀라 부랴부랴 모바일 웹에 대한 지원을 서둘렀고 그에 따라 웹킷이나 게코 엔진에서 잘 동작하는 웹 페이지들이 하나 둘 늘어나기 시작했다.

그리고 덕분에 비 IE 사용자들은 데스크톱 버전의 페이지를 사용하기보다는 더 가볍고, 그들이 사용하는 브라우저에 더 잘 맞는 모바일용 웹 페이지를 데스크톱에서도 즐겨쓰게 되는 역전 현상도 많이 일었다. (…라고 썼지만 그리 붐은 일지 않았다.)

어쨌든 그 즈음에 우리나라나 외국이나 할 것 없이, 웹 플랫폼을 사용하여 앱을 만드는 일에 대해 포탈들은 관심을 갖기 시작한다. 그도 그럴 것이 스마트폰 사용자는 계속해서 엄청나게 증가하는데, 이들을 위해 포탈의 서비스를 앱으로 제공할 필요가 있었기 때문이다. 물론 이런 앱을 통한 유입보다는 모바일 웹 브라우저를 통한 유입이 더욱 의미가 있던 포탈에서는 “웹 앱”을 밀고 나서고자 하는 그런 움직임들이 있었고, 당시에 유행처럼 일어나던 모바일 트렌드 컨퍼런스에서는 주로 이런 포탈에서 일하는 분들이 웹 앱의 가능성에 대해 거의 약 파는 수준으로 설파하고 다니기도 했다.

때마침, W3C의 굼뜬 행보를 참다참다 참을 수 없었던 브라우저 제작사들은 HTML5에 대한 논의를 먼저 시작한다. 그러니가 대략의 아웃라인에 대해 브라우저 제작사들이 먼저 기술적으로 구현을 하고 그에 맞춰서 웹 표준을 정하든가 말든가하는 그런 움직임들이 일어나는 것이다. 웹 브라우저에서 충분히 풍부한 미디어나 상호작용을 다룰 수 있도록 하여, 웹 브라우저 자체가 앱이 돌아가는 플랫폼이 되도록 하고, 웹 서비스들은 더 이상 ‘문서’로 취급되지 않고 ‘앱’으로 발전해 나가는 움직임이 시작된 것이다.

이런 움직임은 예상보다 아주 빨리 가시적인 성과를 보이면서 이미 구글 크롬 웹 스토어는 널리 영업중에 있고, 모질라 재단에서도 파이어폭스를 위한 웹 스토어를 준비중에 있는 것으로 알고 있다.

그래서 모바일 웹 앱도 탄력을 받아서 엄청 발전을 했느냐? 글쎄 그 점이 문제라면 문제이다. 사실 HTML5 를 생각하지 않고서라도 (그러니까 웹 페이지에서 동영상을 재생하는 등의 고급 미디어 기능을 빼고) 이미지와 텍스트로 정보를 제공하면서 앱과 비슷한(?) 사용자 경험을 제공하는 일은 기존의 웹 기술로도 어느 정도 가능한 것은 사실이고, 이미 이렇게 상용화한 앱이 한 두 개가 아니다. 웹 앱을 밀고 있던 진영에서는 특히 안드로이드 계열 스마트폰의 폼팩터 단편화 (안드로이드 폰들의 제각각 스펙은 이미 초창기부터 서비스 제공자들에게는 골칫덩이였음에 분명하다) 를 극복하는 방법으로 웹 앱이 딱이라며 웹 앱으로 가야한다고 이야기했다. 이는 일견 맞는 말이기도 하다. 그런데 이들이 말하던 웹 앱의 단점은 “네이티브 앱에 비해 UI의 미려함이 떨어진다”는 것이었는데, 그게 과연 단지 “미려한 UI”에 국한될 문제일까하는 점에 의심을 품지 않을 수 없다.

문제는 상호작용이고 이는 사용자 만족도의 척도이다

모바일 플랫폼의 성격을 대표하는 말 중에 하나는 바로 ‘손안에 XX’라는 것이다. 폰 자체가 손바닥 보다 작기 (*최근 나온 일부 모델 제외) 때문에 손 안에서 모든 정보가 조작되는다는 의미도 있지만, 실제로 손가락이 닿아서 동작하는 앱들이기 때문에 이러한 감성적인 측면에서의 접근은 적지 않은 의미를 가진다고 본다. 즉, 사용자의 터치 제스처에 적절히 반응해야 한다는 점이 모바일 기기에서 돌아가는 서비스 (그것이 앱이든 웹이든)에서는 “사용자 경험에 대한 만족도”의 가장 핵심이 되는 부분이다. 따라서 단지 화려한 화면 전환 효과만이 웹 앱이 제공할 수 없는 ‘소소한’ 부분이라고 치부할 수 없다.

결국 웹 앱은 정확히는 스마트폰을 플랫폼으로 하는 것이 아니라 스마트폰 용 모바일 브라우저를 플랫폼으로 하는데, 그 때문에 치명적인 한계를 가지게 된다. 첫째로 사용자와 직접적으로 접점을 이루는 인터페이스는 모바일 브라우저가 제공하는 사용자 이벤트이다. 즉 마우스 클릭에 해당하는 탭, 그리고 “실질적인 상호작용”을 할 수 없는 쓸기와 벌리기가 모두 인 것이다. 아직까지 멀티터치 제스처를 제대로 지원하는 모바일 브라우저는 없는 실정이고, 그나마 유연하게 확대/축소나 관성 스크롤은 되고 있지만 이건 웹 앱이 지원하는 기능이 아니라 모바일 브라우저의 인터페이스일 뿐인 것이다.

덕분에 모바일 웹 앱들은 사용자의 손가락을 따라 정확하게 반응할 수 없고, 쓸기나 두 손가락으로 벌리기는 사용자가 손가락을 움직이는 동안에는 아무 일도 할 수 없으며, 제스쳐가 끝난 뒤에야 “아 사용자가 방금 손가락으로 쓸기를 했어”, “사용자가 방금 두 손가락을 벌렸어” 정도의 뒤늦은 이벤트만 알아차릴 수 있는 것이다. (이는 태블릿으로 다음 지도를 접속해서 두 손가락으로 확대/축소해보면 쉽게 느낄 수 있다. 그냥 내가 멍청이가 되는 그런 느낌이다.)

두 번째로 하드웨어에서의 부하가 너무 크다. 같은 기능, 같은 효과를 만들기 위해 이미 스마트폰은 웹 브라우저를 띄우고 있는 상태에서 시작해야 한다. 그리고 사용자의 요청을 웹 브라우저는 부지런히 웹 앱에 전달해야 하고, 웹 앱은 자바스크립트로 이에 반응해야 한다. 따라서 너무 무겁다. 똑같은 기능을 제공하는 웹 앱과 네이티브 앱이 있을 때, 이 버벅임은 품질에 너무나 큰 차이를 가져다 준다.

세 번째로 UI를 그리기 위해 필요한 자원 역시 매 페이지를 불러올 때 가져와야 한다. 페이지를 만드는 데 필요한 정보가 네이티브 앱보다 월등히 많기 때문에 웹 앱의 화면 전환은 필연적으로 느릴 수 밖에 없다. 그리고 사용자가 지루해 하는 틈을 노리는 꼼수를 부릴 수 있는 여지도 그만큼 적다.

네번째로 웹 앱을 지지하는 진영에서 말하는 “다양한 폼팩터에 구애 받지 않는 구현”도 그리 구애를 적게 받는 것은 아니라는 것이다. 물론 서비스 제공자 입장에서는 엄청나게 많은 버전의 똑같은 앱을 만들어 내는 것은 쉽지가 않을 것이다. 하지만 이를 웹앱으로 만드는 것 역시 그리 녹록치 않은 일임에는 틀림없다. 스마트폰의 화면 크기나 해상도는 역시 저마다 각각 다른데, 이를 ‘적절히 맞추어 주는’ 디자인은 가능은 하나 어렵고, 모든 요구를 다 맞추기 힘들기 때문에 어떤 면에서는 포기를 해야 한다. 그런 면에서 ‘품질’은 계속 떨어지기 마련이다.

트위터와 페이스북, 애플 그리고 Path

트위터와 페이스북은 최근 앱 업데이트를 단행하면서 한 가지 치명적인 실수를 저질렀다. 바로 웹 앱으로의 전환이다. 물론 100% 웹 앱은 아니고 네이티브 앱 내에서 웹뷰를 사용하여 화면 UI를 웹을 통해 그려주고 있다. (이는 페이스북 앱에서 담벼락 글을 지우기 위해 손가락으로 쓸어보면 알 수 있다. 통상적인 테이블 뷰와 달리 손가락을 떼고 나서야 버튼이 표시된다.) 덕분에 엄청 반응이 느리고, 사소한 동작이나 사용자의 쓸데 없는 터치 때문에 기껏 공들여(!) 불러온 화면이 하얗게 변하면서 리프레시 된다.

서비스의 UX에 있어서 최고점을 보여주는 애플도 이 측면에서는 그리 잘 해내지 못하고 있다.애플의 앱스토어 앱도 웹 뷰로 구현되어 있다. 덕분에, 역시나 엄청나게 느리다. 심지어 목록에서 앱 상세 정보로 들어간 다음 다시 밖으로 나오면 처음부터 다시 스크롤하고 목록을 추가적으로 불러와야 한다. 엄청나게 짜증나는 일이 아닐 수 없다. 비슷비슷한 앱이 많은 앱 스토어에서 쓸만한 앱을 찾기 위해 상세 화면을 들락여야 하는 상황이라면 상당한 인내심을 가져야 한다. (아 진짜 제발 이거 좀 개선해라 ㅠㅠ 앱 깔자고 맥 켜야 하는 상황이 유쾌하지는 않잖아.)

물론 앞으로 스마트폰의 메모리 사정이나 프로세서 성능등이 점차 좋아지고, (역시 국내에서는 요원하기만 하다만) 무선 네트워크 상황이 좀 더 좋아진다면 이러한 문제는 현재의 일시적인 것으로 여길 수도 있다. 하지만 Path가 보여준 네이티브 앱만이 제공할 수 있는 UX의 장점들을 볼 때 트위터나 페이스북의 공식 앱은 그저 “겨우 보여주기에 급급하다”라는 느낌을 지우기가 힘들다.

웹 표준화 진영에서 내걸던 “One Web”이라는 구호가 기묘하게 변경되어 모바일 앱에 적용되고 있는 현실이 못내 씁쓸하다. 여기저기서 아직도 “N-Screen”이라는 말을 남발하면서 왜 “같은 화면을 보여주는 것”을 자랑하나. 통합되어야 하는 건 화면에 보이는 디자인이 아니라 총체적인 사용자 경험이어야 한다.

아, 이딴 글이나 적고 앉아있자니 괜시리 아이폰5가 기다려지는 그런 날이다. 날씨도 괜히 꿀꿀하다.

 

  • Ykssk7

    좋은글이네요.. 동감하는 바가 큽니다. ^^

  • Ykssk7

    저는 웹개발자지만 웹과 앱의 사용자ui 는 정말 틀리죠.. 사용자 편의냐 개발의 편의냐의 차이 아닐까요..
    어느 누가 승리하거나 점령하는게 아니라 앱의 특성에 맞게 각자의 영역을 구축 할거라 봅니다.
    그점에서 html5는 웹개발자들에겐 모발일로 진출할수 있는 계기가 되는거구… 
    그 한계에 봉착한다면 네이티브 앱 개발로 전환할수도 있겠구요..

    • 그것이 모바일에서의 큰 기회가 되었든 아니든 보다 리치해지고 정교해지는 웹 UI 기술은 그 만의 강점이 있습니다. 아마도 지금 억지스럽게 웹UI를 사용하는 서비스들은 “N-Screen” 환경을 염두해두고 있을 거란 계산은 선다고 보여요. 하지만 그건 거저 ‘헛똑똑이’일 뿐이라고 생각됩니다. 저 역시 웹 기획을 하고 있지만, 이제는 진심으로 IE 사용자와 비IE 사용자를 차별 대우해도 된다는 그런 생각이 들때도 있지요. “모든 환경에서 동일하게보이는 것”을 목표로 하는 One-web 역시 더 이상 웹이 문서가 아닌 지금에서 통용될 수 있는 개념일까 하는 의심도 드는 것이 사실입니다. 

  • jjangadang@gmail.com

    검색하다 들어와서 잠시 읽어보았습니다. 90년대말 웹이 한창 보급될때 시기에 응용프로그래머들도 비슷한 말을 했었지요. 대세는 이미 HTML5로 정해졌습니다. Java도 한물갔고 JavaScript가 그 자리를 대신하려합니다. 네이티브앱은 그 자체가 가지고 있는 그릇이 너무 적습니다. 플랫폼에 국한되고 버전에 영향받고, 당장 내년에 플랫폼 시장이 어떻게 바뀌지 예측하기도 어렵고, 그에 빠르게 대응하기도 어럽습니다. 하지만 하이브리드앱이나 웹앱은 현재 몇가지 문제들만 기술적으로 해결이 된다면 그 그릇의 크기는 무한합니다. 그리고 기술은 결국 발전하게 되어있구요. 이익을 추구하는 기업들의 입장이라면 무엇을 선택하시겠습니까? 답은 이미 정해졌고, 다만 방법과 과정만이 남아있을뿐입니다. 시대는 변하게 마련입니다. 하지만 그 과정은 변함이 없습니다.