Outsider's Dev Story

Stay Hungry. Stay Foolish. Don't Be Satisfied.

기술 뉴스 #77 : 17-05-01

웹개발 관련

  • A Comprehensive Guide To HTTP/2 Server Push : HTTP/2의 Server Push를 이용하면 HTML 문서를 불러올 때 필요한 정적 파일을 서버가 같이 보내줄 수 있는데 Link 헤더를 이용해서 Server Push를 어떻게 사용하는지 설명하고 설정 별로 성능 테스트를 진행해서 어느 정도의 차이가 나는지 보여주고 있다. 마지막으로 캐시 문제 등 Server Push를 사용할 때 주의해야 할 점까지 나와 있어서 HTTP/2에서 Server Push를 사용할 때 한번 읽어보기 좋은 글이다.(영어)
  • Preload, Prefetch And Priorities in Chrome : <link rel="preload"><link rel="prefetch">의 동작이 어떻게 다르고 Chrome 내에서 네트워크 우선순위를 어떻게 배정하는지를 설명한 글이다. 간단히는 preload는 현재 페이지의 필수적인 에셋이라 우선 다운로드를 해야 할 때 사용하고 prefetch는 페이지 이동 후에 사용해야 하는 것을 미리 받아놓는 용도이다. 둘의 차이점을 확실히 이해하면 상황에 맞게 활용할 수 있고 이를 적용하면서 실수로 중복 다운로드를 하는 문제나 Server Push와는 어떻게 분리해서 써야 하는지가 잘 나와 있다.(영어)
  • GPU Animation: Doing It Right : 웹사이트에서 GPU 가속을 이용하기 위해 transform: translateZ(0)will-change: transform 속성을 사용하는데, 애니메이션을 사용할 때 브라우저가 어떻게 동작하고 GPU 가속을 하면 브라우저와 GPU가 화면을 어떻게 구성해서 그리는지를 자세히 설명하고 있다. GPU 가속을 할 때 메모리 사용량이 증가하는 이슈에 대해서도 자세히 나와 있어서 애니메이션을 사용할 때 최적화된 웹사이트를 만들 기에 어떤 부분을 고려해야 할지 잘 이해할 수 있다. 마지막에는 브라우저별로 개발자도구에서 GPU 가속에 대한 최적화를 어떻게 디버깅할 수 있는지까지 설명하고 있다.(영어)
  • Chrome and Firefox Phishing Attack Uses Domains Identical to Known Safe Sites : xn-- 접두사로 브라우저에 유니코드 표현을 punnycode로 하게 해서 사용자가 보기에는 같은 도메인으로 보이지만 실제로는 다른 유니코드를 사용해서 HTTPS 안전함으로 정상 표시되는 똑같은 사이트를 만들 수 있음을 설명한 글이다. 이 글에서는 epic.com이라는 헬스케어 사이트의 피싱사이트를 만들어서 실제 사이트와 같게 보임을 설명하고 있고 이 문제는 Chrome과 Firefox에서만 취약한데 Chrome 58에서는 이 문제가 수정되었다.(영어)

