--- title: "포럼 소프트웨어에서 React 걷어내고 HTMX로 돌아가려는 이유" published: 2026-07-27T09:58:50.000Z canonical: https://jeff.news/article/5090 --- # 포럼 소프트웨어에서 React 걷어내고 HTMX로 돌아가려는 이유 Misago 프로젝트가 React.js 기반 UI 구조를 걷어내고 Django 서버 렌더링과 HTMX 조합으로 단순화하려는 이유를 설명한 글이다. 같은 화면을 Django 템플릿과 React 컴포넌트로 두 번 구현하는 문제, 중복 번역 파일, JSON 직렬화 비용, 플러그인 개발 복잡도까지 꽤 현실적인 고통이 나온다. 결론은 포럼처럼 상호작용이 특정 영역에 몰린 서비스라면 풀 React 앱보다 서버 렌더링 HTML 조각 교체가 더 맞을 수 있다는 얘기다. - Misago가 지금 겪는 문제는 “React를 썼다”가 아니라 “같은 화면을 서버와 클라이언트에서 두 번 만들고 있다”는 데 있음 - 사용자가 `misago-project.org`에 접속하면 Django view가 스레드 목록 데이터를 모아서 템플릿으로 거의 완성된 HTML을 렌더링함 - 그런데 그 HTML 안에 같은 데이터를 담은 JSON도 같이 박아두고, 자바스크립트가 내려온 뒤 React.js가 그 JSON을 읽어서 Django가 만든 HTML 대부분을 다시 갈아엎음 - 결과적으로 버튼이 활성화되고 타임스탬프가 바뀌긴 하는데, 그 과정이 좀 많이 돌아가는 구조임 - 이 방식의 제일 큰 비용은 중복 구현임 - Misago의 많은 페이지가 Django 템플릿과 React.js 컴포넌트로 각각 구현돼 있음 - HTML을 커스터마이징하려는 사람은 Django 템플릿만 고쳤다가, 화면에 잠깐 보인 뒤 React HTML로 교체되는 걸 보고 당황하게 됨 - 게스트와 로그인 사용자 모두 접근하는 view는 Django view와 템플릿, React route와 컴포넌트, API, JSON serializer까지 같이 필요해짐 - 성능과 운영 비용도 같이 따라옴 - React 앱을 위해 데이터를 미리 JSON으로 직렬화하는 과정이 응답 생성 속도를 늦춤 - 번역 메시지도 `django.po`와 `djangojs.po`에 나뉘어 중복되고, 자바스크립트 번역 파일은 초기 다운로드 크기를 키움 - 오래되거나 느린 모바일 기기에서는 많은 자바스크립트 자체가 성능을 깎아먹을 수 있음 > [!IMPORTANT] > 이 글의 핵심은 “포럼 UI에 풀 클라이언트 앱이 꼭 필요한가?”라는 질문임. 스레드 목록, 모더레이션, 알림, 투표처럼 상호작용이 특정 영역에 고립돼 있다면 전체 페이지를 React로 다시 장악할 이유가 약해짐. - 플러그인 생태계까지 생각하면 복잡도는 더 커짐 - 플러그인이 페이지에 HTML을 주입하거나 교체하려면 Django 템플릿뿐 아니라 React 컴포넌트도 구현해야 함 - `misago-docker`에는 사이트 빌드 과정에 자바스크립트 빌드 단계까지 들어가야 함 - 플러그인 개발자도 Django와 React 양쪽을 알아야 하니 진입장벽이 올라감 - 작성자는 대안으로 두 가지를 검토했지만, 결국 더 단순한 방향을 택하려는 분위기임 - 하나는 Django view와 템플릿을 거의 버리고 API 중심으로 간 뒤 UI를 React 앱으로 만드는 것 - 다른 하나는 Django를 API로 줄이고 Next.js나 Remix.run 같은 서버 사이드 렌더링 프레임워크를 쓰는 것 - 하지만 포럼 소프트웨어는 오래전부터 서버에서 최대한 렌더링하고 필요한 곳에만 자바스크립트를 얹는 방식으로 잘 돌아왔다는 게 작성자의 판단임 - 그래서 나온 선택지가 HTMX임 - HTMX는 HTML 일부를 “동적 섬”처럼 지정하고, 사용자 상호작용이 생기면 서버가 렌더링한 새 HTML 조각으로 그 부분만 교체하게 해줌 - 예를 들어 스레드 목록에서 카테고리를 바꾸면 페이지 전체가 아니라 선택된 카테고리의 스레드 목록 HTML만 Django에서 받아와 갈아끼울 수 있음 - 이때 네비게이션 바에 이미 로드된 검색 결과 같은 다른 HTMX 영역은 그대로 유지할 수 있음 - 구현 관점에서도 백엔드 변경 폭이 줄어듦 - Django는 일반 요청이면 전체 페이지 HTML을 반환하고, HTMX 요청이면 해당 섬에 들어갈 HTML 조각만 반환하면 됨 - 별도 JSON 직렬화, 전용 API, React 컴포넌트, 클라이언트 라우팅을 매번 만들 필요가 줄어듦 - 작성자는 이걸 20년 전 jQuery의 `$.get("url", "#outlet")`이나 Rails Turbolinks에 가까운 선언적 방식이라고 표현함 > [!NOTE] > 작성자가 말하는 결론은 꽤 현실적임. 끝없는 스크롤이나 앱 같은 전환감이 꼭 필요한 게 아니라면, 포럼 소프트웨어에는 “서버가 HTML을 만들고 필요한 부분만 바꾸는 방식”이 오히려 더 잘 맞을 수 있다는 것. --- ## 기술 맥락 - 여기서의 기술 선택은 React.js 중심 구조에서 Django 서버 렌더링과 HTMX 조합으로 무게중심을 옮기는 거예요. 왜냐하면 Misago는 이미 Django가 거의 완성된 HTML을 만들고 있는데, React가 같은 데이터를 다시 읽어서 화면을 교체하면서 중복 비용이 커졌거든요. - 대안이 없었던 건 아니에요. 작성자는 아예 API 중심으로 가고 React 앱을 키우는 방법, 혹은 Next.js나 Remix.run 같은 서버 사이드 렌더링 프레임워크를 붙이는 방법도 봤어요. 그런데 포럼 소프트웨어의 상호작용은 모더레이션, 알림, 투표, 답글 작성처럼 특정 영역에 몰려 있어서 전체 앱 구조를 바꾸는 선택이 과하다고 본 거예요. - HTMX가 맞아 보이는 이유는 구현 단위가 페이지 전체가 아니라 HTML 조각이기 때문이에요. Django view가 일반 요청에는 전체 HTML을 주고, HTMX 요청에는 스레드 목록 같은 일부 HTML만 주면 되니까 JSON serializer와 별도 React route를 계속 만들 필요가 줄어들어요. - 이 결정은 프론트엔드 취향 문제가 아니라 확장 구조 문제에 가까워요. 플러그인이 HTML을 바꾸려면 Django 템플릿과 React 컴포넌트를 둘 다 알아야 하는 상황이었고, 이건 오픈소스 포럼 소프트웨어 입장에선 꽤 큰 유지보수 비용이에요. ## 핵심 포인트 - Misago는 현재 Django가 HTML을 렌더링한 뒤 React가 같은 데이터를 다시 읽어 화면 대부분을 교체하는 구조를 쓰고 있다. - 이 구조 때문에 템플릿, 라우트, API, 직렬화, 번역 파일, 플러그인 확장 지점이 중복된다. - 작성자는 포럼 UI의 상호작용은 대부분 고립된 영역에서 일어나므로 HTMX로 서버 렌더링 HTML 조각만 교체하는 쪽이 더 단순하다고 본다. ## 인사이트 이 글의 포인트는 React가 나쁘다는 얘기가 아니라, 서버 중심 앱에 SPA 구조를 얹었을 때 생기는 중복 비용이 생각보다 빨리 커진다는 데 있다. 특히 커스터마이징과 플러그인을 열어둔 오픈소스라면 프론트엔드 선택이 유지보수 정책이 돼버린다.