티스토리 뷰

분류없음

왜 Web Component가 중요한가

한장현 2016.07.01 17:26

다음 글의 번역입니다. [Why web components are so important - Leon Revill]

If writer does not want this article, please contact me.(han41858@gmail.com)


 수년간 Web Component 에는 수많은 이야기가 오르내렸다. Web Component 가 웹 구축 방식을 바꿀것이라고 하는데 ㅡ 왜 그런지, Web Component 의 어떤 점이 중요할까?

Web Component 는 캡슐화, 웹에 대한 사용자 인터페이스 단위의 재사용에 대해 표준화된 결과물이다.


새로운 컨셉은 아니다.

 웹에서 Component 에 대한 개념은 오래 전부터 있었고, 재사용 가능하고 가벼운 코드에 대한 아이디어는 새로운 것이 아니다.

jQuery 플러그인

 jQuery 플러그인은 재사용 가능한 코드 조각을 작성하려는 시도로써 주목을 받았던 것으로는 처음이었을 것이다. jQuery 플러그인은 코드를 어떻게 작성해야 하는지, 어떻게 쉽게 코드를 배포할 수 있는지에 대한 구조를 제공했지만, 문제가 좀 있었다.

 다른 플러그인들을 사용하면서 충돌이 나기도 했을 것이고, 어떤 스타일을 선택적으로 포함해야 하는지에 대한 이슈도 해결해야 했었다.


AngularJS 디렉티브

 다음 세대의 Directive는 몇가지 추가적인 이점을 제공했다. 각 컴포넌트마다 JavaScript 스코프를 분리하여 충돌을 방지할 수 있었고 구성에 대한 정의(definition)가 좀 더 가능해지면서 더 나은 툴의 지원을 받을 수 있었다. 그러나 여전히 스타일을 개별적으로 포함해야 했었고 API 는 복잡하며 배우기 어려웠다.


프레임워크 컴포넌트

 이 컨셉의 가장 최근의 시도는 모던 프레임워크의 컴포넌트이며 Angular 2 와 React 에서 찾을 수 있다. 더 나은 API를 제공하는 클래스와 같은 최근의 JavaScript 기능을 기반으로 만들어졌다. Angular 2에서는 개발자들이 메타데이터를 이용하여 컴포넌트를 꾸미는(decorate) 것을 허용하기 때문에 개발툴을 사용하면서 다른 개발자와 소통(interact)하는 것을 돕기도 한다. 또한 당신이 작성한 컴포넌트에서 완전히 캡슐화된 상태의 Shadow DOM 으로 사용할 수도 있다.



왜 결국 컴포넌트일까?

 왜 웹 컴포넌트가 이렇게 중요한지를 이해하기 전에, 먼저 몇가지 특징을 갖고 잇는 컴포넌트에 대해 생각해보자.


캡슐화

 컴포넌트는 메인 어플리케이션과 완전히 분리되어야 한다. 이로써 재사용성, 테스트 가용성, 신뢰성이 높아지는데, 왜냐하면 컴포넌트가 내부적인 동작에 반응할 뿐이지 어플리케이션의 상태에 관여하지 않기 때문이다.

 컴포넌트의 작성자와 사용자 모두 컴포넌트를 업그레이드 할 때 어플리케이션의 나머지 부분에 영향을 미칠 것인지 걱정하지 않아도 될 것이다.


확장성

 컴포넌트는 각각이 확장 가능해야 하며 웹에서는 DOM 객체가 그러하다. 이 말은, 코드 작성자가 바퀴를 다시 발명할 필요가 없이 이미 있는 기능을 다시 사용하기 쉬워야 한다는 것이다.


결합성

 아주 복잡한 컴포넌트나 심지어 하나의 어플리케이션을 컴포넌트의 조합으로 만들 수도 있다. '전역' 로직의 감소는 좀 더 나은 아키텍처를 가능하게 하며 버그가 발생할 가능성을 줄이는데, 각각의 조각들이 (컴포넌트의 조합이라도) 좀 더 나은 방식으로 만들어지기 때문이다.


재사용성

 중요하다. 위에 설명한 것들이 모두 쉽게 재사용하기 위한 것이며 의존도를 낮추고 좀 더 간결하고 명확한 API 를 위한 것이다.


 위에서 언급한 세 개의 컴포넌트 타입 중에서 위 장점들을 모두 만족하고 있는 것은 프레임워크 컴포넌트이다. 게다가 완전히 캡슐화된 상태의 Shadow DOM 을 사용할 수 있는 것도 프레임워크 컴포넌트 뿐이다.


완전히 캡슐화된 Shadow DOM

 Shadow DOM 은 최종적으로 완전히 캡슐화된 sub-DOM 트리를 제공하며 외부 스타일에 영향을 받지 않는다. 이 말은, 컴포넌트 작성자로써 당신의 컴포넌트가 어떻게 보일지 완벽하게 조작할 수 있으며, 사용자가 컴포넌트에 영향을 주지 못하게 할 수 있다는 것이다.

 다행스럽게도 Angular 와 React 컴포넌트를 이용하면 Shadow DOM 을 사용할 수 있다.


왜 웹 컴포넌트인가?

 프레임워크가 이런 장점들을 모두 제공한다면, 왜 웹 컴포넌트가 필요할까? 큰 이유는 상호운용성(Interoperability) 때문이다.

 프레임워크 컴포넌트는 훌륭하지만 그 생태계 안에서만 훌륭할 뿐이다. Angular 컴포넌트 안에서 React 를 (쉽게) 사용할 수 없고 반대의 경우도 그렇다. (역주 : 사용할 수는 있지만 완벽하게 같은 맥락으로 동작할 수 없다는 의미로 보입니다.)


