오늘은 동적인 페이지를 파싱해야 할 일이 있었다.
평소와 같이 BeautifulSoup4를 사용해 크롤링하려던중, 페이지의 엘리먼트와 크롤링해온 html이 서로 다름을 알고 이상하게 여겨 찾아보니 동적인 페이지란것을 알게되었다.
스승께 이러한 일이 있었음을 보고하니 CSR과 SSR에 대해 설명해 주었다.
클라이언트사이드렌더링(CSR)과 서버사이드렌더링(SSR)은 일종의 렌더링방식이다. 말하자면 화면에 페이지를 출력해주는 방법의 차이에 따라 두개를 나눈것이다.
전통적인 방식은 SSR이다. 브라우저에 나타나는 형태 그대로를 HTML로 만들어 제공하고, 브라우저는 HTML을 표시하는 방식이었다. 하지만 정보의 양이 늘어나면서 성능적인 문제가 드러난다. 매 요청시마다 새로고침이 발생하고 트래픽을 잡아먹는다.
그에반해 CSR은 필요한 정보만을 호출한다. 서버는 단지 JSON파일만 보내주고, html을 그리는 역할은 자바스크립트를 통해 클라이언트 측에서 수행한다.
하지만 무조건 CSR이 좋고 SSR이 나쁘다는 것은 아니다. 각자의 상황에 따라 적당히 혼용할수 있으며, 각자가 가지고 있는 장,단점이 부각되기때문이다.
우선 SSR의 가장 큰 이점은 노출이다. 하나의 코드에 모든 정보가 담겨있으니 외부 검색엔진에 노출이 용이한것이다. 또, 첫렌더링된 html을 사용자에게 전해주기때문에 로딩속도를 줄일 수 있다. 후술할 CSR의 단점에 비해, 로딩이 되기전 사이트를 이용할수 있다. 추가로 서버에서 약간의 계산을 도와줄 수 있다.
하지만 SSR은 결국 페이지마다 일일히 전부를 로딩해오기 때문에 실질적으론 조금 느리고, 코드를 하나로 관리하기 때문에 복잡함을 야기할 수 있다. 단, 이는 단점이라고 단정내리기 힘든 게 프론트와 서버 코드를 따로 관리하는게 편할수도, 혹 아닐수도 있는 상황이 있기때문이다.
반면, CSR은 분리되어 있는 코드가 개발에 용이할 수 있다. 또 각 페이지를 호출시, 최초의 1회를 제외하면 필요한 정보만을 가져오기 때문에 성능의 우위에 서있다. 이러한 점덕분에 트래픽도 감소하고, 새로고침이 발생하지않는 부드러운 경험을 안겨준다.
하지만 CSR은 최초의 1회 로딩이 완료될때까지는 서비스를 이용할 수 없다.J자바스크립트 파일을 번들링해서 한 번에 받기 때문이다. 그리고 오늘 겪은 큰 단점은 중요한 정보들은 필요에 따라 요청해 불러오기 때문에 공백상태로 있다는 것이다. 이는 검색노출에 큰 불리함을 안겨준다.
필요와 상황에 따라 둘을 적당히 혼용하는 방법을 찾아야겠다.
