HTMX는 왜 스스로 New jQuery라고 부를까?

2026년 8월 28일, HTMX 4.0이 정식 출시됐다.

React, Vue, Svelte 같은 프론트엔드 프레임워크가 이미 자리 잡은 2026년에 HTMX가 이야기하는 자신의 미래는 조금 독특하다.

HTMX 팀은 공식 글에서 자신들이 되고 싶은 모습을 이렇게 표현한다.

htmx is the New jQuery

한때 거의 모든 웹사이트에서 사용되던 jQuery는 이제 현대적인 프론트엔드 개발을 이야기할 때 자주 등장하는 이름은 아니다.

그런데 HTMX는 그 이름을 피하기는커녕 오히려 자신들의 미래와 연결한다.

왜 하필 jQuery일까?

HTMX가 말하는 New jQuery

처음에는 이 표현을 보고 HTMX가 jQuery와 비슷한 역할을 하겠다는 의미라고 생각했다.

둘을 겉으로 보면 실제로 닮은 부분도 있다.

jQuery를 사용한다면 서버에서 HTML을 받아 특정 DOM을 변경하는 코드를 이런 식으로 작성할 수 있다.

$("#load").on("click", async function () {
  const html = await fetch("/users").then((response) => response.text());
  $("#users").html(html);
});

HTMX에서는 비슷한 동작을 HTML에 작성한다.

<button hx-get="/users" hx-target="#users">
  사용자 불러오기
</button>
 
<div id="users"></div>

버튼을 누르면 /users로 요청을 보내고 서버가 반환한 HTML을 #users에 넣는다.

결과만 보면 꽤 비슷하다.

하지만 HTMX 팀이 이야기하는 New jQuery의 의미는 단순히 DOM을 변경하는 방식에 있지 않다.

HTMX의 미래에 대한 공식 글에서 jQuery를 이야기하는 부분을 보면 그들이 높게 평가하는 것은 오히려 도구로서의 성격이다.

jQuery는 기존 프로젝트에 쉽게 추가할 수 있었다.

API가 오랫동안 크게 흔들리지 않았고, 필요한 만큼만 사용할 수 있었으며, 애플리케이션 전체 구조를 자기 방식으로 강요하지 않았다.

HTMX 팀은 바로 이런 특징을 낮은 비용으로 큰 가치를 주는 도구의 성격이라고 본다.

그러니까 New jQuery라는 표현은 jQuery의 $()를 다시 만들겠다는 의미가 아니다.

쉽게 추가할 수 있고, 오래 사용할 수 있으며, 필요 이상으로 애플리케이션 전체를 지배하지 않는 도구가 되고 싶다는 의미에 더 가깝다.

사실 HTMX와 jQuery의 관계는 오래됐다

HTMX와 jQuery의 연결은 최근 만들어진 이야기도 아니다.

HTMX의 전신은 intercooler.js라는 라이브러리였다.

HTMX 공식 글에 따르면 intercooler.js는 jQuery를 기반으로 HTML attribute를 통해 동작을 추가하는 방식에서 출발했다.

이후 그 아이디어가 HTMX로 이어졌다.

그러니까 HTMX를 최근 React의 복잡성에 대한 반작용으로 갑자기 등장한 도구라고 보는 것은 정확하지 않다.

그 뿌리는 생각보다 오래됐고, jQuery와의 관계도 우연이 아니다.

jQuery와 비슷하지만 접근 방식은 다르다

jQuery에서는 JavaScript가 동작의 중심에 있다.

$("#load").on("click", async function () {
  const html = await fetch("/users").then((response) => response.text());
  $("#users").html(html);
});

이 코드를 읽으려면 JavaScript를 봐야 한다.

어떤 이벤트가 발생하는지, 어디로 요청하는지, 응답을 받은 다음 어떤 DOM을 변경하는지가 JavaScript에 들어 있다.

HTMX에서는 같은 정보를 HTML에서 확인할 수 있다.

<button hx-get="/users" hx-target="#users">
  사용자 불러오기
</button>

이 요소만 봐도 상당 부분을 알 수 있다.

버튼이 요청을 발생시키고, /users로 GET 요청을 보내며, 응답은 #users에 적용된다.

HTMX는 이런 방식으로 HTML 자체에 동작을 선언한다.

HTMX 공식 글에서도 HTMX는 React보다 jQuery에 훨씬 가깝지만, jQuery와 달리 HTML 기반의 선언적 인터페이스를 사용한다고 설명한다.

이 차이가 작아 보이지만 생각보다 크다.

동작을 가까운 곳에 둔다

HTMX 문서를 보다 보면 Locality of Behaviour라는 표현이 등장한다.

