HTMX가 너무 멋져서 직접 만들었다 — 서버 렌더링 HTML로 돌아가는 미니멀 프런트엔드

HTMX로 돌아가는 미니멀 프런트엔드

HTMX가 너무 멋져서 직접 만들었다 — 서버 렌더링 HTML로 돌아가는 미니멀 프런트엔드

HTMX는 왜 다시 화제인가

HTMX는 서버가 렌더링한 HTML을 중심으로 프런트엔드를 점진적으로 향상하는 JavaScript 라이브러리다. React처럼 거대한 SPA를 짓는 대신 페이지의 일부 영역만 서버 응답으로 교체한다. 긱뉴스에 공유된 dbushell.com 글의 사례가 대표적이다. 자체 호스팅 podcast 웹앱에서 페이지 이동 시 오디오 재생이 끊기는 문제를 HTMX로 해결했다.

핵심 아이디어는 단순하다. HTML을 반환하는 HTTP 요청이 곧 HTMX의 API이며, 클라이언트는 전체 페이지를 다시 받지 않고 필요한 영역만 받아 DOM에 끼워 넣는다. 304 캐싱과 History API까지 기본으로 챙기면 React로 가는 큰 길을 우회할 수 있다.

서버 사이드 렌더링이 다시 부상하는 흐름과 맞물린다. 2024년 이후 많은 팀이 클라이언트 번들 크기와 상호작용 비용을 다시 계산하고 있고, HTMX는 그 흐름의 가장 작은 도구다. 2026년 현재도 이 흐름은 계속된다. 실무에서 마주치는 페이지는 대부분 정적이며, 거기에 한두 개의 동적 영역만 더해진다.

HTMX의 실제 위치

HTMX는 React를 직접 대체하는 도구가 아니라 사고방식의 큰 전환이 필요하다. 라이브러리는 작지만 구현의 상당 부분이 백엔드 템플릿과 서버 설정에 놓이며, PHP, Ruby, Go, Node 모두 같은 방식으로 HTMX 백엔드를 만들 수 있다.

긱뉴스 글의 필자는 작은 웹사이트에는 SvelteKit이 부담스럽다고 느꼈고, 그래서 자체적으로 만들던 DinoSsr로 회귀했다. DinoSsr는 islands 아키텍처를 제공하지만 전체 페이지 상호작용은 의도적으로 포기한 프레임워크다.

HTMX는 React가 풀려는 모든 문제를 해결하지는 않는다. 무한 스크롤과 실시간 검색 결과 같은 인기 사례가 있을 뿐 라우팅과 상태 관리의 풀세트는 없으며, 제한 안에서 가치가 큰 도구다. magic bullet을 기대하면 실망한다. 작은 사이트, 작은 팀, 작은 상호작용이 겹칠 때 가장 효율적인 선택이 된다. 큰 프레임워크 없이도 충분하다. 라이브러리 무게가 가벼울수록 유지보수도 쉬워진다.

직접 만든 미니 구현의 핵심 요소

HTMX를 잠시 적용한 뒤 필자는 같은 아이디어로 직접 미니 버전을 만들었다. 사용한 요소는 4가지다.

• 304 캐싱: last-modified와 if-modified-since HTTP 헤더로 변경 없음을 알린다.

• History API: pushState와 popstate로 브라우저 뒤로가기를 자연스럽게 처리한다.

• title 교체: 응답에서 title 요소를 추출해 document.title을 갱신한다.

• 포인터 이벤트 프리로드: click이 발생하기 전에 fetch를 시작해 체감 속도를 끌어올린다.

이 4요소만으로 페이지 이동 시 오디오 컴포넌트가 끊기지 않는 경험을 만들었고, 결과는 작고 단순한 코드베이스다. HTMX의 제약이 직접 구현의 단순함으로 이어진 셈이다. 작은 라이브러리가 결국 사용자 경험을 개선한다.

흥미로운 점은 표준 웹 API만으로 충분하다는 사실이며, HTMX의 마법이 숨겨진 게 아니라 브라우저가 이미 제공하는 API의 조합이라는 점이 그래서 직접 구현이 가능하다.

HTMX에 대한 작은 불만

HTMX 문서에는 클릭 가능한 div 예시가 많다. 다음은 /messages로 PUT 요청을 보내는 div다.

Put To Messages

div를 클릭 가능하게 만드는 패턴은 접근성 관점에서 바람직하지 않으며, hx-boost를 앵커와 폼 태그에 적용하면 표준 태그를 자동으로 강화해 준다. 클릭 가능한 div를 피하는 가장 깔끔한 방법이다.

또 다른 불만은 hx-* 접두 속성이다. 표준 data-*와 dataset이 이미 있는데 비표준 접두를 쓰는 점은 어색하고, Lobste.rs 의견에서도 같은 지적이 나왔다. 인라인 JavaScript가 등장하는 고급 예시도 다소 지저분해 선언적 속성 템플릿의 한계를 보여주는 사례다.

이 지점에서 직접 구현이 더 깔끔해질 수 있다. 필자가 HTMX를 버리고 직접 만든 이유도 이 지점이며, 표준 웹 API를 그대로 쓰는 편이 마찰이 적다.

서버 부하에 대한 흔한 오해

HTMX는 모든 것을 서버에서 렌더링하니 서버를 혹사시키지 않냐는 우려가 있다. 결론부터 말하면 그렇지 않다. CGI 시절의 문제는 짧게 살아 있는 프로세스를 많이 띄우는 비용이었으며, FastCGI 이후 이 비용은 해결됐다.

HTML 생성 자체는 비싼 작업이 아니며, 대안 방식에서 비슷한 양의 JSON을 만드는 것보다 비싸다고 보기도 어렵다. 서버 사이드 애플리케이션에서 실제 HTML 렌더링 단계가 병목인 경우는 거의 없으며, 병목은 그 이전 과정에 있는 경우가 대부분이다.

HTMX는 SSR과도 다르다. JSON API로 데이터를 보내고 클라이언트가 렌더링하는 대신 서버가 HTML 조각을 직접 보내며, 자원 소비는 비슷한 수준이다. 실제 프로덕션 사례에서는 HTMX가 더 적은 자원으로 같은 사용자 경험을 만들고, 클라이언트 번들이 작고 캐시 적중률이 높다. CDN과 자연스럽게 어울린다.

그래서 우리도 따라 할 수 있는가

HTMX는 작은 웹사이트와 점진적 향상에 가장 잘 맞는다. 서버 템플릿이 이미 있고 클라이언트 번들을 줄이고 싶은 팀이라면 도입 효과가 크다. 반대로 복잡한 클라이언트 상태와 풍부한 상호작용이 필요하면 React가 여전히 답이다.

결론은 단순하다. 작은 도구가 작은 문제에 큰 가치를 줄 때 그 도구를 선택하라. HTMX의 철학은 현대 JavaScript 개발자에게 한 줄의 거울이며, 더 적게, 더 직접적으로, 더 서버 가까이.

HTMX 자체보다 그 철학이 더 오래 남을 것이다. 표준 웹 API로 충분한 일을 표준 웹 API로 처리하는 원칙이며, 이 원칙을 기억하는 개발자가 다음 10년의 웹을 만들 것이다. 더 적은 코드로 더 많은 일을 하려는 태도가 결국 사용자 경험을 결정한다. 작은 코드베이스가 큰 가치를 만든다.