React에서 HTMX로 넘어간 6개월, 진짜 쓸만할까? (실무 경험담)

최근 프론트엔드 개발자 커뮤니티를 뜨겁게 달구고 있는 키워드 중 하나가 바로 HTMX입니다. "자바스크립트를 쓰지 않고(혹은 최소화하고) 모던 웹 앱을 만들 수 있다"는 매력적인 문구에 이끌려 많은 분들이 관심을 가지고 계실 텐데요.

저 역시 호기심을 참지 못하고, 회사에서 운영 중인 사내 백오피스 시스템(원래는 무거운 React로 만들어져 있었습니다) 중 일부 페이지를 HTMX로 완전히 재작성해 보았습니다. 지난 6개월 동안 실제로 프로덕션 환경에서 굴려보면서 느낀 장점, 단점, 그리고 현실적인 한계를 아주 솔직하게 공유해 보려고 합니다.

단순히 공식 문서를 요약하는 것이 아니라, 제가 밤을 새우며 겪었던 진짜 삽질 경험이 담겨 있으니 끝까지 읽어주세요!

1. 왜 잘 돌아가는 React를 냅두고 HTMX를 도입했나?

가장 큰 이유는 '복잡성'에 대한 피로감이었습니다.

저희 백오피스는 전형적인 SPA(Single Page Application) 구조였습니다. 데이터 하나를 불러와 표(Table)로 보여주기 위해 너무 많은 과정이 필요했죠.

• API 엔드포인트를 만들고 JSON으로 응답하게 한다.
• 프론트엔드에서 fetch나 axios로 데이터를 호출한다.
• useState나 useEffect로 상태 관리를 한다.
• (로딩 중 처리) 컴포넌트 렌더링.
• (에러 처리) 에러 바운더리 또는 토스트 알림 띄우기.

단순한 CRUD(생성/읽기/수정/삭제) 화면 하나를 추가할 때마다 프론트엔드와 백엔드 코드를 양쪽 다 건드려야 했습니다. "이거 그냥 서버에서 HTML 렌더링해서 툭 던져주면 끝나는 거 아닌가?"라는 생각이 들 무렵, HTMX가 눈에 들어왔습니다.

2. HTMX 도입 후 체감한 확실한 장점 3가지

막상 코드를 엎고 나니, 개발 경험 측면에서 확실히 달라진 점들이 있었습니다.

압도적으로 줄어든 코드 양 (특히 프론트엔드)

이게 가장 컸습니다. 프론트엔드 쪽 자바스크립트 파일들이 통째로 사라지는 마법을 경험했습니다.

React에서는 상태 관리(useState, Redux, Zustand 등)와 API 통신을 위한 코드가 필수적입니다. 하지만 HTMX를 쓰면 마크업(HTML) 자체에 동작을 정의할 수 있습니다.

<!-- HTMX 적용 예시 -->
<button hx-post="/api/users/123/approve"
        hx-target="#user-status"
        hx-swap="innerHTML">
  승인하기
</button>

버튼을 누르면 서버에 POST 요청을 보내고, 서버가 응답으로 준 HTML 조각을 #user-status 영역에 알아서 갈아 끼워줍니다. 프론트엔드 상태 관리가 사실상 필요 없어지는 셈이죠.

"풀스택" 개발의 귀환과 빠른 생산성

과거 PHP나 JSP 시절처럼 백엔드 개발자가 곧 프론트엔드 개발자가 될 수 있었습니다. 저는 백엔드로 Python(FastAPI)과 Go를 주로 사용하는데, 백엔드에서 템플릿 엔진을 통해 HTML을 바로 렌더링하여 내려주는 방식으로 작업 흐름이 바뀌었습니다.

프론트/백엔드 API 스펙을 맞추기 위해 회의를 할 필요도, Swagger 문서를 쓸고 닦을 필요도 없었습니다. 그냥 서버에서 원하는 뷰를 그려서 내려주면 끝이었으니까요. 백오피스 개발 속도가 체감상 2배 이상 빨라졌습니다.

눈에 띄게 가벼워진 번들 사이즈와 로딩 속도

당연한 이야기지만, 무거운 React 라이브러리들과 관련 생태계 패키지들이 빠지니 초기 로딩 속도가 미친 듯이 빨라졌습니다. HTMX 라이브러리 자체는 압축(gzip)하면 14kb 수준밖에 되지 않습니다. 저사양 노트북이나 모바일 환경에서 백오피스를 접속할 때 버벅거림이 완전히 사라졌습니다.

