SSR과 CSR 정리

핵심 요약

• SSR은 서버에서 HTML을 만들어 내려주는 방식이고, CSR은 브라우저에서 자바스크립트로 화면을 그리는 방식이다.
• 둘 중 하나가 절대적으로 좋은 게 아니라, 초기 로딩 경험, SEO, 상호작용 성격에 따라 선택이 갈린다.
• 요즘 프론트엔드는 SSR과 CSR을 섞어서 쓰는 경우가 많다.
• 면접에서는 "렌더링 위치 차이", "장단점", "언제 어떤 방식을 고르느냐"를 중심으로 말하면 된다.

SSR이란

SSR은 Server Side Rendering의 줄임말이다.
사용자가 페이지를 요청했을 때 서버가 HTML을 만들어서 보내고, 브라우저는 그 결과를 먼저 보여준다.

즉, 첫 화면의 기본 모양은 서버 쪽에서 준비해주는 방식이다.

예를 들어 뉴스 기사, 상품 상세, 랜딩 페이지처럼 처음 보여주는 콘텐츠가 중요한 화면에서 자주 이야기된다.

CSR이란

CSR은 Client Side Rendering의 줄임말이다.
처음에는 비어 있거나 최소한의 HTML을 받고, 이후 자바스크립트가 실행되면서 브라우저에서 화면을 완성한다.

싱글 페이지 애플리케이션에서 많이 쓰는 방식이고, 화면 전환이 부드럽고 상호작용이 많은 서비스와 잘 맞는다.

둘의 차이를 한 번에 보면

SSR

• 서버가 HTML을 만들어 보낸다.
• 첫 화면 내용을 비교적 빨리 보여주기 좋다.
• 검색 엔진 대응에 유리한 경우가 많다.

CSR

• 브라우저가 자바스크립트로 화면을 만든다.
• 한 번 앱이 뜬 뒤에는 상호작용과 페이지 전환이 자연스럽다.
• 초기 JS 번들이 크면 첫 진입 체감이 느릴 수 있다.

SSR의 장점

초기 콘텐츠 노출이 빠르다

사용자는 서버가 만들어준 HTML을 먼저 볼 수 있어서 "아무것도 안 보이는 시간"이 줄어들 수 있다.

SEO 대응에 유리하다

검색 엔진이 읽기 쉬운 HTML을 바로 제공할 수 있어서 공개 콘텐츠 페이지에 적합하다.

공유 미리보기나 메타 정보 처리에 편하다

오픈그래프 같은 메타 정보가 중요한 페이지에서도 SSR이 자주 선택된다.

SSR의 단점

서버 부담이 커질 수 있다

요청마다 HTML을 만들어야 하니 서버 비용과 응답 시간 관리가 중요해진다.

하이드레이션 비용이 있다

HTML만 보내면 끝이 아니라, 이후 자바스크립트가 붙으면서 인터랙션 가능한 상태로 만드는 과정이 필요하다.

구현 복잡도가 올라갈 수 있다

브라우저 전용 API를 바로 쓰기 어렵고, 서버와 클라이언트 환경 차이도 신경 써야 한다.

CSR의 장점

인터랙션이 많은 앱에 잘 맞는다

대시보드, 관리자 화면, 협업 도구처럼 상태 변화가 많은 서비스에서 자연스럽다.

프론트와 백엔드 역할 분리가 비교적 명확하다

프론트는 API를 받아 화면을 그리고, 백엔드는 데이터 제공에 집중하는 구조를 만들기 쉽다.

한 번 로드된 뒤의 사용자 경험이 좋다

라우팅과 부분 갱신이 부드럽고 앱처럼 느껴지기 쉽다.

CSR의 단점

초기 로딩이 느릴 수 있다

자바스크립트 다운로드, 파싱, 실행이 끝나야 의미 있는 화면이 보일 수 있다.

SEO가 까다로울 수 있다

요즘 검색 엔진이 자바스크립트를 어느 정도 처리하긴 하지만, 공개 콘텐츠 서비스에서는 여전히 신중하게 봐야 한다.

저사양 기기에서 부담이 갈 수 있다

렌더링 작업이 브라우저 쪽에 많이 실리기 때문이다.

언제 어떤 방식을 고르나

SSR이 잘 맞는 경우

• 검색 유입이 중요한 페이지
• 첫 화면 노출이 중요한 서비스
• 콘텐츠 중심 페이지

CSR이 잘 맞는 경우

• 로그인 후 사용하는 내부 서비스
• 대시보드, 어드민, 협업 툴
• 상호작용과 상태 변화가 많은 앱

실무에서는 둘 중 하나만 고집하기보다, 공개 페이지는 SSR 쪽으로, 로그인 이후 앱 영역은 CSR 쪽으로 가져가는 혼합 전략도 많다.

예시로 이해하기

쇼핑몰을 생각해보면,

• 메인 페이지나 상품 상세 페이지는 검색 유입과 첫 인상이 중요해서 SSR이 잘 맞을 수 있다.
• 장바구니, 주문 관리, 관리자 화면은 사용자의 상호작용이 많아서 CSR이 더 자연스러울 수 있다.

그래서 "서비스 전체를 무조건 SSR" 혹은 "전부 CSR"로 보기보다 페이지 성격별로 나눠 생각하는 게 현실적이다.

면접 답변 예시

SSR은 서버에서 HTML을 렌더링해서 내려주는 방식이고, CSR은 브라우저에서 자바스크립트로 화면을 완성하는 방식입니다. SSR은 초기 콘텐츠 노출과 SEO 측면에서 유리하고, CSR은 상호작용이 많은 애플리케이션에서 사용자 경험이 좋은 편입니다. 저는 공개 콘텐츠 페이지와 내부 앱 화면의 성격이 다르기 때문에, 실무에서는 둘을 혼합해서 쓰는 경우가 많다고 이해하고 있습니다.

장점

• 렌더링 전략을 단순 암기가 아니라 상황별 선택 문제로 설명할 수 있다.
• Next.js 같은 프레임워크 이야기를 꺼낼 때 기반 개념으로 연결하기 좋다.
• SEO, 성능, UX를 함께 묶어서 답변할 수 있다.

단점

• 개념만 외우면 실제 체감 차이를 설명하기 어렵다.
• SSR과 CSR을 이분법으로만 이해하면 최신 프레임워크 흐름을 놓치기 쉽다.
• 성능은 렌더링 방식 하나만으로 결정되지 않는데, 너무 단순화해서 말하기 쉽다.

주의사항 / 실무 팁

• SSR이라고 항상 빠른 건 아니고, 서버 응답이 느리면 오히려 체감이 나쁠 수 있다.
• CSR이라고 항상 SEO가 불가능한 것도 아니지만, 공개 페이지라면 검증이 필요하다.
• 면접에서는 "어떤 서비스에 더 적합한가"까지 같이 말해야 답이 실무적으로 들린다.
• 하이드레이션, 코드 스플리팅, 캐싱 전략까지 이어서 말할 수 있으면 더 좋다.