왜 이것이 문제인가?

 프론트엔드 개발자 커뮤니티에서는 수많은 툴과 프레임워크, 라이브러리, 기술들을 소개하고 있지만 모든 것을 따라가기는 정말 어렵다.

 개발자로서, 비즈니스적으로나 사용자의 요구에 의해서 어플리케이션을 만드는 방식을 바꾸지만 기존에 있던 것을 유지하면서 새로운 기술을 도입하고 싶다. 이전에는, 특정 기술 셋 안에 갇혀서 업그레이드가 아주 어려웠기 때문에 어쩌면 어플리케이션을 재작성해야 하는 경우도 있었다.

 웹 컴포넌트는 웹 표준 이외에는 어떤 것도 관여하지 않았기 때문에 어떤 생태계에서든지 동작하며, 이것은 몇가지 큰 장점이 있다.

  • 상호운용성 (Interoperability) - 당신의 컴포넌트는 프레임워크를 넘어서서 다른 기술 스택의 프로젝트에서도 동작할 것이다.
  • 수명 (Lifespan) - 당신의 컴포넌트가 상호운용가능하기 때문에 더 긴 수명을 갖게 되고, 새 기술에 맞춰 재작성해야할 필요가 줄어든다.
  • 가용성 (Portability) - 당신의 컴포넌트가 특정 라이브러리나 프레임워크게 의존하지 않는다면, 컴포넌트가 의존성 없이 어디에도 동작하기 때문에 도입에 대한 장벽이 상당히 낮아진다. 
 컴포넌트에 대한 이런 장점들은 모두 웹 컴포넌트에도 적용되며 상호 호환을 돕기 떄문에 웹 생태계는 좀 더 역동적인 방향으로 나아갈 것이다.



웹 컴포넌트 라이브러리
 웹 컴포넌트 표준은 끊임없이 변화하고 있고 문서나 예제, 튜토리얼들이 부족해서, 사람들이 웹 컴포넌트를 시작하기 상당히 어려웠었다. 이전 브라우저를 지원해야 한다면 더욱.

인기를 끌고 있는 웹 컴포넌트 라이브러리들

 이렇기 때문에 몇 개의 웹 컴포넌트 라이브러리가 웹 컴포넌트를 상당히 쉽게 만들 수 있도록 개발되었고, 가장 인기있는 라이브러리는 Polymer, X-Tag, Bosonic 이 있다. 이 라이브러리들은 모두 사용 가능한 컴포넌트 셋을 제공하며 확장도 가능하다. 인기있는 라이브러리답게, 풍부한 문서, 예제가 제공되고 그 뒤에 굳건한 커뮤니티도 있다.

 이 라이브러리들을 사용한다는 것은 당신의 컴포넌트가 이 라이브러리에 강한 의존성을 갖게 되고, 컴포넌트 사용자들도 라이브러리를 사용해야 하는 것을 의미하기는 한다.

 웹 컴포넌트 표준이 점차 명확해지고 훌륭한 예제들이 만들어지고 있기 때문에, 누군가 웹 컴포넌트 작성을 시작하려고 한다면 vanilla 를 이용해서 처음으로 만들어보고 어떤 점이 요구사항에 맞는지 확인하는 것이 좋을 것이다.


결론

 웹 컴포넌트는 우리가 작성하는 어플리케이션이 변화에 빠르게 적응할 수 있는 방식을 제공하기 때문에 아주 중요하다. 이로써 비즈니스나 사용자의 요구를 대응하기 위해 새롭고 신기한 프론트엔드 기술을 빠르게 적용할 수 있으며, 어플리케이션의 상당 부분을 다시 작성할 필요가 없을 것이다.

 우리의 코드는 웹 표준을 기반으로 만들어져 웹 컴포넌트 생태계에서 상호호환이 가능하기 때문에 좀 더 긴 수명을 갖게 될 것이고, 최종적으로 우리 컴포넌트는 종속성이나 요구사항이 적기 때문에 좀 더 많은 사람들에게 도달할 것이다.

 웹 컴포넌트는 사용할 준비가 되어 있고 지금 사용해보자! 나는 웹 컴포넌트를 더 빠르게 보급하기 위해 좀 더 많은 예제나 튜토리얼을 만들어 커뮤니티에 참여하고 있다.

 연락이 필요하다면 @RevillWeb 에서 찾을 수 있다.

댓글
  • 프로필사진 박성민 잘 보고 있습니다~특정 기술 셋 안에 갇혀서 업그레이드가 아주 어려웠기 때문에 '어떠면' 어플리케이션을 재작성해야 하는 경우도 있었다. -> '어떠면' 오타인 것 같아요 2016.07.03 21:45 신고
  • 프로필사진 BlogIcon 한장현 오타였네요!! 수정했습니다~ 찾아주셔서 감사합니다 ㅎㅎ 2016.07.03 23:05 신고
댓글쓰기 폼
공지사항
Total
295,220
Today
56
Yesterday
69
링크
«   2018/11   »
        1 2 3
4 5 6 7 8 9 10
11 12 13 14 15 16 17
18 19 20 21 22 23 24
25 26 27 28 29 30  
글 보관함