HTMX와 알파인(Alpine)은 낮은 오버헤드로 프론트 엔드를 강화하는 두 가지 방법이다. 모두 빌드 단계가 필요 없고 번거로운 작업을 최소화하면서 AJAX 스타일의 API 호출과 클라이언트 측 UI 업데이트를 추가할 수 있게 해준다. 좋아하지 않을 이유가 있을까?

알파인과 HTMX 개요

HTMX와 알파인은 모두 하나의 핵심 아이디어를 기반으로 하며, 각자 그 핵심 사명에 잘 집중하고 있다. HTMX의 사명은 HTML 속성을 활용해서 HTML이 기본적인 AJAX와 세밀한 뷰 업데이트를 수행할 수 있도록 함으로써 웹이 진정한 RESTful 설계를 따르도록 하는 것이고, 알파인의 사명은 상태와 반응성을 HTML 속성에 담을 수 있는 작은 패키지로 구성하는 것이다.

여기서 두 프레임워크의 공통점을 명확히 볼 수 있다. 둘 다 HTML 속성을 주요 메커니즘으로 사용한다는 점이다. 개인적으로는 이것이 탁월한 접근 방법이라고 생각한다. HTML은 웹 개발의 모든 부분에서 사용되기 때문이다. 어떤 경우든 결국에는 얼마간의 HTML(또는 HTML과 유사한 JSX 등)을 작성해야 한다. HTML은 UI의 구조이고, 여기에 필요한 동작을 덧붙임으로써 부가적으로 생각하고 관리해야 할 요소를 피할 수 있다.

관심사의 분리

HTMX와 알파인에 대한 공통적인 비판은 HTML과의 근접성이다. 즉, 뷰와 동작의 분리를 촉구하는 관심사의 분리에 반한다는 것이다. 필자도 원칙적으로는, 특히 크고 구조가 복잡한 앱에 있어서는 그 주장에 대해 이견이 없다. 그러나 HTMX의 경우 사실 HTML의 확장에 불과하다는 점에서 이 비판에 그다지 큰 의미는 없다고 생각한다. (또한 전에도 말했듯이 필자는 HTMX가 HTML 안에 들어가는 것은 시간 문제일 뿐이라고 생각한다.)

알파인 역시 일종의 HTML의 확장으로 볼 수 있다. 다만 알파인에서는 HTML 속성에 포함된 자바스크립트를 직접 다루게 되고, 이 경우 HTML은 자바스크립트라는 언어를 구사할 수 있다.

여기서 관건이 되는 질문은 툴이 프로젝트의 필요 사항을 충족하는지 여부다. AJAX와 몇 가지 소소한 동적 UI 상호작용을 최소한의 오버헤드로 구현하는 것이 핵심 요구사항이라면 당연히 이 두 라이브러리를 모두 고려해야 한다.

알파인과 HTMX를 함께 사용하기

코드를 살펴보기 전에 강조하고 싶은 점은 알파인과 HTMX를 같이 사용할 수 있다는 것이다. 예를 들어 HTMX가 가장 잘하는 일, 즉 백엔드에서 데이터를 처리하는 일에 HTMX를 사용하고, 알파인에는 클라이언트 측 강화 작업(드롭다운, 아코디언, 클라이언트 측 필터링 등)을 맡기는 방식을 고려해 보자. 예를 들어 HTMX로 목록 데이터를 로드한 다음 알파인으로 필터링할 수 있다. 이 두 가지를 결합하면 비교적 간단한 AJAX 상호작용에는 HTMX를 사용하고, 더 정교한 상호작용(HTMX만으로는 클라이언트에서 데이터를 변환하기가 용이하지 않은 경우)에는 알파인을 사용할 수 있게 된다.

HTMX를 HTML의 확장으로 생각하면 이 두 가지 조합은 완벽하게 합리적이다. 즉, 기본적으로 HTML을 확장 기능과 함께 사용하면서 부가적인 기능을 위해 작은 공간 내에 알파인을 추가하는 것이다.

상태는 어디에?

HTMX에서 상태는 서버에 위치한다. HTMX는 서버로부터 상태를 나타내는 HTML 청크를 받는다. (이것이 사실 REST와 HATEOAS의 본질이며, 웹의 작동 원리에 대한 이해를 심화하기 위해 탐구해 볼 만한 부분이다.) HTMX는 백그라운드(AJAX) 요청을 시작하는 속성을 사용한 다음 응답으로 UI를 업데이트한다. 다음은 x-get을 사용하는 간단한 예시다.

이 경우 응답은 다음과 같다.

Get Up, Stand UpWildflowersTo the Sea

클라이언트에 도달하면 HTMX는 이를 적절한 위치에 배치해서 상태에 대한 서버 중심 뷰를 제공한다.

알파인에서 상태는 서버에 존재할 수 있지만 클라이언트에도 있다. 위와 동일한 예시를 일반적인 알파인 방식으로 바꾸면 다음과 같이 된다.

여기에서 x-data는 알파인 구성요소를 생성하는 속성이며, 필요한 클라이언트 측 상태(albums)와 서버에서 데이터를 가져오는 맞춤형 메서드(fetchAlbums)를 정의한다. 순서 없는 목록(

) 내부의 뷰는 부가적인 알파인 속성(x-for 및 x-text)을 사용해 반복을 수행하고 상태를 화면에 출력하는 방법을 설명한다.

