HTMX, 제발 한 번만 써보세요

• 현대 웹 개발에서 HTML과 대형 JavaScript 프레임워크 사이의 거짓된 양자택일 구조가 개발자를 불필요한 복잡성으로 몰아넣고 있음
• HTMX는 HTML 속성만으로 AJAX 요청과 부분 갱신, 애니메이션 전환을 처리해, 서버가 반환한 HTML을 그대로 화면에 반영하는 방식 제공
• 기존 코드베이스를 크게 변경하지 않고 점진적으로 도입할 수 있는 구조로, 프론트엔드 복잡도를 줄이고 생산성과 유지보수성을 높일 수 있음
• React 기반 SPA 대비 코드량·의존성·빌드 시간·로딩 속도에서 큰 개선 사례가 실제 프로덕션에서 확인됨
• 과도한 프레임워크 선택보다 단순한 하이퍼미디어 기반 접근이 장기적으로 생산성과 유지보수성에 유리함

---

문제 제기: 웹 개발의 거짓된 선택지

• 웹 개발 논의에서 HTML만 쓰거나 React 같은 대형 프레임워크를 쓰라는 극단적 선택지만 반복됨
• 순수 HTML은 링크·폼·dialog 등 기본 기능이 강력하지만, 부분 갱신이나 즉각적 반응성에는 한계 존재
• React·Vue·Angular 선택 시 수백 개 의존성, 느린 빌드, 복잡한 상태 관리 논쟁이 뒤따름
• 간단한 CRUD·대시보드·폼 중심 앱에도 과도한 도구 체계가 적용되는 현실

HTMX의 핵심 개념

• HTMX는 HTML 요소에 특수 속성을 추가해 서버와의 비동기 통신을 수행하는 도구
  • 예를 들어 hx-get, hx-post 속성을 통해 요청을 보내고 응답을 특정 DOM 영역에 삽입
• 모든 HTML 요소가 HTTP 요청 주체가 될 수 있도록 확장
• 서버는 JSON이 아닌 HTML 조각을 그대로 반환하고 반환된 HTML을 지정한 위치에 자동으로 교체 또는 삽입
• JavaScript 직접 작성 없이 HTML 속성 선언만으로 동작 정의
• 라이브러리 크기 약 14kb(gzip) 로 매우 가벼운 구성
• 별도의 빌드 도구나 프레임워크 설정 없이 기존 HTML 문서에 바로 적용 가능
• 서버 렌더링 중심의 전통적 웹 개발 방식과 잘 맞는 구조

주요 기능

• AJAX 요청 처리: HTML 속성만으로 GET, POST 요청을 수행
• DOM 업데이트: 서버에서 반환된 HTML을 지정된 요소에 자동 반영
• 이벤트 처리: 클릭, 입력 등 사용자 이벤트에 따라 서버 호출을 연결
• 히스토리 관리: 브라우저의 뒤로가기, 앞으로가기 동작과 연동

실제 적용 사례와 수치

• Contexte가 React 기반 SaaS를 Django + HTMX로 전환
  • 전체 코드 라인 수 67% 감소 (21,500 → 7,200)
  • JavaScript 의존성 96% 감소 (255 → 9)
  • 빌드 시간 88% 단축 (40초 → 5초)
  • 페이지 로딩 속도 50~60% 개선
• 코드베이스의 3분의 2를 삭제했고 앱은 더 좋아졌음
• 프론트엔드와 백엔드 분리 없이 모든 개발자가 풀스택 작업 가능

흔한 반론에 대한 정리

• "복잡한 클라이언트 상태 관리가 필요한 것 아닌가?"
  • 실제로는 대부분 폼, 리스트, 클릭에 따라 나타나는 요소 수준이며 HTMX로 충분히 처리 가능
  • Google Docs 같은 실시간 협업 도구라면 예외지만, 대부분은 CRUD 앱을 과대평가하고 있음
