577. 서버 사이드 렌더링 (SSR) 컴포넌트 아키텍처 (Next.js, Nuxt.js)

핵심 인사이트 (3줄 요약)

1. 본질: 서버 사이드 렌더링(SSR) 컴포넌트 아키텍처는 클라이언트(브라우저)에서 무거운 JS를 낑낑대며 다운받고 그려내던 SPA(단일 페이지 앱)의 치명적 로딩 딜레이(하얀 화면)와 구글 검색 봇(SEO) 누락의 파국을 막기 위해, Node.js 서버 뱃속에서 HTML 껍데기와 데이터를 1차로 완벽히 조립(렌더링)하여 브라우저에 완성품으로 꽂아주는 역발상 렌더링 기술이다.
2. 가치: 이를 통해 유저는 사이트 접속 후 단 0.1초 만에 예쁜 완성된 화면(FCP)을 보며 이탈률이 급감하고, 뒤이어 몰래 날아온 자바스크립트가 메마른 HTML에 생명력(버튼 클릭 이벤트)을 불어넣는 '하이드레이션(Hydration)' 흑마법을 통해 SPA의 부드러운 앱 감성까지 100% 동시에 쟁취한다.
3. 융합: "서버 부하"라는 옛날 JSP/PHP 시절의 단점을 안고 있으나, Next.js와 React 서버 컴포넌트(RSC) 생태계가 **"무거운 데이터 쿼리 컴포넌트만 서버에서 돌리고, 가벼운 UI 컴포넌트만 클라이언트에서 돌린다"**는 클라이언트-서버 극한의 하이브리드 분업술로 진화하며 현대 프론트엔드의 절대 왕좌로 군림하고 있다.

Ⅰ. 개요 및 필요성 (Context & Necessity)

• 개념: 브라우저 화면(View)을 어디서 만들(Render) 것인가의 싸움.

  • CSR (Client-Side Rendering): 서버는 빈 껍데기 HTML 1장과 JS 100MB 뭉치만 툭 던짐. 브라우저가 JS를 다운받아 그제야 화면을 꾸미고 DB(API)를 찔러 데이터를 채움 (SPA의 뼈대).
  • SSR (Server-Side Rendering): 유저가 접속하면 서버(Node.js)가 DB(API)를 직접 찔러서, 텅 빈 껍데기 HTML 안에 데이터를 예쁘게 다 채워 넣은 **'완제품 HTML'**을 1초 만에 찍어내 브라우저로 쏴줌.

• 필요성 (SPA CSR의 3대 재앙: 하얀 화면, SEO 멸망, 똥폰 차별): 2015년 리액트(React)가 세상을 지배하며 모두가 CSR(SPA)로 갈아탔다. 그런데 쇼핑몰 메인 화면을 열었더니 5초 동안 뱅글뱅글 도는 **'하얀 화면(White Screen of Death)'**이 떴다. 유저 50%가 빡쳐서 나갔다. 구글 검색 로봇(Bot)이 사이트를 긁으러 왔는데 빈 HTML 껍데기밖에 없어서 네이버 검색어 노출이 다 박살 났다(SEO 파탄). 아프리카의 구형 스마트폰 유저는 무거운 JS 100MB를 다운받느라 브라우저가 터졌다. "아 ㅆㅂ 옛날 JSP, PHP 시절엔 화면 바로 떴고 검색도 짱 잘 됐는데! 리액트의 부드러움은 살리면서, 첫 화면 속도랑 검색 노출만 옛날 서버 렌더링처럼 되돌릴 방법 없어?!" 이 피맺힌 갈망이 Next.js(SSR)를 발명하게 했다.

• 💡 비유: CSR은 식당에서 **'밀키트(생고기와 야채)'**를 손님 테이블에 던져주는 것입니다. 손님(브라우저)이 직접 가스불 켜고 요리(JS 실행)를 해야 해서 첫 입을 먹기까지 오래 걸리고, 요리할 줄 모르는 바보 손님(검색 로봇)은 굶어 죽습니다. SSR은 주방장(서버)이 **'다 구워진 완벽한 스테이크(HTML)'**를 접시에 담아 내어오는 것입니다. 손님은 받자마자 0.1초 만에 바로 칼질(FCP)을 시작할 수 있고 냄새(SEO)도 끝내줍니다.

