인터넷 웹 서비스들이 느려졌다

HTML5 구현체가 속속 모습을 보이면서 웹 서비스들은 다양한 시도를 하고 있다. 과거에는 인터넷을 통해 콘텐트를 생산하여 전파를 했고, 이 콘텐트가 사람들을 모이게 했다. 웹을 통해 커뮤니케이션이 이루어 지면서 비슷한 관심사의 유저들에 의해 인터넷 커뮤니티가 속속 등장했다.

이것이 개인화로 이어지면서 개인이 운영하는 블로그가 많은 인기를 얻었다. 블로그를 열심히 잘 운영하면 사회 지위적인 약자도(a weak person), 잘 알려지지 못한 무림속의 전문가도 여러 사람의 관심을 받을 수 있는 발언권을 가질 수 있게 되었다. 웹 서비스가 자신을 PR하고 개인의 비즈니스 모델이 될 수 있음이 증명되었다.. 필자도 그런 부류 따위의 한 사람이다.

하지만 최근 인터넷 웹 서비스는 예전 보다 더 쾌적한 환경을 제공하는 지 의심이 된다. 방문하는 웹 사이트마다 괴롭다. 네트워크 대역은 더 용량은 더 커졌고, 개인 PC와 스마트폰의 CPU는 더 빨라짐에도 여전히 브라우저로 인터넷 서비스를 이용하는 것은 더 느려졌고 더 많이 기다려야 한다.

이런 몇 가지 주요 요인은 다음과 같이 정리된다.

1. Javascript 언어 본질적인 문제라기 보다

브라우저에서 동작하는 Javascript가 주요 원인이다. 브라우저에서 동작하는 Javascript는 운영 체제의 커널(kernel)이나 드라이버(driver)에 접근할 수 없으므로 가장 빠른 네이티브 함수를 사용할 수 없다.

Javascript 에서 thread(스레드)와 process(프로세스)를 그 외에 GPGPU(General-Purpose computing on Graphics Processing Units) 와 같은 네이티브 함수에 접근할 수 있다면, 브라우저는 '터보 엔진'을 장착한 것이다.

2. 또, 브라우저는 인터넷의 리소스를 동시에 다운로드 할 수는 있으나

Javascript는 동시에 처리할 수 없다. 

다운로드 받은 여러 개의 Javascript 파일은 빠르다고 소문난 크롬의 v8 엔진이 제공하는 context 객체에서 순차적으로 실행이 된다. 그 안에서 function을 만나면 scope 가 생성이 되는데, 이 scope을 병렬로 처리할 수 없고 blocking 되어 실행되어야 context안의 scope의 atomicity(원자성)이 보장된다. 풀어서 다시 정리하자면, javascript는 concurrents 일 수는 있으나 parallels 할 수 없다.

3. 이번 것은 필자가 제일 싫어하는 문제다.

HTTP/HTTPS는 stateless protocol 이므로 브라우저가 redirect/submit마다 매번 인터넷 리소스나 Javascript 를 reload 하게 된다. 브라우저 랜더링 성능을 향상시키기 위해 Javascript 파일을 HTML 문서 하단에 두는 추세이다. 그 결과 브라우저에 표현될 요소들은 모두 표시되었으나 자바스크립트 컴파일이 가장 마지막에 수행되므로 마우스나 키보드 동작 이벤트가 바로 발생하지 않는다. 

한 마디로, 굼떠진다. 브라우저의 화면은 다 떴는데, 마우스 휠과 움직임 그리고 클릭 같은 동작이 툭~툭~ 끊기거나 freezing 되어 버린다.

4. 프로그래밍 측면에서 오버 엔지니어링도 문제다.

웹 페이지에서 [AngularJS]와 같은 라이브러리를 사용하는 것도 성능 저하와 밀접한 관련이 있다. (nodejs 제외)

AngularJS 라이브러리는 공식 페이지에서 다음과 같이 소개한다.

HTML is great for declaring static documents, but it falters when we try to use it for declaring dynamic views in web-applications.

AngularJS의 가장 best practices 는 정적 페이지다. SPA(single page application)에 최적화 되어 있다. 하지만, 웹 응용 프로그램에 쓴다고 하더라도 문제가 될 것은 없다.