상태는 x-data 속성에 저장된다. 알파인의 역할은 이 상태를 가져와서 UI가 자동으로 이를 반영하도록 하는 것이다. 서버의 데이터는 알파인의 fetch 호출로 수신되는 즉시 뷰에 렌더링된다. 이 예시에서 반환되는 데이터는 다음과 같다.

[   { "id": 1, "name": "The Dark Side of the Moon" },   { "id": 2, "name": "Kind of Blue" },   { "id": 3, "name": "Abbey Road" },   { "id": 4, "name": "Rumours" }]

HTMX 데이터와 알파인의 데이터를 비교해 보면 REST(상태 표현, 즉 뷰가 전송되는 방식)와 유사 REST(일반적으로 JSON API로 구현되는 방식)의 차이가 매우 분명하게 드러난다. HTMX는 상태가 포함된 실제 뷰의 청크를 전송하려고 하고, 알파인은 데이터 형식(JSON)의 청크를 전송한 후 클라이언트에서 변환하려고 한다.

여기에 뚜렷한 정답 또는 “승자”는 없다. 그러나 HTMX에는 클라이언트 측 단순성이라는 커다란 장점이 있다. 알파인도 뛰어난 유연성과 함께 높은 수준의 단순성을 제공한다. 알파인의 속성은 실제로 자바스크립트이므로 알파인에서는 자바스크립트로 무엇이든 할 수 있다. (또한 HTML에 인라인 포함되는 자바스크립트가 번거롭게 느껴지기 시작하면 자바스크립트를 script 태그 안으로 끌어와도 된다.)

HTMX와 알파인을 결합해야 할 때

HTMX은 HTML을 사용해 서버와 상호작용하는 가장 간단한 방법이 되고자 하며, 실제로 그 일을 매우 잘 해낸다. 또한 매우 유연하므로 일부 요구사항이 HTMX의 범위 내에 없다고 너무 성급하게 판단하면 안 된다. HTMX 데모 페이지에서 무한 스크롤, 입력 자동 완성, 클라이언트 및 서버 측 필드 검증을 비롯해 HTMX에서 처리할 수 없을 것이라고 속단하기 쉬운 다양한 예시를 확인할 수 있다. (웹소켓 확장까지 있다.)

물론 UI 상호작용이 정교해질수록 더 복잡해지고, 그건 어쩔 수 없는 일이다. 그렇다면 HTMX로는 부족해서 알파인을 동원할 만한 시나리오를 고려해 보자. 기본 자바스크립트와 그 자매 프로젝트인 하이퍼스크립트 등 HTMX의 핵심 기능을 강화하기 위해 사용할 수 있는 접근 방식은 많지만 알파인도 아주 좋은 선택이다.

HTMX와 함께 알파인을 사용할 만한 확실한 사용례는 클라이언트 측 코드를 세련되게 만들어야 하는 경우다.

    Combined Example        

All Electronics Clothing

이 예시에서는 선택된 범주를 기반으로 제품을 로드하기 위해 HTMX를 사용한다. 일종의 서버 측 필터링으로, HTMX로 가뿐히 할 수 있는 일이다. 그러나 제품이 로드된 후에 알파인을 사용해서 제품 세부정보를 표시하거나 숨기는 기능을 지원하고자 할 수 있다.

이 예시에서 유의할 부분은 개별 제품 항목이 아닌 div에 클릭 핸들러를 연결한다는 점이다. 제품 항목은 서버에서 전송됐다. 서버에서 클라이언트 측 알파인 클릭 핸들러가 생성되지 않기를 원하는 이유는 코드를 깔끔하게 유지하기 위해서다. 핸들러는 클릭된 항목을 가져와 알파인의 뛰어난 클라이언트 측 상태 지원을 사용해 제품 세부정보 창을 동적으로 표시하고 내용을 채운다. 이 예시에서는 간단한 event.target.innerHTML을 통해 제품 세부정보만 가져오지만 각 툴의 장점을 활용하는 이런 종류의 조합을 통해 많은 일을 할 수 있다.

JSON 데이터에 알파인 사용하기

알파인과 HTMX를 함께 사용하는 더 깊이 있는 예로, 제출 시 일부 데이터를 변환해야 하는 경우를 생각해 보자. HTMX는 HTML 표준 데이터 형식 사용을 고수하는데, JSON을 사용하고자 하는 API가 있다면 어떻게 될까?

HTMX에는 JSON 호출을 처리할 수 있는 JSON 확장이 있지만 이미 알파인을 사용 중이라면 계속 알파인을 사용하기를 원할 수 있다. HTML을 이해하는 모든 엔드포인트에서 HTMX를 사용하고, JSON 엔드포인트에 대해서는 알파인의 불러오기(fetch) 메커니즘을 적용해도 된다. (데이터 불러오기 대한 자세한 내용은 알파인.js 페이지에서 볼 수 있다.)

결론

필자는 소프트웨어 라이브러리를 판단할 때 “무게 대비 기능성 비율(weight-to-capability ratio)”이라는 개념을 사용한다. 기본적으로 이 비율은 프로젝트와 내 뇌에 얼만큼의 세부정보를 추가할 수 있는지와 그것으로 얼만큼의 일을 할 수 있는지를 나타내는 비율이다.

HTMX와 알파인은 둘 다 무게 대비 기능성 측면에서 탁월하다. HTML을 이해하는 백엔드를 사용하고자 하는 사람이라면 당연히 HTMX를 선택할 것이다. 깔끔하고 강력한 리액티브 프레임워크가 필요하다면 알파인이 확실한 선택이다. 둘 다 필요하다면 그냥 함께 사용하면 된다.
dl-itworldkorea@foundryco.com