• 등장 배경 및 발전 과정:

  1. 전통적 SSR (JSP/PHP/ASP): 화면 그리는 걸 무조건 백엔드 자바 서버가 다 했다. 새로고침 누를 때마다 화면 전체가 하얗게 깜빡거려서 UX가 최악이었다.
  2. CSR (React / Vue SPA 시대): 2010년대 중반, 폰 앱처럼 깜빡임 없이 부드러운 전환을 위해 프론트(브라우저)한테 화면 그리는 권한을 100% 넘겨버렸다. (SEO, 초기 로딩 박살 남).
  3. Universal / Isomorphic SSR (Next.js / Nuxt.js 현재): "첫 페이지 1방만 서버에서 완제품(SSR)으로 예쁘게 쏴주고, 두 번째 페이지 이동부터는 React가 브라우저 안에서 부드럽게 렌더링(CSR) 쳐서 이어받게 하자!" 장점만 스깐 궁극의 하이브리드 아키텍처가 프론트엔드 천하를 통일했다.

• 📢 섹션 요약 비유: 이 하이브리드(Next.js)는 **'우주선 대기권 돌파'**와 같습니다. 처음 우주로 쏘아 올릴 때(첫 페이지 로딩)는 엄청난 힘이 필요하니 거대한 **'서버 부스터(SSR)'**를 써서 한 번에 궤도에 올려줍니다. 하지만 우주에 도착한 뒤(페이지 이동)엔 부스터를 버리고, 가볍고 날렵한 **'우주선 자체 엔진(CSR)'**으로만 슉슉 날아다니는 완벽한 역할 분담입니다.

Ⅱ. 아키텍처 및 핵심 원리 (Deep Dive)

1. SSR의 영혼, 하이드레이션 (Hydration) 흑마법 💥

면접관이 "Next.js SSR 원리가 뭐죠?" 했을 때 100% 물어보는 핵심 키워드.

• 문제: 서버(Node.js)가 데이터를 채워서 완제품 HTML을 브라우저에 던져줬다. 유저 눈에는 상품 목록과 "결제하기" 버튼이 0.1초 만에 뿅 하고 보였다. 그런데! 유저가 결제 버튼을 광클해도 아무 일도 일어나지 않는다! (껍데기 깡통 상태). 왜? 아직 자바스크립트(이벤트 로직) 코드는 다운로드되지 않았기 때문이다.

• 해결 (Hydration - 물 주기):

  1. 유저가 화면(HTML)을 구경하고 있는 그 찰나의 몇 초 동안, 브라우저는 뒤에서 몰래 무거운 React JS 파일들을 다운받는다.
  2. JS 다운이 끝나면, 브라우저가 방금 띄워놓은 메마른 HTML 뼈대(DOM) 위로 JS 코드(이벤트 리스너, 상태 변수)를 스르륵 물을 스며들게 하듯(Hydrate) 덮어씌운다.
  3. 그 순간 결제 버튼이 활성화(Interactive)되며, 죽어있던 HTML이 살아 숨 쉬는 리액트(React) 앱으로 부활(진화)한다!

• 📢 섹션 요약 비유: 하이드레이션(Hydration)은 **'프라모델 로봇 조립'**과 같습니다. 서버(SSR)는 뼈대와 껍데기가 다 조립된 예쁜 '마징가 Z 깡통(HTML)'을 1초 만에 던져줍니다. 우린 눈으로 보고 와 멋지다! 하죠. 하지만 로봇은 안 움직입니다. 2초 뒤, 뒤늦게 배달된 **'AA 건전지(JavaScript)'**를 로봇 등에 찰칵! 꽂아 넣는 순간(하이드레이션), 눈에 불이 들어오고 팔다리가 징징 움직이기 시작하는(Interactive) 완벽한 심폐소생술입니다.

2. 혁명의 끝판왕: React 서버 컴포넌트 (RSC, React Server Components)

최근(Next.js 13~) 프론트엔드 생태계를 다 뒤집어엎은 사기 템.

