From 7dc7e0436cfad017aa6c65534099f72c295cf2ea Mon Sep 17 00:00:00 2001 From: Antigravity Agent Date: Sun, 26 Apr 2026 09:43:15 +0900 Subject: [PATCH] feat: batch wikify raw data into Master Archive and specialized categories Processed 70+ files covering Skybound mechanics, Frontend mastery, and Business strategy. --- .../Business_Strategy/E-commerce Platforms.md | 22 ++++ .../Business_Strategy/Meta Quest Store.md | 18 +++ ...SaaS 플랫폼 및 인터랙티브 대시보드 개발.md | 23 ++++ ...자상거래 플랫폼 (E-commerce Platforms).md | 24 ++++ ...vivors_Loop_and_Stage_Curve_Preparation.md | 116 ++++++++++++++++++ ...und_Miniboss_Treasure_Cache_Reward_Loop.md | 109 ++++++++++++++++ ...eward_Card_Clarity_and_Command_Cache_UI.md | 104 ++++++++++++++++ .../Topics/Frontend_Mastery/CSS Modules.md | 30 +++++ 10_Wiki/Topics/Frontend_Mastery/CSS-in-JS.md | 28 +++++ .../CSSOM(CSS Object Model).md | 18 +++ .../Component-Based Architecture (CBA).md | 30 +++++ .../Component-Based Architecture.md | 32 +++++ ...Web Vitals Optimization (INP, LCP 개선).md | 31 +++++ .../Frontend_Mastery/Core Web Vitals.md | 18 +++ .../DOM (Document Object Model).md | 25 ++++ .../Topics/Frontend_Mastery/DOM 및 CSSOM.md | 31 +++++ .../DOM(Document Object Model).md | 25 ++++ .../Frontend_Mastery/E-commerce Platforms.md | 22 ++++ .../Feature-Sliced Design (FSD).md | 18 +++ .../Fiber 아키텍처 (Fiber Architecture).md | 25 ++++ .../Interaction to Next Paint (INP).md | 21 ++++ .../Frontend_Mastery/Island Architecture.md | 17 +++ 10_Wiki/Topics/Frontend_Mastery/Lane Model.md | 31 +++++ .../Topics/Frontend_Mastery/Lanes Model.md | 31 +++++ 10_Wiki/Topics/Frontend_Mastery/Lighthouse.md | 18 +++ .../Frontend_Mastery/Meta Quest Store.md | 18 +++ .../Frontend_Mastery/Next.js App Router.md | 18 +++ ... Hybrid Rendering (SSR-CSR-RSC 혼합 적용).md | 18 +++ ... 성능 최적화 하이브리드 렌더링 아키텍처 설계.md | 28 +++++ ... 활용한 하이브리드 렌더링 및 SEO 최적화.md | 28 +++++ .../React 18 & 19 Performance Optimization.md | 28 +++++ .../React 18 Concurrent Features.md | 25 ++++ 10_Wiki/Topics/Frontend_Mastery/React 19.md | 18 +++ .../Frontend_Mastery/React Fiber 아키텍처.md | 24 ++++ .../Frontend_Mastery/React Flight Protocol.md | 17 +++ .../React Frontend Development.md | 35 ++++++ ...eact 기반 대규모 웹 애플리케이션 최적화.md | 31 +++++ ...성 훅 (useTransition, useDeferredValue).md | 25 ++++ ... 최적화 (React Performance Optimization).md | 29 +++++ .../React 컴파일러 (React Compiler).md | 19 +++ .../Frontend_Mastery/Reflow & Repaint.md | 34 +++++ .../Frontend_Mastery/Reflow와 Repaint.md | 30 +++++ ...SaaS 플랫폼 및 인터랙티브 대시보드 개발.md | 23 ++++ .../Topics/Frontend_Mastery/Sanity Studio.md | 18 +++ .../Topics/Frontend_Mastery/Tailwind CSS.md | 24 ++++ .../Topics/Frontend_Mastery/Time Slicing.md | 17 +++ .../Topics/Frontend_Mastery/Time-Slicing.md | 18 +++ .../Virtual DOM과 Reconciliation.md | 37 ++++++ .../Zero-Runtime CSS-in-JS.md | 28 +++++ 10_Wiki/Topics/Frontend_Mastery/flushSync.md | 20 +++ .../Frontend_Mastery/startTransition.md | 18 +++ .../Frontend_Mastery/useDeferredValue.md | 22 ++++ .../useTransition 및 useDeferredValue.md | 18 +++ .../Topics/Frontend_Mastery/useTransition.md | 19 +++ .../가상 DOM (Virtual DOM) 및 Fiber.md | 27 ++++ ... 재조정 (Virtual DOM and Reconciliation).md | 33 +++++ .../검색 엔진 최적화 (SEO).md | 19 +++ ...일 페이지 애플리케이션(SPA) 렌더링 설계.md | 25 ++++ ...규모 엔지니어링 프론트엔드 아키텍처 구축.md | 38 ++++++ ... 기반 애플리케이션 및 전자상거래 플랫폼 구축.md | 22 ++++ .../동시성 렌더링 (Concurrent Rendering).md | 25 ++++ ...링 차단 리소스(Render-blocking resources).md | 22 ++++ .../리플로우 및 리페인트(Reflow & Repaint).md | 27 ++++ ...플로우 및 리페인트(Reflow and Repaint).md | 28 +++++ ...비스 아키텍처 (Microservices Architecture).md | 27 ++++ .../메인 스레드 (Main Thread).md | 25 ++++ ...er 엔진 교체 및 React 18, 19의 동시성 렌더링 적용 사례.md | 29 +++++ ...리식 아키텍처 (Monolithic Architecture).md | 25 ++++ .../무거운 데이터 리스트 필터링 구현.md | 23 ++++ ...저 렌더링 과정 (Critical Rendering Path).md | 20 +++ ... 렌더링 파이프라인(Critical Rendering Path).md | 26 ++++ .../웹 렌더링 전략 (CSR, SSR, SSG, ISR).md | 37 ++++++ ...능 최적화(Web Performance Optimization).md | 25 ++++ ...자상거래 플랫폼 (E-commerce Platforms).md | 24 ++++ .../점진적 정적 재생성 (ISR).md | 27 ++++ ...과 작업 우선순위 (Lane Model & Priorities).md | 31 +++++ .../초기 로드 시간 (Initial Load Time).md | 28 +++++ .../컨테이너 쿼리(Container Queries).md | 19 +++ ...기반의 이커머스 및 뉴스 웹사이트 성능 튜닝.md | 18 +++ .../크로스 플랫폼 디자인 시스템 연동.md | 17 +++ ...컬 렌더링 패스 (Critical Rendering Path).md | 26 ++++ .../클라이언트 사이드 렌더링 (CSR).md | 29 +++++ ...각 반응해야 하는 검색창 (Search-as-you-type).md | 18 +++ .../프론트엔드 기초 구조 이해 핵심 목적.md | 25 ++++ ...엔드 렌더링 최적화(Rendering Optimization).md | 41 +++++++ ...트엔드 성능 최적화 및 SEO 개선 프로젝트.md | 29 +++++ ...능 최적화(Frontend Performance Optimization).md | 28 +++++ ...트엔드 프레임워크 (React, Angular, Vue).md | 29 +++++ .../하이드레이션 (Hydration).md | 28 +++++ ...vivors_Loop_and_Stage_Curve_Preparation.md | 116 ++++++++++++++++++ ...und_Miniboss_Treasure_Cache_Reward_Loop.md | 109 ++++++++++++++++ ...eward_Card_Clarity_and_Command_Cache_UI.md | 104 ++++++++++++++++ ...Web Vitals Optimization (INP, LCP 개선).md | 31 +++++ .../DOM (Document Object Model).md | 25 ++++ .../Topics_Art/UI_UX_Assets/DOM 및 CSSOM.md | 31 +++++ .../DOM(Document Object Model).md | 25 ++++ ... Hybrid Rendering (SSR-CSR-RSC 혼합 적용).md | 18 +++ .../React 18 & 19 Performance Optimization.md | 28 +++++ .../React 18 Concurrent Features.md | 25 ++++ 10_Wiki/Topics_Art/UI_UX_Assets/React 19.md | 18 +++ .../UI_UX_Assets/React Fiber 아키텍처.md | 24 ++++ .../UI_UX_Assets/React Flight Protocol.md | 17 +++ .../React Frontend Development.md | 35 ++++++ ...eact 기반 대규모 웹 애플리케이션 최적화.md | 31 +++++ ...성 훅 (useTransition, useDeferredValue).md | 25 ++++ ... 최적화 (React Performance Optimization).md | 29 +++++ .../React 컴파일러 (React Compiler).md | 19 +++ .../Virtual DOM과 Reconciliation.md | 37 ++++++ .../가상 DOM (Virtual DOM) 및 Fiber.md | 27 ++++ ... 재조정 (Virtual DOM and Reconciliation).md | 33 +++++ .../동시성 렌더링 (Concurrent Rendering).md | 25 ++++ ...링 차단 리소스(Render-blocking resources).md | 22 ++++ ...er 엔진 교체 및 React 18, 19의 동시성 렌더링 적용 사례.md | 29 +++++ ...저 렌더링 과정 (Critical Rendering Path).md | 20 +++ ... 렌더링 파이프라인(Critical Rendering Path).md | 26 ++++ ...능 최적화(Web Performance Optimization).md | 25 ++++ ...컬 렌더링 패스 (Critical Rendering Path).md | 26 ++++ ...엔드 렌더링 최적화(Rendering Optimization).md | 41 +++++++ ...능 최적화(Frontend Performance Optimization).md | 28 +++++ ...트엔드 프레임워크 (React, Angular, Vue).md | 29 +++++ .../Business_Strategy/E-commerce Platforms.md | 22 ++++ .../Business_Strategy/Meta Quest Store.md | 18 +++ ...SaaS 플랫폼 및 인터랙티브 대시보드 개발.md | 23 ++++ ...자상거래 플랫폼 (E-commerce Platforms).md | 24 ++++ ...vivors_Loop_and_Stage_Curve_Preparation.md | 116 ++++++++++++++++++ ...und_Miniboss_Treasure_Cache_Reward_Loop.md | 109 ++++++++++++++++ ...eward_Card_Clarity_and_Command_Cache_UI.md | 104 ++++++++++++++++ 127 files changed, 3968 insertions(+) create mode 100644 10_Wiki/Topics/Business_Strategy/E-commerce Platforms.md create mode 100644 10_Wiki/Topics/Business_Strategy/Meta Quest Store.md create mode 100644 10_Wiki/Topics/Business_Strategy/SaaS 플랫폼 및 인터랙티브 대시보드 개발.md create mode 100644 10_Wiki/Topics/Business_Strategy/전자상거래 플랫폼 (E-commerce Platforms).md create mode 100644 10_Wiki/Topics/Frontend_Mastery/2026-04-25-Skybound_Vampire_Survivors_Loop_and_Stage_Curve_Preparation.md create mode 100644 10_Wiki/Topics/Frontend_Mastery/2026-04-26-Skybound_Miniboss_Treasure_Cache_Reward_Loop.md create mode 100644 10_Wiki/Topics/Frontend_Mastery/2026-04-26-Skybound_Reward_Card_Clarity_and_Command_Cache_UI.md create mode 100644 10_Wiki/Topics/Frontend_Mastery/CSS Modules.md create mode 100644 10_Wiki/Topics/Frontend_Mastery/CSS-in-JS.md create mode 100644 10_Wiki/Topics/Frontend_Mastery/CSSOM(CSS Object Model).md create mode 100644 10_Wiki/Topics/Frontend_Mastery/Component-Based Architecture (CBA).md create mode 100644 10_Wiki/Topics/Frontend_Mastery/Component-Based Architecture.md create mode 100644 10_Wiki/Topics/Frontend_Mastery/Core Web Vitals Optimization (INP, LCP 개선).md create mode 100644 10_Wiki/Topics/Frontend_Mastery/Core Web Vitals.md create mode 100644 10_Wiki/Topics/Frontend_Mastery/DOM (Document Object Model).md create mode 100644 10_Wiki/Topics/Frontend_Mastery/DOM 및 CSSOM.md create mode 100644 10_Wiki/Topics/Frontend_Mastery/DOM(Document Object Model).md create mode 100644 10_Wiki/Topics/Frontend_Mastery/E-commerce Platforms.md create mode 100644 10_Wiki/Topics/Frontend_Mastery/Feature-Sliced Design (FSD).md create mode 100644 10_Wiki/Topics/Frontend_Mastery/Fiber 아키텍처 (Fiber Architecture).md create mode 100644 10_Wiki/Topics/Frontend_Mastery/Interaction to Next Paint (INP).md create mode 100644 10_Wiki/Topics/Frontend_Mastery/Island Architecture.md create mode 100644 10_Wiki/Topics/Frontend_Mastery/Lane Model.md create mode 100644 10_Wiki/Topics/Frontend_Mastery/Lanes Model.md create mode 100644 10_Wiki/Topics/Frontend_Mastery/Lighthouse.md create mode 100644 10_Wiki/Topics/Frontend_Mastery/Meta Quest Store.md create mode 100644 10_Wiki/Topics/Frontend_Mastery/Next.js App Router.md create mode 100644 10_Wiki/Topics/Frontend_Mastery/Next.js 기반의 Hybrid Rendering (SSR-CSR-RSC 혼합 적용).md create mode 100644 10_Wiki/Topics/Frontend_Mastery/Next.js를 활용한 SEO 및 성능 최적화 하이브리드 렌더링 아키텍처 설계.md create mode 100644 10_Wiki/Topics/Frontend_Mastery/Next.js를 활용한 하이브리드 렌더링 및 SEO 최적화.md create mode 100644 10_Wiki/Topics/Frontend_Mastery/React 18 & 19 Performance Optimization.md create mode 100644 10_Wiki/Topics/Frontend_Mastery/React 18 Concurrent Features.md create mode 100644 10_Wiki/Topics/Frontend_Mastery/React 19.md create mode 100644 10_Wiki/Topics/Frontend_Mastery/React Fiber 아키텍처.md create mode 100644 10_Wiki/Topics/Frontend_Mastery/React Flight Protocol.md create mode 100644 10_Wiki/Topics/Frontend_Mastery/React Frontend Development.md create mode 100644 10_Wiki/Topics/Frontend_Mastery/React 기반 대규모 웹 애플리케이션 최적화.md create mode 100644 10_Wiki/Topics/Frontend_Mastery/React 동시성 훅 (useTransition, useDeferredValue).md create mode 100644 10_Wiki/Topics/Frontend_Mastery/React 성능 최적화 (React Performance Optimization).md create mode 100644 10_Wiki/Topics/Frontend_Mastery/React 컴파일러 (React Compiler).md create mode 100644 10_Wiki/Topics/Frontend_Mastery/Reflow & Repaint.md create mode 100644 10_Wiki/Topics/Frontend_Mastery/Reflow와 Repaint.md create mode 100644 10_Wiki/Topics/Frontend_Mastery/SaaS 플랫폼 및 인터랙티브 대시보드 개발.md create mode 100644 10_Wiki/Topics/Frontend_Mastery/Sanity Studio.md create mode 100644 10_Wiki/Topics/Frontend_Mastery/Tailwind CSS.md create mode 100644 10_Wiki/Topics/Frontend_Mastery/Time Slicing.md create mode 100644 10_Wiki/Topics/Frontend_Mastery/Time-Slicing.md create mode 100644 10_Wiki/Topics/Frontend_Mastery/Virtual DOM과 Reconciliation.md create mode 100644 10_Wiki/Topics/Frontend_Mastery/Zero-Runtime CSS-in-JS.md create mode 100644 10_Wiki/Topics/Frontend_Mastery/flushSync.md create mode 100644 10_Wiki/Topics/Frontend_Mastery/startTransition.md create mode 100644 10_Wiki/Topics/Frontend_Mastery/useDeferredValue.md create mode 100644 10_Wiki/Topics/Frontend_Mastery/useTransition 및 useDeferredValue.md create mode 100644 10_Wiki/Topics/Frontend_Mastery/useTransition.md create mode 100644 10_Wiki/Topics/Frontend_Mastery/가상 DOM (Virtual DOM) 및 Fiber.md create mode 100644 10_Wiki/Topics/Frontend_Mastery/가상 DOM과 재조정 (Virtual DOM and Reconciliation).md create mode 100644 10_Wiki/Topics/Frontend_Mastery/검색 엔진 최적화 (SEO).md create mode 100644 10_Wiki/Topics/Frontend_Mastery/단일 페이지 애플리케이션(SPA) 렌더링 설계.md create mode 100644 10_Wiki/Topics/Frontend_Mastery/대규모 엔지니어링 프론트엔드 아키텍처 구축.md create mode 100644 10_Wiki/Topics/Frontend_Mastery/대규모 콘텐츠 기반 애플리케이션 및 전자상거래 플랫폼 구축.md create mode 100644 10_Wiki/Topics/Frontend_Mastery/동시성 렌더링 (Concurrent Rendering).md create mode 100644 10_Wiki/Topics/Frontend_Mastery/렌더링 차단 리소스(Render-blocking resources).md create mode 100644 10_Wiki/Topics/Frontend_Mastery/리플로우 및 리페인트(Reflow & Repaint).md create mode 100644 10_Wiki/Topics/Frontend_Mastery/리플로우 및 리페인트(Reflow and Repaint).md create mode 100644 10_Wiki/Topics/Frontend_Mastery/마이크로서비스 아키텍처 (Microservices Architecture).md create mode 100644 10_Wiki/Topics/Frontend_Mastery/메인 스레드 (Main Thread).md create mode 100644 10_Wiki/Topics/Frontend_Mastery/메인 스레드 차단 문제 해결을 위한 React 16의 Fiber 엔진 교체 및 React 18, 19의 동시성 렌더링 적용 사례.md create mode 100644 10_Wiki/Topics/Frontend_Mastery/모놀리식 아키텍처 (Monolithic Architecture).md create mode 100644 10_Wiki/Topics/Frontend_Mastery/무거운 데이터 리스트 필터링 구현.md create mode 100644 10_Wiki/Topics/Frontend_Mastery/브라우저 렌더링 과정 (Critical Rendering Path).md create mode 100644 10_Wiki/Topics/Frontend_Mastery/브라우저 렌더링 파이프라인(Critical Rendering Path).md create mode 100644 10_Wiki/Topics/Frontend_Mastery/웹 렌더링 전략 (CSR, SSR, SSG, ISR).md create mode 100644 10_Wiki/Topics/Frontend_Mastery/웹 성능 최적화(Web Performance Optimization).md create mode 100644 10_Wiki/Topics/Frontend_Mastery/전자상거래 플랫폼 (E-commerce Platforms).md create mode 100644 10_Wiki/Topics/Frontend_Mastery/점진적 정적 재생성 (ISR).md create mode 100644 10_Wiki/Topics/Frontend_Mastery/차선 모델과 작업 우선순위 (Lane Model & Priorities).md create mode 100644 10_Wiki/Topics/Frontend_Mastery/초기 로드 시간 (Initial Load Time).md create mode 100644 10_Wiki/Topics/Frontend_Mastery/컨테이너 쿼리(Container Queries).md create mode 100644 10_Wiki/Topics/Frontend_Mastery/콘텐츠 기반의 이커머스 및 뉴스 웹사이트 성능 튜닝.md create mode 100644 10_Wiki/Topics/Frontend_Mastery/크로스 플랫폼 디자인 시스템 연동.md create mode 100644 10_Wiki/Topics/Frontend_Mastery/크리티컬 렌더링 패스 (Critical Rendering Path).md create mode 100644 10_Wiki/Topics/Frontend_Mastery/클라이언트 사이드 렌더링 (CSR).md create mode 100644 10_Wiki/Topics/Frontend_Mastery/타이핑에 즉각 반응해야 하는 검색창 (Search-as-you-type).md create mode 100644 10_Wiki/Topics/Frontend_Mastery/프론트엔드 기초 구조 이해 핵심 목적.md create mode 100644 10_Wiki/Topics/Frontend_Mastery/프론트엔드 렌더링 최적화(Rendering Optimization).md create mode 100644 10_Wiki/Topics/Frontend_Mastery/프론트엔드 성능 최적화 및 SEO 개선 프로젝트.md create mode 100644 10_Wiki/Topics/Frontend_Mastery/프론트엔드 성능 최적화(Frontend Performance Optimization).md create mode 100644 10_Wiki/Topics/Frontend_Mastery/프론트엔드 프레임워크 (React, Angular, Vue).md create mode 100644 10_Wiki/Topics/Frontend_Mastery/하이드레이션 (Hydration).md create mode 100644 10_Wiki/Topics/Skybound/2026-04-25-Skybound_Vampire_Survivors_Loop_and_Stage_Curve_Preparation.md create mode 100644 10_Wiki/Topics/Skybound/2026-04-26-Skybound_Miniboss_Treasure_Cache_Reward_Loop.md create mode 100644 10_Wiki/Topics/Skybound/2026-04-26-Skybound_Reward_Card_Clarity_and_Command_Cache_UI.md create mode 100644 10_Wiki/Topics_Art/UI_UX_Assets/Core Web Vitals Optimization (INP, LCP 개선).md create mode 100644 10_Wiki/Topics_Art/UI_UX_Assets/DOM (Document Object Model).md create mode 100644 10_Wiki/Topics_Art/UI_UX_Assets/DOM 및 CSSOM.md create mode 100644 10_Wiki/Topics_Art/UI_UX_Assets/DOM(Document Object Model).md create mode 100644 10_Wiki/Topics_Art/UI_UX_Assets/Next.js 기반의 Hybrid Rendering (SSR-CSR-RSC 혼합 적용).md create mode 100644 10_Wiki/Topics_Art/UI_UX_Assets/React 18 & 19 Performance Optimization.md create mode 100644 10_Wiki/Topics_Art/UI_UX_Assets/React 18 Concurrent Features.md create mode 100644 10_Wiki/Topics_Art/UI_UX_Assets/React 19.md create mode 100644 10_Wiki/Topics_Art/UI_UX_Assets/React Fiber 아키텍처.md create mode 100644 10_Wiki/Topics_Art/UI_UX_Assets/React Flight Protocol.md create mode 100644 10_Wiki/Topics_Art/UI_UX_Assets/React Frontend Development.md create mode 100644 10_Wiki/Topics_Art/UI_UX_Assets/React 기반 대규모 웹 애플리케이션 최적화.md create mode 100644 10_Wiki/Topics_Art/UI_UX_Assets/React 동시성 훅 (useTransition, useDeferredValue).md create mode 100644 10_Wiki/Topics_Art/UI_UX_Assets/React 성능 최적화 (React Performance Optimization).md create mode 100644 10_Wiki/Topics_Art/UI_UX_Assets/React 컴파일러 (React Compiler).md create mode 100644 10_Wiki/Topics_Art/UI_UX_Assets/Virtual DOM과 Reconciliation.md create mode 100644 10_Wiki/Topics_Art/UI_UX_Assets/가상 DOM (Virtual DOM) 및 Fiber.md create mode 100644 10_Wiki/Topics_Art/UI_UX_Assets/가상 DOM과 재조정 (Virtual DOM and Reconciliation).md create mode 100644 10_Wiki/Topics_Art/UI_UX_Assets/동시성 렌더링 (Concurrent Rendering).md create mode 100644 10_Wiki/Topics_Art/UI_UX_Assets/렌더링 차단 리소스(Render-blocking resources).md create mode 100644 10_Wiki/Topics_Art/UI_UX_Assets/메인 스레드 차단 문제 해결을 위한 React 16의 Fiber 엔진 교체 및 React 18, 19의 동시성 렌더링 적용 사례.md create mode 100644 10_Wiki/Topics_Art/UI_UX_Assets/브라우저 렌더링 과정 (Critical Rendering Path).md create mode 100644 10_Wiki/Topics_Art/UI_UX_Assets/브라우저 렌더링 파이프라인(Critical Rendering Path).md create mode 100644 10_Wiki/Topics_Art/UI_UX_Assets/웹 성능 최적화(Web Performance Optimization).md create mode 100644 10_Wiki/Topics_Art/UI_UX_Assets/크리티컬 렌더링 패스 (Critical Rendering Path).md create mode 100644 10_Wiki/Topics_Art/UI_UX_Assets/프론트엔드 렌더링 최적화(Rendering Optimization).md create mode 100644 10_Wiki/Topics_Art/UI_UX_Assets/프론트엔드 성능 최적화(Frontend Performance Optimization).md create mode 100644 10_Wiki/Topics_Art/UI_UX_Assets/프론트엔드 프레임워크 (React, Angular, Vue).md create mode 100644 10_Wiki/Topics_Biz/Business_Strategy/E-commerce Platforms.md create mode 100644 10_Wiki/Topics_Biz/Business_Strategy/Meta Quest Store.md create mode 100644 10_Wiki/Topics_Biz/Business_Strategy/SaaS 플랫폼 및 인터랙티브 대시보드 개발.md create mode 100644 10_Wiki/Topics_Biz/Business_Strategy/전자상거래 플랫폼 (E-commerce Platforms).md create mode 100644 10_Wiki/Topics_GD/Balancing/2026-04-25-Skybound_Vampire_Survivors_Loop_and_Stage_Curve_Preparation.md create mode 100644 10_Wiki/Topics_GD/Balancing/2026-04-26-Skybound_Miniboss_Treasure_Cache_Reward_Loop.md create mode 100644 10_Wiki/Topics_GD/Balancing/2026-04-26-Skybound_Reward_Card_Clarity_and_Command_Cache_UI.md diff --git a/10_Wiki/Topics/Business_Strategy/E-commerce Platforms.md b/10_Wiki/Topics/Business_Strategy/E-commerce Platforms.md new file mode 100644 index 00000000..b3ff3f19 --- /dev/null +++ b/10_Wiki/Topics/Business_Strategy/E-commerce Platforms.md @@ -0,0 +1,22 @@ +# [[E-commerce Platforms]] + +## 📌 Brief Summary +E-commerce Platforms(이커머스 플랫폼)은 제품 카탈로그, 장바구니, 결제 처리 등의 기능을 제공하여 온라인 상거래를 지원하는 시스템입니다 [1, 2]. 이 시스템의 핵심은 검색 엔진 최적화(SEO)를 통한 제품 발견, 빠른 페이지 로딩을 통한 구매 전환율 향상, 그리고 재고 및 가격 변동을 반영하는 최신 데이터의 유지입니다 [3-5]. 소스 자료에 따르면, 이커머스 플랫폼은 성능과 확장성을 극대화하기 위해 SSR(서버 사이드 렌더링), ISR(점진적 정적 재생성)과 같은 최적화된 웹 렌더링 전략과 컴포넌트 기반 아키텍처(CBA)를 적극적으로 채택합니다 [2, 6]. + +## 📖 Core Content +* **이커머스 플랫폼을 위한 웹 렌더링 전략 (Web Rendering Strategies):** + * **SSR (Server-Side Rendering):** 이커머스 플랫폼의 제품 목록 페이지, 카테고리 탐색 및 개별 제품 상세 페이지에 가장 이상적인 렌더링 방식 중 하나입니다 [3]. 서버에서 제품의 세부 정보, 가격, 구매 버튼이 포함된 완전한 HTML을 즉시 제공하므로, 자바스크립트 로딩을 기다릴 필요 없이 사용자에게 콘텐츠를 보여주어 구매 전환율을 크게 향상시킵니다 [5]. 또한 훌륭한 SEO를 제공하여 제품 검색 노출에 유리하며, 항상 최신의 실시간 데이터를 요구하는 결제(Checkout) 페이지에 적합합니다 [3, 7]. + * **SSG (Static Site Generation):** 제품 라인이 변동 없이 안정적이고 콘텐츠 업데이트 주기가 규칙적인 제품 카탈로그 페이지에 적용될 수 있습니다 [8]. + * **ISR (Incremental Static Regeneration):** 이커머스 플랫폼에 최적의 균형(성능과 최신성)을 제공하는 고도화된 접근 방식입니다 [4, 6]. 대규모 제품 카탈로그를 초고속으로 로딩하는 동시에, 전체 사이트를 다시 빌드하는 오버헤드 없이 백그라운드에서 재고 정보와 가격을 주기적으로 업데이트하여 최신 상태로 유지할 수 있습니다 [4, 6, 9]. + +* **컴포넌트 기반 아키텍처 적용 (Component-Based Architecture):** + * 이커머스 플랫폼은 제품 목록(Product listings), 결제 게이트웨이(Payment gateways), 장바구니(Shopping carts), 고객 리뷰 모듈 등 명확히 분리된 기능을 가진 재사용 가능한 소프트웨어 컴포넌트들의 조립으로 구축됩니다 [2]. + * 이러한 모듈식 접근 방식을 통해 비즈니스가 확장됨에 따라 새로운 결제 옵션을 추가하거나 제품 추천 기능을 갱신해야 할 때, 플랫폼 전체에 중단을 일으키지 않고 특정 컴포넌트만 쉽게 교체하거나 확장할 수 있는 유연성을 확보합니다 [2, 10]. + +## 🔗 Knowledge Connections +- **Related Topics:** [[Server-Side Rendering (SSR)]], [[Incremental Static Regeneration (ISR)]], [[Component-Based Architecture]], [[Search Engine Optimization (SEO)]] +- **Projects/Contexts:** 대규모 트래픽을 처리하면서도 검색 엔진 노출을 극대화하고 실시간 재고/가격 변동을 반영해야 하는 프론트엔드 웹 성능 최적화 및 렌더링 아키텍처 구축 맥락 [3, 4, 7]. +- **Contradictions/Notes:** 제공된 소스는 이커머스 플랫폼의 백엔드 비즈니스 로직이나 운영 모델보다는 주로 프론트엔드의 화면 렌더링 최적화(SSR/ISR)와 아키텍처(컴포넌트화) 측면에 초점을 맞추고 있어, 결제 시스템의 내부 동작 원리 등에 대해서는 소스에 관련 정보가 부족합니다. + +--- +*Last updated: 2026-04-25* \ No newline at end of file diff --git a/10_Wiki/Topics/Business_Strategy/Meta Quest Store.md b/10_Wiki/Topics/Business_Strategy/Meta Quest Store.md new file mode 100644 index 00000000..04477daf --- /dev/null +++ b/10_Wiki/Topics/Business_Strategy/Meta Quest Store.md @@ -0,0 +1,18 @@ +# [[Meta Quest Store]] + +## 📌 Brief Summary +Meta Quest Store는 Meta에서 운영하는 플랫폼으로, 제공된 문서 내에서는 프론트엔드 성능 최적화 도구인 React Compiler를 실제 프로덕션 환경에 성공적으로 도입한 대표적인 사례로만 짧게 등장합니다 [1, 2]. 해당 스토어의 구체적인 서비스 목적, 판매 항목, 혹은 전반적인 아키텍처에 대해서는 소스에 관련 정보가 부족합니다. + +## 📖 Core Content +- **React Compiler의 성공적 배포**: Meta는 대중에게 공개하기 전 자사 애플리케이션 생태계 전반에 걸쳐 React Compiler를 내부적으로 테스트했으며, Instagram과 함께 Meta Quest Store에 성공적으로 배포했습니다 [1, 2]. +- **로딩 속도 지표 개선**: 수동 메모이제이션(Manual Memoization) 문제를 해결하는 React Compiler 적용 결과, Quest Store의 로딩 속도는 최소 4% 이상 향상되었으며, 초기 로딩(initial loads) 시간은 최대 12%까지 개선되었습니다 [2]. +- **상호작용(Interaction)의 즉각성**: 최적화의 결과로 Quest Store 내의 복잡한 제품 페이지(complex product pages)들이 눈에 띄게 빠르게 로드되었습니다 [1]. 특히 일부 상호작용은 2배 이상 빨라져 사용자들이 거의 즉각적(instantaneous)이라고 느낄 수 있는 수준의 개선이 이루어졌습니다 [1, 2]. +- 이외에 플랫폼 자체의 상업적 기능이나 비즈니스 로직 등에 대해서는 소스에 관련 정보가 부족합니다. + +## 🔗 Knowledge Connections +- **Related Topics:** [[React Compiler]], [[Performance Optimization]] +- **Projects/Contexts:** [[Meta's Internal Testing (React Compiler 성능 검증)]] +- **Contradictions/Notes:** Meta Quest Store에 대한 독립적이고 포괄적인 설명은 제공된 소스에 관련 정보가 부족합니다. 오직 React Compiler의 적용으로 인한 성능 최적화 지표를 보여주는 단편적인 사례(Case Study)로만 활용되었습니다. + +--- +*Last updated: 2026-04-25* \ No newline at end of file diff --git a/10_Wiki/Topics/Business_Strategy/SaaS 플랫폼 및 인터랙티브 대시보드 개발.md b/10_Wiki/Topics/Business_Strategy/SaaS 플랫폼 및 인터랙티브 대시보드 개발.md new file mode 100644 index 00000000..6a68f440 --- /dev/null +++ b/10_Wiki/Topics/Business_Strategy/SaaS 플랫폼 및 인터랙티브 대시보드 개발.md @@ -0,0 +1,23 @@ +# [[SaaS 플랫폼 및 인터랙티브 대시보드 개발]] + +## 📌 Brief Summary +SaaS 플랫폼과 인터랙티브 대시보드는 실시간 데이터 업데이트, 풍부한 사용자 상호작용, 그리고 매끄러운 화면 전환이 필수적인 웹 애플리케이션입니다 [1, 2]. 이러한 시스템은 대부분 로그인 벽(Authentication wall) 뒤에서 작동하므로 검색 엔진 최적화(SEO)의 중요성이 낮아 클라이언트 사이드 렌더링(CSR)이 가장 이상적인 렌더링 방식으로 평가받습니다 [1, 3, 4]. 또한 대규모 데이터 처리와 복잡한 UI 업데이트 시 성능 병목 현상을 방지하기 위해 컴포넌트 기반 아키텍처와 동시성 렌더링(Concurrent Rendering) 같은 최적화 기술이 적극적으로 활용됩니다 [5, 6]. + +## 📖 Core Content +- **최적의 렌더링 전략 (CSR의 활용):** + SaaS 플랫폼 및 사용자 대시보드 구축 시에는 클라이언트 사이드 렌더링(CSR)이 주로 권장됩니다 [1, 2]. 대시보드 특성상 검색 엔진 인덱싱이 필요하지 않고 동적인 상호작용이 가장 중요하기 때문입니다 [1, 3]. 초기 로딩 속도는 다소 느릴 수 있으나, 브라우저에서 동적으로 라우팅과 데이터를 처리하므로 사용자가 여러 애플리케이션 섹션을 부드럽게 탐색할 수 있고 인터랙티브한 앱과 같은 경험을 제공합니다 [2, 3, 7]. 일부 프레임워크에서는 실시간 상호작용이 중요한 대시보드에는 CSR을, 그 외 문서나 블로그 페이지에는 SSG나 SSR을 사용하는 하이브리드 방식을 적용하기도 합니다 [8, 9]. + +- **데이터 집약적 대시보드의 렌더링 성능 최적화:** + - **자동 배칭(Automatic Batching):** 데이터가 많은 대시보드에서 React 18의 자동 배칭 기능을 활성화하면 여러 상태 업데이트가 단일 리렌더링으로 묶여 처리됩니다 [10, 11]. 내부 사례 연구에 따르면, 이를 통해 최대 부하 시 총 렌더링 횟수를 약 40% 줄이고 프레임 속도를 25% 향상시킬 수 있습니다 [12, 13]. + - **동시성 기능(Concurrent Features):** 대시보드에서 10,000개 이상의 대규모 데이터 리스트를 필터링하거나 차트를 다시 계산하는 등 비용이 많이 드는 작업 시 UI가 멈추는 현상을 방지해야 합니다 [5, 14]. `useTransition`이나 `useDeferredValue` 훅을 사용해 무거운 상태 업데이트를 지연시키면 메인 스레드를 차단하지 않고 UI의 즉각적인 반응성(예: 타이핑 시 입력 지연 방지)을 유지할 수 있습니다 [5, 14, 15]. + +- **컴포넌트 기반 아키텍처(CBA)의 적용:** + 인터랙티브 대시보드는 차트, 데이터 테이블, 그래프 등 독립적이고 재사용 가능한 컴포넌트들을 조합하여 구축하는 컴포넌트 기반 아키텍처가 적합합니다 [6, 16]. 이를 통해 기능별 모듈화가 이루어져 일부 기능(예: 결제 프로세서 교체, 특정 위젯 업데이트)만 안전하게 수정하거나 확장할 수 있어 유지보수와 확장이 용이해집니다 [17, 18]. + +## 🔗 Knowledge Connections +- **Related Topics:** [[Client-Side Rendering (CSR)]], [[Component-Based Architecture]], [[Automatic Batching]], [[Concurrent Rendering]] +- **Projects/Contexts:** [[데이터 집약적 대시보드 성능 최적화 사례]], [[Sanity Studio]] +- **Contradictions/Notes:** React 서버 컴포넌트(RSC) 적용과 관련하여 소스 간 시각 차이가 존재합니다. 일부 소스는 읽기 전용 데이터 디스플레이(제품 카탈로그, 단순 대시보드)에 RSC를 사용하면 클라이언트 JavaScript 번들을 40-60%까지 줄일 수 있다고 주장하지만 [19], 다른 소스에서는 빈번한 리렌더링과 로컬 상태, 직접적인 브라우저 API에 크게 의존하는 '복잡한 대시보드 및 고도의 상호작용이 필요한 인터페이스'에는 RSC가 부적합(Poor fit)하며 클라이언트 컴포넌트를 사용해야 한다고 경고합니다 [20]. + +--- +*Last updated: 2026-04-25* \ No newline at end of file diff --git a/10_Wiki/Topics/Business_Strategy/전자상거래 플랫폼 (E-commerce Platforms).md b/10_Wiki/Topics/Business_Strategy/전자상거래 플랫폼 (E-commerce Platforms).md new file mode 100644 index 00000000..18a11cd5 --- /dev/null +++ b/10_Wiki/Topics/Business_Strategy/전자상거래 플랫폼 (E-commerce Platforms).md @@ -0,0 +1,24 @@ +# [[전자상거래 플랫폼 (E-commerce Platforms)]] + +## 📌 Brief Summary +전자상거래 플랫폼은 제품 카탈로그, 재고 관리, 결제 시스템 등을 처리하기 위해 고도의 확장성과 렌더링 최적화가 요구되는 복잡한 웹 시스템입니다 [1-3]. 검색 엔진 최적화(SEO)와 빠른 페이지 로딩 속도, 그리고 장바구니와 같은 동적 상호작용 간의 균형을 맞추는 것이 핵심 목표입니다 [1, 4, 5]. 이를 달성하기 위해 현대의 전자상거래 플랫폼은 SSR, ISR, SSG와 같은 다양한 렌더링 전략과 컴포넌트 기반 아키텍처(CBA)를 적극적으로 활용합니다 [6-8]. + +## 📖 Core Content +* **전자상거래를 위한 최적의 렌더링 전략:** + * **서버 사이드 렌더링 (SSR):** 제품 목록 페이지, 카테고리 탐색 및 개별 제품 상세 뷰에 이상적입니다. 강력한 검색 엔진 가시성(SEO)을 보장하고 클라이언트 측의 처리 지연 없이 제품의 가격과 재고 등을 즉각적으로 렌더링하여 사용자 경험과 전환율을 향상시킵니다 [1]. + * **점진적 정적 재생성 (ISR):** 빠른 제품 페이지 로딩 속도를 제공하면서도 전체 사이트를 다시 빌드할 필요 없이 재고 정보 및 가격을 최신 상태로 유지할 수 있어 대규모 전자상거래 플랫폼에 완벽한 균형을 제공합니다 [4, 6, 7]. + * **정적 사이트 생성 (SSG):** 실시간 재고 변경보다는 예약된 빌드 프로세스를 통해 제품 정보가 주로 업데이트되는 안정적인 제품 카탈로그 페이지에 유리합니다 [9, 10]. + * **클라이언트 사이드 렌더링 (CSR):** 소셜 미디어나 전자상거래 웹사이트처럼 고도의 상호 작용이 필요한 애플리케이션에 부분적으로 사용됩니다 [5]. + +* **전자상거래에서의 컴포넌트 기반 아키텍처 (CBA) 활용:** + * 전자상거래 플랫폼은 제품 목록, 결제 게이트웨이, 장바구니, 고객 리뷰 모듈과 같은 개별 기능을 독립적인 컴포넌트로 구축하여 아키텍처의 모듈화와 재사용성을 극대화합니다 [2, 3]. + * 트래픽 급증 시 전체 애플리케이션이 아닌 쇼핑 카트 컴포넌트와 같은 특정 인스턴스만 추가하여 원활한 운영을 유지하는 등 뛰어난 확장성을 제공합니다 [8]. + * 마케팅 캠페인이나 시즌별 프로모션에 맞춰 기본 비즈니스 기능을 손상시키지 않고 다양한 테마를 적용하여 사이트의 디자인을 신속하게 변경할 수 있습니다 [11]. + +## 🔗 Knowledge Connections +- **Related Topics:** [[Server-Side Rendering (SSR)]], [[Incremental Static Regeneration (ISR)]], [[Component-Based Architecture (CBA)]] +- **Projects/Contexts:** [[제품 카탈로그 및 장바구니 시스템 (Product Catalogs and Shopping Carts)]] +- **Contradictions/Notes:** 소스 [5]에서는 높은 수준의 상호작용이 필요한 전자상거래 웹사이트에 CSR이 흔히 사용된다고 언급합니다. 하지만 다른 소스들은 검색 엔진 최적화(SEO)와 최신 데이터 제공의 중요성 때문에 제품 탐색 및 세부 페이지에는 SSR 또는 ISR을 사용하는 것이 훨씬 이상적이고 필수적이라고 강조합니다 [1, 4, 7]. + +--- +*Last updated: 2026-04-25* \ No newline at end of file diff --git a/10_Wiki/Topics/Frontend_Mastery/2026-04-25-Skybound_Vampire_Survivors_Loop_and_Stage_Curve_Preparation.md b/10_Wiki/Topics/Frontend_Mastery/2026-04-25-Skybound_Vampire_Survivors_Loop_and_Stage_Curve_Preparation.md new file mode 100644 index 00000000..04f297a2 --- /dev/null +++ b/10_Wiki/Topics/Frontend_Mastery/2026-04-25-Skybound_Vampire_Survivors_Loop_and_Stage_Curve_Preparation.md @@ -0,0 +1,116 @@ +# Skybound Vampire Survivors Loop and Stage Curve Preparation + +작성일: 2026-04-25 23:52 KST + +## 요청 요약 + +- Skybound가 뱀파이어 서바이벌 계열 게임처럼 느껴지도록 재미 요소와 스테이지별 레벨 구조를 준비한다. +- 단순히 적을 많이 내보내는 것이 아니라, 성장 선택, 밀도 상승, 진화 완성, 보스 체크포인트가 자연스럽게 이어지도록 만든다. + +## 핵심 방향 + +Skybound는 탑다운 생존 슈터이지만, 기존 구조는 스테이지 시간이 짧고 보스 진입이 빨라 빌드가 완성되기 전에 전투가 끊기는 문제가 있었다. 뱀서류 재미를 만들려면 다음 루프가 안정적으로 반복되어야 한다. + +1. 초반: 첫 무기 선택 후 약한 적을 많이 처치하며 빠르게 1-2회 성장한다. +2. 중반: 적 밀도와 엘리트 압박이 올라가며 광역/관통/방어 선택의 의미가 생긴다. +3. 후반: 스웜과 미니보스가 들어오며 빌드 조합과 진화 무기가 필요해진다. +4. 보스: 완성된 빌드가 제대로 작동하는지 검증한다. +5. 다음 스테이지: 같은 빌드를 이어가되 적 밀도, 패턴, 보스 기믹이 상승한다. + +## 적용한 변경 + +### 8스테이지 Survivor 프로필 추가 + +`CombatTimeline.ts`에 `SURVIVOR_STAGE_PROFILES`를 추가했다. 각 스테이지는 아래 정보를 가진다. + +- 스테이지 이름 +- 스테이지 길이 +- 기본 난이도 배율 +- 동시 적 수 기준 +- 스폰 템포 +- 오프닝 웨이브 +- 압박 엘리트 웨이브 +- 스웜 웨이브 +- 클라이맥스 엘리트 웨이브 +- 미니보스 체크포인트 + +### 스테이지별 구조 + +- Stage 1 `First Contact`: 첫 무기와 기본 생존 학습 +- Stage 2 `Fast Lanes`: 빠른 적과 이동 압박 +- Stage 3 `Ruined Circuit`: 혼합 편대와 엘리트 압박 +- Stage 4 `Crossfire Grid`: 길막/라인 클리어 압박 +- Stage 5 `Magma Forge`: 고밀도 스웜 시작 +- Stage 6 `Storm Foundry`: 빌드 완성 요구 +- Stage 7 `Arcane Collapse`: 진화 무기 권장 +- Stage 8 `Final Singularity`: 완성 빌드 검증 + +### 스테이지 시간 조정 + +기존 Standard 스테이지는 약 165초부터 시작해 빌드업 시간이 부족했다. 새 구조에서는 Stage 1이 240초, Stage 8이 420초까지 증가한다. + +이렇게 하면 플레이어는 한 스테이지 안에서 다음 리듬을 경험할 수 있다. + +- 0-25%: 세팅과 첫 성장 +- 25-48%: 엘리트 압박 +- 48-72%: 스웜 압박 +- 72%-보스 전: 클라이맥스와 미니보스 +- 마지막 35초 전후: 보스전 진입 + +### 스폰 밀도 조정 + +- 적 하드캡을 56에서 76으로 올렸다. +- 스웜 배치 단위를 6에서 8로 올렸다. +- 기본 절차 스폰 간격을 96프레임에서 84프레임으로 줄였다. + +목표는 “가만히 있어도 클리어”가 아니라, 점점 밀려오는 압박을 움직임과 빌드 선택으로 해결하게 만드는 것이다. + +### Tac EXP 커브 조정 + +바닥 EXP 젬을 다시 뿌리지는 않고, 처치 즉시 Tac EXP를 지급하는 현재 방향을 유지했다. 다만 뱀서류 성장 리듬을 만들기 위해 처치 경험치를 조정했다. + +- 일반 적: `+2 TAC` +- 엘리트 적: `+10 TAC` +- 미드보스: `+30 TAC` + +초기 요구 EXP는 `90`에서 `80`으로 낮췄다. 대신 레벨업 후 초과 EXP carryover는 25%만 유지해 연속 레벨업 폭주는 막는다. + +레벨 요구량 배율은 아래처럼 조정했다. + +- Level 1-4: `x1.34` +- Level 5-8: `x1.42` +- Level 9-14: `x1.52` +- Level 15+: `x1.62` + +## 설계 의도 + +이번 변경은 “Vampire Survivors의 재미”를 다음 요소로 해석했다. + +- 적은 점점 많아진다. +- 플레이어는 더 자주 선택하고 강해진다. +- 선택에는 빌드 방향성이 있다. +- 중반 이후에는 광역, 관통, 방어, 기동 중 최소 하나가 부족하면 압박을 느낀다. +- 보스는 단절된 엔딩이 아니라 빌드 검증 구간이다. +- 다음 스테이지는 새 게임이 아니라 이전 빌드의 확장 시험이다. + +## 수정 파일 + +- `/Volumes/Data/project/Antigravity/Skybound/src/features/game/config/CombatTimeline.ts` +- `/Volumes/Data/project/Antigravity/Skybound/src/features/game/systems/SpawnerSystem.ts` +- `/Volumes/Data/project/Antigravity/Skybound/src/features/game/systems/CombatSystem.ts` +- `/Volumes/Data/project/Antigravity/Skybound/src/features/game/systems/ProgressionSystem.ts` +- `/Volumes/Data/project/Antigravity/Skybound/src/features/game/systems/types.ts` +- `/Volumes/Data/project/Antigravity/Skybound/src/features/game/store/useGameStore.ts` + +## 검증 + +- `npm run build` 성공 +- Vite 경고: `/sprites/player.png referenced in /sprites/player.png didn't resolve at build time` +- 위 경고는 기존 런타임 경로 경고이며 이번 변경으로 인한 빌드 실패는 아니다. + +## 후속 작업 제안 + +- 각 스테이지별 고유 몬스터 역할 비중을 더 명확히 분리한다. +- 스테이지별 보스 패턴을 현재보다 더 강하게 차별화한다. +- 진화 무기별 화면 가독성과 성능을 플레이테스트로 검증한다. +- 미니보스 처치 시 보물상자/카드 선택 보상을 확정 지급하는 구조를 추가하면 뱀서류 보상감이 더 강해진다. diff --git a/10_Wiki/Topics/Frontend_Mastery/2026-04-26-Skybound_Miniboss_Treasure_Cache_Reward_Loop.md b/10_Wiki/Topics/Frontend_Mastery/2026-04-26-Skybound_Miniboss_Treasure_Cache_Reward_Loop.md new file mode 100644 index 00000000..0bc19fac --- /dev/null +++ b/10_Wiki/Topics/Frontend_Mastery/2026-04-26-Skybound_Miniboss_Treasure_Cache_Reward_Loop.md @@ -0,0 +1,109 @@ +# Skybound Miniboss Treasure Cache Reward Loop + +작성일: 2026-04-26 09:32 KST + +## 요청 요약 + +- 뱀파이어 서바이벌 계열의 재미를 더 강하게 만들기 위한 다음 단계로, 미니보스 처치 보상 루프를 추가한다. +- 단순 EXP 성장만 반복되는 구조가 아니라, 중간 강적을 잡았을 때 빌드 방향을 강화하는 확정 보상을 제공한다. +- 보상은 기존 Tac Level Up 화면을 재사용하되, 보물상자 성격의 `Emergency Supply` 카드 선택으로 연결한다. + +## 핵심 방향 + +Skybound의 현재 전투 루프는 적을 처치하면 Tac EXP를 바로 얻고, 일정 EXP에 도달하면 업그레이드를 선택하는 구조다. 이 방식은 화면 가독성에는 좋지만, 플레이 중간에 “강적을 잡아서 특별한 보상을 얻었다”는 뱀서류 특유의 보상감이 부족했다. + +이번 변경의 목표는 미니보스를 다음 역할로 재정의하는 것이다. + +1. 전투 흐름 중간의 압박 체크포인트 +2. 플레이어 빌드가 충분히 강한지 확인하는 작은 검증 구간 +3. 처치하면 현재 빌드를 더 선명하게 만드는 확정 업그레이드 보상 +4. 보스 전 진화/EVO 경로를 완성할 기회를 주는 중간 보물상자 + +## 적용한 변경 + +### 미니보스 식별 플래그 추가 + +기존 `MINI_BOSS` 스폰은 내부적으로 `ELITE` 적을 생성했기 때문에, 처치 시 일반 엘리트와 구분되는 보상 처리가 어려웠다. `SystemEnemy`에 아래 플래그를 추가했다. + +- `isMiniBoss` +- `rewardClaimed` + +`SpawnerSystem`의 `MINI_BOSS` 스폰에서는 이제 `isMiniBoss: true`를 부여한다. + +### 미니보스 HP 스케일링 + +미니보스가 후반 스테이지에서도 너무 빨리 녹지 않도록 스테이지와 난이도 배율을 반영했다. + +- 기본 HP: `620` +- 스테이지당 증가: `+22%` +- 현재 `difficultyMult` 반영 + +의도는 미니보스가 보스만큼 길지는 않지만, 플레이어가 위치와 공격 방향을 신경 써야 하는 짧은 전투 목표가 되게 하는 것이다. + +### 처치 보상 인텐트 추가 + +`EngineProtocol`에 `MINIBOSS_REWARD` 인텐트를 추가했다. `CombatSystem`은 미니보스 처치 시 직접 UI를 열지 않고, 엔진 인텐트를 통해 보상 처리를 요청한다. + +이렇게 한 이유는 다음과 같다. + +- 전투 시스템이 UI 상태를 직접 제어하지 않게 한다. +- 기존 `LEVEL_UP` 이벤트와 `LevelUpModal` 흐름을 재사용한다. +- 추후 보물상자 연출, 룰렛, 보상 티어를 추가하기 쉽다. + +### 빌드 우선 보상 카드 생성 + +`ProgressionSystem`에 `generateMiniBossRewardCards`를 추가했다. 이 보상은 일반 레벨업 카드보다 더 전략적으로 구성된다. + +우선순위는 다음과 같다. + +1. 이미 보유한 무기/스킬의 레벨업 +2. Lv.3 이상 무기의 EVO에 필요한 서포트 패시브 +3. 스웜/압박 구간 대응용 `isSpikeCounter` 스킬 +4. 부족한 자리는 기존 3카드 생성 규칙으로 보충 + +이 구조는 플레이어가 아무 카드나 고르는 것이 아니라, “내 빌드를 완성해가는 선택”을 하도록 유도한다. + +### 보상 UI 연결 + +미니보스 처치 시 아래 흐름으로 동작한다. + +1. 미니보스 사망 +2. `CombatSystem`이 `MINIBOSS_REWARD` 인텐트 발행 +3. `useGameEngine`이 현재 스킬 상태를 기반으로 보상 카드 생성 +4. 게임 일시정지 +5. `LEVEL_UP` 이벤트를 `isChest: true`로 발행 +6. 기존 `Emergency Supply` 카드 선택 UI 표시 +7. `COMMAND CACHE UNLOCKED` 피드백 텍스트 출력 + +## 설계 의도 + +이 변경은 Skybound의 목적성을 더 명확하게 만들기 위한 작업이다. + +- 일반 적 처치: Tac EXP를 쌓는 기본 성장 +- 엘리트 처치: 더 많은 EXP와 재료/장비 가능성 +- 미니보스 처치: 확정 빌드 강화 선택 +- 스테이지 보스 처치: 다음 스테이지 진행과 영구 보상 + +즉, 전투 중 목표가 “그냥 버티기”에서 “위험한 타이밍을 넘기고 빌드를 완성하기”로 바뀐다. + +## 수정 파일 + +- `/Volumes/Data/project/Antigravity/Skybound/src/features/game/hooks/useGameEngine.ts` +- `/Volumes/Data/project/Antigravity/Skybound/src/features/game/systems/CombatSystem.ts` +- `/Volumes/Data/project/Antigravity/Skybound/src/features/game/systems/EngineProtocol.ts` +- `/Volumes/Data/project/Antigravity/Skybound/src/features/game/systems/ProgressionSystem.ts` +- `/Volumes/Data/project/Antigravity/Skybound/src/features/game/systems/SpawnerSystem.ts` +- `/Volumes/Data/project/Antigravity/Skybound/src/features/game/systems/types.ts` + +## 검증 + +- `npm run build` 성공 +- Vite 경고: `/sprites/player.png referenced in /sprites/player.png didn't resolve at build time` +- 위 경고는 기존 런타임 경로 경고이며 이번 변경으로 인한 빌드 실패는 아니다. + +## 후속 작업 제안 + +- 미니보스 처치 순간에 실제 상자/코어가 열리는 0.6초 전용 연출을 추가한다. +- 보상 카드에 `EVO READY`, `BUILD CORE`, `SURVIVAL PICK` 같은 태그를 붙여 선택 이유를 더 명확하게 보여준다. +- 스테이지별 미니보스 외형과 탄막 패턴을 분리해 “이번 스테이지의 중간 위협” 정체성을 강화한다. +- 보물상자 보상을 1장 선택에서 3장 순차 오픈 또는 희귀도 보상으로 확장할지 플레이테스트 후 결정한다. diff --git a/10_Wiki/Topics/Frontend_Mastery/2026-04-26-Skybound_Reward_Card_Clarity_and_Command_Cache_UI.md b/10_Wiki/Topics/Frontend_Mastery/2026-04-26-Skybound_Reward_Card_Clarity_and_Command_Cache_UI.md new file mode 100644 index 00000000..38aedfa3 --- /dev/null +++ b/10_Wiki/Topics/Frontend_Mastery/2026-04-26-Skybound_Reward_Card_Clarity_and_Command_Cache_UI.md @@ -0,0 +1,104 @@ +# Skybound Reward Card Clarity and Command Cache UI + +작성일: 2026-04-26 09:40 KST + +## 요청 요약 + +- 미니보스 보상 루프 다음 단계로, 보상 카드가 왜 좋은 선택인지 사용자가 즉시 이해할 수 있게 개선한다. +- 미니보스 처치 보상과 위기 보급 보상을 같은 화면처럼 보이지 않게 구분한다. +- Stylized Casual Magitech 톤앤매너 안에서 보상감 있는 카드 선택 UI를 강화한다. + +## 핵심 방향 + +이전 단계에서 미니보스 처치 시 확정 업그레이드 선택 보상이 추가되었다. 하지만 카드 3장이 뜨는 것만으로는 사용자가 “왜 이 보상이 지금 내 빌드에 좋은지” 바로 이해하기 어렵다. + +이번 변경의 목표는 보상 화면을 단순 선택지가 아니라, 플레이어에게 다음 메시지를 전달하는 UI로 만드는 것이다. + +1. 이 카드는 현재 주력 빌드를 강화한다. +2. 이 카드는 EVO 진화 경로에 필요하다. +3. 이 카드는 스웜/압박 상황에서 생존에 도움이 된다. +4. 이 카드는 새로운 공격 패턴을 열어준다. + +## 적용한 변경 + +### 보상 출처 타입 추가 + +`LEVEL_UP` 이벤트에 `rewardSource`를 추가했다. + +- `STARTER` +- `LEVEL_UP` +- `POWER_SPIKE` +- `MINIBOSS` + +기존에는 `isChest`만 있어서 미니보스 보상과 위기 보급 보상이 모두 같은 `Emergency Supply`처럼 보였다. 이제 보상 출처에 따라 헤더, 문구, 카드 태그를 다르게 표시할 수 있다. + +### 미니보스 보상 헤더 차별화 + +미니보스 보상은 이제 `Emergency Supply`가 아니라 `Command Cache`로 표시된다. + +- Badge: `Cache` +- Title: `Command Cache` +- Subtitle: `Choose one build-defining reward` + +위기 보급은 기존 의도대로 `Emergency Supply`를 유지한다. + +### 카드 선택 이유 태그 추가 + +각 카드 상단에 보상 이유 태그를 추가했다. + +- `FIRST CORE`: 첫 무기 선택, 런의 시작 방향 결정 +- `CORE UPGRADE`: 현재 주력 무기 강화 +- `MODULE BOOST`: 보유 패시브/모듈 강화 +- `EVO LINK`: 현재 무기의 진화 조건을 지원 +- `EVO READY`: 진화 조건 완성 +- `SURVIVAL PICK`: 스웜/압박 구간 대응 +- `NEW WEAPON`: 새로운 공격 패턴 개방 +- `UTILITY MOD`: 기본 성능 강화 + +이 태그는 단순 라벨이 아니라, 카드가 “왜 지금 의미 있는 선택인지”를 설명하는 짧은 문장과 함께 표시된다. + +### Command Cache 연출 추가 + +보상 화면 상단에 작은 마법공학 캐시 코어를 추가했다. + +- 팝 인 애니메이션 +- 회전하는 점선 링 +- 미니보스 캐시는 청록/라임 계열 빛 +- 일반 보급은 오렌지/시안 계열 빛 + +실제 게임 시간을 더 지연시키지는 않지만, 화면이 뜨는 순간 보상 상자가 열린다는 감각을 강화한다. + +## 설계 의도 + +뱀파이어 서바이벌 계열의 재미는 단순히 레벨업을 많이 하는 것이 아니라, “내가 고른 선택 때문에 빌드가 강해지고 있다”는 확신에서 나온다. + +이번 변경은 그 확신을 UI로 보강한다. + +- 미니보스 처치: `Command Cache` +- 위기 보급: `Emergency Supply` +- 일반 레벨업: `Tactical Upgrade` +- 시작 선택: `Choose First Weapon` + +이제 각 성장 이벤트는 같은 카드 선택이라도 서로 다른 의미를 가진다. + +## 수정 파일 + +- `/Volumes/Data/project/Antigravity/Skybound/src/features/game/hooks/useGameEngine.ts` +- `/Volumes/Data/project/Antigravity/Skybound/src/features/game/systems/ProgressionSystem.ts` +- `/Volumes/Data/project/Antigravity/Skybound/src/features/game/systems/types.ts` +- `/Volumes/Data/project/Antigravity/Skybound/src/features/game/ui/GameSceneRenderer.tsx` +- `/Volumes/Data/project/Antigravity/Skybound/src/features/game/ui/LevelUpModal.tsx` +- `/Volumes/Data/project/Antigravity/Skybound/src/features/game/ui/LevelUpModal.css` + +## 검증 + +- `npm run build` 성공 +- Vite 경고: `/sprites/player.png referenced in /sprites/player.png didn't resolve at build time` +- 위 경고는 기존 런타임 경로 경고이며 이번 변경으로 인한 빌드 실패는 아니다. + +## 후속 작업 제안 + +- 스테이지별 미니보스 패턴을 분리해 `Command Cache`를 얻는 과정 자체를 더 재미있게 만든다. +- 보상 카드에 실제 EVO 결과 미리보기 아이콘을 추가한다. +- 보물상자 보상을 1장 선택에서 희귀도 기반 다중 보상으로 확장할지 플레이테스트한다. +- Command Cache가 열리는 짧은 0.5초 전용 컷인/상자 오픈 애니메이션을 Canvas 위에 추가한다. diff --git a/10_Wiki/Topics/Frontend_Mastery/CSS Modules.md b/10_Wiki/Topics/Frontend_Mastery/CSS Modules.md new file mode 100644 index 00000000..120c47a5 --- /dev/null +++ b/10_Wiki/Topics/Frontend_Mastery/CSS Modules.md @@ -0,0 +1,30 @@ +# [[CSS Modules]] + +## 📌 Brief Summary +CSS Modules는 표준 CSS 문법을 사용하면서도 빌드 단계에서 클래스명을 고유하게 변환하여 컴포넌트 단위로 스타일을 자동으로 스코핑(scoping)하는 CSS 아키텍처 접근법입니다 [1-3]. 전역 네임스페이스 충돌을 방지하기 위해 BEM과 같은 수동 규칙에 의존하는 대신, 도구를 통해 고유한 해시 클래스명을 생성함으로써 유지보수성을 극대화합니다 [4, 5]. 런타임 오버헤드가 없는 정적 CSS를 생성하므로 성능이 뛰어나며, React 및 Next.js와 같은 최신 프레임워크 환경에서 전역 오염 없이 안전하게 UI를 구축할 수 있게 해줍니다 [6-8]. + +## 📖 Core Content +* **동작 방식 및 특징:** + CSS Modules를 사용하면 개발자는 익숙한 표준 CSS 문법을 그대로 작성할 수 있습니다 [6, 9]. 작성된 CSS 파일(`.module.css`)을 JavaScript 컴포넌트에 임포트하면, 빌드 도구가 `.button`과 같은 클래스명을 `Button_button__x9KdL`과 같은 고유한 식별자로 자동 변환합니다 [3, 9]. 또한, `composes` 기능을 통해 기존 스타일을 쉽게 확장할 수 있으며 [1], Sass(SCSS)나 PostCSS와 같은 기존 CSS 도구와도 완벽하게 통합됩니다 [1, 10]. + +* **장점:** + * **완벽한 스코핑 및 충돌 방지:** 클래스명이 자동으로 컴포넌트에 스코핑되므로, 스타일이 의도치 않게 다른 곳에 영향을 미치는 전역 충돌(global namespace collision) 문제를 원천적으로 차단합니다 [5, 6, 9, 11]. + * **제로 런타임 오버헤드 (Zero Runtime Overhead):** 스타일이 빌드 타임에 처리되어 정적 CSS로 출력되므로, 런타임에 스타일을 파싱하는 CSS-in-JS 방식과 달리 브라우저 성능에 악영향을 주지 않으며 브라우저 캐싱을 최대한 활용할 수 있습니다 [6, 7, 12]. + * **기존 CSS 생태계 및 유연성 활용:** 복잡한 애니메이션, 미디어 쿼리, 가상 요소(pseudo-elements) 및 복잡한 선택자 등 CSS의 모든 기능을 제한 없이 자연스럽게 사용할 수 있습니다 [7, 9]. 특정 프레임워크에 종속되지 않습니다 [7]. + * **개발자 경험 향상:** TypeScript와 결합하여 모듈 클래스명에 대한 타이핑을 생성함으로써 오타를 빌드 타임에 잡아낼 수 있습니다 [13]. + +* **단점 및 한계:** + * **파일 전환 (Context Switching):** 스타일을 수정할 때 JavaScript/JSX 파일과 `.module.css` 파일을 번갈아 가며 작업해야 하는 번거로움이 있습니다 [7]. + * **동적 스타일링의 어려움:** CSS-in-JS와 달리 CSS와 JavaScript 간에 데이터를 공유하거나 컴포넌트 상태(Props)에 따른 동적인 스타일을 직접 부여하는 과정이 까다로우며, 이를 위해 조건부 문자열 연결(string concatenation) 작업이 필요합니다 [1, 7, 10]. + * **네이밍 피로 (Naming Fatigue):** 유틸리티 클래스를 제공하는 Tailwind CSS와 달리 개발자가 여전히 요소마다 의미 있는 클래스 이름을 고민하고 지어주어야 합니다 [14]. + +* **실무 활용 전략:** + CSS Modules는 탄탄한 CSS 역량을 갖춘 팀이나, 복잡한 애니메이션 및 세밀한 CSS 제어가 필요한 프로젝트에 가장 적합합니다 [14]. 특히 2025년 기준 Next.js App Router와 같은 React Server Components(RSC) 환경에서는 런타임 CSS-in-JS 라이브러리의 호환성 문제로 인해 Tailwind CSS나 CSS Modules를 사용하는 것이 강력히 권장됩니다 [8, 15]. 대규모 프로젝트의 실무에서는 레이아웃과 간격에는 빠르고 일관된 Tailwind CSS를 사용하고, 복잡한 커스텀 로직이나 애니메이션이 필요한 컴포넌트 스타일에는 CSS Modules를 사용하는 방식으로 두 기술의 장점을 결합한 하이브리드 아키텍처를 채택하기도 합니다 [16-18]. + +## 🔗 Knowledge Connections +- **Related Topics:** [[BEM]], [[Tailwind CSS]], [[CSS-in-JS]], [[SCSS]] +- **Projects/Contexts:** [[컴포넌트 기반 아키텍처]], [[React Server Components]], [[Next.js App Router]] +- **Contradictions/Notes:** 소스 문헌들은 BEM이 개발자의 수동적인 명명 규칙 준수에 의존해 휴먼 에러가 발생하기 쉬운 반면, CSS Modules는 빌드 도구를 통해 "자동화된 캡슐화"를 제공하여 BEM이 풀고자 했던 문제를 더 깔끔하게 해결한다고 비교합니다 [4, 5, 11, 13]. 또한, Tailwind CSS는 클래스명을 짓는 수고와 파일 전환의 피로를 없애주지만 마크업 코드가 길어지고 자의적인 값이 쌓일 수 있는 반면, CSS Modules는 깔끔한 HTML을 유지하지만 파일 전환과 네이밍 피로가 존재한다는 트레이드오프 관계를 가집니다 [7, 14, 19, 20]. + +--- +*Last updated: 2026-04-26* \ No newline at end of file diff --git a/10_Wiki/Topics/Frontend_Mastery/CSS-in-JS.md b/10_Wiki/Topics/Frontend_Mastery/CSS-in-JS.md new file mode 100644 index 00000000..ff0076f6 --- /dev/null +++ b/10_Wiki/Topics/Frontend_Mastery/CSS-in-JS.md @@ -0,0 +1,28 @@ +# [[CSS-in-JS]] + +## 📌 Brief Summary +CSS-in-JS는 JavaScript 파일 내에서 CSS를 직접 작성하여 컴포넌트 단위로 스타일을 결합하는 모던 웹 스타일링 접근 방식입니다 [1, 2]. 기존의 전통적인 CSS가 가진 글로벌 스코프(Global Scope) 문제를 해결하고, 컴포넌트의 상태(State)나 프롭스(Props)에 기반한 동적 스타일링을 가능하게 합니다 [1, 3, 4]. 대표적인 라이브러리로는 styled-components와 Emotion이 있지만, 최근 런타임 성능 오버헤드와 프레임워크 호환성 문제로 인해 빌드 타임에 CSS를 추출하는 Zero-Runtime 방식으로 진화하고 있습니다 [5-8]. + +## 📖 Core Content +- **주요 장점:** + - **스코프 고립 및 충돌 방지:** 자동으로 고유한 클래스명을 생성하여 스타일의 충돌을 막아주며, BEM과 같은 복잡한 네이밍 컨벤션 없이도 캡슐화를 달성할 수 있습니다 [9, 10]. + - **동적 스타일링 및 테마 적용:** 컴포넌트의 프롭스(Props)와 애플리케이션 상태(State)에 직접 접근하여 스타일을 생성할 수 있어, 복잡한 테마(Theming) 시스템을 매끄럽게 구현할 수 있습니다 [3, 4, 8]. + - **응집도(Co-location):** 컴포넌트의 로직과 스타일이 한 파일에 위치하므로, 유지보수성이 높고 컴포넌트를 이동하거나 삭제할 때 스타일 코드가 버려지는(orphaned CSS) 문제를 방지합니다 [3, 4, 11]. + - **개발자 경험(DX):** TypeScript 통합을 통한 타입 안정성, 자동 완성, 자동 벤더 프리픽싱(Vendor prefixing) 등을 지원하여 버그를 줄이고 개발 시간을 단축시킵니다 [12, 13]. + +- **주요 단점 및 한계:** + - **런타임 성능 오버헤드:** 브라우저 런타임에서 CSS 문자열을 파싱하고 DOM에 주입해야 하며, 프롭스 변경 시 스타일을 재계산해야 하므로 렌더링 시간이 지연됩니다 [4, 12, 14, 15]. + - **번들 크기 증가:** styled-components(약 12.7kb~30kb)나 Emotion(약 7.9kb~12kb) 등의 라이브러리 자체가 JavaScript 번들에 추가되어 초기 로딩 및 실행에 부담을 줍니다 [7, 14]. + - **React Server Components (RSC) 호환성 문제:** React의 컨텍스트(Context)에 의존하는 런타임 CSS-in-JS 라이브러리들은 서버 환경에서 구동되는 React Server Components 환경과 근본적으로 호환되지 않아, 2024~2025년 이후 현대적인 프레임워크(예: Next.js App Router) 환경에서 큰 문제로 대두되었습니다 [7, 8, 16]. + +- **미래 동향 및 해결책 (Zero-Runtime CSS-in-JS):** + - 런타임 오버헤드 및 RSC 호환성 문제를 극복하기 위해, 개발 시에는 CSS-in-JS의 문법을 사용하되 빌드 타임(Build time)에 정적인 CSS 파일로 추출하는 **Zero-Runtime** 접근법이 등장했습니다 [5, 6, 15, 16]. + - Linaria, vanilla-extract, Panda CSS 등이 대표적이며, 이들은 런타임 페널티 없이 타입 안정성과 컴포넌트 기반 스타일링의 이점을 제공하여 대규모 엔터프라이즈 시스템에서도 권장되는 방식으로 자리 잡고 있습니다 [15, 17, 18]. + +## 🔗 Knowledge Connections +- **Related Topics:** [[CSS Modules]], [[Tailwind CSS]], [[Zero-Runtime CSS-in-JS]], [[React Server Components]], [[Design Tokens]] +- **Projects/Contexts:** [[컴포넌트 기반 아키텍처]], [[Next.js App Router 프로젝트]], [[대규모 엔터프라이즈 테마 시스템]] +- **Contradictions/Notes:** 소스 문헌들은 CSS-in-JS가 강력한 동적 스타일링과 우수한 개발자 경험을 제공한다고 동의하지만 [3, 4, 8], 성능 오버헤드와 최신 React Server Components의 등장이라는 기술적 배경 변화로 인해 새로운 프로젝트에서는 런타임 기반의 CSS-in-JS(styled-components, Emotion 등)의 사용을 피하고, 대신 [[Tailwind CSS]], [[CSS Modules]], 혹은 [[vanilla-extract]] 같은 Zero-runtime 솔루션으로 마이그레이션할 것을 강력히 권장하고 있습니다 [8, 16, 19]. + +--- +*Last updated: 2026-04-26* \ No newline at end of file diff --git a/10_Wiki/Topics/Frontend_Mastery/CSSOM(CSS Object Model).md b/10_Wiki/Topics/Frontend_Mastery/CSSOM(CSS Object Model).md new file mode 100644 index 00000000..e171a627 --- /dev/null +++ b/10_Wiki/Topics/Frontend_Mastery/CSSOM(CSS Object Model).md @@ -0,0 +1,18 @@ +# [[CSSOM(CSS Object Model)]] + +## 📌 Brief Summary +CSSOM(CSS Object Model)은 웹 페이지의 DOM(Document Object Model) 요소들이 어떻게 스타일링되는지에 대한 모든 정보를 담고 있는 객체 모델입니다 [1, 2]. 브라우저가 제공받은 CSS 규칙을 파싱하여 부모, 자식, 형제 관계를 가진 노드 트리 형태로 구성합니다 [3, 4]. 완성된 CSSOM은 DOM과 결합하여 화면에 픽셀을 그리기 위한 렌더 트리(Render Tree)를 생성하는 데 필수적인 역할을 합니다 [5, 6]. + +## 📖 Core Content +- **렌더링 차단 특성 (Render-Blocking):** DOM 트리의 생성은 점진적으로 이루어지지만, CSSOM 생성은 점진적이지 않은 렌더링 차단(render-blocking) 작업입니다 [1, 2]. 브라우저는 스타일이 적용되지 않은 날 것의 HTML 콘텐츠가 화면에 번쩍이며 나타나는 현상(FOUC, Flash of Unstyled Content)을 방지하기 위해, 연결된 모든 스타일시트를 다운로드하고 처리하여 CSSOM이 완성될 때까지 페이지 렌더링을 차단합니다 [1, 2]. +- **트리 구조와 캐스케이딩 (Cascading):** CSSOM은 CSS 규칙에 따라 노드 트리를 형성하며, 하위 노드는 상위 노드의 스타일 일부를 상속받습니다(하향식 종속) [3, 7]. 이후에 파싱된 규칙이 이전 규칙을 덮어쓸 수 있는 속성이 있으므로, 브라우저는 전체 CSS가 완전히 파싱될 때까지 CSSOM을 렌더 트리 구성에 사용할 수 없습니다 [7]. CSSOM 트리에는 브라우저의 기본 사용자 에이전트(User Agent) 스타일시트 정보도 포함되어 있으며, 브라우저는 가장 일반적인 규칙부터 구체적인 규칙을 거듭 적용하여 최종 스타일을 계산합니다 [8]. +- **선택자 파싱 원리와 성능:** 브라우저는 CSS 선택자를 오른쪽에서 왼쪽으로 파싱합니다 [9]. 따라서 클래스 여러 개가 결합된 구체적인 선택자(예: `.container.navigation.item`)는 조상 관계를 확인하기 위해 DOM 트리를 거슬러 올라가야 하므로, 단순한 선택자(예: `.item`)에 비해 브라우저에 약간의 작업 부하를 더 줍니다 [9, 10]. +- **렌더 트리(Render Tree)와의 결합:** 브라우저는 화면에 표시될 요소의 레이아웃을 계산하기 위해 DOM 트리와 CSSOM 트리를 병합하여 렌더 트리를 만듭니다 [6, 11]. DOM 트리의 루트에서 시작해 눈에 보이는 각 노드를 순회하며 적절한 CSSOM 규칙을 찾아 적용합니다 [6]. 이때 화면에 시각적 영향을 주지 않는 노드나 `display: none` 스타일이 적용된 노드는 렌더 트리에서 제외됩니다 [6, 11]. + +## 🔗 Knowledge Connections +- **Related Topics:** [[DOM(Document Object Model)]], [[Render Tree]], [[Critical Rendering Path]], [[Reflow & Repaint]] +- **Projects/Contexts:** [[브라우저 렌더링 최적화(Browser Rendering Optimization)]] +- **Contradictions/Notes:** 소스에 따르면 CSSOM 구축은 중요한 렌더링 차단 과정이지만, 최신 브라우저 엔진에서 CSSOM 생성 및 스타일 계산 속도는 마이크로초 단위로 이루어질 만큼 매우 빠릅니다 [8-10]. 따라서 CSS 선택자의 구체성을 낮추는 등의 마이크로 최적화보다는, 필요 없는 CSS 규칙을 최소화하거나 논블로킹(non-blocking) 요청을 적절히 사용하는 것이 더 의미 있는 성능 개선 방법이라고 지적합니다 [8, 10, 12]. + +--- +*Last updated: 2026-04-25* \ No newline at end of file diff --git a/10_Wiki/Topics/Frontend_Mastery/Component-Based Architecture (CBA).md b/10_Wiki/Topics/Frontend_Mastery/Component-Based Architecture (CBA).md new file mode 100644 index 00000000..3c3e07ea --- /dev/null +++ b/10_Wiki/Topics/Frontend_Mastery/Component-Based Architecture (CBA).md @@ -0,0 +1,30 @@ +# [[Component-Based Architecture (CBA)]] + +## 📌 Brief Summary +컴포넌트 기반 아키텍처(Component-Based Architecture, CBA)는 독립적이고 모듈화된, 재사용 가능한 소프트웨어 컴포넌트들을 조립하여 애플리케이션을 구축하는 최신 소프트웨어 설계 패러다임입니다[1-3]. 레고 블록을 맞추듯 각 컴포넌트가 특정 기능을 수행하며, 명확히 정의된 인터페이스(API)를 통해 서로 통신합니다[2, 4]. 이 접근 방식은 소프트웨어를 처음부터 개발하는 대신 표준화된 부품을 재사용함으로써 유지보수성을 높이고 개발 속도를 앞당기며 뛰어난 확장성을 제공합니다[4-6]. + +## 📖 Core 소스 Content + +* **컴포넌트의 정의 및 핵심 특징** + 컴포넌트는 특정 기능을 캡슐화한 재사용 가능하고 독립적인 소프트웨어 단위입니다[7]. 주요 특징으로는 내부 구현과 데이터를 숨기고 필요한 인터페이스만 노출하는 **캡슐화(Encapsulation)**, 여러 언어나 플랫폼 간에도 표준 인터페이스를 통해 통신할 수 있는 **상호 운용성(Interoperability)**, 더 큰 시스템을 구성하기 위해 쉽게 플러그인 할 수 있는 **조립성(Composability)**, 그리고 기존 기능을 손상시키지 않고 교체할 수 있는 **대체 가능성(Replaceability)**이 있습니다[8-13]. + +* **컴포넌트 기반 개발의 주요 장점** + * **개발 속도 향상 및 비용 절감(Faster Time-to-Market):** 기존 컴포넌트를 재사용하여 반복적인 코딩을 방지함으로써 제품 출시를 가속화하고 개발 비용을 낮춥니다[14, 15]. + * **확장성(Scalability):** 트래픽이나 요구사항이 증가할 때 시스템 전체가 아닌 장바구니, 결제 등 특정 컴포넌트만 개별적으로 추가 및 확장할 수 있습니다[16-18]. + * **유지보수 및 병렬 개발(Maintainability & Collaboration):** 한 컴포넌트의 버그 수정이나 업데이트가 전체 시스템에 미치는 영향을 최소화합니다. 또한, 여러 팀이 서로 다른 컴포넌트(프론트엔드, 백엔드 등)를 동시에 개발할 수 있어 협업이 효율적입니다[14, 16, 18-20]. + +* **설계 원칙 및 구현 방법** + CBA 시스템을 구현할 때는 모듈성, 추상화, 그리고 역할에 따른 '관심사 분리(Separation of Concerns)'를 원칙으로 삼아야 합니다[8, 21]. 시스템의 기능 및 비기능적 요구사항을 분석한 후 도메인 주도 설계(DDD) 등의 기법을 사용해 컴포넌트 경계를 식별합니다[22, 23]. 이후 명확한 API 및 통신 프로토콜(예: REST, gRPC 등)을 설계하고, 각각 독립적으로 개발 및 유닛 테스트를 진행한 뒤, CI/CD 파이프라인을 통해 통합 및 배포를 수행합니다[24-26]. + +* **구현 시 직면하는 한계 및 과제** + * **초기 설계의 복잡성과 통합 오버헤드:** 시스템을 모듈화하고 인터페이스와 의존성을 명확히 정의하는 초기 계획 단계가 까다롭습니다[27-29]. 서로 다른 팀이 개발한 컴포넌트 간의 통신과 매끄러운 통합을 보장하는 것에도 오버헤드가 발생합니다[29, 30]. + * **성능 저하 및 의존성 관리:** 네트워크 호출이나 프로세스 간 통신 등 컴포넌트 상호작용으로 인해 성능 오버헤드와 지연(Latency)이 발생할 수 있습니다[27, 30, 31]. 또한, 다수의 컴포넌트가 다양한 버전의 라이브러리에 의존할 경우 버전 충돌 및 관리가 매우 복잡해집니다[31, 32]. + * **보안 및 과잉 엔지니어링 위험:** 각 컴포넌트의 업데이트 주기가 달라 최신화되지 않은 컴포넌트가 전체 시스템의 보안 취약점이 될 수 있으며[33], 유연성만을 추구하다 보면 시스템을 너무 잘게 쪼개어 과잉 엔지니어링(Over-engineering)으로 이어질 위험도 존재합니다[34]. + +## 🔗 Knowledge Connections +- **Related Topics:** [[Microservices Architecture]], [[Service-Oriented Architecture (SOA)]], [[Monolithic Architecture]], [[Object-Oriented Architecture]] +- **Projects/Contexts:** [[React]], [[Angular]], [[Vue.js]], [[PayPal]], [[Spotify]], [[Uber]], [[Walmart]] +- **Contradictions/Notes:** 소스에 따르면, 객체 지향 아키텍처(Object-Oriented Architecture)와 CBA는 원칙을 일부 공유하지만 차이가 있습니다. 객체 지향 아키텍처가 단일 애플리케이션 내에서 데이터와 동작을 캡슐화하는 데 중점을 둔다면, CBA는 여러 시스템 및 애플리케이션 전반에서 상호작용하고 재사용할 수 있는 독립적인 단위 생성을 강조합니다[35]. 또한 기존의 모놀리식 아키텍처(Monolithic Architecture)는 시스템 전체를 하나의 코드베이스로 묶어 확장 및 유지보수가 어렵지만, CBA는 느슨하게 결합된 모듈을 통해 독립적인 배포와 병렬 개발을 가능하게 합니다[36, 37]. + +--- +*Last updated: 2026-04-25* \ No newline at end of file diff --git a/10_Wiki/Topics/Frontend_Mastery/Component-Based Architecture.md b/10_Wiki/Topics/Frontend_Mastery/Component-Based Architecture.md new file mode 100644 index 00000000..3d0c239e --- /dev/null +++ b/10_Wiki/Topics/Frontend_Mastery/Component-Based Architecture.md @@ -0,0 +1,32 @@ +# [[Component-Based Architecture]] + +## 📌 Brief Summary +컴포넌트 기반 아키텍처(Component-Based Architecture, CBA)는 소프트웨어 시스템을 모듈화되고 독립적이며 재사용 가능한 단위인 '컴포넌트(Component)'로 나누어 구축하는 설계 방법론입니다 [1, 2]. 레고 블록을 조립하듯 각 컴포넌트를 결합하여 크고 복잡한 애플리케이션을 완성할 수 있으며, 이로 인해 개발 속도와 시스템 확장성을 크게 향상시킵니다 [3, 4]. 각 컴포넌트는 내부 로직과 상태를 캡슐화하고 명확히 정의된 인터페이스를 통해서만 상호작용하도록 설계되어, 유지보수성과 팀 간의 협업 효율을 극대화합니다 [5, 6]. + +## 📖 Core Content +- **핵심 원칙 및 특징:** + - **모듈성 및 캡슐화 (Modularity & Encapsulation):** 컴포넌트는 특정한 목적을 위해 기능과 데이터를 내부로 숨기고(캡슐화), 외부에 필요한 부분만 잘 정의된 인터페이스로 노출합니다 [5, 7]. + - **재사용성 및 독립성 (Reusability & Independence):** 한 번 개발된 컴포넌트는 수정 없이 여러 프로젝트에 재사용될 수 있으며, 전체 시스템을 파괴하지 않고 독립적으로 개발, 테스트, 배포 및 교체가 가능합니다 [8-10]. + - **상호운용성 (Interoperability):** 서로 다른 기술이나 플랫폼으로 구축된 컴포넌트라도 표준화된 인터페이스와 API를 통해 원활하게 통신하고 결합될 수 있습니다 [6, 11]. + +- **아키텍처의 주요 이점:** + - **개발 속도 향상 및 비용 절감:** 기존 컴포넌트를 재사용하여 코드를 처음부터 다시 작성하는 수고를 덜어 제품 출시 기간(Time-to-Market)을 앞당깁니다 [12, 13]. + - **확장성 및 유지보수 용이성:** 전체 시스템을 재구성할 필요 없이 트래픽이나 요구사항에 따라 특정 컴포넌트만 독립적으로 확장하거나 업그레이드할 수 있으며, 버그 수정 시 다른 시스템에 미치는 영향을 최소화합니다 [8, 14-16]. + - **병렬 개발 (Parallel Development):** 시스템이 명확하게 나뉘어 있어 여러 개발 팀이 동시에 각기 다른 컴포넌트를 분담하여 작업할 수 있습니다 [8, 17]. + +- **설계 시 당면 과제 및 단점:** + - **복잡성 및 의존성 관리:** 컴포넌트의 수가 증가할수록 컴포넌트 간의 상호작용, 호환성, 버전 관리 등 의존성을 통제하고 통합하는 것이 복잡해집니다 [18-20]. + - **성능 오버헤드:** 시스템을 지나치게 작은 컴포넌트로 나눌 경우(Over-engineering), 컴포넌트 간 통신(네트워크 호출 및 RPC 등)으로 인한 지연(Latency)과 오버헤드가 발생하여 성능을 저하시킬 수 있습니다 [18, 21, 22]. + - **보안 관리의 어려움:** 각 컴포넌트가 각기 다른 라이브러리와 업데이트 주기를 가질 경우, 제때 업데이트되지 않은 구식 컴포넌트가 전체 애플리케이션의 보안 취약점이 될 위험이 존재합니다 [23]. + +- **실제 활용 및 대안 아키텍처:** + - **활용 사례:** 사용자 로그인, 결제 게이트웨이, 쇼핑카트와 같은 모듈이 독립적으로 필요한 전자상거래 플랫폼, CRM 시스템, 모바일 앱 등에서 활발히 사용됩니다 [24, 25]. 프론트엔드 라이브러리(React, Angular, Vue.js)뿐만 아니라 백엔드 플랫폼(Java EE, .NET 등)에서도 이 방식을 채택하며, PayPal, Walmart, Spotify, Uber 등의 기업들이 이 아키텍처를 도입해 확장성을 입증했습니다 [3, 26, 27]. + - **대안 아키텍처:** 프로젝트의 규모와 팀 구조에 따라 하나의 코드베이스로 구성된 [[Monolithic Architecture]], 서비스 단위로 결합도를 낮춘 [[Microservices Architecture]], 기업 환경에 맞춘 [[Service-Oriented Architecture (SOA)]], [[Layered Architecture]] 등과 비교되거나 혼합되어 사용됩니다 [28-31]. + +## 🔗 Knowledge Connections +- **Related Topics:** [[Modularity]], [[Encapsulation]], [[Monolithic Architecture]], [[Microservices Architecture]], [[Service-Oriented Architecture (SOA)]] +- **Projects/Contexts:** [[React, Angular, Vue.js 기반 프론트엔드 UI 구축]], [[전자상거래 플랫폼 및 CRM 시스템 설계]], [[Java EE 및 .NET 엔터프라이즈 애플리케이션]] +- **Contradictions/Notes:** 컴포넌트 기반 아키텍처는 유연성과 재사용성을 극대화하지만, 모듈화를 극대화하려는 목적으로 시스템을 너무 잘게 쪼개는 것(Over-engineering)은 오히려 통합 비용과 통신 오버헤드를 발생시키고 디버깅을 어렵게 만들 수 있으므로 적절한 세분화(Granularity) 수준을 결정하는 것이 핵심입니다 [18, 22, 32]. + +--- +*Last updated: 2026-04-25* \ No newline at end of file diff --git a/10_Wiki/Topics/Frontend_Mastery/Core Web Vitals Optimization (INP, LCP 개선).md b/10_Wiki/Topics/Frontend_Mastery/Core Web Vitals Optimization (INP, LCP 개선).md new file mode 100644 index 00000000..a39e0ec0 --- /dev/null +++ b/10_Wiki/Topics/Frontend_Mastery/Core Web Vitals Optimization (INP, LCP 개선).md @@ -0,0 +1,31 @@ +# [[Core Web Vitals Optimization (INP, LCP 개선)]] + +## 📌 Brief Summary +Core Web Vitals는 구글이 웹 페이지의 검색 순위와 사용자 경험을 평가하기 위해 정의한 핵심 성능 지표입니다 [1]. 여기에는 화면의 주요 콘텐츠가 로드되는 속도를 측정하는 LCP(Largest Contentful Paint)와 페이지 세션 내내 애플리케이션이 사용자 상호작용에 얼마나 빠르게 응답하는지 측정하는 INP(Interaction to Next Paint)가 포함됩니다 [1, 2]. 이 지표들의 기준치(LCP 2.5초 미만, INP 200 밀리초 미만)를 달성하면 사용자 이탈률을 낮추고 유기적 검색(SEO) 성과를 직접적으로 높일 수 있습니다 [1-3]. + +## 📖 Core Content + +- **Largest Contentful Paint (LCP) 최적화** + LCP는 브라우저 화면의 가장 큰 콘텐츠 요소가 렌더링되는 시간을 측정하며, 이를 2.5초 미만으로 유지하는 것이 목표입니다 [1]. + - **코드 스플리팅(Code Splitting):** 기본적으로 번들러는 전체 애플리케이션을 하나의 큰 파일로 묶지만, `React.lazy()` 등을 통해 라우트 수준에서 코드를 분할하면 초기 번들 크기를 30~50%가량 줄여 LCP를 크게 개선할 수 있습니다 [4]. + - **렌더링 전략 변경:** 클라이언트 측 렌더링(CSR)은 초기 로딩이 느리다는 단점이 있습니다 [5, 6]. 따라서 서버 사이드 렌더링(SSR)이나 정적 사이트 생성(SSG)을 도입해 자바스크립트 파싱 전에 완성된 HTML을 사용자에게 즉시 제공함으로써 LCP 병목 현상을 해소할 수 있습니다 [7-9]. + - **이미지 최적화:** WebP나 AVIF 같은 현대적인 이미지 포맷을 사용하여 파일 크기를 줄이고, 화면에 보일 때만 이미지를 로드하는 `loading="lazy"` 지연 로딩을 도입해 초기 주요 리소스와의 대역폭 경쟁을 막습니다 [10, 11]. + +- **Interaction to Next Paint (INP) 최적화** + INP는 기존의 First Input Delay(FID)를 대체한 지표로, 클릭이나 키보드 입력 같은 상호작용 지연 시간을 200ms 이내로 응답하게 만드는 것이 핵심입니다 [2]. + - **동시성 렌더링(Concurrent Rendering):** React 19의 `useTransition` 및 `useDeferredValue` 훅을 통해 무거운 상태 업데이트(예: 대규모 목록 필터링)를 후순위로 미루고, 긴급한 사용자 입력(타이핑 등)을 먼저 처리하여 메인 스레드의 응답성을 유지합니다 [2, 12, 13]. + - **메모이제이션과 연산 최적화:** 부모 컴포넌트의 상태가 변할 때 발생하는 불필요한 '리렌더링 폭포(Re-render Cascade)' 현상을 막기 위해 `React.memo`, `useMemo`, `useCallback`을 활용합니다 [14-16]. 더불어 키 입력마다 발생하는 과도한 API 호출을 줄이기 위해 디바운싱(Debouncing)을 적용합니다 [17]. + - **목록 가상화(Virtualization):** 수백, 수천 개의 항목이 포함된 긴 목록을 렌더링할 때, 화면에 보이는 노드만 렌더링하는 가상화를 도입하면 레이아웃 및 페인트 작업 부하를 방지하여 상호작용 속도를 높입니다 [2, 18, 19]. + - **React Server Components (RSC):** 읽기 전용 데이터 컴포넌트를 서버에서 전적으로 실행함으로써 클라이언트의 자바스크립트 크기를 40~60% 감소시키고, 상호작용 시 브라우저 메인 스레드가 처리할 코드를 줄여 INP를 직접적으로 낮출 수 있습니다 [20]. + +- **Cumulative Layout Shift (CLS) 관리 및 성능 프로파일링** + - 시각적 안정성을 측정하는 CLS는 0.1 미만을 목표로 하며, 불필요한 DOM 노드를 줄이기 위한 React Fragment의 사용, 이미지의 명시적 크기 지정 등의 방법으로 개선합니다 [2, 21]. + - 최적화를 적용하기 전에 항상 `React DevTools Profiler`나 `Lighthouse`를 사용하여 병목을 유발하는 컴포넌트를 찾고, 프로덕션 환경의 실측 데이터를 얻기 위해 `Web Vitals` 라이브러리로 필드 데이터를 모니터링해야 합니다 [22-26]. + +## 🔗 Knowledge Connections +- **Related Topics:** [[Largest Contentful Paint (LCP)]], [[Interaction to Next Paint (INP)]], [[Concurrent Rendering]], [[Server-Side Rendering (SSR)]], [[React Server Components (RSC)]] +- **Projects/Contexts:** [[React Performance Optimization]], [[Search Engine Optimization (SEO) Strategy]] +- **Contradictions/Notes:** Lighthouse와 같은 도구로 측정한 연구실 데이터(Lab measurements)는 다양한 기기 성능과 네트워크 조건을 겪는 실제 사용자들의 경험(Field data)과 항상 일치하지는 않으므로 프로덕션 상의 Web Vitals 데이터를 함께 수집해야 합니다 [23, 24]. + +--- +*Last updated: 2026-04-25* \ No newline at end of file diff --git a/10_Wiki/Topics/Frontend_Mastery/Core Web Vitals.md b/10_Wiki/Topics/Frontend_Mastery/Core Web Vitals.md new file mode 100644 index 00000000..77590760 --- /dev/null +++ b/10_Wiki/Topics/Frontend_Mastery/Core Web Vitals.md @@ -0,0 +1,18 @@ +# [[Core Web Vitals]] + +## 📌 Brief Summary +Core Web Vitals(코어 웹 바이탈)은 웹사이트의 실제 성능과 사용자 경험을 평가하는 필수 지표로, 로딩 속도, 레이아웃의 안정성, 사용자 입력에 대한 반응 속도를 측정합니다 [1]. 핵심 지표로는 LCP(Largest Contentful Paint), CLS(Cumulative Layout Shift), INP(Interaction to Next Paint)가 있으며, 이는 구글의 검색 순위(Ranking signal)와 모바일 우선 인덱싱에 직접적인 영향을 미칩니다 [2, 3]. + +## 📖 Core Content +* **핵심 지표와 목표치**: Core Web Vitals는 크게 세 가지 주요 지표로 구성됩니다. LCP(Largest Contentful Paint)는 주요 콘텐츠의 로딩 속도를 의미하며 2.5초 미만을 유지해야 하고, CLS(Cumulative Layout Shift)는 레이아웃의 시각적 안정성을 나타내며 0.1 미만이어야 하며, INP(Interaction to Next Paint)는 사용자의 입력에 대한 반응성을 측정하여 200밀리초 미만을 목표로 최적화해야 합니다 [4]. +* **CSS 및 반응형 디자인과의 연관성**: 잘못된 이미지 크기 지정, 너비(width) 및 높이(height) 속성 누락, 최적화되지 않은 폰트 등은 모바일 환경에서 Core Web Vitals 점수 하락의 가장 흔한 원인이 됩니다 [2, 3]. 잘 구축된 반응형 레이아웃은 불필요한 레이아웃 이동(Layout shift)을 줄이고 로딩 시간을 개선하며 사용자 상호작용을 민첩하게 만듭니다 [1]. +* **성능 최적화 기법**: CLS를 방지하기 위해 컨테이너에 `aspect-ratio` 속성을 적용하거나 명시적인 너비와 높이를 지정해야 합니다 [5, 6]. LCP 향상을 위해서는 LCP 요소(주로 히어로 이미지)에 `fetchpriority="high"`를 설정하고 폴드(fold) 아래의 이미지는 지연 로딩(lazy-load) 처리하며, WebP나 AVIF 같은 압축률이 높은 차세대 포맷을 사용하는 방법이 있습니다 [5-7]. +* **SEO 및 비즈니스 영향**: 구글은 페이지 경험 신호의 일부로 Core Web Vitals를 활용하므로, 로딩이 느리고 레이아웃 이동이 잦은 비반응형 웹사이트는 검색 결과에서 성능이 저하될 수 있습니다 [3, 4]. 따라서 이 지표들을 지속적으로 모니터링하고 최적화하는 것은 2026년 현재 반응형 웹 디자인의 핵심 요구 사항입니다 [4, 8]. + +## 🔗 Knowledge Connections +- **Related Topics:** [[Responsive Web Design]], [[CSS Performance Optimization]] +- **Projects/Contexts:** [[Search Engine Optimization (SEO)]] +- **Contradictions/Notes:** 소스 전반에 걸쳐 CSS 및 반응형 디자인의 최적화가 Core Web Vitals 지표 개선으로 직결된다고 강조하고 있으며, 소스 간 상충되는 의견은 존재하지 않습니다. + +--- +*Last updated: 2026-04-26* \ No newline at end of file diff --git a/10_Wiki/Topics/Frontend_Mastery/DOM (Document Object Model).md b/10_Wiki/Topics/Frontend_Mastery/DOM (Document Object Model).md new file mode 100644 index 00000000..b531a1b5 --- /dev/null +++ b/10_Wiki/Topics/Frontend_Mastery/DOM (Document Object Model).md @@ -0,0 +1,25 @@ +# [[DOM (Document Object Model)]] + +## 📌 Brief Summary +DOM(Document Object Model)은 브라우저가 수신한 HTML 문서 데이터를 파싱하여 생성하는 페이지 구조의 계층적 트리 표현입니다 [1-3]. 브라우저는 HTML 태그의 포함 관계를 바탕으로 부모 및 자식 노드의 트리를 형성하며, `` 요소를 루트 노드로 갖습니다 [4, 5]. DOM은 페이지의 모든 콘텐츠 정보를 담고 있으며, 스타일 정보를 담은 CSSOM과 결합해 최종 화면 출력에 필요한 렌더 트리(Render Tree)를 형성하는 브라우저 렌더링 과정의 핵심 기반입니다 [6-8]. + +## 📖 Core Content +* **DOM 트리의 점진적 구축 (Incremental Construction)** + 브라우저는 네트워크를 통해 HTML 문서의 전체 데이터를 다 받기 전부터 점진적으로 DOM 트리를 구축할 수 있습니다 [1, 4]. 초기 14KB의 데이터 패킷이 수신되면 바이트를 문자로, 문자를 토큰(startTag 및 endTag 등)으로 변환한 뒤, 최종적으로 노드(Node)로 변환하여 트리를 조립합니다 [1, 4]. 이 점진적 생성 메커니즘 덕분에 네트워크 요청이 진행 중인 상태에서도 브라우저는 렌더링 준비를 시작할 수 있습니다 [9]. + +* **렌더링 파이프라인에서의 DOM과 CSSOM** + DOM은 문서의 '콘텐츠'를 표현하는 반면, CSSOM은 해당 콘텐츠의 '스타일'을 정의하는 독립적인 트리 구조입니다 [9, 10]. 이 두 모델은 브라우저에 의해 결합되어 화면에 시각적으로 출력되어야 하는 노드만을 포함하는 '렌더 트리(Render Tree)'로 합성됩니다 [6, 11, 12]. 이 과정에서 `