• "React 생태계가 주는 이점?"
  • 방대한 생태계는 곧 수 GB의 node_modules, 끝없는 선택지, 상태 관리 논쟁으로 이어짐
  • HTMX의 생태계는 선택한 서버 사이드 언어 하나로 끝남
• "SPA가 체감 속도 면에서 더 빠르지 않나?"
  • 초기에는 대용량 JavaScript 다운로드·파싱·실행·하이드레이션을 모두 거쳐야 함
  • HTMX는 초기 로딩부터 빠르고, 이후에도 변경된 부분만 교체해 응답 속도 유지
• "특정 React 기능이 꼭 필요한 경우는?"
  • 일부 경우에는 React가 적합할 수 있음
  • 다만 실제로는 전체 문제의 일부에만 필요한 도구를 습관적으로 선택하는 경우가 많음
• 왜 HTMX를 선택해야 하나?
  • 팀이 실패하는 이유는 잘못된 프레임워크가 아니라 과도한 프레임워크 선택
  • HTMX는 단순함에 베팅하며, 장기적으로 단순함은 유지보수성과 생산성에서 이점 제공

HTMX가 적합하지 않은 경우

• 실시간 협업 편집 도구 (Google Docs, Figma)
• 대규모 클라이언트 연산이 필요한 애플리케이션 (비디오 편집기, 캐드 도구)
• 오프라인 우선 구조 (물론 여러 접근 방식을 결합할 수도 있음)
• 진짜로 복잡한 UI 상태를 요구하는 경우

• 하지만, 자신이 정말로 그런걸 만들고 있나요?
  • 그저 폼과 표, 목록으로만 이루어진 또 다른 대시보드, 관리자 패널, 전자상거래 사이트, 블로그, SaaS 앱을 만들고 있는 건 아닌가?
  • 이런 것에는 HTMX는 정말 놀랍도록 훌륭함 "왜 이렇게 복잡하게 만들었을까?" "맙소사, 그동안 시간을 너무 많이 낭비했네" 라고 하고 싶을 정도로

그러니 한번 시도해 보세요

• React도 써봤고 Vue도 써봤고, Angular는 써보고 후회해봤지 않나요?
  • 이번 주 Hacker News에서 유행하는 메타 프레임워크도 이미 한 번쯤 건드려봤을 것이고
• HTMX를 그냥 한 번만 써보세요
  • 주말 하루 정도 투자
  • 사이드 프로젝트 하나를 선택하거나
  • 아무도 크게 신경 안 쓰는 내부 도구를 고르거나
  • 언젠가 다시 만들려고 미뤄둔 대상을 끄집어 내서
    -<script> 태그 하나 추가하고 hx-get 속성 하나 작성한후에 동작을 직접 확인해 볼 것
• 최악의 경우 주말 하루를 잃는 정도로 손해는 크지 않음
  • 하지만 싫지 않을 것임
  • 실제로는 웹 개발이 왜 이렇게까지 복잡했는지 의아해하게 될 것

[GN⁺]

Hacker News 의견들

• 나는 htmx의 창시자임. 과장된 기사 덕분에 주목받는 건 고맙지만, 이런 식의 하이프는 별로 좋아하지 않음
  웹앱을 만드는 방식은 다양하고 각각 장단점이 있음. htmx의 강점과 약점을 이 글에서 정리했음
  또 다른 훌륭한 hypermedia 지향 라이브러리인 Unpoly도 꼭 써보길 추천함
  (추가) 기사 내용을 다시 보니 생각보다 괜찮았음. 그래도 htmx는 좀 더 차분한 분위기로 다뤄지길 바람

  • 1999년대 초 웹앱을 만들던 방식에 익숙하다면, HTMX는 적은 노력으로 인터랙티브한 기능을 쉽게 추가할 수 있음
    드롭다운으로 필드 업데이트, 모달 생성, 자동완성 검색창 등 모두 간단함
    다만 RIA 프론트엔드의 복잡성은 데이터 변경 시 프론트엔드를 어떻게 업데이트하느냐에 있음.
    백엔드에서 일부 조정이 필요하고, 여러 partial 업데이트를 함께 처리할 수 있는 구조가 있으면 더 좋음
  • HTMX Sucks라는 글도 있음. 흥미로운 관점임
  • Unpoly가 정말 멋져 보임. 아직 HTMX는 안 써봤지만, Django나 Rails 같은 프레임워크의 UX 문제를 가볍게 해결해주는 점이 마음에 듦
    현재 Rails + Stimulus로 사이드 프로젝트를 하는데, Stimulus가 오히려 과한 느낌임. Inertia나 Stimulus를 언제 선택해야 하는지 궁금함
  • 참고로 나는 htmx의 CEO인데, 이런 과장된 기사들 정말 좋아함
  • Unpoly의 문서도 훌륭하지만 약간 복잡하다고 느낌. 더 단순한 경우엔 Alpine AJAX를 씀.
    Alpine.js 플러그인으로 링크와 폼에 기본적인 AJAX 기능을 추가해줌

