SSR이 SSG보다 더 나은 이유

Jun 30, 2024

SSR만으로도 충분한 이유

SSR(서버 사이드 렌더링)은 서버에서 실행 시점에 페이지를 렌더링한 후 프론트엔드로 전송하는 것을 의미합니다. SSG(정적 사이트 생성)는 HTML 등의 정적 파일을 미리 컴파일하여 사용자가 요청할 때 직접 프론트엔드로 전송하는 것을 의미합니다.

이러한 정의가 명확해지면, SSR은 동적 로직을 포함할 수 있지만 항상 서버를 실행해야 하며, SSG는 CDN에 배치할 수 있는 정적 콘텐츠에 더 적합하다는 것을 쉽게 이해할 수 있습니다. 유명한 NextJS 프레임워크는 SSR과 SSG를 모두 지원합니다. 그러나 새로운 Remix 프레임워크는 SSG를 완전히 포기하고, 이 접근 방식에 충분한 이점이 있다고 생각합니다. 제 경험에 따르면, 현대적인 CDN의 지원으로 이 접근 방식은 타당합니다.

Cloudflare와 Vercel과 같은 현대적인 CDN은 서버리스 환경을 지원하여 NodeJS 애플리케이션 배포가 정적 파일 배포와 거의 동일하게 편리합니다.
SSG의 주요 이점은 정적 파일을 CDN에 직접 배포하여 서버 리소스를 절약하는 것입니다. 그러나 SSR도 적절한 Cache-Control 헤더를 설정하여 콘텐츠를 CDN에 쉽게 캐시할 수 있습니다. 이는 SSR 서버가 첫 번째 요청에서만 실행되어 정적 파일과 거의 구분되지 않게 만듭니다.
정적 콘텐츠를 수정할 때마다 재컴파일과 재배포가 필요하지 않습니다.
NextJS와 같은 SSG와 SSR을 구분하는 접근 방식을 포기하면 정신적 부담이 크게 줄어듭니다. 캐시 설정은 Cache-Control과 같은 HTML 표준에 완전히 의존하며, 추가 인터페이스를 배울 필요가 없습니다. 캐시 문제 디버깅도 훨씬 쉬워집니다 - 브라우저가 캐시하지 않아야 할 요청을 캐시한 경우 Response 설정만 확인하면 됩니다.

예시

사실, Remix의 공식 웹사이트는 훌륭한 예시입니다. 그들의 문서는 SSR을 사용하여 생성됩니다. 많은 사람들은 문서가 단순한 정적 텍스트이므로 SSG가 최적이라고 생각할 수 있습니다. Remix 팀은 설명하고 있습니다.

그들의 문서는 Remix의 소스 코드 저장소에 저장되어 있으며, 공식 웹사이트에 직접 작성되어 있지 않습니다. 이 문서를 소스 코드와 함께 유지하는 접근 방식에는 여러 이점이 있습니다:

코드를 읽을 때 더 참조하기 쉬움
코드를 변경할 때 문서를 쉽게 수정할 수 있음
Git이 자동으로 문서 변경 사항을 추적하고 소스 코드 버전과 연결

공식 웹사이트의 서버는 Remix의 소스 코드 저장소에서 읽어 SSR을 통해 문서 페이지를 생성합니다. 이 접근 방식에는 여러 이점이 있습니다:

문서를 수정할 때마다 전체 웹사이트를 재컴파일하고 재배포할 필요가 없음
소스 코드 저장소에서 모든 Remix 버전의 문서에 직접 접근할 수 있으며, dev 브랜치의 최신 문서에도 접근할 수 있습니다. 이를 통해 공식 웹사이트는 모든 Remix 버전에 해당하는 문서를 표시할 수 있습니다.

문서는 실시간 데이터가 아니므로, 몇 가지 캐시 최적화를 구현했습니다:

lru-cache를 사용하여 문서 결과를 캐시합니다. 캐시는 서버 측에 있으므로 모든 클라이언트가 혜택을 받습니다.
- 타임아웃을 5분으로 설정
Cache-Control을 stale-while-revalidate로 설정. 이를 통해 CDN 캐싱이 가능합니다:
```
return json(
  { doc },
  {
    headers: {
      "Cache-Control": "max-age=300, stale-while-revalidate=604800",
    },
  }
);
```
이는 문서가 수정될 때 공식 웹사이트가 최대 5분(max-age=300)의 지연으로 변경 사항을 표시한다는 것을 의미합니다.