🔎 Overview

 Next.js 를 이용해 프론트엔드 실습을 진행 중, 헷갈리는 부분이 생겼다. 필자가 알고 있는 SSR 과 CSR 의 개념이 실습 중 혼동을 일으키기 시작했다.

 서버 사이드 렌더링은 서버 측에서 렌더링을 해서 보여주는 거고, 클라이언트 사이드 렌더링은 브라우저에서 렌더링을 해서 보여준다 라고만 이해하고 있었다.
그러다보니, ' Next.js 에서 JSX 와 JavaScript 를 사용해서 코드를 작성하면 CSR 이다' 라고 잘못 이해하고 있었다.

 잘못된 정보에 대한 인식을 개선한 김에, 이후에는 절대 헷갈리지 않도록 관련 개념에 대한 기록을 남겨두기로 했다.

---

1️⃣ SSR

• Server-Side Rendering - 서버 사이드 렌더링
• 서버에서 웹 페이지 렌더링을 담당
• 클라이언트로부터 페이지를 요청받으면 완성된 정적 + 동적 HTML 파일을 클라이언트에게 반환
  • 기본적인 정적 데이터인 HTML , JSX 파일은 그대로 반환
  • 서버에 동적인 데이터를 요청한 경우, 해당 API 를 호출한 후의 응답값(동적 데이터) 또한 HTML, JSX 파일에 담아서 반환
  • 즉, 데이터를 모두 채워 넣은 완전한 HTML 파일 반환
• 서버 데이터 기반 UI 구성 담당
  
  

❓ 장점

1. 빠른 초기 로딩 성능
   • HTML 파일 자체가 모든 컨텐츠를 이미 포함
   • 클라이언트(브라우저)는 이 페이지를 바로 렌더링하기만 하면 됨
2. SEO 최적화
   • 검색 엔진 크롤러가 페이지의 모든 콘텐츠를 쉽게 읽을 수 있음
   • 특정 키워드에 대한 검색 결과 노출에 유리
     
     

❗ 단점

1. 느린 페이지 전환 속도
   • 페이지 이동 시마다, 서버는 HTML 을 새로 렌더링 후 전송
   • 로직 처리에 시간이 다소 소요된다면, 응답받기 전까지 페이지 로딩
   • 이는 불쾌한 사용자 경험을 초래
2. 서버 부하의 증가
   • 매번 서버 API 를 호출하므로, 서버 호출 횟수 증가
   • 트래픽이 많을수록 서버 자원은 많이 소모
   • 서버 부하로 인한 성능 저하, 심하면 서버 다운까지 초래

---

2️⃣ CSR

• Client-Side Rendering - 클라이언트 사이드 렌더링
• 클라이언트(브라우저)에서 페이지 렌더링을 담당
• 웹 페이지의 모든 구성 요소가 JavaScript 에 의해 동적으로 생성
• UX 및 사용자 인터렉션 담당
  
  

❓ 장점

1. 빠른 페이지 전환
   • 서버 API 호출 이전에 페이지를 먼저 렌더링
   • 즉, 서버에 데이터가 저장되기도 이전에, 바로 UI 에 먼저 적용
   • 낙관적 업데이트
2. 풍부한 사용자 경험
   • 사용자에게 즉각적인 피드백을 제공
   • 사용자의 UX 극대화
     
     

❗ 단점

1. 초기 로딩 속도 저하
   • CSR 은 사용자에게 해당 컴포넌트의 JavaScript 를 모두 전송
     • 컴포넌트가 많아질수록 초기 다운로드 용량 증가
   • 서버로부터 받은 HTML 에 JavaScript 를 연결하여 이벤트 리스너를 등록
     • 이를 하이드레이션 이라고 함
     • 하이드레이션에 필요한 작업 증가로 인한 인터랙션 소요 시간 증가
2. SEO 효율성 감소
   • JavaScript 기반이므로, 완성된 HTML 파일을 제공하는 SSR 방식에 비해 낮은 효율
     
     

💡 낙관적 업데이트의 이면

• 가상 시나리오
  1) 사용자가 좋아요 버튼 클릭
  2) 좋아요 숫자 증가 및 버튼 액티브 UI 제공
  3) 서버 API 호출
  4) API 는 10분 대기 후 해당 로직 실행
  5) 10분 후 해당 로직 수행 중 에러 발생
  6) 좋아요 클릭 인터랙트 초기화 및 에러 메시지 표시