공식 글에서는 이를 어떤 코드 단위의 동작을 가능한 한 그 코드 단위만 보고도 이해할 수 있게 만드는 원칙으로 설명한다.

예를 들어 다음 코드를 보면:

<button hx-get="/users" hx-target="#users">
  사용자 불러오기
</button>

별도의 JavaScript 파일을 찾지 않아도 이 버튼이 어떤 일을 하는지 대략 알 수 있다.

hx-get을 보면 요청 주소를 알 수 있고 hx-target을 보면 결과가 어디에 적용되는지도 알 수 있다.

물론 실제 애플리케이션이 이 정도로 단순한 경우만 있는 것은 아니다.

그리고 HTMX 공식 글 역시 Locality of Behaviour가 DRY나 Separation of Concerns 같은 다른 설계 원칙과 충돌할 수 있으며, 결국 트레이드오프라고 설명한다.

그래도 HTMX가 어떤 방향을 추구하는지는 명확하다.

동작을 추상화해서 멀리 보내기보다 동작하는 요소 근처에 그 정보를 두려고 한다.

그런데 서버는 JSON이 아니라 HTML을 보낸다

HTMX를 처음 봤을 때 가장 낯설었던 부분은 따로 있었다.

서버가 JSON이 아니라 HTML을 반환한다는 점이다.

React를 비롯한 클라이언트 중심 개발에 익숙해지면 보통 이런 흐름을 생각한다.

브라우저
   ↓
API 요청
   ↓
서버
   ↓
JSON
   ↓
클라이언트 상태
   ↓
컴포넌트 렌더링
   ↓
HTML

HTMX에서는 이 과정이 훨씬 짧아질 수 있다.

브라우저
   ↓
요청
   ↓
서버
   ↓
HTML
   ↓
DOM 일부 교체

예를 들어 서버가 이런 응답을 보내면 된다.

<ul>
  <li>Kim</li>
  <li>Lee</li>
</ul>

HTMX는 이 HTML을 지정된 위치에 넣는다.

클라이언트가 JSON을 받아 다시 HTML로 만드는 과정 자체가 없다.

처음에는 너무 단순해서 오히려 이상하게 느껴졌다.

그런데 생각해보면 웹은 원래 이런 방식으로 동작했다.

서버가 HTML을 만들고 브라우저가 그것을 보여준다.

HTMX는 이 오래된 모델에서 페이지 전체를 다시 요청해야 했던 부분을 확장한다.

HTMX 팀도 자신들의 역할을 모든 것을 해결하는 완전한 애플리케이션 솔루션이라기보다, HTML의 hypermedia control을 확장하는 것으로 설명한다.

그러면 초기 데이터도 HTMX로 가져와야 할까?

여기서 처음에 한 가지 착각을 했다.

HTMX를 사용한다면 초기 데이터도 이런 식으로 가져와야 하는 줄 알았다.

<div id="posts" hx-get="/posts" hx-trigger="load"></div>

페이지가 로드되면 /posts를 요청하고 결과를 넣는다.

물론 이렇게 만들 수 있다.

하지만 반드시 그래야 하는 것은 아니다.

서버가 처음 요청을 받을 때부터 완성된 HTML을 내려주면 된다.

<main>
  <article>첫 번째 글</article>
  <article>두 번째 글</article>
</main>

그리고 이후 사용자 행동에서 필요한 부분만 HTMX를 이용해 변경한다.

<button hx-get="/posts?page=2" hx-target="#posts">
  다음 페이지
</button>

이 부분을 이해하고 나니 HTMX가 무엇을 하려는지 조금 더 명확해졌다.

HTMX는 서버 템플릿 엔진이 아니다.

초기 HTML을 만드는 것은 여전히 서버의 역할이다.

Django, Rails를 비롯해 서버에서 HTML을 생성할 수 있는 전통적인 템플릿 방식과도 잘 맞는다. HTMX 공식 글도 HTML이라는 공통분모 덕분에 오래된 도구와 새로운 도구 모두와 잘 동작한다는 점을 강조한다.

그렇다면 SEO는?

처음에는 HTMX도 페이지 일부를 동적으로 변경하니 SPA처럼 SEO에서 불리하지 않을까 생각했다.

하지만 초기 요청에서 서버가 콘텐츠가 포함된 HTML을 반환한다면 상황은 다르다.

검색 엔진이나 브라우저가 페이지를 처음 요청했을 때 이미 콘텐츠가 존재할 수 있다.

HTMX는 이후 사용자 인터랙션에서 필요한 영역을 변경한다.

따라서 HTMX를 사용한다는 이유만으로 SEO가 약해지는 것은 아니다.

