[NextJS] Next.js의 데이터 페칭 전략(ISR vs SSR)

모든 페이지를 실시간으로 가져올 필요는 없다

사용자가 웹사이트에 접속했을 때 느끼는 '속도'는 곧 서비스의 품질과 직결된다.

Next.js는 이를 위해 다양한 렌더링 전략을 제공하지만, 상황에 맞지 않는 전략 선택은 오히려 서버 부하를 높이거나 불필요한 로딩 시간을 초래한다.

오늘은 Next.js의 데이터 페칭 전략에 대해 정리를 해보려 한다.

ISR (Incremental Static Regeneration): 정적 페이지의 진화

• 상품 목록이나 공지사항처럼 데이터가 실시간으로 변하지는 않지만, 주기적인 업데이트가 필요한 페이지에는 ISR이 최적이다.
• 작동 원리: 빌드 시점에 페이지를 미리 생성(Static)해두고, 설정한 주기(revalidate)마다 백그라운드에서 페이지를 새로 고친다.
• 장점: 사용자는 항상 미리 생성된 HTML을 받기에 로딩 속도가 압도적으로 빠르다(LCP 최적화).
• 적용 예시: 쇼핑몰의 메인 상품 리스트. 1시간마다 업데이트되도록 설정하여 서버 부하를 줄이면서도 최신 정보를 유지한다.

SSR (Server Side Rendering): 개인화된 데이터의 실시간성

• 마이페이지나 장바구니처럼 사용자마다 데이터가 다르고 보안이 중요한 페이지는 SSR을 사용해야 한다.
• 작동 원리: 요청이 들어올 때마다 서버에서 데이터를 새로 가져와 HTML을 완성한다.
• 장점: 항상 최신 데이터를 보장하며, 쿠키나 세션 등 서버 측 보안 로직을 태우기 용이하다.
• 적용 예시: 위픽의 내 주변 꽃집 검색 결과. 사용자의 현재 위치를 기반으로 매번 다른 결과를 보여줘야 하므로 SSR이 적합하다.

하이브리드 전략: 성능과 최신성의 균형

최고의 성능은 '무엇을 안 보여줄지'가 아니라 '언제 보여줄지'를 결정하는 데서 나온다.

• 현대적인 프론트엔드 아키텍처는 하나의 정답만을 강요하지 않는다.
• Next.js App Router에서는 컴포넌트 단위로 force-dynamic이나 revalidate 옵션을 섞어 쓸 수 있다.
• 패턴: 뼈대가 되는 레이아웃은 정적(Static)으로 가져오고, 변동이 잦은 가격이나 재고 정보만 클라이언트 사이드(SWR/TanStack Query)에서 보충하는 방식을 취한다.

데이터의 성격에 따라 최적의 렌더링 전략을 선택하는 과정은 프론트엔드 아키텍처 설계의 핵심이다.

네트워크 기초 지식과 Next.js의 최신 기능을 결합하여, 단순한 구현을 넘어 시스템 전체의 효율성을 고민하는 개발자로 성장하고 싶다.