HTMX 4.0, 리액트의 복잡성에 제동을 걸다

웹 개발에서는 어느새 화면 하나를 띄우는 일마저 거대한 프로젝트가 됐습니다. HTMX 4.0에 관심이 쏠린 건 새로운 기능보다 더 근본적인 질문 때문입니다. 웹 애플리케이션에 정말 이만큼 많은 자바스크립트가 필요할까요?

그렇다고 출시 직후의 열기를 숫자로 단정하기는 어렵습니다. 최근 30일 동안 확인할 수 있는 커뮤니티 자료가 충분하지 않았습니다. 그래서 이번 글에서는 과장된 반응보다 HTMX가 던지는 설계상의 질문을 자세히 들여다보겠습니다.

HTMX는 무엇을 되돌리려는가

리액트 중심의 웹 애플리케이션은 보통 서버에서 JSON 데이터를 받습니다. 브라우저는 이 데이터를 상태로 저장한 뒤 자바스크립트로 화면을 다시 그립니다.

복잡한 서비스를 만들 때는 유용한 구조입니다. 하지만 간단한 검색창이나 관리자 페이지를 만드는 데도 상태 관리, API 설계, 빌드 도구가 따라붙습니다.

HTMX의 방식은 다릅니다. HTML 요소에 hx-get, hx-post, hx-target 같은 속성을 붙이면 브라우저가 서버에 요청을 보냅니다. 서버는 JSON이 아니라 완성된 HTML 조각을 돌려줍니다.

예를 들어 “더 보기” 버튼을 누르면 서버는 다음 목록의 HTML만 반환합니다. HTMX가 그 조각을 지정된 영역에 끼워 넣습니다. 화면을 갱신하려고 별도의 컴포넌트 상태를 만들 필요가 없습니다.

이런 방식을 하이퍼미디어 기반 개발이라고 합니다. 링크와 폼이 다음 행동을 설명한다는 웹의 원래 원리를 더 다양한 상호작용으로 넓힌 겁니다.

HTMX 4.0이라는 큰 버전 변화가 눈길을 끄는 데는 분명한 이유가 있습니다. 프론트엔드 생태계가 당연하게 여겨 온 복잡성을 다시 따져 묻게 하기 때문입니다.

리액트식 구조에서는 서버와 클라이언트가 저마다 데이터 모델을 관리할 때가 많습니다. 같은 검증 규칙과 화면 상태가 양쪽에 나뉘어 있기도 합니다. 그러다 보면 작은 기능 하나를 고치면서 API, 타입, 캐시, 컴포넌트까지 함께 수정해야 합니다.

HTMX는 이 책임을 서버 쪽에 모읍니다. 서버가 화면의 현재 상태를 파악해 HTML을 만들어 주는 방식입니다. 백엔드 템플릿을 써 본 개발자라면 익숙할 겁니다.

그러니 HTMX 4.0의 핵심은 “새로운 자바스크립트가 나왔다”는 데 있지 않습니다. HTML도 충분히 애플리케이션의 인터페이스가 될 수 있다는 주장에 가깝습니다.

HTMX를 쓰면 브라우저에 내려가는 자바스크립트의 양과 빌드 과정은 줄어들 수 있습니다. 그렇다고 복잡성 자체가 사라지지는 않습니다. 그 복잡성이 다른 곳으로 옮겨갈 뿐입니다.

서버는 전체 페이지뿐 아니라 여러 형태의 HTML 조각도 반환해야 합니다. 뒤로 가기, 로딩 상태, 오류 처리, 포커스 이동도 빠뜨릴 수 없습니다. 응답 조각 사이의 규칙을 제대로 정리하지 않으면 템플릿이 또 다른 스파게티가 됩니다.

HTMX도 자바스크립트로 작동합니다. “자바스크립트 없는 개발”이라는 표현은 정확하지 않습니다. 개발자가 직접 관리해야 할 클라이언트 코드의 양을 줄여 주는 도구라고 보는 편이 맞습니다.

접근성 역시 저절로 해결되지 않습니다. 화면 일부가 바뀌면 보조 기술도 이를 알아차릴 수 있도록 설계해야 합니다. 빠르게 만들 수 있다고 해서 기본기를 건너뛰어도 되는 건 아닙니다.

HTMX는 서버가 중심이 되는 업무에 특히 잘 맞습니다. 관리자 페이지, 게시판, 예약 시스템, 전자상거래의 장바구니처럼 요청과 응답의 경계가 뚜렷한 서비스가 그렇습니다.

사용자가 버튼을 누르고 서버의 결과를 확인하는 흐름이라면 효과가 큽니다. 팀이 관리해야 하는 상태와 코드가 줄어듭니다. 서버 렌더링 덕분에 첫 화면도 빠르게 보여주기 쉽습니다.

반면 브라우저 안에서 수많은 상태가 동시에 움직이는 제품은 상황이 다릅니다. 영상 편집기, 디자인 도구, 복잡한 드래그앤드롭 화면, 오프라인 우선 앱 같은 제품입니다. 이런 서비스에는 리액트 같은 클라이언트 중심 구조가 더 자연스러울 수 있습니다.

결국 유행이 선택의 기준이 되어서는 안 됩니다. 상태의 주인이 누구인가를 따져야 합니다. 상태의 대부분을 서버가 관리한다면 HTMX가 유리합니다. 브라우저가 실시간으로 상태를 계산하고 보존해야 한다면 전통적인 프론트엔드 프레임워크가 낫습니다.

현실에서는 두 방식을 섞어 쓰는 쪽이 답에 가깝습니다. 페이지 이동과 폼 처리는 HTMX에 맡기고, 복잡한 차트나 편집기만 자바스크립트 컴포넌트로 만들 수 있습니다.

그렇다고 프론트엔드 프레임워크를 완전히 몰아내는 건 아닙니다. 필요한 부분에만 사용하는 아일랜드 구조를 만드는 겁니다. 섬처럼 독립된 영역만 자바스크립트가 맡는 방식입니다.

HTMX 4.0이 보여주는 흐름을 단순한 과거 회귀로 볼 수는 없습니다. 지난 10여 년 동안 쌓인 프론트엔드 경험을 바탕으로 HTML과 HTTP의 역할을 다시 살펴보는 움직임입니다.

중요한 건 “HTMX가 리액트를 이길까”라는 승부가 아닙니다. 지금 만드는 화면에 클라이언트 상태 관리가 정말 필요한지부터 물어야 합니다. 여러분의 서비스에서 자바스크립트를 절반으로 줄인다면 무엇이 불편해지고, 무엇이 오히려 선명해질까요?