하지만 이미지가 너무 많아서 렌더링이 느리고, 검색 엔진에서 찾기 쉽게 하는 SEO 작업에 제한이 있다는 것을 알게 됐다.
이러한 이유로 더 빠른 렌더링과 SEO를 위해 Next.js로 마이그레이션을 하기로 결정했다.
1차 스프린트를 React+TS로 마무리하고, 이 프로젝트를 Next로 마이그레이션 후 2차 스프린트를 진행하는 순서로 진행중이었는데, 한 선생님께서 질문을 하셨다.
분명 난 이유가 있어서 마이그레이션을 하기로 결정한건데, 질문에 대답을 잘 못하는 모습을 보고 다시 공부해야겠다는 생각이 들어 이렇게 글을 적는다.
SSR이란?
분명 뭔지 알고, 공부했었는데 대답을 잘 못해서 다시 공부했다.
Server Side Rendering의 약자로
렌더링부터 적자.
렌더링이란?
서버에서 HTML을 생성하고 클라이언트에 전달하는 과정.
서버는 클라이언트의 요청에 따라서 HTML을 동적으로 생성하고, 이를 클라이언트에 전달한다.
클라이언트는 받은 HTML을 파싱하여 문서 객체 모델인 DOM을 생성한다.
*DOM: HTML 문서의 구조와 내용을 표현한 트리 구조
클라이언트는 DOM을 기반으로 렌더링 엔진을 사용하여 HTML 요소를 화면에 paint 하고, css 스타일을 적용하며 JS 이벤트를 처리. 이 과정을 통해 사용자에게 보여지는 최종적인 화면이 생성되어 표시되는 것이 렌더링이다.
이러한 렌더링 방식은 크게 2가지가 있는데, CSR과 SSR로 나뉜다.
CSR이란?
Client-Side Rendering의 약자로 클라이언트 측에서 동적으로 웹 페이지를 렌더링하는 방식
CSR의 과정
- 클라이언트 초기 요청에 대해 서버로부터 정적인 HTML 파일 수신
- 클라이언트는 받은 HTML 파싱 => JS 코드를 로드하여 데이터 수신, 동적인 화면 요소 생성, 이벤트 처리
- JS 코드는 서버로부터 필요한 데이터를 비동기적으로 요청하고, 데이터를 수신하여 화면에 적용
- 데이터를 받아 화면에 적용되면 클라이언트는 JS를 사용하여 동적으로 화면을 업데이트하고 렌더링 => 이 때, HTML 요소들이 생성되고, 스타일이 적용되며, 사용자와 상호작용을 처리한다.
SSR이란?
Server-Side Rendering의 약자로 서버 측에서 웹 페이지를 동적으로 렌더링하는 방식
SSR의 과정
- 클라이언트가 서버에 웹 페이지 요청 전송
- 서버는 요청에 필요한 데이터를 DB, API 등에서 가져옴
- 가져온 데이터를 HTML과 결합하여 최종 HTML 생성(동적인 데이터 포함 가능)
- 생성된 HTML을 클라이언트에게 응답으로 전송
- 클라이언트는 받은 HTML을 파싱하여 DOM 생성 후, 화면 렌더링
- 즉
클라이언트에서 요청이 들어올 때마다 서버사이드에서 그에 맞는 HTML을 만들어 응답으로 보내주는 것
React와 차이점
React는 JS 라이브러리로, 하나의 HTML파일에 여러 컴포넌트로 구성된다.
컴포넌트는 JS이지만, JSX라는 문법을 사용하여 JS코드 안에 HTML과 유사한 구조로 작성한다.
React의 과정
- 루트 컴포넌트가 진입점 역할을 수행하며, 전체 구조와 동작을 결정
- 루트 컴포넌트가 React의 유일한 HTML 파일에 마운트
* 마운트 : 컴포넌트가 브라우저의 실제 DOM에 추가되고 화면에 표시(렌더링)되는 것
- 다른 컴포넌트를 생성하면 부모-자식 관계를 형성하며 컴포넌트 트리 생성 => 루트 컴포넌트가 최상위
- 생성된 트리를 기반으로 Virtual DOM 생성
- 가상 DOM을 생성하고 이전 실제 DOM과 비교하여 변경된 부분을 식별하고, 해당 부분만을 업데이트
- 즉, 요청에 맞게 알맞는 컴포넌트를 렌더링
React는 Virtual DOM을 활용하여 변경된 부분만을 업데이트하기 때문에 렌더링이 효율적이다.
초기에 한 번만 HTML파일을 로드하고, 이후에는 필요한 데이터만을 서버로부터 비동기적으로 받아와 동적으로 화면을 갱신하는 SPA방식이다.
FE Build란?
작성한 코드를 최적화하고, 번들링하며, 배포 가능한 형태로 변환하는 작업
* 번들링: 여러 파일을 하나의 번들 파일로 결합하는 과정, 의존성 문제 해결 및 요청 수 저하로 로딩 속도 개선 가능
보통 서비스 배포 전 수행되며, 최적화된 코드를 배포하여 사용자에게 빠른 로딩 속도와 사용자 경험 제공 가능
번들링 하여 생성된 파일은 정적 파일이다.
정적 파일이란?
웹 서버에 미리 저장되어 있는 파일로, 클라이언트에게 전달되는 파일.
웹 애플리케이션의 구성 요소로 사용되며, 서버에서 동적으로 생성되거나 변경되지 않음
HTML, CSS, JS 등등
클라이언트는 웹 서버에 동기, 비동기적으로 요청하여 파일을 전달받는다.
동적 파일이란?
WAS 서버에서 클라이언트의 요청을 받으면 필요한 동적 파일을 생성하여 데이터를 포함시킴
요청에 의해 생성된 동적 파일을 클라이언트에 응답으로 전송
매번 요청에 따라 실시간으로 생성되기 때문에, 서버의 자원과 성능에 영향을 미침
WEB & WAS
WEB 서버란?
클라이언트의 요청을 받아들이고, 그에 따른 정적파일을 제공하는 역할
사용자가 웹 페이지의 URL을 입력하거나 클리하는 등의 동작을 통해 웹 서버에 요청을 전송
웹 서버는 요청에 맞는 응답(HTML, CSS, JS)을 보내주면 클라이언트는 웹 페이지로 해석하여 표시
즉, 웹 서버는 요청을 받아들여 처리하고, 클라이언트는 서버에 요청을 보내고 응답을 받아 표시함으로써 사용자에게 웹 페이지를 제공
프론트엔드 서버 = WEB 서버
WAS 서버란?
웹 애플리케이션의 실행 환경을 제공하는 서버
클라이언트의 요청에 따라 동적인 처리 수행 및 로직 실행
서버 측 스크립트나 서버 측 언어를 실행하여 동적 파일을 생성하고, DB와 상호작용 처리
이때, 백엔드는 WAS에서 실행되는 서버 측 코드로서, 웹 애플리케이션의 비즈니스 로직과 데이터 처리를 담당하며 기능을 구현
백엔드 서버 = WAS 서버
위 내용들을 종합해보면
React === CSR === SPA === 정적 파일을 요청하여 받아옴 === WEB 서버
Next === SSR === 요청 마다 동적으로 파일을 생성해서 넘겨줌 === WAS 서버
CSR은? 데이터를 받아오는데 데이터가 클수록 로딩하는 시간이 길다!
SSR은? 내용은 바로 볼 수 있지만, HTML을 동적으로 생성하는 시간이 길다!
결론: React나 Next나 프로젝트 크기가 동일하면 사용자가 브라우저에 접속하여 대기하는 시간이 비슷하다.
마이그레이션을 하는 가장 큰 이유 중에 하나가 렌더링 시간 감소였는데, 제대로 공부하고 내린 결정이 아니라 SSR이 더 바르대~ 하는 얘기만 듣고 마이그레이션을 결정했더니 이런 사태가 발생했다....
그럼 해결법이 없을까? 하고 여쭤보니
어떻게 빠르게 만들 수 있는지, 왜 빠른지를 알아보고 했어야했다.
그냥 빠르다는 얘기만 듣고 SSR 방식만 사용했더니 실제로 렌더링 시간에 큰 차이를 체감하지 못했다.
해결법을 알려주셔서 공부해서 적용해보려고 한다.
📌 느낀점
프로젝트를 단순하게 만드는 것 만을 목표로 하지 않고, 설계부터 잘 해야겠다는 생각이 들었다. 왜 이 라이브러리를 사용하는지, 왜 이런 방식을 써야하는지 알고 써야되는데, 모르면서 그냥 사용해서 만들기만 하니까 프로젝트가 마무리 되고 나서 받는 질문에 대답을 못하는 상황이 발생했다.
내가 개발자로 취업을 목표로 한다면, 앞으로는 위와 같은 상황을 방지하기 위해 이론적으로 공부해서 알고 프로젝트를 진행해야겠다는 생각이 들었다.😢
