Web Components: Keep calm and UseThePlatform


Keep Calm And Carry On

이 포스터(Keep Calm and Carry On)은 영국 정부가 제2차 세계 대전이 발발하기 전 대규모 공중 폭격이 예고된 가운데 영국 시민들에게 “평상심을 유지하고 하던 일을 계속해라”라는 뜻으로 배포했다. 그런데 현재 webcomponents.org는 무슨 이유인지 상단에 전쟁 시 사용되었던 포스터의 패러디로 “Keep calm and #UseThePlatform”이라는 모토를 달아놓았다. 구글은 지금 자바스크립트 세상을 전쟁 상황이라고 표현하는 것일까.

image.png

프레임워크 전쟁

지난 몇 해 자바스크립트 세계는 전쟁이라 해도 과언이 아니라 할 만큼 수많은 자바스크립트 프레임워크들이 폭탄처럼 쏟아져 내렸다. AngularJS, React, Bootstrap, ExtJS 등등. 이 전에는 jQuery 하나로도 모든 일이 될 때도 있었다. 당시 자바스크립트는 정적인 페이지 내에서의 제한된 역할을 맡았고, 복잡도는 페이지를 새로 로드 하는 것으로도 충분했다. AJAX의 도입으로 자바스크립트의 역할이 늘어남과 함께 코드의 복잡도는 올라갔고, 모바일을 필두로 SPA의 득세는 코드를 한없이 복잡하게 만들었다. 이를 해결하기 위한 다양한 프레임워크들의 등장은 필연적이었다 하겠다.

하루가 멀다 하고 나타나는 자바스크립트 프레임워크들을 대면하고 있자면, 이를 마치 전쟁이라 할 수 있겠지만 Keep calm and #UseThePlatform(침착하고 그 플랫폼을 사용해)은 과연 무슨 뜻이란 말인가?

image.png (Framework = DOM, Platform = Browser)

#UseThePlatform - Browser