3. 하지만, 현실은 녹록지 않았다 (치명적인 단점들)

"이거 완전 혁명인데? 다 HTMX로 바꾸자!"라고 외치기엔, 실무를 하면서 뼈저리게 느낀 치명적인 한계점들이 존재했습니다.

오프라인 지원과 복잡한 클라이언트 상태(Client State)의 부재

HTMX의 철학은 **"서버가 상태를 들고 있는다(Server-Source-Of-Truth)"**입니다. 모든 인터랙션은 서버와의 통신을 전제로 합니다.

문제는 네트워크가 불안정하거나, 화면 이동 없이 브라우저 내에서만 복잡하게 상태가 변해야 하는 UI(예: 복잡한 다중 스텝 폼, 드래그 앤 드롭으로 순서를 실시간으로 바꾸고 마지막에 저장하는 UI)를 구현할 때 발생했습니다.

React였다면 로컬 state에 담아두고 요리조리 만지면 그만인데, HTMX로는 이 과정이 너무 매끄럽지 않았습니다. 결국 이런 부분은 Alpine.js나 순수 자바스크립트를 덕지덕지 붙여서 해결해야 했고, 코드가 다시 스파게티처럼 꼬이는 느낌을 받았습니다.

재사용 가능한 UI 컴포넌트 생태계의 부재

React의 가장 큰 무기는 거대한 생태계입니다. MUI, Ant Design, Radix UI 등 가져다 쓰면 바로 예쁘고 접근성(a11y)까지 챙겨주는 컴포넌트들이 널려 있죠.

HTMX 환경에서는 이런 컴포넌트를 제가 직접 바닥부터 깎아야 합니다. 디자인 시스템이 잘 구축되어 있고 Tailwind CSS 등을 쓴다고 해도, 복잡한 DatePicker나 AutoComplete 같은 컴포넌트를 직접 만들거나 서버 렌더링에 맞게 개조하는 작업은 엄청난 고통이었습니다. (오픈소스 생태계의 위대함을 다시 한번 깨달았습니다...)

모바일 앱(Native App) 확장의 어려움

만약 우리의 프로덕트가 나중에 iOS나 Android 네이티브 앱으로 나와야 한다면? React(JSON API 기반)로 만들어두었다면, 기존 백엔드 API를 그대로 모바일 앱에서 가져다 쓰면 됩니다.

하지만 HTMX를 위해 만든 백엔드 엔드포인트는 JSON이 아니라 HTML 조각을 리턴합니다. 모바일 앱에서는 HTML 조각을 파싱해서 쓸 수가 없죠. 결국 모바일 앱을 위한 별도의 JSON API 서버를 새로 파거나, 로직을 두 번 짜야 하는 끔찍한 상황이 발생할 수 있습니다. 다행히 저희는 백오피스라 모바일 앱이 필요 없었지만, B2C 서비스라면 매우 심각한 고려 사항입니다.

4. 결론: 그래서 HTMX, 누가 언제 써야 할까요?

6개월간의 치열한 동거 끝에 제가 내린 결론은 **"HTMX는 은탄환(Silver Bullet)이 아니지만, 특정 영역에서는 React를 압살하는 최고의 도구"**라는 것입니다.

👍 HTMX를 강력히 추천하는 경우:

• 사용자보다 관리자가 주로 쓰는 어드민 / 백오피스 대시보드
• 상호작용이 복잡하지 않고, 주로 데이터의 조회와 단순 입력이 주를 이루는 서비스
• 프론트엔드 전담 인력이 부족하고, 백엔드 개발자가 빠르게 UI까지 쳐내야 하는 소규모 팀

👎 HTMX 도입을 말리고 싶은 경우:

• Trello, Figma, Google Docs처럼 클라이언트 상호작용이 극도로 복잡한 앱
• 오프라인 모드 지원이 필수적인 앱
• 가까운 미래에 모바일 네이티브 앱(iOS/AOS) 출시 계획이 있는 서비스

개발 트렌드에 휩쓸려 무작정 최신 기술을 도입하기보다는, 현재 우리 팀과 프로덕트가 처한 상황을 냉정하게 분석하는 것이 중요합니다. 저의 경험담이 여러분의 다음 프로젝트 기술 스택 선정에 작은 힌트가 되기를 바랍니다!