[Next.js] Hydration이란?

🗣️ Hydration이란 무엇인가요?

• 의도: 지원자가 Hydration의 개념과 중요성을 이해하고 있는지 평가

• 팁
  • Hydration의 개념을 설명한다.
  • Hydration이 필요한 이유를 설명한다.
  • Hydration의 동작 방식을 설명한다.

• 주어진 답안 (모범 답안)

  Hydration은 서버에서 렌더링된 HTML을 클라이언트 측에서 다시 렌더링하여 인터랙티브하게 만드는 과정을 의미합니다.
  Next.js와 같은 프레임워크에서는 서버 사이드 렌더링(SSR)을 통해 HTML을 미리 생성하여 빠른 초기 로딩 속도를 제공하고, SEO에도 유리한 환경을 만듭니다.
  이후 클라이언트 측에서는 Hydration을 수행하여 React 컴포넌트를 초기화하고, 이벤트 리스너를 추가하여 동적인 인터랙션을 가능하게 합니다.

  Hydration이 필요한 이유는 서버에서 렌더링된 HTML만으로는 사용자 인터렉션을 처리할 수 없기 때문입니다.
  예를 들어, 서버에서 생성된 버튼이 있다고 해도 Hydration이 완료되기 전까지는 클릭 이벤트를 처리할 수 없습니다.
  React는 이를 해결하기 위해 서버에서 렌더링된 요소와 클라이언트에서 렌더링된 요소를 비교(React Reconciliation)한 후, 필요한 부분을 업데이트하여 UI를 활성화합니다.

  Hydration 과정에서 주의해야 할 점은 클라이언트와 서버에서 생성된 UI가 동일해야 한다는 점입니다.
  그렇지 않으면 React가 Hydration failed 오류를 발생시키거나, 불필요한 전체 리렌더링이 발생할 수 있습니다.
  이를 방지하기 위해 useEffect를 활용하여 클라이언트에서만 실행될 로직을 분리하거나, suppressHydrationWarning을 사용할 수 있습니다.

  결론적으로, Hydration은 서버 사이드 렌더링의 이점을 유지하면서도 클라이언트에서 동적 기능을 제공하는 핵심적인 과정이며, Next.js에서는 이를 최적화하기 위해 useEffect, useHydration, next/dynamic 등의 기능을 활용할 수 있습니다.

---

📝 개념 정리

🌟 Hydration의 개념과 필요성

• 개념: 정적인 HTML에 이벤트 핸들러를 붙여서 인터랙티브하게 만드는 React의 과정

• Next.js의 기본 렌더링 흐름은 다음과 같다.
  1. 서버에서 렌더링 (SSR/SSG/ISR)
     • 서버가 React 컴포넌트를 실행해서 순수 HTML을 만든다.
     • 이 HTML이 브라우저에 먼저 도착해서, JS가 아직 안 받아져도 사용자는 내용을 볼 수 있다.
       ➡️ FCP(First Contentful Paint)/LCP(Largest Contentful Paint) 개선
  2. 클라이언트에서 Hydration
     • 이후 브라우저가 JS 번들을 다운로드하고, 같은 컴포넌트를 클라이언트에서 한 번 더 렌더링해, 이미 있는 HTML과 React 트리를 연결하는 과정이 필요하다.
       ➡️ 이 과정이 Hydration!
     • Hydration이 끝나야 이벤트 핸들러(onClick 등) 등록, 상태 업데이트, 인터랙션이 가능해진다.

  💡 즉, SSR/SSG/ISR는 보여주는 단계, Hydration은 살리는 단계라고 이해하면 편하다.

• 왜 필요한가?
  • SSR/SSG의 장점: HTML을 바로 보내서 FCP/LCP를 빠르게 만든다.
  • CSR의 장점: 한 번 앱이 뜨고 나면 SPA처럼 빠른 내비게이션, 풍부한 상호작용이 가능하다.
  • Hydration SSR/SSG + CSR의 교차점: SSR로 빠른 화면 표시 + Hydration으로 CSR 수준의 상호작용을 동시에 얻기 위한 필수 단계이다.