하지만 AngularJS를 MVC 웹 응용 프로그램과 같이 쓰게 되면 동일한 패턴을 관리하는 포인트가 하나 더 생긴다. 웹 응용 프로그램 레벨에서 MVC 패턴과 View 레벨에서 한번 더 AngularJS와 같은 MV(C) 패턴이 추가 된다. 필자 경험으로 웹 페이지에서 controlling이 필요한 view는 자주 보기 힘들다.

웹 페이지에서 model binding이 필요한 건지, view-model, templating이 필요한 건지 controlling이 필요한 건지, 다시 생각해 볼 수 있는 문제다.

결론

우리나라 속담에 '뱁새가 황새 쫓다가 가랑이 찢어진다'가 있다.

웹이 네이티브 쫓다가 가랭이 찢어진다. 인터넷 웹 서비스가 발전하고 있는 경향은 웹 브라우저에서 네이티브 데스크탑 응용 프로그램(desktop application)과 같은 사용자 경험(user experiences)을 제공하고 싶어 한다.

앞으로도 웹의 기술적인 진화는 네이티브 데스크탑 응용 프로그램 처럼 동작하기 위한 요소들이 추가될 것이다.

AJAX(asynchronous javascript and xml), web socket, web db, comet 과 같은 기술은 분명 웹을 진화시켰다. 하지만 웹 다워 졌다가 아니라, 네이티브 처럼 표현하기 위한 수단이 되었다. 그리고 지금은 많은 웹 서비스들이 네이티브 응용 프로그램을 웹 서비스로 그대로 옮겨 놓았다. 혁신적이기는 하지만 굳이 웹을 통해서 이용할 생각은 없다. 가끔 필요할 때 유용하게 이용하긴 하지만... 브라우저라는 sandbox 환경에서는 절대 네이티브와 같은 사용자 경험을 제공하지 못한다.

많은 모바일 네이티브 앱들이 브라우저에서 돌아가도록 갈아 탔고, 다시 네이티브로 귀환하는 경우를 가끔 본다. 모바일 브라우저에서 페이스북을 즐기긴 여간 까다롭지만, 페이스북 전용 앱을 사용하면 더 큰 재미를 얻는 느낌과 비유해도 될 것 같다.

아직 필자도 결론을 내릴 만큼 정리되지 않았다. 그리고 이런 추이를 지켜보는 것도 재미있다. 

다만 인터넷 웹 서비스는 네트워크 응답 속도와 체감 속도의 향상이 전부가 아니다. 사용자 경험 측면에서 좋은 성능을 내야 함이 분명한 결론이 될 것이다.

신고
크리에이티브 커먼즈 라이선스
Creative Commons License
Posted by 땡초 POWERUMC

