React 19 서버 컴포넌트와 React Compiler 실전 마이그레이션 가이드

2024년 12월 정식 릴리스된 React 19는 단순한 버전업이 아니라 렌더링 패러다임의 전환점이다. 서버 컴포넌트(RSC)가 안정화되고 React Compiler가 실험 딱지를 떼면서, 그동안 손으로 최적화하던 관행이 대거 사라지고 있다. 2026년 현재 대형 서비스의 마이그레이션 사례가 축적되며 실전 노하우가 정리되는 시점이다. 이 글은 기존 React 18 코드베이스를 React 19로 옮기는 개발자를 위한 구체적 절차와 함정을 다룬다.

서버 컴포넌트가 바꾸는 데이터 페칭 구조

서버 컴포넌트의 핵심은 컴포넌트 자체가 서버에서 실행되어 자바스크립트 번들에 포함되지 않는다는 점이다. 데이터베이스나 파일 시스템에 직접 접근하는 로직을 클라이언트로 내려보내지 않으므로, 초기 번들 크기가 눈에 띄게 줄어든다. 실제 마이그레이션 사례에서 대시보드 성격의 페이지는 클라이언트 번들이 30에서 45퍼센트까지 감소하는 경우가 흔하다. 마케팅 페이지처럼 상호작용이 적은 화면일수록 절감 폭이 크다.

기존 useEffect 안에서 fetch를 호출하던 패턴은 서버 컴포넌트에서 async 함수로 대체된다. 워터폴 요청이 사라지고, 컴포넌트가 데이터를 기다리는 동안 Suspense 경계가 스트리밍으로 부분 렌더링을 처리한다. 다만 ‘use client’ 지시자의 경계를 잘못 설정하면 서버 전용 코드가 클라이언트로 새어 나가 빌드 에러가 발생한다. 페칭과 상호작용을 명확히 분리하고, 상태를 다루는 리프 컴포넌트에만 클라이언트 지시자를 붙이는 것이 정석이다.

// 서버 컴포넌트: 번들에 포함되지 않는다
async function ProductList() {
  const products = await db.product.findMany();
  return products.map((p) => <ProductCard key={p.id} data={p} />);
}

React Compiler: 수동 메모이제이션의 종말

React Compiler는 빌드 타임에 컴포넌트를 분석해 자동으로 메모이제이션을 삽입한다. 그동안 리렌더링 최적화를 위해 개발자가 useMemo, useCallback, React.memo를 수동으로 배치하던 작업이 사실상 불필요해진다. 컴파일러는 각 값의 의존성을 정적으로 추적해 필요한 지점에만 캐싱 코드를 주입하므로, 사람이 놓치던 세밀한 최적화까지 커버한다.

도입은 바벨 플러그인 또는 SWC 설정으로 시작한다. 먼저 eslint-plugin-react-hooks의 컴파일러 규칙을 켜서 컴파일러가 안전하게 처리할 수 없는 컴포넌트를 찾아내야 한다. 리액트의 규칙을 위반하는 코드, 예컨대 렌더링 중 변수를 직접 변형하거나 ref를 부적절하게 읽는 코드는 컴파일러가 자동으로 최적화를 건너뛴다. 점진적 도입을 위해 특정 디렉터리부터 적용하고, 프로파일러로 리렌더링 횟수를 측정하며 범위를 넓히는 방식을 권장한다. 실전에서는 기존 useMemo를 한꺼번에 지우기보다, 컴파일러 적용 후 성능을 검증한 뒤 단계적으로 제거하는 편이 안전하다.

Actions와 폼 처리의 표준화

React 19는 Actions라는 개념으로 비동기 상태 전환을 1급 시민으로 끌어올렸다. useActionState, useOptimistic, useFormStatus 훅이 추가되어 폼 제출 시 로딩 상태, 낙관적 업데이트, 에러 처리를 표준 방식으로 다룰 수 있다. 기존에는 제출 상태를 useState로 직접 관리하고 try-catch로 에러를 잡던 보일러플레이트가 크게 줄어든다.

낙관적 업데이트는 useOptimistic으로 서버 응답을 기다리지 않고 UI를 즉시 갱신한 뒤, 실패 시 자동으로 되돌린다. 댓글 작성이나 좋아요 같은 상호작용에서 체감 반응 속도가 극적으로 개선된다. 또한 ref를 prop으로 직접 전달할 수 있게 되면서 forwardRef가 불필요해졌고, 문서 메타데이터 태그를 컴포넌트 안에서 선언하면 자동으로 head로 끌어올려진다. 마이그레이션 시에는 이러한 API 변경점을 codemod로 일괄 처리한 뒤, 서버 컴포넌트 경계와 컴파일러 적용을 순차적으로 진행하는 로드맵이 현실적이다. 팀 규모가 크다면 리프 컴포넌트부터 위로 올라가는 상향식 전환이 충돌을 최소화한다.

점진적 전환 로드맵과 흔한 함정

실제 프로젝트에서 React 19로의 전환은 한 번에 이뤄지지 않는다. 가장 현실적인 순서는 먼저 버전을 올리고 호환성 경고를 해소한 뒤, 컴파일러를 좁은 범위에 적용하고, 마지막으로 서버 컴포넌트를 도입하는 단계적 접근이다. 각 단계마다 회귀 테스트를 돌려 렌더링 결과와 성능 지표가 유지되는지 확인해야 한다. 특히 서드파티 라이브러리가 새 버전과 호환되는지 사전에 점검하지 않으면, 전환 도중 예상치 못한 런타임 오류에 발목이 잡히기 쉽다.

가장 흔한 함정은 클라이언트 컴포넌트와 서버 컴포넌트의 경계를 잘못 설정하는 것이다. 서버 컴포넌트는 상태나 이벤트 핸들러를 가질 수 없고, 브라우저 전용 API에 접근할 수 없다. 반대로 클라이언트 컴포넌트 안에서 데이터베이스에 직접 접근하려 하면 민감한 자격 증명이 번들에 노출될 위험이 있다. 데이터 페칭은 가능한 한 서버 쪽으로 끌어올리고, 상호작용이 필요한 최소 단위만 클라이언트로 내리는 원칙을 지켜야 이 경계 문제를 예방할 수 있다.

성능 측정도 전환의 필수 요소다. 마이그레이션 전후로 라이트하우스 점수, 최초 콘텐츠풀 페인트, 상호작용까지의 시간 같은 핵심 웹 지표를 비교해 실제 개선을 정량적으로 확인해야 한다. 번들 크기는 빌드 분석 도구로 추적하고, 리렌더링 횟수는 프로파일러로 계측한다. 감으로 최적화했다고 믿는 대신, 숫자로 검증하는 습관이 대규모 전환을 성공으로 이끄는 가장 확실한 열쇠다.

전환을 시작하기 전에 팀 차원의 준비도 중요하다. 서버 컴포넌트와 클라이언트 컴포넌트의 사고방식은 기존과 크게 다르므로, 팀원들이 새로운 렌더링 모델을 충분히 이해하도록 학습 시간을 확보해야 한다. 작은 시범 프로젝트로 개념을 검증하고 그 경험을 팀 내부에 공유하면, 본격적인 전환에서 발생할 시행착오를 크게 줄일 수 있다. 문서화되지 않은 암묵적 규칙에 의존하기보다, 어떤 컴포넌트를 어떤 방식으로 작성할지에 대한 명확한 지침을 세워두는 편이 협업의 혼란을 막는다. 결국 성공적인 마이그레이션은 기술적 완성도만이 아니라 팀 전체가 새로운 패러다임을 공유하고 일관되게 실천하는 데서 완성된다.