클라이언트 사이드 랜더링

D+45

하루하루 뭐 하나라도 공부하고 정리하고 이야기를 해보자. 건축 소프트웨어 엔지니어라는 멋진 이름으로 시작했지만 실상은 잡부다. 잡부는 모든 걸 알아야 하는 법. React Three Fiber로 시작해서 프런트엔드 근본으로 가는 나의 글. 오늘도 이야기를 시작해 본다.

서버사이드 렌더링의 장점도 있지만 단점도 있다

서버사이드 렌더링이 마치 꿈의 나라로 가는 것 같았지만 단점도 존재한다. 클라이언트 사이드 랜더링은 서버사이드 랜더링의 단점을 극복할 수 있다는 내용이 주를 이룬다. 앞에선 서버사이드가 마치 만능인 거 같았으나 꼭 그렇지도 않다는 게 이 이야기의 흐름이다. 그렇다면 끝에 가서 next.js는 이 둘의 장점을 결합할 수 있다고 주장하는 글이 펼쳐질 것으로 보인다.

서버사이드 단점 1 : 페이지간 탐색

서버사이드 랜더링은 서버단에서 모든 자바스크립트, CSS 등을 처리한 후 HTML만 클라이언트로 쏴주게 된다. 그렇기 때문에 클라이언트에서는 큰 연산 없이 웹페이지를 볼 수 있다. 하지만 만약 페이지 이동이 잦은며, 각 내용물의 차이가 크지 않은 경우는 어떨까? 예를 들면 껍데기는 같지만 안의 내용물만 약간 다른 경우를 이야기한다. 이럴 때 서버사이드 랜더는 그렇게 좋지 않다. 왜냐하면 매번 요청마다 모든 HTML을 다시 만들어서 클라이언트 사이드로 넘겨주기 때문이다. 

반면 클라이언트 사이드 렌더링은 전체를 다시 계산하는 것이 아닌 특정 부분 데이터만 재연산하기 때문에 이런 경우 더 효율적이다. 

서버사이드의 단점 2 : 서버의 부담이 크다

프런트앤드 앱을 만들게 되면 클라우드에 배포를 하게 된다. 보통 AWS에 많이 쓸 것으로 예상할 수 있다. 다들 좋아하는 상상을 해보자. 만약 내 앱이 잘돼서 하루에 수천만 건 요청이 들어온다면 어떻게 될까. 그런 경우 서버에 부담이 커지고, 비용도 커지고 여러 가지로 심각하게 고민을 하게 될 것이다. 주객이 전도되어 클라이언트의 부담이 적게 만들어 웹페이지를 빠르게 띄우려고 했지만 오히려 느려질 수 도 있음을 암시한다. 서버의 부담을 클라이언트로 다시 가져가기 때문에 서버자체의 부담은 줄어들게 된다. 내가 아직 제대로 모르지만 이렇게 함으로써 serverless 환경 구축을 더 원활히 할 수 있다. 글로만 보면 이해가 안 가지만 나중에 프로젝트로 뚜드려 맞으면 분명 이해가 되리라고 생각한다.

다음은

다음은 static site genration을 이야기한다. R3F를 이야기하려다 끝까지 가는 나의 글. 어서 열심히 해서 다시 R3F궤도로 올라와야겠다.