웹 컴포넌트 성공 사례

원문: https://jakelazaroff.com/words/the-web-component-success-story/

Tom MacWright는 최근 간단한 글을 통해 왜 웹 컴포넌트를 사용하는 유명한 애플리케이션은 눈에 띄지 않는가라는 질문을 던졌습니다.

매우 적절한 질문이라고 생각합니다! 리액트나 레일즈 같은 프레임워크의 성공은 이 프레임워크로 구축된 수천 개의 웹사이트를 보면 쉽게 알 수 있습니다. 그럼 웹 컴포넌트의 성공 사례는 어떤 모습일까요?

일부 사람들과 달리, 저는 웹 컴포넌트 자체가 개별 웹사이트의 생산성을 크게 향상한다고 보지 않습니다. 일단 특정 기술 스택을 선택하면, 그것을 최대한 활용하는 게 합리적입니다. 만약 리액트 앱을 개발하고 있다면, 컴포넌트를 구축하는 다른 방식을 도입하는 것에 대해 의구심을 갖는 것이 당연할 겁니다!

오히려 제가 보기에 웹 컴포넌트의 가장 큰 장점은 업계 전반을 아우르는 집단적인 이점입니다. 웹 컴포넌트는 전체 웹의 접근성을 높일 수 있다고 생각합니다. 현재 분열된 커뮤니티, 다양한 자바스크립트 프레임워크와 이를 기피하는 사람들을 아울러 통합할 잠재력이 있습니다.

저도 이게 무모한 주장이라는 걸 압니다. 하지만 제 말씀을 들어주시길 바랍니다.

자바스크립트 프레임워크 상호운용성

웹 컴포넌트에 대해 글을 쓸 때마다, 자바스크립트 커뮤니티의 일부 사람들에게 저항을 받습니다. 그들은 제가 자바스크립트 프레임워크를 웹 컴포넌트로 대체하려 한다고 생각합니다.

만약 여러분이 그런 생각을 하고 계셨다면, 걱정 마십시오. 웹 컴포넌트 성공 스토리는 모든 리액트 앱을 웹 컴포넌트로 다시 작성하는 것이 아니라는 점을 분명히 말씀드리고 싶습니다. 제가 계속 말씀드리겠지만, 웹 컴포넌트와 자바스크립트 프레임워크는 상호 보완적인 (경쟁 관계가 아닙니다) 기술입니다. 사실 저는 자바스크립트 프레임워크 앱이 웹 컴포넌트가 가장 많이 사용되는 곳 중 하나가 될 거라고 생각합니다!

그렇다고 우리가 리액트 컴포넌트 외에 웹 컴포넌트까지 작성하기 시작할 거라는 뜻은 아닙니다. 제가 자바스크립트 웹 컴포넌트가 프레임워크 앱에서 사용될 거라고 할 때, 이는 서드파티 라이브러리를 말하는 것입니다.

자바스크립트 프레임워크는 도구이며, 모든 도구에는 장단점이 있다는 것은 다들 알 것입니다. 그런 설명은 제쳐두고, 저는 자바스크립트 프레임워크의 한 가지 약점에 대해 이야기하고 싶습니다. 바로 상호운용성 부족입니다. 거의 예외 없이 각 프레임워크는 그 프레임워크를 위해 특별히 작성된 컴포넌트만 렌더링할 수 있습니다.

그 결과 자바스크립트 커뮤니티는 프레임워크 경계에 따라 스스로 분열되는 경향이 있습니다. 프레임워크를 전환하는 데는 큰 비용이 발생하며, 특히 덜 인기 있는 프레임워크로 이동할 때는 더욱 그렇습니다. 이는 대부분의 서드파티 생태계를 포기해야 한다는 것을 의미합니다.

이런 전환 비용은 기존의 거대 생태계를 가진 프레임워크에 크게 선호함으로써 프레임워크 혁신을 저해합니다. 새로운 프레임워크를 만들기는 어려운데, 생태계를 처음부터 다시 시작해야 하므로 동일한 기본 요소 세트를 계속해서 반복적으로 재구축해야 하기 때문입니다.

