인프런 커뮤니티 질문&답변

안녕하세요 이정환입니다.

우선 waterfall이 아예 발생하지 않을 수는 없습니다. 어떤 방식이든 조금이라도 기다려야 하는 구간이 생길 수 밖에 없기 때문이죠. 따라서 이 문제의 핵심은 특정 시점(예를 들어 FCP 등)까지 얼만큼의 딜레이가 발생해야 하는지를 논하는게 더 중요한 것 같습니다.

먼저 CSR의 경우에는 아래 그림과 같이 강의에서 안내드리고 있는 것 처럼 최초 접속시에 서버와 브라우저가 HTML을 JS Bundle을 받아 실행한 뒤가 되어서야 FCP가 이루어집니다. 이 방식에서는 브라우저가 JS Bundle을 직접 실행할 때 까지 화면이 등장하지 않기 때문에 FCP가 늦어지게 됩니다.

SSR은 CSR의 이런 단점을 해결합니다.

SSR의 경우에는 아래 그림과 같이 서버 측에서 JS를 미리 실행하여 완성된 HTML 페이지를 한방에 브라우저에게 보내주게 됩니다. 그 결과 CSR 방식에 비해 FCP 까지의 시점이 단축됩니다.

추가로 RSC는 FCP를 앞당길 수 있는 기술이 아닙니다. 엄밀히 말하자면 RSC는 클라이언트에게 전달되는 JS Bundle의 용량을 줄이기 위해 사용되어 FCP가 아닌 TTI까지의 딜레이를 단축하기 위한 기술입니다.

이 내용은 우리 강의의 3.4 챕터 "리액트 서버 컴포넌트 이해하기" 에서 아주 자세히 소개하고 있으니 해당 부분을 주의깊게 다시 살펴보시면 어떨까 싶습니다!

안녕하세요, 인프런 AI 인턴입니다. 이준구 님의 질문에 대해 서버 컴포넌트와 SSR의 차이, 그리고 ‘waterfall 문제’에 대해 설명드리겠습니다.

서버 컴포넌트의 등장 및 ‘Waterfall 문제’

Waterfall 문제란 주로 클라이언트 측에서 발생하는 요청의 체인으로 인해 데이터 로딩 및 화면 렌더링이 지연되는 문제를 말합니다. 클라이언트가 데이터 fetching을 각각의 컴포넌트마다 따로 수행하면서 전체적인 성능에 영향을 줄 수 있습니다.

서버 컴포넌트(RSC)는 클라이언트에서는 필요 없는 데이터 로딩을 줄이고 서버에서 데이터 fetching을 미리 수행해 클라이언트에 필요한 HTML과 필요한 데이터만 전달함으로써 이 문제를 해결하려고 도입되었습니다. 이는 클라이언트 측에서는 최소한의 JS 로딩만 담당하게 되어, 초기 로딩 속도를 향상시킵니다.

SSR 방식과의 차이점

SSR(Server-Side Rendering)는 초기 요청 시에 서버에서 페이지를 완전히 그려 클라이언트에 초기 HTML을 제공하는 방식입니다. SSR도 초기 로딩에 유리하나, 이후 상호작용에서는 클라이언트 측 로직이 필요하게 되면서 ‘waterfall 문제’가 여전히 발생할 수 있습니다.

RSC는 서버에서 모든 컴포넌트가 실행되며, 컴포넌트 결과만 클라이언트에 전달됩니다. 따라서 각 컴포넌트의 데이터 fetching이 서버에서 미리 해결되어 데이터를 한번에 같이 내려주게 되어, 사전 요청 처리만으로도 클라이언트 측 로딩 시간을 줄일 수 있습니다.

결론

1. Waterfall 문제는 주로 다수의 데이터를 클라이언트에서 요청할 때 발생하는 병목 현상이며,
   
2. RSC는 SSR을 자연스럽게 확대해 모든 컴포넌트를 서버에서 렌더링한다는 점에서 차별화됩니다. 클라이언트에서 불필요한 자바스크립트 처리를 줄인 것이 RSC의 장점입니다.
   

추가로 확인하고 싶으신 부분은 Next.js 공식 문서나, 관련 강의에서 다뤄진 ‘리액트 서버 컴포넌트 이해’ 단원을 참조하시면 더욱 도움이 될 것입니다.

저는 질문자님의 이해를 돕고자 지식공유자님의 기존 답변을 참고하여 유사한 답변 링크를 추천해드리고 있습니다. 현재 베타 기능으로 답변이 만족스럽지 않을 수 있는 점 양해 부탁드립니다. 🙏 추가적으로 궁금한 점이 있으시면, 이어서 질문해 주세요. 곧 지식공유자께서 답변해 주실 것입니다.