▲

2025년 React와 커뮤니티의 현주소

 (blog.isquaredsoftware.com)
18P by neo 14시간전 | ★ favorite | 댓글 10개
  • React는 여전히 가장 널리 쓰이는 UI 프레임워크지만, 최근 수년간 커뮤니티 내 혼란과 논쟁, 불신이 증가했으며, 공식 팀과 외부 개발자 간 커뮤니케이션 부재와 잘못된 마케팅이 혼합되어 우려가 증폭됨
  • React 19가 정식 출시되어 Server Components, 새로운 use 훅, 폼 통합 등 대규모 기능이 추가됐으나, "프레임워크만 권장" 정책과 Next.js 중심 구조가 많은 사용자의 불만을 낳음
  • "React는 이제 Next.js에서만 제대로 쓸 수 있다" "곧 클라이언트 전용 지원이 중단된다" 등 오해와 FUD가 퍼졌지만, 실제로는 클라이언트 렌더링 기능이 없어질 일은 절대 없고, RSC·서버 기능도 어디까지나 선택사항임
  • React 팀의 프레임워크 중심 정책은 성능/구조 표준화와 사용자 경험 개선 목적이지만, SPA와 다양한 아키텍처에 대한 존중 부족과 비공식적/불친절한 문서가 커뮤니티 혼란을 키움
  • 최근에야 Vite·Parcel 기반 SPA 등 다양한 방법이 공식 문서에 포함되었으나, 서버 컴포넌트(RSC)에 대한 공식 설명 부족과 소통 미흡이 여전히 남아 있음

서론 및 목적

  • 2025년 기준 React 커뮤니티는 성공·불신·논쟁이 뒤섞인 복잡한 국면
  • 이 글의 목표는 React의 발전 과정, 개발 방향, 주요 결정 배경을 정리하고 FUD와 혼란을 해소하는 것

필자 배경 및 커뮤니티 참여 이력

  • React 팀 멤버는 아니지만, 2015년부터 React 에코시스템에 깊이 관여
  • Redux 패밀리 라이브러리(특히 Redux Toolkit) 유지보수자 및 주요 커뮤니티 활동가
  • 수많은 React/Redux 튜토리얼과 블로그, 강연, 팟캐스트에 참여
  • Reactiflux Discord, /r/reactjs subreddit 등 주요 커뮤니티에서 운영진 및 중재자 역할
  • React 팀과의 협업 경험(예: useSyncExternalStore 훅 알파 테스터), 다양한 내부 피드백 그룹 참여
  • React DevTools, sourcemaps, Replay DevTools 등 다양한 기술적 기여

  • 편향 및 한계 고지

    • 본인은 항상 옳지 않을 수 있으며, 정보의 한계·오해·요약 과정에서 일부 부정확한 설명이 있을 수 있음을 인정
    • Redux를 유지보수하며, React 사용 경험 역시 주로 내부 도구 및 SPA 형태에 치우침
    • SSR, RSC, 대규모 트래픽, i18n 등 실무 경험은 제한적임
    • 커뮤니티 깊숙이 논의된 주제는 익숙하지만, 일반적인 앱 개발자의 일상과는 일부 괴리 있음
    • React 팀과의 긍정적·부정적 개인적 경험 모두가 관점에 영향을 줌
    • 역사적/구조적 배경 설명에서 최대한 성실하게 사실을 전달하려고 노력함