그 밖의 프로그래밍 관련

  • DOCKERCON 2017 HIGHLIGHTS DAY 1, DAY 2 : 이번에 DockerCon에서 발표된 내용을 정리한 글이다. Docker 이미지에 멀티 스테이지가 생겨서 컨테이너를 만들 때 단계별로 이미지를 분리해서 구성할 수 있게 되었고 컨테이너 전용 OS를 구성할 수 있는 LinuxKit, Docker의 새 이름인 Moby를 공개했다. 요즘 Docker 쪽이 나오는 게 많아서 헷갈리는데 기존 Docker 프로젝트가 Moby라는 이름으로 바뀌었고(저장소 명이 변경됨) Moby를 이용해서 Docker CE와 Docker EE라는 제품이 나오는 형태가 되었다. 엄청 헷갈리지만, 아무튼 그렇게 됐다.(영어)
  • Multi-Stage Docker Builds for Creating Tiny Go Images : 이번 DockerCon에서 발표된 Multi-Stage 기능을 테스트해 본 글이다. DockerCon에서는 Multi-Stage를 정확히 어떻게 사용하는지 몰랐는데 이 글을 보면 빌드용 이미지와 최종 이미지를 어떻게 나누어서 사용할 수 있는지 쉽게 이해할 수 있다.(영어)
  • Serverless Stack : Serverless 프레임워크로 AWS Lambda, DynamoDB, Conginoto로 백엔드를 구성하고 React.js로 프론트엔드를 구성해서 서버리스로 전체 웹 애플리케이션을 만드는 튜토리얼(영어)
  • Introduction to Relay Modern : Relay의 새 버전인 Relay Modern의 소개 글이다. GraphQL의 클라이언트 격인 Relay가 1.0부터 사용하기 쉽고 성능이 향상된 Relay Modern이 되었다.(영어)
  • AWS Lambda Python 3.6 지원 : 그동안 Lambda에서는 Python 2.7만 사용가능했는데 드디어 3.6 지원이 추가되었다.(영어)
  • 번역 - React VR 시작하기 : 이번 F8에서 공개된 React VR의 소개 글인 Getting started with React VR의 번역 글로 React를 이용해서 VR 애플리케이션을 어떻게 만들 수 있는지 튜토리얼 성 설명을 볼 수 있다.(한국어)
  • Announcing the new GitHub Developer Program : GitHub에서 제공하는 개발자 프로그램이 개선되었다. 유료사용자에게만 제공하던 기존과 달리 모든 사용자가 참여할 수 있게 되었고 레벨이 적용되어 GitHub API에 대한 정보를 받을 수 있는 Level 1부터 API로 앱을 만들어서 공개하면 지원받을 수 있는 Level 2, 3 등 다양해졌다.(영어)

