Day 8 Weekly review

[yoorli]

🇶 웹 페이지 렌더링 방식 CSR, SSR, SSG, ISR 각각의 특징과 각 방식을 어떤 상황에 사용하면 좋을지 설명해 주세요.
🇶 리액트만 사용할 때와 비교해 Next.js를 사용하는 이유에 대해 설명해 주세요.

[yoorli]

추가 질문:
CSR의 SEO 단점을 보완할 수 있는 방법에는 어떤 것들이 있을까?
SSR 방식은 SEO에 유리하지만, 모든 웹사이트에서 SSR을 사용하지 않는 이유는 무엇일까?
ISR을 사용할 때 데이터 변경 주기를 설정할 수 있는데, 이 값을 너무 짧거나 길게 설정하면 각각 어떤 문제가 발생할 수 있을까?

---

1. CSR의 SEO 단점을 보완하는 방법
   CSR(Client-Side Rendering)은 기본적으로 SEO에 불리한데, 이유는 초기 페이지 로딩 시 HTML이 비어 있어서 크롤러가 콘텐츠를 제대로 읽지 못할 수 있기 때문임. 이를 보완하는 방법은 다음과 같음.

   • Pre-rendering: HTML을 미리 렌더링하여 제공하는 방식. react-snap, prerender.io 같은 도구를 활용할 수 있음.
   • Dynamic Rendering: 검색 엔진 봇이 방문했을 때만 SSR된 HTML을 제공하고, 일반 사용자에게는 CSR을 제공하는 방식. rendertron 같은 도구를 사용함.
   • Server-Side Rendering(SSR) 도입: 페이지의 중요한 콘텐츠를 서버에서 미리 렌더링하여 제공하면 SEO 문제를 해결할 수 있음.
   • ncremental Static Regeneration(ISR): 일부 페이지는 미리 정적 생성하고, 일정 시간마다 다시 렌더링하는 방식.
   • 메타 태그 동적 설정: react-helmet 또는 next/head 등을 사용하여 SEO 메타 태그를 동적으로 업데이트할 수 있음.
   • 사이트맵 및 구조화된 데이터 제공: robots.txt, sitemap.xml을 작성하고, Schema.org 기반의 구조화된 데이터를 제공하여 검색 엔진이 더 잘 이해할 수 있도록 함.

2. SSR이 모든 웹사이트에서 사용되지 않는 이유
   SSR(Server-Side Rendering)은 SEO와 초기 페이지 로딩 속도에서 유리하지만, 몇 가지 단점이 있어서 모든 사이트에서 사용하지 않음.

   • 서버 부하 증가: 매 요청마다 서버에서 HTML을 생성하므로 트래픽이 많을 경우 서버 부담이 큼.
   • TTVB 증가: Time to First Byte(TTFB)가 증가할 수 있음. 즉, 서버에서 HTML을 생성하는 시간이 필요하므로 응답이 느려질 수 있음.
   • 캐싱 어려움: 정적인 페이지와 다르게 SSR된 페이지는 매번 새로 생성되므로 CDN 캐싱이 어렵고, 성능 저하 가능성이 있음.
   • 개발 복잡성 증가: 데이터 페칭을 서버에서 처리해야 하므로 클라이언트에서의 상태 관리와 다르게 구현해야 함.
   • 유저 인터랙션 지연: CSR 기반의 앱보다 초기 페이지가 렌더링될 때까지 시간이 걸릴 수 있음.

   이런 이유로, SEO가 필수적인 일부 페이지(예: 블로그, 문서 사이트 등)에서는 SSR을 사용하지만, 대부분의 웹앱에서는 CSR이나 ISR을 선호함.

3. ISR에서 데이터 변경 주기를 너무 짧거나 길게 설정할 때 발생하는 문제
   ISR(Incremental Static Regeneration)은 특정 페이지를 정적으로 생성하고, 일정 주기마다 다시 빌드하는 방식임. 이때 **데이터 변경 주기(revalidate 값)**를 적절히 설정해야 함.

   너무 짧게 설정하면 발생하는 문제:

   • 서버 부하 증가: 짧은 주기로 페이지를 재생성하면 서버에서 자원을 과도하게 소모할 수 있음.
   • 성능 저하: 캐싱 효과를 거의 누리지 못하게 되어 빠른 응답 속도의 이점을 잃음.
   • 데이터 변경이 자주 일어나지 않는 페이지에서는 불필요한 재생성이 발생하여 낭비가 심함.

   너무 길게 설정하면 발생하는 문제:

   • 오래된 데이터 제공: 중요한 데이터가 자주 변경되는데도 반영되지 않으면 사용자에게 오래된 정보가 제공될 수 있음.
   • 최신 콘텐츠 반영 지연: 블로그, 뉴스 같은 경우 최신 글이 즉시 반영되지 않음.
   • 사용자 경험 저하: 쇼핑몰 같은 경우 재고가 변했는데도 오랫동안 변경되지 않으면 고객 불편이 발생할 수 있음.

   적절한 주기 설정 방법

   • 데이터가 자주 변하는 서비스 : 1~5분 정도의 짧은 주기 (revalidate: 60 - 300)
   • 블로그, 문서 등 업데이트가 자주 필요 없는 서비스: 1시간 이상 (revalidate: 3600 이상)
   • 실시간 데이터를 제공해야 하는 경우: ISR보다는 SSR이나 API 요청을 통한 CSR을 고려

   ISR을 적용할 때는 해당 서비스의 데이터 갱신 빈도에 따라 적절한 주기를 설정하는 것이 중요함.

[yoorli]

