[NextJS] 프론트엔드 서버는 필요한가? (CSR, SSR)

이전에 팀원분들과 프로젝트 구조에 관해 논의하던 중 이런 이야기가 나왔습니다.

백엔드: 그런데 사실 저는 프론트 서버가 왜 필요한지 모르겠습니다.
어차피 백엔드 서버가 있는데 왜 프론트 서버가 따로 필요한건가요?
프론트 서버를 거쳐서 백엔드 서버에 접근할 거라면 애초에 백엔드 서버에 접근하는게 더 빠르지 않나요?

저는 당시 쉽사리 답변을 해드리지 못했습니다. 저 말만 놓고 보면 틀린 말이 아니니까요.

그럼 결국 프론트엔드 서버는 필요 없는걸까요?

 

1. 전통적인 프론트엔드 개발 방식 (정적 배포)

근본적으로 웹 프론트엔드는 HTML, JS, CSS의 세 가지 요소로 이루어져있습니다.

브라우저는 위 요소만을 가지고 웹을 구성하게 되죠. 전통적인 프론트엔드의 배포 과정은 아래와 같습니다.

1. 리액트 등의 라이브러리, 프레임워크를 사용하여 앱을 개발한다.
2. 코드 결과물에 빌드 과정을 거쳐 HTML, JS, CSS로 최종 결과물을 만들어낸다.
3. 빌드 결과물을 Nginx, Apache 등의 웹서버에 업로드한다.
4. 사용자들이 URL로 해당 웹서버에 접근하면 서버는 브라우저에 HTML, JS, CSS를 제공한다.
5. 브라우저는 서버에서 전달받은 HTML, JS, CSS를 이용해 웹 서비스를 제공한다.

위 방식을 "정적 배포"(Static deployment)라고 부릅니다.

프론트엔드 개발자는 서버에 대해 신경쓸 필요가 전혀 없습니다.

 

장점

• 일반적인 CDN 서비스는 굉장히 안정적이고 빠르다.
• 모든 코드를 클라이언트 사이드로 작성하면 되므로 일관되고 간단하다.

단점

• 모든 작업이 브라우저에서 이루어진다. 즉 클라이언트의 CPU 성능에 따라 사용자 경험이 천차만별이다.
• 브라우저가 리소스를 받아오고 파싱을 하기 전까지 렌더링이 블락된다.
• 자바스크립트가 파싱되고 실행된 후 새로운 리소스(백엔드 콜)를 요청하면 레이턴시가 발생한다.
• 서버사이드일 때보다 보안 사항이 더욱 복잡하다. (CORS 등)

 

2. 프론트엔드 서버를 이용한 개발 방식 (동적 배포)

서버에는 제각각 역할이 존재합니다.

웹서버는 리소스를 서빙하기 위해 존재하고,
자바 백엔드 서버는 효율적이고 안전하게 데이터를 제공하기 위해 존재합니다.

이 둘이 같다고 보시나요? 데이터를 제공한다는 점은 같지만 다른 역할을 수행하고 있습니다.

그리고 프론트엔드를 위한, 프론트엔드 서버가 등장했습니다.

이전에 보았던 전통적인 프론트엔드의 배포 과정은 거의 동일합니다.

하지만 차이점이라면, 웹서버의 역할도 해주며 다양한 기능을 추가적으로 제공하는 서버를 사용한다는 점입니다.

유저가 URL로 페이지를 요청하면 서버는 동적으로 페이지를 생성합니다. 동시에 백엔드 콜을 요청합니다.

브라우저는 생성된 HTML을 받게 됩니다. 상호작용을 위한 JS 만을 다운로드하므로 CSR에 비해 JS 페이로드가 적습니다.

 

장점

• 서버에서 이루어지는 작업이 대다수이므로 제품의 퍼포먼스가 서버에 달렸다.
• 백엔드 호출이 서버에서 이루어지므로 빠르게 집계되며 레이턴시가 적다.
• 더 작은 JS 페이로드로 인해 파싱과 실행이 빠르며, 페이지의 상호작용이 거의 즉각 가능하다.
• 보안이 CSR에 비해 쉽고 빠르다.

단점

• HTML을 받기 전까지는 렌더링이 블락되므로 고성능의 기기에서는 CSR보다 더 길게 블락될 수 있다.
• 서버 사이드와 클라이언트 사이드 로직을 따로 작성하여 관리해야 한다.

 

3. 결국 프론트엔드 서버는 필요한가?

많은 질문에 대한 답이 그렇듯 "상황에 따라 선택하면 된다"입니다.

지금까지 저의 짧은 경험을 비추어 봤을 때, 각 접근 방식에 적절한 상황을 나열해보면..

SSR

• 빠르게 동작하는 데모를 만들어야 할 때
• SEO가 중요한 프로젝트를 개발할 때
• 2개 이상의 페이지를 다루는 대규모 프로젝트일 때
• 프론트엔드 서버를 실행할 자원이 허용되는 상황일 때

CSR

• SPA 어플리케이션을 개발할 때
• 작은 사이즈의 프로젝트를 개발할 때
• 프론트엔드 서버를 실행할 자원이 허용되지 않을 때

현재 NextJS는 App Router를 활용하는 강력한 서버 사이드 기능들을 지원하며 SSR을 권장하고 있습니다.

또한 국내의 경우 토스에선 SSR 제품 적용으로 렌더링 시간의 획기적 단축 사례 등을 공유하는 등,

이곳 저곳에서 CSR에서 SSR로의 전환 기조가 일고 있다고 보여집니다.

하지만 분명히 각 상황에 적합한 방법이 따로 존재하므로, 제품의 성격과 확장 가능성을 파악하고 팀원들과의 논의(특히 인프라 팀과의 논의)를 거쳐 알맞은 방법을 선택하시길 바라겠습니다.

이후 외전으로 SSG와 RSC에 대해 정리해보겠습니다.

 

참고할 만한 글

From the nextjs community on Reddit