서버 사이드 렌더링(SSR) 쉽게 이해하기 🚀

안녕하세요! 오늘은 웹 개발에서 중요한 개념인 서버 사이드 렌더링(SSR)에 대해 알아보겠습니다. 복잡한 개념을 쉽게 설명해 드릴게요! 😊

SSR이란 무엇인가요? 🤔

서버 사이드 렌더링(SSR)은 서버에서 완성된 HTML을 만들어 클라이언트(브라우저)에게 바로 보내주는 방식입니다. 마치 서버가 차려놓은 완성된 식사를 바로 배달받는 것과 같아요! 🍽️

반면, 클라이언트 사이드 렌더링(CSR)은 서버가 빈 그릇만 주고 레시피(JavaScript)를 함께 보내면, 브라우저가 직접 요리해서 먹는 방식이에요. 🧑‍🍳

간단한 비교 예시

CSR (Client Side Rendering)

서버: "여기 빈 HTML과 JavaScript 코드 줄게요"
브라우저: "알겠어요! 이 JavaScript로 화면을 그릴게요"
사용자: (처음에는 빈 화면을 보다가 점차 콘텐츠가 채워지는 것을 기다림) ⏳

SSR (Server Side Rendering)

서버: "여기 다 만들어진 HTML 페이지예요! 바로 보세요"
브라우저: "감사합니다! 바로 보여드릴게요"
사용자: (즉시 콘텐츠를 볼 수 있음) ⚡

SSR의 장점 ✅

SEO에 유리해요 🔍
- 검색엔진 크롤러가 완성된 HTML을 바로 읽을 수 있어 검색 결과에 더 잘 노출됩니다.
초기 로딩 속도가 빨라요 ⚡
- 사용자는 JavaScript를 다운로드하고 실행할 때까지 기다릴 필요 없이 바로 콘텐츠를 볼 수 있습니다.
저사양 기기에서도 좋은 경험 📱
- 클라이언트 기기에서 많은 JavaScript를 실행할 필요가 없어, 성능이 낮은 기기에서도 잘 작동합니다.

SSR의 단점 ⚠️

상호작용 지연 ⏱️
- HTML은 빨리 보이지만, JavaScript가 로드될 때까지는 버튼 클릭 등의 상호작용이 안 될 수 있어요.
- TTV(Time To View)와 TTI(Time To Interact) 사이에 간격이 생깁니다.
서버 부하 증가 🖥️
- 매 요청마다 서버에서 페이지를 생성해야 해서 서버 리소스를 더 많이 사용합니다.
개발 복잡도 🧩
- 서버 코드와 클라이언트 코드를 구분해서 관리해야 하므로 개발이 조금 더 복잡할 수 있습니다.

정리 📝

SSR은 서버에서 미리 HTML을 만들어 보내주는 방식으로, 초기 로딩 속도와 SEO에 장점이 있지만 서버 부하와 상호작용 지연이라는 단점도 있습니다. Next.js와 같은 현대적인 프레임워크는 SSR과 CSR의 장점을 모두 활용할 수 있게 해주어, 데이터센터 관리 소프트웨어와 같은 복잡한 애플리케이션에서도 최적의 사용자 경험을 제공할 수 있습니다.

어떤 방식이 더 좋은지는 프로젝트의 특성에 따라 달라지니, 상황에 맞게 선택하세요! 😊

SSR(Server Side Rendering)에 대해 설명해주세요.

SSR(Server Side Rendering) 방식은 서버에서 완성된 정적 HTML을 클라이언트에 내려주는 방식입니다. 클라이언트 측에서는 해당 HTML을 파싱만 하여 화면을 그리게 됩니다.
반면, CSR(Client Side Rendering) 방식은 브라우저가 서버로부터 비어있는 뼈대 HTML을 받아온 후, 필요한 자바스크립트 번들을 다운로드하고 번들을 실행하여 동적으로 컨텐츠를 채우는 방식입니다.

Next.js에서는, SSR 방식으로 정적인 html을 내려주어 초기 화면을 빠르게 렌더한 이후, hydration을 통해 이벤트 리스너 부착 등의 자바스크립트 작업을 수행하여 정적인 화면을 동적으로 전환하는 작업을 수행하기도 합니다.

SSR의 장점은 무엇인가요? 🤔

SEO(검색 엔진 최적화) 측면에서 유리합니다. 화면이 동적으로 그려지는 CSR에 비해 크롤러가 컨텐츠를 쉽게 인식하며, 초기 로드가 상대적으로 빨라 우선순위가 부여되어 상위에 노출될 가능성이 높아지기 때문입니다. 이런 점에서 SSR은 블로그나 커머스 등 SEO가 중요한 웹 애플리케이션에 특히 적합합니다.
또한, SSR 방식에서는 사용자가 빠른 초기 로딩 속도를 경험할 수 있습니다. CSR과 달리 SSR에서는 번들을 다운로드 받거나 번들을 실행하여 동적으로 화면을 그려야 할 필요가 없기 때문입니다.

SSR의 단점은 없나요? 🧐

전통적인 SSR 방식에서는 클라이언트 사이드 라우팅이 불가능하기 때문에 빠르고 매끄러운 페이지 전환 경험을 제공하기 어렵습니다. 또한, 단순히 정적인 리소스를 내려주는 것이 아니라, 요청 시마다 페이지를 동적으로 구성해서 내려주어야 하는 경우에는 WAS 서버 구동으로 인해 서버 비용이 증가할 수 있다는 단점이 있습니다.

Next.js를 통한 최신의 방식으로 SSR을 구현할 경우에는 다음과 같은 단점이 있습니다.
첫째, hydration을 통해 동적인 화면으로 전환할 경우 상호작용 초기화가 비교적 느립니다. 이는 페이지가 표시되기까지 걸리는 시간(TTV)과 상호작용까지 걸리는 시간(TTI) 사이에 격차가 발생한다는 의미입니다. 그 사이에 사용자가 버튼을 클릭해도 동작하지 않는 등의 답답한 상황을 겪을 수 있습니다.
둘째, 상대적으로 구현 복잡도가 높습니다. 현대의 웹앱은 SSR과 CSR을 동시에 사용하는 경우가 많습니다. 이때 클라이언트 사이드 로직과 서버 사이드의 로직을 구분해가면서 구현해야 하기 때문에 상대적으로 구현 복잡도가 높습니다.

728x90

저작자표시 (새창열림)