Chapter 8. Static and Dynamic Rendering

Chapter 8

정적 렌더링과 동적 렌더링

이전 장에서는 대시보드 개요 페이지에 대한 데이터를 가져왔습니다. 그러나 현재 설정의 두 가지 한계에 대해 간단히 논의했습니다:

데이터 요청이 의도치 않은 워터폴을 생성하고 있습니다.
대시보드는 정적이므로 데이터 업데이트는 애플리케이션에 반영되지 않습니다.

이번 장에서는...
다음과 같은 내용을 다룰 예정입니다.
정적 렌더링이란 무엇이며 애플리케이션 성능을 어떻게 향상시키는지
동적 렌더링이란 무엇이고 언제 사용하는지
대시보드를 동적으로 만들기 위한 다양한 방법
느린 데이터 가져오기를 시뮬레이션하여 결과 확인하기

정적 렌더링이란 무엇인가요?

정적 렌더링에서는, (배포할 때) 서버에서 빌드되는 시간 동안 또는 재검증 중에 데이터 가져오기와 렌더링이 발생합니다. 그 결과물은 컨텐츠 전송 네트워크(CDN)에 분배되고 캐시될 수 있습니다.

사용자가 애플리케이션에 방문할 때마다 캐시된 결과가 제공됩니다. 정적 렌더링의 장점은 다음과 같습니다:

빠른 웹사이트 - 사전 렌더링된 콘텐츠는 캐시되고 전역적으로 분배됩니다. 이는 전 세계 사용자가 웹사이트 콘텐츠에 빠르게 액세스할 수 있도록 보장합니다.
서버 부하 감소 - 콘텐츠가 캐시되기 때문에 서버는 각 사용자 요청에 동적으로 콘텐츠를 생성할 필요가 없습니다.
검색 엔진 최적화(SEO) - 사전 렌더링된 콘텐츠는 페이지 로드 시 이미 사용 가능하기 때문에 검색 엔진 크롤러가 쉽게 색인화할 수 있습니다. 이는 검색 엔진 순위 향상으로 이어질 수 있습니다.

정적 렌더링은 데이터가 없는 경우 또는 사용자 간에 공유되는 데이터에 유용합니다. 예를 들어, 정적 블로그 글이나 제품 페이지와 같은 경우에 적합합니다. 그러나 주기적으로 업데이트되는 개인화된 데이터가 있는 대시보드에는 적합하지 않을 수 있습니다.

정적 렌더링의 반대는 동적 렌더링입니다.

퀴즈를 풀어보세요!
지금까지 배운 내용을 테스트해보세요.
대시보드 앱에 정적 렌더링이 적합하지 않은 이유는 무엇일까요?
A: 웹사이트를 느리게 만들기 때문에
B: 서버 부하가 증가할 것이기 때문에
C: 애플리케이션에 최신 데이터 변경 사항이 반영되지 않을 것이기 때문에
D: 컨텐츠 전송 네트워크가 필요하기 때문에
정답 확인
C: 애플리케이션에 최신 데이터 변경 사항이 반영되지 않을 것이기 때문에
데이터가 업데이트되면 대시보드에 최신 변경 사항을 보여주고 싶어요. 정적 렌더링은 이러한 경우에 적합하지 않습니다.

동적 렌더링이란 무엇인가요?

동적 렌더링에서는 컨텐츠가 **요청 시간(사용자가 페이지를 방문할 때)**에 서버에서 렌더링됩니다. 동적 렌더링의 장점은 다음과 같습니다:

실시간 데이터 - 동적 렌더링을 통해 애플리케이션이 실시간으로 또는 자주 업데이트되는 데이터를 표시할 수 있습니다. 데이터가 자주 변경되는 애플리케이션에 이상적입니다.
사용자별 콘텐츠 - 대시보드나 사용자 프로필과 같은 개인화된 콘텐츠를 제공하고 사용자 상호작용에 따라 데이터를 업데이트하는 것이 더 쉽습니다.
요청 시간 정보 - 동적 렌더링을 사용하면 요청 시간에만 알 수 있는 정보에 액세스할 수 있습니다. 예를 들어, 쿠키나 URL 검색 매개변수 등입니다.

