[Fluent React] 서버 사이드 리액트

전문가를 위한 리액트(Fluent-React)를 읽고 서버 사이드 리액트에 대해 정리합니다.

리액트는 클라이언트 사이드 라이브러리로 시작했습니다. 이 방식은 웹 생태계에 성능이 뛰어나고 반응이 빠른 사용자 경험을 구현했습니다. 하지만 웹이 발전함에 따라 클라이언트 사이드 렌더링의 한계가 명확해졌습니다.

1. CSR의 한계

1-1. SEO

CSR의 가장 큰 한계 중 하나는 검색 엔진의 크롤러가 JS를 실행하지 않아 콘텐츠를 색인하기 어렵다는 점이었습니다. 실행되더라도 예상대로 실행되지 않을 수 있어 콘텐츠를 올바르게 색인할 수 못할 수 있습니다.

이는 검색 엔진의 크롤러의 구현 방식이 다양하고, 상당수가 폐쇄적이며 공개되지 않아 더욱 명확하지 않은 부분이 되었습니다.

2015년 검색 엔진 랜드가 기사를 통해 다양한 검색 엔진이 CSR 앱에서 어떻게 동작하는지에 대한 실험에 대해 밝혔는데,
일련의 테스트를 통해 구글이 다양한 구현 방식으로 JS를 실행하고 색인할 수 있다는 사실을 확인했습니다. 또한, 구글이 전체 페이지를 렌더링하고 DOM을 읽어 동적으로 생성된 컨텐츠를 색인할 수 있다는 사실도 확인했습니다.

위 기사는 구글과 빙(Bing)이 CSR 앱을 색인할만큼 발전했다는 것을 나타내지만, 방대한 비공개 지식의 조각에 불과한 연구 프로젝트일 뿐, 아직 우리가 알지 못하는 부분이 훨씬 큽니다

1-2. 성능

CSR 앱은 클라이언트에서 렌더링되기에, 느린 네트워크 환경이나 낮은 성능의 기기 환경에서 문제를 겪을 수 있습니다.

이는 넓은 관점에서 다시 보면, CSR 앱의 SEO와 성능 최적화 문제는 웹 표준과 모범 사례를 준수하는 것이 얼마나 중요한지 다시 보여줍니다. 특히 콘텐츠가 많은 앱의 경우, 성능이 뛰어나고 접근성이 좋은 방식으로 컨텐츠를 제공하고자 할 때 SSR, 혹은 SSG가 더 신뢰할 수 있는 대안임을 가르키고 있습니다.

 

또한, 사용자 경험 전체가 CSR의 JS로만 구성되는건 웹의 설계 의도에 부합하지 않습니다. JS의 역할은 웹 페이지를 보완하고 개선하는 것이지, 그 자체가 되어버리는 것이 아닙니다.

CSR 앱의 네트워크 워터폴

CSR 앱에서 흔히 나타나는 네트워크 워터폴입니다. 네트워크 연결이 제한적인 경우에는 애플리케이션이 상당한 시간동안 응답이 전혀 없을 수 있습니다. SSR을 이용하면 사용자가 컨텐츠를 즉시 볼 수 있도록 개선할 수 있습니다.

SSR 앱은 사용자가 컨텐츠를 즉시 볼 수 있도록 개선합니다.

필요한 데이터를 가져와 서버에서 렌더링했기 때문에 처음 페이지를 로딩하는 순간부터 컨텐츠를 담고 있습니다. 네트워크 워터폴이 존재하지 않으며, 사용자는 모든 정보를 즉각적으로 얻습니다.

 

하이드레이션을 기다리는 HTML이 생각나서 가져왔습니다.

하지만 SSR된 HTML은 정적이며, JS를 불러오지 않은 상태여서 상호 작용 지원이 부족합니다. 사용자 상호 작용을 비롯한 동적 기능을 활성화하기 위해, 필요한 JS를 정적 HTML에 "촉촉"하게 공급해주어야 합니다. 하이드레이션이 필요합니다.

2. 하이드레이션

하이드레이션은 서버에서 생성되어 클라이언트로 전송되는 정적 HTML에 이벤트 리스너와 여러 JS 기능을 추가하는 프로세스를 의미하는 용어입니다. 하이드레이션의 목적은 브라우저가 서버 렌더링 애플리케이션을 읽어 들인 후 여기에 상호 작용을 추가해서 사용자에게 빠르고 원활한 경험을 제공하는 것입니다.

 

리액트는 하이드레이션 과정을 통해 정적 HTML의 DOM 구조를 리액트 컴포넌트의 JSX 구조와 일치시킵니다. 이 부분은 매우 중요한데, 불일치하면 리액트는 이벤트 리스너를 올바르게 연결할 수 없으며 리액트 엘리먼트가 어떤 DOM 엘리먼트에 직접 매핑되어야 하는지 인식하지 못해 애플리케이션이 예상대로 동작하지 않게 됩니다. (이를 "하이드레이션 에러"라고 부릅니다)

 

2-1. 하이드레이션에 대한 비판

하이드레이션 과정

일부는 하이드레이션이 필요 이상으로 느리다며, 재개 가능성(resumability)을 대안으로 꼽습니다. 하이드레이션은 SSR의 결과물로 HTML을 렌더링한 후 JS 번들을 다운로드, 이벤트 리스너를 추가하는 작업을 거쳐야 합니다. 많은 작업을 필요로 하며 콘텐츠가 표시되는 시점과 사용자가 실제로 사이트를 사용할 수 있는 지점 사이에 지연이 발생할 수 있습니다.

재개 가능성 과정

재개 가능성을 활용하면 전체 앱이 서버에서 렌더링되고, 브라우저로 스트리밍됩니다. 여기서 하이드레이션과 다른 점은, 모든 인터렉티브 동작이 직렬화되어 브라우저에 전송된다는 점입니다. 이 동작들은 하이드레이션 없이 역직렬화 후 반응합니다. 이로 인해 TTI(Time to Interactive)가 짧아집니다.

 

위와 같은 재개 가능성에 장점이 있음은 자명하지만, 구현에 따르는 복잡성을 감수할 가치가 있냐고 개발자 커뮤니티는 묻습니다. 하이드레이션보다 더 복잡한 접근 방식이며, 장점이 비용보다 더 큰지는 명확하지 않습니다. 인터렉티브 시간이 몇 밀리초 빠르긴 하지만, 복잡성을 감수하면서 재개 가능성을 구현할 가치가 있는지는 아직 논란이 되고 있습니다.