Next.js - Pages Router(2)

렌더링에 대한 논의는 아래의 글을 참고해 주세요.

reference: https://velog.io/@minkwan/Next.js-Pages-Router1

0. Intro 🎯

지난 글에서는 Pages Router에서 활용할 수 있는 다양한 렌더링 방식과 더불어 RSC 개념까지 폭넓게 살펴봤습니다. 각각의 방식이 어떤 고민 속에서 등장했는지, 어떤 트레이드오프를 가지고 있는지 이해하는 시간이었습니다.

렌더링 방식이 '어떻게 화면을 그려낼 것인가'에 대한 고민이라면, 오늘 다룰 Data Fetching은 그 화면을 채울 '데이터를 어디서, 언제, 어떻게 가져올 것인가'에 관한 논의입니다.

Pages Router 환경에서는 각 렌더링 전략에 맞춰 데이터를 fetching 하는 특수한 함수들이 존재합니다. 빌드 타임에 데이터를 미리 가져오는 getStaticProps, 매 요청마다 최신 데이터를 확보하는 getServerSideProps, 동적 경로를 처리하기 위한 getStaticPaths 등의 개념이 있죠.

학습한 렌더링 개념을 기반으로, Next.js Pages Router의 핵심이라고 할 수 있는 Data Fetching 메서드들의 구체적인 동작 원리와 활용법을 정리해 보겠습니다.

1. getStaticProps 🎯

1-1. getStaticProps 사용 ✅

페이지에서 아래 코드와 같이 getStaticProps 함수를 export 하면, Next.js는 빌드 타임에 해당 함수를 실행하여 필요한 데이터를 가져오고, 그 결과물(props)을 사용해 HTML 페이지를 미리 생성하는 Pre-Rendering을 수행합니다.

export async function getStaticProps() {
  const res = await fetch('https://api.github.com/repos/vercel/next.js')
  const repo = await res.json()
  return { props: { repo } }
}
 
export default function Page({ repo }) {
  return repo.stargazers_count
}

이 과정에서 getStaticProps는 오직 서버 측에서만 실행되며, 빌드 시점에 데이터가 채워진 정적 HTML과 JSON 파일을 함께 생성합니다. 이렇게 생성된 정적 자산은 CDN에 캐싱 되어 사용자에게 매우 빠르게 전달되므로, getStaticProps는 SSG(Static Site Generation) 방식을 구현하는 핵심 메서드라고 할 수 있습니다.

Pitfall ⚠️

렌더링 방식과 무관하게 모든 props가 컴포넌트로 전달되며, 이를 초기 HTML을 통해 클라이언트 측에서 확인할 수 있습니다. 페이지가 올바르게 Hydration 될 수 있도록 하기 위함입니다. 클라이언트에서 확인 가능해서는 안 되는 민감한 정보는 props에 포함하여 전달하지 않도록 주의해야 합니다.

1-2. getStaticProps 사용 시점 ✅

getStaticProps는 한마디로 '누가 접속해도 똑같은 화면을 보여줄 때' 가장 강력한 성능을 보여줍니다. 대표적으로 네 가지 상황이 있습니다.

빌드 시점에 데이터 준비가 가능한 경우

사용자가 페이지를 요청하기 전, 즉 서비스를 빌드 하는 시점에 이미 화면에 나타낼 데이터를 확정 지을 수 있을 때 사용합니다.

외부 CMS에서 데이터를 가져오는 경우

Contentful, Strapi처럼 화면은 없고 데이터만 API로 전송해 주는 외부 헤드리스 CMS에서 관리하는 콘텐츠(블로그 포스트, 공지사항 등)를 불러와 화면을 구성할 때 적합합니다.

강력한 SEO와 빠른 속도가 필수적인 경우

검색 엔진 최적화가 중요하고, 로딩 속도가 매우 빨라야 하는 페이지에 사용합니다. HTML과 JSON 파일을 미리 만들어 CDN에 저장해두기 때문에 사용자에게 즉시 화면을 보여줄 수 있습니다.

사용자마다 내용이 달라지지 않는 경우

장바구니, 프로필처럼 개인화된 정보가 아니라, 모든 방문자에게 동일하게 보이는 공용 데이터를 렌더링 할 때 사용합니다.

1-3. getStaticProps 실행 시점 ✅