반대로 중요한 콘텐츠를 초기 HTML에 포함하지 않고 페이지 로드 이후 전부 별도의 요청으로 가져오도록 설계한다면 이야기가 달라질 수 있다.

결국 중요한 것은 HTMX 자체보다 초기 HTML을 어떻게 설계했느냐에 가깝다.

그러다 다른 질문이 생겼다

HTMX를 보다 보니 처음에는 React와 비교하게 됐다.

React에서는 상태를 만들고 서버에서 데이터를 가져온 다음 그 상태를 기반으로 UI를 렌더링하는 구조가 흔하다.

HTMX에서는 서버가 HTML을 만들고 필요한 부분만 교체하는 방식이 자연스럽다.

그런데 둘을 계속 비교하다 보니 질문 자체가 조금 잘못됐다는 생각이 들었다.

React와 HTMX 중 무엇이 더 좋은가?

가 아니라,

지금 만들고 있는 화면에서 브라우저가 얼마나 많은 상태를 책임져야 하는가?

가 더 중요한 질문 아닐까?

React가 등장하고 널리 사용된 이유가 있다.

웹사이트가 점점 웹 애플리케이션이 됐기 때문이다.

클라이언트에서 관리해야 할 상태가 많아졌다.

하나의 상태가 여러 UI에 영향을 준다.

서버 응답을 기다리지 않고 먼저 화면을 변경해야 하는 경우도 있다.

드래그 앤 드롭처럼 브라우저에서 지속적으로 변하는 상태도 있다.

이런 UI를 DOM을 직접 수정하는 방식으로 관리하면 금방 복잡해진다.

React는 이런 문제를 다루기 위한 도구다.

그렇다면 React가 복잡한 것은 어느 정도 당연하다.

복잡한 문제를 해결하고 있기 때문이다.

하지만 모든 웹사이트가 그렇게 복잡한가?

게시판을 생각해보자.

목록을 요청한다.

글을 읽는다.

글을 작성한다.

검색한다.

페이지를 이동한다.

관리자 페이지도 비슷한 경우가 많다.

데이터를 조회하고, 수정하고, 저장하고, 삭제한다.

이런 서비스에서는 중요한 상태의 대부분을 서버가 가지고 있을 수 있다.

그런데 클라이언트 중심 구조에서는 서버의 데이터를 JSON으로 받아 브라우저에서도 다시 상태로 관리한다.

서버 상태
   ↓
JSON
   ↓
클라이언트 상태
   ↓
UI

물론 이 구조가 필요한 서비스도 많다.

하지만 모든 서비스에서 반드시 필요한 것은 아니다.

서버가 대부분의 상태를 가지고 있고 UI가 그 결과를 보여주는 역할에 가깝다면:

서버 상태
   ↓
HTML
   ↓
UI

처럼 더 단순한 구조로도 충분한 경우가 있다.

HTMX가 재미있는 이유는 새로운 렌더링 기술을 만들어서라기보다 이 오래된 구조를 다시 현실적인 선택지로 가져왔다는 점에 있다.

React가 필요 없다는 이야기는 아니다

여기까지 이야기하면 쉽게 다른 극단으로 갈 수 있다.

React는 너무 복잡하고 HTMX면 충분하다는 결론이다.

하지만 그렇게 생각하지 않는다.

복잡한 클라이언트 상태가 있는 애플리케이션이라면 React 같은 도구가 훨씬 자연스럽다.

여러 UI가 하나의 상태에 동시에 반응해야 할 수도 있다.

optimistic update가 중요할 수도 있다.

실시간으로 많은 상태가 변경될 수도 있다.

브라우저 자체가 하나의 애플리케이션처럼 동작해야 할 수도 있다.

이런 서비스를 HTMX만으로 해결하려고 한다면 오히려 더 복잡해질 수 있다.

반대로 서버가 대부분의 상태를 가지고 있는 서비스라면 상황이 달라진다.

CRUD.

관리자 페이지.

검색과 목록.

폼 중심의 서비스.

콘텐츠 중심의 웹사이트.

이런 서비스에서는 처음부터 클라이언트가 많은 책임을 가져야 하는지 다시 생각해볼 수 있다.

결국 문제는 어떤 기술이 더 현대적인가가 아니다.

어디까지 브라우저가 책임져야 하는가의 문제다.

그리고 2026년, HTMX 4가 나왔다

이런 생각을 하던 시점에 HTMX 4.0이 정식 출시됐다.

HTMX 4는 약 8개월간의 작업 끝에 나왔고, 내부 구현에서는 꽤 큰 변화가 있었다.

대표적으로 오랫동안 사용하던 XMLHttpRequest 기반 구현을 fetch()와 async JavaScript 중심으로 옮겼다.