---

🌟 Next.js App Router에서 Hydration이 일어나는 전체 흐름

Next.js App Router 기준으로, 첫 로드 시 렌더링 파이프라인을 단계별로 보면 다음과 같다.

• 서버에서 하는 일
  1. Server Component 렌더링
     • app/ 밑의 layout.tsx, page.tsx 등은 기본적으로 Server Component이다.
     • 이들은 브라우저가 아니라 서버에서 실행되고, 데이터를 가져오고, JSX를 렌더링한다.
  2. RSC Payload 생성
     • 서버에서 React Server Component Payload(RSC Payload)라는 특수한 데이터 포맷을 만든다.
     • 여기에는 다음 내용이 들어간다.
       • Server Component의 렌더 결과
       • Client Component가 들어갈 자리와 그 JS 파일에 대한 참조
       • Server → Client로 전달되는 props
  3. HTML 프리렌더링
     • RSC Payload + Client Component 정보를 바탕으로 HTML을 미리 렌더해 클라이언트로 스트리밍/전송한다.

• 클라이언트(브라우저)에서 하는 일 (Hydration 포함)

  1. HTML 표시
     • 서버에서 온 HTML을 바로 화면에 그린다. → 빠른, 비인터랙티브 프리뷰
  2. RSC Payload로 트리 재결합
     • 브라우저에서 React가 RSC Payload를 사용해 Server + Client Component 트리를 재구성한다.
  3. Client Component Hydration
     • 다운로드된 JS 번들을 이용해 Client Component들에 이벤트 핸들러/상태를 붙여서 인터랙티브하게 만든다.
       ➡️ 이 단계가 바로 Hydration

  💡 여기서 핵심은, Hydration은 Server Component 전체가 아니라, Client Component 부분을 대상으로 한다.

  • Server Component 부분은 HTML만 있고, JS 인터랙션 없음 (Hydration 없음)
  • Client Component로 감싼 부분만 Hydration 비용이 든다고 보면 됨

---

🌟 Hydration과 Server/Client Components의 관계

• 어떤 컴포넌트가 Hydration 대상인가?
  • Server Component
    • 기본값 (app/ 아래 대부분)
    • SSR + 데이터 패칭 + 캐싱 담당
    • 브라우저에 JS 번들이 거의 가지 않음 ➡️ Hydration 불필요
  • Client Component ("use client")
    • 이벤트 핸들러(onClick), 상태(useState), useEffect, 브라우저 API(window, localStorage) 등이 필요한 경우
    • 이 부분만 별도의 JS로 번들되어 브라우저로 보내짐 ➡️ Hydration 대상

    💡 즉, App Router에서는 "Hydration 비용 = Client Component의 양만큼"이라고 이해해도 된다.
    💡 그래서 Next.js 문서에서도 가능한 Server Component를 많이 사용해 JS 번들을 줄이고, FCP를 개선하라고 권장한다.

• 간단한 예제

  • app/posts/[id]/page.tsx: Server Component

    import LikeButton from "./LikeButton";
    import { getPost } from "@/lib/data";
    
    export default async function Page({ params }: { params: { id: string } }) {
      const post = await getPost(params.id);
      
      return (
        <main>
          <h1>{post.title}</h1>
          {/* 여기까지는 Server Component → HTML만 생성 */}
          <LikeButton initialLikes={post.likes} />
        </main>
      );
    }

  • app/posts/[id]/LikeButton.tsx: Client Component

    "use client";
    
    import { useState } from "react";
    
    export default function LikeButton({ initialLikes }: { initialLikes: number }) {
      const [likes, setLikes] = useState(initialLikes);
      return (
        <button onClick={() => setLikes((v) => v + 1)}>
          좋아요 {likes}
        </button>
      );
    }

  • 서버에서는 LikeButton까지 포함된 HTML을 프리렌더한다.
  • 클라이언트에서는 LikeButton에 대한 JS가 다운로드된 후, 이 버튼 DOM에 onClick과 state를 연결하는 Hydration이 수행된다.