getStaticProps는 브라우저에서 실행되지 않고, 오직 서버에서만 실행된다는 점이 핵심입니다. getStaticProps 내부에 작성한 로직이나 데이터베이스 접근 코드는 배포 시 클라이언트가 받는 자바스크립트 번들 파일에서 완전히 제거됩니다. getStaticProps는 기본적으로 next build 시점에 실행되어 서비스에 필요한 모든 정적 페이지를 미리 완성합니다. 물론 개발 모드에서는 성능 편의를 위해 매 요청마다 실행됩니다.

하지만 SSG 방식 외에, ISR이나 동적 경로를 처리하는 경우에는 실행 시점이 조금 더 다양해집니다. 이때는 revalidate 옵션을 통해 이미 배포된 상태에서도 백그라운드에서 주기적으로 실행되어 페이지를 최신 데이터로 업데이트합니다. 또한 fallback 옵션을 사용하면, 사용자가 미리 생성하지 않은 페이지에 처음 방문했을 때 서버는 즉시 백그라운드에서 getStaticProps를 호출하여 새로운 HTML 페이지를 만들어냅니다.

getStaticProps는 빌드 타임이나 백그라운드에서 '미리' 실행되는 성격을 가졌습니다. 따라서 사용자가 브라우저 주소창에 입력한 쿼리 파라미터나 HTTP 헤더 정보에는 직접 접근할 수 없습니다. HTML을 미리 만들어두는 시점에는 누가 어떤 요청을 보낼지 알 수 없기 때문이죠. 사용자 개개인의 요청 정보가 반드시 요구된다면 getStaticProps가 아니라 미들웨어를 함께 활용하거나 SSR 방식을 고려해야 하겠죠?

1-4. CMS 데이터 페칭 활용 ✅

아래 코드와 같이 CMS에서 블로그 게시물 목록을 가져올 수 있습니다.

// getStaticProps()에 의해 빌드 타임에 posts 데이터가 채워집니다.
export default function Blog({ posts }) {
  return (
    <ul>
      {posts.map((post) => (
        <li key={post.id}>{post.title}</li>
      ))}
    </ul>
  )
}

// 서버 측의 빌드 타임에 호출됩니다.
// 클라이언트 측(브라우저)에서는 호출되지 않으므로, 
// 데이터베이스에 직접 접근하는 쿼리를 작성할 수도 있습니다.
export async function getStaticProps() {
  // 게시물을 가져오기 위해 외부 API 엔드포인트를 호출합니다.
  // 어떤 데이터 페칭 라이브러리든 사용 가능합니다.
  const res = await fetch('https://.../posts')
  const posts = await res.json()

  // { props: { posts } }를 반환함으로써, Blog 컴포넌트는
  // 빌드 타임에 `posts`를 prop으로 전달받게 됩니다.
  return {
    props: {
      posts,
    },
  }
}

1-5. 서버 사이드 코드 직접 작성 ✅

getStaticProps에서는 서비스의 내부 API Route(/api/posts)를 다시 fetch로 호출해서는 안 됩니다. 이유는 단순합니다. getStaticProps 자체가 이미 서버 환경이기 때문에 내부 API를 fetch로 호출하면 네트워크 요청을 이중으로 보내는 상황이 됩니다.

pages/api/posts.js API Route가 있다고 생각해 보죠.

export default async function handler(req, res) {
  const posts = await fetch("https://my-cms.com/posts").then(r => r.json());
  res.status(200).json(posts);
}

pages/index.js의 getStaticProps에서 다시 이를 호출한다고 해봅시다.

export async function getStaticProps() {
  const res = await fetch("http://localhost:3000/api/posts");
  const posts = await res.json();

  return {
    props: { posts },
  };
}

export default function Home({ posts }) {
  return <div>{posts.length} posts</div>;
}

getStaticProps 서버 코드에서 내부 api route로 네트워크 요청 한 번, /api/posts.js에서 CMS로 네트워크 요청 한 번, 총 두 번의 네트워크 요청이 발생합니다.

아래 코드를 보시죠.

// lib/load-posts.js (공통 로직)
export async function loadPosts() {
  // 외부 CMS나 DB에 직접 접근 (네트워크 1단계)
  const res = await fetch('https://external-cms.com/posts')
  return await res.json()
}

// pages/blog.js
import { loadPosts } from '../lib/load-posts'

export async function getStaticProps() {
  // 내부 API를 fetch 하지 않고, 로직을 직접 실행하여 중복 네트워크를 제거함
  const posts = await loadPosts() 
  return { props: { posts } }
}

