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 속성 하나 작성한후에 동작을 직접 확인해 볼 것
• 최악의 경우 주말 하루를 잃는 정도로 손해는 크지 않음
  • 하지만 싫지 않을 것임
  • 실제로는 웹 개발이 왜 이렇게까지 복잡했는지 의아해하게 될 것