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

종민님, 안녕하세요! 질문 남겨주셔서 감사합니다.

1. SSR 방식에 서버 컴포넌트와 클라이언트 컴포넌트를 둘 다 적절히 사용하는 것인가요??

SSR 방식은 서버 컴포넌트와 다른 방식입니다. 서버에서 컴포넌트를 렌더링한다는 점에서는 동일하지만 렌더링의 결과값과 동작 방식이 다릅니다.

SSR은 Prerendering의 방식으로 서버에서 HTML을 만들어냅니다. 이후에 클라이언트로 전달된 JS 번들 파일과 수화되는 과정을 거쳐 React 컴포넌트로 사용됩니다. 기존의 React 컴포넌트이며 이를 클라이언트 컴포넌트라고 부릅니다.

서버 컴포넌트는 JSON과 유사한 형태가 만들어집니다. 그 자체로 React 컴포넌트이기에 별도의 JS 번들 파일 없이 브라우저에서 컴포넌트로 사용됩니다. 새로운 컴포넌트이고 React Server Component, RSC라고 부릅니다.

두 가지를 함께 사용하는 경우는 서버 컴포넌트가 Children 요소로 클라이언트 컴포넌트에게 전달되는 경우일 것 같아요. 이때 모든 컴포넌트가 서버에서 렌더링되어 브라우저로 전달됩니다. 이후의 동작은 클라이언트 컴포넌트와 서버 컴포넌트가 다르지만 모두 서버에서 렌더링 되어 HTML, JSON 형태로 브라우저에 전달됩니다. 이러한 특성을 기억해서 알맞게 적절히 사용하는 것이 옳은 사용 방법이 될 수 있을 것 같습니다.

2. 서버 컴포넌트는 데이터 페칭, 보안, 캐싱, JS 번들크기 감소와 같은 장점이 있고 event와 hook을 사용하지 못한다는 특징도 이야기해주셨는데, 그렇다면 데이터를 받아서(페칭해서) 클라이언트 컴포넌트에 데이터를 뿌려주는 느낌으로 조합해서 사용하는 건가요??

"클라이언트 컴포넌트에 데이터를 뿌려주는 느낌"이라는 표현이 정확하게 이해가 되진 않았지만 나름의 해석을 붙여 답변드려볼게요!

서버 컴포넌트가 클라이언트 컴포넌트에 전달하는 데이터는 없고 그 자체로 컴포넌트의 역할을 합니다. 다만 앞선 답변에서처럼 Children 요소로 활용된다면 어떤 점에선 데이터를 전달한다고 볼 수도 있을 것 같습니다. 쉽게 표현하자면 클라이언트 컴포넌트의 구성 요소 중 하나로 서버 컴포넌트를 끼워 넣을 수 있다고 봐도 좋을 것 같아요.

서버컴포넌트는 event를 사용하지 않으므로, TTI를 개선하기 위해 나온 개념은 아닌거죠???

말씀주신 것처럼 서버 컴포넌트는 이벤트를 사용할 수 없기 때문에 컴포넌트 그 자체로 TTI에 직접 영향을 주진 못할 수 있습니다. 하지만 생각해보면 JS 번들 크기를 줄이는데 도움을 주기 때문에 전체적인 성능 개선에 영향을 줍니다. 그 결과 TTI에도 긍정적인 영향을 줄 수 있습니다.

애초에 서버 컴포넌트가 나온 이유에 대해 간단히 설명드려보겠습니다. 서버에서 미리 렌더링하는 Prerendering의 경우 페이지 단위로만 SSR, SSG를 수행할 수 있었어요. 서버 컴포넌트는 페이지 단위가 아닌 컴포넌트 단위로 서버에서 렌더링할 수 있도록 하기 위한 고민 끝에 나온 개념입니다. 그 결과 앞서 답변 드린 것처럼 클라이언트 컴포넌트와 혼용해서 쓸 수 있는 새로운 방식이 가능해진 것입니다.

관련해서 읽어보시면 도움될만한 글을 남겨두겠습니다! 제가 참고한 내용을 인용해뒀습니다.

Making Sense of React Server Components - Specifying client components

As a general rule, if a component can be a Server Component, it should be a Server Component. Server Components tend to be simpler and easier to reason about. There's also a performance benefit: because Server Components don't run on the client, their code isn't included in our JavaScript bundles. One of the benefits of the React Server Components paradigm is that it has the potential to improve the Page Interactive (TTI) metric.

일반적으로 컴포넌트가 서버 컴포넌트가 될 수 있다면 서버 컴포넌트가 되어야 합니다. 서버 컴포넌트는 더 간단하고 추론하기 쉬운 경향이 있습니다. 서버 컴포넌트는 클라이언트에서 실행되지 않기 때문에 자바스크립트 번들에 코드가 포함되지 않는다는 성능상의 이점도 있습니다. React 서버 컴포넌트 패러다임의 장점 중 하나는 페이지 인터랙티브 (TTI) 지표를 개선할 수 있는 잠재력이 있다는 것입니다.

많은 분들이 혼란스러워하는 부분이라 종민님의 질문이 다른 수강생분들께 도움이 되었을 것 같아요.
질문 주셔서 감사합니다. 다른 질문도 언제든 환영입니다! 편하게 남겨주세요 😃

와 안녕하세요 종민님, 조은님 두분의 질의응답 덕분에

이해되지 않던 부분들을 이해하게 되었습니다.

감사합니다 ^_^b

여기 맛집이네

네트워크탭을 확인해봤을 때, Next.js의 첫번째 요청이나 새로고침시에는 pre-rendering한 HTML 파일을 받아오는데, 그 이후부터는 RSC Payload 형태의 JSON 데이터만 받아오게 되는데 이것이 Next.js가 SPA라는 뜻일까요??

hard navigate시에만 HTML을 받아오게 되고, soft navigate시에는 JSON 형태의 데이터를 받아오게 되는게 맞을까요 (즉, SPA의 동작을 하게 되는건가요??)

선생님 추가로 질의드릴 부분이 생겼습니다!
네트워크 탭을 통해 라우팅으로 이동하게 되면 RSC Payload를 응답으로 받는다는 사실을 알게 되었습니다.
Server Component는 서버에서 실행되었기 때문에 RSC Payload 상에 데이터가 있지만 Client Component는 참조의 형태로 남아있는 것으로 이해했는데, 그렇다면 Client Component는 렌더링 시에 hydration 작업이 별도로 이뤄지는 것인가요??