• 기존 SSR의 한계: 하이드레이션을 하려면 결국 브라우저가 화면을 채운 모든 JS 코드를 다 다운받아야 했다. 컴포넌트가 10,000개면 JS 용량이 100MB로 뚱뚱해져 하이드레이션하다 핸드폰이 터졌다.
• RSC (React Server Component)의 기적: 아키텍트가 선언한다. "야! 텍스트 덩어리 렌더링하는 Markdown 컴포넌트나, DB에서 데이터 긁어오는 DB_Fetch 컴포넌트는 브라우저(클라이언트)로 아예 JS 코드를 1바이트도 다운시키지 마!! 오직 서버(Node.js) 뱃속에서만 실행(렌더링)되고 쿨하게 뒈져버려라! 브라우저엔 그 결과물인 HTML 텍스트 쪼가리만 던져라!"
• 결과: 결제 버튼 같이 마우스 클릭(이벤트)이 필요한 놈만 클라이언트 컴포넌트로 냅두고 브라우저로 보낸다. 유저가 다운받는 JS 번들 용량이 1/10로 극한 다이어트 되며, 프론트엔드 컴포넌트가 서버(Backend)와 클라이언트(Frontend)라는 두 우주로 나뉘어 완벽하게 분업하는(Zero-Bundle-Size) 메가 아키텍처가 열렸다.

Ⅲ. 융합 비교 및 다각도 분석

1. 렌더링 아키텍처 3형제 최종 비교 (CSR vs SSR vs SSG)

과목 융합 관점

• 백엔드 아키텍처 (BFF, Backend For Frontend 융합): 543장에서 배운 BFF가 SSR과 환상의 짝꿍이다. Next.js 서버는 단순히 화면 HTML만 구워주는 놈이 아니다. 뱃속에 Node.js 런타임을 품고 있어서, 백엔드 MSA(결제, 쿠폰) 서버 50대를 다이렉트로 찔러 데이터를 뭉쳐오는(Aggregation) 훌륭한 문지기(BFF) 역할을 100% 대리 수행한다. 브라우저가 백엔드를 여러 번 찌르는 네트워크 오버헤드 지옥을, Next.js 서버(AWS 백엔드 인프라와 핑 1ms 컷)가 대신 몽땅 찌른 뒤 예쁜 HTML로 구워 브라우저로 1방에 쏴주는 완벽한 디커플링 콤보다.

• 클라우드 네트워크 (CDN 캐싱의 딜레마): SSR의 최대 약점은 "서버가 렌더링 치느라 CPU가 터진다"는 것이다. 아키텍트는 이걸 K8s 파드 무한 오토스케일링으로 막으면 돈이 다 털린다! 반드시 CloudFront 같은 CDN(531장 연계) 에지(Edge) 서버에 렌더링 된 HTML 껍데기를 30초 단위로 캐싱(Cache-Control: s-maxage=30) 박아둬야 한다. 유저 1만 명이 와도 1명만 서버를 찌르고 나머지 9,999명은 CDN에서 캐시된 HTML을 0.01초 만에 훔쳐 가는 초경량 방어막(Caching Strategy)을 치지 않으면 SSR 서버는 디도스 맞은 것처럼 파멸한다.

• 📢 섹션 요약 비유: CSR은 **'IKEA 조립 가구(재료+설명서 던져주고 니가 만들어)'**입니다. SSR은 **'주문제작 가구(고객이 주문할 때마다 공장에서 뚝딱뚝딱 다 만들어서 완제품 배송)'**입니다. 만들기 귀찮은 고객(SEO)은 좋아하지만, 공장(서버)은 주문 1만 개 들어오면 터지죠. SSG(정적 생성)는 **'기성품 가구(공장에서 이미 10만 개 만들어 창고에 쫙 쌓아놓고 바로 빼줌)'**입니다. 극강의 스피드입니다.

Ⅳ. 실무 적용 및 기술사적 판단

실무 시나리오

1. 시나리오 — 하이드레이션(Hydration) 미스매치로 인한 '번쩍임(Flicker)'과 레이아웃 쉬프트(CLS) 대재앙: 주니어 개발자가 "현재 시간(Now)"을 띄우는 코드를 짰다. SSR(서버)이 화면을 그릴 때 서버 시간은 오전 10:00 이었다. 1초 뒤 브라우저에 HTML이 떴다. 그런데 브라우저(클라이언트)가 하이드레이션(JS 실행) 하려고 폰 시계를 보니 오전 10:01 이었다! React가 "어? 서버가 준 HTML(10:00)이랑, 내가 지금 가진 데이터(10:01)가 다르네?!" ➡ **React가 대분노하며 브라우저에 그려져 있던 완벽한 HTML을 폭파(DOM 파괴)시켜버리고 처음부터 빈 화면에 다시 화면을 우적우적 그려버리는 최악의 하이드레이션 에러(Hydration Mismatch)**가 터졌다. 화면이 번쩍번쩍 거리고 클릭이 막혔다.

   • 아키텍트의 해결책: Two-Pass Rendering 통제 및 서버-클라이언트 상태 일치성(Determinism) 헌법 강제다. SSR과 CSR의 환경 차이(시간, 로컬 스토리지, Window 객체 유무)를 개발자가 뼈저리게 깨달아야 한다. 서버는 윈도우(브라우저)가 아니니까 window.localStorage 치면 100% 뻗는다. 아키텍트는 룰을 건다. "브라우저 전용 데이터(시간, 로컬스토리지)는 무조건 useEffect (마운트 된 이후) 안에서만 렌더링 쳐라! 첫 번째 렌더링(SSR) 때는 무조건 서버나 클라이언트나 100% 동일하게 그릴 수 있는 깡통(Null) 데이터만 넘겨줘서 하이드레이션 아다리를 맞추고, 2번째 패스(CSR)에서 진짜 클라이언트 데이터를 덮어씌워라!" 이 렌더링 2단계 분리술을 익히지 못하면 SSR의 번쩍임 늪에서 평생 못 빠져나온다.

