🔮 Server/Client Side Rendering

웹 어플리케이션의 렌더링 방식은 크게 서버와 클라이언트 렌더링 방식이 있습니다. 이 방식을 살펴보기에 앞서 과거 웹 사이트의 역사에 대해 간단하게 살펴보겠습니다.

Static Site

1990년 중반까지는 대부분의 사이트가 static 사이트 였습니다. 서버에 이미 잘 만들어진 html문서들이 있고 사용자가 부라우저에서 주소에 접속하면 서버에 이미 배포되어있는 HTML 문서를 받아와 보여주는 형식이죠. 이런한 방식의 문제점은 페이지에서 다른 메뉴를 클릭하면 다시 서버에서 해당페이지의 HTML을 받아와서 페이지 전체가 업데이트 되어야 합니다. (깜박, 깜박... 정말 사용성이 떨어지죠)

iframe

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

XMLHttpRequest API

그리고 1998년 우리가 많이 쓰고 있는 fetch API의 원조 XMLHttpRequest API가 개발이 되어 이제는 HTML문서 전체가 아니라 JSON과 같은 포멧으로 서버에서 가법게 필요한 데이터만 받아 올 수 있게 됩니다. 그 데이터를 자바스크립트를 이용해서 동적으로 HTML요소를 생성하여 페이지에 업데이트 하는 방식이죠.

AJAX, SPA

2005년 이런 방식이 공식적으로 AJAX라는 이름을 가지게 되고 구글에서도 AJAX를 이용해 GMail, Google Map과 같이 우리가 많이 쓰고 있는 웹 어플리케이션을 만들기 시작합니다. 이것이 바로 현재 널리 쓰이고 있는 싱글페이지 어플리케이션(SPA) 입니다. 사용자가 한 페이지 내에서 머무르면서 필요한 데이터를 서버에서 받아와 부분적으로만 업데이트 하게 되죠. 이런 방식으로 하나의 어플리케이션을 사용 하듯 웹사이트에서도 이제 사용성이 굉장히 좋아지게 됩니다.

이런 SPA트랜드 + 사용자의 PC성능이 점차 좋아져서 많은 것들을 무리 없이 처리할 수 있게 되었고 자바스크립트도 표준화가 잘 되어짐에 따라 Angular, React, Vue와 같은 프레임워크가 나와 클라이언트 사이드 렌더링(CSR) 시대로 접어듭니다.

Client Side Rendering

클라이언트 사이드 렌더링이란 쉽게 얘기하면 클라이언트에서 다 처리하는걸 말하는데요, 서버에서 index.html 파일을 클라이언트에 보내주면 자바스크립트를 이용해 서버에서 데이터를 요청하고 받아온 데이터를 기반으로 동적으로 HTML을 생성하여 사용자에게 최종적인 어플리케이션을 보여 주게 됩니다.

그런데 말입니다. 이런 클라이언트 사이드 렌더링은 다음과 같은 문제점이 있습니다.

• 사용자가 첫 화면을 보기까지의 시간이 오래 걸릴 수 있다
• 썩 좋지 않는 SEO(Search Engin Optimization)

Server Side Rendering

이러한 CSR의 문제점 때문에 기존 Static 사이트에서 영감을 받은 서버 사이드 렌더링(SSR)이 도입되게 됩니다. 클라이언트에서 모든 것을 처리하는 방식과는 다르게 웹사이트에 접속하면 서버에서 필요한 데이터를 모두 가져와서 HTML파일을 만들게 되고 이렇게 만들어진 HTML파일을 동적으로 제어할 수 있는 소스코드와 함께 클라이언트에게 보내줍니다. 그럼 클라이언트에서는 잘 만들어진 HTML문서를 받아와 바로 사용자에게 보여줄 수 있게 되는거죠.

어떤것이 더 좋을까?

이런 SSR을 이용하게 되면 CSR과 비교했을때 다음과 같은 장점이 있습니다.

• 첫 번째 페이지 로딩이 빨라짐
• 모든 컨텐츠가 HTML에 담겨져 있기 때문에 효율적인 SEO 가능

그럼 이런 SSR 과연 모든것의 해결책이 될까요? 그것은 아닙니다.

SSR에도 다음과 같은 큰 문제점이 존재하는데요,

• Static 사이트와 같은 깜박임 이슈 즉, 썩 좋지 않는 UX
• 서버의 과부화 (사용자가 많은 사이트 일수록)
• 사용자가 빠르게 웹사이트를 확인할 수 있지만 동적으로 데이터를 처리하는 자바스크립트를 다운로드 받지 못해 여기저기 클릭해도 반응이 없는 경우가 발생할 수 있습니다.

TTV(Time To View), TTI(Time to interact)

TTV, TTI 두가지에 대해 좀 더 살펴보겠습니다.

CSR은

1. 사이트에 접속
2. 서버에게서 텅텅빈 인덱스 파일을 받아옴
3. 웹사이트에 필요한 자바스크립트를 서버에 요청
4. 서버에게서 자바스크립트 파일을 받아옴
5. 최종적으로 동적으로 HTML을 생성할 수 있는 자바스크립트를 받아와 웹사이트를 사용자가 볼수 있게 해줌과 동시에 사용자 클릭이 가능

즉, CSR은 TTV 사용자가 웹사이트를 볼 수 있음과 동시에 TTI 클릭을 하거나 인터랙션이 가능하게 됩니다.

반대로 SSR은

1. 사이트에 접속을 하면 서버에서 잘 만들어진 인덱스 파일을 받아오고
2. 사용자는 웹사이트를 볼수 있게 됩니다.
3. 하지만 아직 동적으로 제어할 수 있는 자바스크립트 파일은 받아오지 않았기 때문에 이 순간 사용자가 클릭을 해도 반응이 없습니다.
4. 이후 최종적으로 자바스크립트 파일을 서버에서 받아온 이후에나 사용자의 클릭을 처리할 수 있는 인터랙션이 가능해집니다.

즉, SSR은 사용자가 사이트를 볼 수 있는 시간과 실제로 인터렉션을 할 수 있는 공백 기간이 꽤 긴편입니다.

그래서 웹사이트의 성능을 분석할때 TTV와 TTI도 중요한 매트릭으로 사용할 수 있습니다.

CSR을 많이 사용하는 분들이라면 우리가 최종적으로 번들링해서 사용자에게 보내주는 자바스크립트 파일을 어떻게 하면 효율적으로 많이 분할해서 첫번째로 사용자가 보기위한 정말 필수적인 부분만 보낼 수 있을지를 고민해야 합니다.

SSR같은 경우는 사용자가 보고, 인터렉션 하는 시간의 공백을 줄이기 위해 어떻게 해야할지, 어떻게 조검더 매끄러운 UI와 UX를 제공할 수 있을지 고민해 보면 좋을것 같습니다.

마치며

요즘에는 꼭 CSR 또는 SSR만을 고집해서 사용하기 보다는 Gatsby와 같은 SSG(Static Site Generation)도 있습니다. (지금 보고 계시는 블로그도 Gatsby를 사용) 뿐만아니라 React의 Next.js, Angular Universal과 같은 Angular 애플리케이션을 서버에서 실행하는 테크닉도 있으니, 어떤 방식이 좋고 나쁘고가 아닌 각각의 방식을 이해하고 필요에 의해 선택적으로 사용하면 될 것 같습니다.