저번 글에서 CSR에 대해 간단히 복기하면서 SSR은 다음에 알아보겠다고 말을 남겼었다. 지금 쓰는 글이 그 '다음'일 것 같다. 그에 더해, 단일 페이지 어플리케이션(Single-Page Application, SPA)와 SSR의 연계성도 같이 공부해보라는 제안을 받았다. 이번 머릿말도 동일하다. 조금이라도 스스로에게 유익한 시간이 될 수 있게 공부해보기로.
Server-Side Rendering, SSR
SSR은 서버에서 렌더링을 한 뒤에, 완성된 페이지를 클라이언트에게 보내 보여주는 방식이다. CSR은 설명서를 받고 필요한 자재를 발주넣는 것이라고 가정하면, SSR은 완성된 제품을 받는 느낌으로 이해하면 편하다.
출처: The Benefits of Server Side Rendering Over Client Side Rendering
이 전글에서 이야기했던 HTML, CSS, JavaScript 를 불러오고, 사이트마다 필요한 추가 데이터를 요청하는.. 일련의 과정들은 서버에서 담당한다. 사용자 기기는 결과물을 출력해주는 일만 남는다.
SSR을 CSR과 비교했을 때의 특징
아무래도 CSR의 특징을 이야기 했을 때와 다소 겹치는 부분이 있다.
- 사용자가 편하다.
사용자의 기기는 렌더링에 쓸 자원을 아낄 수 있다. 서버가 작업을 해주기 때문에, 본인의 기기에 가해지는 부하가 적고, 기기에 따른 차이도 영향을 덜 끼치게 된다. 이전 글에서 이야기한 대로 모든 사용자가 신식 기기를 사용하지는 않으니, 이 점은 어떤 기기에서도 비슷한 경험을 할 수 있게 해준다는 데에 의의를 둘 수는 있겠다.
.. 사실 이제와서 하는 지극히 개인적인 의견은..
이 문제를 논함에 있어서 '실제로 얼마나 속도의 차이가 존재하는가' 를 확인해야 확신이 설 것 같다. '정량적인 지표' 가 필요하단 말이다. 이를테면, 렌더링 방식에 따라 로드 속도에 700~1000ms (0.7~1초) 가량 차이가 난다고 해보자. 그렇다면 충분히 유의미한 속도라고 할 수 있을것이다. 다시 말해, 1초라도 방문한 사용자가 기다리지 못하고 나가기에 충분한 시간이라고 본다.
-
검색 엔진이 잘 '긁는'다.
CSR처럼 비어있는 문서를 받아서 렌더링을 시작하는게 아니므로, 크롤러가 문서를 상대적으로 잘 긁어가줄 수 있다. 이런 것을 '검색 엔진 최적화(Search Engine Optimization, SEO)'가 잘 되어있다고 말하나. 물론, 단순히 작성자도 이것 때문에 잘 긁는다고만 표현하는 건 무리가 있다고 생각은 한다. 너무 남 일같이 말하는 것 같지만, 웹 개발자가 어떻게 만드느냐에 따라 충분히 결과가 다를 수 있다고 본다. 괜히 단어 이름이 '검색 엔진 최적화' 겠는가. -
서버가 바쁘다.
데이터 전송, 페이지 렌더링 모두 서버가 전담한다면 서버가 받는 피로도가 높을 수 밖에 없다. 사용자는 외부에서 페이지를 구경하는, 일종의 '손님' 입장이니 아무래도 어떻겠느냐만, 이 문제는 개발자와 회사가 신경을 쓰게 만드는 쪽이라고 할 수 있다. 다량의 트래픽과 렌더링 작업을 모두 소화할 수 있는 '튼튼한' 서버를 마련하고, 이 두 과정에 필요한 자원을 최적화하는 과정이 선행될 수 밖에 없다.
Single Page Application, SPA
단일 페이지 애플리케이션(이하 SPA)은 단어 그대로 '하나의 페이지' 로 구성된 애플리케이션을 말한다. 다른 컨텐츠를 보기 위해 새 페이지를 로드하지 않고, 이미 로드된 문서의 DOM 요소를 수정하는 식으로 동작한다. 빠릿빠릿한 동작과 전환으로 사용자가 마치 스마트폰의 앱/어플을 쓰는듯한 느낌을 주는 것이 SPA의 방향성이다.
추가로, SPA와 대조되는 방식은 다중 페이지 애플리케이션(Multiple Page Application, MPA)이다.
공부하라고 제안받은 정확한 내용이..
"SPA로 구성된 웹 앱에서 SSR이 필요한 이유에 대한 설명"이었는데.. 문장을 이렇게 보니 막연하다는 느낌을 받았다. 가장 의문인 점은 '왜' 인지를 모르겠다는 점이다.
아무래도 작성자가 무언가 놓치고 있단 생각이 들어서 조금 더 검색을 해보게 되었다. 적어도 지금 찾아야 할 기술을 발견하면 '왜' 필요한 지도 알 수 있지 않을까 싶어서라도. 경험도 지식도 부족하니 몸이 고생을 하게 된다.
SSR with hydration
이 부분 부터는 아무런 정보나 지식이 없던 상태였기에, 내 힘으로 뭔가 작성하는 건 불가능이라 판단이 되었고, 그렇기에 대부분은 아래에 명시할 출처들의 내용을 되풀이 하는 것이라 볼 수 있다. 좀 더 디테일하고 확실한 내용을 읽고자 한다면 아래 출처를 확인함이 좋을 듯 싶다.
- SPA로 SSR 구현하기 by taero.blog
- 정확히 무엇을 찾아야 하나 싶어서 막연하게 키워드로 검색하다가 발견한 글이다. 어떻게 작동하는 지 차근차근 풀어서 요연하게 설명해주셨다.
- 해당 글에서 출처로 달아진 Rendering on the Web 도 영어 독해에 문제가 없다면 읽어보는 것이 괜찮아보인다.
- Next.js의 렌더링 과정(Hydrate) 알아보기 by MJ Kim
- Next.js에서 'SSR with hydration'이 어떻게 작동하는지 풀어서 설명해주셨다.
- React의 Hydration에 대하여 by huurray
- (18 버전 이후의) React에서도 hydration을 이용한 웹 개발이 가능함을 이전과 이후로 비교하여 일목하게 설명해주셨다.
출처: Rendering on the Web
표의 3번째 열에 대한 이야기이다.
SSR with hydration수분을 보충한 SSR은 일단 사이트를 빌드할 때 HTML 문서를 미리 렌더링(Pre-rendering)해두고, 사용자가 요청하면 스크립트 코드를 가져와 페이지를 완전히 상호작용할 수 있게 렌더링하는 기술이다. 사용자가 페이지를 부르면 그 페이지에 나머지 코드들을 불러서 합치는 모양새가 마치 '말라붙은 문서에 수분을 보충하는' 것처럼 보여서 hydrate라고 하나보다. 뭔가 말려놓은 미역이나 다시마를 물에 담궈서 불리는 느낌이다.
여기서 미리 렌더링할 것들은 주로 투고한 글이나, 제품 정보, 사이트 메뉴와 같이 한번 작성하면 (거의) 바뀔 일이 없는 컨텐츠들이다. 이런 식으로 한번 만든 뒤에 서버단에서 추가적인 렌더링 없이 완성된 페이지를 가져다주기만 하면 되는 상태로 만들어놓는 것을 '정적 사이트 생성(Static Site Generation, SSG)' 이라고 하며, 맞춤 추천목록 같이 SSG로 처리하기엔 난감한 컨텐츠들은 서버에서 렌더링(SSR)한 뒤에 가져다준다.
아무래도 서버에서 해야할 일은 줄어들고, SEO에도 약점이 잡히지 않는 구성이기에 그런 과제를 받은건가 싶다.
쉽지 않다.
남들보다 뒤쳐져 있는 입장이다보니 조급하기도 하거니와, 뭔갈 찾아내고 이해하는 데에도 시간이 더 걸리는 느낌이다. 찜찜하다. 결국 좀 더 잘해지고자 배우려고 하는 거니까, 내가 인내해야 할 문제겠지만.
출처를 달긴 했는데..
원저자 분들에게 물어보고 가져왔어야 할 거 같단 생각이 한주먹 만큼 피어나고 있다.. 또 찜찜하다. 혹시나 불편한 원저자님께서는 댓글을 부탁드립니다. 그리고, 내용에 감사합니다.
반박할 시 당신의 말이 맞습니다, 네.
웃음을 유발하고자 하는 이야기가 아니라, 교정이 필요하거나 틀린 부분을 배우고 수정할 수 있도록 여러분들의 발언을 부탁드리는 것입니다. 혼자서 공부할 때의 가장 큰 문제는 '한 번 모르는 건 (거의) 영원히 모른다.' 는 것입니다. 당장 거울이 없으면 자기 얼굴도 볼 수 없고, 거울 두 개가 없으면 자기 이면인 등을 볼 수도 없는 것이 인간(을 포함한 동물)입니다.
제 벨로그를 찾아와 읽어주시는 여러분의 의견에 미리 감사드립니다.