React의 간략한 역사

  • 2011~2012년 Facebook(현 Meta) 내부 개발, 2013년 오픈소스화
  • 최근까지 모든 핵심 개발은 Facebook/Meta의 React 팀이 주도
  • 핵심 개념(컴포넌트, props, state, data flow)은 유지, 구현·API·적용 범위는 지속적으로 확장·변화
    • createClass → ES6 class → 함수형 컴포넌트(Hooks 지원)
    • React Native로 모바일, react-reconciler로 WebGL(react-three-fiber), CLI(ink) 등 다양한 플랫폼 확장
    • 내부적으로 "Fiber" 아키텍처로 전면 리팩토링(성능/구조 혁신)
    • 2018년 Hooks 도입으로 함수형 컴포넌트에 상태/효과 부여
  • “최소 UI 라이브러리(V in MVC)” 전략으로, 아키텍처·상위 프레임워크·빌드·상태관리 등은 커뮤니티에 위임
    • 이로 인해 Redux/Mobx/Zustand(상태), Styled-Components/Emotion/CSS Modules(스타일), React Query/Apollo/SWR(RTK Query)(데이터), Webpack/Vite/Parcel 등 수많은 서드파티 라이브러리 및 빌드 도구 등장
  • 유연성이 장점이지만, 프로젝트별로 필요한 라이브러리 선택이 필수 → 코드베이스 다양성, 피로도, 표준 부재 문제 동반

  • 빌드 도구와 CRA

    • 초기에는 Webpack/Babel 등 복잡한 설정이 필수였음
    • Create React App(CRA): Webpack+Babel 기반 CLI, 복잡성 은닉, 단일 커맨드로 프로젝트 생성 가능(블랙박스 방식)
    • 데이터 패칭·상태 관리는 별도 3rd-party 도구에 의존
    • SSR(서버 사이드 렌더링) 기능은 초기부터 존재했으나, 수동 구현 필요
    • 이후 Next.js(SSR/파일 시스템 기반 라우팅, 데이터 패칭), Gatsby(정적 사이트, GraphQL), Remix(서버 데이터 로더) 등 프레임워크 등장

  • React Server Components(RSC)와 프레임워크 전환

    • 2020년 말 React Server Components(RSC) 프로토타입 공개, 비동기 컴포넌트·서버 데이터 패칭을 React로 표준화하려는 아키텍처적 변화
    • 개발 과정에서 일부 React팀이 Vercel로 이직, Next.js와 협업해 App Router 및 RSC 최초 구현
    • 2020~2023년 React 공식 문서(react.dev) 전면 개편, 대화형 튜토리얼 및 API 참조 강화

  • 공식 권장 사용법 변화

    • 과거 공식 문서에서는 CRA 기반 SPA 시작을 추천하고, SSR/정적 사이트 필요시 Next/Gatsby 등 대안을 안내
    • 새 문서(react.dev)에서는 프레임워크 사용을 강력 권장(라우팅, 데이터 패칭, 빌드 통합), RSC 구현체로 Next.js만 언급
    • CRA는 2022년경부터 사실상 관리 중단(공식적으로 deprecated는 아니었으나, 커뮤니티에서 점차 대체)
    • 공식 문서와 커뮤니티 내에서도 “Next.js가 진짜 React 18”이라는 의견 등 Next.js와의 강한 연계가 부각

React와 소유 기업(스폰서)의 관계

  • Meta(Facebook)

    • React는 처음부터 Facebook/Meta가 소유·주도한 프로젝트
    • 오픈소스이지만 실질적 개발은 Meta React 팀이 담당, 핵심 회의·로드맵도 모두 내부 중심
    • 새로운 기능은 Meta 내부 여러 앱팀에서 실제로 검증·테스트 후 외부 공개
    • React 팀은 개발 자유도가 높았으며, 로드맵과 비전 수립을 주도적으로 수행
    • 성과와 프로젝트가 Meta 비즈니스에 어떻게 기여하는지는 내부적으로 검증 필요
    • Meta는 자체 서버 인프라와 GraphQL, Relay 등 자체 기술을 적극 활용, 라우팅·상태관리 등에서 커뮤니티와 다른 방식으로 React 사용
    • 따라서 Meta 내부에선 외부 3rd-party 라이브러리 활용 빈도가 낮음

  • Vercel, Next.js, React

    • Vercel은 웹앱 호스팅 플랫폼이자 Next.js 프레임워크의 개발사
    • 비즈니스 모델은 Next 등 프레임워크 확산 → Vercel 플랫폼 호스팅 유도
    • CEO(Guillermo Rauch)는 초기부터 React 렌더링 철학에 깊은 신뢰와 투자
    • 2021년, React 팀 리더 Sebastian Markbage가 Meta에서 Vercel로 이직, Andrew Clark·Tom Occhino 등 주요 인력 합류
    • Vercel 이적 멤버들은 React Server Components(RSC)·Next.js App Router 등 핵심 기능을 React와 Next.js 양쪽에서 구현
    • Vercel 소속 엔지니어들도 React 코어 및 서버 렌더링 기능에 실질적 기여
    • 2025년 현재, React 팀은 Meta와 Vercel에 나뉘어 활동(주력은 Meta, 주요 코어 구현은 Vercel도 관여), 외부 기여자도 일부 있음

