
솔직히 고백하자면, 저는 지난 몇 년간 '프론트엔드 공포증'을 앓았습니다. 스타트업 시절, 인력이 부족해 백엔드 API부터 프론트엔드 UI까지 모두 도맡아야 했을 때 겪었던 트라우마 때문입니다. 당시에는 React나 Vue 같은 SPA(Single Page Application) 프레임워크가 마치 개발의 정답인 것처럼 여겨졌습니다. 간단한 사내 어드민 페이지 하나를 만드는 데도 npm install을 시작으로 수백 개의 의존성을 설치하고, Webpack 설정을 만지작거리고, Redux나 Recoil 같은 상태 관리 라이브러리와 씨름해야 했습니다. 비즈니스 로직은 이미 서버에 다 있는데, 이걸 다시 브라우저에서 상태로 관리하려니 코드는 비대해지고 버그는 증식했습니다. "고작 버튼 하나 눌러서 데이터를 업데이트하는데 이렇게 많은 보일러플레이트가 필요한가?"라는 회의감이 들 때마다, 저는 그저 제가 트렌드를 따라가지 못하는 것이라 자책하곤 했습니다.
하지만 최근 이직한 회사에서 레거시 시스템을 분석하고, 운영팀을 위한 긴급 백오피스 기능을 개발하면서 생각이 완전히 바뀌었습니다. 운영팀은 화려한 UI나 부드러운 페이지 전환보다는 '정확하고 빠른 데이터 처리'를 원했습니다. 굳이 무거운 Next.js 프로젝트를 띄우고 API 명세서를 작성하며 프론트엔드와 백엔드를 분리할 이유가 없었습니다. 그때 제 눈에 들어온 것이 바로 htmx였습니다. 처음에는 그저 과거의 유물인 jQuery 시절로 돌아가는 것 아닌가 하는 의구심이 들었지만, 깃허브 리포지토리의 README를 읽어내려가며 머리를 한 대 맞은 듯한 충격을 받았습니다. htmx가 던지는 질문은 본질적이었습니다. "왜 HTML의 <a> 태그와 <form> 태그만 HTTP 요청을 보낼 수 있는가?", "왜 클릭과 제출(submit)만 요청을 트리거해야 하는가?", "왜 오직 GET과 POST 메서드만 사용해야 하는가?"
htmx의 접근 방식은 놀라울 정도로 직관적이었습니다. HTML 속성(Attribute) 몇 개만으로 모던 웹의 기능을 구현할 수 있었기 때문입니다. 예를 들어, 버튼을 클릭했을 때 서버로 POST 요청을 보내고, 응답받은 HTML 조각으로 버튼 자체를 교체하는 로직을 작성한다고 가정해 봅시다. 기존의 리액트 방식이라면 상태(state)를 정의하고, fetch나 axios로 비동기 통신 함수를 짜고, useEffect로 라이프사이클을 관리해야 했을 겁니다. 하지만 htmx를 사용하면 <button hx-post="/clicked" hx-swap="outerHTML">Click Me</button> 이 한 줄로 끝납니다. 자바스크립트 파일에 별도의 이벤트 리스너를 등록할 필요도, JSON 데이터를 파싱하느라 고생할 필요도 없습니다. 서버는 그저 완성된 HTML 조각을 내려주면 그만입니다.
이 도구를 실제 사내 어드민 도구 개발에 도입해 보았습니다. 결과는 놀라웠습니다. 프론트엔드 빌드 파이프라인이 사라지니 배포 속도가 비약적으로 빨라졌고, 백엔드 개발자인 제가 가장 잘 다루는 서버 사이드 템플릿(Thymeleaf나 Django Template 등)에만 집중하면 되니 생산성이 2배 이상 올랐습니다. 무엇보다 코드의 '응집도'가 높아졌습니다. 동작과 구조가 한곳에 모여 있으니, 6개월 뒤에 다시 코드를 봐도 "아, 이 버튼은 /clicked로 요청을 보내는구나"라고 즉시 파악할 수 있었습니다. 최근 업무에 적극 활용 중인 AI 코딩 도구인 Cursor나 Claude에게 코드를 요청할 때도 훨씬 효율적이었습니다. 복잡한 리액트 컨텍스트를 설명할 필요 없이, "이 버튼 누르면 저 div 갱신해 줘"라고만 하면 htmx 속성을 뚝딱 만들어주니까요.
물론 htmx가 만능열쇠는 아닙니다. 페이스북이나 노션처럼 고도의 상호작용이 필요한 B2C 서비스를 만든다면 여전히 React나 Svelte 같은 프레임워크가 필수적일 것입니다. 하지만 우리가 개발하는 소프트웨어의 80%는 그렇게 복잡한 상태 관리가 필요하지 않습니다. 특히 백엔드 개발자가 주도하는 어드민 툴, 대시보드, MVP(Minimum Viable Product) 프로젝트에서 htmx는 강력한 무기가 됩니다. 단순히 기술적인 도구를 넘어, "HTML을 진짜 하이퍼텍스트답게 쓰자"는 철학은 복잡도에 매몰되어 있던 저에게 '적정 기술'의 가치를 다시금 일깨워 주었습니다.
후배 개발자분들께 꼭 드리고 싶은 말씀이 있습니다. "요즘 뜨는 기술이니까", "남들이 다 쓰니까"라는 이유로 무조건 거창한 프레임워크를 선택하지 않으셨으면 좋겠습니다. 때로는 문제 해결을 위해 가장 단순한 도구를 선택하는 것이야말로 진정한 엔지니어링 실력입니다. 14kb 남짓한 이 작은 라이브러리가 주는 교훈은 명확합니다. 기술의 본질을 이해하면, 유행에 휩쓸리지 않고 가장 효율적인 길을 찾을 수 있다는 것입니다. 저처럼 프론트엔드의 복잡함 속에서 길을 잃었던 분이라면, 이번 주말 가벼운 마음으로 htmx를 한번 써보시는 건 어떨까요? 어쩌면 잃어버렸던 웹 개발의 즐거움을 되찾을지도 모릅니다.


