1. 웹의 역사 (SPA 시대까지)

1.1 1990년 전까지 : Static Sties

1990년 중반까지는 모두 다 Static Sites였습니다. 서버에 이미 잘 만들어진 HTML문서들이 있고, 사용자가 브라우저에서 Hello.com같은 주소에 접속하면, 서버에 이미 배포되어져 있는 HTML 문서를 받아와서 보여주는 형식이죠.

문제점은 페이지 내 다른 링크를 클릭하면, 다시 서버에서 해당 페이지의 HTML을 받아와서 페이지 전체가 업데이트 되어야 합니다.

1.2 1996년 : iframe

1996년, 문서 내에서 또 다른 문서를 담을 수 있는 iframe 태그가 도입되었고, 페이지 내에서 부분적으로 문서를 받아와서 업데이트 할 수 있게 됩니다.

1.3 1998년 : XMLHttpRequest

1998년, 현재 많이 쓰는 fetch API의 원조, XMLHttpRequest API가 개발되어, HTML 문서 전체가 아니라 JSON과 같은 포맷으로 서버에서 가볍게 필요한 데이터만 받아올 수 있게 됩니다. 그 데이터를 JavaScript를 이용해서, 동적으로 HTML 요소를 생성해서, 페이지에 업데이트하는 방식이죠.

1.4 2005년 : AJAX

2005년, XMLHttpRequest API 방식이 공식적인 AJAX라는 이름을 가지게 되고, 구글에서 AJAX를 이용해서 Gmail, Google Maps같은 서비스 등의 서비스를 만들기 시작합니다. 이것이 현재 널리 쓰이고 있는 SPA(Single Page Application)입니다.

• 사용자가 한 페이지 내에서 머무르면서, 필요한 데이터를 서버에서 받아와서, 부분적으로만 업데이트하는 방식
• 이 방식으로 하나의 어플리케이션을 사용하듯, 웹 사이트에서도 사용성이 조금씩 좋아짐

2. CSR (Client Side Rendering)

이런 SPA트렌드와 사용자들의 PC 성능이 점차 좋아져서, 많은 것들을 무리없이 처리할 수 있게 되었고, JS도 표준화가 잘 되면서, 강력한 커뮤니티를 바탕으로 Angular, React, Vue같은 프레임워크가 나와서, CSR(Client Side Rendering) 시대로 접어듭니다.

CSR을 쉽게 말하자면, 클라이언트측에서 다 해결하는 걸 말합니다. 서버에서 index.html을 클라이언트에 보내주면, 어플리케이션에서 필요한 링크들만 들어있습니다. HTML은 텅텅 비어있기 때문에 처음 접속하면, 빈 화면만 보이고, 다시 링크된 어플리케이션 JavaScript를 서버로부터 다운로드 받습니다.

다운로드한 JavaScript에는 어플리케이션에서 필요한 로직뿐만 아니라, 어플리케이션을 구동하는 프레임워크와 라이브러리의 소스코드들도 모두 포함되어 있습니다. 그렇기 때문에 굉장히 사이즈가 커서, 다운로드받는데도 오랜 시간이 소요될 수 있겠죠? 추가로 필요한 데이터가 있다면, 서버에 요청해서 데이터를 받아온 다음에 이것들을 기반으로 동적으로 HTML을 생성해서, 사용자에게 최종적인 어플리케이션을 보여줍니다.

이런 CSR의 큰 문제점은 2가지입니다.

• Initial Loading may take too long
  • 사용자가 첫 화면을 보기까지 오랜 시간이 걸릴 수 있다는 점
• Low SEO
  • 썩 좋지 않는 SEO(Search Engin Optimization)
  • SEO :
    • 구글, 네이버같은 검색엔진들은 서버에 등록된 웹사이트를 하나씩 돌아다니며 HTML을 분석하는데,
    • 이떄 검색할 웹사이트가 빠르게 동작하도록 하는 것

CSR에서 사용되는 HTML body는 대부분 텅텅 비어있기 때문에, 검색엔진들이 CSR로 작성된 웹페이지를 분석하는데, 많은 어려움을 겪습니다.

3. SSR (Server Side Rendering)

이런 CSR의 과도한 문제점때문에 1990년 중반쯤 사용했던 Static Stite에서 영감을 받은 SSR이 등장합니다.

클라이언트에서 모든 것을 처리하는 방식과는 다르게 웹사이트에 접속하면, 서버에 필요한 데이터를 모두 가져와서 HTML 파일을 만들고, 잘 만들어진 HTML파일을 동적으로 조금 제어할 수 있는 소스코드와 함께 클라이언트에게 보내줍니다. 그러면 클라이언트 측에서는 잘 만들어진 HTML 문서를 받아와서 사용자에게 보여줄 수 있는 것이죠.

💡 참고

사실 SSR은 CSR보다 더 오래된 기술입니다. AJAX가 나오 기전 웹페이지를 생성하는 기술이 SSR이였고, PHP, AJP, JSP 등이 다 SSR을 위해 사용되었던 기술이빈다. 당시에는 CSR이라는 개념이 없어서 대신 서버사이드 스크립트라고 불렸습니다. AJXX가 등장하며, 서버에서만 가능하던 것들이 클라이언트로 어느정도 넘어가면서 CSR이 발전하고, SSR이 재조명된 것입니다.

3.1 장점

이런 SSR을 이용하게 되면, CSR을 사용했을 떄보다 다음과 같은 장점이 있습니다.

• Initial page load is faster
  • 첫 번쨰 페이지 로딩이 빨라짐
• Great SEO
  • 모든 컨텐츠가 HTML에 담겨있기 때문에 조금 더 효율적인 SEO를 할 수 있음

