React 서버 컴포넌트 소개

이전에는 사용자가 React 애플리케이션에 접속하면 서버는 하나 이상의 JavaScript 파일이 포함된 빈 HTML 파일을 반환했습니다. 브라우저는 HTML을 파싱한 다음 JavaScript 파일을 다운로드하여 클라이언트 측에서 웹 페이지를 렌더링했습니다.

React 서버 컴포넌트(RSC)의 등장은 React의 범위를 확장했습니다. 이름에서 알 수 있듯이 React 서버 컴포넌트는 React의 서버 측 컴포넌트입니다. 이는 서버에서만 실행되며 서버 측 메서드를 호출하고 데이터베이스 등에 액세스할 수 있습니다. 각 사전 렌더링 후 RSC는 HTML을 클라이언트에 보내고, 클라이언트는 이를 하이드레이트하고 공식적으로 렌더링합니다. 이 접근 방식의 장점은 원래 클라이언트 측 JavaScript 파일에 패키지화된 코드의 일부를 이제 서버에서 실행할 수 있으므로 클라이언트 측 부담을 줄이고 애플리케이션의 전체 성능과 응답 속도를 향상시킬 수 있다는 것입니다.

"서버 리소스를 최대한 활용"하는 것이 RSC 출시의 가장 큰 동기입니다. 즉, 상호 작용이 필요하지 않은 모든 것은 서버에 배치되어야 합니다. React 공식 웹사이트에서는 마크다운 콘텐츠 렌더링이라는 매우 일반적인 예제를 제공합니다.

클라이언트 측 컴포넌트 렌더링

import marked from'marked'; // 35.9K (11.2K gzipped)
import sanitizeHtml from'sanitize-html'; // 206K (63.3K gzipped)

function NoteWithMarkdown({text}) {
  const html = sanitizeHtml(marked(text));
  return (/* rendering */);
}

이 예제에서 클라이언트 측 컴포넌트를 사용하여 렌더링하는 경우 클라이언트는 콘텐츠를 렌더링하기 위해 최소 200k 이상의 파일을 다운로드해야 합니다. 그러나 여기서 마크다운 콘텐츠는 실제로 상호 작용이 필요하지 않으며 사용자 작업으로 인해 업데이트된 정보가 필요하지 않습니다. 이는 RSC 사용 개념과 매우 일치합니다. RSC를 사용하는 경우:

서버 측 컴포넌트 렌더링

import marked from'marked'; // zero packaging size
import sanitizeHtml from'sanitize-html'; // zero packaging size

function NoteWithMarkdown({text}) {
  // the same as before
}

종속성 패키지는 서버에 배치되고 서버는 사용자에게 필요한 콘텐츠만 반환합니다. 클라이언트 측 패키지는 갑자기 200k 이상 줄어듭니다.

이 시점까지 커뮤니티의 주류 견해는 긍정적이었지만 Next.js는 RSC의 특성을 기반으로 적극적으로 발전했고, 그 후 의견 차이가 나타났습니다.

커뮤니티 의견 불일치

의견 불일치의 가장 근본적인 이유는 React가 서버 측 개념을 도입했기 때문입니다. 서버 측 컴포넌트와 클라이언트 측 컴포넌트에는 명확한 차이점이 있습니다.

서버 측 컴포넌트는 useState 및 useEffect와 같은 React 훅을 사용할 수 없습니다. 클라이언트 측 컴포넌트는 사용할 수 있습니다.
서버 측 컴포넌트는 브라우저 API에 액세스할 수 없습니다. 클라이언트 측 컴포넌트는 모든 브라우저 API 권한을 갖습니다.
서버 측은 서버 측 프로그램 및 API에 직접 액세스할 수 있는 권한이 있습니다. 반면 클라이언트 측 컴포넌트는 요청을 통해 일부 프로그램에만 액세스할 수 있습니다.

Next.js v13 및 v14가 출시됨에 따라 React의 카나리아 버전인 RSC가 Next.js에 의해 프로덕션 환경으로 이동되었습니다. 'use client' 및 'use server'가 점점 더 많은 사람들에게 논의되고 있습니다. 개발자들은 이제 "두 개의 React"가 있다고 말하며 커뮤니티는 React가 수년에 걸쳐 발전했는지 퇴보했는지에 대해 논쟁을 벌이기 시작했습니다.

커뮤니티의 반대 의견

유명한 소프트웨어 엔지니어 Cassidy Williams

그녀는 지난 2년간 React의 개발 문제를 지적했습니다.

