# [[프론트엔드 기초 구조 이해]]

## 📌 Brief Summary
프론트엔드 기초 구조는 브라우저가 HTML, CSS, JavaScript를 시각적인 화면으로 변환하는 **중요 렌더링 경로(Critical Rendering Path)** 와 이를 효율적으로 제어하기 위한 아키텍처 및 렌더링 전략을 의미합니다 [1]. **리플로우(Reflow)와 리페인트(Repaint)를 최소화**하여 렌더링 성능을 최적화하는 것이 가장 핵심적인 과제입니다 [2, 3]. 현대 프론트엔드는 **컴포넌트 기반 아키텍처(CBA)** 를 통해 재사용성과 유지보수성을 높이며 [4], 애플리케이션의 요구사항에 따라 **CSR, SSR, SSG** 등의 렌더링 방식을 전략적으로 선택하여 사용자 경험을 극대화합니다 [5, 6]. 특히 React는 **Virtual DOM과 Fiber 아키텍처**를 도입하여 DOM 조작 비용을 줄이고 렌더링 성능을 획기적으로 개선했습니다 [7, 8].

## 📖 Core Content

**1. 브라우저 렌더링 과정 (Critical Rendering Path)**
*   **DOM 및 CSSOM 트리 생성:** 브라우저는 네트워크를 통해 전달받은 HTML을 점진적으로 파싱하여 문서의 구조를 나타내는 **DOM(Document Object Model) 트리**를 구성합니다 [9, 10]. 동시에, 렌더링을 차단(Render-blocking)하는 CSS를 파싱하여 스타일 정보를 담은 **CSSOM(CSS Object Model) 트리**를 생성합니다 [11, 12].
*   **렌더 트리(Render Tree) 구축:** DOM과 CSSOM이 결합하여 화면에 실제로 표시될 노드들만 포함하는 렌더 트리가 만들어집니다 [13, 14]. `display: none`이 적용된 요소나 `<head>` 태그 등은 시각적 출력이 없으므로 렌더 트리에 포함되지 않습니다 [14, 15].
*   **레이아웃(Layout) 및 페인트(Paint):** 렌더 트리를 기반으로 기기의 뷰포트 내에서 각 요소의 정확한 크기와 위치를 계산하는 **레이아웃(또는 리플로우)** 과정을 거칩니다 [16-18]. 이후 계산된 기하학적 형태와 스타일을 화면의 실제 픽셀로 그리는 **페인트(Paint)** 단계를 수행하며, 요소가 겹칠 경우 레이어를 합성하는 **컴포지팅(Compositing)**이 발생합니다 [19-21].

**2. Reflow 및 Repaint 최소화 최적화**
*   **개념:** **리플로우(Reflow)** 는 요소의 너비, 높이, 위치 변경이나 노드의 추가/제거 등 문서의 기하학적 구조가 바뀔 때 전체 또는 일부 레이아웃을 다시 계산하는 매우 무거운 연산입니다 [2, 3]. **리페인트(Repaint)** 는 레이아웃 변화 없이 배경색, 그림자 등 시각적 속성만 변경될 때 발생합니다 [22, 23]. 
*   **최소화 방법:** 무거운 연산인 리플로우를 줄이려면 불필요한 DOM 깊이를 줄이고, 복잡한 CSS 선택자 사용을 피해야 합니다 [24]. 레이아웃 속성을 읽고 쓰는 작업을 번갈아 하여 발생하는 '레이아웃 스래싱(Layout Thrashing)'을 피하기 위해 DOM 업데이트를 일괄 처리(Batching)하는 것이 좋습니다 [2, 25]. 복잡한 애니메이션을 구현할 때는 문서 흐름에서 벗어나도록 `position-absolute`나 `position-fixed`를 사용하며 [24], `top`이나 `left` 속성 대신 GPU 가속을 지원하는 `transform` 속성을 사용하여 렌더링 성능을 개선해야 합니다 [19, 26].