댓글을 달아 주세요

  1. muy.kr 2014.04.08 02:11 신고 Address Modify/Delete Reply

    정말 좋은 정보네요.. 잘 보고 갑니다^^

  2. A TearDrop 2014.04.08 03:22 신고 Address Modify/Delete Reply

    잘보고갑니다

  3. 업글 2014.04.08 04:04 신고 Address Modify/Delete Reply

    정말 도움이 많이 되었습니다.
    요즘 추세인 역동적이고 멋진 이펙트들로 느려지는 문제를 제외한다면 요즘 웹은 만들기가 참 편해져갑니다.
    단, 구형브라우저들을 다 버린다는 가정하에 말이지요 ㅋㅋ

  4. 이승근 2014.04.08 12:39 신고 Address Modify/Delete Reply

    AngularJS 의 소개 글은 html은 정적페이지를 위해 최고이지 동적페이지 작성에는 좋지 못하다 따라서 AngularJS를 만들었다 라는 내용인데요.
    정적 페이지가 AngularJS의 best practices라고 말하지 않습니다.

  5. 이승근 2014.04.08 12:58 신고 Address Modify/Delete Reply

    그리고 모든 이벤트 드리븐 기반의 프로그래밍 모델( event loop )에서, 이벤트 핸들러는 event thread에 대해 serialize되어야 합니다.
    이는 모든 UI프로그래밍에서 UI접근은 ui thread(aka main thread/event thread )에서만 수행되어야한다는 제약과 동일합니다. DOM객체를 UI객체로 생각하시면 다른 native 프로그래밍 모델과 크게 다를바는 없습니다.

    그리고 web worker를 제공해서 별도의 thread에서 computing logic을 수행 할 수 있습니다.


    "concurrents 일 수는 있으나 parallels 할 수 없다."
    라는 말은 무슨 의미로 작성하셨는지 이해하기가 어렵네요

    • 땡초 POWERUMC 2014.04.08 17:26 신고 Address Modify/Delete

      읽어 주셔서 고맙습니다.

      '그리고 모든 이벤트 드리븐'은 자바스크립트를 말하시는 건가요?
      이벤트 드리븐이 race condition 하는데, 핸들러가 왜 serialize가 필요한가요?

      그리고 concurrents와 parallels의 의미는 컴퓨터 사이언스의 사전적 의미와 동일합니다.

  6. 이승근 2014.04.08 18:16 신고 Address Modify/Delete Reply

    자바스크립트를 포함 모든 이벤트 드리븐 프로그래밍을 말하였습니다.

    이벤트 드리븐이 race condition이라는 말은 어떤 의미로 하신건지는 모르겠네요,
    race condition은 제가 아는 한에서는,
    같은 자원을 동시에 2개 이상의 thread에서 접근하는 상황인데요,
    이벤트 드리븐 모델에서는 이벤트 자체가 하나의 큐를 통해서 serialize되므로 핸들러간 race condition이 발생하지 않습니다. 그런 의미로, serialize되어야 한다는 말이었구요, 핸들러 안에서 serialize가 필요하다는 말은 아니였습니다.

    그리고, 제가 아는 concurrents는 "동시에 수행 할수 있는"을 의미하고, 자바스크립트의 경우 보통 모두 이벤트 핸들링에 의해서 하나의 thread에 의해서 수행되고, 더구나 DOM이라는 객체 자체가 concurrent한 접근을 허용하지 않기 때문에 concurrent하다고 말하기 어려울듯하네요,

    parallel은 물리적으로 동시에 수행하는 CPU 파이프라인이나,
    물리적으로 여러대의 PC에서 컴퓨팅을 수행하는것에 대해 일컷는 말이라고 알고 있어서, 무엇을 말하려고 하셨는지 잘 이해하기가 어렵습니다.




    • 땡초 POWERUMC 2014.04.08 20:39 신고 Address Modify/Delete

      내용 잘 보았습니다.
      허나 이런 방식으로 논쟁을 계속 해야 할 지 모르겠네요.

      먼저 이벤트 드리븐의 직렬화에 대해서 아래의 링크로 보아도 무방하겠죠?
      https://www.artima.com/weblogs/viewpost.jsp?thread=84958
      같은 메모리 프레임 안에 있는 객체의 포인터 객체를 왜 직렬화 해야 하는지요?
      이벤트는 포인터 함수를 통해 위임을 하고, 이런 방식으로 프로그래밍 하는 것을 이벤트 드리븐으로 알고 있습니다.
      serialize는 네트워크 통신이나 프로세스간, 또는 이기종 간에 데이터를 전송하기 위해 직렬화하는데, 왠 이벤트 드리븐에서 직렬화 얘기가 나오는지 이해가 가지 않네요.
      이것과 관련된 내용이 있으면 링크좀 부탁 드립니다.

      concurrents, 즉 non-blocking을 concurrents로 표현한 것입니다.
      잘못된 비유인가요?

  7. 이승근 2014.04.08 20:47 신고 Address Modify/Delete Reply

    용어 측면에서, synchronization을 썼어야 하는데, serialize를 잘못사용해서 답글을 이해하시는데 혼란을 드린것 같네요.
    결국 event handler는 event thread에 대해 synchronization되며, 이는 모든 event driven기반 프로그래밍 모델에 동일한 사항인데, 자바스크립트의 문제점이라고 하시기에 답글을 달았습니다.

  8. 성현 2014.04.08 20:53 신고 Address Modify/Delete Reply

    잘보구감니다.
    개발당시 요구사항도 요즘은 네이티브처럼 만들어달라는데. 그리하면 정말 검나 느림 ㅡㅡ

  9. Rachel:) 2015.01.22 10:45 신고 Address Modify/Delete Reply

    좋은글 감사합니다! 잘읽고가요~~