SSR, 왜 이런 방식이 필요한 걸까

Hushed_Mind·2025년 4월 28일
post-thumbnail

SSR이 뭐고, CSR이 뭔지 설명하는 글은 이미 많다.
나도 많이 봤다. 근데 이상하게, 머릿속에 확실히 남지 않았다.
"아 서버에서 렌더링하는 거야, 브라우저에서 하는 거야" 말로야 할 수 있었는데,
"왜 이런 방식을 쓰는지",
"그 구조가 실제로 어떤 문제를 풀려고 나온 건지"
이건 몸으로 체득되지 않았다.

그래서 이번엔, 남한테 설명하려고 하지 않고,
그냥 나 스스로 납득할 때까지 생각한 과정을 적어보려고 한다.


렌더링, 결국 시작점을 어디로 잡느냐의 문제

처음으로 떠오른 건 이거였다.
"웹페이지가 필요하다"라는 요구가 있을 때,
그 화면을 서버가 미리 만들어서 줄 거냐,
아니면 브라우저가 받아서 스스로 만들게 할 거냐
이 두 가지 방법밖에 없다는 거다.

그리고 이 선택 하나로, 모든게 달라진다.

서버가 미리 다 만들어서 주면, 브라우저는 그냥 받아서 보여주기만 하면 되니까 빠르겠지.
하지만 서버는 매번 열심히 페이지를 만들어야 한다.
그리고 브라우저는 받은 걸로는 상호작용을 잘 못할 거다.
자기가 직접 조립한 게 아니니까.

반대로 브라우저가 직접 화면을 만들게 하면, 서버는 간단해진다.
그냥 껍데기 HTML 주고, 스크립트 파일만 넘기면 된다.
근데 브라우저는 처음에 그걸 다 해석하고, 만들어야 하니까, 초기 로딩은 느릴 수밖에 없다.


SSR이 풀려고 했던 문제

생각해보면, 옛날 웹은 거의 다 서버 렌더링이었다.
그때는 CSR 같은 개념 자체가 없었다. HTML을 만들어서 보내는 게 당연했으니까.

근데 요즘은 사용자 경험이 너무 중요해졌다. 버튼 누르면 바로 반응해야 하고,
페이지 이동할 때 새로고침 같은 거 없이 부드럽게 넘어가야 하고.
그래서 SPA(Single Page Application)가 등장했다. CSR 중심으로.

그런데, CSR만 하니까 문제가 생겼다.

  • 첫 화면이 너무 늦게 뜬다.
  • 빈 화면을 오래 보여준다.
  • 검색 엔진이 페이지 내용을 제대로 못 읽는다.

결국,
"초기 화면은 빨라야 한다",
"검색 엔진도 컨텐츠를 읽을 수 있어야 한다"
이걸 다시 해결해야 했다.

그래서 다시 서버에서 미리 화면을 만들어주는 방식을
다시 끌어온 거다. 그게 바로 SSR.


SSR을 쓰면 좋은 점이 뭔가

처음에 이걸 생각했을 때, 제일 먼저 떠오른 건
"빠른 첫 화면"이었다.

SSR은 브라우저가 별로 할 일이 없다.
그냥 서버가 준 완성된 HTML을 바로 띄우면 된다.
그러니까 사용자 입장에서는 클릭하자마자 바로 화면이 뿅 하고 나온다.

특히 모바일 네트워크 느린 환경에서는 이 차이가 진짜 크다.

또 하나,
"SEO".

서버가 준 HTML 안에는 이미 컨텐츠가 다 들어있다.
텍스트, 이미지, 메타데이터 다.
검색 엔진 로봇이 그걸 읽어가기 정말 쉽다.

만약 CSR이라면?
처음엔 아무것도 없는 빈 껍데기다.
크롤러가 JS를 실행해서 동적으로 만들어지는 화면을 기다려야 한다.
근데 모든 크롤러가 그걸 잘 지원하는 건 아니니까,
결국 노출에 손해를 볼 수 있다.


그렇다고 SSR이 무조건 좋은 건 아니다

생각할수록 느꼈다.
SSR도 만만한 게 아니다.

첫 번째로,
서버 부하 문제가 있다.

CSR은 요청이 오면 그냥 JS 파일 던져주면 끝이다.
근데 SSR은 요청 올 때마다, HTML을 새로 만들어야 한다.
어떤 유저가 들어왔는지, 그 사람 데이터에 따라 화면을 조합해야 하고,
그걸 전부 서버가 실시간으로 해야 한다.

이건 진짜 서버 리소스를 많이 잡아먹는다.
유저가 많아질수록 서버는 버거워진다.

두 번째,
상호작용 문제다.

서버가 HTML은 줄 수 있지만, 거기엔 아직 자바스크립트 기능이 없다.
클릭 이벤트 같은 건 동작하지 않는다.
결국 브라우저가 추가로 JS 파일을 다운받고,
HTML에 다시 기능을 붙이는 작업(hydration)을 해야 한다.

이게 느려지면 초기 화면은 떴는데
버튼 눌러도 아무 반응 없는 이상한 상황이 생길 수 있다.

(요즘엔 이걸 줄이려고 Partial Hydration 같은 것도 연구되고 있다.)


결국 내린 결론

SSR이든 CSR이든,
단순히 "이게 무조건 낫다"는 없다.

서비스 성격에 따라 다르다.

  • 블로그, 커머스, 뉴스 사이트처럼
    빠른 초기 로딩, SEO가 중요한 경우 → SSR이 낫다.

  • 대시보드, 복잡한 앱형 서비스처럼
    실시간 반응성과 부드러운 전환이 중요한 경우 → CSR이 낫다.

그리고 현대 웹은 둘 중 하나만 고집하지 않는다.

초기에는 SSR로 빠르게 보여주고,
그 이후엔 CSR처럼 부드럽게 조작하는 하이브리드 방식을 쓴다.


진짜로 느낀 것

처음엔 SSR, CSR이 그냥 "렌더링 방식"의 차이인 줄 알았다.
근데 진짜 고민하고 정리해보니까,
이건 단순 기술 싸움이 아니라
"사용자가 언제, 어떻게 화면을 만나야 하는가"에 대한
전략적인 선택이었다.

기술은 결국, 사용자 경험을 어떻게 설계할까를 결정하는 수단이라는 걸
이번에 진짜 몸으로 느꼈다.

profile
개발 공부 블로그

0개의 댓글