이 경우에는 getStaticProps에서 곧바로 CMS로 네트워크 요청을 한 번만 보내게 됩니다.

결국 getStaticProps는 그 자체가 이미 서버이므로, 또 다른 서버 통로인 API Route를 거칠 필요 없이 데이터 소스에 가장 가까운 로직을 직접 실행하는 것이 성능 최적화의 핵심입니다.

1-6. HTML 및 JSON 정적 생성 매커니즘 ✅

getStaticProps를 사용하는 페이지가 빌드 타임에 Pre-Rendering 될 때, Next.js는 페이지 HTML 파일뿐만 아니라 getStaticProps 실행 결과를 담은 JSON 파일도 함께 생성합니다.

JSON 파일은 next/link나 next/router를 통한 클라이언트 사이드 라우팅에 사용됩니다. getStaticProps로 Pre-Rendering 된 페이지로 이동할 때, Next.js는 빌드 타임에 미리 계산된 JSON 파일을 가져와 페이지 컴포넌트의 props로 사용합니다. 즉, 클라이언트 사이드 페이지 전환 시에는 이미 생성된 JSON만 사용하므로 getStaticProps가 다시 호출되지 않습니다.

증분 정적 재생성(ISR)을 사용하는 경우, 클라이언트 사이드 네비게이션에 필요한 JSON을 생성하기 위해 백그라운드에서 getStaticProps가 실행됩니다. 이 과정에서 동일한 페이지에 대해 여러 번의 요청이 발생하는 것을 볼 수 있지만, 의도된 동작이며 최종 사용자 성능에는 영향을 미치지 않습니다.

1-7. getStaticProps 사용 가능 범위 ✅

getStaticProps 함수는 오직 '페이지 파일'에서만 사용할 수 있습니다. getStaticProps는 pages 폴더 내에 있는 페이지용 파일에서만 export 해야 합니다. 일반적인 UI 컴포넌트나 모든 페이지의 공통 설정을 담당하는 _app.js, _document.js 같은 특수 파일에서는 사용할 수 없습니다. 리액트가 화면을 그리기 전, 해당 페이지에 필요한 데이터를 서버에서 미리 완벽하게 준비(Pre-Fetching) 해야 하는 구조적 이유 때문입니다.

또한, 반드시 '독립된 함수'로 내보내야 합니다. export async function getStaticProps() { ... }와 같이 독립적인 이름을 가진 함수로 내보내야 정상적으로 작동합니다. 만약 페이지 컴포넌트 객체의 속성으로 추가하는 방식을 사용하면 Next.js가 이를 인식하지 못하므로 주의가 필요합니다.

2. getStaticPaths 🎯

2-1. getStaticPaths 사용 ✅

동적 경로가 있는 페이지에서 getStaticProps를 사용하는 경우, 정적으로 생성될 경로 목록을 미리 정의해야 합니다. 동적 경로를 사용하는 페이지에서 getStaticPaths 함수를 export 하면, Next.js는 getStaticPaths에 지정된 모든 경로를 정적으로 Pre-Rendering 합니다. 기본적인 사용 형태는 아래와 같습니다.

export async function getStaticPaths() {
  return {
    paths: [
      {
        params: {
          name: 'next.js',
        },
      },
    ],
    fallback: true,
  };
}

export async function getStaticProps() {
  const res = await fetch('https://api.github.com/repos/vercel/next.js');
  const repo = await res.json();
  
  return { props: { repo } };
}

export default function Page({ repo }) {
  return repo.stargazers_count;
}

2-2. getStaticPaths 사용 시점 ✅

getStaticPaths는 본질적으로 getStaticProps와 동일한 소스에서 데이터를 가져옵니다. CMS나 DB, 파일 시스템 등에서요. 하지만 목적에서는 결정적인 차이가 있습니다. about.js와 같은 고정된 경로의 페이지와 달리, [id].js와 같은 동적 경로는 빌드 시점에 Next.js가 도대체 몇 개의 페이지를 만들어야 할지 알 수 없습니다. 이 타이밍에 getStaticPaths가 개입하여 "1번부터 100번까지의 게시글 주소가 있으니, 이 목록을 기반으로 미리 지도를 그려두어라!"라는 식의 명령을 내립니다. 데이터의 내용을 가져오기 전에 주소 리스트를 확정 짓기 위한 일종의 사전 작업인 셈입니다.