**3. DOM vs Virtual DOM과 React의 빠른 성능 (Reconciliation & Fiber)**
*   **Virtual DOM의 도입:** 실제 DOM을 직접 수정하면 렌더링 경로의 레이아웃과 페인트 단계가 매번 트리거되어 속도가 저하됩니다 [7]. React는 가벼운 메모리 내 표현인 **Virtual DOM**을 사용하여 상태 변경 전후의 가상 UI를 비교(Diffing)하고, **실제 DOM에는 변경된 부분만 최소한으로 업데이트**하여 성능을 최적화합니다 [7, 27].
*   **Reconciliation (조정 알고리즘):** React는 $O(n^3)$의 복잡도를 피하기 위해 노드 타입이 다르면 트리를 완전히 새로 구축하고, 같은 목록의 요소는 `key` 속성을 이용해 식별하는 $O(n)$ 휴리스틱 알고리즘을 사용합니다 [28, 29].
*   **Fiber 아키텍처와 성능 최적화:** React 16부터 도입된 **Fiber 아키텍처**는 동기식으로 진행되던 기존 렌더링을 작은 단위로 쪼개어, 우선순위(Lanes)에 따라 렌더링 작업을 중단하고 긴급한 사용자 입력을 먼저 처리한 뒤 재개할 수 있도록 하는 동시성(Concurrent) 렌더링을 지원합니다 [8, 30-33]. 또한 React 18의 **자동 배칭(Automatic Batching)** 은 비동기 통신 시 발생하는 여러 상태 업데이트를 하나로 묶어 불필요한 재렌더링을 방지하며 [34, 35], 최근의 **React Compiler**는 코드를 분석해 자동으로 메모이제이션을 적용하여 성능 최적화 작업을 크게 줄여줍니다 [36-38].

**4. 웹 렌더링 전략 (CSR vs SSR vs SSG)**
*   **CSR (Client-Side Rendering):** 서버에서 빈 HTML과 JavaScript 번들을 보낸 후 브라우저가 화면을 그립니다 [39, 40]. 전환 속도가 빠르고 동적 상호작용에 유리하지만, 초기 로딩이 느리고 SEO에 불리합니다 [39, 41-43].
*   **SSR (Server-Side Rendering):** 요청 시마다 서버에서 완전한 HTML을 생성해 클라이언트로 보냅니다 [44, 45]. 초기 화면 표시(FCP)가 빠르고 SEO에 우수하나, 브라우저가 JavaScript를 다운로드하고 화면에 이벤트를 연결하는 **하이드레이션(Hydration)** 과정이 끝날 때까지 상호작용(TTI)이 지연될 수 있습니다 [44-46].
*   **SSG (Static Site Generation) 및 ISR:** 빌드 시점에 미리 정적 HTML을 생성해 CDN을 통해 배포하므로 로딩 속도가 가장 빠릅니다 [47-49]. 자주 변경되지 않는 콘텐츠에 적합하며, 최신 데이터를 반영하기 위해 백그라운드에서 주기로 업데이트하는 **ISR(Incremental Static Regeneration)** 방식과 혼합할 수 있습니다 [47, 50]. 

**5. 컴포넌트 기반 아키텍처 (Component-Based Architecture, CBA)**
*   **개념 및 이점:** 애플리케이션을 특정 기능을 수행하는 독립적이고 캡슐화된 **소프트웨어 컴포넌트**들로 분할하여 조립하는 아키텍처입니다 [51-53]. 
*   **효과:** 이 구조는 한 번 만든 컴포넌트를 여러 곳에서 재사용할 수 있게 하여 개발 속도를 높입니다(Reusability) [4, 54]. 또한, 모듈성을 바탕으로 한 구성 요소가 다른 요소에 영향을 미치지 않고 독립적으로 테스트 및 유지보수될 수 있으므로, 대규모 시스템에서의 확장성(Scalability)과 팀 간 병렬 개발을 돕습니다 [4, 54-56].

## 🔗 Knowledge Connections
- **Related Topics:** [[Critical Rendering Path]], [[Virtual DOM]], Reconciliation 및 Fiber 아키텍처, 컴포넌트 기반 아키텍처(CBA), 웹 렌더링 전략(CSR, SSR, SSG)
- **Projects/Contexts:** Next.js를 활용한 하이브리드 렌더링, [[React Server Components (RSC)]], React Compiler 및 Automatic Batching 적용
- **Contradictions/Notes:** 소스 X[44-46]는 SSR이 SEO와 초기 콘텐츠 로딩(FCP) 측면에서 유리하다고 주장하지만, 동시에 브라우저가 대용량 JavaScript 번들을 다운로드하고 하이드레이션(Hydration)을 마칠 때까지 사용자와의 상호작용(TTI)이 심각하게 지연되는 단점이 존재한다고 설명합니다. 한편, 소스 Y[57, 58]는 React Compiler가 도입되어 수동 메모이제이션의 90%를 자동으로 처리한다고 밝히고 있으나, Effect의 의존성 제어가 필요한 특정 상황이나 서드파티 라이브러리 연동 시에는 여전히 `useMemo` 및 `useCallback`과 같은 수동 제어가 필요함을 지적합니다.

---
*Last updated: 2026-04-25*