2. 시나리오 — '뚱뚱한 API 병목'으로 인한 SSR TTFB(첫 바이트 도달 시간) 10초 무한 로딩 지옥: 백엔드 API 3개를 찔러 상품, 리뷰, 장바구니 데이터를 모아오는 SSR 메인 페이지를 짰다. 리뷰 API가 렉 걸려서 응답이 10초 걸렸다. CSR(SPA) 이었으면 상품 화면이라도 1초 만에 뜨고 리뷰 칸만 빙글빙글(Loading) 돌았을 텐데, SSR 서버는 "HTML 완제품을 다 채우기 전까진 절대 브라우저로 1방울도 안 뱉어줄 거야!"라며 10초 내내 브라우저 화면을 하얀색 빈 창으로 멈춰 세웠다. 결국 이탈률 90% 달성하고 회사가 파산했다 (SSR Blocking 딜레마).

   • 아키텍트의 해결책: 스트리밍 SSR (Streaming SSR)과 Suspense의 융합 구원이다. 다 구워질 때까지 기다리는 건 멍청한 짓이다! 아키텍트는 React 18의 Suspense 아키텍처로 찢어버린다. 빨리 로딩되는 '상품(1초)'은 SSR 서버가 먼저 HTML 청크(Chunk)로 뜯어서 브라우저로 즉시 발사(Streaming)한다! 유저는 상품 화면을 바로 본다. 느려 터진 '리뷰(10초)'는 Fallback(회색 뼈대 스켈레톤) 껍데기만 먼저 던져놓고, 서버가 뒤에서 10초 뒤 API 응답받으면 그제야 쪼가리 HTML을 파이프라인(HTTP 스트리밍)으로 스윽 밀어내어 브라우저 구멍 난 자리에 찰칵 끼워 넣는다. SSR의 SEO 꿀을 빨면서도, CSR 수준의 빠른 화면 체감 속도(UX)를 쟁취하는 모던 프론트엔드의 최종 병기다.

도입 체크리스트

• 비즈니스적: "이 도메인이 진짜로 SEO(검색 노출)와 FCP(첫 화면 노출 속도 0.1초 컷)가 회사의 매출(Conversion)을 쥐락펴락하는 B2C 커머스 코어인가?" 사내 직원용 인사/재무 어드민(B2B) 관리자 페이지를 만들면서 "아 최신 기술 Next.js SSR 짱짱!" 하고 도입하는 순간 개발팀장 뺨을 때려야 한다. 검색 로봇이 사내 보안망을 긁을 일도 없고, 직원들은 첫 화면 로딩 3초 기다린다고 퇴사하지 않는다. 사내 어드민 페이지에 SSR 떡칠하면 무거운 서버 Node.js 비용만 펑펑 낭비되고 복잡한 하이드레이션 상태 관리(State Management) 버그로 유지보수만 지옥이 된다. "돈 버는 퍼블릭(Public) B2C 화면엔 무조건 SSR(Next.js), 폐쇄적인 B2B/어드민 화면엔 무조건 쌩 CSR(React SPA 깡통 배포)" 이것이 자본주의 클라우드의 가성비 절대 헌법이다.
• 기술적: 서버(Node.js)의 램/CPU 누수(Memory Leak)를 통제할 데브옵스 역량이 있는가? CSR(리액트) 땐 유저 폰 브라우저가 다 계산해 줘서(Offloading) 서버는 API 통신만 뚫어주면 됐다(서버 CPU 개꿀). SSR로 갈아타면? 유저 10만 명의 화면 그리는 렌더링 연산(CPU/RAM)을 내 K8s Node.js 서버 뱃속에서 쌩으로 10만 번 처맞으며 구워내야 한다! 컴포넌트 하나 잘못 짜서 렌더링에 병목 나면 서버 메모리가 터져서 100대가 도미노로 셧다운(OOM) 된다. SSR 서버를 띄운다는 건, 기존 백엔드 인프라만큼의 강력한 K8s 오토스케일링(HPA)과 메모리 덤프 디버깅 체계를 구축해야 한다는 십자가를 짊어지는 것이다.