따라서 getStaticPaths는 SEO와 압도적인 성능이 동시에 요구되면서도, 그 대상 페이지가 가변적인 동적 라우팅 방식을 따라야 할 때 필수적으로 사용됩니다. 제품 상세나 블로그 포스트 등 특정 사용자에게 종속되지 않는 공용 데이터를 다룰 때 사용해야 할 것 같습니다.

결국 getStaticPaths를 사용한다는 것은 수천, 수만 개의 상세 페이지를 사용자 요청이 들어오기 전에 미리 '준비한다'라는 것을 의미합니다. 사용자는 어떤 상세 페이지에 접속하더라도 서버의 연산을 기다릴 필요 없이, 이미 전 세계 CDN에 배포된 완성형 페이지를 빠른 속도로 받을 수 있게 됩니다.

2-3. getStaticProps와의 상호작용 ✅

getStaticPaths는 프로덕션 환경에서 오직 빌드 시점에 실행됩니다. 중요한 것은 getStaticProps와의 관계입니다.

가장 먼저 next build 중에 getStaticPaths를 실행합니다. 이후 getStaticPaths가 반환한 모든 paths에 대해 getStaticProps를 실행합니다. 이때 fallback을 true로 설정하면 빌드 타임에 생성되지 않은 페이지 요청이 들어오면 백그라운드에서 getStaticProps가 실행되고, blocking으로 설정하면 초기 렌더링이 일어나기 직전에 getStaticProps가 호출되어 완료될 때까지 기다립니다.

getStaticPaths와 getStaticProps 모두 서버와 빌드 타임이라는 큰 틀에서 보면 완전히 동일한 궤를 그리며 움직입니다. 핵심은 SSG입니다. SSG의 목표는 사용자가 요청하기 전에 모든 준비를 끝내는 것입니다. 두 함수 모두 빌드 시점에 서버에서 미리 작업을 끝내버리기 때문에, 사용자가 서비스에 접속했을 때에는 서버가 데이터베이스를 찾아볼 필요 없이 이미 만들어진 HTML과 JSON 파일만 툭 던져주면 끝납니다.

getStaticPaths와 getStaticProps의 미세한 차이는 getServerSideProps와 Incremental Static Regeneration 과정에서 발생하는데요, 이에 대해서는 후술할 예정입니다.

2-4. 온디맨드(On-demand) 경로 생성 ✅

이미 언급했지만, getStaticPaths의 fallback 옵션을 활용하면 모든 페이지를 빌드 시점에 만드는 대신, 요청이 들어오는 시점(On-demand)에 생성되도록 제어할 수 있습니다. 빌드 시점에 너무 많은 페이지를 생성하면 빌드 속도가 느려질 수 있기 때문입니다.

paths에 빈 배열([])을 반환하면 모든 페이지의 생성을 On-demand 방식으로 미룰 수 있습니다. 이 방식은 Next.js 애플리케이션을 여러 환경에 배포할 때 특히 유용합니다. 예를 들어, 정적 페이지가 수백, 수천 개에 달하는 사이트의 경우 프리뷰 환경에서는 모든 페이지를 On-demand로 생성하게 하여 빌드 속도를 높이고, 프로덕션 환경에서만 미리 생성하는 방식으로 활용할 수 있습니다.

export async function getStaticPaths() {
  // 환경 변수 설정 시 정적 페이지 미리 생성 안 함
  // (빌드는 빨라지지만, 첫 접속 시 로딩 속도는 느려질 수 있음)
  if (process.env.SKIP_BUILD_STATIC_GENERATION) {
    return {
      paths: [],
      fallback: 'blocking',
    }
  }

  // 외부 API를 호출하여 게시글 목록 가져오기
  const res = await fetch('https://.../posts')
  const posts = await res.json()

  // 가져온 데이터를 기반으로 미리 생성할 경로(ID) 목록 생성
  // 프로덕션 환경에서는 모든 페이지를 미리 생성하여 속도 최적화
  const paths = posts.map((post) => ({
    params: { id: post.id },
  }))

  // 정의되지 않은 경로는 404 에러 처리
  return { paths, fallback: false }
}

3. getServerSideProps 🎯

3-1. getServerSideProps 사용 ✅

페이지 컴포넌트에서 getServerSideProps를 export 하여 사용할 수 있습니다. 아래는 기본적인 사용 예시입니다.

