Virtual DOM을 'DOM을 빠르게 해주는 마법' 정도로 외워 왔는지, 아니면 reconciliation 휴리스틱과 그 한계까지 짚을 수 있는지를 가른다. 후속 질문은 보통 key 설계, 리렌더 경계, Fiber 도입 배경 같은 깊이 시험으로 이어진다.
Virtual DOM은 실제 DOM을 메모리상의 객체 트리로 떠 놓은 사본이다. 상태가 바뀌면 React는 새 트리를 만들어 이전 트리와 비교(reconciliation)하고, 달라진 노드만 실제 DOM에 반영한다. 일반 트리 비교의 O(n³)을 피하려고 두 가지 휴리스틱을 쓴다 — 타입이 다른 노드는 서브트리 전체를 교체하고, 같은 레벨 자식은 key로 비교한다. 덕분에 비교 비용은 실용적인 수준으로 떨어지지만, 휴리스틱이 어긋나는 패턴(key를 index로 쓰거나 트리 타입을 자주 바꾸는 코드)에서는 오히려 더 많은 노드를 갈아엎게 된다.
리스트에 index를 key로 썼다가 입력값이 엉뚱한 행으로 옮겨붙은 버그를 잡아본 경험이 있다면, key 설계와 reconciliation 흐름을 연결해 말할 수 있다
React Profiler로 commit 시간을 재 리렌더 범위를 좁혀본 경험이 있다면, diff 비용과 실제 DOM 갱신 비용을 구분해 설명할 수 있다
memo·useCallback을 끼웠다 빼면서 성능이 어떻게 달라지는지 본 경험이 있다면, 렌더링 경계 설계와 휴리스틱 동작을 엮어 답할 수 있다
아직 공개된 답변이 없어요. 첫 공개 답변을 남겨보세요.