Mark Erikson의 “2025년 리액트 커뮤니티 현황” 읽기

개발#react#rsc#커뮤니티

팀 내 공유용으로 정리한 글입니다. 리액트 커뮤니티에서 어떤 논의가 오가고 있는지 소개하는 것이 목적이라, 원문의 논지를 따라가며 제 정리를 붙였습니다. 인용과 근거는 원문에 그대로 있으니 관심 있으면 직접 읽어보시길 권합니다. 원문: The State of React and the Community in 2025 — Mark Erikson (Redux 메인테이너)

글의 배경과 목적

Mark Erikson이 이 글을 쓴 이유가 흥미롭다. 그는 현재 리액트 커뮤니티가 복잡하고 분열된 상태라고 진단한다. 성공과 회의주의, 논쟁이 뒤섞여 있다는 것이다.

긍정적인 면으로는 리액트가 가장 널리 사용되는 UI 프레임워크이고 React 19가 출시되었다는 점을 언급한다. 하지만 동시에 리액트가 어디로 향하고 있는지, 어떻게 개발되고 있는지, 그리고 리액트 사용 권장 접근법에 대한 불만과 의견 충돌이 커지고 있다고 관찰했다고 한다.

Mark은 자신이 리액트 커뮤니티의 “내부 서클”에 속한다고 설명하면서, Redux 메인테이너로서 2015년부터 리액트 생태계에 깊이 관여해왔다고 밝힌다.

리액트의 역사적 변화

초기 리액트의 철학

Mark은 리액트가 처음에는 최소한의 UI 중심 렌더링 라이브러리로 자신을 소개했다고 설명한다. “MVC의 V”, “사용자 인터페이스를 구축하기 위한 JS 라이브러리”라고 스스로를 설명했다는 것이다.

Angular이나 Ember 같은 다른 프레임워크들은 완전한 배터리가 포함된 상태로 앱을 구축하고 구조화하는 방법에 대해 강한 의견을 가지고 있었지만, 리액트 팀은 그 모든 것을 커뮤니티에 맡겼다고 한다.

생태계의 폭발적 성장

이것이 생태계의 거대한 폭발로 이어졌고, 좋은 면과 나쁜 면이 모두 있었다. 상상할 수 있는 모든 라이브러리 카테고리에 대해 겹치는 문제들을 해결하는 수십 개의 경쟁 도구들이 있었다는 것이다.

상태 관리(Redux, MobX, Zustand), CSS와 스타일링(Styled-Components, Emotion, CSS Modules), 데이터 페칭(React Query, Apollo, SWR, RTK Query), 빌드 도구(Babel, Webpack, ESBuild, Vite, Parcel) 등 수백 개의 도구들이 나타났다고 한다.

Create React App의 등장과 몰락

초기 리액트 튜토리얼들이 “Webpack과 Babel을 설정하는 방법”을 여러 페이지에 걸쳐 설명해야 했던 복잡성 때문에 리액트 팀이 Create React App을 만들었다고 설명한다.

Dan Abramov가 CRA를 중단하는 이유를 설명한 댓글도 인용되어 있다. 요지는 CRA가 문제의 한 면만 해결했다는 것이다. 좋은 개발 경험은 제공했지만, 좋은 사용자 경험을 위해 웹의 강점을 활용하는 데 도움이 될 만한 충분한 구조를 부과하지는 않았다는 것.

React Server Components의 개발 과정

RSC와 Vercel의 관계

Mark은 RSC 개발과 Vercel의 관계에 대해 자세히 설명한다. 2020년 말에 리액트 팀이 “React Server Components”라는 프로토타입을 발표했는데, 이는 서버에서 비동기 리액트 컴포넌트를 실행하고 데이터를 가져온 다음, 자식 컴포넌트들을 렌더링하고 클라이언트에서 실행되는 리액트에 자식들과 데이터를 전달하는 아키텍처 접근법이었다고 한다.

중요한 것은 리액트 팀이 Meta 내부에서 RSC를 효과적으로 설계하고 프로토타입할 수 없었다는 점이다. 이전의 리액트 기능 개발과 달리, Meta는 이미 자체 서버 인프라를 가지고 있어서 거기서 프로토타입을 만들어 앱 팀들이 시도해보게 할 수 없었기 때문이다.

RSC 개발의 실제 과정

Mark이 아는 한, RSC는 미래에 리액트 앱을 작성하는 방법에 대한 리액트 팀의 비전이었고, Meta나 Vercel이 생각해내거나 리액트 팀에게 구축하도록 밀어붙인 것이 아니었다고 설명한다.

그는 리액트 팀이 Vercel에 접근해서 RSC 비전을 제시했고, Vercel이 RSC 개발 과정에서 새로운 실험 환경이 되는 것에 동의했다고 이해하고 있다고 밝힌다.

커뮤니티 우려사항 분석

Vercel과 Next.js에 대한 음모론

커뮤니티에서 가장 흔한 관점 중 하나가 “Vercel이 리액트 개발을 주도하고 있다”는 것이라고 Mark은 언급한다. Vercel이 사실상 리액트를 장악했고, 사용자들을 Next.js와 Vercel 배포로 유도해서 주주들이 더 부자가 되게 하는 것이 주요 관심사라는 식의 Reddit 댓글이 대표적이다.

하지만 Mark은 이런 견해가 일반적으로 인과관계를 뒤바꾸고 있으며 대부분 FUD(Fear, Uncertainty, Doubt)라고 반박한다.

“리액트가 Next.js 없이는 작동하지 않는다”는 오해

