React 20이 없는 이유와 React Compiler

리액트 버전을 확인하려고 들어가 보면 의외의 사실을 마주한다. 2026년 9월 현재 최신은 19.3이고, React 20은 발표된 적이 없다. 19.0이 나온 뒤로 메이저 버전이 올라가지 않고 있다. 이 글은 왜 그런지, 그리고 그 사이 리액트에서 실제로 바뀐 것이 무엇인지를 정리한다. 결론부터 말하면 변화의 무게 중심이 런타임에서 컴파일러로 옮겨 갔다.

버전 기록이 말해주는 것

공식 버전 페이지의 최근 기록은 이렇다.

버전	날짜
19.3.0	2026-09-09
19.2.7	2026-06-01
19.2.6	2026-05-06
19.2.5	2026-03-18
19.2.4	2026-01-26
19.2.0	2025-10-01

1년 가까이 19.x 안에서만 움직였다. 마이너와 패치가 꾸준히 나오지만 메이저는 없다.

이걸 "정체"로 읽을 수도 있고 "안정"으로 읽을 수도 있다. 나는 후자에 가깝다고 본다. 리액트는 16에서 17, 18로 넘어갈 때마다 큰 마이그레이션 비용을 요구했다. 동시성 렌더링이 들어온 18은 특히 그랬다. 19에서 서버 컴포넌트와 액션이 정리된 뒤로는, 깨지는 변경 없이 개선을 쌓는 쪽으로 방향이 잡힌 것으로 보인다.

진짜 변화는 컴파일러 쪽에서 일어났다

런타임 버전이 조용한 동안, 리액트 생태계에서 가장 큰 변화는 React Compiler였다. 2025년 10월에 1.0으로 안정화됐고, 리액트 17까지 거슬러 지원한다.

컴파일러가 하는 일은 한 문장으로 요약된다. 빌드 시점에 컴포넌트를 분석해서 필요한 메모이제이션을 자동으로 넣는다.

// 지금까지: 손으로 감싼다
const Row = memo(function Row({ item, onPick }) {
  const label = useMemo(() => format(item), [item]);
  const handle = useCallback(() => onPick(item.id), [onPick, item.id]);
  return <li onClick={handle}>{label}</li>;
});

// 컴파일러 적용 후: 그냥 쓴다
function Row({ item, onPick }) {
  const label = format(item);
  return <li onClick={() => onPick(item.id)}>{label}</li>;
}

아래 코드가 위 코드와 같은 수준으로 최적화된다. memo, useMemo, useCallback을 손으로 붙이는 작업이 대부분 사라진다.

이게 왜 큰 변화인가. 지금까지 리액트 성능 최적화는 사람이 의존성 배열을 정확히 관리하는 일이었다. 배열에 값을 빠뜨리면 낡은 값이 남고, 너무 많이 넣으면 메모이제이션이 무의미해진다. 이 실수가 리액트 버그의 큰 축이었다.

컴파일러는 코드를 분석해서 무엇에 의존하는지 스스로 판단한다. 사람이 틀릴 여지가 사라진다. 다만 조건이 있다. 컴파일러가 분석하려면 컴포넌트가 리액트 규칙을 지켜야 한다. 렌더링 중 부수 효과를 일으키거나 props를 직접 변경하는 코드는 최적화 대상에서 빠진다. 그래서 컴파일러 진단이 Hooks ESLint 규칙 생태계 안에 들어가 있다. 규칙을 어긴 곳을 린트가 잡아준다.

도입할 때 실제로 확인할 것

컴파일러는 Next.js, Vite, Expo에 통합 경로가 있다. 설정 자체는 어렵지 않다. 문제는 그다음이다.

먼저 린트를 통과시켜야 한다. 기존 코드에 리액트 규칙 위반이 있으면 그 컴포넌트는 최적화되지 않는다. 조용히 건너뛰므로 "적용했는데 안 빨라진다"는 상황이 생긴다. 컴파일러가 어떤 컴포넌트를 처리했는지 확인하는 도구를 함께 보는 것이 좋다.

