▲

React를 좋아하는 사람이 실제로 있긴 한가요?

 (jsx.lol)
1P by GN⁺ | ★ favorite | 댓글 3개
  • React 및 React 계열 도구에 대한 비판 글을 모아 큐레이션한 자료 모음으로, 다양한 개발자·블로거의 글을 인용 형식으로 정리
  • 성능 저하, 복잡도 증가, 하이드레이션 문제 등 React가 가진 구조적 한계를 지적하는 글이 다수 포함
  • React 중심의 기술 선택은 기술 적합성보다 관성·네트워크 효과로 굳어졌고, “모두가 React를 안다”는 전제가 아키텍처 결정보다 앞선다는 비판을 받음
  • React Server Components와 Next.js를 둘러싼 보안·거버넌스 우려가 커졌고, CVE-2025-55182는 CVSS 10.0 등급의 인증 없는 원격 코드 실행 취약점으로 공개됨
  • React 생태계의 API 설계 혼란과 품질 위기, 복잡성은 장기 유지보수와 학습을 어렵게 만들며, Hooks·현대 UI 기능·릴리스 흐름까지 React의 방향성 논쟁으로 이어짐

사이트 개요

  • "Does anybody actually like React?" 라는 도발적 질문을 내건 큐레이션 사이트
  • React 및 React에 영향을 받은 도구들에 대한 비판 글을 모은 cherry-picked 컬렉션
  • RSS 구독 기능 제공

React 자체에 대한 근본적 비판

보안 및 거버넌스 문제

API 설계 및 학습 곡선 문제

  • Is it Time to Regulate React?

    • React의 핵심 실패는 혼란스러운 API 설계로 가중됨
    • 문서가 우유부단하고, 올바른 사용법에 대한 논쟁이 끝없이 이어짐

  • I don't have time to learn React

    • React가 모던 UI를 가르쳐 준다는 주장과 달리, 실제로는 모던 UI를 거의 다루지 못함
    • autofocus가 깨져 있고, custom elements는 실험적 버전 외에서는 작동하지 않음
    • dialog, popover 등 모던 기능을 쓰려면 useEffect가 필요함
    • synthetic event 시스템 때문에 실제 DOM 동작을 거의 배우지 못함
    • 모던 UI가 아니라 2013년 수준의 UI

  • The React Blog Post: Reflections and Reactions

    • 모든 문제를 "skill issue"로 치부하고 외부 라이브러리로 해결된다고 말하는 태도는 이상함
    • 3년 만에 돌아와도 작업 가능해야 할 기술이지만, 프론트엔드 특히 React는 그렇지 않음

  • React, where are you going?

    • 오늘날 React를 덜 즐기게 만드는 두 가지 문제: ownership과 complexity
    • 신규 개발자들이 React에 위축될 수 있다는 우려

성능 및 사용자 경험 문제

  • Why use React?

    • 기본적으로 악명 높은 하이드레이션 패턴에 갇히게 됨
    • 서버에서 JS로 모든 연산을 하고, HTML을 즉시 보내고, 다시 동일한 JS를 클라이언트에 보내는 구조

  • How React 19 (Almost) Made the Internet Slower

    • 공개적 반발과 격렬한 논쟁 끝에 React 팀이 변경을 보류

  • An even faster Microsoft Edge

    • React에서 모던 Web Components + HTML-first 아키텍처로 전환
    • 특히 저사양 하드웨어 사용자에게 큰 혜택

  • Switching costs

    • 클라이언트 사이드 React가 강요하는 끔찍한 사용자 경험에 대한 불만이 더 많아지길 바람
    • 하지만 실제 불만은 거의 개발자 경험에 집중되어 있음

  • Pivoting From React to Native DOM APIs: A Real World Example

    • 한 개발팀이 React의 "압도적인 VDOM"에서 모던 DOM API로 전환
    • 속도와 인터랙션 개선을 즉시 체감

모바일 및 플랫폼 문제

생태계 및 커뮤니티 문제

React Server Components 비판

기본기 회귀와 대안 강조

마이그레이션 및 전환 사례

전반적 흐름과 향후 전망

