React 살아있니?

최근 들어 React 소식을 예전만큼 챙겨보지 않는다. 프론트엔드 커뮤니티가 AI 이야기로 가득 차면서 React 자체를 다루는 글이나 대화가 눈에 띄게 줄었다. 공식 블로그도 조용하다. 이 글을 쓰는 2026년 8월 기준, 가장 최근 글은 지난 2월에 올라온 React Foundation 출범 소식이다. 예전처럼 가만히 있어도 React 소식이 들려오던 때와는 분위기가 확실히 달라졌다.

AI가 등장한 뒤 개발하는 방식도 많이 바뀌었다. 예전에는 React 공식 문서를 늘 띄워두고 필요한 API를 찾아가며 개발했다. 지금은 막히는 부분이 생기면 문서보다 AI에 먼저 묻는다. React를 계속 쓰면서도 정작 React의 변화는 놓치기 쉬워졌다.

그렇다고 프론트엔드에서 React의 존재감이 줄어든 건 아니다. React는 여전히 가장 널리 쓰이는 기술 중 하나다. 나 역시 새 프로젝트를 시작하면 자연스럽게 React부터 고르지만, 마지막으로 업데이트 소식을 찾아본 게 언제인지는 기억나지 않았다.

그래서 이번에 다시 찾아봤다. 최근 React에는 무엇이 추가됐고, 지금 누가 만들고 있으며, 커뮤니티는 그 변화를 어떻게 보고 있을까.

아직 살아 있나?#

React는 여전히 잘 살아 있다. 다만 우리가 기억하던 클라이언트 UI 라이브러리와는 모습이 꽤 달라졌다. 이제는 컴파일러와 서버 렌더링까지 다루는 기반 기술로 범위를 넓히고 있다. 그에 비해 왜 이렇게 달라지고 있는지는 커뮤니티에 충분히 전달되지 않은 듯하다.

최근 업데이트#

먼저 React 19 이후 무엇이 달라졌는지 살펴보자.

2024년 12월 나온 React 19에는 비동기 작업을 다루는 Actions와 use, 폼 관련 Hook, ref를 일반 prop처럼 넘기는 기능이 들어갔다. 2025년 10월에는 React 19.2와 React Compiler 1.0이 연달아 공개됐다.

왜 이런 기능이 필요했을까. 웹 앱이 커질수록 데이터 로딩과 화면 전환은 복잡해지고, 불필요한 렌더링을 줄이는 일도 어려워진다. 지금까지는 개발자가 여러 라이브러리와 최적화 기법을 조합해 해결했다. 이제는 React가 이런 문제를 렌더링 과정 안에서 직접 다루려는 것이다.

2026년 2월에는 운영 주체도 달라졌다. React와 React Native의 소유권과 운영은 Meta에서 Linux Foundation 산하의 React Foundation으로 옮겨갔다. 이제 React는 Meta의 내부 도구를 넘어 수많은 회사가 의존하는 기반 기술이 됐다. 한 회사보다 중립적인 재단이 운영하는 편이 더 자연스러워진 셈이다.

그렇다고 Meta가 React에서 완전히 빠진 것은 아니다. Meta는 5년간 300만 달러 이상을 지원하고 전담 엔지니어도 계속 투입하기로 했다. 2026년 8월 기준 React Leadership Council 7명 가운데 5명 역시 Meta 소속이고, 나머지 2명은 Vercel 소속이다.

2026년 7월 21일에는 React 19.2.8이 나왔다. 새로운 기능을 선보인 버전은 아니지만 React Server Components의 디코딩 성능이 개선됐다. 공식 블로그가 조용할 뿐, 개발과 릴리스는 꾸준히 이어지고 있다.

React Compiler#

최근 React에서 가장 눈에 띄는 변화는 React Compiler다. React 컴포넌트는 상태가 바뀔 때 함수가 다시 실행되고, 이 과정에서 같은 계산과 자식 렌더링이 반복될 수 있다. React Compiler는 이런 불필요한 작업을 줄이기 위해 개발자가 직접 하던 메모이제이션을 빌드 단계에서 대신 처리한다.