손으로 넣은 메모이제이션을 바로 걷어내지 않는다. 컴파일러가 켜졌다고 기존 useMemo를 전부 지우면, 문제가 생겼을 때 원인을 가리기 어렵다. 먼저 컴파일러를 켜고 동작을 확인한 뒤, 새 코드부터 메모이제이션 없이 쓰는 순서가 안전하다.

성능 측정을 먼저 해둔다. 컴파일러는 불필요한 리렌더를 줄이지만, 애초에 리렌더가 병목이 아니었다면 체감이 없다. 느린 원인이 큰 리스트 렌더링이나 무거운 연산, 네트워크 대기라면 컴파일러는 답이 아니다.

React 20 이 없는 것은 문제인가

메이저 버전이 안 올라가는 상황을 걱정하는 목소리도 있다. 프레임워크가 멈춘 것 아니냐는 것이다.

나는 반대로 본다. 메이저 버전은 깨지는 변경이 있을 때 올리는 것이지, 부지런함을 증명하려고 올리는 것이 아니다. 리액트는 이미 웹에서 가장 많이 쓰이는 UI 라이브러리이고, 그 위치에서 잦은 파괴적 변경은 생태계 전체에 비용을 떠넘긴다.

실제로 컴파일러는 메이저 버전 없이 나왔다. 빌드 단계에 붙는 도구라 런타임 API를 바꿀 필요가 없었기 때문이다. 리액트 17까지 지원한다는 점도 그 덕분이다. 큰 개선을 깨지는 변경 없이 전달하는 방법을 찾은 셈이다.

경계할 점이 없지는 않다. 개선이 컴파일러·서버 컴포넌트·프레임워크 통합 쪽으로 몰리면서, 리액트를 쓰는 비용이 리액트 자체가 아니라 그 주변 도구에 있는 상황이 됐다. 예전에는 <script> 태그 하나로 시작할 수 있었지만 지금은 번들러와 컴파일러 설정을 이해해야 한다. 진입 장벽이 다른 곳으로 옮겨 간 것이지 사라진 것은 아니다.

그래도 방향은 맞다고 본다. 사람이 손으로 하던 최적화를 도구가 가져가는 것은 거의 항상 옳은 이동이다. 의존성 배열을 눈으로 검사하며 보낸 시간은 아무에게도 가치를 만들어 주지 않았다.

컴파일러가 못 고치는 성능 문제

컴파일러는 불필요한 리렌더를 줄인다. 그런데 리액트 앱이 느린 이유가 그것만은 아니다. 자주 만나는 나머지 원인을 정리하면 이렇다.

리스트가 크다. 수천 개 항목을 한 번에 렌더링하면 리렌더 여부와 무관하게 느리다. 가상 스크롤로 화면에 보이는 것만 그려야 한다. 컴파일러는 여기에 관여하지 않는다.

번들이 크다. 첫 화면이 늦는 원인은 대개 자바스크립트를 내려받고 파싱하는 시간이다. 코드 분할과 지연 로딩이 답이고, 이것도 컴파일러 밖의 일이다.

네트워크 폭포수가 생긴다. 컴포넌트가 마운트된 뒤에 데이터를 요청하고, 그 데이터를 받아야 자식이 렌더링되고, 자식이 또 요청하는 구조다. 요청을 상위로 끌어올리거나 서버 컴포넌트로 옮겨야 풀린다.

연산이 무겁다. 큰 배열을 정렬하거나 필터링하는 작업이 렌더링 경로에 있으면, 메모이제이션이 잘 되어 있어도 처음 한 번은 느리다. 웹 워커로 옮기거나 서버에서 계산해 내려주는 편이 낫다.

성능 작업의 순서는 언제나 같다. 측정하고, 가장 큰 것부터 고친다. 컴파일러는 그 목록의 한 항목을 자동으로 처리해 주는 도구지, 목록 자체를 없애 주지는 않는다.

참고 자료

• React Versions — react.dev — 최신 버전과 릴리스 날짜 기록
• React Compiler Turned One in 2026 — Refonte Learning — 컴파일러 1.0 안정화 시점, 지원 범위, 프로덕션 적용 관점
• React Compiler Is Coming — The New Stack — 컴파일러가 해결하려는 문제의 배경