React 사용 패턴

  • 표준 아키텍처

    • React 자체는 SPA, SSR, SSG, 하이브리드 등 다양한 방식 모두 지원
      • SPA: 빈 HTML에 React 트리 전체를 클라이언트에서 렌더링
      • SSR: 서버에서 요청마다 동적 HTML 생성
      • SSG: 빌드 타임에 정적 HTML 미리 생성
      • 여러 언어나 프레임워크(Python/Django, Ruby/Rails, PHP/WordPress 등)와 조합 가능
    • 2015년경부터 SPA(클라이언트 렌더링) 방식이 표준이었으나, 초기 로딩 속도·JS 번들 크기·네이티브 브라우저 동작 차이 등 트레이드오프 존재
    • 데이터 패칭은 원래 Redux 등에서 직접 로직 구현, 이후 React Query/Apollo/SWR/RTK Query 등 전용 훅/라이브러리 등장으로 단순화
    • Next.js, Remix 등 프레임워크는 SSR, SSG, 파일 시스템 라우팅 표준화와 데이터 패칭 구조화로 React의 활용 폭을 넓힘
    • SSR 기반 아키텍처(서버 렌더링, 프리패치, 코드 스플리팅 등)로 이동하는 트렌드
    • React팀은 "데이터 패칭 waterfall" 현상을 지양하며, 라우트 단위 사전 패칭 등 성능 개선 패턴을 권장

  • 빌드 도구 및 프레임워크 사용 현황

    • 주요 도구/프레임워크:
      • Next.js(SSR/SSG/RSC/SPA)
      • Remix / React-Router v7(SSR/SSG/SPA)
      • Vite(SPA, 빌드 도구, 다양한 프레임워크 플러그인 지원)
      • Create React App(SPA)
    • Vite는 Vue 생태계에서 출발했으나, React, Svelte 등 다수 지원 → React 공식 플러그인, 프레임워크 빌드툴 표준
    • Remix/React-Router도 최근 Vite 기반 SSR/SSG 지원 구조로 이동
    • 다운로드 통계 요약:
      • Next.js 사용률 압도적 1위
      • Vite의 React 플러그인 급성장, 두 번째로 많이 쓰임
      • CRA(react-scripts) 2023년 이후 하락세지만 여전히 상당한 사용량
      • Remix는 입소문은 강하지만 전체 규모는 제한적, React Router는 framework mode로의 전환 속도가 느림
      • Gatsby는 Next/Vite/CRA보다 한참 적고, 최근 Astro(다중 프레임워크 정적 사이트)에도 역전당함
      • Astro는 React에 특화되진 않지만 Remix와 비슷한 규모
      • Vite+CRA 사용량 합치면 Next와 대등 → SPA 방식 수요도 여전히 높음

