1. 계기
개발을 하면서 CSR과 SSR의 개념을 명확하게 이해하는 것이 중요하다고 느꼈다. 아래는 이번 글을 쓰게 된 계기이자 내가 헷갈렸던 부분이다.
- CSR과 SSR의 가장 큰 차이는 무엇인가?
- CSR에서는 백엔드 서버가 HTML을 제공한다고 하는데, 프론트엔드 서버가 있어도 백엔드에서 HTML을 제공하는 건가?
- SSR에서 "서버"란 무엇을 의미하는가? 프론트엔드 서버인가, 백엔드 서버인가?
- 프론트엔드 서버와 백엔드 서버의 역할은 무엇인가?
어느 정도 알고 있다고 생각했었는데, 한번 헷갈리기 시작하니 과연 내가 제대로 알고 있던 것이 맞았는지 의문이었다.
그래서, 이번 기회로 정말 정말로 제대로 이해하고 넘어가기로 했다 !
2. 브라우저 렌더링 과정
CSR과 SSR을 설명하기에 앞서, 먼저 이 글을 쓰게 된 초기 궁금증의 원인인 브라우저 렌더링 과정에 대해 설명하려고 한다.
일반적으로 아는 브라우저 렌더링 과정은 아래와 같다.
- 웹 브라우저에 URL을 입력한다.
- 주소창에 입력한 URL의 Host Name이 DNS를 통해 IP 주소로 변환되고, 해당 IP를 가진 서버로 요청을 보낸다.
- 서버에 존재하던 HTML 파일이 브라우저 요청에 의해 응답된다. 브라우저는 서버가 응답한 HTML을 읽어 분석 후 파싱한다.
- HTML 마크업을 바탕으로 DOM 트리와 CSS가 있다면, CSSOM 트리를 생성한 후, 이를 결합하여 렌더 트리를 형성한다.
- 이후, 이 렌더 트리를 기준으로 레이아웃을 실행하고 페인팅 작업을 수행한다.
- 자바스크립트의 경우, 서버로부터 파일을 받아와 자바스크립트 엔진에 의해 파싱된다.
이번 포스트에서 중점적으로 정리한 부분은 1번과 6번이다. 이 두 부분에서 모두 서버라는 단어를 사용하고 있다.
그렇다면, 여기서 말하는 "서버"는 프론트 서버일까 백엔드 서버일까?
3. 일반적인 HTML 요청에서 서버는 프론트 서버인가 백엔드 서버인가?
처음에는 브라우저의 렌더링 방식은 정적인 페이지 기준으로만 생각해 봐서 당연히 백엔드 서버라고 생각했었다.
하지만, CSR과 SSR일 때를 생각해 보니 무언가 이상하다는 생각이 들었다.
백엔드 서버에서 보내준다고 하기에는 " SSR은 프론트 프레임워크인 Next.js에서 페이지를 구현해 보내주는데 어떻게 백엔드 서버에서 보내줄 수 있는거지?" 라는 의문이 들었고, 이에 대해 찾아보게 되었다.
결론적으로 대부분의 경우 1번의 서버는 "프론트엔드 서버", API를 요청하는 6번의 서버는 "백엔드 서버"이다.
서버라고 해서 당연히 백엔드 서버라고 생각했던 내게 이 결과는 조금 충격적이었다.
기본적으로 CSR 방식은 프론트엔드 서버가 index.html과 JS 번들을 제공하여 브라우저에서 동적으로 HTML을 생성하고, SSR 방식은 프론트엔드 서버(예: Next.js)에서 HTML을 생성한 후 사용자에게 전달한다.
즉, SSR의 경우 백엔드가 아닌 프론트엔드 서버가 HTML을 생성하여 반환한다.
4. CSR과 SSR의 차이
두 방식에 대해 조금 더 설명해 보자면, CSR과 SSR은 웹 애플리케이션에서 HTML을 생성하는 방식의 차이를 의미한다.
CSR(Client-Side Rendering)
CSR은 사용자가 특정 페이지에 접근하면, 브라우저는 서버에서 index.html을 다운 받고, 코드를 분석하고 파싱하며 CSS 파일과 JS 파일을 다운 받는다. 이후 브라우저에서 JS가 실행되면서 API를 통해 데이터를 가져와 화면을 구성한다.
HTML을 브라우저에서 동적으로 생성하기 때문에 초기 로딩 속도가 느릴 수 있지만, 이후의 페이지 전환은 빠르다는 장점이 있다.
SSR(Server-Side Rendering)
SSR은 사용자가 특정 페이지에 접근하면, 서버가 해당 페이지에 필요한 데이터를 받아와 HTML을 생성하여 사용자에게 전달하여 브라우저는 이미 내용이 채워진 HTML을 바로 렌더링 할 수 있다. 이 때문에 초기 로딩 속도가 빠르다는 장점이 있다.
하지만, 페이지 전환 시에는 서버에서 다시 HTML을 생성해야 하기 때문에 추가적인 요청 시간이 발생할 수 있다.
5. 프론트엔드 서버란?
위에서 언급한 프론트엔드 서버란, 보통 index.html과 JavaScript 같은 정적인 파일을 서빙하는 역할을 한다. 이후 브라우저에서 JavaScript가 실행되며 백엔드 서버로 API 요청을 한다. 하지만, SSR 환경에서는 단순한 정적 파일 제공이 아니라, 요청이 들어올 때마다 프론트엔드 서버가 백엔드 서버에 API 요청을 해 데이터를 받아와 적용된 HTML을 생성하여 반환한다.
즉, 프론트엔드 서버는 CSR과 SSR에서 HTML을 제공한다는 공통 역할을 하지만, CSR에서는 단순한 정적 파일만 제공하고, SSR에서는 백엔드 서버로부터 데이터를 받아와 동적으로 HTML을 생성하는 차이가 있다.
5. 백엔드 서버에서 HTML을 보내주는 경우
일반적으로 백엔드 서버는 API를 제공하고, HTML은 프론트엔드 서버에서 처리한다. 하지만 백엔드 서버에서도 HTML을 제공할 수 있다. 바로 위에서 언급했던 전통적인 방식의 서버 렌더링일 때와 프론트엔드 빌드 파일을 백엔드 서버에 포함하여 배포하는 경우이다.
먼저 전통적인 방식의 서버 렌더링은 예전 PHP, JSP, Ruby on Rails 등을 사용할 때, 백엔드에서 직접 HTML을 생성하여 브라우저로 보내주는 방식이다.
두 번째는 빌드된 정적 파일을 백엔드 서버 내부에 포함하여 정적 파일을 서빙할 때인데, 이 경우에는 백엔드 서버에서 직접 HTML을 브라우저로 보내준다. (방식은 CSR과 동일하지만 빌드된 파일이 백엔드 서버 내부에 있다는 차이점이 있다.)
두 경우 모두 프론트엔드 서버가 따로 구축되지 않아 백엔드에서 보내주는 경우이다.
프론트엔드 비중이 커져 서버를 따로 관리하거나, SSR로 개발한다면 프론트엔드 서버에서 HTML을 보내주게 된다.
7. 결론
그동안 헷갈렸던 부분들을 정리하니까 연관된 다른 부분들도 조금이나마 명확하게 알게 된 것 같다.💥
"서버"라는 단어에 대해 너무 안일하게 생각하고 있던 것 같다. 이번 기회에 정리한 것 같아 기쁘다.
'Study' 카테고리의 다른 글
[Web] Webpack HMR과 풀 페이지 리로드 (+IE9 해결 방법) (0) | 2025.03.14 |
---|---|
[Next.js] App Router vs Pages Router (feat. 달라진 폴더 구조) (1) | 2025.01.19 |
[JavaScript] 디바운스 구현하기 (feat. 더블 클릭 이슈 해결하기) (1) | 2024.08.31 |
[Node.js] Excel 파일 업로드 및 다운로드 하기 (feat. Multer) (0) | 2024.02.21 |
[Vue.js] Excel 파일 업로드 및 다운로드 하기 (feat. 다른 이름으로 저장하기) (0) | 2024.02.21 |