---

🌟 React 18, Streaming SSR, Selective Hydration과 Next.js

예전(React 17까지)의 SSR은 거의 "올-오어-낫싱(all-or-nothing) Hydration"이었다.

• 모든 데이터 로딩 → 전체 HTML 생성 → 전체 JS 번들 다운로드 → 전체 트리를 한 번에 Hydration
• 이 방식의 문제: JS가 무거워질수록 TTI(Time To Interactive), TBT(Total Blocking Time) 같은 성능 지표가 나빠진다.

1. Streaming SSR
   React 18 + Next.js는 Streaming SSR을 도입했다.
   • 서버가 HTML을 한 번에 다 보내는 게 아니라, 빠르게 준비된 부분부터 chunk 단위로 스트리밍한다.
   • 사용자는 페이지 일부라도 먼저 볼 수 있다.
   • Next.js에서 loading.js 파일을 쓰면, Suspense를 통해 이 스트리밍 경험을 더 쉽게 구성할 수 있다.

2. Selective Hydration
   React 18의 핵심 기능 중 하나가 Selective Hydration이다.
   • 예전: 한 번에 전체 페이지를 Hydration → 인터랙션 가능
   • 지금:
     • HTML이 스트리밍되는 동시에,
     • React가 일부 컴포넌트만 우선 Hydration 할 수 있다.
     • 특히 사용자가 먼저 상호작용하려는 컴포넌트를 우선적으로 Hydration한다.

• 예시 흐름
  1. 상단 Hero 섹션, 네비게이션 같은 가벼운 부분 → 먼저 스트리밍 + Hydration
  2. 아래 무거운 차트, 대시보드 → JS가 준비된 후에 천천히 Hydration
  3. 사용자가 아래 차트를 스크롤해 클릭하면 → React가 그 부분 Hydration을 우선순위로 올려서 처리

💡 Next.js App Router에서는 Streaming SSR + Selective Hydration + Server Components를 조합해서 "빨리 보이고, 필요한 곳만 먼저 반응하는" 렌더링/하이드레이션 전략을 구현하고 있다.

---

🌟 Hydration 에러(불일치)와 원인

Hydration에서 가장 자주 보는 게 바로 Hydration mismatch 경고/에러이다.

• Hydration mismatch란?
  • 서버에서 만든 HTML과 클라이언트에서 같은 컴포넌트를 다시 렌더링한 결과가 조금이라도 다르면 React가 경고를 띄운다. (텍스트, 태그 구조 등)
  • 예: 서버에서 <span>1</span>을 보냈는데, 클라이언트에서는 <span>2</span>이라고 생각하는 상황

• Hydration mismatch의 대표적인 원인
  대부분은 서버/클라이언트에서 다른 값으로 렌더링되는 코드 때문에 생긴다.
  1. 브라우저 전용 API 사용
     • window, document, localStorage, navigator 등
     • 서버 렌더링 시에는 존재하지 않기 때문에 분기 처리 없으면 에러/불일치
     • Next.js도 이런 문제를 환경 오염(environment poisoning)이라고 부르며, Server Component에서 브라우저 API를 직접 사용하지 말라고 경고한다.
  2. 랜덤 값/현재 시간에 의존하는 렌더링
     • Math.random(), Date.now(), new Date() 등을 바로 JSX에 사용하면, 서버 렌더링과 클라이언트 렌더링 결과가 거의 항상 다르다.
  3. 조건부 렌더링이 클라이언트에서만 다른 경우
     • 예: 로그인 여부를 SSR 시점 정보가 아니라, localStorage에서만 읽어서 결정하는 UI
       • 서버: 로컬스토리지 없음 → A 버전으로 렌더
       • 클라이언트: 로컬스토리지 있음 → B 버전으로 렌더 ➡️ mismatch
  4. 외부 UI 라이브러리의 스타일/구조 차이
     • MUI, Chakra 등 일부 컴포넌트가 브라우저 환경에서만 스타일 계산 → SSR 결과와 맞지 않을 수 있다.

