React와 Virtual DOM 자세히 알아보기
React의 Virtual DOM이라고 표현하곤 하죠. 대부분 Virtual DOM에 집중을 하게 됩니다. 하지만 Virtual DOM을 이해하기 전에, React가 무엇인지 부터 알아보고 가는게 좋습니다.
React는 무엇인가?
React는 무엇일까요? 프론트 개발을 도와주는 라이브러리? 웹 개발을 하기 위한 신기술? 많은 정의가 있겠지만, 저는 React의 공식 홈페이지에서 이 해답을 찾아보았습니다.
Zoom image will be displayed
이제는 레거시가 된 이전 공식 홈페이지 이지만, 많은 정보를 얻을 수 있습니다. 상단의 가운데 글귀를 보면 React가 무엇인지에 대해 간단한 해답을 바로 찾을 수 있습니다.
사용자 인터페이스를 만들기 위한 JavaScript 라이브러리
깔끔하죠? 사용자 인터페이스가 UI를 뜻 하므로, React는 JavaScript UI 라이브러리 라고 정리하면 되겠습니다.
여기서 끝내지 않고, 왼쪽 아래 ‘선언형’ 문단을 보면 더 자세한 정보를 알 수 있는데요.
React는 상호작용이 많은 UI를 만들 때 생기는 어려움을 줄여줍니다.
(…중략)
React는 데이터가 변경됨에 따라 적절한 컴포넌트만 효율적으로 갱신하고 렌더링합니다.
React는 상호작용이 많은 UI를 만들때 생기는 어려움을 줄여 준다고 합니다. 이는 이전에 브라우저가 복잡한 인터렉션을 하기 위해 DOM이 탄생했던 것과 비슷한 느낌을 주는 것 같네요. 자 이제 React에 대해 알았으니 Virtual DOM에 대해 알아보겠습니다.
React는 왜 Virtual DOM을 사용하고자 했는가?
글의 초입에 작성 했듯이 Virtual DOM이란 가상의 문서 객체 모델 입니다. 즉, React는 DOM을 직접적으로 조작하며 동작하는 것이 아닌 가상의 DOM을 사용한다는 뜻이죠. 이 사실을 알고 나면 자연스레 떠오르는 질문이 있을겁니다. React는 왜 굳이 가상의 문서 객체 모델을 사용한 것 일까요? Virtual DOM을 사용하기 이전에는 어떤 문제점이 있었길래 이를 보완하고자 만들어 낸 것 일까요? 이 의문점을 한번 풀어보겠습니다.
기존 방식의 문제점
React가 개발되기 전의 상황을 생각해보겠습니다. 당시에도 React 처럼 웹 개발에 도움을 주는 도구들이 존재했습니다. 그 중 AngularJS도 있었는데요. 이에 대해 알아보도록 하겠습니다.
AngularJS의 Dirty Checking 방식의 문제점
AngularJS는 변경을 감지하기 위해 Dirty Checking 방식을 사용했습니다. 이는 데이터 모델을 주기적으로 검사하며 변경된 점이 있는지를 감지하는 방법인데요. 간단한 회원가입 폼을 예시로 들어보겠습니다.
Zoom image will be displayed
이메일, 비밀번호, 이름, 전화번호를 input으로 입력받는 회원가입 폼 입니다. AngularJS는 이를 아래와 같은 형식으로 정리하고 다이제스트 루프(Digest Loop) 라고 칭하는 것이 돌며 주기적으로 변경되는 것을 확인하고 반영합니다.
Zoom image will be displayed
만약 이 때 이메일의 값이 변경된다면 dirty 여부가 true로 변하게 되고, 다이제스트 루프가 이를 확인해 View에 반영시킵니다.
Zoom image will be displayed
이 방식의 장점은 개발자가 지금까지의 과정을 위해 어떠한 것도 하지 않아도 된다는 것입니다. AngularJS의 프레임워크에서 알아서 동작해서 반영해주는 것이죠. 그렇다면 한계점은 무엇일까요? 조금 생각해보면 바로 예상할 수 있습니다.
만약 @watchlist가 4개가 아니라 50개면 어떨까요? 100개면요? 이처럼 루프를 돌아야 하는 데이터의 양이 많아질 수록 그 성능은 저하될 수 밖에 없을 겁니다. 물론 하나의 페이지에 너무 많은 데이터가 생기는 구조 자체가 잘못된 것이라고 볼 수 있지만, 그걸 감안하더라도 대규모 어플리케이션에 부적절한 방식이라는 것은 알 수 있습니다. React는 이러한 방식을 사용하지 않고, Virtual DOM을 사용해 이러한 한계점을 극복하고자 했습니다.
※ 해당 게시물은 React를 집중적으로 알아보고 있습니다. 다만 이것이 React가 항상 정답임을 뜻하지 않으며, 상황에 따라 적합한 도구를 선택하는 것이 중요합니다.
React의 동작 방식
그렇다면 React의 Virtual DOM은 어떻게 동작하는 것 일까요? 워낙 복잡하고 많은 내용을 담고 있어 지금 하나하나 알아보기는 어려우므로 간단하게 구조에 대해서 알아보겠습니다.
Virtual DOM
React는 메모리 상에 Virtual DOM을 저장해두어 데이터 변경을 감지하고 실제 DOM에 반영하는데 사용합니다. Virtual DOM은 Tree 구조로 되어 있습니다. 특정 노드에 변화가 된 것이 감지 되었을 때 React는 실제 DOM을 조작하는 것이 아닌, Virtual DOM Tree를 메모리 상에 새로 만들어 이전 버전의 Virtual DOM Tree와 비교합니다. 그리고 실제로 변경 된 부분만 모아서 실제 DOM에 반영시킵니다. 그림으로 보자면 아래와 같습니다.
Zoom image will be displayed
왜 이렇게 했을까요? 변화가 감지 되었을 때 굳이 Virtual DOM Tree를 사용할 필요가 있을까요? 결론부터 말하자면 Virtual DOM Tree를 쓰지 않고 실제 DOM에 반영 하는 방식을 사용한다고 해서 동작이 불가한 것이 아닙니다. 그러나 매번 실제 DOM에 반영하게 되면 Virtual DOM을 사용하는 것과 비교하여 성능이 저하 될 수 있습니다. 실제 DOM 에 반영한다는 것은 브라우저가 reflow, repaint 과정을 진행하게 한다는 것이기 때문이죠. input 의 입력 값이 하나씩 바뀔 때 마다 모든 DOM을 reflow, repaint 하는 것은 굉장히 비효율적일 것입니다. 때문에 메모리 상에 Virtual DOM Tree를 비교하고 바뀐 부분만 반영시켜 reflow, repaint 과정을 최소화 하는 것이 성능에 이점을 가져갈 수 있습니다.
Zoom image will be displayed
이 때 변화가 감지되고 변경 된 부분을 모아서 실제 DOM 에 반영 하기까지의 과정을 Reconciliation(재조정) 이라고 부릅니다.
Reconciliation
React 16 버전 이전에는 Stack Reconciliation 이라는 이름의 재조정 방식을 사용했습니다. Stack Reconciliation 이란 단어 그대로 stack 구조를 사용한 재조정 방식인데요. 변화가 감지되어 새로운 Virtual DOM Tree를 생성하고, 이전 버전과 비교할 때 stack 구조를 사용하여 비교하는 것입니다. 이는 React 16 버전부터 Fiber Reconciliation 으로 탈바꿈하게 됩니다.
Stack Reconciliation 의 한계점
그렇다면 Stack Reconciliation은 어떤 한계점을 가지고 있어 Fiber Reconciliation으로 변경 된 것일까요? 대표적으로는 Tree 구조를 사용하는것과 JavaScript의 Call Stack을 사용하는 것에 대한 한계점이 있었습니다.
Tree 구조의 한계점
Virtual DOM Tree 라고 칭하는 것에서 알 수 있듯이 Virtual DOM은 Tree 구조로 이루어져 있습니다. 이 같이 두 개의 Tree를 비교하려면 재귀적인 알고리즘으로 동작해야 합니다. 재귀적으로 동작한다는 것은, 다르게 말하면 중간에 멈추거나 다시 시작할 수 없음을 의미합니다. 즉, 시작하면 무조건 끝을 보아야 한다는 것이죠. 아무리 급한 일이 생기더라도 시작한 작업이 끝날 때 까지 다른 일을 할 수 없습니다.
JavaScript Call Stack 사용의 한계점
이는 Tree 구조에서 오는 한계점에 이어지는 한계점 입니다. Stack Reconciliation 작업은 JavaScript의 Call Stack 위에서 진행됩니다. JavaScript는 싱글 스레드를 사용중이죠. 그런데 Stack Reconciliation 작업은 재귀적으로 동작하여 중간에 멈출 수 없습니다. 만약 Reconciliation 작업이 길어진다면 유저의 클릭 이벤트나 브라우저의 화면 렌더링이 아예 동작하지 않을 수 있습니다. Stack Reconciliation은 이러한 한계점을 가지고 있어 React 개발자들은 또 다른 Reconciliation Architecture를 만들고자 했습니다.
안녕하세요. 저는 KCD 금융사업팀 Frontend Engineer로 재직 중인 hyunee(황주현) 라고 합니다. 올해 4월경에 React Fiber Architecture 라는 주제로 사내 테크톡 발표를 진행했는데요. 회사 구성원 외에 저희 회사에 관심 있는 분들에게도 이 내용을 공유하면 좋을 것 같아 글을 작성하게 되었습니다.
들어가며
React가 Fiber를 사용한다는 말은 프론트 개발을 하며 React를 사용해 보신 분이라면 한번 쯤 들어보았을 것입니다. 그러나 프론트 개발을 시작한 지 얼마 되지 않았거나, 아직 React 에 익숙하지 않은 분이라면 자세한 내용을 알기 어려울 수 있습니다. 이번 게시글에서는 바로 기술적인 내용을 들어가는 것이 아닌, 조금 더 기초적인 부분 부터 차근차근 접근해 나가며 React Fiber에 대해 이해해보고자 합니다.
React와 Virtual DOM
React Fiber 를 본격적으로 알아보기 앞서 React의 Virtual DOM 에 대해 알아보고 넘어고자 합니다.
“React 는 Virtual DOM을 사용한다.” 라는 말은 프론트 개발을 하시는 분이라면 익숙한 말입니다. 그런데 Virtual DOM이라고 불리는 것은 무엇일까요? 한번 같이 차근차근 알아보겠습니다.
질문의 시작
Virtual DOM이 뭐지?
Virtual DOM은 Virtual + DOM 가 합쳐진 합성어 입니다. 사전적인 정의부터 알아볼까요? Virtual은 ‘(컴퓨터를 이용한) 가상의’ 라는 뜻을 지니고 있습니다. DOM은 무엇일까요? 이는 Document Object Model 의 약자로, 직역 하자면 문서 객체 모델 이라는 뜻을 가지고 있습니다. 즉, 여기까지 정리하자면 아래와 같습니다.
따라서 Virtual DOM 은 가상 문서 객체 모델이라는 의미를 지닙니다. 이걸 알고 나면 또 다른 질문이 생기게 됩니다.
DOM(문서객체모델) 이 뭐지?
DOM은 프로그래밍 언어가 HTML 또는 XML 를 보다 쉽게 접근하고 조작하기 위해 표현하는 프로그래밍 인터페이스를 의미합니다. 웹의 경우에서 프로그래밍 언어는 JavaScript를 의미합니다. 문자열로 되어있는 HTML코드를 쉽게 조작하고자 DOM을 사용한다고 볼 수 있습니다. <p></p>와 같은 태그 문자열을 조작하는게 아닌, pElement.appendChild(otherNode) 와 같은 방법을 사용하는 것이 실수를 방지하는 데도 도움을 주기 때문이죠. 그럼 다음으로 떠오르는 질문은 뭘까요?
왜 DOM을 탄생시킨거지?
어떠한 기술이 새로 만들어진다는 건 기존에 존재하던 문제점을 개선하거나, 보완하기 위해서 일 것입니다. 기존의 기술에 문제점이 없다면 굳이 새로이 기술을 만들어낼 필요가 없기 때문이죠. 그렇다면 DOM이 만들어진 이유는 무엇일까요?
앞서 서술했듯이 JavaScript에서 HTML을 쉽고 안전하게 조작하기 위해 만들어졌습니다. 여기서 좀 더 나아가볼까요? HTML을 간편하게 조작할 수 있다는 건, 이전보다 더 많은 조작을 할 수 있다는 것을 의미합니다. 단순히 HTML 파일을 서버에서 받아와 그려주기만 하는 것이 아닌, 브라우저 내에서 여러 복잡한 인터렉션을 사용할 수 있게됨을 뜻하죠. 즉, DOM을 사용하게 되면 더 많은 행위를 브라우저에서 할 수 있게 된다는 것을 알 수 있습니다. 다르게 말하면 더 많은 행위를 브라우저에서 하고 싶었다는 것이죠.
왜 브라우저에서 이런저런 걸 하고 싶어 졌을까?
DOM이 탄생하던 당시는 1990년대 말로 알려져 있습니다. 이 당시에는 어떤 일이 있었을까요? 저도 이 시대를 경험해보지 않았지만, 기록에 따르면 Microsoft와 Netscape 두 회사간의 소위 ‘브라우저 전쟁’ 이 일어나고 있을 때 입니다. 이 전쟁 에서 승리하고자 했다면 어떤 것이 필요 했을까요? 사용자들이 조금 더 우리 회사의 브라우저를 사용하게끔 만들어야 했을 것입니다. 그러기 위해서는 브라우저가 더 많은 것을 지원하는 것이 좋았을 것이죠.
다만 이름에서도 알 수 있듯이 HTML(HyperText Markup Language)은 정적인 문서를 웹 상에 표현하는게 목적 이었기 때문에 복잡한 기능을 제공하기에는 한계가 있었습니다. 때문에 각 회사는 이 HTML을 좀 더 쉽게 조작할 수 있는 방법을 고안하여 DOM 구조를 개발 했었고, 이것이 DOM이 탄생하게 된 시초라고 할 수 있겠습니다.
여기까지 정리
지금까지 DOM 이 무엇인지, 이것이 왜 탄생하게 되었는지에 대해서 알아보았습니다. 간단히 요약해 보자면 아래와 같습니다.
자, 이제 우리는 DOM의 시초와 그것이 무엇인지에 대해 알고 있습니다. 그렇다면 이제 React와 Virtual DOM에 대해서 알아보겠습니다.
React와 Virtual DOM 자세히 알아보기
React의 Virtual DOM이라고 표현하곤 하죠. 대부분 Virtual DOM에 집중을 하게 됩니다. 하지만 Virtual DOM을 이해하기 전에, React가 무엇인지 부터 알아보고 가는게 좋습니다.
React는 무엇인가?
React는 무엇일까요? 프론트 개발을 도와주는 라이브러리? 웹 개발을 하기 위한 신기술? 많은 정의가 있겠지만, 저는 React의 공식 홈페이지에서 이 해답을 찾아보았습니다.
이제는 레거시가 된 이전 공식 홈페이지 이지만, 많은 정보를 얻을 수 있습니다. 상단의 가운데 글귀를 보면 React가 무엇인지에 대해 간단한 해답을 바로 찾을 수 있습니다.
깔끔하죠? 사용자 인터페이스가 UI를 뜻 하므로, React는 JavaScript UI 라이브러리 라고 정리하면 되겠습니다.
여기서 끝내지 않고, 왼쪽 아래 ‘선언형’ 문단을 보면 더 자세한 정보를 알 수 있는데요.
React는 상호작용이 많은 UI를 만들때 생기는 어려움을 줄여 준다고 합니다. 이는 이전에 브라우저가 복잡한 인터렉션을 하기 위해 DOM이 탄생했던 것과 비슷한 느낌을 주는 것 같네요. 자 이제 React에 대해 알았으니 Virtual DOM에 대해 알아보겠습니다.
React는 왜 Virtual DOM을 사용하고자 했는가?
글의 초입에 작성 했듯이 Virtual DOM이란 가상의 문서 객체 모델 입니다. 즉, React는 DOM을 직접적으로 조작하며 동작하는 것이 아닌 가상의 DOM을 사용한다는 뜻이죠. 이 사실을 알고 나면 자연스레 떠오르는 질문이 있을겁니다. React는 왜 굳이 가상의 문서 객체 모델을 사용한 것 일까요? Virtual DOM을 사용하기 이전에는 어떤 문제점이 있었길래 이를 보완하고자 만들어 낸 것 일까요? 이 의문점을 한번 풀어보겠습니다.
기존 방식의 문제점
React가 개발되기 전의 상황을 생각해보겠습니다. 당시에도 React 처럼 웹 개발에 도움을 주는 도구들이 존재했습니다. 그 중 AngularJS도 있었는데요. 이에 대해 알아보도록 하겠습니다.
AngularJS의 Dirty Checking 방식의 문제점
AngularJS는 변경을 감지하기 위해 Dirty Checking 방식을 사용했습니다. 이는 데이터 모델을 주기적으로 검사하며 변경된 점이 있는지를 감지하는 방법인데요. 간단한 회원가입 폼을 예시로 들어보겠습니다.
이메일, 비밀번호, 이름, 전화번호를 input으로 입력받는 회원가입 폼 입니다. AngularJS는 이를 아래와 같은 형식으로 정리하고 다이제스트 루프(Digest Loop) 라고 칭하는 것이 돌며 주기적으로 변경되는 것을 확인하고 반영합니다.
만약 이 때 이메일의 값이 변경된다면 dirty 여부가 true로 변하게 되고, 다이제스트 루프가 이를 확인해 View에 반영시킵니다.
이 방식의 장점은 개발자가 지금까지의 과정을 위해 어떠한 것도 하지 않아도 된다는 것입니다. AngularJS의 프레임워크에서 알아서 동작해서 반영해주는 것이죠. 그렇다면 한계점은 무엇일까요? 조금 생각해보면 바로 예상할 수 있습니다.
만약 @watchlist가 4개가 아니라 50개면 어떨까요? 100개면요? 이처럼 루프를 돌아야 하는 데이터의 양이 많아질 수록 그 성능은 저하될 수 밖에 없을 겁니다. 물론 하나의 페이지에 너무 많은 데이터가 생기는 구조 자체가 잘못된 것이라고 볼 수 있지만, 그걸 감안하더라도 대규모 어플리케이션에 부적절한 방식이라는 것은 알 수 있습니다. React는 이러한 방식을 사용하지 않고, Virtual DOM을 사용해 이러한 한계점을 극복하고자 했습니다.
React의 동작 방식
그렇다면 React의 Virtual DOM은 어떻게 동작하는 것 일까요? 워낙 복잡하고 많은 내용을 담고 있어 지금 하나하나 알아보기는 어려우므로 간단하게 구조에 대해서 알아보겠습니다.
Virtual DOM
React는 메모리 상에 Virtual DOM을 저장해두어 데이터 변경을 감지하고 실제 DOM에 반영하는데 사용합니다. Virtual DOM은 Tree 구조로 되어 있습니다. 특정 노드에 변화가 된 것이 감지 되었을 때 React는 실제 DOM을 조작하는 것이 아닌, Virtual DOM Tree를 메모리 상에 새로 만들어 이전 버전의 Virtual DOM Tree와 비교합니다. 그리고 실제로 변경 된 부분만 모아서 실제 DOM에 반영시킵니다. 그림으로 보자면 아래와 같습니다.
왜 이렇게 했을까요? 변화가 감지 되었을 때 굳이 Virtual DOM Tree를 사용할 필요가 있을까요? 결론부터 말하자면 Virtual DOM Tree를 쓰지 않고 실제 DOM에 반영 하는 방식을 사용한다고 해서 동작이 불가한 것이 아닙니다. 그러나 매번 실제 DOM에 반영하게 되면 Virtual DOM을 사용하는 것과 비교하여 성능이 저하 될 수 있습니다. 실제 DOM 에 반영한다는 것은 브라우저가 reflow, repaint 과정을 진행하게 한다는 것이기 때문이죠. input 의 입력 값이 하나씩 바뀔 때 마다 모든 DOM을 reflow, repaint 하는 것은 굉장히 비효율적일 것입니다. 때문에 메모리 상에 Virtual DOM Tree를 비교하고 바뀐 부분만 반영시켜 reflow, repaint 과정을 최소화 하는 것이 성능에 이점을 가져갈 수 있습니다.
이 때 변화가 감지되고 변경 된 부분을 모아서 실제 DOM 에 반영 하기까지의 과정을 Reconciliation(재조정) 이라고 부릅니다.
Reconciliation
React 16 버전 이전에는 Stack Reconciliation 이라는 이름의 재조정 방식을 사용했습니다. Stack Reconciliation 이란 단어 그대로 stack 구조를 사용한 재조정 방식인데요. 변화가 감지되어 새로운 Virtual DOM Tree를 생성하고, 이전 버전과 비교할 때 stack 구조를 사용하여 비교하는 것입니다. 이는 React 16 버전부터 Fiber Reconciliation 으로 탈바꿈하게 됩니다.
Stack Reconciliation 의 한계점
그렇다면 Stack Reconciliation은 어떤 한계점을 가지고 있어 Fiber Reconciliation으로 변경 된 것일까요? 대표적으로는 Tree 구조를 사용하는것과 JavaScript의 Call Stack을 사용하는 것에 대한 한계점이 있었습니다.
Tree 구조의 한계점
Virtual DOM Tree 라고 칭하는 것에서 알 수 있듯이 Virtual DOM은 Tree 구조로 이루어져 있습니다. 이 같이 두 개의 Tree를 비교하려면 재귀적인 알고리즘으로 동작해야 합니다. 재귀적으로 동작한다는 것은, 다르게 말하면 중간에 멈추거나 다시 시작할 수 없음을 의미합니다. 즉, 시작하면 무조건 끝을 보아야 한다는 것이죠. 아무리 급한 일이 생기더라도 시작한 작업이 끝날 때 까지 다른 일을 할 수 없습니다.
JavaScript Call Stack 사용의 한계점
이는 Tree 구조에서 오는 한계점에 이어지는 한계점 입니다. Stack Reconciliation 작업은 JavaScript의 Call Stack 위에서 진행됩니다. JavaScript는 싱글 스레드를 사용중이죠. 그런데 Stack Reconciliation 작업은 재귀적으로 동작하여 중간에 멈출 수 없습니다. 만약 Reconciliation 작업이 길어진다면 유저의 클릭 이벤트나 브라우저의 화면 렌더링이 아예 동작하지 않을 수 있습니다. Stack Reconciliation은 이러한 한계점을 가지고 있어 React 개발자들은 또 다른 Reconciliation Architecture를 만들고자 했습니다.
React Fiber Architechture의 탄생
드디어 Fiber Architecture에 다다랐습니다. DOM, React, Virtual DOM, Stack Reconciliation 까지 일련의 과정을 알고 있어야 비로소 Fiber Architecture의 필요성에 대해 깊게 이해할 수 있습니다. Fiber는 React 16 버전부터 적용된 새로운 Reconciliation Architecture 라고 말할 수 있습니다. 어떤 목표로 탄생했는지, 그 동작 방식은 무엇인지 알아보도록 하겠습니다.
React Fiber Architecture의 목표
Fiber Architecture는 Tree구조와 Call Stack을 사용하는 한계점을 벗어나고자 했습니다. 이를 위해 스케줄링(Scheduling)이 가능한 Reconciliation 을 만들기 위해 4가지 목표를 설정했습니다.
위와 같은 4가지 목표를 달성하게 된다면 작업 자체가 길더라도 멈췄다가 재시작 하여 다른 이벤트가 실행되도록 유연하게 동작할 수 있고, 이전 작업을 재사용하여 불필요한 작업을 방지할 수도 있습니다.
Fiber 구조
LCRS Tree
Virtual DOM은 Tree 구조로 되어있기 때문에 재귀적인 동작이 불가피했습니다. 이를 해결하고자 Fiber Node는 일반적인 Tree가 아닌 LCRS(Left Children Right Sibling) Tree로 구현되었습니다. 아래 예시와 함께 보면 이해가 빠릅니다
LCRS Tree 구조를 차용함에 따라 작업이 중간에 멈추더라도 해당 노드부터 다시 시작할 수 있게 되었습니다.
Double Buffering
Virtual DOM Tree는 현재 실제 돔에 마운트 되어있는 current와 새로이 작업 중인 workInProgress 두 개의 트리를 가집니다. 이렇게 한 이유는 4번째 목표를 이루기 위해서 입니다. current와 별개로 작업이 진행중인 workInProgress 를 사용하면 작업이 필요 없어졌을 때 Virtual DOM Tree의 작업을 되돌리는 개념이 아닌, 그저 workInProgress 를 버리면 되기 때문입니다.
Fiber Reconciliation의 동작 방식
Fiber Reconciliation 과정은 2개의 Phase가 존재합니다.
Render Phase
Render Phase는 Virtual DOM을 조작하는 모든 일련의 과정으로, 해당 단계가 끝나면 재조정이 완료된 Virtual DOM를 얻게 됩니다. 또한 실제 DOM에 마운트 해야 하는 내용들을 모아 둔 effect list 도 산출됩니다. 해당 Phase는 중간에 멈추고 다시 시작할 수 있습니다.
Commit Phase
Render Phase에서 산출 된 effect list를 토대로 실제 DOM에 반영을 진행합니다. 이 과정은 중간에 멈출 수 없으며 동기적으로 한번에 진행되게 됩니다. 이 과정으로 실제 DOM 반영을 완료해 단계가 종료되며 Call Stack 점유가 끝나면, 브라우저가 UI에 반영하게 됩니다.
마치며
이번 게시글에서는 DOM의 탄생부터 React 의 Fiber Architecture 까지, 그 과정을 간략하게 알아보았습니다. 사실 React는 지금 소개한 것 보다 훨신 복잡하고 자세하며 체계적으로 연결되어 있습니다. 기술을 잘 사용하는 것도 중요하지만, 그 기술이 어떠한 필요로 탄생했으며 어떤 방식으로 동작 하는지 이해하는 것이 ‘잘하는 개발자’ 의 덕목 중 하나가 아닐까 생각이 됩니다.
당장에 기술을 사용함에만 급급하는것이 아닌, 동작 원리부터 차근차근 알아보는 것은 어떨까요?