기타 Lobsters · 2일 전

"HTMX가 컴포넌트 조립이 된다고?" 직접 플러그인 만들어보고 놀란 개발자

핵심 요약
  • 마스토돈 피드 앱 'Fossil'을 개발하던 엔지니어가 HTMX 기반으로 풀스택 플러그인 시스템을 구축한 경험을 공유했습니다.
  • 흔히 모놀리식이라 확장이 어려울 것이라는 편견과 달리, UI·API·DB를 한데 묶어 확장하기엔 상태가 분산되는 React+REST 조합보다 HTMX가 훨씬 직관적이었다고 밝혔습니다.
  • HTML을 일종의 선언형 설정 언어로 취급함으로써 복잡한 클라이언트-서버 간 상태 동기화 문제를 피할 수 있었다는 분석입니다.
요약 개발자 팀 켈로그(Tim Kellogg)가 마스토돈용 맞춤형 피드 클라이언트 'Fossil'을 개발하며 겪은 HTMX 플러그인 아키텍처 구축기를 공유했습니다. 그는 당초 빅테크의 추천 알고리즘과 반대로 자신이 원하는 정보만 부각하는 피드 리더를 만들고자 Streamlit으로 프로토타입을 제작했으나, 해커뉴스 피드백을 계기로 누구나 자신만의 추천 알고리즘을 끼워 넣을 수 있는 플러그형 프레임워크로 전면 개편하기로 결정했습니다. 이후 HTMX를 도입해 앱을 재작성하는 과정에서 의외의 발견을 하게 됩니다. 백엔드와 프론트엔드가 하나로 뭉쳐 모놀리식할 것 같았던 HTMX가 사실은 풀스택 플러그인 확장에 매우 유연했던 것입니다. 개발자는 UI 버튼 추가, API 엔드포인트 등록, SQLite 테이블 생성, AI 알고리즘 연동까지 단일 파이썬 플러그인 클래스 안에서 손쉽게 엮어낼 수 있었습니다. 예컨대 디버깅용 플러그인의 경우, 클릭 시 서버 콘솔에 JSON을 출력하고 버튼 텍스트를 즉시 교체하는 HTML 조각과 FastAPI 엔드포인트를 한 파일에 간결하게 정의할 수 있었습니다. 작성자는 흔히 리액트와 REST API의 조합이 컴포넌트 단위로는 조합성이 뛰어나 보이지만, 실제로는 클라이언트와 서버 간에 상태가 쪼개진 '분산 시스템'이 되어 에러 처리나 확장이 훨씬 까다로워진다고 지적했습니다. 반면 HTMX는 HTML 자체를 일종의 선언적 설정 언어처럼 사용하고 상태 관리를 브라우저 엔진에 맡김으로써, 과거 지나치게 복잡했던 IoC XML 설정보다 훨씬 직관적으로 전체 스택을 조합할 수 있었다고 평가했습니다.
Sponsored · 광고