지금까지는 불필요한 계산과 렌더링을 줄이기 위해 useMemo, useCallback, React.memo를 직접 조합해야 했다.

const TodoList = memo(function TodoList({ todos, onSelect }) {
  const visibleTodos = useMemo(
    () => todos.filter((todo) => !todo.done),
    [todos],
  )
 
  const handleSelect = useCallback(
    (id) => onSelect(id),
    [onSelect],
  )
 
  return <List items={visibleTodos} onSelect={handleSelect} />
})

계산 결과는 useMemo, 함수는 useCallback, 컴포넌트는 React.memo로 감쌌다. 무엇을 재사용할지 고르고 의존성 배열까지 관리하는 일은 모두 개발자의 몫이었다.

Compiler를 적용하면 코드는 간단해진다.

function TodoList({ todos, onSelect }) {
  const visibleTodos = todos.filter((todo) => !todo.done)
  const handleSelect = (id) => onSelect(id)
 
  return <List items={visibleTodos} onSelect={handleSelect} />
}

Compiler가 실제로 세 API를 코드에 넣는 것은 아니다. 내부에서는 먼저 Babel이 읽은 소스 코드를 AST(Abstract Syntax Tree)로 전달받는다. AST는 함수와 조건문, 변수, JSX 같은 문법을 트리 형태로 나타낸 구조다.

그다음 AST를 CFG(Control Flow Graph) 기반의 HIR(High-Level Intermediate Representation)로 바꾼다. CFG는 코드를 단순히 위에서 아래로 읽는 대신 조건문과 조기 반환처럼 실행 경로가 갈라지는 지점까지 연결해서 보여준다. HIR은 이 흐름을 Compiler가 분석하기 좋게 정리한 내부 표현이다. 이 과정은 React Compiler 공식 설명에서도 확인할 수 있다.

이제 data-flow 분석으로 각 값이 어디에서 만들어지고 무엇에 의존하는지 추적한다. 위 코드에서는 visibleTodos가 todos에 의존하고, handleSelect가 onSelect에 의존한다. <List>는 두 값을 모두 사용한다.

todos    → visibleTodos ─┐
                         ├→ <List />
onSelect → handleSelect ─┘

mutability 분석은 그 값이 나중에 바뀔 가능성이 있는지를 확인한다. 같은 객체를 여러 변수가 가리키거나 외부 함수가 값을 변경할 수 있다면 이전 결과를 안전하게 재사용하기 어렵다. 반대로 의존 관계가 분명하고 값이 예측 가능하면 필요한 계산과 JSX에 캐시를 만든다.

실제 변환 결과는 React Compiler Playground에서 확인할 수 있다. 결과 코드에서 react/compiler-runtime의 캐시가 만들어지고, 입력이 그대로일 때 이전 값을 꺼내 쓰는 모습을 볼 수 있다.

todos가 바뀌면 목록만 다시 계산하고, onSelect가 바뀌면 함수만 새로 만든다. 둘 다 그대로라면 이전 <List>를 재사용해 자식 컴포넌트의 렌더링도 건너뛴다. 각각 useMemo, useCallback, React.memo로 처리하던 최적화와 비슷한 효과다.

이 과정은 브라우저에서 실시간으로 일어나지 않는다. 앱을 빌드할 때 분석을 끝내고 캐시가 포함된 코드를 미리 만든다. 조건문 뒤에 있는 계산처럼 개발자가 Hook을 넣기 어려운 부분도 필요한 범위만 골라 최적화할 수 있다.

다만 모든 코드를 무조건 캐시하는 것은 아니다. Compiler는 React의 규칙을 지키는 컴포넌트와 Hook을 중심으로 필요한 값과 JSX만 고른다. 안전하게 분석하기 어려운 코드는 동작을 바꾸는 대신 최적화를 건너뛴다. 기존 코드의 useMemo와 useCallback을 당장 모두 지울 필요도 없다. 중요한 변화는 성능을 위해 사람이 일일이 붙이던 힌트를 이제 Compiler가 코드에서 찾아낼 수 있게 됐다는 점이다.