• Next.js에서의 대표적인 해결 패턴

  1. 브라우저 전용 로직은 Client Component 안에서만

     "use client";
     
     import { useEffect, useState } from "react";
     
     export default function ClientOnly() {
       const [mounted, setMounted] = useState(false);
       
       useEffect(() => {
         setMounted(true);
       }, []);
       
       if (!mounted) {
         // 서버와 클라이언트가 동일하게 렌더되도록
         // 초기에는 아무것도 안 보여주거나 skeleton만 보여줌
         return null;
       }
       
       return <div>브라우저 전용 정보: {window.innerWidth}</div>;
     }

     • "use client" 파일 안으로 분리하고,
     • 거기에서 useEffect, useState로 마운트 이후에 브라우저 값을 읽는 방식을 사용한다.

  2. 서버/클라이언트 렌더 결과를 같게 유지

     • 초기 렌더에서는 서버와 클라이언트가 동일한 값을 사용하도록 만들고,
     • 값 차이는 useEffect 이후에 반영한다. (예: 실제 시간 업데이트)

  3. 정말 어쩔 수 없을 때 suppressHydrationWarning

     <div suppressHydrationWarning>
       {isClient ? "클라이언트 값" : "서버 값"}
     </div>

     • 일부 텍스트만 의도적으로 다를 수밖에 없을 때 사용한다.
     • 하지만 근본 해결책은 아니고, 마지막 수단에 가깝다.

  4. Client-only 라이브러리는 동적 import + ssr: false

     • 예: window에 강하게 의존하는 차트 라이브러리
     • Next.js에서 dynamic(() => import('./Chart'), { ssr: false }) 방식으로 렌더링을 클라이언트에서만 하게 해서 mismatch를 제거한다.

---

🌟 Next.js에서 Hydration 관련 실무 체크리스트

1. Server vs. Client 컴포넌트 설계
   • 기본은 Server Component: 데이터 패칭, SEO 중요한 콘텐츠, 정적 텍스트
   • 정말 필요한 곳만 Client Component: 버튼 클릭, 폼 입력, 토글 UI, 모달처럼 상호작용이 있는 부분
   • 상호작용이 없는 컴포넌트는 무조건 Server Component가 디폴트라고 생각하면 Hydration 비용이 자동으로 줄어든다.

2. 브라우저 의존 로직 다루기
   • window, document, localStorage 등은
     • Server Component에서 직접 사용하지 않는다.
     • "use client" 컴포넌트 + useEffect 안에서만 사용한다.
   • 시간/랜덤 값
     • 서버/클라이언트에 따라 변하지 않는 값(예: DB에서 온 timestamp)을 우선 사용한다.
     • 현재 시간처럼 계속 변하는 값은 초기 렌더를 서버 기준으로 맞추고, 마운트 후 클라이언트에서 업데이트한다.

3. Heavy 컴포넌트 최적화
   • 차트, 에디터, 지도 등 무거운 컴포넌트는
     • 동적 import + Suspense로 Hydration 시점을 조절한다.
     • 필요하다면 ssr: false로 완전히 클라이언트를 렌더링한다.
   • 화면에 보이는 순간까지만 Hydration하고 싶다면
     • IntersectionObserver나 "스크롤 시점에 로딩"같은 패턴을 사용한다.

4. Hydration mismatch 디버깅 습관
   경고 메시지(텍스트/DOM 불일치)를 보면
   • 해당 컴포넌트가 Server인지 Client인지 확인한다.
   • 초기 렌더에 랜덤/시간/브라우저 API가 개입하는지 확인한다.
   • 필요하다면
     • 클라이언트 전용으로 분리
     • 초기 렌더 값을 고정
     • suppressHydrationWarning은 마지막 수단으로만 사용한다.