웹개발은 끊임없이 진화하고 있으며, React 는 이러한 변화의 최전선에 있습니다.
이 다양한 변화중 가장 핵심중 하나는 단언 React Server Components 일 겁니다.
얼마전까지만 해도 웹개발은 대부분의 로직이 브라우저에서 발생하는 클라이언트 측 렌더링에 집중했습니다.
하지만 앱의 크기가 커지면서 클라이언트에서 동작하는 로직의 복잡성이 증가하고 로딩시간을 줄여야 한다는 부담감이 커졌습니다. 이를 CSR 로는 완벽하게 커버하기란 결코 쉬운일이 아니였죠.
그래서 일부 작업을 서버에서 실행하여 성능을 개선할 수 있는 SSR을 채택했습니다.
서버에서 html 을 문자열 형태로 렌더링하여 클라이언트에 전송하는 방식입니다. 오늘날에 많이 쓰이는 방식이죠.
브라우저는 html 만 받아서 hydration 과정을 거친 뒤에 페이지를 그릴 수 있습니다. 그러면 서버에서 가져오는 용량이 굉장히 줄어들었기에 빠르게 화면을 보여줄 수 있었습니다.
하지만 이로써도 부족했습니다. js 번들 크기가 크면 서버에 부담을 줄 수 있고, hydration 과정이 너무 비효율적이였기 때문이죠.
( hydration은 서버에서 한번 렌더링 한 결과물을 클라이언트에서 한번 더 렌더링하여 비교하는 과정이라 실제로 렌더링이 두번 됩니다. )
그래서 CSR, SSR 의 장점을 모두 결합한 형태라고 볼 수 있는 RSC 가 등장했습니다.
RSC 는 말 그대로 서버에서 실행되는 컴포넌트입니다.
서버에서 컴포넌트가 실행되면 JSON 형태의 결과물을 클라이언트에 전달합니다.
이미 모두 서버에서 실행되고 HTML 파일이 아닌 JSON 형태로 클라이언트에 전달되기 때문에 번들 사이즈 걱정이 없습니다.
게다가 정적 HTML 을 전송하는게 아닌 서버에서 직렬화된 UI 트리를 ( RSC payload ) 전송합니다.
그러므로 서버 컴포넌트의 결과물을 react DOM 트리에 삽입만 하면 되기 때문에 클라이언트 단에서 Hydration 를 거칠 필요가 없습니다.
둘다 서버에서 동작하니까 비슷한 개념으로 보일 수 있습니다.
서버에서 동작하는 교집합은 있겠지만 둘은 각자의 역할이 다르고 결과물도 다릅니다.
그래서 굳이 따지자면 별개의 기능으로 보는게 맞습니다.
SSR 은 초기 렌더링 속도와 SEO 최적화에 초점을 맞추고 있는 기능인 반면,
RSC 는 서버에서 동작하는 데이터 페칭, 서버 상태 관리나 이벤트 핸들링을 서버에서 처리에 초점이 맞춰진 기능이라고 볼 수 있습니다. 게다가 RSC 는 SSR 과 다르게 직접 데이터베이스에 접근도 가능합니다.
앞에서 설명했듯이 RSC 는 SSR 과 차별화된 장점을 갖고 있습니다.
정리하자면,
RSC 는 기존의 React 기능들에 비해 비교적 파격적인 변화를 가져왔습니다. 컴포넌트를 서버, 클라이언트를 구분해야하는 복잡성이 늘어난 셈이죠. 게다가 늘어난 복잡성에 비해 개발자에게 친절하지 않습니다.
RSC 를 사용하다보면, 의외로 구분이 어렵습니다. 규모가 큰 서비스의 경우 다양한 컴포넌트이 존재하는데, 아무리 정리를 잘 해놨다고 한들 작업하다보면 이게 서버컴포넌트인지 클라이언트 컴포넌트인지 단번에 파악하기 꽤 어렵습니다.( 지시어만으로는 부족할 수 있습니다 ) 아 이거 RSC 였구나
React 를 사용하는 라이브러리, 프레임워크도 RSC 를 지원하기 위해 많은 노력이 필요합니다. 큰 패러다임의 변화를 가져온 만큼 적응도 잘 해야겠죠. 그 몫은 2차 가공인 라이브러리가 맡습니다. RSC 등장 이후 스토리북이 불타고 있습니다.
이제 React 19 에서 RSC 는 안정화되었음을 발표했습니다.
많은 문제를 해결하기 위해 큰 패러다임 변화를 가져왔고 개발자들은 익힐 필요가 있어 보입니다.
RSC 로 인해 프론트 포지션이 좀 애매해진 느낌도 없지않아 있네요
해당 글에 대한 모든 의견은 환영합니다.