하지만 공식 릴리스 글은 사용자 관점에서 HTMX 4가 HTMX 2와 거의 동일하다고 설명한다.

실제로 주요 변경점도 비교적 제한적이다.

• attribute inheritance가 기본적으로 암시적 방식에서 명시적 방식으로 바뀌었다.
• HTMX 이벤트 이름이 정리되고 표준화됐다.
• history 지원에서 기본 localStorage 사용이 제거됐다.

그리고 내부의 XMLHttpRequest에서 fetch()로의 이동은 대부분의 사용자에게 투명해야 한다고 설명한다.

더 흥미로운 부분도 있다.

HTMX 팀은 4.0을 곧바로 NPM의 latest로 지정하지 않았다.

버전을 지정하지 않은 CDN URL을 사용하는 기존 사용자를 강제로 업그레이드시키고 싶지 않다는 이유로, 2.x를 당분간 latest로 유지하고 4.0은 next로 두겠다고 밝혔다.

메이저 버전을 내놓고도 기존 사용자를 일부러 새 버전으로 밀어 올리지 않는 셈이다.

이 선택은 HTMX가 이야기하는 New jQuery라는 목표와 묘하게 잘 맞는다.

jQuery에서 가져오고 싶었던 것은 오래 살아남는 방식이었다

처음 HTMX의 New jQuery라는 표현을 봤을 때는 기술적인 유사성을 먼저 생각했다.

하지만 자료를 찾아볼수록 다른 의미가 더 크게 보였다.

HTMX가 jQuery에서 가져오고 싶어 하는 것은 $()가 아니다.

Ajax API도 아니다.

DOM을 직접 조작하던 개발 방식도 아니다.

프로젝트에 쉽게 추가할 수 있고,

API가 가능한 한 안정적으로 유지되고,

필요한 만큼만 사용할 수 있으며,

오늘 작성한 코드를 몇 년 뒤에도 큰 부담 없이 유지할 수 있는 도구.

HTMX가 이야기하는 New jQuery는 그런 의미에 더 가까워 보인다.

그렇다고 HTMX가 애플리케이션 구조에 아무 영향도 주지 않는다는 뜻도 아니다.

HTMX 공식 글에서도 네트워크 요청의 상당 부분을 HTMX로 처리한다면 HTML 구조, endpoint, 서버 응답 형식까지 HTMX의 방식에 영향을 받기 때문에 실질적으로 프레임워크처럼 작동한다고 인정한다.

즉 HTMX는 마법처럼 복잡성을 없애는 라이브러리가 아니다.

다만 그 복잡성을 JavaScript 애플리케이션 모델보다 HTML과 hypermedia 쪽에 더 가깝게 배치하려는 선택이다.

다시 과거로 돌아가는 것은 아니다

처음 HTMX를 봤을 때는 과거로 돌아가는 것처럼 보였다.

서버가 HTML을 만든다.

브라우저가 그것을 받아 보여준다.

필요하면 DOM 일부만 변경한다.

jQuery로 개발하던 시절과 묘하게 닮아 있다.

그런데 HTMX는 그 유사성을 부정하지 않는다.

오히려 스스로 New jQuery가 되겠다고 이야기한다.

하지만 이것은 React 이전으로 돌아가자는 이야기가 아니다.

React가 해결한 문제는 여전히 존재한다.

복잡한 클라이언트 애플리케이션에는 그 복잡성을 다룰 도구가 필요하다.

다만 모든 웹사이트가 그런 애플리케이션인 것은 아니다.

HTMX를 살펴보면서 재미있었던 것은 새로운 문법이나 기능보다 오히려 이 질문이었다.

이 화면을 만들기 위해 브라우저가 정말 이만큼 많은 책임을 가져야 하는가?

jQuery에서 React로 넘어오면서 브라우저가 해야 하는 일은 계속 많아졌다.

HTMX는 그 흐름에서 무언가 완전히 새로운 것을 제시한다기보다 서버와 HTML이 원래 가지고 있던 역할을 다시 바라보게 만든다.

그래서 HTMX 4를 보면서 가장 흥미로웠던 것은 새로운 기능보다도, 2026년에 다시 jQuery의 장점을 이야기하는 이유였다.

출처

• HTMX 4.0.0 is Released
• The Future of htmx
• Is htmx Just Another JavaScript Framework?
• Locality of Behaviour
• HTMX Documentation

이 글은 HTMX와 jQuery를 살펴보며 느낀 개인적인 생각을 바탕으로 작성했으며, 기술적 사실과 프로젝트의 방향에 관한 내용은 HTMX 공식 문서와 공식 글을 기준으로 확인했다. 초안 정리와 문장 교정에는 AI 도구를 활용했다.