볼만한 링크

  • Painting with Code : Airbnb에서 Sketch를 사용하면서 디자이너와 엔지니어 협업 문제를 해결하려고 노력하다가 보통 하는 작업과는 반대로 React 컴포넌트를 작성하면 이를 이용해서 Skectch 파일을 만들어서 협업할 수 있도록 한 과정을 설명한 글이다. 이 작업의 결과로 React Sketch.app을 만들어서 오픈소스로 공개했다.
  • Open Arrow 작업기 : heeyeun님이 얼마 전에 공개하신 Open Arrow의 아이디어 구상부터 만드는 과정을 설명한 글이다.(한국어)
  • 트위터는 왜 모니터링을 2번이나 만들었을까? : 트위터가 내부 시스템 모니터링을 두 번 만들었는데 1.0에서 어떤 문제가 있었고 이 문제를 해결하기 위해 2.0에서 확장성이나 UI 부분에서 어떻게 해결했는지를 정리한 글이다.(한국어)
  • 팀 공용 계정 비밀번호 관리하기 : pass라는 GPG 기반의 패스워드 관리 도구를 이용해서 팀에서 공용으로 사용하는 비밀 정보를 관리하는 방법을 설명한 글이다. git을 이용해서 프로젝트를 공유해서 팀원이 전체가 사용하고 pass가 암복호화하는 방법을 설명하면서 팀원이 어떻게 복호화해서 사용하고 새로운 팀원이 왔을 때 어떻게 추가하는지까지 설명할 수 있다. 개인적으로는 Vault로 비슷한 목적을 이루려고 하고 있지만 pass를 이용한 방법도 흥미로운 방법이다.(영어)
  • macOS Sierra에서 원화 대신 백 쿼트 입력하기 : 최근 macOS 업데이트해서 한글에서는 백틱(`) 대신 원 표시(₩)가 입력되도록 바뀌었는데 마크다운 등을 많이 사용하는 개발자들은 항상 옵션 키랑 같이 누르거나 하는 큰 불편함이 생겼다. 이 글의 내용으로 패치를 하면 백틱을 그대로 사용할 수 있다.(한국어)

프로젝트

  • Tamper Chrome : 크롬에서 HTTP 요청을 디버깅하거나 수정해서 요청해 볼 수 있는 크롬 익스텐션.
  • TodoMVC for the RealWorld : 예제로 활용할 수 있도록 Medium 같은 사이트를 프론트엔드는 Angular 2, React.js, Angular 1.5로 구성하고 백엔드는 Django, Node.js, Rails로 구성한 프로젝트.
  • pkg : Node.js 프로젝트를 Node.js가 설치되지 않은 환경에서도 실행할 수 있도록 OS별로 패키징하는 도구.
  • postal : 메일 서버를 직접 돌릴 수 있는 오픈소스 플랫폼으로 Ruby로 작성되었다.
  • Slate : 웹 텍스트 에디터를 만드는 프레임워크.
  • Xi Editor : Rust로 작성된 텍스트 에디터.
  • React VR : Facebook에서 오픈소스로 공개한 프로젝트로 React로 VR 웹사이트를 만들 수 있다.
  • Barba.js : 웹사이트에서 자연스러운 전환 효과를 지원하는 JavaScript 라이브러리.
  • Litho : Facebook에서 공개한 안드로이드용 선언적 UI 프레임워크.

버전 업데이트

2017/05/01 22:42 2017/05/01 22:42

나는 AMP를 좋아하지 않는다.

AMP가 처음 등장했을 때 꽤 관심이 있었고 그동안 모바일 최적화에서 느끼던 어려움을 해결해 줄 것으로 생각했지만, 자세한 내용을 보면 볼수록 내가 생각하던 웹의 방향과는 달라서 지금은 전체적인 추세만 보고 있을 뿐 내가 직접 구현할 것 같지는 않다. 정말 큰 흐름이 된다면 거스를 수는 없겠지만 내가 먼저 구현해서 그 흐름에 참여할 생각은 별로 없다.

AMP란 무엇인가?

AMP는 Google에서 시작한 프로젝트로 Accelerated Mobile Pages의 약자이다. 즉, 모바일전용 빠른 웹페이지를 의미한다. 요즘은 하나의 웹사이트를 만들고 미디어쿼리로 큰 해상도부터 작은 해상도까지 모두 대응하고 있다. 하나의 문서를 가지고 다양한 클라이언트 환경에 맞추어서 보여주는 이 방향은 맞는다고 생각하지만, 현실에서 이를 제대로 구현하기는 쉽지 않다. 미디어쿼리로 구현한 경우 어쩔 수 없이 성능이나 기능에서 손해를 볼 수밖에 없는데 몇 가지 예를 들면 srcset을 아직 현실에서 사용할 수 없는 상황에서 이미지 등을 상황에 맞게 사용하려면 이미지를 CSS에서 미디어쿼리로 지정해야 하는데 이렇게 하면 검색엔진에서는 이미지가 제대로 수집되지 않는다. 그리고 자바스크립트를 상황에 따라 동적으로 로딩하는 수준으로 구현하는 게 아니라면 데스크톱에서만 필요한 스크립트를 모바일에서도 다운받아야 하고 그 반대의 경우가 생기기도 한다. 이는 복잡한 사이트일수록 모바일에서 성능 저하가 생길 수밖에 없게 된다.

이런 문제를 해결하려고 AMP가 나왔다고 생각하는데 모바일에서 빠른 속도를 보장하기 위해 AMP는 몇 가지 제약사항을 가지고 있다.

  • CSS는 모두 인라인으로 지정해야 하며 50KB를 넘을 수 없다.
  • 스크립트는 <script async src="https://cdn.ampproject.org/v0.js"></script>처럼 AMP에서 제공하는 스크립트 외에는 외부 JavaScript를 허용하지 않는다.
  • 기본 HTML 태그 대신 <amp-img>, <amp-anim>, <amp-video>같은 AMP 전용 태그를 사용한다.
  • 모든 리소스는 크기를 지정해서 리소스를 다운로드 한 후에 브라우저가 레이아웃을 다시 그리지 않도록 한다.

이 외에도 브라우저 속도에 영향을 줄 수 있는 요소를 차단하는 다양한 제약사항이 있다. 이를 통해서 아주 빠른 모바일 전용 페이지를 제공하고 있다. AMP에 대해서는 검색하면 자세히 설명하는 다양한 글을 볼 수 있다.

웹사이트가 모바일에서 느리다는 것은 모두가 겪는 문제인데 각 서비스에서는 이를 해결하려는 움직임을 보였다. Apple에서는 News를 공개했고 Facebook은 Instant Article을 공개했다. Apple과 Facebook이 모바일에서 빠른 속도를 보여줄 수 있는 환경을 만들자 여기에 위기를 느낀 구글이 AMP를 만들었다고 생각하고 있다.(이런 배경을 설명하진 않으므로 이건 내 추정일 뿐이다.) News와 Instant Article이 완전히 자사 플랫폼 전용임과 비교하면 AMP는 좀 더 범용적인 포맷을 만들어서 반격을 꾀했다고 생각하고 현재까지는 꽤 괜찮은 분위기를 만들고 있다고 본다.

하지만 나는 AMP가 잘못된 방향이라고 생각한다.

이렇게 생각하는 이유가 몇 가지 있는데 AMP는 그동안 웹이 발전해 온 방향과는 다른 방향이라고 느끼기 때문이다. 웹이 계속 발전해도 나는 웹은 그 근간이 문서라는 개념에 무게를 크게 두고 있고 이게 웹의 핵심이라고 생각하기에 이를 거스르는 느낌이 들면 거부감이 드는 편이긴 하다.

AMP는 모바일 전용 페이지 시대로의 회귀이다.

스마트폰이 처음 등장했을 때 웹에는 모바일 전용 페이지라는 개념이 있었다. outsider.ne.kr이 웹사이트면 모바일은 m.outsider.ne.kr 같은 식으로 만들었다. 이는 서버에서 User Agent를 확인해서 모바일 브라우저라고 판단되면 모바일 전용 페이지로 리다이렉트 시키는 방식으로 동작했고 이 페이지는 작은 해상도에서 최적화된 레이아웃으로 구성된 웹페이지를 제공했고 하단에는 보통 "PC 버전 보기" 같은 버튼이 있어서 둘 사이를 오갈 수 있도록 구현했다.

이 모바일 전용 페이지는 현재 국내에도 많이 남아있지만 각 모바일 페이지가 상당히 형편없게 만들어진 것과 상관없이 이는 하나의 페이지가 두 가지 주소를 가지고 있다는 문제를 가지고 있었다. 이는 웹 문서의 퍼머링크라는 개념과 맞지 않았고(요즘은 이런 용어를 잘 안 쓰지만) 결국 2개의 페이지가 존재하는 것과 다름없게 되었다.

그리고 모바일 페이지가 잘못된 방향이라고 내가 생각하는 이유 중 하나는 모바일과 데스크톱의 경계가 모호해졌기 때문이다. 데스크톱과 모바일은 얼핏 보면 명확한 구분 같지만 모바일 디바이스가 점점 발전하면서 이 경계는 무너져버렸다. 예를 들어 iPad Pro는 1024x1366의 해상도를 가지고 있다. 그러면 여기서 iPad Pro는 모바일로 구분해야 하는가 데스크톱으로 구분해야 하는가? 이는 쉽지 않은 문제다. 만약 1280을 기준으로 모바일과 데스크톱을 나눈다고 하더라도 1280 해상도가 안되는 노트북도 많이 존재하고 iPad Pro같은 경우 가로로 보면 폭이 1366이 되어 버린다. 같은 장비가 세로로 보냐 가로로 보냐에 따라 모바일이냐 데스크톱이냐를 다르게 구분할 수는 없다. 이런 문제는 모바일 전용 페이지로 해결할 수 있는 문제가 아니라 미디어쿼리로 각 상황에 맞게 모든 픽셀에 대응할 수 있는 게 더 옮은 방향이라고 생각한다.(아직 부족한 점이 있다고 하더라도...)

다시 AMP로 돌아가 보자.

Apple just received a permit to test self-driving cars in California라는 The Verge의 기사를 보자. 이 기사의 주소는 http://www.theverge.com/2017/4/14/15303338/apple-autonomous-vehicle-testing-permit-california이고 이 페이지는 큰 해상도에서 보면 다음과 같은 디자인으로 되어 있고 당연히 모바일에서도 잘 볼 수 있도록 반응형 디자인으로 만들어져 있다.

The Verge의 뉴스 기사

이 페이지의 소스를 보면 다음과 같은 HTML 태그가 존재한다.

<link rel="amphtml" href="http://www.theverge.com/platform/amp/2017/4/14/15303338/apple-autonomous-vehicle-testing-permit-california">

이 태그가 이 페이지의 AMP 페이지 주소를 알려주는 역할을 하고 그 주소는 http://www.theverge.com/platform/amp/2017/4/14/15303338/apple-autonomous-vehicle-testing-permit-california가 되고 이는 큰 해상도에서 접속해 들어가더라도 다음과 같이 모바일 전용 레이아웃으로 보이게 된다.

The Verge의 뉴스 기사의 AMP 페이지

나는 이 구조가 앞에서 본 모바일 전용 페이지와 별로 달라 보이지 않는다. 서버에서 자동 리다이렉트를 안 해준다는 것과 서로 간에 가시적인 이동 버튼이 없는 것 말고는 나한테는 똑같아 보인다. 이 AMP 구조가 모바일에 최적화 사이트이므로 좋은 방식이라면 m.도메인으로 시작하는 모바일 전용 페이지도 괜찮은 접근이어야 한다. 물론 AMP가 여러 방향에서 더 좋은 기술적인 요소를 가진 것은 맞지만 큰 흐름의 방향은 거의 비슷하다고 본다.

AMP는 검색엔진 중심이다.

위에서 간단히 AMP의 구조를 설명했지만 실제로 사용자들이 이용하는 방식을 살펴보자. AMP가 위에서 보았듯이 <link> 태그로 표시되어 있고 UI에 버튼이 없으면 사용자는 어떻게 AMP 페이지를 이용하는가? 구글에서 검색하면 AMP를 지원하는 웹페이지 즉, 위처럼 <link rel="amphtml" href="">를 제공하는 웹페이지는 다음과 같이 AMP 페이지라고 보여준다.

구글 검색에 표시된 AMP 페이지

이 페이지를 클릭하면 https://www.google.co.kr/amp/www.theverge.com/platform/amp/2017/4/14/15303338/apple-autonomous-vehicle-testing-permit-california같은 주소로 접속이 된다. 이 주소는 스마트폰 등에서 열면 아래와 같이 열린다.

구글에서 보여주는 AMP 페이지

좀 더 설명을 하면 다른 환경에서 접속하면 원래의 주소인 http://www.theverge.com/2017/4/14/15303338/apple-autonomous-vehicle-testing-permit-calif로 리다이렉트된다. 기술적으로 설명하면 AMP 페이지에는 <link rel="canonical" href="http://www.theverge.com/2017/4/14/15303338/apple-autonomous-vehicle-testing-permit-california">처럼 원본 페이지에 대한 주소 정보를 알려주고 있고 기술적으로 말하면 크롤러가 이 모바일 페이지에 오게 되면 canonical 주소를 찾아가므로 실제 크롤링을 원본 문서만 크롤링 된다.

다시 위의 구글에서 접속한 AMP 페이지로 돌아가 보자. 이 페이지는 주소에서 볼 수 있듯이 google의 사이트이다. 구글에서 AMP 전용 사이트를 가지고 있고 뒤의 주소를 이용해서 아이프레임으로 해당 페이지를 AMP로 보여주고 있다. 상단에 www.theverge.com이라고 표시된 헤더 부분은 구글의 사이트이고 그 아래 <iframe>으로 AMP 페이지를 보여주는 방식을 취하고 있다. 이렇게 하는 경우 해당 문서에 대한 URL(여기서는 the verge의 기사) 대신 구글 주소가 주소창에 표시되므로 구글에서는 이를 조금이라도 완화하기 위해 상단 헤더에서 원본 주소를 복사하고 AMP에 대한 정보를 얻을 수 있는 버튼을 제공하고 있다.

그리고 AMP를 서비스해서 테스트해보진 않았지만 내가 아는 지식 선에서는 이 AMP 페이지를 더 빠르게 제공하려고 Google에서 AMP 캐시를 제공하고 있다. AMP 페이지를 접속할 때마다 해당 서버에서 가져오는 것이 아니라 구글이 제공하는 AMP 캐시에 저장해 뒀다가 사용자에게 빠르게 제공하는 것이다. 물론 구글 캐시서버의 성능과 인프라는 신뢰할만하니 사용자는 빠르게 페이지를 볼 수 있지만, 사용자는 해당 서버에 접속하지 않는다.(물론 콘텐츠 내에 광고로 수익을 내거나 로깅을 하려는 방법 등은 존재한다)

나는 이 구조가 아주 이상하게 느껴진다. 내가 알던 모든 웹 기술은 해당 서비스 프로바이더 중심이었고 웹브라우저 기반이었다. 계속 예시로 사용한 The Verge를 계속 얘기하면 사용자가 어떤 페이지를 보고 어떻게 보여줄지는 The Verge 사이트 더 정확히는 The Verge 서버에 HTTP 요청이 왔을 때 The Verge가 결정한다. 이를 동적으로 처리해서 보여주던 정적페이지로 캐시 해서 CDN으로 배포하던 어쨌든 The Verge의 서버가 결정하고 표준에 맞춰서 구현된 웹브라우저가 그것에 맞게 처리해준다. 처음 AMP를 보여줬을 때 나는 당연히 여태 하던 이 개념 내에서 AMP를 이해하려고 했고 수많은 문서를 보았지만 내 사이트에 사용자가 접속했을 때 어떻게 빠른 AMP 페이지를 이용할 수 있게 하는지 이해하지 못했다. 그래서 Stackoverflow에 질문도 올렸다가 AMP가 동작하는 방식을 이해하게 되었다.

AMP는 기존에 우리가 알고 있던 웹사이트가 동작하는 방식대로 돌아가는 게 아니라 검색엔진 중심으로 동작한다. 내 블로그가 AMP를 제공한다고 하면 사용자가 AMP를 이용하려면 구글 검색을 통해서 들어와야 한다. 내 블로그에 접속해서는 AMP를 이용할 수 없다. AMP가 보급되면서 구글뿐 아니라 다른 검색엔진에도 AMP 지원이 확대되고 있고 더 발전하면 페이스북이나 트위터 같은 대형서비스에서도 AMP를 지원할 수도 있지만 내 웹사이트에서 내가 통제권을 가지고 있지 않다는 것은 여전히 같다. A 사이트가 내 AMP를 이상하게 제공한다면 그냥 이상하게 제공되는 거다.

이건 내가 여태까지 이해하고 공부하던 웹이 나아가던 방향과는 완전히 다르고 극단적으로 말하면 페이스북 내에 페이스북 페이지를 만드는 것과 크게 다를 바가 없다고 느껴진다. 구글은 그나마 이런 방향 내에서도 최대한 웹의 방향을 적게 헤치려고 노력을 하고 있지만 다른 서비스도 똑같이 할 거라는 보장은 전혀 없다. 나는 이게 완전히 잘못된 방향이라고 생각한다.

AMP는 기술적으로 새로울 것이 전혀 없다.

물론 기술이란 것은 항상 새롭고 혁신적인 것만 만들어야 하는 것은 아니다. 이미 존재하는 기술을 새롭게 연동하거나 새로운 개념을 부여하는 것도 충분히 혁신적인 일이다. 그렇긴 하지만 앞에서 설명한 방향적인 문제를 포함해서 생각할 때 AMP가 제공하는 기술적인 혁신은 전혀 없다. AMP는 모바일에서 웹페이지를 더 빠르게 보여주겠다는 것이 목표이다. 내가 AMP 제약조건에 맞추어서 간단한 웹페이지를 만들어서 CDN으로 제공하면 AMP보다 느릴까? 물론 구글 캐시 서버나 CDN보다는 느릴 수도 있지만 비싼 CDN을 쓰지 못하더라도 요즘은 저렴한 CloudFront나 CloudFlare 등 저렴한 CDN을 쓸 방법이 많이 있다. AMP에서 다수의 대단한 사람들이 좋은 라이브러리를 빠르게 만들고 잘 모르는 개발자라도 실수하지 않게 좋은 제약사항을 제공한 것은 이해하지만, 오픈소스로 누군가 yet-another-amp.js같은 라이브러리를 만들어서 가져다 쓸 수 있게 한다면 다를 건 하나도 없다.

기존에 모바일에서 웹사이트가 느렸던 이유는 기술적으로 모바일에서 빠른 전용 웹사이트를 만들 수 없었기 때문이 아니다. 현재 웹 기술로 데스크톱 웹을 제공하면서 모바일에도 최적화할 기반 기술이 안 만들어졌기 때문이다. 맨 앞에서 얘기한 대로 이런 방향이면 나로서는 다시 m.도메인 사이트를 모바일 전용으로 만들어서 사용자에게 빠르게 제공하는 게 훨씬 더 낫다고 본다.

그리고 대부분 웹사이트가 점점 느려지는 이유는 서비스마다 다양한 요구사항이 있기 때문이다. 모든 사이트가 뉴스 사이트라서 간단한 텍스트만 제공하면 끝나는 것이 아니다. 콘텐츠 사이트라고 하더라도 사용자 온보딩을 위해서 여러 요소를 넣어야 하고 광고도 그냥 보여주는 게 아니라 다양한 실험을 해야 하고 애플리케이션 적이 고급 요소도 제공해야 한다. 실제로 이런 요구사항을 맞추기 위해서 AMP에도 새로운 컴포넌트가 계속 추가되고 있다. 이게 과연 모두의 요구사항을 맞출정도로 다양한 컴포넌트가 갖춰진다면 여전히 지금처럼 빠를까? 나는 AMP도 결국 요구사항을 맞추기 위해서 점점 느려지거나 요구사항을 맞춰주지 못할 것이라고 본다. 물론 AMP는 뉴스사이트 같은 문서에 기반을 둔 웹사이트를 타게팅하고 있는 것은 확실하지만, 시간이 지나면서 이는 점점 흐려질 것으로 생각한다.

결론

구글은 AMP를 지원하면 구글 검색결과에 더 높은 중요도를 배정하면서 웹사이트 운영자에게 AMP는 달콤한 유혹이 되었다. AMP라는 요소만으로 검색 결과에 상위로 올라갈 정도로 검색 알고리즘이 간단하지는 않지만, 조금이라도 상위에 올리고 싶은 웹사이트 운영자들에게 AMP 지원은 할 수 있다면 안 할 이유가 없는 부분이다. 물론 난 이 검색 결과에 적용하는 방식은 기술의 제대로 된 검증 없이 구글이 점유율을 이용해서 기술을 강요했다는 거부감이 훨씬 더 크다.

PWA이 웹의 방향성에서는 훨씬 좋은 방향이라고 보고 있는 편인데 자연스럽게 AMP가 PWA와 같이 어울리면서(둘 다 구글이 주도하다 보니) 섞여 들어오는 게 더 싫기는 하다. 물론 내가 이렇게 생각한다고 AMP가 안된다는 것은 아니다. 보통은 오히려 내가 비관적으로 보는 기술이나 회사는 더 잘되는 경향이 있지만....

2017/04/22 09:30 2017/04/22 09:30