export async function getServerSideProps() {
  const res = await fetch('https://api.github.com/repos/vercel/next.js')
  const repo = await res.json()
  return { props: { repo } }
}
 
export default function Page({ repo }) {
  return (
    <main>
      <p>{repo.stargazers_count}</p>
    </main>
  )
}

getServerSideProps는 개인화된 사용자 데이터나 위치 정보처럼 요청 시점에만 알 수 있는 정보에 의존하는 페이지를 렌더링 해야 할 때 사용합니다.

요청 시점에 데이터를 가져올 필요가 없거나, 데이터와 Pre-Rendering 된 HTML을 캐싱 하는 상황이 더 적절하다면 getServerSideProps가 아니라 getStaticProps를 사용하는 것이 더 좋겠죠?

3-2. Edge Cases ✅

getServerSideProps를 사용할 때 주의해야 할 상황들이 있습니다.

예외 처리와 리다이렉트

내부에서 에러가 발생하거나 특정 조건에 따라 사용자를 다른 페이지로 보내야 할 때가 있습니다. 이러한 경우 notFound나 redirect 속성을 반환하여 처리할 수 있겠습니다.

export async function getServerSideProps(context) {
  const res = await fetch(`https://api.example.com/data/${context.params.id}`)
  
  // 데이터가 존재하지 않는 경우 404 페이지로
  if (!res.ok) {
    return {
      notFound: true,
    }
  }
  
  const data = await res.json()
  
  // 특정 조건에 따라 리다이렉트
  if (!data.published) {
    return {
      redirect: {
        destination: '/',
        permanent: false,
      },
    }
  }
  
  return {
    props: { data },
  }
}

Context 객체 활용

getServerSideProps는 매 요청 시 동작하기에, 요청 관련 정보를 담은 context 객체에 접근할 수 있습니다. 이 부분이 getStaticProps와의 결정적인 차이점입니다.

export async function getServerSideProps(context) {
  // context 객체에는 다양한 정보가 담겨있습니다
  const {
    params,       
    req,          
    res,          
    query,        
    preview,      
    previewData,  
    resolvedUrl,  
    locale,       
    locales,      
  } = context
  
  // 쿠키나 헤더 정보 접근 가능
  const token = req.cookies.auth_token
  const userAgent = req.headers['user-agent']
  
  return {
    props: {
      userAgent,
    },
  }
}

캐싱 동작 제어

마지막으로, getServerSideProps는 매 요청마다 실행되지만 Cache-Control 헤더를 통해 캐싱 전략을 세밀하게 조정할 수도 있습니다.

export async function getServerSideProps({ res }) {
  // 60초 동안 캐시하고, 그 이후 10초 동안은 stale 콘텐츠를 제공하면서
  // 백그라운드에서 재검증(stale-while-revalidate)
  res.setHeader(
    'Cache-Control',
    'public, s-maxage=60, stale-while-revalidate=10'
  )
  
  const data = await fetch('https://api.example.com/data')
  const json = await data.json()
  
  return {
    props: { data: json },
  }
}

4. Incremental Static Regeneration(ISR) 🎯

ISR은 우리가 앞서 학습했듯, SSG의 성능과 SSR의 유연성을 결합한 하이브리드 전략입니다. 빌드 시점에 모든 페이지를 생성하는 대신, 일부 페이지만 미리 만들고 나머지 페이지는 요청에 따라 생성하면서도, 한 번 생성된 페이지는 일정 시간 동안 재사용할 수 있도록 합니다.

4-1. On-Demand Revalidation ✅

ISR은 revalidate 옵션으로 설정한 시간이 지나면 백그라운드에서 페이지를 재생성하는 방식으로 동작합니다.

// pages/blog/[slug].js
export async function getStaticProps({ params }) {
  const post = await getPostBySlug(params.slug)
  
  return {
    props: { post },
    // 60초마다 백그라운드에서 페이지 재생성
    revalidate: 60,
  }
}

export async function getStaticPaths() {
  return {
    paths: [],
    fallback: 'blocking',
  }
}

하지만 때로는 일정 시간이 지난 후가 아니라, 데이터가 변경되는 즉시 페이지를 업데이트해야 할 필요가 있습니다. 가령 블로그 포스트를 수정하자마자 변경사항이 반영되기를 원할 수 있죠. 즉 On-Demand에 의한 Revalidation이 필요한 경우가 있습니다.

