# HTMX, 제발 한 번만 써보세요

> Clean Markdown view of GeekNews topic #25182. Use the original source for factual precision when an external source URL is present.

## Metadata

- GeekNews HTML: [https://news.hada.io/topic?id=25182](https://news.hada.io/topic?id=25182)
- GeekNews Markdown: [https://news.hada.io/topic/25182.md](https://news.hada.io/topic/25182.md)
- Type: GN+
- Author: [neo](https://news.hada.io/@neo)
- Published: 2025-12-19T09:50:53+09:00
- Updated: 2025-12-19T09:50:53+09:00
- Original source: [pleasejusttryhtmx.com](http://pleasejusttryhtmx.com/)
- Points: 21
- Comments: 8

## Summary

현대 웹 개발은 **HTML과 대형 프레임워크 사이의 이분법**에 갇혀 불필요한 복잡성을 자초하고 있습니다. HTMX는 HTML 속성만으로 AJAX 요청과 부분 갱신을 처리해, 서버가 반환한 HTML을 그대로 반영하는 단순한 모델을 제시합니다. 기존 코드베이스를 거의 수정하지 않고 도입할 수 있어 **생산성과 유지보수성**을 동시에 높이며, React 기반 SPA 대비 코드량과 빌드 시간, 로딩 속도 모두에서 실질적 개선이 확인되고 있습니다. 사이드 프로젝트에서 한번 써보는 걸 권장하네요.

## Topic Body

- 현대 웹 개발에서 **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**로 전환](https://htmx.org/essays/a-real-world-react-to-htmx-port/)  
  - 전체 코드 라인 수 **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` 속성 하나 작성한후에 동작을 직접 확인해 볼 것  
- 최악의 경우 주말 하루를 잃는 정도로 손해는 크지 않음  
  - 하지만 싫지 않을 것임   
  - 실제로는 웹 개발이 왜 이렇게까지 복잡했는지 의아해하게 될 것

## Comments



### Comment 48045

- Author: iolothebard
- Created: 2025-12-20T10:56:32+09:00
- Points: 3

작년에 이런 발표를 했었네요. 들은 사람은 별로 없었지만^^  
https://www.slideshare.net/slideshow/htmx-2024/274315966  
  
PoC차원에서 이런것도 만들었었네요  
https://github.com/iolo/hx  
  
그러나 아무도 htmx를 쓰지 않죠 ㅎㅎ

### Comment 48081

- Author: shakespeares
- Created: 2025-12-21T19:13:31+09:00
- Points: 1
- Parent comment: 48045
- Depth: 1

이미 익숙해진 상황과 그만큼 많은 대용량의 생태계 구성 후에 고착화되어 더 이상 혁신에 대한 움직임이 없는 것 같아 아쉽네요.

### Comment 48048

- Author: roxie
- Created: 2025-12-20T11:26:07+09:00
- Points: 1
- Parent comment: 48045
- Depth: 1

장표 재밌네요 발표를 못봐서 아쉽습니다 ㅎㅎㅎ

### Comment 48096

- Author: ryj0902
- Created: 2025-12-22T08:50:41+09:00
- Points: 1

파이콘에서 관련 강연을 들은 적이 있는데 강연자분도 아직 현업에서 사용해보진 못했다는 말이 기억나네요.

### Comment 48062

- Author: aer0700
- Created: 2025-12-21T08:09:03+09:00
- Points: 1

Rust, 제발 한 번 써보세요?

### Comment 48049

- Author: bbulbum
- Created: 2025-12-20T12:36:29+09:00
- Points: 1

Alpine.js 를 시도해본적이 있는데, 상태관리는 대부분 필요했습니다...  
처음부터 백앤드에서 상태관리하도록 설계하지 않는 이상 단계별 상태, 조건부 상태 등을 해결하는게 골치아팠던 기억이 나네요.

### Comment 48047

- Author: roxie
- Created: 2025-12-20T11:24:26+09:00
- Points: 1

모든 말에 공감하지만 htmx 는 손이 안갑니다 ㅠ

### Comment 47985

- Author: neo
- Created: 2025-12-19T09:50:53+09:00
- Points: 1

###### [Hacker News 의견들](https://news.ycombinator.com/item?id=46312973) 
- 나는 **htmx**의 창시자임. 과장된 기사 덕분에 주목받는 건 고맙지만, 이런 식의 하이프는 별로 좋아하지 않음  
  웹앱을 만드는 방식은 다양하고 각각 장단점이 있음. htmx의 강점과 약점을 [이 글](https://htmx.org/essays/when-to-use-hypermedia/)에서 정리했음  
  또 다른 훌륭한 **hypermedia 지향 라이브러리**인 [Unpoly](https://unpoly.com/)도 꼭 써보길 추천함  
  (추가) 기사 내용을 다시 보니 생각보다 괜찮았음. 그래도 htmx는 좀 더 **차분한 분위기**로 다뤄지길 바람
  - 1999년대 초 웹앱을 만들던 방식에 익숙하다면, HTMX는 **적은 노력으로 인터랙티브한 기능**을 쉽게 추가할 수 있음  
    드롭다운으로 필드 업데이트, 모달 생성, 자동완성 검색창 등 모두 간단함  
    다만 RIA 프론트엔드의 복잡성은 데이터 변경 시 프론트엔드를 어떻게 업데이트하느냐에 있음.  
    백엔드에서 일부 조정이 필요하고, 여러 **partial 업데이트**를 함께 처리할 수 있는 구조가 있으면 더 좋음
  - [HTMX Sucks](https://htmx.org/essays/htmx-sucks/)라는 글도 있음. 흥미로운 관점임
  - Unpoly가 정말 멋져 보임. 아직 HTMX는 안 써봤지만, Django나 Rails 같은 프레임워크의 **UX 문제를 가볍게 해결**해주는 점이 마음에 듦  
    현재 Rails + Stimulus로 사이드 프로젝트를 하는데, Stimulus가 오히려 과한 느낌임. **Inertia나 Stimulus를 언제 선택해야 하는지** 궁금함
  - 참고로 나는 htmx의 CEO인데, 이런 **과장된 기사**들 정말 좋아함
  - Unpoly의 문서도 훌륭하지만 약간 복잡하다고 느낌. 더 단순한 경우엔 [Alpine AJAX](https://alpine-ajax.js.org/)를 씀.  
    **Alpine.js 플러그인**으로 링크와 폼에 기본적인 AJAX 기능을 추가해줌

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

- 우리 스타트업은 HTMX를 도입했다가 결국 **React로 전환** 중임  
  HTMX는 응답 처리 복잡도가 높고, 각 엔드포인트가 여러 HTML 조각을 반환해야 함  
  문서와 사례가 부족하고, **대규모 베스트 프랙티스**도 없음.  
  React는 성숙하고, **AI 코딩과의 궁합**도 좋음. HTMX는 단순 프로젝트엔 적합하지만 그 이상은 어려움
  - 나는 HTMX로 **매끄러운 아키텍처 패턴**을 찾았음  
    각 엔드포인트는 하나의 역할만 수행하고, **Optimistic UI**로 즉시 반응함  
    에러 처리는 단순하게, `hx-swap-oob`는 최소 사용  
    기술 선택의 핵심은 **트레이드오프를 최소화**하는 것임
  - 프론트와 백엔드가 모든 시나리오에 합의해야 한다는 건 당연함.  
    그래서 나는 **백엔드 검증 중심**으로 두고, 프론트는 단순히 표시만 하게 함
  - [Hypermedia Systems](https://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](https://alpine-ajax.js.org/) 플러그인이 있어 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](https://htmx.org/essays/splitting-your-apis/) 글을 보면 오히려 좋은 점임
  - Jinja 같은 서버 템플릿을 쓰면 한 번의 렌더링으로 **여러 표현 형식**을 처리할 수 있음  
    전체 페이지를 서버에서 구성하면 데이터는 이미 그 안에 있음