• “Hello World” 예제로 React보다 낫다고 주장하는 글들에 지침
  단순 예제에서는 뭐든 잘 돌아감. 하지만 실제로는 의존성이 많은 백엔드와 복잡한 UI가 대부분임

  • 초간단 프레임워크에 대한 개발자들의 두려움은 결국 확장성의 한계에 부딪힐 때임
    기본 데모는 좋지만, 더 복잡한 기능을 추가할 때 어떻게 확장할 수 있는지 보여줘야 함
    JS를 어디에 추가할지, 빌드 스텝이 필요한지, htmx의 패러다임에 얼마나 묶이는지 궁금함
  • Fizzy처럼 37signals가 Hotwire로 만든 앱도 있음.
    React보다 낫다기보단 또 다른 접근 방식일 뿐임
  • 우리 인트라넷은 Python + HTMX 조합으로 돌아감. 아직까지 못 한 게 없음
    DOM 일부를 교체하는 패러다임이 매우 단순하고 직관적임
  • 반대로, 너무 복잡한 기술이 “Hello World”부터 어렵다는 경우도 있음
    예: effect-ts는 강력하지만, 단순 출력조차 복잡함
  • Go + Htmx로 만든 실시간 플래닝 포커 앱이 있음. 약 500줄 코드로 구현됨

• 우리 스타트업은 HTMX를 도입했다가 결국 React로 전환 중임
  HTMX는 응답 처리 복잡도가 높고, 각 엔드포인트가 여러 HTML 조각을 반환해야 함
  문서와 사례가 부족하고, 대규모 베스트 프랙티스도 없음.
  React는 성숙하고, AI 코딩과의 궁합도 좋음. HTMX는 단순 프로젝트엔 적합하지만 그 이상은 어려움

  • 나는 HTMX로 매끄러운 아키텍처 패턴을 찾았음
    각 엔드포인트는 하나의 역할만 수행하고, Optimistic UI로 즉시 반응함
    에러 처리는 단순하게, hx-swap-oob는 최소 사용
    기술 선택의 핵심은 트레이드오프를 최소화하는 것임
  • 프론트와 백엔드가 모든 시나리오에 합의해야 한다는 건 당연함.
    그래서 나는 백엔드 검증 중심으로 두고, 프론트는 단순히 표시만 하게 함
  • Hypermedia Systems 책이 통합적인 설명을 더 잘 해줌
  • 이해하지 못한 틈새 솔루션을 선택했다가, 또 다른 복잡한 걸로 옮기는 건 트레이드오프를 반복하는 일임
  • “AI 코딩에 좋다”는 이유로 기술을 선택하는 건 좀 슬픈 일임

• 나는 SSR을 원하지 않음. 백엔드는 JSON API만 제공하고, 프론트는 그걸 소비함
  SSR은 과대홍보된 개념이라 생각함. 클라우드 서비스 판매를 위한 유도 전략 같음