퀴즈를 풀어보세요!
지금까지 배운 내용을 테스트해보세요.
요청 시간에만 알 수 있는 정보는 무엇일까요?
A: 데이터베이스 스키마
B: URL 경로
C: 쿠키 및 URL 검색 매개변수
정답 확인
C: 쿠키 및 URL 검색 매개변수
쿠키와 URL 검색 매개변수는 요청 시간에만 알 수 있는 정보입니다.

대시보드를 동적으로 만들기

기본적으로 @vercel/postgres는 자체 캐싱 시맨틱스를 설정하지 않습니다. 이는 프레임워크가 자체적으로 정적 및 동적 동작을 설정할 수 있게 합니다.

서버 컴포넌트 또는 데이터 가져오기 함수 내에서 unstable_noStore라는 Next.js API를 사용하여 정적 렌더링을 사용하지 않도록 설정할 수 있습니다. 이를 추가해봅시다.

data.ts에서 next/cache에서 unstable_noStore를 가져오고 데이터 가져오기 함수의 최상단에 호출합니다.

/app/lib/data.ts

// ...
import { unstable_noStore as noStore } from 'next/cache';

export async function fetchRevenue() {
  // 응답이 캐시되지 않도록 여기에 noStore()를 추가합니다.
  // 이는 fetch(..., {cache: 'no-store'})와 동등합니다.
  noStore();

  // ...
}

export async function fetchLatestInvoices() {
  noStore();
  // ...
}

export async function fetchCardData() {
  noStore();
  // ...
}

export async function fetchFilteredInvoices(
  query: string,
  currentPage: number
) {
  noStore();
  // ...
}

export async function fetchInvoicesPages(query: string) {
  noStore();
  // ...
}

export async function fetchFilteredCustomers(query: string) {
  noStore();
  // ...
}

export async function fetchInvoiceById(query: string) {
  noStore();
  // ...
}

참고: unstable_noStore는 실험적인 API이며 나중에 변경될 수 있습니다. 본인의 프로젝트에서 안정적인 API를 사용하려면 세그먼트 구성 옵션인 export const dynamic = "force-dynamic"을 사용할 수도 있습니다.

느린 데이터 가져오기 시뮬레이션

대시보드를 동적으로 만드는 것은 좋은 첫 걸음입니다. 그러나 이전 장에서 언급한 문제점이 하나 있습니다. 모든 다른 요청보다 한 데이터 요청이 더 느린 경우 어떻게 될까요?

느린 데이터 가져오기를 시뮬레이션해보겠습니다. data.ts 파일에서 fetchRevenue() 내의 console.log와 setTimeout을 주석 해제해보세요.

/app/lib/data.ts

export async function fetchRevenue() {
  try {
    // 데모 목적으로 응답을 인위적으로 지연시킵니다.
    // 실제 제품에서는 이렇게 하지 마세요 :)
    console.log('수익 데이터 가져오는 중...');
    await new Promise((resolve) => setTimeout(resolve, 3000));

    const data = await sql<Revenue>`SELECT * FROM revenue`;

    console.log('데이터 가져오기 완료 - 3초 후');

    return data.rows;
  } catch (error) {
    console.error('데이터베이스 오류:', error);
    throw new Error('수익 데이터를 가져오지 못했습니다.');
  }
}

이제 새 탭에서 http://localhost:3000/dashboard/를 열고 페이지 로드에 더 오랜 시간이 걸리는 것을 확인하세요. 터미널에서도 다음과 같은 메시지를 볼 수 있어야 합니다:

Fetching revenue data...
Data fetch completed after 3 seconds.

여기서는 인위적으로 3초 지연을 추가하여 느린 데이터 가져오기를 시뮬레이션했습니다. 결과적으로 데이터를 가져오는 동안 전체 페이지가 차단됩니다.

이렇게 동적 렌더링을 사용할 때 가장 느린 데이터 가져오기에 따라 애플리케이션의 속도가 결정된다는 개발자들이 해결해야 할 공통적인 도전 과제에 도달했습니다.

PreviousChapter 7. Fetching Data NextChapter 9. Streaming

Last updated 1 year ago