"두 개의 React"가 가져온 새로운 개념은 대부분의 사람들에게 명확하고 이해하기 쉬운 지식이 아닙니다. 이러한 분열은 추가적인 혼란과 학습 장벽으로 이어질 수 있습니다.
2022년 6월 이후 React는 새로운 릴리스가 없을 뿐만 아니라 개발자가 상위 계층 프레임워크를 사용하도록 장려했습니다. 이러한 상위 계층 프레임워크는 RSC가 안정적인 버전으로 업그레이드될 때까지 기다리지 않고 RSC를 기반으로 한 기능을 릴리스했습니다(거의 Next.js를 지명)..
최근 몇 년 동안 React의 일부 멤버가 다른 상위 계층 프레임워크 팀에 합류했습니다. 이들은 버전 업데이트를 소홀히 했을 뿐만 아니라 문서 업데이트도 소홀히 했습니다.

React Query 개발자 Tanner Linsley

그는 또한 React 개발에 대한 우려와 불만을 표명했습니다.

React가 훅과 서스펜스 API를 도입한 이후 React는 몇 가지 개념에 지나치게 집중했습니다. 이러한 새로운 개념은 기술적으로 단일 스레드 UI API의 한계와 경계를 넓히지만 사용자에게 가치를 제공하는 그의 일상 업무에는 거의 영향을 미치지 않습니다.
RSC의 릴리스를 보면 React 팀은 더 이상 클라이언트 측 성능을 강력하게 추구하지 않습니다.

지도 기술 및 시각화 기술 전문가 Tom MacWright

그는 React 생태계의 파편화를 비판했습니다.

현재 React 업데이트는 느립니다. 대신 Shopify에서 자금을 지원하는 Remix와 Vercel에서 자금을 지원하는 Next.js라는 두 개의 상위 계층 프레임워크가 치열한 경쟁을 벌이고 있습니다.
React 팀과 Next.js 팀 간의 교집합이 너무 커서 Vercel에게 선두적인 이점을 제공합니다. Remix와 같이 Vercel 및 Facebook 생태계에 속하지 않는 다른 프레임워크는 수정되었지만 릴리스되지 않은 React의 버그에 영향을 받습니다.

커뮤니티의 긍정적인 태도

커뮤니티의 반대 의견이 증가함에 따라 React의 주요 기여자인 Dan Abramov도 여러 차례 자신의 견해를 표명했습니다. 그는 기술 변화에 대해 개방적인 태도를 가지고 있습니다.

Next.js의 앱 라우터는 야심이 크지만 여전히 개발 초기 단계에 있으며 앞으로 더욱 훌륭하게 반복될 것입니다.
클라이언트 측 컴포넌트의 작업은 UI = f(상태)이고 서버 측 컴포넌트의 작업은 UI = f(데이터)입니다. React는 둘 다의 장점을 결합하여 UI = f(데이터, 상태)를 달성하고자 합니다. 그는 커뮤니티에 이 목표의 실현을 공동으로 추진할 것을 촉구했습니다.
Next.js에서 RSC를 프로덕션 버전으로 릴리스하는 것과 관련하여 Dan은 "프로덕션 준비"가 주관적인 판단이라고 생각합니다. RSC는 여전히 카나리아 버전이지만 Facebook에서는 이미 광범위하게 사용하고 있습니다. 그는 실제로 검증하면 기술을 더 빠르게 개선하고 궁극적으로 성숙도와 안정성을 달성할 수 있다고 믿습니다.
새로운 기술 개발은 지속적인 테스트, 피드백 및 반복을 포함하는 점진적인 프로세스입니다. 커뮤니티의 힘이 매우 중요합니다.

전반적으로 Dan은 모든 사람이 편견을 버리고 React의 다음 단계 전환을 실제로 공동으로 탐색할 수 있기를 바랍니다.

결론

RSC는 최신 웹 애플리케이션 개발을 향상시키는 데 긍정적인 의미가 있습니다. 가장 분명한 장점은 대규모 애플리케이션의 성능을 향상시키고 클라이언트 측 로드를 줄이며 데이터 획득 프로세스를 최적화하는 등입니다. RSC를 통해 이러한 작업을 완료하는 것이 이전 SSR 솔루션보다 더 편리합니다.

Node v20 출시와 RSC 적용으로 프런트엔드와 서버 간의 거리가 더욱 좁혀졌습니다. 프런트엔드 작업의 "백엔드화"를 목격할 기회가 있습니다. 즉, 프런트엔드 엔지니어는 데이터 쿼리 최적화, 서버 리소스 관리 등과 같이 전통적으로 백엔드에 속하는 더 많은 작업을 처리하게 됩니다. 이는 실제로 프런트엔드 엔지니어를 위한 문을 열어 전체 웹을 포괄적으로 마스터할 수 있는 기회를 제공합니다.