React Server Components(RSC) 내부 및 프레임워크와의 관계

  • RSC 개발 배경 및 Vercel 협력

    • Meta 내부 인프라는 이미 자체 서버 구조가 구축되어 있어 RSC(React Server Components) 개발·테스트에 한계
    • RSC는 React 팀이 직접 주도한 미래 지향적 설계, Meta·Vercel의 지시나 요구가 아닌 React팀의 독립적 비전에서 출발
    • React팀이 Vercel에 RSC 비전을 제안, Vercel이 개발의 실험장·지원자로 합류
    • Sebastian Markbage, Andrew Clark 등 React 코어 멤버가 Meta→Vercel로 이동, Next.js 팀이 App Router(최초의 실제 RSC 적용 사례)를 구축
    • 이 과정에서 Next.js는 거의 처음부터 다시 설계·구현
    • Shopify(Hydrogen), Remix 등 다른 프레임워크도 초기 테스트·협력 시도는 있었으나 본격 참여는 미비
    • 결과적으로 Next.js App Router만이 실제 “프로덕션급” RSC 구현체로 자리, 다른 프레임워크(React Router, Parcel, Waku 등)는 현재 통합 작업 중이나 대중적 사용은 Next가 독점

  • RSC와 프레임워크/번들러의 통합 구조

    • "RSC는 왜 프레임워크나 번들러가 꼭 필요하냐?"는 질문이 많음
    • 기존 SSR(renderToString, renderToPipeableStream)은 어디서든 실행 가능했지만, RSC는 구조적으로 훨씬 복잡
      • 코드 내 'use client', 'use server' 디렉티브 해석
      • 클라이언트/서버 컴포넌트 분리 및 등록 자동화 필요
      • 모듈 그래프 전체를 분석·컴파일하는 번들러(예: Webpack, Vite 등)와 긴밀한 통합이 필수
    • React 코어는 RSC의 핵심 로직과 데이터 직렬화 API만 제공, 실제 동작과 라우팅, 엔드포인트 호출 등은 프레임워크가 책임
    • 각 프레임워크마다 RSC 활용·아키텍처·구현 방식이 상이
      • Next.js App Router는 레이아웃·라우팅 등 자체 규칙 적용
      • Parcel, Waku, React Router 등은 각기 다른 설계 도입 중
    • 정리:
      • RSC는 React 코어에 내장된 하이브리드 기능이지만, 실제 사용은 반드시 번들러/프레임워크의 통합이 필요
      • 프레임워크가 지원해야만 RSC의 강점을 실제로 활용 가능

