왜 모두가 React를 쓰는데, 우리는 쓰지 않아도 되는가? — 프론트엔드 전쟁의 역사와 Hotwire의 탄생 이유
요즘 웹 개발 이야기를 들으면
항상 똑같은 말이 나온다.
“프론트는 React로 해야지.”
“요즘은 다 React 써.”
“React 안 배우면 개발자 못 된다.”
하지만 진짜일까?
아니, 정확히 말하면 절반만 맞는 말이다.
React가 좋은 라이브러리인 건 사실이다.
그런데 문제는…
React가 “필요한 상황”은 정말 전체 웹서비스 중 10~20% 정도라는 것이다.
그리고 놀랍게도,
Rails 개발자가 만드는 대부분의 서비스는
그 10~20% 안에 속하지 않는다.
1. React가 자리잡기까지 수많은 라이브러리들이 장렬히 전사했다
초보 개발자들은 잘 모르는 사실이 하나 있다.
React는 처음부터 ‘절대 강자’가 아니었다.
그 전에 있었던 수많은 프레임워크와 라이브러리들은
지금 거의 사라졌다.
AngularJS (사망)
Ember.js (사망 직전)
Backbone.js (거의 사라짐)
Knockout.js
ExtJS
Meteor 프런트엔드 레이어
jQuery + SPA 프레임워크들
Mithril, Riot, Preact…
프론트엔드 생태계는
10년 동안 100개 넘는 기술이 부상하고, 98%가 사라지는 난세였다.
React만 살아남은 이유는 크다:
그나마 구조가 좋았고
그나마 유지보수가 쉬웠고
그나마 기업들이 채택했다
그러나 이 말은 React도 언젠가 사라질 것이라는 뜻이다.
왜냐하면 프론트엔드 기술의 본질은 언제나 동일하기 때문이다.
2. React도 점점 비대해지고 복잡해지고 있다 (현실)
초기 React는 정말 단순했다.
“UI는 상태(state)의 함수다.”
그런데 현재 React는 어떻게 되었는가?
React
ReactDOM
JSX
Babel
Webpack
Vite
Next.js
Zustand
Redux
Suspense
Server Components
hydration
client/server boundary
streaming
routing
bundler
compiler 기반 렌더링…
이 모든 것들이
React 생태계 안에서 “필수 논의”가 되어버렸다.
React는 더 이상 단순한 라이브러리가 아니다.
React는 자체로 하나의 복잡한 세계가 되었고, 매년 더 어려워지고 있다.
이렇게 되면 어떤 문제가 생길까?
신규 개발자의 진입 장벽 폭증
팀 전체가 React 전문가가 아니면 유지보수 난이도 급상승
프로젝트 초기 속도가 엄청나게 느려짐
서버는 단순한데 프런트가 오히려 핵심 복잡성의 원인이 됨
그리고 이 질문이 따라온다.
“내 서비스가 정말 React가 필요한가?”
3. 대부분의 SaaS, 웹서비스는 React가 필요 없다
React가 필요한 상황은 주로 두 가지다:
실시간으로 UI가 계속 바뀌는 복잡한 SPA
(예: Figma, 슬랙(Web), Notion, Trello 등)대규모 프런트엔드 조직 + 멀티팀 협업이 필요한 초거대 프로젝트
하지만 Rails 개발자가 만드는 서비스는 어떠한가?
CRUD 서비스
대시보드
블로그
커뮤니티
데이터 검색 중심 서비스
Form 중심 서비스
고객관리
내부 도구
SaaS
전자상거래 백오피스
이런 서비스는
React의 반 정도 기능도 필요 없다.
그리고 React를 쓰면
오히려 개발 속도는 느려지고
복잡성이 급격히 증가한다.
4. 이런 배경에서 탄생한 기술이 바로 Hotwire다
Hotwire는 Rails 팀이 제안한 기술 스택이며
이 철학을 핵심으로 한다.
“Front-end의 80%는 굳이 React처럼 복잡할 필요가 없다.”
Hotwire의 구성은 심플하다:
Turbo (HTML streaming + partial updates)
Stimulus (작은 자바스크립트 엔진)
Cable + Streams (실시간)
하지만 핵심은 이것이다.
HTML 그 자체를 업데이트하는 방식이 대부분의 웹서비스에서 가장 빠르고, 가장 쉬우며, 가장 유지보수 가능하다.
React처럼
상태 → diff → 렌더링 → hydration…
이런 복잡한 과정이 없다.
Hotwire는 Rails의 철학을 그대로 따른다:
단순함
생산성
반복 속도
유지보수성
코드의 적음
개발자의 행복
그리고 놀라운 현실:
실제로 만들어보면 React보다 3배 빠르고,
코드량은 1/5 수준이며,
버그는 극적으로 줄어든다.
5. React를 안 써도 되는 이유 — Hotwire가 이미 해결했다
React가 해결하려던 문제 10개 중
Hotwire는 7~8개를 서버 중심 방식으로 해결한다.
예:
| 문제 | React 방식 | Hotwire 방식 |
|---|---|---|
| UI 업데이트 | diff 계산 → 렌더 | 그냥 HTML 조각을 서버가 보내줌 |
| 상태 관리 | Redux/Zustand | 서버 상태 = UI 상태 |
| 라우팅 | 프런트 라우터 | Turbo로 페이지 이동 최적화 |
| 실시간 | WebSocket + 클라이언트 렌더 | Turbo Stream으로 바로 HTML 업데이트 |
| SEO | 별도 설정 | 서버 렌더링 100% |
| 빌드 | Babel/Webpack/Vite | 없음 (No build!) |
| 복잡성 | 고도화됨 | 낮음 |
Hotwire는 Rails 개발자의 생산성을 극적으로 올린다.
6. 그럼 React는 어떻게 될까? 언젠가 전사한다. 거의 확실하게.
왜냐하면 프론트엔드의 역사는 반복되어 왔기 때문이다.
- 처음에는 단순한 UI 라이브러리
→ 점점 기능이 비대해지고
→ 복잡해지고
→ 조직은 유지 못하고
→ 다른 기술이 등장
→ 세대교체 발생
React도 이 길을 걷고 있다.
실제로 이미 징후가 보인다.
React Server Components는 너무 복잡해서 개발자 반발
성능 이슈
Next.js가 React 규칙을 주도(React 본체가 더 이상 독립적이지 않음)
경쟁자(솔리드, Qwik, Svelte, HTMX 등) 등장
“No Build + 서버 중심 웹” 흐름이 재부상
현재 오히려 개발자들이 말한다:
“요즘 웹 너무 복잡해졌다. 다시 단순함이 필요하다.”
이 흐름은 역사적으로 항상 맞았다.
메인프레임 → PC(단순성 회귀)
SOAP → REST(단순성 회귀)
jQuery 시절 난세 → React(단순성 회귀)
복잡해진 SPA → Hotwire/HTMX(단순성 회귀)
React는 결국 사라진다. 단지 “언제냐”의 문제일 뿐이다.
결론 — 우리는 기술을 선택하는 것이 아니라, 방향을 선택하는 것이다
React를 배우지 말자는 것이 아니다.
React가 필요할 때는 반드시 쓰면 된다.
하지만 대부분의 서비스는 React가 필요 없다. 복잡한 기술을 쓰는 순간 속도가 느려지고 유지보수가 어려워진다.
Rails + Hotwire는 이렇게 말한다:
“웹은 본래 단순해야 한다.
서버가 HTML을 주고, 브라우저가 보여주면 된다.
모든 복잡성은 필요할 때만 조금씩 얹으면 된다.”
이 철학은
AI 시대의 개발 방식과도 완벽하게 들어맞는다.
초심자라면 특히 Hotwire를 쓸 이유가 강력하다.
빠르다
쉽다
명확하다
버그가 적다
서버 상태 = UI 상태
빌드 시스템이 없다
유지보수가 쉽다
1인 개발자에게 최적
그리고 가장 중요한 말:
Hotwire는 React보다 훨씬 오래갈 기술이다. Rails의 철학은 20년을 버텼고 앞으로도 변하지 않을 것이다.