새 프로젝트가 시작될 때 기술 스택 논의는 대개 이렇게 흘러간다. "React 쓰자, 다들 알잖아." 이 한 문장이 아키텍처 결정을 대신한다. jsx.lol은 바로 이 관성을 정면으로 겨냥한 큐레이션 사이트다. "Does anybody actually like React?"라는 도발적인 질문 아래 수십 편의 비판 글을 모아놓은 이 사이트는, 단순한 불만 컬렉션이 아니라 React 중심 생태계가 쌓아온 구조적 문제들의 스냅샷이다.
비판의 층위는 생각보다 두텁다. 가장 표면적인 문제는 성능이다. 하이드레이션 패턴—서버에서 JS로 연산하고, HTML을 즉시 보내고, 다시 동일한 JS를 클라이언트에 전달하는 이중 구조—은 React의 기본값이 된 지 오래다. Microsoft Edge 팀이 React에서 Web Components + HTML-first 아키텍처로 전환한 사례, 그리고 한 팀이 React SPA를 Phoenix LiveView로 교체한 지 몇 주 만에 성능 문제를 해결한 사례는 이 구조적 비용이 특정 규모 이상에서 얼마나 선명하게 드러나는지를 보여준다.
더 깊은 문제는 학습 곡선과 API 설계다. useEffect로 dialog, popover 같은 네이티브 기능을 우회해야 하는 현실, autofocus가 제대로 작동하지 않는 환경, synthetic event 시스템 때문에 실제 DOM 동작을 배울 기회가 줄어드는 구조—이것은 단순한 불편함이 아니라 "React가 모던 UI를 가르쳐준다"는 명제 자체를 흔드는 문제다. Hacker News의 한 개발자는 이를 정확히 짚었다. Vue에서 watch와 computed가 하는 일을 React에서는 useEffect와 useMemo로 직접 관리해야 하고, 그 민간전승은 API가 바뀔 때마다 일부가 틀린 정보가 된다.
보안과 거버넌스 이슈도 빠질 수 없다. CVE-2025-55182는 CVSS 10.0—인증 없는 원격 코드 실행(RCE)—등급으로 공개된 React Server Components 취약점이다. 취약점 자체보다 더 주목해야 할 것은 Vercel의 대응 방식이었다. "Next.js는 오픈소스 프레임워크를 가장한 Vercel 벤더 락인"이라는 비판이 단순한 감정적 반응이 아닌 거버넌스 우려로 읽히기 시작한 것은 바로 이 맥락에서다. 프레임워크 선택이 곧 특정 클라우드 벤더 의존성 선택이 된다면, 그 비용은 기술 부채가 아니라 사업 리스크로 분류해야 한다.
그렇다면 이 비판들이 "React를 쓰지 말라"는 결론으로 이어져야 할까. 나는 그렇게 읽지 않는다. 16년간 JavaScript 생태계를 경험한 한 개발자가 Hacker News에 남긴 말이 더 정직하다. "React는 우리가 시도해 본 다른 모든 것들을 제외하면 최악의 JavaScript 프레임워크다." Angular 1의 양방향 바인딩 지옥, Backbone의 조립 피로, jQuery 수프—React는 그 반성의 산물이었고, 그 역할을 충분히 해냈다. 문제는 React가 나빠진 것이 아니라, React가 설계된 맥락(Facebook 규모, Facebook 자원)과 대부분의 프로젝트가 놓인 맥락이 다르다는 점을 아키텍처 결정 시점에 고려하지 않는다는 것이다.
여기서 프로덕트 사고가 필요해진다. "우리 팀이 React를 아니까 쓴다"는 결정과 "이 제품의 인터랙션 복잡도와 팀 규모에 React가 맞는가"를 묻는 결정은 전혀 다른 프로세스다. 콘텐츠 중심 사이트에서 하이드레이션 비용을 지불할 이유는 없다. 소규모 팀이 빠른 사용자 검증이 필요한 프로토타입을 만든다면 Svelte나 심지어 점진적 향상(progressive enhancement) 기반의 HTML-first 접근이 훨씬 빠른 피드백 루프를 만든다. 반면 대규모 인터랙티브 대시보드, 복잡한 상태 관리가 필요한 SaaS, 풍부한 채용 풀이 필요한 엔터프라이즈 팀이라면 React의 네트워크 효과는 여전히 실질적인 자산이다.
AI 워크플로우 관점에서도 이 논의는 흥미롭게 교차한다. v0.dev나 Cursor로 빠르게 프로토타입을 뽑아낼 때 React + Tailwind + shadcn/ui 스택은 AI가 가장 잘 아는 문법이다. 학습 데이터가 가장 방대하고, 컴포넌트 패턴이 가장 예측 가능하다. 이것은 단기적으로 React를 기본값으로 유지시키는 또 다른 관성이 될 수 있다. 하지만 뒤집어 보면, AI 도구가 Svelte나 Solid를 동등하게 지원하게 되는 순간—그 속도는 우리 예상보다 빠를 것이다—이 관성은 빠르게 약해질 수 있다.
결국 이 비판들이 가리키는 곳은 하나다. 아키텍처 결정을 관성에 맡기지 말라. React Server Components와 React Compiler가 일부 비판에 응답하고 있는 것은 사실이지만, 릴리스 속도 둔화와 거버넌스 불투명성은 여전히 해소되지 않은 리스크다. 시니어 엔지니어가 "React 리라이트" 제안 앞에서 침묵하지 말아야 한다고 한 것처럼, 우리도 "React 시작" 제안 앞에서 한 번쯤 제대로 된 질문을 던져야 한다. 이 제품에 필요한 인터랙션 복잡도는 어느 수준인가. 팀의 실제 숙련도는 어디에 있는가. 3년 뒤에도 이 코드베이스를 즐겁게 유지보수할 수 있는가. 그 답이 여전히 React라면, 기꺼이 쓰면 된다. 하지만 그 답이 나오기 전에 스택을 먼저 고르는 습관은 이제 바꿀 때가 됐다.