커뮤니티의 우려와 혼란

  • 1. "Vercel이 React를 장악했다"는 우려

    • Vercel이 주요 React 팀원을 고용하고, Next.js가 문서·예제에서 강조되어 “Vercel이 React 개발을 주도한다”는 의혹 확산
    • 실제로는 React 팀이 RSC 비전 및 Next App Router 구조를 주도했고, Vercel은 지원자·실험장 역할
    • Vercel이 React를 "장악"했다기보단, React 코어팀 일부가 Vercel로 이직하여 비전을 실현한 구조

  • 2. "React는 이제 Next에서만 동작한다"는 오해

    • Next.js만이 유일한 RSC 프로덕션 구현체로 강조되다 보니 이런 오해가 생김
    • React 공식 문서에는 Next 이외에도 다양한 프레임워크 및 프레임워크 없는 사용법도 언급
    • Next는 React 기반 프레임워크일 뿐, React 단독·다른 도구와도 여전히 사용 가능

  • 3. "클라이언트 앱에서 React가 사라질 수 있다"는 불안

    • 서버 기능(RSC, SSR 등) 강조로 SPA 클라이언트 지원 중단을 걱정하는 목소리 존재
    • React의 클라이언트 렌더링 기능은 결코 사라지지 않음
      • Meta 등 대형 코드베이스도 클라이언트 방식 대량 활용
      • React팀은 호환성·마이그레이션 지원에 철저

  • 4. "왜 React는 프레임워크 사용을 강요하는가?"

    • React팀은 데이터 패칭·라우팅·SSR 통합 등 프레임워크의 생산성·성능 장점을 이유로 기본 권장
    • "직접 설정(맞춤 SPA)은 장기적으로 비효율적, 프레임워크가 업계 표준"이라는 입장
    • 실제론 다양한 사용 패턴이 있는데, 지나치게 일괄적인 권장이 됨
      • 초보자 진입장벽, 서버 호스팅 제한 기업, SPA 호스팅의 단순성 등 현실적인 이유로 SPA도 여전히 유효
    • 공식 문서의 "비프레임워크 방식" 안내가 부차적으로 취급되어 커뮤니티에 소외감 제공

  • 5. 공식 문서의 한계 및 개선 논란

    • CRA(react-scripts) 공식적으로 deprecated, 대체 도구(Vite 등) 언급이 늦어져 혼란 가중
    • SPA 등 "비프레임워크" 방식도 공식적으로 인정·가이드 추가(2025년 최신 문서)
    • Vite 등 주요 빌드 도구에 대한 공식 언급이 늦은 점에 대해 커뮤니티, 생태계 인물(Evan You 등)도 문제 제기
    • 개선된 최신 문서에서는 SPA, Vite/Parcel/RSPack 등도 추천, 라우터·데이터 패칭 선택 가이드 제공

  • 6. RSC 공식 문서 및 설명 부족

    • Next.js, Vercel 등 외부 자료에 비해 React 공식 문서 내 RSC 설명·개념 안내 부족
    • API Reference에만 단편적 정보, 전반적 개념/적용 가이드 미흡
    • 커뮤니티와 주요 인물들(Dan Abramov 등)이 적극적으로 보충 설명을 제공하고 있으나, 공식화 부족이 지속적 혼란 초래
    • RSC의 컨셉, 아키텍처, 도입 사례, FAQ 등 문서 섹션 추가 필요성 제기

주요 우려 사항에 대한 정리

  • 프레임워크·서버 기능 강조가 “Vercel의 이익 때문”이라는 오해가 커뮤니티에 뿌리내렸으나, 실제로는 사실과 다름
    • React팀의 커뮤니케이션, 공식 문서의 표현 등이 오해를 키운 측면이 있음
  • React의 클라이언트 렌더링 기능은 앞으로도 계속 유지, 서버 기능(RSC/SSR 등)은 옵션일 뿐, SPA 등 기존 방식 계속 사용 가능
  • 커뮤니티의 우려와 혼란은 React팀의 소통 부족, 개발자 관계(DevRel) 활동 미흡도 한 요인
    • 공식 입장 표명, 오해 해소, 다양한 패턴에 대한 인정과 안내가 필요
  • “프레임워크 사용” 권장은 선의에서 출발했으나, 실제로는 너무 획일적으로 느껴지고, 다양한 사용 패턴을 소외시켰다는 비판 존재
  • 2025년 이후 공식 문서가 개선되어 SPA/맞춤 빌드 방식도 인정·가이드가 추가됐지만, 커뮤니티 피드백을 반영하는 데 오랜 시간이 소요
  • RSC(React Server Components) 개념, 트레이드오프 등 핵심 내용의 공식 문서 보강 필요
    • 커뮤니티의 올바른 이해와 불필요한 논란 방지에 도움

맺음말

  • 본문은 React가 어떻게 발전해왔는지, 어떤 영향과 목표 하에 개발되고 있는지, 그리고 현재 생태계에서 사용 패턴이 어떻게 자리잡았는지에 대한 다양한 질문에 대한 답변을 제공
  • React 팀의 방향성과 변화에 대해 발생한 혼란이나 FUD(공포·불확실성·의심)를 해소하고자 했음
    • 기술적 방향에 동의하지 않거나 RSC/대형 프레임워크를 굳이 쓸 필요성을 못 느껴도, React 팀의 의도와 방향성은 충분히 타당
  • React팀의 정책은 성능 표준화와 커뮤니티의 UX 개선이라는 선의에서 비롯되었으나, 불친절한 소통과 문서로 불필요한 혼란을 키움
  • SPA, 프레임워크, 다양한 빌드 도구 등 실제 사용 패턴의 다양성에 대한 존중과 공식 문서의 개선 필요성이 커짐
  • 앞으로는 커뮤니티 피드백 반영과 다양한 아키텍처를 포용하는 문서 개선, 오픈 커뮤니케이션이 React의 건강한 발전에 핵심