On-Demand Revalidation을 사용할 때는 getStaticProps에 revalidate 시간을 명시할 필요가 없습니다. 시간 설정을 생략하면 기본값인 false가 되며, 오직 revalidate()가 호출될 때만 페이지를 업데이트합니다.

// pages/api/revalidate.js
export default async function handler(req, res) {
  // 보안을 위한 토큰 검증
  if (req.query.secret !== process.env.REVALIDATE_TOKEN) {
    return res.status(401).json({ message: 'Invalid token' })
  }
  
  try {
    // 특정 경로의 페이지를 즉시 재생성
    await res.revalidate('/blog/my-post')
    
    return res.json({ revalidated: true })
  } catch (err) {
    return res.status(500).send('Error revalidating')
  }
}

getServerSideProps는 매 요청마다 서버에서 코드를 실행하여 데이터를 직접 가져오기에 별도의 캐싱 로직이 필요하지 않습니다. 하지만 ISR은 빌드 시점에 이미 생성된 정적 자산을 서빙하는 방식이기에, 물리적인 파일 교체를 위한 별도의 트리거가 필요합니다.

사용자의 페이지 방문 시점이 아니라 CMS의 데이터 수정 시점처럼, 특정 이벤트가 발생했을 때 서버에 '정적 파일 재생성'을 명령해야 하므로, res.revalidate()를 실행할 수 있는 독립적인 API 엔드포인트가 요구됩니다.

한마디로, 데이터 요청과 캐시 무효화는 실행 주체와 시점이 완전히 다른 로직이기에 API Route를 통해 제어권을 분리하여 관리합니다.

4-2. Error handling and revalidation ✅

ISR 방식을 따를 때 발생할 수 있는 에러 상황들을 알아보겠습니다.

Revalidation 실패

getStaticProps 내부에서 에러가 발생하더라도, 이미 생성된 페이지는 유지됩니다. Revalidation 과정 중 getStaticProps 내에서 예기치 못한 에러가 발생하더라도, Next.js는 즉시 에러 화면을 띄우는 대신 기존에 성공적으로 생성되었던 최신 정적 페이지를 그대로 사용자에게 제공합니다. 데이터 소스가 일시적으로 불안정한 상황에서도 사용자에게 최소한의 정상적인 화면을 보장하며, 시스템은 다음 재검증 주기에 맞춰 다시 페이지 갱신을 시도합니다.

export async function getStaticProps() {
  try {
    const data = await fetchDataFromAPI()
    
    return {
      props: { data },
      revalidate: 60,
    }
  } catch (error) {
    // 에러가 발생해도 이전에 생성된 페이지는 계속 제공됩니다
    // 다음 재검증 시점에 다시 시도됩니다
    console.error('Revalidation failed:', error)
    
    // 이전 페이지를 유지하려면 throw하지 않습니다
    // 만약 에러 페이지를 보여주고 싶다면 throw error
    return {
      notFound: true, // 또는 에러 props 전달
    }
  }
}

조건부 Revalidation

모든 페이지를 동일한 주기로 Revalidation할 필요는 없겠죠? 데이터의 특성에 따라 서로 다른 revalidate 값을 반환할 수 있습니다.

export async function getStaticProps({ params }) {
  const post = await getPostBySlug(params.slug)
  
  // 최근 게시물은 자주 업데이트, 오래된 게시물은 덜 업데이트
  const isRecent = Date.now() - new Date(post.createdAt).getTime() < 7 * 24 * 60 * 60 * 1000 // 7일
  
  return {
    props: { post },
    // 최근 글은 1분, 오래된 글은 1시간
    revalidate: isRecent ? 60 : 3600, 
  }
}

Revalidation 중복 방지

동일한 페이지에 대해 동시에 여러 Revalidation 요청이 들어올 수 있습니다. Next.js는 내부적으로 이러한 상황을 처리하여 중복 실행을 방지하지만, API 호출을 최적화하고 싶다면 직접 제어할 수도 있습니다.

// lib/cache.js
const revalidationCache = new Map()

export async function fetchWithDedupe(key, fetcher, ttl = 5000) {
  const cached = revalidationCache.get(key)
  
  // 이미 진행 중인 요청이 있으면 재사용
  if (cached && Date.now() - cached.timestamp < ttl) {
    return cached.promise
  }
  
  const promise = fetcher()
  revalidationCache.set(key, {
    promise,
    timestamp: Date.now(),
  })
  
  // 캐시 정리
  setTimeout(() => revalidationCache.delete(key), ttl)
  
  return promise
}