Server Components#

React의 최근 변화를 이야기할 때 React Server Components(RSC)도 빼놓을 수 없다. 이름은 어렵지만 방향은 단순하다. 화면을 만드는 일 가운데 서버가 더 잘하는 부분은 서버에서 처리하자는 것이다.

Server Component는 컴포넌트 안에서 데이터베이스나 파일을 바로 읽을 수 있다. 브라우저가 API를 호출하고 데이터를 기다린 뒤 화면을 다시 그리던 과정을 서버 안에서 끝낸다.

async function PostPage({ id }) {
  const post = await db.posts.find(id)
 
  return (
    <article>
      <h1>{post.title}</h1>
      <p>{post.content}</p>
      <LikeButton postId={post.id} />
    </article>
  )
}

PostPage와 데이터베이스 코드는 서버에서만 실행된다. 그렇다고 JavaScript를 전혀 보내지 않는 것은 아니다. 게시글 본문처럼 보여주기만 하는 부분은 결과만 보내고, 클릭이 필요한 LikeButton의 JavaScript는 브라우저로 보낸다. 이렇게 상호작용에 필요한 코드만 전달해 사용자가 내려받을 JavaScript를 줄이는 것이 RSC의 장점이다.

이 페이지를 처음 열면 서버는 PostPage의 본문과 LikeButton의 모양을 모두 HTML로 만들어 보낸다. 이것이 SSR(Server Side Rendering)이다. 즉 SSR로 만든 첫 화면에는 Server Component와 Client Component가 모두 들어갈 수 있다.

차이는 첫 화면이 나온 다음이다. PostPage는 이미 서버에서 할 일을 끝냈으므로 브라우저에서 다시 실행되지 않는다. 반면 LikeButton은 클릭에 반응해야 하므로 JavaScript를 내려받아 연결한다.

한마디로 SSR은 첫 화면을 어떻게 보내는가에 대한 방식이고, RSC는 어떤 컴포넌트를 서버에서만 실행할 것인가에 대한 방식이다. SSR은 첫 화면과 검색 노출에 유리하다. 다만 Server Component에서는 useState나 onClick을 쓸 수 없어, 상호작용이 필요한 부분을 Client Component로 나눠야 한다.

이 경계를 나누고 데이터 로딩과 캐시를 연결하려면 프레임워크의 도움이 필요하다.

JavaScript를 줄이고 데이터 로딩을 단순하게 만든다는 방향은 매력적이다. 하지만 기존 React와 개발 방식이 크게 달라지는 만큼 새로 배울 것도 많다. 그래서 RSC를 바라보는 커뮤니티의 반응도 엇갈리고, 이야기는 자연스럽게 Next.js로 이어진다.

커뮤니티 반응#

State of React 2025는 3,760명이 참여한 비공식 설문이다. React 사용자 전체의 생각이라고 보기는 어렵지만, 커뮤니티가 어떤 기능을 기대하고 무엇을 걱정하는지는 엿볼 수 있다.

새 기능 가운데 React Compiler를 기대한다는 응답은 약 62%였다. 반면 React Server Components는 약 20%에 그쳤다.

왜 이렇게 차이가 클까. Compiler는 기존 코드를 거의 그대로 두면서 성능을 개선할 수 있다. 반면 RSC를 적용하려면 서버와 클라이언트의 경계부터 데이터 로딩, 캐시, 배포 방식까지 다시 생각해야 한다. 장점은 분명하지만 그만큼 새로 배울 것도 많다.

React를 만드는 조직을 바라보는 시선도 엇갈렸다. Meta의 참여에는 긍정적인 반응이 부정보다 많았다. 독립적인 React Foundation에는 50%가 긍정적으로 답했고, 부정적인 응답은 2%에 불과했다. 한 회사가 소유하던 프로젝트를 중립 재단으로 옮기는 방향을 긍정적으로 바라보는 분위기가 뚜렷했다.

