CSR(Client-Side Rendering)에 대해 알아보라는 제안을 받았다. 그 내용이나 특징에 대해서 이미 알고는 있었으나, 이렇게 글로 정리해본 적은 아무래도 처음인 것 같다. 스스로에게 알고 있던 것을 복기하는 의미있는 시간이 되기를 바라며 정리해본다.
Client-Side Rendering, CSR
우선 렌더링(Rendering)이란 표현을 먼저 짚고 넘어가야 한다. 크게 개발에서 쓰이는 렌더링(Rendering)은 시각적으로 그려내고 구체화하는 일련의 과정들을 통칭한다. 이를 테면, 내가 Davinci Resolve 라는 후처리 비디오 애플리케이션을 이용해서 일상을 담은 녹화본을 이어붙이고 반짝이는 특수효과를 넣은 뒤, 하나의 mp4파일로 저장한다고 하자. 그렇다면, 그 과정 역시 렌더링이다.
Davinci Resolve와 Visual Studio Code.
외관은 둘이 많이 다르지만, 결국 둘 다 '렌더링'이란 표현을 사용한다. 결과물을 구체화하는 점에선 동일하니까..
웹 개발에선 mp4가 아니라 웹 페이지가 렌더링 할 목표가 된다. 그런데 렌더링을 할거면 그냥 하면 될텐데, '클라이언트 쪽에서(Client-Side)'나 '서버 쪽에서(Server-Side)'라는 말이 붙어있다. 렌더링을 할 때 어디에서 할 건지 개발하는 과정에서 고르는 셈이다. 분명 둘 사이에 차이가 있으니 고르는 것일 터이다. (...)
이 글에선 '클라이언트 쪽에서 렌더링(Client-Side Rendering, CSR)'에 대해서 이야기하기로 한다. '서버 쪽에서 렌더링(Server-Side Rendering, SSR)'은 아마도 다음 글에서 이야기할 것이다.
CSR의 과정
우리가 보는 웹 페이지는 불러와야 할 것들이 정해져있다. 기본적으로 HTML, CSS, JavaScript를 불러올 것이며, 커뮤니티 사이트라면 유저들이 작성한 글 데이터들을, 통계 사이트라면 통계 데이터, 기상 예측이나 공공 정보를 관측하는 사이트라면 그러한 공공 데이터를 호출해서 페이지 요소에 조합할 것이다.
'CSR'은 이 과정을 사용자(Client, 쉽게 생각하면 사이트 이용자)측에서 처리한다. 사용자측에서 '서버(Server)'에 페이지를 보고 싶다고 요청하면, 서버가 페이지를 '렌더링'하는데 필요한 것을 보내주는 것으로 응답한다. 사용자가 HTML, CSS와 JavaScript를 받고 그걸 기반으로 화면에 렌더링을 하게 된다. 여기서 상기했듯, 사이트의 성격에 따라 필요한 데이터가 있을 것이고 JavaScript로 그 데이터를 불러와 페이지 요소에 조합한다.
출처: The Benefits of Server Side Rendering Over Client Side Rendering
CSR을 SSR과 비교했을 때의 특징
-
빠르다.
말 그대로 빠르다. 금방금방 그려서 눈 앞으로 가져다준다. 허나 분명히 짚고 넘어가야 할 것이 있는데, 눈에 보이는 걸 빠르게 가져다주는 건 맞으나 데이터는 아닐 수도 있다. 앞서 언급하기로 '사이트의 성격에 따라 필요한 데이터'가 있을 수 있다고 했고, 이걸 스크립트로 호출하는 과정이 남아있기 때문이다. -
서버가 편하다.
서버 측에서는 페이지 요청을 받고, 페이지 구성 요소와 데이터 응답하는 일을 이미 하고 있다. 렌더링을 사용자가 해준다고 하면 서버는 데이터- 그리고 대게 이런 데이터는 반복해서 불러야 하는 경우가 잘 없다 -만 보내주면 되니 그만큼 서버에 걸리는 부하가 적다. 한두명이 이용하는 트래픽 정도로 서버에 기별이 갈까 싶지만, 사이트 이용자가 정말 많은 곳이라면 상용 서버로도 부담일 것이고 계산기를 두드리느라 바쁠테니.. 상대적으로 부하가 적게 걸릴 것이라는 것도 분명하게 장점이다. -
검색 엔진이 잘 '긁지' 못한다.
페이지마다 다를 것이다. 서버에 다른 것 없이 정말로 마크다운 요소들이 들어차있는 HTML, CSS, 사이트에 쓸 JavaScript가 올라가있고, 요청하면 그걸 보내주는 사이트라면 검색 엔진이 긁을 수 있을 것이다. (이미 마크다운이 적혀있으니까, 적어도 사이트 메뉴와 같은 이용 수칙등은 문제없이 긁지 않을까) 하지만, 요즘 그런 사이트는 잘 없고, 웹 개발 프레임워크를 이용하는 곳이 다수이다.이 중 CSR방식으로 작동하는 프레임워크(예: React.js)라면 지금 말하는 애로사항이 발생한다. 이런 프레임워크는 '첫 번째'로 JavaScript를 불러와서 페이지를 프레임워크에서 지정한 대로 구현하는데, 이 '첫 번째' 로 불러올 때 HTML은 요소가 없이 비어있기 때문이다. 검색 엔진은 이걸 가지고 내용이 없는걸로 생각해버린다.
2023. 06. 23. 수정:
모든 CSR 방식의 페이지가 SEO하고 상극은 아니었다. 일례로 구글 봇도 개발자가 필요한 작업을 수행하고 나면, CSR 방식 페이지라 해도 수집해갈 수 있다.
출처: 자바스크립트 검색엔진 최적화의 기본사항 이해하기 - Google for Developers
아니 공부할 게 끝이 없어.. -
부담은 사용자에게.
사이트를 보겠다고 결심한 이상 렌더링은 어느 쪽에서든 하긴 해야한다. 그런데, 서버에서 안하는 거라면 사용자가 해야 한다. 그럼 부담은 사용자가 받는다. 물론, 서버처럼 서버에 들어오는 모든 일을 다 맡는 건 절대 아니다. 지금 이용하는 사용자 본인 하나 분량만 본인 기기에서 부담하면 될 뿐이다. 이 점은 사용자 기기의 역량에 따라 달라지는데, 기기가 연식이 오래됬거나 장시간 사용하면서 노후되어 있다면 렌더링을 처리하는데 더 힘겨워 할 수 있다. (...)세대가 변할 수록 기기 성능은 점점 더 좋아지고 있으니 사실상 지금에선 논할 의미가 없는 문제가 아니겠냐고 물을 수도 있겠다. 하지만, 사이트에 들어온 모든 사용자의 기기가 신식이라고 보장할 수 있는가? (이 문제를 확장한다면, 사용자가 쓰는 브라우저와 스크립트 호환까지 논하게 된다.)
출처: Installed Base Data Testifies to iPhone 12’s Stellar Performance
아이폰 8과 X의 출시는 2017년 하반기였다. 2021년에도 절반 가까이가 4년은 되가는 구형(?) 스마트폰을 사용하고 있다.
다시 물어보자, 정말로 모든 사용자의 기기가 신식이라고 장담할 수 있는가?
결정은 수시로 바뀔 수 있다
렌더링 방식을 결정하는 것이 "이게 좋으니 이것을 써야 한다!"의 문제는 아니다. 필요에 따라서 한 방식을 선택하는 문제이지. 다만, 하나에 익숙해지면 다른 것으로 넘어가기 싫은 것이 인간의 본성이기도 하고(경로의존성), 교체나 변화에 투입되는 비용도 무시할 수 없는 것이고. CSR과 SSR도 각각의 특징에 각 개발팀과 개발자들의 '이런저런' 사정이 조합되어서 골라지는 것들 중 하나가 아닐까.. 정도로 생각해본다.
반박할 시 당신의 말이 맞습니다, 네.
웃음을 유발하고자 하는 이야기가 아니라, 교정이 필요하거나 틀린 부분을 배우고 수정할 수 있도록 여러분들의 발언을 부탁드리는 것입니다. 혼자서 공부할 때의 가장 큰 문제는 '한 번 모르는 건 (거의) 영원히 모른다.' 는 것입니다. 당장 거울이 없으면 자기 얼굴도 볼 수 없고, 거울 두 개가 없으면 자기 이면인 등을 볼 수도 없는 것이 인간(을 포함한 동물)입니다.
제 벨로그를 찾아와 읽어주시는 여러분의 의견에 미리 감사드립니다.