안티패턴

• "Redux(전역 상태) 상점을 SSR 서버 렌더링 단계에서 글로벌(Global) 객체로 박아버려서 10만 유저 개인정보 짬뽕 치기 (Cross-Request State Pollution)": CSR에선 유저 폰(브라우저) 안에서 Redux 스토어를 const store = createStore() 하나만 덜렁 파서 싱글톤으로 쓰면 편했다. (어차피 폰 주인 1명 꺼니까). 그 버릇 그대로 SSR (Node.js) 서버 코드 전역 변수에 const store 박아놨다 치자. A 유저가 접속해서 장바구니에 '팬티' 넣고 서버가 렌더링 쳤는데, 0.1초 뒤 B 유저가 접속했는데 전역 변수(Store)가 공유돼서 B 유저 화면에도 '팬티'가 담겨서 렌더링 되어 내려가는 끔찍한 개인정보(Session) 대참사가 터진다! "명심해라. SSR 서버(Node.js) 환경에선 10만 명의 요청(Request) 스레드가 1개의 런타임 메모리를 더럽게 공유한다. 절대 전역(Global) 변수에 상태를 박지 말고, 무조건 요청 1번당 새 스토어(Store) 인스턴스를 갈아 끼워(Per-Request Isolation) 철저한 샌드박스를 구축해야 감방을 안 간다."

• 📢 섹션 요약 비유: 전역 변수에 상태를 박는 건, **'레스토랑 주방장(SSR 서버)이 100명의 손님 요리를 볶는데 1개의 거대한 프라이팬(전역 변수)을 안 씻고 계속 재탕해서 쓰는 짓'**입니다. 1번 손님이 불닭 볶은 프라이팬에 그대로 2번 손님 까르보나라를 볶아서 매워 죽는 사태(정보 오염)가 터집니다. SSR 렌더링 시엔 무조건 1요청당 1개의 깨끗한 새 프라이팬(지역 변수/Per-Request 인스턴스)을 꺼내서 요리(렌더링)하고 버리는 것이 생명줄입니다.

Ⅴ. 기대효과 및 결론

정량/정성 기대효과

미래 전망

• 스트리밍 SSR과 React Server Components(RSC)의 우주 통일: 프론트엔드의 패러다임이 "CSR ➡ SSR"을 거쳐 이젠 아예 "클라이언트 JS 다운로드 0바이트"를 꿈꾸는 **RSC(React Server Components)**로 미친 듯이 질주하고 있다. 버튼 클릭, 상태 관리(State)가 필요한 컴포넌트 빼고 모든 뼈대(Markdown, Layout, DB Fetch) 코드를 아예 브라우저로 쏘지 않는다. 서버 뱃속에서만 실행되고 죽는다. JS 번들 용량이 마법처럼 90% 증발하며, 브라우저는 솜털 같은 가벼움으로 돌아가는 'Zero-JS 아키텍처'의 과도기가 차세대 프론트 프레임워크(Next.js 14 App Router)를 멱살 잡아 끌고 있다.
• Edge SSR (엣지 컴퓨팅 렌더링)의 상륙 (Cloudflare/Vercel Edge): SSR의 치명타는 "한국에서 미국 서버(Node.js) 찔러서 HTML 구워올 때까지 핑 100ms 걸린다"는 거다. 이걸 타파하기 위해 람다(Lambda) 같은 무거운 중앙 서버를 버리고, 한국 통신사 기지국(Edge) 옆에 심어놓은 V8 Isolate 엔진(Vercel Edge Functions, Cloudflare Workers)에서 유저가 접속하자마자 0.001초 만에 엣지 단에서 SSR HTML을 구워내서 쏴버리는 '글로벌 분산 초광속 렌더링' 시대가 열렸다. 우주 어디서 접속하든 10ms 안에 구워진 완제품 화면을 때려 맞는 지구촌 No-Latency 마술이다.

참고 표준

