## 내가 Alpine.js에 정착하고 HTMX를 멀리하게 된 이유 {#sec-a4901ce975c0}

안녕하세요. 오늘은 백엔드 위주의 Django 개발자로서, 최근 프론트엔드 생태계에서 '[[JavaScript]] 적게 쓰기' 열풍을 이끄는 두 주인공, **[[Alpine.js]]**와 **[[HTMX]]**에 대해 이야기해보려 합니다.

저처럼 Django와 Python에 익숙한 사람들에게 이 툴들은 정말 고마운 존재입니다. 복잡한 React나 Vue 설정 없이도 꽤 그럴싸한 현대적인 웹사이트를 만들게 해주니까요. 하지만 이 두 친구는 사용목적과 성격이 아주 다릅니다. HTMX는 서버와의 통신에 특화되어 있고, Alpine.js는 브라우저 내부의 UI 동작에 특화되어 있기 때문입니다.

결론부터 말하자면, 저는 **Alpine.js**의 광팬이 되었고, **HTMX**와는 조금 거리를 두게 되었습니다. 그 이유를 가감 없이 공유해 보겠습니다.

![htmx와 Alpine.js의 비교 이미지](/media/whitedec/blog_img/c6faef36da5c4f90a5e774e7c86df0cf.webp)

---

## 1. 사전 지식: [[HTMX]] vs [[Alpine.js]] 한눈에 보기 {#sec-588a3f69cb07}
본론에 들어가기 전, 이 두 개념이 생소한 분들을 위해 간단히 비교표를 정리했습니다.

| 구분 | HTMX | Alpine.js |
| :--- | :--- | :--- |
| **핵심 목적** | **서버 통신** (AJAX 요청 후 HTML 교체) | **클라이언트 상태 관리** (UI 상호작용) |
| **철학** | HTML의 확장 (서버 중심) | Vue/React의 경량화 (브라우저 중심) |
| **데이터 형태** | **HTML 조각 (Snippet)** | **JSON 데이터** |
| **주요 강점** | 무한 스크롤, 실시간 검색 (SSR 방식) | 모달, 드롭다운, 탭 전환 (CSR 방식) |



---
## 2. 내가 HTMX를 점점 기피하게 된 4가지 이유 {#sec-cbf50b3543fc}

HTMX는 언뜻 보면 굉장히 편합니다. 하지만 실제로 프로젝트에 깊게 적용해 볼수록 저의 개발 성향과 충돌하는 지점들이 생기더군요.

### ① "굳이 HTML 조각을 서버에서 만들어야 하나?" (유지보수의 딜레마) {#sec-ccc17a7c9816}
HTMX를 쓰려면 서버(Django)가 JSON이 아니라 **HTML 스니펫**을 반환해야 합니다. 이게 제 성격에는 좀 맞지 않았습니다.
* **나의 시각:** "서버는 데이터만 깔끔하게 주고, 렌더링은 클라이언트가 하는 게 역할 분담이 확실하지 않나?"
* **HTMX의 입장:** "JSON 받아서 다시 렌더링하는 게 낭비다. 서버가 최종 결과물을 주는 게 진실의 원천(SSOT)이다."

Django 템플릿 안에서 `if request.htmx:` 같은 분기 처리를 넣다 보면, 뷰(View) 로직이 파편화되고 지저분해지는 느낌을 지울 수 없었습니다.

### ② AJAX 로직, 이미 충분히 쉽지 않나? {#sec-3d93df5c1f47}
HTMX의 `hx-get`, `hx-target`은 훌륭한 '문법적 설탕'입니다. 하지만 이미 Vanilla JS나 나만의 유틸리티 함수로 AJAX를 구현해 본 사람에게는 필수적이지 않습니다.
요즘 브라우저의 **fetch API**는 정말 강력합니다. Alpine.js의 `x-init` 안에서 fetch 한 줄 쓰는 것만으로도 충분히 선언적이고 깔끔한 코드가 나오는데, 굳이 또 다른 라이브러리의 규칙을 따를 필요성을 덜 느끼게 되었습니다.

### ③ 치명적인 "Locality of Behavior (LoB)"의 단절 {#sec-2cd75954bdb6}
저는 Alpine.js를 정말 좋아합니다. 코드가 뭘 하는지 **그 자리에서 바로 보이기 때문**이죠. 하지만 HTMX는 다릅니다.
* **Alpine.js:** 행동(Behavior)이 HTML 안에 있고, 결과도 브라우저 메모리 안에서 즉시 일어납니다.
* **HTMX:** 행동은 HTML에 정의되어 있지만, **결과물(HTML 조각)을 보려면 다시 서버 코드(`views.py`)를 뒤져봐야 합니다.**

이 과정에서 맥락(Context)이 끊기는 게 굉장히 비효율적이라고 느꼈습니다. 코드를 읽다가 자꾸만 백엔드 파일을 열어봐야 하는 귀찮음, 그게 htmx를 기피하게 된 결정적 이유 중 하나입니다.

### ④ 미세한 레이턴시(Latency)의 불편함 {#sec-c2deaaea82da}
HTMX는 모든 상호작용이 네트워크 왕복을 전제로 합니다.

아무리 서버가 빨라도 브라우저 내부에서 즉각 반응하는 Alpine.js의 속도를 따라갈 순 없습니다. 클릭했을 때 0.1~0.2초씩 느껴지는 그 미세한 지연이, 사용자 경험 측면에서 저에게는 꽤 거슬리는 요소였습니다.

---

## 마무리하며: 여러분의 생각은 어떠신가요? {#sec-fbc8664e9292}

정리하자면, 저는 **데이터는 API(JSON)로 흐르고, UI는 브라우저 안에서 즉시 반응해야 한다**는 구조를 선호합니다. 그래서 Alpine.js와 DRF(Django REST Framework)의 조합을 가장 좋아하죠.

재미있는 점은, 최근 레딧(Reddit) 같은 커뮤니티를 보니 저와는 정반대의 의견이 많더라고요. [[Alpine.js]]을 복잡하다고 느끼며 HTMX나 심지어 jQuery + HTMX 조합으로 돌아가는 분들이 많았습니다. 어쨌든 확실히 요즘은 HTMX의 인기가 압도적인 것 같긴 합니다.

물론 [[HTMX]]는 매우 훌륭한 툴입니다. 단지 저의 개발 스타일과 시스템 설계 방식에 맞지 않았을 뿐이죠. **"정답은 없고 나에게 맞는 옷이 있을 뿐"**이라는 생각이 듭니다.

여러분은 어떠신가요? HTMX의 서버 중심 철학에 만족하시나요, 아니면 저처럼 JSON 응답과 Alpine.js의 즉각적인 반응성을 더 선호하시나요? 댓글로 의견을 들려주세요!

어쩌면 저는 HTMX의 진정한 힘을 깨닫기도 전에 너무 일찍 멀리한 것일까요?