Hooks 및 대안 패러다임

  • Why Signals Are Better Than React Hooks

    • React의 Hooks는 올바르게 쓰기도 어렵고 성능 좋게 쓰기는 더 어려움
    • 많은 애플리케이션의 코드 품질과 성능 저하 원인

비유적 비판

  • What Is React.js?

    • 지지자들의 특이함, 과도한 자기 진지함, 끝없는 문서를 기독교에 비유한 영상

함께 보면 좋은 글 β

▲
bichi   [-]

리엑트는 그냥 신앙이에요 (사이비)

답변달기
▲
bichi   [-]

Ant Mill 같은 거죠 //

답변달기
▲
GN⁺   [-]
Hacker News 의견들

  • React에서 마음에 안 드는 점들이 있음. React는 화면에 인터랙티브 HTML을 그리는 프레임워크이지, 대단히 복잡한 프로그래밍을 하라고 있는 게 아님
    첫째, 복잡한 개념과 용어에 너무 기대고 있음. Vue와 비교하면 useEffect는 watch, useMemo는 computed에 해당함
    둘째, 이런 쓸데없이 “똑똑한” 방식이 용어를 넘어 생태계에도 스며들었음. 예전 Redux는 숫자 하나 증가시키는 데도 여러 파일에 많은 코드를 써야 했고, 작성자가 영리한 컴퓨터과학 개념을 좋아했기 때문으로 보였음. 같은 시기 VueX는 그냥 그 숫자를 증가시키면 됐음. 다행히 요즘 React 생태계에는 제정신인 상태 관리자가 많아짐
    셋째, React는 CSS 작업 도구를 기본 제공하지 않음
    넷째, React는 최적화를 알아서 해주지 않음. useEffect와 useMemo를 언제 어떻게 쓰거나 쓰지 말아야 하는지 알아야 하고, React 최적화에 관한 민간전승도 많음. 재렌더링이 핵심 목적인데도 이렇다는 게 문제임. Vue에서는 프레임워크가 자기 도구를 쓰게 만들고 그 안에서 대부분 최적화해 줘서, Vue 앱을 수동 최적화해야겠다고 생각해 본 적이 없음
    다섯째, 그 민간전승 자체가 문제임. React API와 “올바른 React 작성법”이 너무 여러 번 크게 바뀌어서, 지금도 맞는 얘기와 아닌 얘기를 구분하기가 매우 어려움
    결국 React는 아이디어, 컴퓨터과학, 고수준 추상화에 지나치게 집중하고, 실제로 화면에 인터랙티브 HTML을 쉽게 그리게 하는 데는 덜 집중한다고 요약 가능함
    React, Vue, Svelte를 모두 많이 쓰지만 React를 쓸 때는 Vue나 Svelte라면 이미 처리해 줬을 것들을 계속 신경 써야 함. 성능 면에서는 셋이 비슷함
    예전에 관련 글도 썼음: https://www.brachkow.com/notes/what-i-like-in-vue/

  • 지난 약 16년 동안 JavaScript의 주요 흐름을 다 겪어 본 입장에서는, 어떤 의미로는 React를 좋아함
    React는 우리가 시도해 본 다른 모든 것들을 제외하면 최악의 JavaScript 프레임워크임
    Angular 1 시절보다는 언제든 React를 택하겠음. Backbone처럼 매번 처음부터 직접 조립하는 방식보다는 Angular 1의 묵직한 MVC를 택하겠고, 고전적인 JQuery 수프 구조보다는 Backbone의 최소한의 MVC 구조가 나았음. 그 시절 네이티브 API보다는 JQuery의 DOM 조작과 표준 라이브러리 보강을 즉시 택했을 것임
    React에도 트레이드오프는 있지만, 작동하지 않는 수많은 대안을 오래 겪은 끝에 여기까지 온 것임

    • React를 즐겨 쓰고, 앞서 나온 것들보다는 React를 택하겠음. 다만 필요한 게 그 정도라면 htmx/data-star와 서버 렌더링보다 React를 택하진 않겠고, 조금 더 복잡한 페이지 몇 개가 있어도 마찬가지임
    • 그런데 왜 Vue보다 React인지 모르겠음. 가장 큰 답답함은 Vue가 결국 React 방향으로 움직인다는 점이었음. Vue의 원래 컴포넌트 구조, 즉 HTML 템플릿, JavaScript 상태, CSS 스타일이 함께 있는 방식은 정말 좋았음. 컴포넌트 안에서 URL로 데이터를 가져오는 방식도 아주 직관적이었음
    • 동의함. 손으로 작성한 cgi-bin HTML에서 JQuery, Angular v1, React로 넘어왔고, React는 기꺼이 집어 들 도구임. 내가 하려는 일을 해줌
    • Angular보다는 React가 좋고, React보다는 Vue가 좋음
    • Svelte를 써봤는지 궁금함. 왜 누군가 React를 더 좋아할 수 있는지 잘 모르겠음. React의 유일한 장점은 프런트엔드의 IBM 같은 존재라는 점이라고 봄. React를 골랐다고 해고된 사람은 없음

  • 당연히 React를 좋아하는 사람들은 있음. JavaScript처럼 사실상 강제로 써야 하는 것도 아니고, React나 다른 웹 프레임워크를 강요받는 것도 아닌데 React가 이겼음. 적어도 대부분의 다른 프레임워크보다 충분히 좋아한다는 증거로 봐도 됨
    2010년대 후반까지 웹 개발에 대한 흔한 불평은 변화가 너무 빠르고 새로 배울 것이 계속 나온다는 것이었고, 그 불평은 타당했음. 그런데 React 단일 문화가 꼭대기에 올라오자 이제는 그게 싫다고 다들 불평함. 정말 이길 수가 없음

    • 직장에서는 프레임워크와 라이브러리를 고를 수 있었던 적이 거의 없음. 거의 항상 누군가 몇 년 전에 시작한 작업을 이어받거나, 엄격한 선택지가 있는 조직에 묶여 있었음. 개인적으로는 React를 고르지 않을 것임
      React가 이긴 건 기본 선택지가 되었고 사람들이 자기 취향에 익숙한 것을 좋아하기 때문임
    • React에는 장점이 있지만, 그 일이 위한 최선의 도구인지보다 관성 때문에 선택되는 경향도 있음. “모두 React를 쓰니 채용 풀과 외주 풀을 최대화할 수 있다”, “React 프로젝트는 이력서에 좋아 보인다” 같은 이유가 작동함
    • 오히려 React와 Next.js를 강제로 쓰게 됨. 많은 SaaS 공급사가 Vercel과 제휴하고, 확장 지점을 그쪽으로만 열어두기 때문임
      다른 것을 쓰고 싶으면 통합을 직접 구현하거나, 이미 해둔 오픈소스 프로젝트를 찾거나, AI에게 물어봐야 함
      취미 프로젝트에서는 가능하지만, 업무 환경에서는 상상하기 어려움
    • 아무도 React를 강제로 쓰지 않는다는 게 무슨 뜻인지 모르겠음. Lisp를 배워서 원하는 모든 것에 쓰고, 기업 문화가 기술 선택에 아무 영향도 미치지 않는 그런 멋진 신세계가 어디 있는지 궁금함

  • React를 좋아함. HTMX/Hotwire 진영도 진지하게 써봤음
    받은편지함에서 온 경우에는 브라우저 API로 뒤로 가기를 하고, 아니면 스크롤을 보존하기 위해 받은편지함 링크로 보내는 뒤로가기 버튼을 만들고 싶었음. HTML에서 동작을 연결해 뒤로 가는 함수를 호출하고, 컨트롤러에서 이전 페이지를 판단한 뒤 JavaScript가 켜진 뒤로가기 버튼이나 하드 링크를 내려줘야 했음. 로직이 3개 파일에 흩어졌음
    React에서는 컴포넌트 안의 JavaScript가 이전 페이지가 받은편지함인지 판단하고, 그 값에 따라 뒤로가기 버튼 JSX나 링크를 보여줄 수 있음. 전부 한 파일 안에서 끝남. 나에게는 하나의 개념적 엔터티를 모델링하면 되지만, 다른 방식에서는 3개 엔터티에 기능을 억지로 끼워 넣어야 했음
    더 느리냐고 하면 확실히 느림. 그래도 행복하게 해줌. 회사의 지저분한 React 코드베이스에서 괴롭다면 동료들을 탓해야 함. React가 없었다면 분명 더 나빴을 것임

    • 그래서 React 단일 페이지 앱을 싫어함. 항상 브라우저의 뒤로가기 버튼과 탐색 버튼을 깨뜨리는 멍청한 방법을 찾는 것 같음
      가끔 폼 향상 정도를 제외하면, 항상 htmx/서버 렌더링과 네이티브 동작을 선호하겠음
    • HTMX는 데이터 상태와 관련된 작업에만 쓰는 게 좋다고 봄. 지능형 뒤로가기 버튼처럼 리소스 상태에 의존하지 않는 것은 백엔드에서 계산하지 않는 편이 나음
      권장되는 htmx 방식이라면 onclick 버튼을 인라인 JavaScript에 연결하거나, 그게 싫다면 goBackOrInbox 같은 함수를 호출하면 됨
      function goBackOrInbox() { if (document.referrer) { const path = new URL(document.referrer).pathname; if (path.startsWith('/inbox')) { history.back(); return; } } window.location.href = '/inbox'; }
      이런 패턴을 많이 쓴다면, 이동해야 할 경로를 인자로 받아 매개변수화하면 됨
    • 뒤로가기 버튼 문제를 푸는 최선의 방법은 너무 복잡하게 만들지 말고, 정말 돌아가고 싶은 것만 브라우저 기록에 들어가게 보장하는 것 아닌가 싶음. 문제 설정 자체가 “구조를 더 잘 잡으면 풀 필요가 없는 문제가 된다”고 외치는 듯함
    • 여기저기 복잡한 부분은 있겠지만, Web Components로도 할 수 있지 않나 싶음

  • React 코드를 오래 쓰다가 지금은 회사에서 큰 Vue 프로젝트를 하고 있음. 예전에는 모두 Vue가 둘 중 더 쉽고 접근하기 좋은 선택지라고 했지만, 이제는 다르게 보이기 시작함
    React는 우아하게도 컴포넌트가 본질적으로 함수일 뿐이고, 그 밖에는 많지 않음. Next.js 생태계는 일단 제쳐두면, 프런트엔드 개발에서 본 것 중 가장 우아함
    반면 Vue는 뒤섞인 느낌임. JavaScript를 제대로 배우고 싶지 않았던 백엔드 개발자들이 받아들이고 칭송한 흔적이 보이고, 그 결과물은 깔끔하게 맞물리지 않는 어색한 혼합물처럼 느껴짐

    • 이런 견해가 늘 이해되지 않음. React 컴포넌트는 그냥 함수가 아니라, 훅을 통해 접근하는 마법처럼 주입된 컨텍스트가 붙은 함수임. 이 훅은 온갖 보장을 요구하고, 이를 의식하지 않으면 디버깅하기 어려운 결과가 생김. 우아함과는 거리가 멀다고 봄
      주요 프레임워크를 모두 써봤고 지금은 큰 Angular 웹 앱을 만들고 있음. Angular에서 컴포넌트는 클래스와 템플릿, 스타일로 표현됨. 이벤트 리스너는 대체로 클래스의 메서드를 호출하고, 상태는 클래스의 속성처럼 단순할 수 있음. 훨씬 자연스럽고 함정도 훨씬 적음. 물론 0개는 아님
    • Vue를 얼마나 오래 썼는지 궁금함. 나도 몇 년 전 React 배경에서 Vue를 보며 비슷한 생각을 했음. 하지만 지금은 React보다 Vue를 선호하고, 개인 프로젝트와 업무 프로젝트 모두에서 Vue를 먼저 고름
      사용감은 조금 다름. React에서 더 쉬운 일도 있고 Vue에서 더 쉬운 일도 있지만, Vue가 시그널을 쓴다는 점은 나에게 큰 장점임

  • React 자체보다, 일반적으로 코드로 UI를 가장 잘 작성하는 방법이라는 질문에 더 관심이 있음
    React 팬이고 만드는 거의 모든 웹 애플리케이션에 React를 쓰지만, 가장 크고 명확한 문제는 React로 UI를 작성하는 일이 Go로 명령줄 도구를 쓰거나 Elixir로 실시간 앱을 쓰는 것만큼 자연스럽게 느껴지지 않는다는 점임
    어떤 언어는 특정 작업에 대해 놀랄 만큼 자연스럽고 마찰이 없음. 하지만 UI는 아직 아무도 제대로 정복하지 못했음. Swift, JSX/HTML, Svelte, 그 주의 인기 프레임워크가 무엇이든 모두 어느 정도 문제를 우회하는 느낌임. 언어/프레임워크 설계자가 어느 순간 요구사항을 만족시키려고 지저분하거나 이상하거나 고통스러운 문법을 타협해 넣은 듯함
    UI의 자연스러운 인터페이스는 시각적이므로 Figma 같은 도구가 해법의 중요한 일부가 될 수 있음. 그래도 뭔가 빠져 있다는 느낌이 듦. 시각적인 것을 코드로 표현하는 더 직관적인 방법이 있을 것임. 현재 해법들은 정확히 설명하기 어렵지만, 언제나 어딘가 아슬아슬하게 부족함

    • 비슷하게 느낌. React가 나왔을 때는 당시 대안들과 비교해 완벽하게 느껴져서 정말 좋아했음
      지금도 Svelte, Vue, Solid를 포함해 거의 모든 것보다 React를 선호함. 하지만 최근에는 Crank(https://crank.js.org/)를 쓰기 시작했고, 내가 가고 싶은 방향에 한 걸음 더 가까워 보임. 다만 지금까지는 장난감 프로젝트에만 써봤기 때문에 성능과 개발자 경험 양쪽에서 얼마나 잘 확장될지는 말하기 어려움
    • “어떤 언어는 특정 작업에 대해 놀랄 만큼 자연스럽고 마찰이 없지만, UI는 아직 아무도 제대로 정복하지 못했다”는 데 강하게 동의함. 90년대 초반에 이 문제를 다룬 책들[1]을 보면 지금도 그대로 적용됨
      지금까지 본 가장 좋은 분석은 Chatty의 “Programs = Data + Algorithms + Architecture: consequences for interactive software engineering”[2]에 있음. 읽기 좀 어렵지만 충분히 가치 있음
      짧게 요약하면 문제는 아키텍처, 더 구체적으로는 언어와 아키텍처의 불일치임. “범용” 프로그래밍 언어가 유도하는 호출/반환 아키텍처 스타일은 사용자 인터페이스에 필요한 아키텍처와 맞지 않고, 오히려 충돌함
      이 주제로 “Can Programmers Escape the Gentle Tyranny of call/return?”에도 썼음
      현재 접근은 대체 아키텍처 스타일을 쉽게 표현할 수 있는 프로그래밍 언어인 Objective-Smalltalk[4]를 먼저 만드는 것임
      그걸로 지금 interscript라는 UI 프레임워크를 만들고 있고, HTMXNative와 여러 부가 요소도 포함됨
      꽤 잘 풀리는 것 같음
      [1] 예: Myers 등의 “Languages for developing user interfaces” https://api.taylorfrancis.com/content/books/mono/download?id...
      [2] https://opendl.ifip-tc6.org/db/conf/ehci/ehci2007/Chatty07.p...
      [3] https://2020.programming-conference.org/details/salon-2020-p...
      [4] https://objective.st
    • 엔지니어로서는 모든 문제를 보며 “완벽한 해법이 있는데 아직 못 찾았을 뿐”이라고 생각하기 쉬움
      하지만 시간이 지나면서 덜 이상주의적인 답을 받아들이게 됨. 어쩌면 그런 해법은 없을 수 있음. 문제 공간이 너무 복잡해서 모든 형태를 아우르는 인간적으로 가능한 일반 해법이 존재하지 않을 수도 있음. 그게 참인 분야가 하나 있다면 아마 UI일 것임

  • 맞음. React는 선언형과 명령형 스타일을 성공적으로 결합한, 단연 가장 직관적인 인터페이스임. 모든 언어의 UI 프레임워크를 통틀어 JSX에 가까운 것은 없다고 봄

    • Flutter, SwiftUI, Jetpack Compose 등 많은 다른 플랫폼이 React를 자기들의 UI 프레임워크처럼 구현해 왔음
    • 그렇게 직관적이라면 왜 거의 모든 React 앱에 성능 버그가 들어 있는지 모르겠음

  • Svelte를 정말 좋아하고, 더 복잡한 앱에는 SvelteKit을 쓰고 있음
    예전 같으면 React를 썼을 많은 경우에서 훨씬 나은 개선이라고 느꼈음
    Svelte는 웹 개발, HTML, CSS, JavaScript의 기본을 아는 사람에게 훨씬 배우기 쉬워 보임. 그런데 요즘은 웹 개발을 React로 시작하는 사람을 자주 보는데, 순서가 좀 거꾸로인 느낌임
    개인적으로는 SvelteKit + Capacitor로 모바일 앱을 만들고 있고, 설정은 여기에 썼음: https://bryanhogan.com/blog/web-to-app-sveltekit-capacitor
    단순 랜딩 페이지에는 Astro를 선호함

    • 나도 항상 Svelte + SvelteKit을 먼저 집어 듦. 단순 앱에 Kit을 쓰는 건 과할 수 있지만, 예상치 못하게 복잡해질 때 갖고 있으면 좋음
      요즘 사람들이 React로 웹 개발을 시작하는 건 거꾸로인 느낌이라는 데 동의함. Svelte는 HTML을 모어처럼 다뤄서 이 문제를 잘 막아줌. Svelte(Kit)로 웹 개발을 시작하면 React로 시작할 때보다 기초를 더 많이 배우게 될 가능성이 큼
    • 내게는 Svelte + Astro 조합이 맞음. 문서 사이트와 선택적으로 상호작용이 들어가는 페이지에 아주 좋음

  • 내가 React가 가능해지도록 만든 사람들 중 일부였기 때문에 편향은 있지만, React를 정말 좋아함. 그전에는 프런트엔드에서 겪던 문제를 고치려고 온갖 것을 다 시도했음. 하지만 React가 나온 뒤로는 그런 필요가 없어졌고, 그냥 만드는 데 집중할 수 있게 됨

  • 정말 좋게 본 발표 중 하나가 https://www.youtube.com/watch?v=h9SDuTSy7ps임. 내 경험상 React의 아키텍처는 정말 좋고, 큰 애플리케이션을 만들기에 꽤 잘 맞음
    안타깝게도 React의 가장 큰 문제는 JS/TS 생태계로 들어가게 강제한다는 점임. 내게 JavaScript/TypeScript는 의심의 여지 없이 직접 다루고 싶은 시스템이라기보다 컴파일 대상에 가까움
    Elm에는 만족함. 커뮤니티가 정말 작고, 때로는 라이브러리를 직접 만들어야 함. TEA는 React에서 온 입장에서는 가끔 부자연스럽지만, useEffect 같은 암묵적이고 예기치 않은 상태를 걱정하지 않아도 된다는 점 때문에 Elm으로 일할 때는 늘 신남
    게다가 Claude는 적어도 크고 무서운 코드베이스 안에서는 React보다 Elm에서 더 잘 버티는 것 같음

    • 내 경험상 Elm은 사실상 죽었음. 계속 작동하는 라이브러리가 있는 React와 TypeScript를 쓰는 편이 낫겠음. TypeScript를 네이티브로 컴파일 가능하게 만들려는 시도들도 있었음
    • TEA는 좋아하지만, 재사용 컴포넌트나 충분히 복잡한 페이지가 있는 앱에서 어떻게 확장되는지 완전히 이해하진 못했음. 이를 다루는 합의된 방식이 있는지 궁금함
      상태는 큰 금기처럼 보이니 약간 충돌하는 것 같기도 함. 결국 모든 Elm 앱은 효과 없는 전역 Redux + React 앱이 된다는 뜻인지도 궁금함. Elm에서 무엇이 즐겁고 어떤 식으로 작업하는지 더 자세히 알고 싶음. 링크도 좋음
답변달기