React render phase와 commit phase, 리렌더링이 DOM에 반영되기까지
빠른 답
- render phase는 무엇이 바뀌어야 하는지 계산하는 단계라서 다시 실행되거나 중단될 수 있습니다.
- commit phase는 계산 결과를 실제 DOM에 반영하는 단계라서 짧고 일관되게 끝나는 것이 중요합니다.
- DOM 접근, 측정, 외부 부수효과는 render가 아니라 commit 이후 훅에서 처리해야 안전합니다.
- React 18 이후에는 render가 곧바로 화면 반영으로 이어진다고 보면 동작을 잘못 이해하기 쉽습니다.
목차
한눈에 비교
render phase: 컴포넌트를 호출해 다음 UI 스냅샷을 계산하는 단계입니다. 같은 입력이면 같은 출력이 나와야 하는 순수 계산이어야 합니다.commit phase: render 결과를 실제 DOM에 반영하는 단계입니다. ref 연결, DOM mutation, effect 실행 준비가 여기서 이어집니다.useLayoutEffect: commit 직후, 브라우저가 그리기 전에 실행됩니다. DOM 크기 측정이나 위치 보정처럼 paint 전에 끝나야 하는 작업에 맞습니다.useEffect: 외부 시스템과 동기화하는 용도입니다. 보통은 paint 뒤에 실행되지만, 사용자 상호작용으로 시작된 업데이트에서는 paint 전에 관찰될 수도 있습니다.- 실무 기준으로는 파생값 계산은 render, DOM 측정은
useLayoutEffect, 네트워크·구독·타이머·로그 수집은useEffect로 나누면 거의 틀리지 않습니다.
흐름으로 보기
React 공식 문서는 이 과정을 trigger → render → commit으로 설명합니다. 여기에 브라우저의 paint와 effect 타이밍까지 붙여 보면, setState 직후 왜 DOM이 아직 안 바뀌어 보이는지, 왜 useLayoutEffect가 깜빡임을 막는지, 왜 useEffect에서 외부 시스템 동기화를 처리하는지가 한 줄로 정리됩니다.
왜 render phase와 commit phase를 자주 헷갈릴까
헷갈리는 출발점은 대부분 "리렌더링됐다"라는 말을 너무 넓게 쓰는 데 있습니다. React에서 state는 즉시 덮어쓰는 변수가 아니라, 각 렌더에 전달되는 스냅샷에 가깝습니다. State as a Snapshot 관점에서 보면 setState는 현재 함수 안의 값을 바꾸는 게 아니라, 다음 render를 예약하는 동작입니다.
여기서 중요한 축이 상태 소유권입니다. 상태는 한 군데가 소유하고, 아래로는 props로 흘러가야 합니다. 부모가 상태를 소유하고 자식이 그 값을 읽는 단방향 흐름이 유지되면, React는 어떤 서브트리를 다시 계산해야 하는지 명확하게 판단할 수 있습니다. 반대로 같은 의미의 데이터를 여러 컴포넌트가 중복으로 저장하면 render 타이밍보다 먼저 데이터 모델이 흔들립니다.
실무에서 자주 생기는 오해는 두 가지입니다.
- 컴포넌트 함수가 다시 호출되면 화면도 이미 바뀌었다고 생각하는 경우
useEffect가 항상 "렌더 직후 즉시" 실행된다고 생각하는 경우
둘 다 정확하지 않습니다. render는 계산이고, commit이 실제 반영입니다. effect는 commit 이후 동기화 단계입니다.
상태 변경부터 화면 반영까지 따라가기
상태 변경은 그 상태를 소유한 컴포넌트에서 시작합니다. 그 업데이트가 큐에 들어가면 React는 해당 컴포넌트와 관련 하위 트리를 다시 계산합니다. 이때 render 단계에서는 컴포넌트 함수가 호출되고, 새 JSX 스냅샷이 만들어집니다.
이 스냅샷이 이전 결과와 완전히 같다면 리렌더링은 있었어도 DOM 변경은 없을 수 있습니다. Render and Commit 문서가 강조하는 지점도 여기입니다. 리렌더링 횟수와 DOM 업데이트 횟수는 같지 않습니다.
React 18 이후에는 이 구분이 더 중요해졌습니다. React 18 소개 글은 concurrent rendering의 핵심을 "interruptible rendering"으로 설명합니다. 즉, render 작업은 중간에 멈추거나 버려질 수 있지만, 사용자에게 보이는 DOM 변경은 계산이 끝난 뒤 commit에서 일관되게 반영됩니다. 그래서 console에 render 로그가 여러 번 찍혀도 DOM이 그 횟수만큼 바뀌었다고 해석하면 안 됩니다.
이 흐름을 데이터 소유권 관점에서 다시 보면 더 선명합니다.
- 상태를 소유한 컴포넌트가 업데이트를 받습니다.
- render 단계에서 새 UI를 계산합니다.
- React는 이전 결과와 비교해 실제 바꿀 부분만 추립니다.
- commit 단계에서 최소한의 DOM 변경만 적용합니다.
- 그 뒤에 layout effect와 effect가 순서대로 외부 세계와 동기화합니다.
실수를 빨리 잡는 설정
이 주제는 코드 리뷰보다 린트가 먼저 잡아주는 경우가 많습니다. 특히 set-state-in-effect와 set-state-in-render 규칙은 render와 commit의 경계를 흐리는 실수를 빠르게 드러냅니다. React 19.2 기준으로는 eslint-plugin-react-hooks 최신 버전을 쓰는 편이 안전합니다.
// eslint.config.js
import reactHooks from 'eslint-plugin-react-hooks';
export default [
{
plugins: {
'react-hooks': reactHooks,
},
rules: {
'react-hooks/rules-of-hooks': 'error',
'react-hooks/exhaustive-deps': 'warn',
'react-hooks/set-state-in-effect': 'warn',
'react-hooks/set-state-in-render': 'error',
},
},
];
이 설정은 "render에서 상태를 다시 밀어 넣는 코드"와 "effect에서 동기식으로 파생 state를 만드는 코드"를 빨리 발견하는 데 유용합니다.
render에 둘 코드와 commit 이후에 둘 코드
가장 흔한 안티패턴은 파생 데이터를 effect로 다시 state에 저장하는 것입니다. 이런 코드는 데이터 소유권을 흐리고, render 한 번이면 끝날 계산을 effect 때문에 한 번 더 render하게 만듭니다.
import { useEffect, useState } from 'react';
// 안 좋은 예: 같은 의미의 데이터를 두 군데서 관리
function BadList({ items }) {
const [selectedId, setSelectedId] = useState(null);
const [selectedItem, setSelectedItem] = useState(null);
useEffect(() => {
setSelectedItem(items.find(item => item.id === selectedId) ?? null);
}, [items, selectedId]);
return (
<>
<button onClick={() => setSelectedId(2)}>2번 선택</button>
<p>{selectedItem ? selectedItem.name : '선택 없음'}</p>
</>
);
}
// 좋은 예: 상태는 selectedId만 소유하고, 나머지는 render에서 계산
function GoodList({ items }) {
const [selectedId, setSelectedId] = useState(null);
const selectedItem = items.find(item => item.id === selectedId) ?? null;
return (
<>
<button onClick={() => setSelectedId(2)}>2번 선택</button>
<p>{selectedItem ? selectedItem.name : '선택 없음'}</p>
</>
);
}
위 예시에서 selectedItem은 외부 시스템과 동기화해야 하는 값이 아니라, 이미 가진 items와 selectedId로부터 계산 가능한 값입니다. 이런 값은 render에 둬야 합니다. React의 set-state-in-effect 규칙이 바로 이 패턴을 경고하는 이유도 같습니다.
반대로 commit 이후 훅에 둬야 하는 코드는 분명합니다.
useLayoutEffect: DOM 크기 측정, 스크롤 보정, tooltip 위치 계산useEffect: 웹소켓 연결, 이벤트 리스너 등록, 타이머, analytics, fetch 이후 외부 시스템 동기화
render 안에서 DOM을 읽거나, render 안에서 setState를 호출하거나, props를 effect로 다시 state에 복제하면 phase 경계가 무너집니다.
로그로 보는 실행 순서
타이밍은 말보다 로그가 더 정확합니다. 아래 컴포넌트는 render, useLayoutEffect, useEffect의 순서를 그대로 보여줍니다.
import { useEffect, useLayoutEffect, useState } from 'react';
export default function PhaseLogger() {
const [count, setCount] = useState(0);
console.log('render', count);
useLayoutEffect(() => {
console.log('layout effect', count);
return () => console.log('layout cleanup', count);
}, [count]);
useEffect(() => {
console.log('effect', count);
return () => console.log('effect cleanup', count);
}, [count]);
return (
<button onClick={() => setCount(c => c + 1)}>
count: {count}
</button>
);
}
프로덕션에 가까운 흐름은 대체로 아래처럼 보입니다.
초기 마운트
render 0
layout effect 0
effect 0
버튼 클릭 후
render 1
layout cleanup 0
layout effect 1
effect cleanup 0
effect 1
이 출력에서 읽어야 할 핵심은 세 가지입니다.
render가 먼저 실행됩니다.useLayoutEffect는 DOM 반영 직후, paint 전에 실행됩니다.useEffect는 더 나중에 실행됩니다.
개발 모드에서 StrictMode가 켜져 있으면 setup과 cleanup이 한 번 더 돌 수 있습니다. 이건 effect가 "이상하게 두 번 실행되는 버그"라기보다, 순수하지 않은 render나 비대칭 cleanup을 드러내기 위한 검사에 가깝습니다. 따라서 로그 횟수만 보지 말고, cleanup이 setup을 정확히 되돌리는지 먼저 봐야 합니다.
React 19.2 기준에서 달라진 설명
이 주제는 버전 차이를 같이 보지 않으면 오래된 글에 쉽게 끌려갑니다. 현재 기준은 React 19.2입니다.
첫째, Concurrent Mode를 앱 전체에서 켜는 별도 모드처럼 설명하는 글은 지금 기준으로는 오래됐습니다. React 18 이후 공식 설명은 "concurrent rendering은 기능을 통해 점진적으로 활성화되는 내부 렌더링 모델"에 가깝습니다. startTransition, Suspense, 프레임워크의 라우팅 같은 기능이 이 동작을 활용합니다.
둘째, 진입점 API가 달라졌습니다. React 19에서는 ReactDOM.render와 ReactDOM.hydrate가 제거됐고, createRoot와 hydrateRoot가 기준입니다. 오래된 예제를 그대로 가져오면 렌더링 모델 설명도 함께 뒤틀립니다.
// 오래된 예시
import { render, hydrate } from 'react-dom';
render(<App />, document.getElementById('root'));
hydrate(<App />, document.getElementById('root'));
// 현재 기준
import { createRoot, hydrateRoot } from 'react-dom/client';
const container = document.getElementById('root');
createRoot(container).render(<App />);
// SSR hydration
hydrateRoot(container, <App />);
셋째, findDOMNode 같은 예전 escape hatch는 현재 기준에서 제거됐습니다. DOM 접근은 ref로 옮겨야 합니다. render와 commit의 경계를 분리하는 방향으로 React API도 계속 정리되고 있다고 보면 됩니다.
넷째, effect 설명도 바뀌었습니다. 예전에는 ref나 dependency 무시로 우회하던 패턴이 많았지만, React 19.2에는 useEffectEvent가 공식 문서에 포함되어 있습니다. effect 내부에서 발생하는 이벤트성 로직이 최신 props와 state를 읽어야 하지만, effect 자체를 다시 연결하고 싶지는 않을 때 쓰는 도구입니다. 채팅 연결은 유지하면서 알림 테마만 최신값으로 읽고 싶은 경우가 대표적입니다.
다섯째, 서버에서의 useLayoutEffect는 여전히 레이아웃을 측정할 수 없습니다. React 19 업그레이드 과정에서 SSR warning은 줄었지만, 서버에 실제 레이아웃 정보가 생긴 것은 아닙니다. 경고가 사라졌다고 서버에서 layout measurement가 가능해진 것은 아니라는 점을 같이 기억해야 합니다.
흔한 안티패턴과 디버깅 체크포인트
- 파생 데이터를 effect로 다시 state에 저장하면 render 한 번으로 끝날 계산이 render 두 번으로 늘어납니다.
- render 안에서
setState를 호출하면 무한 루프나 예측하기 어려운 phase update 문제가 생깁니다. useLayoutEffect를 습관처럼 쓰면 paint를 막아 입력 응답성이 나빠질 수 있습니다. 정말 화면이 그려지기 전에 맞춰야 하는 경우에만 써야 합니다.- render 로그 횟수를 DOM 반영 횟수로 해석하면 안 됩니다. concurrent features와
StrictMode에서는 특히 더 틀리기 쉽습니다. - 부모와 자식이 같은 의미의 상태를 동시에 소유하면 단방향 흐름이 깨지고, 어느 값이 진짜 소스인지 빠르게 불분명해집니다.
결국 이 주제의 핵심은 단순합니다. render는 계산, commit는 반영, effect는 동기화입니다. 이 세 책임을 섞지 않으면 리렌더링과 DOM 반영 시점, 상태 소유권, 성능 문제를 훨씬 쉽게 추적할 수 있습니다.
원문 참고
https://www.maeil-mail.kr/question/30
댓글
댓글 쓰기