• Next.js (Vercel) / Nuxt.js: React와 Vue 진영에서 CSR(SPA)의 검색봇 멸망 똥 닦기를 위해 탄생했다가, 이젠 아예 프론트엔드 생태계 그 자체를 독재하고 있는 우주 1티어 하이브리드(SSR/SSG) 메타 프레임워크 제국.
• React Server Components (RSC) Architecture: 리액트 코어 팀이 "야, 클라이언트에서만 돔(DOM) 돌리지 말고 아예 백엔드 서버에서 리액트 돌려서 결과만 주자!"라고 판을 뒤집어엎으며 프론트엔드/백엔드 경계를 다시 허물어버린 2024년 넥스트-젠 렌더링 헌법.

서버 사이드 렌더링 (SSR) 컴포넌트 아키텍처는 소프트웨어 공학이 **'순수한 클라이언트 위임(SPA)'이 낳은 극단적 다운로드의 폭압을 반성하고, 서버(Server)의 강력한 심장 엔진과 브라우저(Client)의 부드러운 살결을 예술적으로 꿰매어 붙인 렌더링 역사의 가장 완벽한 변증법적 진화(정반합)**다. 2010년대 힙스터 개발자들은 "서버에서 HTML 굽는 건 낡아빠진 JSP 시대의 똥"이라며 모든 짐을 유저의 연약한 스마트폰(CSR)에 욱여넣었다. 그 오만함의 대가는 하얀 빈 화면(White Screen)과 검색 엔진으로부터의 완벽한 고립(SEO 파멸)이었다. Next.js는 도끼를 들어 이 극단을 팼다. "화면의 뼈대는 압도적인 깡패 CPU를 가진 클라우드 서버(Node.js)가 DB를 1ms로 직빵 찔러서 1초 만에 풀파워로 구워내라(SSR). 유저의 눈을 1초 만에 사로잡아라. 그리고 유저가 예쁜 화면에 취해있는 그 찰나의 순간 뒤통수에, 조용히 자바스크립트라는 생명수(Hydration)를 스르륵 들이부어라." 딱딱한 정적(Static) 뼈대가 그 물을 머금고 0.1초 만에 부드럽게 살아 움직이는 세포(Interactive SPA)로 부활하는 기적. 이것이 서버의 무거운 책임과 클라이언트의 유려한 감성을 한 캔버스에 녹여낸 프론트엔드 연금술의 최고봉이다.

• 📢 섹션 요약 비유: 이 하이드레이션(SSR)의 마술은, **'박물관의 마네킹(HTML)'**이 밤이 되면 살아나는 것과 같습니다. 서버는 유저에게 뼈대와 옷이 완벽하게 입혀진 엄청 예쁜 마네킹을 1초 만에 딱 던져줍니다. 유저는 "우와 예쁘다!" 하고 쳐다봅니다(빠른 FCP). 하지만 만지면 돌덩이입니다(클릭 안 됨). 2초 뒤 하늘에서 **'마법의 가루(JS Bundle)'**가 스르륵 뿌려져 마네킹에 스며들고(Hydration), 마네킹은 진짜 사람처럼 숨을 쉬고 관절을 꺾어 춤(Interactive 앱)을 추기 시작합니다. 유저는 마네킹이 살아 움직일 때까지의 지루한 제작 과정을 1도 기다리지 않은 완벽한 관람 경험을 얻습니다.

📌 관련 개념 맵 (Knowledge Graph)

👶 어린이를 위한 3줄 비유 설명

1. 옛날 리액트 앱(CSR)은 식당에서 손님한테 "도마랑 고기, 채소 줄 테니까 니들이 직접 썰어서 볶아 먹어 ㅋ" 해서 손님들이 배고파서 엉엉 우는 짱 느린 식당이었어요(하얀 화면 렉!).
2. 그래서 똑똑한 식당 주방장(SSR 서버)이 **"아 안 되겠다! 내가 주방에서 완벽하게 맛있는 스테이크(HTML)를 다 구워서 접시에 올려 1초 만에 손님상에 내갈게!"**라고 방식을 싹 바꿨어요.
3. 손님(유저)은 자리에 앉자마자 맛있는 요리를 보며 감동해요(짱 빠른 화면!). 그리고 몰래 요리 위로 마법 소스(자바스크립트/하이드레이션)를 스윽 뿌려주면 요리가 살아서 부드럽게 춤까지 추는 진짜 무적의 짱 빠른 화면 만들기 마법을 'SSR'이라고 부른답니다!