3.2 문제점

그럼 SSR이 모든 것에 솔루션이 될 수 있느냐? 그건 아닙니다. SSR에도 큰 문제점이 존재합니다.

• Blinking issue, Non-rich site interactions
  • Static Sites에서 발생했던 깜박임(Blinking) 이슈가 여전히 존재
  • 사용자가 클릭을 하게 되면, 전체 웹사이트를 서버에서 다시 받아오는 것과 동일하기 때문에
  • 썩 좋지 않는 User experience를 겪습니다.
• Server side overhead
  • 서버에 과부하가 걸리기 쉽습니다.
  • 특히 사용자가 많은 제품일 수록, 사용자가 클릭할 떄마다 서버에 요청해서
  • 서버에 필요한 데이터를 가지고 와서 HTML을 만들어야 하므로 서버에 과부하가 걸리기 쉬움
• Need to wait before interacting
  • 사용자가 빠르게 웹사이트를 확인할 수 있지만,
  • 동적으로 데이터를 처리하는 자바스크립트를 아직 다운로드 받지 못했는데,
  • 여기저기 클릭해서 반응이 없는 경우가 발생할 수 있음

3.3 TTV와 TTI 측면에서 한번 더 정리

SSR의 문제점을 이해하기 위해 TTV와 TTI를 알아야 합니다.

• TTV (Time To View)
• TTI (Time To Interact)

CSR과 SSR을 시간이 흘러가는 순서대로 분석해보면,

CSR은 사이트에 접속하면, 서버에서 인덱스 파일을 받아오고, 인덱스 파일은 텅텅 비어있기 때문에 사용자에게는 아무것도 보여지지 않습니다. HTML 파일에 링크되어져 있는 웹사이트에 필요한 모든 로직이 담겨있는 JavaScript를 요청하게 됩니다.

그리고 최종적으로 동적으로 HTML을 생성할 수 있는 웹 어플리케이션 로직이 담긴 JavaScript파일을 받아옵니다. 그리고 이 순간부터 웹사이트가 사용자에게 보여지게 되고, 또 사용자가 클릭이 가능해집니다. 즉, CSR은 TTV(사용자가 웹사이트를 볼 수 있음)과 동시에 TTI(클릭하거나 인터렉션)이 가능하게 됩니다.

반대로 SSR은 사이트에 접속하면, 서버에서 이미 잘 만들어진 인덱스 파일을 받아오게 되고, 사용자가 웹 사이트를 볼 수 있습니다.

하지만 아직 동적으로 제어할 수 있는 JavaScript 파일을 받아오지 않았으므로, 사용자가 클릭을 해도 동작하지 않습니다. 그래서 최종적으로 JavaScript파일을 받아와야지만, 그때부터 사용자의 클릭을 처리할 수 있는 인터렉션이 가능해집니다. 그래서 서버사이드 렌더링은 사용자가 사이트를 볼 수 있는 시간과 실제로 인터렉션을 할 수 있는 시간의 공백 기간이 꽤 긴 편입니다.

3.4 어떻게 개선할 수 있을까?

그래서 웹사이트 성능을 분석할 때, TTV와 TTI도 중요한 매트릭으로 사용할 수 있는데요,

CSR을 정말 많이 사용하는 개발자라면, 최종적으로 번들링해서 사용자에게 보내주는 JS파일을 어떻게 하면 효율적으로 많이 분할해서, 첫 번째로 사용자가 보기 위해 필요한 정말 필수적인 것만 보낼 수 있는지 고민해야 합니다.

SSR같은 경우 사용자가 보고, 인터렉션하는 이 시간의 단차를 줄이기 위해 어떤 노력을 할 수 있는지, 어떻게 조금 더 매끄러운 UI와 UX를 제공할 수 있을지 고민해야 합니다.

4. SSG (Static Site Generation)

4.1 Gatsby

요즘에는 꼭 CSR 또는 SSR 만을 고집해서 사용하기보다는 SSG도 있습니다. React의 경우 CSR에 특화된 라이브러리이지만, Gatsby라는 라이브러리와 함께 사용하면, React로 만든 웹어플리케이션을 정적으로 웹페이지를 미리 생성해둬서 서버에 배포해놓을 수 있습니다.

그러면 이렇게 만들어진 웹사이트들은 모두 정적이냐? 그런 건 아닙니다. 추가적으로 데이터를서버에서 받아오거나 또는 동적으로 처리해야 하는 로직이 있다면, JS파일을 함께 가지고 있을 수 있기 때문에 동적인 요소도 추가할 수 있습니다.

4.2 Next.JS

Gatsby다음으로 React에서 많이 사용되는 것이 Next.js입니다. Next.js는 강력한 SSR을 지원하는 라이브러리였는데, 요즘에는 SSG도 지원하고, CSR과 SSR을 잘 섞어서 더 강력하고 유연하게 사용할 수 있게 되었습니다.

NextJS 쓰는 이유

• 프론트엔드 개발자들이 가진 고민에 대한 적절한 해결책을 제공
• 규모가 있는 서비스 구조 설계를 어떻게 할 것인가?
• 개발환경 / 코드 분할 / 파일 기반 구조
• SEO(검색 엔진 최적화)
• 프론트엔드에 필요한 간단한 API 구성
• 손쉬운 배포 시스템 Vercel

Next.js의 대체재는?

• Next.js는 대표적인 React 프레임워크로서 자리를 공고히 하고 있음
• 대체재로는 Gatsby / Remix 등이 있음

Reference

• 드림코딩 (https://youtu.be/iZ9csAfU5Os)