// pages/blog/[slug].js
import { fetchWithDedupe } from '@/lib/cache'

export async function getStaticProps({ params }) {
  const post = await fetchWithDedupe(
    `post-${params.slug}`,
    () => getPostBySlug(params.slug)
  )
  
  return {
    props: { post },
    revalidate: 60,
  }
}

5. Client-Side Fetching 🎯

서버에서 데이터를 가져와 HTML을 미리 만드는 방식이 능사는 아닙니다. 브라우저에서 직접 데이터를 가져오는 것이 더 적절한 경우도 있습니다.

5-1. Client-Side data fetching with useEffect ✅

SEO가 중요하지 않거나, 페이지를 Pre-Rendering 할 필요가 없거나, 사용자 상호작용에 따라 데이터가 자주 업데이트되는 경우에 적합합니다. 사실 지금까지 작성해온 방식이도 합니다.

import { useState, useEffect } from 'react'
 
function Profile() {
  const [data, setData] = useState(null)
  const [isLoading, setLoading] = useState(true)
 
  useEffect(() => {
    fetch('/api/profile-data')
      .then((res) => res.json())
      .then((data) => {
        setData(data)
        setLoading(false)
      })
  }, [])
 
  if (isLoading) return <p>Loading...</p>
  if (!data) return <p>No profile data</p>
 
  return (
    <div>
      <h1>{data.name}</h1>
      <p>{data.bio}</p>
    </div>
  )
}

5-2. Client-Side data fetching with SWR ✅

useEffect로 직접 구현하는 것도 좋지만, 매번 보일러 플레이트 코드를 작성해야 하고, 캐싱이나 재검증 등의 고급 기능을 직접 구현하기는 어렵습니다. 이럴 때 SWR이나 Tanstack Query와 같은 기술을 사용하게 됩니다. Tanstack Query는 평소에 자주 사용했으니 SWR 코드만 가볍게 살펴보겠습니다.

SWR - 기본 사용법

import useSWR from 'swr'

const fetcher = (url) => fetch(url).then((res) => res.json())

export default function Profile() {
  const { data, error, isLoading } = useSWR('/api/user/profile', fetcher)

  if (error) return <div>Failed to load</div>
  if (isLoading) return <div>Loading...</div>

  return (
    <div>
      <h1>{data.name}</h1>
      <p>{data.bio}</p>
    </div>
  )
}

SWR - Mutation과 Optimistic UI

import useSWR, { useSWRConfig } from 'swr'

export default function TodoList() {
  const { data: todos } = useSWR('/api/todos', fetcher)
  const { mutate } = useSWRConfig()

  async function addTodo(title) {
    // Optimistic UI 업데이트
    mutate(
      '/api/todos',
      [...todos, { id: Date.now(), title, completed: false }],
      false // 재검증 건너뛰기
    )

    // 실제 API 호출
    await fetch('/api/todos', {
      method: 'POST',
      body: JSON.stringify({ title }),
    })

    // 서버 데이터로 재검증
    mutate('/api/todos')
  }

  return (
    <div>
      {todos?.map((todo) => (
        <div key={todo.id}>{todo.title}</div>
      ))}
      <button onClick={() => addTodo('새 할 일')}>추가</button>
    </div>
  )
}

6. Outro 🎯

Next.js Pages Router의 Data Fetching은 페이지의 성격에 따라 최적의 사용자 경험을 제공하기 위한 네 가지 전략으로 나뉩니다.

모든 사용자에게 동일한 화면을 보여주는 SSG는 getStaticProps와 getStaticPaths를 통해 빌드 타임에 정적 자산을 미리 생성하여 압도적인 성능과 SEO를 보장하며, 개인화된 최신 데이터가 필요한 경우에는 getServerSideProps를 활용해 매 요청마다 서버에서 렌더링을 수행합니다.

이에 더해 ISR은 정적 페이지 배포 후에도 백그라운드에서 데이터를 주기적으로 갱신하여 SSG의 효율성과 SSR의 유연성을 동시에 확보하며, 대시보드처럼 실시간 상호작용이 중요한 영역은 SWR이나 Tanstack Query를 활용한 CSR 방식으로 보완하여 효율적인 데이터 아키텍처를 구축할 수 있습니다.