오늘부터 진행한 원티드에서 주관하는 프리온보딩 FE챌린지를 진행했다.
이번 주제에대해서 깊게 생각해본적은 없으나, 웹공부하면서 들어봤던 내용과 개념들이라 next.js가 도입되는 이유를 좀더 잘 파악할 수 있을것 같았다.
1. MPA 그리고 SPA
CSR에대해 얘기하기 전에, SPA는 왜 생겨났으며, MPA와은 어떻게 다른지에대해서부터 확인이 필요할것 같았다.
결론부터 얘기해보자면,
MPA는 SSR에 가깝게 동작하고, SPA는 CRA에 가깝게 동작한다고 볼 수 있다.
사실 위처럼 정확하게 얘기하기엔 부분적으로 부족한 내용이 있긴하지만 이해를 위해서 먼저 이런느낌으로 뇌에 박고 진행해 보았다.
1) MPA(Multi Page Application)
쉽게말해 여러개(multi)의 html파일로 웹앱을 구성하는 방식을 말한다.
사실 MPA는 전통적으로 웹 초기부터 존재하여 서비스 해오고 있었고,페이지를 이동할때마다 새로운 페이지를 서버에 요청을 하게 된다. 그럼 그것에 맞는 새로운 내용이 서버 연산을 통해서 렌더링 하고 완성된페이지 형태(템플릿)로 응답한다. 사실 이를 SSR(Server Side Rendering)이라고 한다.
그렇기 때문에 사용자에 의해 다른 페이지로 옮기는 행위 즉, 라우팅(routing : 경로를 찾아가는 행위)에 필요한 라이브러리나 번들링에 필요한 여러 자바스크립트 툴체인이 필요 없고 정적페이지를 그대로 서버에서 가져오므로 SEO측면과 초기 로딩속도에 이점이 생길 수 있었다.
하지만, 이렇게 되면 페이지가 이동하고 새로 업데이트될때마다 새로고침이 필요하며 끊기는 현상이 지속되어 사용자 측면에 불편을 초래하기도 했다.
웹이 발전될수록 사용자의 측면에 더 부합하고 적합하게 이루어지는 서비스가 각광을 받으며 UX가 중요해지는 부분이 늘어나면서 사용자 친화적인 웹 개발을 하기 시작했고 이에 SPA가 등장했다.
2) SPA(Single Page Application) 등장
이런 통신의 형태로 웹서비스가 발전해오는 중, 페러다임이 급격히 바뀌게되는 사건이 발생했고 구글에서 AJAX를 적극 도입하면서 자리잡게 되었다.
이를통해 동기적인 서버 요청이 비동기적으로 요청을 할수 있게 되면서 데이터의 업데이트의 큰 변화가 이뤄지며 자바스크립트가 크게 성장하는 포인트가 됐었던 것이다.
SPA는
사용자가 페이지를 로드할때 초기 로딩시 필요한 모든 리소스(html,css,js)를 한번에 받아놓기때문에 초기 로딩속도는 느리지만, 그 이후에 추가적인 데이터 갱신이나 요청은 서버로 부터 AJAX요청을 하여 결과적으로 html을 동적으로 화면에 보여줄 수 있게 되는 것이다.
따라서 결국 SPA는 CSR방식으로 서버와 통신한다고 볼 수 있겠다.
2. CSR 과 SSR
앞전에 먼저 CSR방식은 SPA에서 동작하는것과 가깝고 SSR방식 MPA의 동작과 가깝다고 언급했다.
MPA의 동기적인 서버요청을 보완하고 매번 새로고침되는 좋지못한 UX로 인해 SPA가 발전되면서 CSR방식을 도입하여 사용해왔지만, 당연히 그에따른 단점도 생기기 때문에 SSR방식과 장단점을 잘 파악해 웹서비스에 필요와 목적에 맞게 적용하는게 제일 베스트가 아닐까 싶다.
CSR(Client Side Rendering)
CSR은 클라이언트측에서 페이지를 렌더링 한다
- CRA의 렌더링 과정
브라우저의 요청에 의해 서버는 웹페이지를 본인이 렌더링하지않고 골격인 html파일과 javascript파일(여러 라이브러리와 툴체인)을 같이 보낸다.
-> 그래서 초기 로딩속도가 지연이 됨(다소 무겁기 때문에).
이때 클라이언트(브라우저)가 전달받은 html페이지와 js파일이 웹 페이지를 완전히 렌더링된 페이지로 바꾼다.
그리고 그 이후에는 데이터를 받아올때만 서버와 통신하게 된다.(AJAX)
첫 요청할때만 딱 한페이지만 불러오고 그다음부턴 기존 페이지의 내부를 수정 및 업데이트하여 보여주는 방식이다고 볼 수 있다.
👍 장점
1. 매끄러운 사용자 경험(UX)
2. 필요한 데이터만 부분적으로 로딩가능(성능개선)
3. 서버의 부하를 감소 : 연산을 클라이언트로 분산시켜줌
4. 컴포넌트별 개발 용이 (생산성)
5. 개발 프로세스 단순화 : 프론트 - 백엔드 독립적으로 개발 작업가능👎 단점
1. 초기 로딩 구동 속도 느림 : 초기 로드시 필요한 모든 파일을 다운로드 하고 샐행해야하기 때문, 규모가 커질수록 더 심해짐
=> webpacak의 code splitting으로 해결가능
2. 검색엔진 최적화(SEO) 어려움 : 초기 로딩 시점에는 항상 비어져있는 html 페이지라 검색엔진이 크롤링할 데이터 없음
=> SSR로 해결가능
3. 보안 이슈 : 프론트단에서 로직이 실행된다는것에 대한 보안약점
SSR(Server Side Rendering)
SSR은 서버측에서 페이지를 렌더링 한다.
- SSR의 렌더링 과정
브라우저가 서버의 url로 GET요청을 보내면 그에 맞는 웹페이지를 보내준다. 그 웹 페이지가 브라우저에서 보일땐 완전히 렌더링된 상태로 보여진다.
필요에 따른 요청일 경우엔 MPA에서 설명했다시피
페이지를 이동하거나 데이터를 요청할 때마다 새로운 페이지를 요청하고 그에 해당하는 모든 템플릿은 서버연산을 통해 렌더링하고 완성된 페이지를 응답으로 돌려준다.
👍 장점 및 사용
1. 검색엔진 최적화(SEO)
2. 단일 파일 용량이 적은경우 적합
3. 사용자와 상호작용이 적은 페이지 적합
4. 정보전달 성격이 짙은 페이지(블로그, 검색엔진사이트) 적합👎 단점
1. 페이지 이동시 화면 새로고침으로인한 깜빡임(UX)
2. 서버 렌더링에 따른 부하(성능)
3. 모바일 앱 개발시 추가적인 백엔드 작업 필요(생산성)
📍 SPA로 구성된 웹앱에서 SSR이 필요한 이유??
위에서 정리한것처럼
일반적인 SPA를 CRA로 동작할때에는
브라우저에서 JavaScript를 사용하여 페이지를 렌더링하고, 데이터를 동적으로 가져와서 페이지를 업데이트한다.
그러나 SSR에서는
서버에서 애초에 초기 페이지 로드 시에 필요한 HTML, CSS 및 데이터를 생성하여 클라이언트에게 전달하고, 이렇게 서버에서 생성된 완전한 HTML 페이지가 브라우저에 렌더링 되게 되어 사용자에게 보여지게 된다고 했다.
SPA를 CSR방식으로 구현했을시에 초기 로딩 속도나, 검색 엔진 최적화 등의 제가있었기 때문에
SPA에 SSR방식을 도입한다면
js코드가 동작하기 전에 이미 완성된 형태의 템플릿(html에 데이터가 삽입된 상태)을 서버로 부터 전달받아 검색엔진 크롤러가 페이지를 크롤링하기에 적합한 상태가 되는것이다. (SEO)
또한
초기 페이지를 로딩 시에 필요한 콘텐츠를 서버에서 렌더링하여 전달하기 때문에 사용자는 빠르게 페이지를 볼 수 있습니다.
기존에 MPA에서 가지고 있던 문제를 SPA로 해결하며, CSR이라는 개념이 도입되었고, 로딩이 느려진 문제를 SSR로 해결할 수 있게 된 것이다.
정리
어떤 방식을 사용하든 트레이드 오프는 존재한다고 생각하기 때문에 어느 한 쪽이 더 우월하다고 말하기는 어렵고 제공하고자하는 웹 서비스의 특성에 맞게 선택하는 방향이 좋을 것 같다.
