AMP에 대한 생각
AMP (Accelerated Mobile Pages)는 다른 어떤 기술이 그러하듯 어떠한 문제를 해결하기위한 라이브러리다. 그리고 AMP Project가 특별히 문제라고 생각한 점은 ‘현대 모바일 페이지가 너무 느리다' 라는 것이다.
어떻게 생각해보면 당연한 이야기이지만, 로딩 속도가 빠르면 빠를 수록 유저들은 더 나은 사용자 경험을 겪게 된다. 그러나 우리 중 그 누가 로딩 속도를 빠르게 하기 위해서, DOM이 렌더링되는 속도를 빠르기 위해서 많은 고민을 하고 있는가?
React나 Vue, Angular 같은 Front-End 라이브러리들이 나오면서 사용자들이 더 나은 사용자 경험을 겪고있다고 이야기하지만 이런 라이브러리들을 사용하더라도 잘못된 방식으로 구현하면 bundle된 자바스크립트의 파일은 커지고 사용자들은 결국 불편한 사용자 경험을 겪게된다.
사실 그런 사용자 경험의 대표적인 예가 아이러니하게도 페이스북이라고 생각한다. 내 노트북을 기준으로 페이스북에 접속하여 데이터가 노출되기까지는 약 3.7초 정도가 소요된다. (Performance 탭으로 측정하였다)
그리고 그 중 2.3초를 Script를 해석하기 위해 사용하고 있다. 물론 Bundle된 스크립트를 최초에 불러오면 이후에는 스크립트의 실행시간만 발생할 뿐 해석하는 시간은 별도로 발생하지 않기 때문에 비용이 절약된다고 할 수 있지만 처음 유저가 접속하였을 때 만족스럽지 않은 결과를 불러일으킬 수 있다.
그리고 이 3.7초는 무엇보다 네트워크 환경이 정말 좋은 상황임을 전제로 만들어진 시간이다. 네트워크 환경이 나쁘다면 이런 속도를 기대할 수 없을 것이다.
Mobile First
웹 개발 산업이 그동안 Desktop이라고 불리는 환경에서 Mobile로 넘어올 때, 일부 선구자들은 Mobile 환경과 Desktop 환경은 완전히 다르기 때문에 두 영역을 별도로 바라봐야한다고 이야기하였지만 일부는 Desktop에서 구현하던 관습 그대로 Mobile 페이지를 개발한다.
Desktop과 다르게 Mobile은 보통 Viewport의 너비가 좁고, Viewport의 높이는 넓기 때문에 세로로 스크롤을 길게해서 보는 콘텐츠가 Desktop의 그것보다도 많아진다. 하지만 우리가 웹 페이지를 개발할 때 그런 기기의 특성을 고려해서 구현하고 있는가?
AMP에서는 리소스를 다운로드 할 때 Viewport에 해당 요소가 나타났는 지를 체크해서 리소스를 다운로드 받도록 하고있다. 그래서 <img> 요소가 아닌 <amp-img> 요소를 사용하게 된다.
또한 AMP에서 화면을 그릴 때에 이미지나 동영상 등 리소스의 사이즈 변경으로 인한 layout 과정을 방지하기 위해 width, height 및 layout 값을 사전에 정의하도록 한다. 그렇게 하면 리소스의 크기를 미리 알 수 있기 때문에 화면을 해석하는 과정에서 미리 해당 높이를 요소에 부여하여 브라우저가 다시 계산하는 로직을 방지할 수 있기 때문이다.
또한 대부분의 인터렉션은 Touch 인터페이스던 Mouse 인터페이스던 상관없이 동작하도록 구축되어있기 때문에 사용자가 어떤 인터페이스를 통해 접근하던 편리하게 페이지를 이용할 수 있도록 되어있다.
그 외에도 GPU 가속 애니메이션만 사용하도록 제약하고, 웹 폰트를 빠른 CDN에서만 사용할 수 있게 하는 등 웹 페이지를 빠르게 하기 위한 모든 기술을 집약적으로 다루고 있다. 이는 페이지의 속도를 빠르게 만들어줄 뿐만 아니라 사용자의 경험을 좋게 만들어주기까지 한다.
구현자의 잘못을 AMP의 책임으로 돌리지 마라
우리 시대에는 다양한 라이브러리를 사용해왔다. jQuery로 시작되었던 그 붐은 지금 React, Vue까지 도달했고 미래에는 어떤 상황이 올 지 잘 모르겠다. 어떤 이는 AMP가 모바일 전용 페이지로의 회귀라고 이야기하는 것을 보았다.
아이러니 하게도 AMP가 Accelerated Mobile Pages, 즉 빠른 모바일 페이지라는 프로젝트 명을 가지고 있지만 이는 반드시 모바일에만 국한되어있는 것은 아니다. 예를 들어 bmw.com 은 전체 페이지가 AMP HTML로 구현되어있음에도 불구하고 Desktop 이던 Mobile 에서던 미려한 화면을 나타내고 있다.
따라서 AMP를 사용해서 개발한다는 것이 Mobile Page만을 위한 것이 아니며 우리가 HTML을 사용하듯이 페이지의 속도를 좋게 만들기 위해 확장되어있는 HTML을 사용한다는 것에 집중하면 좋을 거 같다.
그리고 AMP는 유저가 직접 작성한 JavaScript를 지원하지 않지만 AMP 자체가 가지고있는 강력한 컴포넌트들이 많기 때문에 유저가 표현하고자하는 바 대부분은 AMP 자체의 컴포넌트만으로도 표현이 가능하다.
AMP는 정적이다라는 오해
AMP가 처음 나왔을 때에는 주로 언론사 등 정적인 페이지에서 주로 사용되었는데 AMP가 가지고 있는 표현력이 굉장히 좋지 않았기 때문이다. 특히 자바스크립트를 이용하면 아주 간단하게 작업 가능할 것도 AMP를 이용하면 구현이 불가능하던 때도 있다.
하지만 AMP가 버전업을 거치면서 유저의 인터렉션에 따라서 반응해서 동작하는 기능들이 추가되었기 때문에 지금 AMP가 정적이다라고 말하면 그것을 잘못된 이야기이다.
JSON을 받아서 실시간으로 데이터를 화면에 뿌려주는 <amp-list> 혹은 <amp-live-list>, 유저의 선택상태에 따라서 데이터를 다르게 보여줄 수 있는 <amp-state> 등 다양한 요소들이 AMP에 추가되고 있다.
AMP Project에서 제공하는 Product Page 샘플을 보면 더 이해가 쉬울 것이라고 생각한다.
AMP는 자유도를 낮춘다
이는 아쉽게도 어느정도 맞는 말이다. AMP를 사용하면 수많은 제약에 갇히게 된다. 유저는 내 마음대로 Script를 작성할 수도 없고, CSS를 마음편히 작성하지도 못하며 img 요소를 하나 쓰려고 해도 width, height, layout을 정의해주어야한다.
서두에서도 이야기 했지만 AMP는 특정한 문제를 해결하기 위해서 나온 라이브러리다. 그 문제는 ‘모바일 페이지의 속도가 너무 느리다' 라는 것이고 그들이 내린 결론은 ‘개발자들에게 제약은 가더라도 모바일 페이지의 속도를 빠르게 하자' 라는 것을 결론으로 삼은 것이다.
그렇기 때문에 AMP를 사용할 때 고려해야하는 점은 ‘이런 제약사항을 가지고서라도 AMP를 이용해서 개발해야하는가?’ 라고 생각한다. 그리고 나는 여전히 AMP가 매력적이라고 생각하고 있다.
여러가지 이유가 있지만 이미 우리는 플러그인이나 라이브러리로 도배된 웹 페이지를 만드는 경우가 많다. 하지만 그런 플러그인을 사용할 때 가지는 제약사항들은 ‘써야만 하니까 가지는 제약사항' 이 되는 경우가 많고, 그렇게 추가되는 CSS와 JS들이 웹 페이지를 느리게 만든다.
우리는 이런 개발 추이에 늘 경계해야하지만 사실상 경계하는 경우가 많지 않다. ‘에이 그래봤자 플러그인 한두개 쓰는데' 웹 페이지의 성능은 그 한두개가 불러오는 사이드이팩트가 부풀고 부풀어서 느리게 만든다.
그래서 어쩌라고?
나는 이 글을 읽은 사람이 AMP를 쓰던 안쓰던 상관없다. 하지만 AMP Project가 어떤 것인 지 제대로 알고 그것을 써야하는 지에 대해서 이야기를 해보면 좋을 거 같다.
다가오는 9월 11일에 한국에서 첫 AMP Roadshow가 열린다. 이 이벤트에 참석할 사람이 몇명이나 될 지 모르겠지만 만약 이 글을 읽고 AMP에 대해서 관심이 조금이라도 생겼다면 한번 참석해보면 좋을 거 같다.
