google.com 같은 사이트에 접속할 때 실제로 무슨 일이 벌어지는지를 이해하기 위한 오늘의 주제. 마지막인 렌더링 단계를 정리해보았다.
[네트워크]
DNS → TCP → HTTPS → index.html 다운로드
↓
[브라우저]
HTML 파싱 → JS 번들 다운로드
↓
[자바스크립트]
React/Vue 앱 실행
↓
[API 네트워크]
백엔드 API 호출
↓
[렌더링]
DOM 생성 → 화면에 UI 표시
렌더링은 회사에서 일할 때 특히나 배포를 하던 때에 프론트엔드 개발자에게서 많이 들은적이 있던 단어다. 사실 프론트엔드에 대해서는 아는게 거의 없던 나는 대충 화면에 UI를 띄워주는거이지 않을까 눈치껏 이해했던거 같다. 렌더링이란 뭘까?
1. [렌더링] 데이터 바인딩과 UI 표시
- 데이터 수신 및 상태(State) 업데이트
-
수신: fetch나 Axios가 200 OK 응답과 함께 JSON 데이터를 받아온다.
-
업데이트: 프론트엔드 프레임워크가 이 데이터를 자신의 '상태(State)'에 저장 ex) setResults(data)
- Virtual DOM 리렌더링 (Re-rendering)
데이터가 바뀌었으므로 프레임워크는 다시 한번 가상 DOM을 그린다.
- Diffing 알고리즘: 이전의 가상 DOM(로딩 중 화면)과 새 가상 DOM(검색 결과 화면)을 비교하여 바뀌어야 할 부분만 찾아낸다.
- Diffing 알고리즘의 동작 원리
브라우저는 두 개의 가상 DOM 트리를 위에서부터 아래로 비교하며 내려간다.
1) 노드 타입이 다를 경우
- 두 요소의 태그 타입이 다르면(예:<div>가<span>으로 바뀜), 그 아래의 모든 자식 노드들을 다 버리고 새로 만든다.
2)노드 타입은 같고 속성(Attribute)만 다를 경우
- 태그는 그대로 두고, 변경된 속성만 업데이트<`div class="old"`> → <`div class="new"`> (클래스 명만 교체)3) 자식 노드의 재귀적 처리 (중요: Key의 존재 이유)
- 리스트 형태의 데이터를 다룰 때 효율성을 극대화
- 문제: 리스트 맨 앞에 항목이 추가되면, 알고리즘은 모든 항목이 바뀌었다고 착각할 수 있다.
- 해결: 우리가 리스트를 만들 때 주는 key 속성을 사용. key를 비교해서 "아, 1번과 2번은 그대로고 0번만 새로 추가됐구나!"라고 판다.
- 실제 DOM 반영 (Reconciliation)
변경된 부분만 실제 브라우저 DOM에 주입한다. 이때 기존의 로딩 스피너가 사라지고 실제 검색 결과 리스트가 그 자리를 채우게 된다.
로딩 스피너(Loading Spinner): 웹사이트나 앱에서 데이터를 가져오는 동안 화면이 멈춘 것이 아니라 "지금 열심히 일하고 있으니 잠시만 기다려주세요"라는 것을 사용자에게 시각적으로 알려주는 회전하는 모양의 인디케이터를 말한다.
-> 요즘은 단순한 스피너 대신, 실제 데이터가 들어올 자리에 회색 박스로 미리 틀을 보여주는 '스켈레톤 UI'를 더 선호하기도 한다고 한다.
ex) 유튜브, 페이스북
2. 브라우저의 마지막 작업 (Reflow & Repaint)
DOM이 수정되었으므로, 브라우저는 단계에서 나왔던 렌더링 파이프라인을 다시 가동한다.
-
Layout (Reflow): 검색 결과 리스트가 들어오면서 주변 요소들의 위치와 크기를 다시 계산
-
Paint (Repaint): 텍스트 색상, 이미지, 버튼 디자인 등을 픽셀로 채운다.
-
Composite: 레이어들을 합쳐 최종 화면을 모니터에 출력
3. 사용자 경험(UX)의 완성: TTI (Time to Interactive)
단순히 화면이 보이는 것을 넘어, 사용자가 검색 결과를 클릭하거나 스크롤할 수 있게 되는 시점
-
상호작용 가능: 모든 JS 실행과 데이터 바인딩이 끝나 사용자의 입력에 즉각 반응하는 상태가 된다.
-
완료: 이제 사용자는 Google 검색 결과를 확인하고 원하는 링크로 이동할 준비가 되었다.
이렇게 길었던 google.com 접속 과정에 대한 학습이 끝났다. 백엔드 개발자로 API 정도만 신경쓰던 나로서는 네트워크라던가 브라우저라던가 관련해서 모르는 용어도 많았고 얼핏 들어본 적은 있어도 실제로 어떤 논리로 진행되는지 몰랐던 것에 대해서도 많이 알게됐다. 예전엔 배포 후에 화면이 하얗게 되어서 아무것도 안뜨면 내 머리도 하얘지면서 에러로그를 찾으려고 분주했는데... 물론 백엔드 개발자로서 할 수 있는게 그정도이긴 했지만 앞으로는 비슷한 상황이 발생할 때 조금 더 알아볼 수 있을 것 같다. 개발을 하면서 느끼는 거지만 개발을 애초에 100% 완벽하게 하는 것은 쉽지 않고 문제 상황에 직면하면 그걸 어떻게 빠르게 파악하고 또 어떤 방식으로 처리할지 선택하는 과정의 연속인 것 같다. 그 과정이 여전히 어렵긴 하지만...😅