▲
click 14시간전  [-]

RSC를 시작부터 Next.js 기반으로 개발했다는 사실 자체는 다르지 않은 듯 하네요.
Next.js가 점점 더 Vercel 이외의 환경에서는 삐걱대는 것까지 조합하면
React 팀 내부 생각이 어떤진 몰라도 RSC가 미래에요! 근데 RSC를 구동하기 위해서는 Next.js를 추천하고 Next.js는 Vercel에서 쓰세요 라는 논리 흐름이 되는데 이게 Vercel의 이익과 관련이 없냐고 하면 흠...
아무리 오해라고 주장해도 결국 사람들은 Vercel이 React를 잠식했다 라고 느낄 수밖에 없고 오해를 풀기 위해서 빠르게 대응한 것도 아니지 않나요?

답변달기
▲
spp00 23분전  [-]

당장 리액트 공홈이 메타 쪽 서버가 아니라 Vercel 위에서 돌아가죠.

답변달기
▲
click 11시간전  [-]

똑같이 Vercel이 투자하는 svelte는 규모가 작아서 그런진 몰라도 이렇게 벤더 락인이 걸리는 경우가 없다고 느꼈는데 차이점도 궁금하네요.

답변달기
▲
spp00 25분전  [-]

스벨트는 버셀이 후원만 하는거지 버셀이 리드하는게 아닙니다. 반면 넥스트는 버셀이 아예 리드하는거고요.

깃허브 저장소 같은 경우에도 넥스트는 버셀 조직 산하지만 스벨트는 그렇지 않아요.

그리고 넥스트.js는 공홈 푸터의 카피라이트 표기에 버셀이 있지만 스벨트는 없습니다.

답변달기
▲
preserde 5시간전  [-]

사실 여기 웹 프론트엔드 개발 이슈는 꽤 적게 올라오는데... 그럼에도 최근에 nextjs가 언급이 너무 많이 되는게 심상치 않게 느껴집니다.
Server component만 문제지 다른건 괜찮아~ 라는 느낌이네요.

답변달기
▲
passerby 12시간전  [-]

프레임워크가 편하다라는것과 React 자체에서 CRA 를 포기하는건 아예 차원이 다른 문제인듯요. 바뀐 리액트 문서에서 다짜고짜 next 깔라고 하길래 좀 위화감을 느꼈는데 저만 느낀게 아니었네요.

답변달기
▲
dohyun682 14시간전  [-]

Vercel과 리액트 개발팀이 별개인 줄 알았는데 실제로는 연관이 더 깊군요

답변달기
▲
ahwjdekf 10시간전  [-]

js fe 이쪽은 생태계 한번 싹다 멸망하고 리셋한번 해주세요. 그리고 상태관리 이런거도 좀 싹 다 포함해서 프레임워크를 만들어 주길. 지나치게 많은 선택지? 그건 자유가 아니고 그냥 무책임일뿐.

답변달기
▲
quilt8703 14시간전  [-]

React로 UI 상호작용, 내부 상태 계산, 상태 표시 정도만 필요한 게임 프로토타이핑을 하고 있습니다. 몇 년 전 create-react-app이 공식 문서에서 퇴출될랑말랑 때와 비교해 최근이 좀 더 공식 문서를 보고 셋업하기 까다로웠다고 느꼈습니다. 그 때 작성했던 글이 조금 관련있을 것 같네요.

답변달기