Google I/O 2016에서 등장한 이 모토(Keep calm and #UseThePlatform)는 Progressive, Performant, Polymer: Pick Three – Google I/O 2016세션에서 잘 설명해주고 있다.

요약하면,

  • 프레임워크들은 다양한 문제를 해결할 강력한 도구이지만
  • 무거운 덩치는 앱을 무겁게 만들고
  • 리소스를 사용자에게 전가 시키며
  • 프레임워크 종속적인 코드를 생산한다

그러니,

  • 그러한 문제들을 프레임워크 대신 브라우저 기능을 사용하여 해결하면
  • 프레임워크를 가볍게 만들어도 되고
  • 더 적은 자바스크립트 코드를 사용하게 되어
  • 표준 코드로 만든 성능 좋은 Awesome APP! 이 된다는 결론

다시 한번 짧게는, “프레임워크 키우지 말고 그러한 기능을 표준으로 정하고 표준대로 코딩하자.”라고 할 수 있을 것 같다.

image.png

WebComponents

오! 역시 구글은 다르구나! 다들 프레임워크 만들어 내기 위해 몰두해 있을 때, 프레임워크를 줄이는 것으로 방법을 찾다니! 그러한 시도의 중심에 WebComponents가 있다. WebComponents는 JavaScript, CSS, HTML들을 컴포넌트화하기 위해 필요한 4개의 표준을 묶어서 부르는 이름인데, 자세한 설명은 추후 붙이기로 하겠다.

프레임워크를 줄이려는 이러한 시도는 WebComponents의 최전방에 있는 Polymer를 보면 확인할 수 있는데, Polymer는 2.0으로 업데이트 되면서 1.0에서 가지고 있던 자체적인 문법들을 WebComponent 표준에 맞게 변경하였고, 프레임워크 사이즈는 최소 10kb까지 줄였다. jQuery 도 30kb는 되는 것을 생각해보면 참 놀라운 일이다.

Living Standard

image.png (이제는 Edge 역시 기특하게도 이러한 일을 하고 있다)

하지만 이러한 시도는 브라우저 제조사들끼리 표준의 합의가 필요할 뿐만 아니라, 프레임워크들이 업데이트 되듯, 브라우저가 빠르게 업데이트 될 수 있어야만 의미 있지 않을까? 다행히도 우리는 IE의 은퇴를 목전에 두고 있다. IE를 제외하고 봤을 때, 현재 주요 브라우저 제조사들(Google, Apple, MS, Mozilla …)은 Living HTML Standard라고 불리는 WHATWG에서 표준을 논의하며, 빠른 주기로 업데이트를 배포하고 있다. 또한 제조사들은 브라우저의 Status 페이지를 통해 브라우저가 현재 표준을 어떻게 지원하고 있는지, 계획 중인지, 개발 중인지 실시간으로 보여주기도 한다.

UseThePlatform 모토는 프레임워크를 선택해 그 위에서 개발하던 흐름에서, 동적인 브라우저 표준 위에서 개발하는 흐름으로의 변화라고도 볼 수 있다. 이는 구시대의 유물인 IE의 은퇴와 더불어 진정한 EverGreen 브라우저들의 시대와 함께하기에 가능한 이야기이다. 이러한 변화에 빠르게 올라타지 못하게 만드는 우리나라 IE점유율을 생각해보면 눈물이 날 지경이다. 만약 Window11과 함께 Edge2를 내보낸다거나 하는 만행을 저지른다면 정말 죽을 때까지 MS를 저주하고 싶을 것이다.


WebComponents는 왜 안보일까?

image.png (우리 국사책 표현식을 빌리자면 “프론트엔드 문제를 해결하기 위해 시작한 #UseThePlatform 운동” 이라고 할 수 있지 않을까?)

그렇다면 왜 우리는 아직 이러한 얘기의 중심에 있는 WebComponents를 얘기하는 사람이 주변에는 없는 것일까? 주변에서는 일단 시작하고 보는 AngularJS, 한창 뜨거운 React 얘기로 만 풍성하다. 이유야 여러 가지 있겠지만 종합하자면 WebComponents가 실제 프로젝트에 도입하기에 아직 준비되지 않았기 때문인 것 같다.

Custom Elements, v1은 v0에서 업데이트 되지 얼마 되지 않아, 브라우저 지원은 순차적으로 될 것이라 보이지만 Polyfill 조차 최근까지 활발히 커밋되고 있다. Shadow DOM 역시 v1로의 업데이트가 얼마 되지 않았으며, Polyfill 을 사용 하더라도 성능 문제를 가지고 있다. 더욱이 HTML Import의 경우는 여러 브라우저 개발사 가운데 그 효용에 대해서 이견이 있어 언제 지원이 될지 모르는 사정이다. 그나마 Template Element가 IE 제외하면 일찍이 모든 주요 브라우저에서 지원되고 있다.

#UseThePlatform - Frameworks

그렇다면 나는 WebComponents가 준비되지 않았다는 이야기를 하기 위해 #UseThePlatform를 시작으로 이처럼 긴 이야기를 했단 말인가? 물론 그렇지 않다. 이제부터는 다른 의미로 #UseThePlatform을 보려 한다. 비록 구글은 프레임워크 대신 브라우저 표준을 사용하라는 뜻을 밝혔지만 정 반대로, 괜찮아 이것은 또 다른 프레임워크가 아니니 “침착하고 쓰던 플랫폼(react, angular) 써.”라고 해석해 보려 한다.

이것이 무슨 이상한 해석이냐고 하겠지만 그렇지 않다. 내 맘대로 이긴 하지만, 구글 역시 이러한 생각을 가지고 있다고도 믿는다. 위에서 밝힌 대로, 비록 각 표준들은 준비되지 않은 상황이기는 하나, 4개의 표준은 뭉쳐야 하나가 되는 마법의 열쇠 조각 같은 존재가 아니라 개별적으로 쓸 수 있는 것들이다. 실제 구글의 Avocate Rob Dodson은 작년부터 다른 표준 기다리지 말고 CustomElements를 먼저 적용해서 사용해보기를 권하고 있다.

또한 WebComponents 표준들은 기존의 프레임워크들을 대체하기 위함이 아니라(못한다), 보완하기 위한 것이며, 구글과 페이스북을 포함한 프레임워크 제작자사들은 React vs WebComponents가 아닌 WebComponents with React, Angular, Ember 등에 관한 글도 쓰고 있다.

이처럼 #UseThePlatform을 브라우저로 해석하면 WebComponents의 목표가 될 것이며, React, Angular 등의 프레임워크로 해석하더라도 그 효용을 찾을 수 있다 하겠다. WebComponents의 이러한 유연성은 이것이 기존 프레임워크를 대체하는 또 다른 프레임워크가 아닌 웹 표준을 따르는 기술이기에 가지는 강점이다.

마치며

본 글을 시작할 때에는 WebComponents의 표준 중 하나인 CustomElements 소개하고자 이를 써야 하는 타당성에 대한 이야기로 시작했으나, 글이 길어지며 여기까지로 마감해야 하겠다. 많은 얘기를 담지 못해 아쉽지만 이번 글을 통해서 WebComponents에 대한 관심이 생겼기를 바라며, 이번에는 WebComponents 자체의 소개도 모자랐던 만큼 다음 글에서 소개와 함께 CustomElements에 대한 이야기를 해보도록 하겠다.

참고

최규우2017.04.28
Back to list