React에서 HTMX로 전환, 진짜 쓸만할까? (실무 관점 정리)

React 백오피스를 HTMX로 옮기는 건 데이터 조회 위주의 어드민 화면이라면 충분히 해볼 만합니다. 프론트엔드 코드가 크게 줄고, 백엔드 개발자가 UI까지 바로 만들 수 있으며, HTMX 라이브러리 자체는 압축(gzip) 시 14kb 수준입니다. 반면 클라이언트 상태가 복잡하거나, 오프라인 지원이 필요하거나, 네이티브 모바일 앱 계획이 있다면 맞지 않습니다.

HTMX는 "자바스크립트를 쓰지 않고(혹은 최소화하고) 모던 웹 앱을 만들 수 있다"는 매력적인 문구로 최근 프론트엔드 커뮤니티를 뜨겁게 달구고 있습니다. 이 글은 원래 무거운 React로 만들어진 사내 백오피스 시스템의 일부 페이지를 HTMX로 재작성할 때 무엇이 달라지는지, 공식 문서 요약을 넘어 장점, 단점, 그리고 현실적인 한계를 정리합니다.

왜 잘 돌아가는 React를 두고 HTMX를 도입할까?

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

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

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

단순한 CRUD(생성/읽기/수정/삭제) 화면 하나를 추가할 때마다 프론트엔드와 백엔드 코드를 양쪽 다 건드려야 합니다. "이거 그냥 서버에서 HTML 렌더링해서 툭 던져주면 끝나는 거 아닌가?"라는 생각이 든다면, HTMX가 바로 그 발상에서 출발한 도구입니다.

HTMX의 장점은 무엇인가요?

HTMX의 확실한 장점은 세 가지로, 주로 개발 경험 측면에서 드러납니다.

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

가장 큰 변화는 프론트엔드 자바스크립트가 대폭 줄어든다는 점입니다. 백오피스라면 관련 파일이 폴더째 사라질 수도 있습니다.

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 문서를 쓸고 닦는 일도 필요 없습니다. 서버에서 원하는 뷰를 그려서 내려주면 끝이니, 백오피스 개발 속도가 눈에 띄게 빨라질 수 있습니다.

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

무거운 React 라이브러리와 관련 생태계 패키지가 빠지면 초기 로딩 속도가 크게 빨라집니다. HTMX 라이브러리 자체는 압축(gzip)하면 14kb 수준밖에 되지 않아, 저사양 노트북이나 모바일 환경에서 백오피스에 접속할 때의 버벅거림도 상당 부분 사라질 수 있습니다.

HTMX의 치명적인 단점은 무엇인가요?

"다 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 서비스라면 매우 심각한 고려 사항입니다.

결론: HTMX, 누가 언제 써야 할까요?

제 결론은 **"HTMX는 은탄환(Silver Bullet)이 아니지만, 특정 영역에서는 React보다 확실히 나은 도구"**라는 것입니다.

👍 HTMX를 추천하는 경우:

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

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

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

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