• 이처럼, 빠른 반응성을 제공하는 낙관적 업데이트이지만 추후 에러 발생 시 뒤늦은 에러 응답 발생
• 이에 따른 불쾌환 사용자 경험 제공
  
  

⚒️ 해결 방안

1. 타임아웃 설정
   • 서버 응답을 기다리는 최대 시간 설정
   • UX 저하 방지를 위해, 납득할 정도의 처리 시간 한도 설정
2. 로딩 상태 사용
   • 서버 응답이 오기 전까지, 페이지에 로딩 중임을 알리는 상태 추가
   • 빠른 응답성이라는 장점을 로딩 중 상태 표시에 사용하지만, 그만큼 안정적인 사용자 경험 제공
3. 백그라운드 재시도
   • 서버 요청 실패시, 에러 표시 대신 백그라운드로 요청 자동 재시도

---

3️⃣ SPA (Single-Page Application)

• 단일 페이지 어플리케이션
• 페이지 이동 시마다 서버에 전체 페이지를 요청하는 기본 방식과 달리, 최초 페이지 접근 한 번만 정적 리소스를 다운로드
  • 이후 상호작용 발생시, 페이지 새로고침을 하지 않고 JavaScript 로 필요한 데이터만 서버에서 비동기적으로 호출
  • 브라우저 캐싱을 통해 다운로드 리소스들은 재활용
  • 첫 로딩은 느릴 수 있어도, 이후 페이지 전환은 매우 빠름
• 이렇게 동적 업데이트 렌더링 수행
• CSR 방식을 극대화한 웹 애플리케이션 형태
  
  

---

4️⃣ Next.js 에서의 렌더링

• Next.js 는 SSR 과 CSR 을 함께 사용하는 하이브리드
• "use client" 사용 유무에 따라 SSR 과 CSR 을 구분
  • "use client" 사용 : CSR - 클라이언트 컴포넌트 렌더링
  • "use client" 미사용 : SSR - 서버 컴포넌트 렌더링
    
    

📌 "use client"

• 클라이언트 컴포넌트로 정의한다는 의미
• 브라우저만 사용할 수 있는 기능을 사용할 때 사용
• React Hooks을 사용하는 경우
  • ex) use() , useEffect() , useRouter() ...
• JavaScript 로 등록된 이벤트 핸들러가 존재하는 경우
  • ex) onClick() , onSubmit() , onChange() ...
• 브라우저 API를 사용하는 경우
  • ex) window.scrollTo() , document.title ...
    
    

💡 a 🆚 router 🆚 Link

• JavaScript 에서는 Link 나 <a> , router 등으로 페이지 이동 지원
  
  

🥇 <a>

• 브라우저 기본 링크 동작
• 클릭 시 서버에 새로운 페이지 요청
• 서버는 해당 페이지의 새로운 HTML 응답

• SSR

• 페이지 이동 이후, 해당 페이지의 "use client" 유무에 따라 CSR 추가
• 즉, SSR 로 시작하여 필요에 따라 CSR 추가로 사용자 인터랙션 제공
  
  

🥈 router

• JavaScript 이벤트 핸들러 내부에서 사용
• 페이지 전체를 새로고침하는 게 아니라, 필요한 데이터만 호출하여 페이지 업데이트

• CSR

• 즉, CSR 로 시작하여 사용자 인터랙션으로 인해 페이지가 이동되고, 이후 SSR 로 새로운 콘텐츠 응답
  
  

🥉 <Link>

• SPA 방식의 페이지 이동 지원
• 클릭 시 새로운 페이지 요청이 아닌, Next.js 가 미리 다운로드해 둔 필요한 JavaScript 및 데이터만으로 페이지 업데이트
  • 이렇게 다운로드 리소스를 미리 가져오는 것을 프리패칭(Prefetching) 이라고 함
• router 와 마찬가지로 새로고침 없이 페이지 전환

• SSR + CSR (하이브리드)

• SSR 로 초기 페이지 렌더링 이후, <Link> 페이지 이동 시에는 CSR 로 부드러운 페이지 전환
• Next.js 의 기본 제공 렌더링 방식으로, SPA 의 장점들을 모두 누릴 수 있음

---

검수) Google Gemini ( https://gemini.google.com/app )