RSC의 이해: 클라이언트 컴포넌트에서 서버컴포넌트로

React가 클래스 컴포넌트에서 함수 컴포넌트를 개발하고 사용을 권장해서 현재는 대부분 함수 컴포넌트로 개발을 하고 있는데요.

Next.js 에서도 최근 앱 라우터를 출시해서 페이지 기반 라우터에서 앱 라우터의 사용을 권장하고 있습니다. 앱 라우터는 기본적으로 모든 컴포넌트가 서버 컴포넌트 입니다. 따라서 React개발 흐름이 '리액트 서버 컴포넌트' 라고 불리우는 'RSC'로 방향을 이어가고 있는데요. 따라서 React개발자는 이러한 변화에 맞추어 이 기술을 활용하고 적응해야 합니다. 그럼 이 RSC는 무엇일까요?

클라이언트 사이드 UI 라이브러리

리액트는 초기에 아주 간단한 클라이언트 사이드 UI라이브러리 였습니다. 큰 컴포넌트를 작은 컴포넌트 조각으로 나누는것을 제안했습니다. 자체 비공개 데이터인 State 와 데이터를 전달하는 방법인 Props로 컴포넌트 계층 구조를 나누고 데이터 흐름을 관리했습니다. 자바스크립트 함수를 통해서 말이죠.

그렇다면 기존 리액트 앱의 문제는 무엇이었을까요?

1. JavaScript 파일 크기로 인한 초기 로딩 시간 지연: SSR을 통해 어느정도 문제를 해결할수는 있지만, 여전히 클라이언트에서 추가적인 JavaScrip를 실행해야 합니다.

2. 네트워크 워터폴로 인한 클라이언트 컴포넌트 응답 지연

3. 레이아웃 이동 문제: 네트워크 API응답 순서에 대한 보장이 없다보니, 지연 시간 등의 요인에 따라 컴포넌트 로딩 순서가 여러 요인에 따라 달라집니다.
   

이러한 문제를 해결하기 위해 React 컴포넌트를 서버로 옮기는 구상을 하게 됩니다.

컴포넌트가 서버에 있으면 데이터를 미리 가져오고 처리하여 클라이언트에 전달함으로써, 클라이언트는 렌더링에만 집중할 수 있게 됩니다.

따라서 초기 로드 시간을 단축하고 네트워크 효율성을 개선할수 있는 일종의 패러다임의 전환 이라고 볼수 있는데요.

RSC는 다음과 같은 특징이 있습니다.

1. 비동기 호출을 처리해서 컴포넌트가 async 타입이다.

2. 컴포넌트 자체에서 DB에 연결이 가능하다(Express 처럼)

3. console.log를 찍으면 브라우저 콘솔이 아닌 서버 콘솔에 찍힌다.

또한 다음과 같은 주의사항이 있습니다.

• 사용자 인터렉션을 추가할 수 없다(이벤트 핸들러)

• LocalStorage 같은 브라우저 웹 API를 사용할 수 없다.

• 클라이언트 상호 작용과 관련된 것은 클라이언트 컴포넌트를 사용해야 한다.

크롬의 Source탭에서는 클라이언트 컴포넌트 JavaScript 코드를 확인할 수 있습니다. RSC는 서버에서 실행되고 처리되어 Source탭에서는 확인할수 없고 서버의 코드를 직접 확인해야 합니다.

위 내용과 관련하여 더 자세한 내용을 알 고 싶으신 분은 아래 사이트를 방문해서 보시는것을 추천드립니다.

https://www.freecodecamp.org/korean/news/how-to-use-react-server-components/