Joel Spolsky의 유명한 블로그 글에는 자본주의 기술 기업들이 오픈 소스에 기여하는 이유에 대한 설명이 나와있습니다. 간단히 말해, 모든 제품에는 대체재 (그것을 대체할 수 있는 제품)과 보완재(그것과 함께 사용될 수 있는 제품)이 있습니다. 중요한 점은 "똑똑한 회사는 자신의 제품의 보완재를 상품화하려고 노력한다"는 것입니다. 다시 말해, 그들은 자신의 제품만 독점적 이점을 갖도록 하고, 함께 사용되는 제품은 모두 저렴하고 상호 교환 가능하게 만들려고 합니다.

자바스크립트 프레임워크로 돌아가 봅시다. 리액트와 스벨트는 대체재이고, 리액트와 Radix는 보완재입니다. 라이브러리 작성자로서 보완재를 상품화하는 방법은 가능한 한 많은 프레임워크에서 작동하도록 만드는 것입니다. (1) 그리고 수십 년 동안 수십억 달러를 들여 한 번 작성하면 어디서나 실행할 수 있는 환경을 개발해 온 네이티브 앱과 달리, 웹에는 이러한 환경이 이미 갖춰져 있습니다.

(1): Meta는 이를 이해하고 있기에 리액트 네이티브를 만들었습니다. 프레임워크는 플랫폼의 보완재이고, 플랫폼을 상품화하는 방법은 프레임워크를 가능한 많은 플랫폼에서 실행되도록 만드는 것입니다.

들어보셨겠죠? HTML라는걸요. HTML은 모든 자바스크립트 프레임워크에서 작동합니다. 모든 결점에도 불구하고 웹 컴포넌트가 이런 상호운용성을 무료로 얻을 수 있다는 사실은 엄청나게 강력한 이점이며, 이를 활용하지 않는 라이브러리는 많은 잠재 사용자를 테이블 위에 남겨두는 셈입니다.

구체적인 예를 들어보겠습니다. xyflow는 플로우 차트를 만드는 훌륭한 라이브러리입니다. 원래는 React Flow라고 불렸지만, 스벨트 지원을 추가하면서 이름을 바꿨습니다. 단 하나의 추가 프레임워크를 지원하기 위해서 엄청난 작업을 해야 했죠! 그리고 뷰, 앵귤러, 솔리드, 퀵(Qwik), 엠버를 사용하고 있다면 여전히 그런 지원을 받지 못하고 있는 것입니다.

리액트는 Radix, React Aria, React Three Fiber, Framer Motion, xyflow 등 환상적인 서드파티 라이브러리들이 해자 역할을 해주어 계속 성공을 거두고 있습니다. 웹 컴포넌트에는 모든 프레임워크에 걸쳐 동일한 생태계를 제공할 잠재력이 있습니다.

상호작용성의 섬

물론 많은 웹사이트들이 자바스크립트 프레임워크를 사용하지 않습니다. 하이퍼미디어 중심 접근법(즉, 2010년 이전에 웹사이트가 만들어지던 방식)이 htmx와 같은 라이브러리의 주도로 다시 부상하고 있습니다.

이런 웹사이트 중 상당수는 여전히 매우 동적인 요소를 포함하고 있습니다. 이들은 메뉴나 콤보 박스 같은 HTML에 없는 풍부한 위젯 형태로 나타납니다. 때로는 대화형 다이어그램처럼 더 복잡하기도 합니다. 이렇게 정적인 페이지 내에 존재하는 동적 영역을 최근에는 "상호작용성의 섬"이라고 부르지만, 이 패턴은 오래전부터 존재해 왔습니다.

이런 상호작용성의 섬들을 더 큰 페이지에 내장하는 것은 항상 약간 어색했습니다. 이 과정은 HTML 클래스, CSS 선택자, 자바스크립트 함수 호출의 복잡한 연계에 의존하는 jQuery 플러그인 시절과 크게 달라지지 않았습니다. 대부분의 설정은 컴포넌트가 위치할 HTML과 동떨어진 별도의 자바스크립트 파일에서 이루어집니다.

웹 컴포넌트는 이 과정을 반전시킵니다. 웹 컴포넌트를 사용하면 페이지 마크업에 태그 이름을 작성하는 것처럼 다른 요소와 동일한 방식으로 섬을 인스턴스화할 수 있습니다. 웹사이트와 웹앱의 이분법은 존재하지 않는다는 제 글에서 언급했듯이, 웹 컴포넌트는 개발자가 선언적으로 HTML 자체에 동적 동작을 추가할 수 있게 해 줍니다.