반면 Vercel의 참여에는 부정적인 응답이 36%, 긍정적인 응답이 25%였다. Vercel은 React에 많은 인력과 비용을 투자하지만, 동시에 Next.js와 호스팅을 주요 사업으로 삼는 회사다. React가 서버 중심으로 변하는 방향과 Vercel의 사업이 맞물리면서, React가 특정 회사나 플랫폼에 지나치게 의존하게 되는 것 아니냐는 우려가 나온다.

2025년 말 React Server Components에서 원격 코드 실행 취약점에 이어 서비스 거부와 소스 코드 노출 취약점이 발견된 일도 불안을 키웠다. 패치는 빠르게 나왔지만 RSC가 아직 안정되어 가는 과정이라는 인상을 남겼다.

결국 커뮤니티의 불만은 변화 자체보다 React가 왜 이 방향으로 가는지 알기 어렵다는 데 가깝다. Redux maintainer Mark Erikson도 React 커뮤니티를 정리한 글에서 Vercel이 React를 장악했다는 주장은 과장이라고 봤다. 다만 React 팀의 부족한 문서와 소통이 그런 의심을 키웠다고 지적했다.

React와 Next.js#

React는 UI를 그리는 라이브러리고, Next.js는 라우팅·빌드·데이터 로딩·캐시·배포 구조를 더한 프레임워크다. 둘은 같은 제품이 아니다.

하지만 두 기술이 예전보다 훨씬 가까워진 것은 사실이다. React Server Components만 설치한다고 서버 기능이 저절로 완성되는 것은 아니다. 어떤 코드를 서버에서 실행할지 나누고 그 결과를 브라우저로 전달하려면 라우팅과 번들링까지 연결해 줄 프레임워크가 필요하다.

대표적으로 Next.js App Router가 이 역할을 일찍부터 맡아 실제 서비스에 적용했다. React 안정 버전에 들어가기 전인 Canary 기능도 Next.js를 통해 검증됐다. React 팀에는 Vercel 소속 개발자도 참여하고 있어 React의 변화가 Next.js에 빠르게 반영되고, Next.js에서 확인된 문제도 React 개발에 전달되는 구조다.

그래서 “Vercel이 React를 소유한다”는 말은 맞지 않는다. 다만 “Next.js에서 React의 미래를 가장 먼저 볼 수 있다”는 말에는 어느 정도 고개가 끄덕여진다.

이렇게 가까운 관계 덕분에 React는 새로운 기능을 실제 환경에서 시험할 수 있었다. 반대로 React를 제대로 쓰려면 Next.js까지 선택해야 하는 것처럼 보이게 만들기도 했다.

달라진 React#

React는 죽지 않았다. 새 버전은 계속 나오고 있고, Compiler 같은 빌드 단계의 최적화도 발전하고 있다. Meta도 소유권을 재단에 넘겼지만 사람과 돈은 계속 투자하고 있다.

달라진 것은 React가 다루는 범위다. 예전에는 “상태가 바뀌면 UI를 다시 그리는 작은 라이브러리”에 가까웠다면, 지금은 클라이언트와 서버, 빌드 단계까지 하나의 렌더링 방식 안에서 다루려는 것 같다.

이 글은 사실관계나 해석에 오류가 있을 수 있습니다. 잘못된 내용이나 질문이 있으면 댓글로 편하게 남겨 주세요.

Reference#

• React, React 19.2
• React, React Compiler v1.0
• React, Server Components
• React, The React Foundation: A New Home for React
• React, Meet the Team
• React, Critical Security Vulnerability in React Server Components
• React, Denial of Service and Source Code Exposure in React Server Components
• Meta, Introducing the React Foundation
• Devographics, State of React 2025
• Mark Erikson, The State of React and the Community in 2025