• Demo 3 Live Search 예제는 스크롤 지연(jank) 문제가 심함.
  결과가 문서 내에 직접 삽입되어 레이아웃이 계속 재계산되는 듯함

• React는 충분히 괜찮음. 단순한 프로젝트라도 굳이 다른 패러다임을 배울 이유가 없음

  • React도 결국 HTML로 렌더링되므로, HTML/CSS를 배워야 함. 단지 추상화가 있을 뿐임
  • React 생태계는 너무 넓어 계속 배우고 잊어야 하는 피로감이 있음
    반면 HTMX는 15분이면 개념을 익히고, 10년은 써먹을 수 있음
  • React나 Angular는 MVC 위에 또 다른 MVC를 얹은 구조임. 불필요하게 복잡함
  • 무거운 솔루션을 모든 곳에 쓰는 건 비효율적임.
    역사적으로 가벼운 패러다임이 시장에서 이김. React도 한때 그런 존재였음
  • 이유는 단순함 — 성능

• 나는 HTMX가 아니라 Alpine.js에 완전히 반했음
  서버 렌더링된 HTML을 강화(enhance) 하는 개념이 클릭됐음
  드롭다운, show/hide 등 모두 직관적이고 빌드 스텝이 필요 없음

  • Alpine에도 Alpine AJAX 플러그인이 있어 HTMX와 유사한 기능을 제공함
  • 나도 Alpine.js를 쓰며 프론트엔드가 다시 즐거워졌음
    직관적이고 대규모 프로젝트에서도 관리가 쉬움
  • 하지만 상용 프로젝트에서는 Alpine이 악몽이 될 수 있음
    JS를 HTML에 인라인으로 넣다 보면 유지보수가 어렵고, 상태 관리도 암묵적임
    Hotwire나 Stimulus가 조직 규모에서는 훨씬 낫다고 느낌
  • 선언적 접근이 정답임

• 대규모 앱에서 HTMX를 쓴다면 서버 부하와 비용이 궁금함
  HTML을 서버에서 렌더링하니 JSON보다 처리량이 많을 것 같음

  • 하지만 꼭 그렇진 않음. 템플릿 렌더링은 매우 빠름
    JSON 직렬화보다 효율적일 때도 많고, 클라이언트에서도 역직렬화 비용이 있음
    HTMX는 Alpine.js 같은 도구와 함께 쓰면 복잡한 상태도 쉽게 처리 가능함
    모든 상황에 맞진 않지만, 많은 경우에 매우 잘 작동함

• 프레임워크 전도는 웹 생태계의 최악의 문화임
  좋은 솔루션이라면 결국 채택될 것임. 굳이 전도사처럼 굴 필요 없음
  npm 공격도 과장임. htmx도 결국 npm을 쓸 수밖에 없음

  • htmx는 의존성 없는 단일 파일이라 npm이 꼭 필요하진 않음
  • “좋은 솔루션은 자연히 채택된다”는 말은 틀림.
    세상엔 마케팅과 인지도로 채택된 나쁜 솔루션이 많음
  • 인기와 예산, 관성이 기술 채택을 좌우함.
    진짜 장인정신을 지키려면 이런 편향에 맞서야 함

• HTMX는 양쪽 세계의 단점만 합친 것처럼 보임
  SSR은 응집력 있고, CSR은 분리된 구조인데, HTMX는 둘 다 섞여 암묵적 결합이 생김
  같은 데이터를 다른 형식으로 보여주려면 백엔드에서 두 엔드포인트를 만들어야 하는지 의문임

  • 프론트엔드 상태가 꼭 필요하다는 생각에서 벗어나야 함
    대부분의 앱은 백엔드 상태만으로 충분하고, UX 향상 외엔 큰 이득이 없음
  • Splitting Your APIs 글을 보면 오히려 좋은 점임
  • Jinja 같은 서버 템플릿을 쓰면 한 번의 렌더링으로 여러 표현 형식을 처리할 수 있음
    전체 페이지를 서버에서 구성하면 데이터는 이미 그 안에 있음