추가 질문:
Next.js에서 getServerSideProps와 getStaticProps의 차이점은 무엇이며, 각각 언제 사용하는 것이 좋을까?
Next.js의 자동 코드 분할(Code Splitting)이 성능 최적화에 어떻게 도움이 되는지 설명해줄 수 있을까?
Next.js의 API Routes를 활용할 때, Express 같은 별도의 백엔드 서버를 사용하는 것과 비교했을 때 어떤 장점과 단점이 있을까?

---

1. getServerSideProps와 getStaticProps의 차이점 및 사용 시점
Next.js에서는 페이지별 데이터를 가져오는 방법으로 getServerSideProps와 getStaticProps를 제공함. 두 방법의 차이점과 각각의 사용 시점은 다음과 같음.

✅ getServerSideProps (SSR - Server-Side Rendering)

• 요청이 들어올 때마다 실행되며, 매 요청마다 데이터를 서버에서 가져와 페이지를 렌더링함.
• SEO에 유리하지만, 요청마다 서버에서 데이터를 가져와야 하므로 응답 속도가 느릴 수 있음.
• 요청 시점에서 항상 최신 데이터를 가져와야 하는 경우 사용.

사용 예시

• 실시간 데이터가 필요한 경우 (예: 사용자 대시보드, 최신 뉴스, 검색 결과 등)
• 로그인한 사용자에 따라 다른 데이터를 보여줘야 하는 경우
• 요청마다 다른 결과를 보여줘야 하는 경우 (예: A/B 테스트)

✅ getStaticProps (SSG - Static Site Generation)

• 빌드 타임에 데이터를 가져와 정적 HTML을 생성하여 배포함.
• 요청 시점이 아니라 빌드 시점에 데이터를 가져오기 때문에 로딩 속도가 빠르고 SEO에도 유리함.
• 데이터가 자주 변경되지 않는 페이지에 적합.

사용 예시

• 블로그, 문서 페이지, 제품 상세 페이지 등 변경이 자주 없는 콘텐츠
• 마케팅 페이지처럼 빠른 로딩 속도가 중요한 경우

구분	getServerSideProps (SSR)	getStaticProps (SSG)
실행 시점	매 요청 시	빌드 타임에 한 번
성능	느림 (서버 요청 필요)	빠름 (정적 페이지 제공)
SEO	좋음	좋음
데이터 갱신	항상 최신 데이터	revalidate를 사용해 일정 주기마다 갱신 가능
예제	로그인 대시보드, 검색 결과	블로그, 제품 상세 페이지

2. Next.js의 자동 코드 분할(Code Splitting)이 성능 최적화에 어떻게 도움이 되는지
Next.js는 기본적으로 자동 코드 분할(Auto Code Splitting) 기능을 제공하여 성능을 최적화함.

✅ 코드 분할이란?

• 일반적으로, 모든 페이지에서 모든 JavaScript 번들을 한 번에 로드하면 초기 로딩 시간이 길어짐.
• Next.js는 각 페이지별로 필요한 코드만 로드하도록 자동으로 최적화함.
• 브라우저는 더 적은 양의 JavaScript 파일을 로드하므로 성능이 향상됨.

✅ 코드 분할의 주요 방식

1. 페이지 단위 코드 분할

   • 페이지별로 별도 번들을 생성하여 해당 페이지를 방문할 때만 필요한 코드가 로드됨.
   • 예: /about 페이지를 방문하면 about.js만 로드됨.

2. 컴포넌트 단위 코드 분할 (dynamic import)

   • import()를 사용하여 특정 컴포넌트를 필요한 시점에만 로드할 수 있음.
   • next/dynamic을 사용하면 컴포넌트를 지연 로딩할 수 있음.

✅ 성능 최적화 효과

• 초기 페이지 로딩 속도 향상
• 불필요한 JavaScript 다운로드 방지
• 브라우저 캐싱 최적화 (필요한 파일만 갱신)
• 대규모 애플리케이션에서 UX 개선

3. Next.js API Routes vs Express 같은 별도 백엔드 서버
Next.js는 API Routes를 제공하여 별도의 백엔드 서버 없이 API 엔드포인트를 만들 수 있음. Express 같은 별도 서버를 사용할 때와 비교하여 장점과 단점이 있음.

✅ Next.js API Routes의 장점

1. 설정이 간단함

   • 별도의 Express 서버 없이 Next.js 내에서 API를 만들 수 있음.
   • 서버리스 환경과 잘 맞음 (Vercel, AWS Lambda에서 쉽게 배포 가능).

2. 서버리스 배포 가능

   • Next.js의 API Routes는 Vercel, AWS Lambda 같은 서버리스 환경에서 자동으로 배포될 수 있음.
     사용량이 적으면 비용이 거의 들지 않음.

3. 페이지와 API를 하나의 프로젝트에서 관리 가능

   • 프론트엔드와 백엔드를 같은 리포지토리에서 관리할 수 있어 유지보수가 용이함.

4. SSR과 통합 가능

   • API Routes에서 데이터를 가져와 getServerSideProps에서 바로 사용할 수 있음.

✅ 단점

1. 긴 실행 시간에는 부적합

• Next.js의 API Routes는 서버리스 기반이므로 긴 실행 시간이 필요한 작업(예: 대용량 데이터 처리, 파일 변환 등)에 적합하지 않음.
• 데이터베이스 연결을 유지해야 하는 경우 Express 같은 전용 백엔드가 필요함.

2. 확장성 문제

• API 규모가 커지면 Next.js의 API Routes보다는 NestJS, Express 같은 백엔드 프레임워크가 더 적합할 수 있음.

3. 미들웨어 및 고급 기능 부족

• Express에서는 미들웨어, 쿠키/세션 관리 등을 쉽게 설정할 수 있지만, Next.js API Routes에서는 직접 구현해야 함.