웹 컴포넌트가 하이퍼미디어 지향 라이브러리의 특히 좋은 동반자가 되는 이유는 페이지의 다른 부분과 상호작용하는 방식 때문입니다. 자바스크립트 프레임워크 컴포넌트는 콜백 함수를 호출하는 방식으로 이를 수행하는 반면, 웹 컴포넌트는 웹의 핵심 개념 중 하나인 이벤트를 채택하고 있습니다. (2) 실제로 Carson Gross의 에세이 하이퍼미디어 친화적 스크립팅은 이 사용 사례를 깔끔하게 요약하고 있습니다.

(2): 섬 접근법이 자바스크립트 프레임워크를 포기하는 것을 의미하는 것은 아닙니다. 웹 컴포넌트로 자바스크립트 프레임워크 종속 제거라는 제 글에서 웹 컴포넌트가 디커플링 도구로서 자바스크립트 프레임워크와 함께 사용될 수 있음을 보여주었습니다. 일부 프레임워크는 웹 컴포넌트로 컴파일하는 것을 기본적으로 지원하기도 합니다. 요점은 자바스크립트 프레임워크를 사용해 섬을 구축하는 것이 쉽다는 것입니다.

이벤트를 트리거하는 자바스크립트 기반 컴포넌트는 htmx와 같은 하이퍼미디어 지향 자바스크립트 라이브러리가 해당 이벤트를 수신하고 하이퍼미디어 교환을 트리거할 수 있게 해 줍니다. 이는 결과적으로 모든 자바스크립트 라이브러리를 잠재적인 하이퍼미디어 컨트롤로 만들어, 사용자가 선택한 작업을 통해 하이퍼미디어 중심 애플리케이션을 구동할 수 있게 합니다.

예를 들어, 제가 TIL로 작성한 htmx와 Shoelace 웹 컴포넌트 라이브러리를 사용하여 다이얼로그 콘텐츠를 로드하기가 있습니다. 다이얼로그 컴포넌트를 인스턴스화하는 것부터, 모달이 열릴 때 콘텐츠를 요청하는 것, DOM의 적절한 위치에 삽입하는 것까지 전체 프로세스가 선언적으로 마크업을 통해 제어되는 것에 주목하세요.

또한 새로운 DOM을 렌더링하지 않고 기존 마크업을 점진적으로 개선하는 방식으로 동작하는 HTML 웹 컴포넌트도 있습니다. 이런 식으로 로직을 한곳에 모으는 것을 때로는 동작의 지역성이라고 부르는데, 이는 자바스크립트 개발자들에게 이미 친숙한 개념을 다른 관점에서 바라본 것입니다.

더 이상 고립은 없습니다

이는 별개의 문제처럼 들리지만, 사실은 동전의 양면과 같습니다. 웹 컴포넌트를 사용하면 모든 자바스크립트 프레임워크에서 작동하는 라이브러리가 또한 정적 웹페이지의 상호작용성 섬으로도 작동합니다. 심지어 HTML 웹 컴포넌트도 양쪽 모두에 해당합니다.

Brad Frost는 "현재 대부분의 디자인 시스템에서 발견되는 공통 UI 컴포넌트를 포함하는 공통 라이브러리"인 글로벌 디자인 시스템을 제안했습니다. 이 제안은 Radix처럼 일관되고 스타일이 지정되어 있지 않으며 접근성이 좋고 국제화할 수 있는 컴포넌트 집합을 만드는 것을 목표로 합니다. 하지만 단일 자바스크립트 프레임워크가 아닌 전체 웹을 대상으로 한다는 점에서 차이가 있습니다. 이는 꽤 야심 찬 목표이며, 웹 컴포넌트는 이를 달성하는 가장 좋은 방법으로 보입니다.

웹 컴포넌트가 웹 개발 생태계를 완전히 변화시키거나 웹사이트를 구축하는 단 하나의 진리를 보여주지는 않을 것입니다. 자바스크립트 프레임워크를 몰아낼 필요도 없죠. 아마도 모두가 웹 컴포넌트를 작성하는 방법을 다 알아야 하는 것도 아닐 겁니다!

웹 컴포넌트가 앞으로 할 일은 (적어도 제가 희망하기로는) 어떤 웹 기술 스택과도 호환되는 풍부한 동적 컴포넌트 생태계를 함께 구축하는 것입니다. 더 이상 고립은 없습니다. 이것이 바로 웹 컴포넌트 성공 스토리입니다.