이런 댓글들을 온라인에서 여러 번 보았다고 Mark은 언급한다. 하지만 이것은 쉽게 반박될 수 있다고 한다. 리액트 문서의 “새 리액트 프로젝트 시작하기” 페이지를 보면 Next가 아닌 다른 프레임워크들과 “프레임워크 없이 리액트를 사용할 수 있나요?” 섹션이 있다는 것이다.

하지만 동시에 이것이 리액트, “프레임워크 사용”, Vercel의 영향력 주변의 메시징이 얼마나 혼란스러워졌는지를 보여준다고 지적한다.

프레임워크 추천에 대한 리액트 팀의 입장

Andrew Clark의 설명

Mark은 Andrew Clark의 2023년 1월 트윗을 인용해서 리액트 팀의 의도를 명확히 설명한다. 리액트를 사용한다면 리액트 프레임워크를 사용해야 하고, 기존 앱이 프레임워크를 사용하지 않는다면 점진적으로 마이그레이션해야 하며, 새로운 프로젝트라면 처음부터 프레임워크를 쓰라는 것이다.

프레임워크를 쓰지 않기로 선택한다면 실제로는 자신만의 맞춤형 프레임워크를 구축하는 셈이고, 그건 기성품보다 훨씬 나쁠 가능성이 크다는 논리다.

성능과 사용자 경험에 대한 우려

Mark은 리액트 팀과의 대화에서, 리액트 앱의 나쁜 로딩 시간과 전반적으로 좋지 않은 성능에 대한 외부 불만들을 많이 들었다는 이야기를 직접 들었다고 언급한다.

따라서 프레임워크 강조는 이에 대한 직접적인 응답으로, 더 많은 앱이 기본적으로 괜찮은 성능을 갖도록 하는 것이 목표라고 한다.

문서화 문제

RSC 문서 부족

Mark은 React Server Components 관련 공식 문서와 정보가 흩어져 있고 부족하다는 점을 큰 문제로 지적한다. 이것이 RSC를 둘러싼 큰 고통점이자 혼란의 원천이라는 것이다.

리액트 팀이 2020년 12월에 RSC를 발표했지만, RSC 기능이 리액트 자체의 일부임에도 불구하고 리액트 문서에는 RSC에 대한 정보가 없었다는 점이 매우 혼란스러웠다고 한다.

문서의 톤 문제

초기 리액트 문서에서 SPA를 두고 “unusual constraints”라는 표현을 쓴 것에 대해 Mark은 비판적이다. SPA는 처음부터 리액트 커뮤니티의 표준 아키텍처였기 때문이다.

또한 “we can’t stop you”라는 표현도 많은 사람들에게 커뮤니티를 무시하는 것으로 여겨졌고, 리액트 팀이 SPA를 지원하지 않는 접근법으로 격하시키고 있다는 신호로 받아들여졌다고 지적한다.

실제 사용량 데이터

Mark은 NPM 다운로드 통계를 제시한다. 현재 주요 옵션들로는 Next.js, Remix/React-Router v7, Vite, Create React App이 있다고 한다.

몇 가지 주요 발견사항들:

  • Next.js가 가장 널리 사용됨
  • Vite의 React 플러그인이 꾸준히 성장해서 현재 두 번째로 널리 사용되는 리액트 관련 빌드 도구
  • CRA 사용량이 2023년 중반에 정점을 찍고 그 이후 감소하고 있지만 여전히 상당한 사용량을 보임
  • Vite + CRA를 합치면 Next의 사용량과 같아져서, 리액트 생태계에서 여전히 순수 SPA 프로젝트에 대한 강한 수요가 있음을 보여줌

Mark의 최종 평가

Mark은 리액트 팀이 의도적으로 프레임워크를 추천하는 것이 합리적인 의견이고 평균적인 리액트 앱을 개선하려는 유효한 의도라고 인정한다. 하지만 동시에 이런 “추천”이 생태계 전반에서 리액트가 실제로 사용되는 다양한 방식들에 충분한 신뢰를 주지 않는, 지나치게 광범위한 처방이 되었다고 느낀다고 말한다.

프레임워크를 사용할 좋은 이유들이 많지만 사용하지 않을 이유들도 많다고 지적한다. 예를 들어 프레임워크는 기능과 기능성을 추가하지만 학습해야 할 복잡성도 함께 추가하므로, 리액트 자체를 다루는 방법을 익히려는 초보자들에게는 덜 적합하다는 점 등이다.

결론

Mark은 이 글이 리액트가 시간이 지나면서 어떻게 발전했는지, 리액트 개발을 주도하는 힘들, 그리고 왜 그리고 어떻게 리액트의 최근 개발 방향이 일어났는지를 명확히 하고 설명하는 것이 목표였다고 밝힌다. 또한 특정 방향으로 밀어붙이는 리액트 팀의 동기와 이유를 둘러싼 혼란과 FUD 중 일부를 해소할 수 있었기를 바란다고 말한다.

그는 널리 사용되는 라이브러리를 유지하고 커뮤니티의 다양한 요구와 사용 패턴을 만족시키는 것이 정말 어렵다고 인정하면서, 리액트 팀이 전반적으로 좋은 일을 해왔다고 생각한다고 평가한다. 하지만 커뮤니케이션이 좋지 않았던 부분들과 문서 문제들이 커뮤니티의 좌절과 불안에 큰 기여 요인이었다고 지적한다.

앞으로는 그런 커뮤니케이션을 개선할 방법을 찾고, 심지어 더 많은 커뮤니티가 문서 개선에 참여할 수 있기를 희망한다고 마무리한다.