문제 발생

hydration mismatch 문제가 나타난 입력, 직전 동작과 실제 결과를 함께 적습니다. 예를 들어 “가끔 실패”라고 쓰는 대신 정상 사례와 실패 사례를 하나씩 두고, 두 사례에서 달라진 version·설정·데이터를 표로 남깁니다.

사례 입력과 상태 결과
정상 가장 작은 정상 조건 기대한 결과
실패 한 조건만 달라진 재현 실제 오류·값

원인 분석

hydration mismatch는 server HTML과 browser의 첫 render가 다를 때 생기므로 시간·random·browser 전용 값과 잘못된 HTML 중첩을 먼저 확인합니다.

render에서 계산할 값, 사용자가 소유한 state와 외부 시스템 동기화를 구분합니다. update를 시작한 값과 다시 update된 dependency를 따라가면 순환 원인을 찾을 수 있습니다. 빌드 route 분류, 서버 로그, 응답 Cache-Control, RSC 요청과 데이터 쿼리 수를 구분해 본다. 정상과 실패를 번갈아 실행하고, 이 원인이 맞다면 달라져야 할 값부터 확인합니다. 관련 없는 로그와 설정을 한꺼번에 바꾸지 않습니다.

해결 방안

파생값은 가능한 한 render나 computed에서 계산하고 effect·watch는 외부 동기화에만 둡니다. 비동기 작업은 최신 요청 식별자나 취소 신호와 cleanup을 갖게 합니다. Server와 Client 경계를 좁히고 데이터 변경 계약에 맞춰 캐시 태그, 재검증과 동적 렌더링을 명시한다.

수정 전 실패 사례가 사라지고 기존 정상 사례가 유지돼야 합니다. 프로덕션 빌드에서 정적·동적 route, 번들 크기, TTFB, 캐시 적중과 관리자 변경 직후 일관성을 확인한다. 초기 render, 연속 입력, 느린 응답의 순서 역전, unmount와 SSR hydration에서 state·DOM·cleanup이 기대한 순서로 바뀌는지 확인합니다. 가장 작은 실패 입력은 자동 테스트나 실행 가능한 점검 명령으로 남깁니다.

공식 문서와 적용 범위

문서의 기본값과 동작은 version에 따라 달라질 수 있습니다. 현재 runtime·framework version, 실제 입력과 요청 흐름에서 다시 확인합니다.