diff --git a/10_Wiki/Topics/Business_Strategy/SaaS 대시보드 및 이커머스 UI 개발.md b/10_Wiki/Topics/Business_Strategy/SaaS 대시보드 및 이커머스 UI 개발.md new file mode 100644 index 00000000..2bbfcfa6 --- /dev/null +++ b/10_Wiki/Topics/Business_Strategy/SaaS 대시보드 및 이커머스 UI 개발.md @@ -0,0 +1,27 @@ +# [[SaaS 대시보드 및 이커머스 UI 개발]] + +## 📌 Brief Summary +SaaS 대시보드 및 이커머스 UI 개발은 복잡한 데이터와 다양한 컴포넌트를 사용자에게 효과적으로 전달하고, 여러 기기에서 일관된 경험을 제공하기 위해 체계적인 CSS 설계와 반응형 기술이 필수적인 영역입니다. 대시보드의 위젯 배치와 이커머스의 상품 목록은 CSS Grid와 Flexbox를 활용한 모듈식 레이아웃으로 구축되며, 전역 스타일 충돌 방지 및 유지보수성을 위해 CSS Modules나 Tailwind CSS 같은 구조화된 스타일링 전략이 적용됩니다. 더불어 컴포넌트 수준의 반응성을 제공하는 컨테이너 쿼리와 시각적 피드백을 주는 최적화된 애니메이션을 통해 사용성을 극대화합니다. + +## 📖 Core Content +* **레이아웃 설계 (CSS Grid & Flexbox)** + * SaaS 대시보드의 위젯을 행과 열로 정밀하게 배치하거나 이커머스의 복잡한 이미지 갤러리 및 상품 목록을 구성할 때는 2차원 레이아웃 시스템인 CSS Grid가 이상적입니다 [1-3]. + * 반면, 내비게이션 바 정렬, 카드 내부의 콘텐츠, 혹은 중앙 정렬 등 1차원적인 흐름(행 또는 열)이 필요한 영역에서는 Flexbox를 사용하여 유연성을 확보하는 것이 바람직합니다 [3-5]. +* **컴포넌트 중심의 반응형 디자인 (컨테이너 쿼리 적용)** + * SaaS 대시보드와 같은 데이터 중심 인터페이스에서는 화면 전체 크기(뷰포트)가 아닌 부모 컨테이너의 너비에 반응하는 컨테이너 쿼리(`@container`)가 필수적입니다. 이를 통해 좁은 영역에서는 차트를 단순한 숫자 카드로 바꾸거나, 데이터 테이블을 카드 스택 형태로 유연하게 변환할 수 있습니다 [6, 7]. + * 이커머스 인터페이스는 반응형 설계 시 상품 이미지를 최우선으로 배치하고 주변 콘텐츠를 재구성합니다. 특히 모바일 환경에서는 구매 버튼(CTA)을 뷰포트 하단에 고정(fixed-position)하여 항상 접근 가능하게 만들고, 필터 및 정렬 제어 기능은 풀스크린 오버레이나 바텀 시트 패턴으로 축소하는 것이 모범 사례입니다 [8, 9]. +* **사용자 경험을 향상시키는 목적 있는 애니메이션** + * 이커머스에서는 장바구니 담기와 같은 사용자 행동을 확인시켜주는 마이크로 인터랙션(Micro-interactions)이나, 주문부터 결제까지의 진행 상태를 보여주는 애니메이션을 통해 마찰을 줄이고 신뢰감을 구축할 수 있습니다 [10, 11]. + * 대시보드에서는 포그라운드의 핵심 지표가 백그라운드 패널보다 약간 더 빠르게 움직이게 하는 계층적 모션(Layered Motion)을 사용하여 컨텍스트를 유지하면서 중요한 정보로 시선을 유도할 수 있습니다 [12]. + * 이러한 애니메이션을 구현할 때 너비, 높이, 마진 등 브라우저의 리플로우(Reflow)를 유발하는 레이아웃 속성을 애니메이션화하면 성능이 크게 저하되므로, `transform`과 `opacity` 속성을 활용해 GPU 가속을 유도하는 방식으로 최적화해야 합니다 [13-15]. +* **유지보수성을 위한 CSS 아키텍처 및 폴더 구조 전략** + * 대규모 SaaS 및 이커머스 환경에서 BEM과 같은 수동 네이밍 규칙은 인간의 실수로 인한 한계가 존재합니다 [16]. 이를 해결하기 위해 CSS Modules를 활용하여 클래스명 충돌을 원천 차단(캡슐화)하거나, 디자인 토큰이 강제되는 Tailwind CSS의 유틸리티 우선(Utility-first) 접근법을 사용해 CSS 파일 비대화를 막고 일관성을 유지해야 합니다 [17-20]. + * 규모가 커질수록 타입, 훅, 스타일 등을 한 폴더에 모아두는 것보다 비즈니스 도메인이나 기능(Feature)을 기준으로 구조를 분리하고 해당 디렉토리에 UI와 스타일을 함께 두는 기능 주도 아키텍처(Feature-Driven Architecture)가 유지보수 및 확장에 훨씬 유리합니다 [21, 22]. + +## 🔗 Knowledge Connections +- **Related Topics:** [[CSS Grid 및 Flexbox]], [[컨테이너 쿼리(Container Queries)]], [[성능 최적화(Reflow & Repaint)]], [[유지보수 가능한 CSS 아키텍처(CSS Modules & Tailwind)]] +- **Projects/Contexts:** [[데이터 중심의 SaaS 어드민 패널 및 CRM 대시보드 구축]], [[이커머스 모바일 최적화 및 상품 탐색 UX/UI 설계]] +- **Contradictions/Notes:** 실무에서는 단일 CSS 방법론에 얽매이지 않습니다. Tailwind CSS는 레이아웃과 간격 설정 시 빠른 개발 속도와 일관성을 보장하지만 HTML이 길어지는 단점이 있고, CSS Modules는 표준 CSS를 사용할 수 있지만 컨텍스트 스위칭이 발생합니다. 이에 따라 대규모 엔터프라이즈 팀은 레이아웃에는 Tailwind를 사용하고, 복잡한 애니메이션이나 정밀한 스타일 제어가 필요한 개별 컴포넌트에는 CSS Modules(또는 SCSS)를 혼합하여 사용하는 하이브리드 전략을 채택하기도 합니다 [23-26]. + +--- +*Last updated: 2026-04-26* \ 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..399f86ca --- /dev/null +++ b/10_Wiki/Topics/Business_Strategy/SaaS 대시보드 및 이커머스 레이아웃 구축.md @@ -0,0 +1,28 @@ +# [[SaaS 대시보드 및 이커머스 레이아웃 구축]] + +## 📌 Brief 시 Summary +SaaS 대시보드 및 이커머스 레이아웃 구축은 방대한 데이터와 제품 정보를 다양한 크기의 화면에서 일관되고 직관적으로 보여주기 위한 반응형 설계 과정입니다. 이를 위해 CSS Grid와 Flexbox를 결합하여 견고한 레이아웃을 구성하고, 컨테이너 쿼리(Container Queries)를 통해 컴포넌트 단위의 유연성을 확보합니다. 또한, 시각적 계층 구조를 명확히 하고 상호작용에 대한 즉각적인 피드백을 제공하기 위해 의도적인 애니메이션(Motion Design)을 전략적으로 적용하여 유지보수성과 사용자 경험(UX)을 동시에 향상시킵니다. + +## 📖 Core Content + +**1. SaaS 대시보드 레이아웃 및 스타일링 전략** +* **CSS Grid를 통한 2차원 배치:** 대시보드는 다양한 위젯과 데이터 구조를 한 화면에 배치해야 하므로, 행과 열을 동시에 정밀하게 제어할 수 있는 CSS Grid가 매우 적합합니다 [1]. +* **컨테이너 쿼리를 활용한 데이터 반응성:** 분석 대시보드나 CRM 등 데이터가 많은 인터페이스는 화면이 좁아질 때 표와 차트가 자연스럽게 축소되지 않는 문제를 겪습니다 [2]. 이를 해결하기 위해 전체 화면 너비가 아닌 '부모 컨테이너의 너비'를 기준으로 반응하는 컨테이너 쿼리를 사용합니다 [3, 4]. 좁은 너비에서는 막대 차트를 단순한 숫자 카드로 변경하거나, 데이터 테이블의 각 행을 라벨이 붙은 카드 스택으로 변환하는 방식이 최선의 구현으로 꼽힙니다 [2]. +* **애니메이션을 통한 데이터 시각화 강화:** 대시보드에서 카드와 차트를 독립적으로 움직이게 하는 계층형 모션(Layered Motion)을 적용하면, 배경 패널보다 전경의 핵심 지표를 약간 빠르게 이동시켜 중요한 정보로 사용자의 시선을 유도할 수 있습니다 [5]. 또한 애니메이션이 적용된 데이터 시각화를 통해 복잡한 정보와 변화 추이를 사용자가 빠르게 소화할 수 있도록 돕습니다 [6]. + +**2. 이커머스 레이아웃 및 UI 구축 전략** +* **모바일 중심(Mobile-First) 구조와 콘텐츠 재배치:** 선도적인 이커머스 인터페이스는 모든 중단점(Breakpoint)에서 제품 이미지를 최우선에 두고 가격, 리뷰, 옵션, CTA(콜투액션) 등의 지원 콘텐츠를 그 주위에 재배치합니다 [7]. 모바일 환경에서는 스크롤을 하더라도 항상 접근할 수 있도록 구매 버튼을 뷰포트 하단에 고정하며, 필터 및 정렬 컨트롤은 사이드바 대신 전체 화면 오버레이나 하단 시트 패턴으로 축소하여 제공합니다 [7]. +* **카드 기반 레이아웃 (Card-Based Layouts):** 제품 목록에는 카드 기반 레이아웃을 사용하는 것이 가장 신뢰할 수 있는 패턴입니다 [8]. 큰 화면에서는 여러 카드가 나란히 놓이지만, 작은 화면에서는 레이아웃이 깨지지 않고 수직으로 자연스럽게 쌓이므로 탐색이 매우 용이해집니다 [8]. +* **사용자 피드백을 위한 마이크로 인터랙션:** 장바구니에 제품을 추가할 때 짧은 애니메이션으로 장바구니 아이콘을 강조하면, 사용자의 현재 탐색 흐름을 방해하지 않으면서 작업이 완료되었음을 명확히 피드백할 수 있습니다 [9]. 주문 후 결제 등 시간이 걸리는 과정에서는 스켈레톤 스크린(Skeleton screens)과 같은 로딩 애니메이션을 배치하여 체감 대기 시간을 줄이고 시스템 상태에 대한 확신을 줍니다 [10]. + +**3. 유지보수성과 성능을 고려한 구조 설계** +* **역할에 따른 Flexbox와 Grid 분리:** 페이지의 전체적인 골격이나 뼈대(대규모 레이아웃)를 잡을 때는 CSS Grid를 사용하고, 그 내부 컴포넌트 요소들을 정렬할 때는 Flexbox를 혼합하여 사용하는 것이 효율적이고 유지보수하기 좋은 아키텍처를 만듭니다 [11, 12]. +* **애니메이션 성능 최적화:** 대시보드나 이커머스와 같이 렌더링할 컴포넌트가 많은 곳에서 너비(width), 높이(height), 여백(margin) 등 레이아웃에 영향을 주는 속성을 애니메이션화하면 값비싼 리플로우(Reflow)와 리페인트(Repaint)가 발생하여 성능이 저하됩니다 [13, 14]. 따라서 렌더링 성능을 최적화하기 위해서는 GPU 가속을 활용할 수 있는 `transform`이나 `opacity` 위주로 애니메이션을 설계해야 합니다 [14-16]. + +## 🔗 Knowledge Connections +- **Related Topics:** [[CSS Grid]], [[Flexbox]], [[컨테이너 쿼리 (Container Queries)]], [[모바일 중심 설계 (Mobile-First Design)]], [[마이크로 인터랙션 (Micro-interactions)]] +- **Projects/Contexts:** [[데이터 중심 대시보드 (Data-heavy Dashboards)]], [[반응형 이커머스 웹사이트 (Responsive E-commerce Websites)]] +- **Contradictions/Notes:** 뷰포트 기반의 일반적인 미디어 쿼리(Media Queries)는 사이드바나 영웅 영역 등 컴포넌트가 배치된 개별 컨텍스트의 가용 공간을 파악하지 못하는 근본적인 한계가 있습니다. 따라서 대시보드나 이커머스처럼 복잡하고 모듈화된 레이아웃에서는 화면 크기가 아닌 컴포넌트 부모 크기에 반응하는 컨테이너 쿼리가 2026년의 새로운 표준으로 권장됩니다 [3]. + +--- +*Last updated: 2026-04-26* \ No newline at end of file diff --git a/10_Wiki/Topics/Business_Strategy/데이터 중심의 SaaS 어드민 패널 및 CRM 대시보드 구축.md b/10_Wiki/Topics/Business_Strategy/데이터 중심의 SaaS 어드민 패널 및 CRM 대시보드 구축.md new file mode 100644 index 00000000..6a0e7189 --- /dev/null +++ b/10_Wiki/Topics/Business_Strategy/데이터 중심의 SaaS 어드민 패널 및 CRM 대시보드 구축.md @@ -0,0 +1,19 @@ +# [[데이터 중심의 SaaS 어드민 패널 및 CRM 대시보드 구축]] + +## 📌 Brief Summary +데이터 중심의 SaaS 어드민 패널 및 CRM 대시보드 구축은 다량의 데이터를 명확하게 시각화하고 동적으로 배열해야 하는 복잡한 인터페이스 설계 작업입니다 [1-3]. 표나 차트와 같은 데이터 요소는 화면 크기에 맞춰 자연스럽게 축소되지 않기 때문에 반응형 설계에 있어 가장 큰 과제로 꼽힙니다 [3]. 이를 해결하기 위해 CSS Grid를 활용한 체계적인 2차원 레이아웃 구성, 컨테이너 쿼리를 이용한 컴포넌트 단위의 유연한 반응형 처리, 그리고 정보의 이해도를 높이는 모션 디자인을 적용하여 유지보수 가능하고 확장성 있는 시스템을 구축해야 합니다 [1-4]. + +## 📖 Core Content +- **복잡한 2차원 레이아웃 설계 (CSS Grid):** 어드민 패널과 데이터 대시보드처럼 다양한 위젯을 구조화된 그리드에 배치해야 하는 경우 CSS Grid가 이상적입니다 [2]. CSS Grid는 행과 열을 동시에 제어하는 2차원 레이아웃을 지원하므로, 분석 대시보드의 주요 레이아웃 스타일(전체 페이지 구조 등)을 설정하고 콘텐츠를 동적으로 배열하는 데 탁월한 성능을 발휘합니다 [2, 5]. +- **데이터 컴포넌트의 반응형 처리 (Container Queries):** 데이터가 많은 CRM 및 분석 대시보드는 뷰포트 기반의 단순한 반응형 웹 디자인만으로는 해결하기 어려운 과제를 안고 있습니다 [3]. 표와 차트는 좁은 공간에서 자연스럽게 축소되지 않으므로, 컨테이너 쿼리(Container Queries)를 활용하여 컴포넌트 자체가 자신이 놓인 공간의 가용 너비를 인식하고 표시 방식을 스스로 결정하도록 구현하는 것이 핵심입니다 [3]. 예를 들어, 너비가 좁아질 때 복잡한 차트를 단순한 숫자 카드로 전환하거나, 모바일 환경에서 데이터 테이블을 라벨이 붙은 카드 스택으로 변환하는 패턴이 권장됩니다 [3]. +- **동적 데이터 시각화 및 애니메이션:** 데이터가 많은 인터페이스에 애니메이션이 적용된 차트와 그래프를 도입하면 정적인 데이터를 실행 가능한 인사이트(Actionable insights)로 전환할 수 있습니다 [1]. 데이터 시각화 시 적용하는 애니메이션은 사용자의 인지 부하를 줄여주고, 지표의 변화나 트렌드를 빠르게 비교하고 파악할 수 있게 도와주어 의사결정의 효율을 높입니다 [1]. +- **레이어 모션을 통한 시각적 위계 강조:** 대시보드나 제품 개요 페이지에서 배경 패널보다 전경의 핵심 지표(foreground metrics) 카드를 약간 더 빠르게 움직이게 하는 레이어 모션(Layered Motion) 기법을 적용할 수 있습니다 [4]. 이러한 계층적 애니메이션은 2차적인 요소들의 맥락을 유지하면서도 가장 중요한 핵심 정보로 사용자의 시선을 자연스럽게 유도합니다 [4]. +- **유지보수를 위한 폴더 및 컴포넌트 구조화:** 대시보드(Dashboard) 화면은 프론트엔드 폴더 구조 내에서 고유한 페이지(Pages folder)로 관리되며, 여러 재사용 가능한 컴포넌트(Components)들이 결합하여 하나의 전체 뷰를 구성하게 됩니다 [6, 7]. 애플리케이션의 규모가 커짐에 따라 유지보수성을 높이기 위해서는 UI 시각 요소와 비즈니스 로직을 명확히 분리하는 구조적 접근이 필수적입니다 [6, 8]. + +## 🔗 Knowledge Connections +- **Related Topics:** [[CSS Grid]], [[Container Queries]], [[데이터 시각화 애니메이션 (Animated Data Visualization)]], [[레이어 모션 (Layered Motion)]] +- **Projects/Contexts:** [[SaaS Dashboards]], [[데이터 테이블의 모바일 카드 스택 변환]], [[분석 대시보드 그리드 시스템]] +- **Contradictions/Notes:** 대시보드 및 CRM 구축 방법에 대하여 소스 데이터 내에 상충하는 의견이나 모순점은 발견되지 않았습니다. + +--- +*Last updated: 2026-04-26* \ No newline at end of file diff --git a/10_Wiki/Topics/Business_Strategy/이커머스 모바일 최적화 및 상품 탐색 UX-UI 설계.md b/10_Wiki/Topics/Business_Strategy/이커머스 모바일 최적화 및 상품 탐색 UX-UI 설계.md new file mode 100644 index 00000000..18ff235e --- /dev/null +++ b/10_Wiki/Topics/Business_Strategy/이커머스 모바일 최적화 및 상품 탐색 UX-UI 설계.md @@ -0,0 +1,20 @@ +# [[이커머스 모바일 최적화 및 상품 탐색 UX/UI 설계]] + +## 📌 Brief Summary +이커머스 모바일 최적화 및 상품 탐색 UX/UI 설계는 제한된 모바일 화면에서도 사용자가 상품을 쉽게 탐색하고 결제에 이를 수 있도록 유연한 레이아웃과 반응형 디자인을 적용하는 과정입니다 [1]. 모든 화면 크기에서 상품 이미지를 우선시하며, 장바구니 담기와 같은 주요 행동에 목적 있는 애니메이션 피드백을 제공하여 쇼핑 경험의 마찰을 줄이고 직관성을 높이는 것이 핵심입니다 [2], [1]. + +## 📖 Core Content +* **모바일 친화적인 상품 탐색 및 UI 재배치**: 선도적인 이커머스 인터페이스는 모든 브레이크포인트에서 상품 이미지를 최우선으로 배치하고, 가격이나 리뷰, 구매 옵션 등의 보조 콘텐츠를 그 주위에 재구성합니다 [1]. 특히 모바일 환경에서는 스크롤 위치와 상관없이 항상 접근할 수 있도록 '구매(Buy)' 버튼을 뷰포트 하단에 고정(fixed) 시키는 방식을 활용합니다 [1]. 또한, 필터나 정렬 컨트롤은 좁은 화면의 사이드바 대신 모바일에 적합한 전체 화면 오버레이(full-screen overlay) 형태로 제공하여 탐색의 편의성을 높입니다 [1]. +* **유연한 그리드와 컨테이너 쿼리(Container Queries) 활용**: 이커머스 사이트의 상품 그리드나 대시보드와 같이 복잡한 페이지에서는 '컨테이너 쿼리'를 활용하는 것이 효과적입니다 [3]. 이를 통해 전체 화면 크기가 아닌 개별 컴포넌트가 배치된 부모 컨테이너의 가용 공간에 따라 상품 카드의 레이아웃이 지능적으로 반응하게 만들 수 있습니다 [3]. 또한 CSS Grid의 `auto-fit`과 `minmax()` 속성을 결합하면 수동으로 브레이크포인트를 설정하지 않아도 상품 리스트가 화면 공간에 맞춰 자동으로 열을 확장하거나 축소하도록 구성할 수 있습니다 [4]. +* **터치 상호작용 및 접근성 최적화**: 모바일 기기에서의 원활한 쇼핑을 위해 버튼, 링크, 메뉴 등의 모든 터치 타겟은 최소 44x44px(Apple 권장) 또는 48x48px(Google 권장) 크기를 확보해야 합니다 [5], [6]. 패딩을 통해 시각적 요소의 크기를 키우지 않고도 클릭 가능한 영역을 넓힐 수 있으며, 인접한 터치 타겟 사이에는 충분한 간격을 두어 잘못된 탭으로 인한 사용자 스트레스를 방지해야 합니다 [5]. +* **쇼핑 경험을 돕는 마이크로 인터랙션과 애니메이션 피드백**: + * **장바구니 담기**: 사용자가 장바구니에 상품을 추가할 때, 사용자의 현재 탐색 흐름을 끊지 않으면서도 장바구니 아이콘을 짧게 애니메이션으로 강조하면 성공적으로 작업이 수행되었음을 확실히 알릴 수 있습니다 [2]. + * **결제 및 진행 상태**: 사용자가 주문을 완료하고 결제를 진행하는 동안, 스켈레톤 스크린(skeleton screens)이나 진행률 표시 애니메이션을 제공하면 체감 대기 시간을 줄이고 시스템이 정상적으로 로딩 중이라는 확신을 줄 수 있습니다 [7]. + +## 🔗 Knowledge Connections +- **Related Topics:** [[반응형 웹 디자인(Responsive Web Design)]], [[컨테이너 쿼리(Container Queries)]], [[CSS Grid와 Flexbox]], [[마이크로 인터랙션(Micro-interactions)]] +- **Projects/Contexts:** [[이커머스 컴포넌트 기반 레이아웃 설계]], [[모바일 퍼스트(Mobile-First) UI 개발]] +- **Contradictions/Notes:** 소스에 따르면, 이커머스 모바일 최적화는 단순히 데스크톱 화면의 크기를 줄이는 방식이 아닙니다. 데스크톱용 화면을 억지로 축소하면 텍스트가 너무 작아지고 요소들이 답답하게 배치되므로, 처음부터 가장 작은 모바일 화면을 기준으로 필수 요소를 우선 배치(모바일 퍼스트)하는 접근법을 강력히 권장합니다 [8]. 또한 애니메이션은 시각적 장식이 아닌 시스템 상태 전달 등 명확한 목적(기능)을 가질 때만 유효하며, 과도한 애니메이션은 피해야 합니다 [9], [10]. + +--- +*Last updated: 2026-04-26* \ No newline at end of file diff --git a/10_Wiki/Topics/Frontend_Mastery/2026-04-26-Skybound_Stage_Miniboss_Pattern_Differentiation.md b/10_Wiki/Topics/Frontend_Mastery/2026-04-26-Skybound_Stage_Miniboss_Pattern_Differentiation.md new file mode 100644 index 00000000..b8531f41 --- /dev/null +++ b/10_Wiki/Topics/Frontend_Mastery/2026-04-26-Skybound_Stage_Miniboss_Pattern_Differentiation.md @@ -0,0 +1,115 @@ +# Skybound Stage Miniboss Pattern Differentiation + +작성일: 2026-04-26 09:44 KST + +## 요청 요약 + +- 미니보스 보상 루프 다음 단계로, 8개 스테이지마다 미니보스 전투 패턴을 다르게 만든다. +- `Command Cache`를 얻는 과정 자체가 작은 보스전처럼 느껴지게 한다. +- 스테이지가 올라갈수록 압박 방식이 달라져 반복감을 줄이고, 플레이어가 이동/회피/빌드 선택을 더 의식하게 만든다. + +## 핵심 방향 + +기존 미니보스는 내부적으로 `ELITE + COMMANDER`에 가까웠고, 일반 적 사격 규칙을 타고 있었다. 그래서 미니보스를 처치하면 보상은 의미 있어졌지만, 전투 자체는 “체력이 많은 엘리트”처럼 느껴질 위험이 있었다. + +이번 변경은 미니보스를 아래 역할로 재정의한다. + +1. 각 스테이지 중반의 작은 실력 체크 +2. 스테이지 기믹을 미리 보여주는 압박 패턴 +3. `Command Cache` 보상을 얻기 위한 전투 목표 +4. 보스전 전 빌드가 충분한지 검증하는 중간 관문 + +## 적용한 변경 + +### 미니보스 패턴 타입 추가 + +`SystemEnemy`에 미니보스 전용 패턴 상태를 추가했다. + +- `miniBossPattern` +- `miniBossTimer` +- `miniBossCooldown` +- `miniBossDashFrames` +- `miniBossActionSeed` +- `dashTargetX` +- `dashTargetY` + +일반 적 AI에는 영향을 주지 않고, `isMiniBoss`가 true인 적만 전용 이동/사격 로직을 사용한다. + +### 스테이지별 패턴 매핑 + +`SpawnerSystem`에서 현재 스테이지에 따라 미니보스 패턴을 자동 부여한다. + +- Stage 1: `DUELIST` +- Stage 2: `DASH_RAIDER` +- Stage 3: `DRONE_CALLER` +- Stage 4: `BARRAGE_WALL` +- Stage 5: `MINE_LAYER` +- Stage 6: `DRONE_RING` +- Stage 7: `BLINK_SNIPER` +- Stage 8: `OMEGA_COMMANDER` + +### 전용 이동 AI 추가 + +`CombatSystem`에서 미니보스는 기존 `role` 기반 AI 대신 `updateMiniBossAI`를 탄다. + +패턴별 이동/행동은 다음과 같다. + +- `DUELIST`: 플레이어 x축을 따라가며 기본 팬샷 압박 +- `DASH_RAIDER`: 짧은 예고 후 플레이어 방향으로 돌진 +- `DRONE_CALLER`: 좌우에 스팅어 호위기를 주기적으로 소환 +- `BARRAGE_WALL`: 화면 가로 라인을 오가며 안전 구멍이 있는 탄막벽 생성 +- `MINE_LAYER`: 플레이어 근처에 위험 구름/지뢰형 압박 구역 생성 +- `DRONE_RING`: 헌터 호위기와 링 탄막으로 공간 압박 +- `BLINK_SNIPER`: 위치를 순간이동하며 빠른 저격 탄을 발사 +- `OMEGA_COMMANDER`: 팬샷, 링 탄막, 지뢰, 블링크를 순환하는 최종형 미니보스 + +### 전용 사격 패턴 추가 + +`spawnMiniBossBulletPattern`을 추가해 미니보스 사격을 일반 적과 분리했다. + +- 팬샷 +- 빠른 저격탄 +- 링 탄막 +- 안전 구멍이 있는 라인 탄막 +- 느린 중력/지뢰형 탄 +- 최종 스테이지 혼합 패턴 + +스테이지가 올라가면 탄 수와 쿨다운이 자연스럽게 강해진다. + +## 설계 의도 + +이번 변경은 “보상을 얻는 과정”을 재미있게 만들기 위한 작업이다. + +이전 구조: + +- 미니보스 등장 +- 체력이 많은 적을 처치 +- 보상 선택 + +변경 후 구조: + +- 스테이지별 다른 압박을 가진 미니보스 등장 +- 사용자는 이동/회피/빌드 강점을 이용해 작은 보스전을 해결 +- 처치하면 `Command Cache`를 열고 빌드를 강화 +- 다음 구간을 버틸 준비가 된다 + +이렇게 하면 미니보스가 단순 보상 트리거가 아니라, 스테이지 리듬의 핵심 이벤트가 된다. + +## 수정 파일 + +- `/Volumes/Data/project/Antigravity/Skybound/src/features/game/systems/CombatSystem.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` +- 위 경고는 기존 런타임 경로 경고이며 이번 변경으로 인한 빌드 실패는 아니다. + +## 후속 작업 제안 + +- 실제 플레이에서 Stage 4 `BARRAGE_WALL`과 Stage 7 `BLINK_SNIPER`의 탄속/쿨다운을 체감 기준으로 조정한다. +- 미니보스 등장 시 패턴 이름을 더 상품성 있는 경고 문구로 표시한다. +- 미니보스별 외형 색상, 엔진 이펙트, 코어 형태를 패턴에 맞게 분리한다. +- `Command Cache` 오픈 전 0.5초 컷인 연출을 추가해 전투 승리 보상감을 더 강화한다. diff --git a/10_Wiki/Topics/Frontend_Mastery/BEM (Block Element Modifier).md b/10_Wiki/Topics/Frontend_Mastery/BEM (Block Element Modifier).md new file mode 100644 index 00000000..c6bcd6ff --- /dev/null +++ b/10_Wiki/Topics/Frontend_Mastery/BEM (Block Element Modifier).md @@ -0,0 +1,32 @@ +# [[BEM (Block Element Modifier)]] + +## 📌 Brief Summary +BEM(Block Element Modifier)은 모듈식이고 재사용 가능하며 충돌 없는 UI 컴포넌트를 구축하기 위해 고안된 검증된 CSS 아키텍처 방법론이다 [1]. 깊게 중첩된 선택자 대신 평면적이고 명시적이며 스스로를 설명할 수 있는 클래스 명명 규칙을 도입하여 CSS를 구조화한다 [2, 3]. 이를 통해 대규모 프론트엔드 프로젝트에서 전역 네임스페이스 충돌을 방지하고 CSS의 예측 가능성과 유지보수성을 높이는 것을 핵심 목적으로 한다 [4, 5]. + +## 📖 Core Content +* **BEM의 구조 및 명명 규칙:** + * BEM은 독립적으로 의미를 가지는 재사용 가능한 UI 컴포넌트인 '블록(Block)', 블록에 종속되어 독립적으로 존재할 수 없는 하위 요소인 '엘리먼트(Element)', 그리고 모양이나 상태의 변화를 나타내는 '모디파이어(Modifier)'로 구성된다 [3, 6, 7]. + * 엘리먼트는 이중 밑줄(`__`)로 구분하고(예: `card__title`), 모디파이어는 이중 하이픈(`--`)으로 구분한다(예: `button--primary`) [6-8]. + +* **BEM의 장점 및 유지보수성 기여:** + * 낮은 결합도(Low Coupling)와 높은 응집도(High Cohesion)를 촉진하여 컴포넌트를 격리하고, 스타일이 깊은 DOM 중첩에 의존하지 않게 만든다 [5, 9]. + * 평면적인(flat) 선택자 계층 구조를 생성하여 브라우저 CSS 엔진의 광범위한 트리 탐색을 방지하므로 렌더링 성능에 유리하다 [9, 10]. + * 클래스 이름 자체가 문서 역할을 하여(Self-documenting) 새로운 개발자도 해당 클래스가 어느 컴포넌트의 어떤 변형인지 즉시 파악할 수 있으므로 팀 협업과 안전한 리팩토링을 돕는다 [9, 11, 12]. + +* **한계 및 단점:** + * 가장 큰 취약점은 규율 준수를 전적으로 '사람의 강제(human enforcement)'에 의존한다는 점이다 [5, 13, 14]. + * 개발자의 실수로 명명 규칙이 위반되거나 전역 스코프에서 블록 이름이 충돌할 위험이 존재한다 [13, 15]. + * 클래스 이름이 길고 장황해질 수 있으며(verbosity), 사용하지 않는 데드 코드(dead code)를 빌드 파이프라인에서 자동으로 식별하고 제거하기 어렵다 [12-14]. + +* **실무 활용 및 현대적 대안과의 비교:** + * 장황한 클래스명 작성의 불편함은 Sass나 Less 같은 CSS 전처리기의 중첩(nesting) 기능을 활용하여 완화할 수 있다 [16, 17]. + * 최근의 React 등 컴포넌트 기반 환경에서는 BEM이 해결하려 했던 전역 CSS 충돌 문제를 자동으로 해결해주는 CSS Modules가 선호되는 경향이 있다 [18, 19]. + * 그러나 공유 유틸리티, 전역 디자인 시스템, 혹은 컴포넌트 라이브러리에서 테마를 덮어써야 하는 화이트라벨(whitelabel) 앱 환경 등에서는 BEM의 명시적 구조가 여전히 매우 유용하게 사용된다 [19-21]. + +## 🔗 Knowledge Connections +- **Related Topics:** [[CSS Modules]], [[Tailwind CSS]], [[CSS-in-JS]], [[CSS Architecture]] +- **Projects/Contexts:** [[대규모 프론트엔드 프로젝트 유지보수]], [[컴포넌트 기반 UI 설계]], [[디자인 시스템 구축]] +- **Contradictions/Notes:** BEM은 명시적이고 예측 가능한 스타일링을 제공하여 유지보수성을 극대화하지만 [1, 9], 인간의 수동 관리에 의존해야 한다는 명확한 한계가 존재한다 [5, 14]. 이로 인해 오늘날의 실무에서는 빌드 단계에서 자동으로 고유 클래스명을 보장하는 CSS Modules나, 유틸리티 클래스 기반으로 재사용성을 높인 Tailwind CSS와 종종 비교되거나 상호 보완적으로 사용된다 [8, 21-23]. + +--- +*Last updated: 2026-04-26* \ No newline at end of file diff --git a/10_Wiki/Topics/Frontend_Mastery/BEM.md b/10_Wiki/Topics/Frontend_Mastery/BEM.md new file mode 100644 index 00000000..7e4eea64 --- /dev/null +++ b/10_Wiki/Topics/Frontend_Mastery/BEM.md @@ -0,0 +1,28 @@ +# [[BEM]] + +## 📌 Brief Summary +BEM(Block Element Modifier)은 모듈화되고 재사용 가능하며 충돌이 없는 UI 컴포넌트를 구축하기 위해 고안된 CSS 아키텍처 및 네이밍 규칙론입니다 [1]. 클래스 이름을 블록(Block), 요소(Element), 상태/변형(Modifier)이라는 세 가지 구성 요소로 명확히 나누어 작성함으로써 CSS의 전역 스코프(Global Scope)로 인해 발생하는 복잡성과 이름 충돌 문제를 방지합니다 [2-4]. 이를 통해 대규모 프론트엔드 프로젝트에서도 CSS를 예측 가능하고 유지보수하기 쉽게 관리할 수 있도록 돕습니다 [5]. + +## 📖 Core Content +- **BEM의 핵심 구성 요소:** + - **Block (블록):** `card`, `button`, `navigation` 등과 같이 스스로 의미를 가지며 독립적으로 재사용 가능한 UI 컴포넌트 단위입니다 [3]. 주변 DOM 구조에 의존하지 않고 기능해야 합니다 [3]. + - **Element (요소):** 블록에 종속된 하위 구성 요소로, 독립적으로 존재할 수 없습니다 [6]. 이중 밑줄(`__`)을 사용하여 표기합니다(예: `card__title`, `card__image`) [6]. + - **Modifier (모디파이어):** 블록이나 요소의 상태, 외관, 동작의 변화를 나타냅니다 [7]. 이중 하이픈(`--`)으로 표기합니다(예: `card--highlighted`, `button--disabled`) [7]. + +- **아키텍처적 이점:** + - **유지보수성과 예측 가능성:** 예기치 않은 스타일 덮어쓰기와 선택자 명시도(specificity) 충돌 문제를 방지하여 소위 '스파게티 스타일'이 되는 것을 막습니다 [2, 8]. + - **평면적인 선택자(Flat Selectors):** 깊이 중첩된 선택자를 사용하지 않고 평면적이고 고유한 클래스명을 만들어내므로, 브라우저의 렌더링 성능이 향상되고 코드를 쉽게 읽을 수 있습니다 [9, 10]. + - **협업 및 리팩토링 용이성:** 클래스 이름이 그 자체로 문서화(Self-documenting) 역할을 하여, 새로운 개발자가 컴포넌트의 경계를 즉시 파악할 수 있습니다 [11, 12]. 또한, 길고 고유한 네이밍 패턴 덕분에 'Ctrl+H(찾기/바꾸기)'와 같은 텍스트 교체 기능으로 리팩토링하기 매우 쉽습니다 [13]. + +- **실무 설계 원칙 및 한계점:** + - **가이드라인:** 과도하게 깊은 요소 체인(예: `block__elem1__elem2`)을 만드는 것을 지양해야 하며, 부모 선택자에 의존하는 문맥 의존적 스타일링(Context-Dependent Styling)은 피해야 합니다 [14, 15]. + - **장황함(Verbosity) 극복:** BEM의 주된 비판 중 하나는 클래스 이름이 길고 장황해진다는 점입니다 [12]. 하지만 SCSS나 Less 같은 CSS 전처리기를 사용하면 부모 참조(`&`)와 중첩(Nesting) 기능을 통해 BEM을 훨씬 효율적이고 깔끔하게 작성할 수 있습니다 [16, 17]. + - **휴먼 에러의 한계:** BEM은 개발자의 자발적인 규칙 준수에 의존하는 '수동적인' 보장 방식입니다 [18, 19]. 따라서 프로젝트가 커지고 시간이 지날수록 규칙이 깨지거나 이름이 충돌할 위험성을 완전히 배제할 수는 없습니다 [18, 20]. + +## 🔗 Knowledge Connections +- **Related Topics:** [[CSS Modules]], [[Tailwind CSS]], [[SCSS]], [[CSS Architecture]] +- **Projects/Contexts:** [[디자인 시스템 개념]], [[컴포넌트 기반 아키텍처 (React, Vue 등)]], [[Feature-Sliced Design (FSD)]] +- **Contradictions/Notes:** 소스 문헌들에서는 BEM과 CSS Modules의 근본적인 접근 방식을 비교하고 있습니다. BEM은 고유한 네이밍 패턴을 '수동으로' 작성하여 충돌을 막으려는 시도인 반면, CSS Modules는 빌드 시점에 해시된 고유 식별자를 생성해 스코프 제한을 '자동으로' 해결합니다 [19, 21]. 이러한 이유로 현대의 React/TypeScript 기반 생태계에서는 BEM의 원래 목적이 CSS Modules로 대체될 수 있어 CSS Modules가 더 자연스럽다는 주장이 있습니다 [22, 23]. 그러나 여전히 글로벌 디자인 시스템의 토큰 및 유틸리티 구성이나 리팩토링 관점에서는 BEM이 유용하다는 시각도 공존합니다 [13, 24]. + +--- +*Last updated: 2026-04-26* \ No newline at end of file diff --git a/10_Wiki/Topics/Frontend_Mastery/CSS Architecture.md b/10_Wiki/Topics/Frontend_Mastery/CSS Architecture.md new file mode 100644 index 00000000..5f470295 --- /dev/null +++ b/10_Wiki/Topics/Frontend_Mastery/CSS Architecture.md @@ -0,0 +1,26 @@ +# [[CSS Architecture]] + +## 📌 Brief Summary +CSS 아키텍처는 과거의 단순한 시각적 장식 계층에서 벗어나, 대규모 프론트엔드 프로젝트의 확장성과 유지보수성을 보장하기 위한 엄격한 엔지니어링 시스템입니다 [1]. 애플리케이션이 복잡해짐에 따라 흔히 발생하는 전역(Global) 네임스페이스 충돌과 'CSS 비대화(Bloat)' 같은 기술적 부채를 방지하는 것을 핵심 목적으로 합니다 [1, 2]. 현대의 CSS 설계는 BEM과 같은 수동적인 네이밍 규칙에서 출발하여, CSS Modules, Tailwind CSS와 같이 스코프(Scope)를 격리하고 모듈화를 강제하는 자동화 및 유틸리티 기반 접근법으로 진화했습니다 [3-5]. + +## 📖 Core Content +현대의 프론트엔드 개발에서 CSS 설계는 "예쁘게" 만드는 것을 넘어, 여러 팀이 협업하고 프로젝트가 커져도 안정적으로 코드를 유지보수할 수 있는 구조를 구축하는 데 중점을 둡니다 [1, 2]. 이를 달성하기 위해 실무에서는 다음과 같은 구조 설계 방식과 전략을 활용합니다. + +* **BEM (Block Element Modifier) 구조:** + BEM은 UI를 독립적이고 재사용 가능한 '블록(Block)', 블록에 종속된 '요소(Element)', 그리고 상태나 모양을 변경하는 '수식어(Modifier)'로 나누어 명명하는 CSS 방법론입니다 [3, 6-8]. 선택자를 평면적(Flat)으로 유지하여 깊은 DOM 중첩으로 인한 성능 저하를 막고, 스타일이 어느 컴포넌트에 속하는지 명확하게 알려줍니다 [9, 10]. 하지만 규칙을 사람이 직접 지켜야 하므로 프로젝트가 커질수록 실수가 발생하기 쉽고, 사용하지 않는 코드를 자동으로 제거(Dead code elimination)하기 어렵다는 단점이 있습니다 [11]. +* **CSS Modules를 통한 자동화된 캡슐화:** + CSS Modules는 일반적인 CSS(또는 SCSS) 문법을 작성하되, 빌드 시점에 고유한 해시값이 포함된 클래스 이름을 자동으로 생성하여 로컬 스코프(Local Scoping)를 보장하는 방식입니다 [12-14]. BEM이 가진 수동 네이밍의 한계를 해결하고 컴포넌트 간 스타일 충돌을 원천 차단하므로, 복잡한 애니메이션이나 세밀한 CSS 제어가 필요한 프로젝트에서 선호됩니다 [15-17]. +* **Tailwind CSS와 유틸리티 우선(Utility-First) 전략:** + Tailwind는 `flex`, `pt-4`, `text-gray-500`과 같은 단일 목적의 작은 유틸리티 클래스를 HTML이나 JSX에 직접 조합하여 UI를 구성합니다 [18, 19]. 설정 파일에 디자인 토큰을 정의해두기 때문에 임의의 색상이나 간격이 무분별하게 늘어나는 것을 막아 시각적 일관성을 유지할 수 있습니다 [18, 20]. 사용된 클래스만 최종 빌드에 포함되므로 대규모 프로젝트에서도 CSS 파일의 크기가 일정 수준에서 더 이상 늘어나지 않는다는 강력한 이점이 있습니다 [18, 19]. +* **실무에서의 CSS 관리 및 아키텍처 통합 전략:** + 최근의 엔터프라이즈 팀들은 단일 기술에 얽매이지 않고, 레이아웃과 간격 배치 등 속도와 일관성이 중요한 부분에는 Tailwind CSS를 사용하고, 고도로 복잡한 컴포넌트 스타일링에는 CSS Modules나 SCSS를 결합하는 하이브리드 접근법을 취하기도 합니다 [21-23]. 또한, 폰트 크기나 색상 등을 플랫폼에 종속되지 않는 '디자인 토큰(Design Tokens)'으로 추상화하여 관리함으로써 디자인 시스템과 CSS 아키텍처를 하나로 통합합니다 [24, 25]. + +## 🔗 Knowledge Connections +- **Related Topics:** [[BEM (Block Element Modifier)]], [[CSS Modules]], [[Tailwind CSS]], [[Design Tokens]], [[Feature-Sliced Design (FSD)]] +- **Projects/Contexts:** [[대규모 엔터프라이즈 프론트엔드 프로젝트]], [[컴포넌트 기반 아키텍처 (React, Next.js)]], [[디자인 시스템 구축]] +- **Contradictions/Notes:** + - CSS 설계에서 BEM은 이름 충돌을 방지하는 훌륭한 수단으로 소개되지만 [3], 최근 모던 프론트엔드 생태계에서는 CSS Modules가 클래스 이름의 격리를 자동으로 해결해주기 때문에 BEM의 수동적인 네이밍 컨벤션은 더 이상 필수적이지 않다는 시각이 존재합니다 [17, 26, 27]. + - Tailwind CSS는 빠른 개발 속도와 일관된 디자인 시스템을 장점으로 내세우지만 [19], 동시에 HTML 마크업이 지나치게 길어지며 과거의 '인라인 스타일(Inline CSS)'로 퇴보하는 것 같아 추상화 방식에 동의하지 않는다는 개발자들의 비판적인 의견도 분명하게 대립하고 있습니다 [20, 28, 29]. + +--- +*Last updated: 2026-04-26* \ No newline at end of file diff --git a/10_Wiki/Topics/Frontend_Mastery/CSS Container Queries.md b/10_Wiki/Topics/Frontend_Mastery/CSS Container Queries.md new file mode 100644 index 00000000..b1b90772 --- /dev/null +++ b/10_Wiki/Topics/Frontend_Mastery/CSS Container Queries.md @@ -0,0 +1,25 @@ +# [[CSS Container Queries]] + +## 📌 Brief Summary +CSS Container Queries(컨테이너 쿼리)는 전체 뷰포트(브라우저 창)의 크기가 아닌, 컴포넌트가 속한 부모 컨테이너의 가용 공간을 기준으로 스타일과 레이아웃을 조정하는 강력한 CSS 기능입니다 [1-3]. 이는 좁은 사이드바에 위치한 카드와 넓은 메인 화면에 위치한 카드가 동일한 뷰포트 너비 환경에서도 각기 다른 형태를 가져야 하는 기존 미디어 쿼리(Media Queries)의 근본적인 한계를 해결해 줍니다 [1, 4]. 결과적으로 웹 디자인의 패러다임을 페이지 수준에서 컴포넌트 수준으로 전환시키며, 2026년 기준 모듈식 반응형 디자인 및 디자인 시스템 구축을 위한 필수적인 표준 기술로 자리 잡았습니다 [1, 5, 6]. + +## 📖 Core Content +* **작동 원리 및 문법 적용** + 컨테이너 쿼리를 사용하려면 부모 컨테이너에 `container-type: inline-size;` 속성을 선언하여 컨텍스트를 활성화해야 합니다 [4, 7]. 이후 `@container (min-width: 600px)`와 같은 문법을 작성하면, 전체 화면의 크기와 상관없이 해당 컨테이너가 지정된 임계값에 도달했을 때 자식 요소의 스타일(예: 1열에서 2열 레이아웃으로 변경)이 적용됩니다 [2, 7]. + +* **가변 타이포그래피(Fluid Typography)와의 결합** + 컨테이너 쿼리는 크기 기반 레이아웃뿐만 아니라 텍스트 크기 조정에도 활용됩니다. `cqw`나 `cqi`와 같은 전용 단위(컨테이너 인라인 너비의 1%를 의미)를 `clamp()` 함수 등과 함께 사용하면, 뷰포트가 아닌 컨테이너 크기에 반응하여 유동적으로 조절되는 가변 타이포그래피를 구현할 수 있습니다 [8-10]. + +* **모듈식 아키텍처 및 유지보수성 극대화** + 컨테이너 쿼리를 도입하면 개별 컴포넌트가 자신이 배치된 환경(Context)을 자체적으로 인지하고 구조를 조정하는 완전한 자립형(Self-contained) 모듈이 됩니다 [1, 4]. 따라서 동일한 컴포넌트를 애플리케이션의 어느 위치에 재사용하더라도 깨짐 없이 일관되게 동작하며, 이는 독립적인 UI 단위 구성을 지향하는 현대의 디자인 시스템(Design Systems) 철학과 완벽하게 부합합니다 [1, 4, 11, 12]. + +* **실무 활용 및 2026년 표준 관행** + 과거에는 실험적인 고급 기술이었으나 2024년 이후 모든 최신 브라우저에서 온전히 지원되며 프로덕션 환경에서 안전하게 사용할 수 있습니다 [1]. 2026년 현재, 이커머스의 다중 패널 레이아웃이나 공간 제약이 많은 SaaS 대시보드에서 데이터 테이블을 카드 스택으로 유연하게 변환하는 등, 자바스크립트에 의존하지 않고도 컴포넌트 수준의 복잡한 반응형 동작을 처리하는 기본 관행(Default practice)이 되었습니다 [5, 7, 13-15]. + +## 🔗 Knowledge Connections +- **Related Topics:** [[미디어 쿼리 (Media Queries)]], [[반응형 웹 디자인 (Responsive Web Design)]], [[디자인 시스템 (Design Systems)]], [[모듈식 컴포넌트 (Modular Components)]] +- **Projects/Contexts:** [[SaaS 대시보드 및 이커머스 레이아웃 구축]], [[가변 타이포그래피 (Fluid Typography)]] +- **Contradictions/Notes:** 컨테이너 쿼리는 미디어 쿼리를 완전히 대체하는 것이 아닙니다. 미디어 쿼리가 디바이스나 뷰포트 너비에 대응하는 전역적(페이지 수준) 레이아웃을 관리한다면, 컨테이너 쿼리는 "뷰포트 중심에서 컴포넌트 중심"으로 관점을 전환하여 개별 요소 내부의 지역적인 공간 적응을 전담함으로써 상호 보완적으로 작동합니다 [1, 3, 6]. + +--- +*Last updated: 2026-04-26* \ No newline at end of file diff --git a/10_Wiki/Topics/Frontend_Mastery/CSS Grid 및 Flexbox.md b/10_Wiki/Topics/Frontend_Mastery/CSS Grid 및 Flexbox.md new file mode 100644 index 00000000..c19beede --- /dev/null +++ b/10_Wiki/Topics/Frontend_Mastery/CSS Grid 및 Flexbox.md @@ -0,0 +1,31 @@ +# [[CSS Grid 및 Flexbox]] + +## 📌 Brief 신Summary +CSS Flexbox와 CSS Grid는 웹 페이지의 요소들을 배치하고 정렬하기 위해 도입된 최신 CSS 레이아웃 모듈입니다 [1-3]. Flexbox는 행(Row)이나 열(Column) 중 하나의 방향으로 요소를 배치하는 1차원 레이아웃에 특화되어 있으며, CSS Grid는 행과 열을 동시에 제어하는 2차원 레이아웃 시스템입니다 [4-6]. 이 두 기술은 과거의 float이나 복잡한 위치 지정(positioning) 방식을 대체하여, 예측 가능하고 유지보수가 용이한 반응형 디자인을 구축하는 핵심 도구로 사용됩니다 [7-9]. + +## 📖 Core Content +**1. Flexbox (1차원 레이아웃 및 컴포넌트 정렬)** +* **목적 및 특징:** Flexbox는 단일 차원(행 또는 열)에서 항목을 정렬하고 간격을 분배하는 데 최적화되어 있습니다 [4, 9, 10]. 주로 내비게이션 바, 폼 필드, 카드 컴포넌트 내의 텍스트와 이미지 정렬 등 소규모 레이아웃에 적합합니다 [3, 11, 12]. +* **동작 원리 (Content-out):** Flexbox는 '콘텐츠 중심(Content-out)'으로 동작합니다. 요소들의 내부 콘텐츠 크기에 따라 항목이 커지거나(`flex-grow`) 줄어들며(`flex-shrink`), 가용 공간을 유연하게 채웁니다 [1, 13-16]. 화면 크기가 줄어들면 `flex-wrap` 속성을 통해 자연스럽게 다음 줄로 넘어가게 할 수 있습니다 [17, 18]. + +**2. CSS Grid (2차원 레이아웃 및 페이지 구조화)** +* **목적 및 특징:** CSS Grid는 행(Row)과 열(Column)을 동시에 다룰 수 있는 가장 강력한 2차원 레이아웃 도구입니다 [5, 6, 19]. 전체 페이지 구조, 데이터 대시보드, 복잡한 이미지 갤러리 등 정밀한 배치가 필요한 대규모 레이아웃에 적합합니다 [20-22]. +* **동작 원리 (Layout-in):** CSS Grid는 '레이아웃 중심(Layout-in)'으로 동작합니다. 먼저 그리드 구조(행과 열의 틀)를 정의한 뒤, 그 틀 안의 특정 셀이나 영역에 콘텐츠를 배치합니다 [16, 23]. 아이템들이 여러 행과 열에 걸쳐 병합(spanning)되거나 겹치도록 정밀하게 제어할 수 있습니다 [22, 24, 25]. + +**3. 반응형 디자인에서의 역할** +* 두 기술 모두 고정된 픽셀 폭 대신 유연한 유닛과 논리를 사용하여 수많은 미디어 쿼리(Media Queries)를 줄이는 데 기여합니다 [26, 27]. +* 예를 들어, CSS Grid의 `auto-fit` 속성과 `minmax()` 함수를 결합하면 화면의 가용 공간에 맞춰 열의 개수를 동적으로 자동 조절하는 반응형 그리드를 손쉽게 구현할 수 있습니다 [28-31]. + +**4. 실무 레이아웃 통합 전략 (Grid + Flexbox)** +* 대규모 프론트엔드 프로젝트에서 가장 권장되는 아키텍처 원칙은 **"레이아웃에는 CSS Grid를, 정렬에는 Flexbox를 사용하라(Grid is for layout; Flexbox is for alignment)"**는 것입니다 [32-34]. +* CSS Grid를 사용하여 헤더, 푸터, 사이드바, 메인 콘텐츠 영역 등 애플리케이션의 '주요 레이아웃 스타일(Major layout style)'을 구축합니다 [34, 35]. +* 그런 다음 개별 그리드 셀 내부에 들어가는 버튼 그룹, 아이콘, 텍스트 등의 요소들을 정렬할 때는 Flexbox를 활용합니다 [35, 36]. +* 이러한 하이브리드 접근 방식은 불필요한 래퍼(Wrapper) 요소의 중첩을 줄여 DOM 구조를 가볍게 만들고, 브라우저 렌더링 성능과 코드의 유지보수성을 크게 향상시킵니다 [35, 37-39]. + +## 🔗 Knowledge Connections +- **Related Topics:** [[반응형 디자인]], [[CSS 아키텍처]], [[BEM]] +- **Projects/Contexts:** [[대규모 프론트엔드 아키텍처 최적화]], [[컴포넌트 기반 UI/UX 설계]] +- **Contradictions/Notes:** Flexbox와 CSS Grid는 서로를 대체하는 기술이 아닙니다 [40, 41]. 오히려 Flexbox는 1차원 정렬(예: 한 줄 또는 한 열의 아이템 배치)에 직관적이고 적합하며, CSS Grid는 2차원의 복잡한 구조 배치에 강점을 지니므로 두 기술을 상호 보완적으로 함께 사용해야 완벽한 레이아웃 시스템을 설계할 수 있다고 여러 소스에서 강조합니다 [8, 36, 39, 40]. + +--- +*Last updated: 2026-04-26* \ No newline at end of file diff --git a/10_Wiki/Topics/Frontend_Mastery/CSS Grid.md b/10_Wiki/Topics/Frontend_Mastery/CSS Grid.md new file mode 100644 index 00000000..ba2b1185 --- /dev/null +++ b/10_Wiki/Topics/Frontend_Mastery/CSS Grid.md @@ -0,0 +1,29 @@ +# [[CSS Grid]] + +## 📌 Brief Summary +CSS Grid는 행(Row)과 열(Column)을 동시에 다루어 복잡하고 체계적인 웹 페이지 구조를 설계할 수 있도록 돕는 2차원 레이아웃 시스템입니다 [1, 2]. Flexbox와 달리 레이아웃 구조를 먼저 정의하고 요소를 배치하는 '레이아웃 우선(layout in)' 방식을 취하며, 대규모 페이지 레이아웃이나 대시보드, 갤러리 등 정밀한 배치가 필요한 곳에 가장 적합합니다 [3-5]. + +## 📖 Core Content +* **2차원 레이아웃 제어:** + * 1차원(행 또는 열)으로만 작동하는 Flexbox와 다르게, CSS Grid는 가로와 세로 두 방향의 레이아웃을 동시에 제어할 수 있습니다 [2, 6]. + * 복잡한 중첩 컨테이너를 생성할 필요 없이 깔끔한 마크업으로 복잡한 디자인(예: 헤더, 푸터, 사이드바, 메인 콘텐츠 배치)을 쉽게 구현할 수 있습니다 [7, 8]. +* **정밀한 배치 및 오버랩(Overlap):** + * `grid-template-columns`, `grid-template-rows`, `grid-template-areas` 등의 속성을 통해 아이템을 원하는 위치에 정확히 배치할 수 있습니다 [9, 10]. + * `grid-column` 및 `grid-row` 속성을 활용해 복잡한 마진이나 절대 위치 지정(Absolute positioning) 없이도 요소들을 겹치게 만들 수 있어 시각적인 계층을 표현하는 데 유리합니다 [11, 12]. +* **강력한 반응형 설계 기능:** + * 여백 제어용 `gap`(`grid-gap`) 속성을 네이티브로 지원하므로 margin과 관련된 부작용을 방지합니다 [6, 12]. + * `fr`(분수) 단위와 `minmax()` 함수, 그리고 `repeat(auto-fit, ...)` 같은 기능을 결합하여, 미디어 쿼리에 크게 의존하지 않고도 가용 공간에 따라 트랙 수가 동적으로 변하는 유연한 반응형 레이아웃을 구현할 수 있습니다 [13-17]. +* **다른 CSS 기능과의 상호작용:** + * **절대 위치 지정:** Grid 컨테이너에 `position: relative`를 주면 내부의 절대 위치(`position: absolute`) 요소가 전체 그리드 또는 할당된 그리드 영역(Grid Area)을 기준으로 정밀하게 배치될 수 있습니다 [18-20]. + * **`display: contents` 활용:** Grid 항목의 래퍼(Wrapper) 요소에 `display: contents`를 적용하면, 해당 래퍼의 박스는 사라지고 내부 자식 요소들이 직접 Grid 시스템의 항목으로 편입되어 그리드의 정렬 규칙을 따르게 됩니다 [21-23]. +* **실무 유지보수를 위한 설계 전략 (Flexbox와의 조합):** + * 모던 프론트엔드 아키텍처에서는 CSS Grid와 Flexbox 중 하나만 선택하는 것이 아니라, 목적에 맞게 두 가지를 혼용하는 것이 핵심입니다 [24, 25]. + * 전체 페이지의 구조(Major layout)나 대규모 뼈대는 2차원인 **CSS Grid**로 잡고, 해당 셀 내부에 들어가는 UI 컴포넌트들의 세부적인 정렬은 1차원인 **Flexbox**로 처리하는 것이 유지보수성 높은 코드를 작성하는 모범 사례입니다 [26-29]. + +## 🔗 Knowledge Connections +- **Related Topics:** [[Flexbox]], [[반응형 디자인]] +- **Projects/Contexts:** [[유지보수 가능한 CSS 레이아웃 설계]], [[웹 페이지 및 대시보드 구조화]] +- **Contradictions/Notes:** Flexbox는 콘텐츠의 크기를 기반으로 공간을 분배하는 '콘텐츠 우선(content out)' 방식으로 동작하지만, CSS Grid는 정의된 레이아웃의 형태에 요소를 끼워 맞추는 '레이아웃 우선(layout in)' 방식을 취합니다 [5, 30]. CSS Grid가 더 복잡한 기능을 제공하지만 단순한 1차원 정렬(행, 열 내에서의 아이템 정렬)에 사용하기에는 과도한 설정(overkill)이 될 수 있으므로 상황에 맞게 Flexbox와 구별해 사용해야 합니다 [6, 27, 31]. + +--- +*Last updated: 2026-04-26* \ No newline at end of file diff --git a/10_Wiki/Topics/Frontend_Mastery/CSS Media Queries.md b/10_Wiki/Topics/Frontend_Mastery/CSS Media Queries.md new file mode 100644 index 00000000..8c117378 --- /dev/null +++ b/10_Wiki/Topics/Frontend_Mastery/CSS Media Queries.md @@ -0,0 +1,19 @@ +# [[CSS Media Queries]] + +## 📌 Brief Summary +CSS Media Queries(미디어 쿼리)는 뷰포트 너비, 화면 해상도, 방향 등의 특정 조건에 따라 각기 다른 CSS 스타일을 적용할 수 있게 해주는 규칙이다 [1, 2]. 이는 반응형 웹 디자인의 논리적 토대를 형성하며, 다양한 디바이스에 맞춰 단일 코드베이스로 레이아웃을 유연하게 조정할 수 있도록 돕는다 [1-3]. 또한, 특정 조건에서만 필요한 스타일을 분리하여 브라우저의 초기 렌더링 차단 현상을 방지하는 등 웹 성능 최적화에도 필수적인 역할을 한다 [4, 5]. + +## 📖 Core Content +- **반응형 디자인의 논리적 기반:** 미디어 쿼리는 뷰포트 너비뿐만 아니라 고해상도 디스플레이, 다크/라이트 모드, 가로/세로 화면 방향 등의 조건에 반응하여 각기 다른 CSS 규칙을 적용할 수 있게 해준다 [2, 6]. 이를 통해 모바일용과 데스크톱용 페이지를 따로 만들 필요 없이 유기적으로 적응하는 레이아웃을 구성할 수 있다 [1, 2]. +- **모바일 우선 설계 (Mobile-First Approach):** 미디어 쿼리 작성 시 가장 작은 화면(모바일)을 위한 기본 스타일을 먼저 정의한 후, `min-width` 쿼리를 사용해 화면이 커짐에 따라 점진적으로 복잡한 레이아웃이나 요소를 추가하는 것이 권장된다 [7-9]. 이 방식은 불필요한 스타일 덮어쓰기를 방지하여 코드를 논리적이고 유지보수하기 쉽게 만들어준다 [9]. +- **중단점(Breakpoints) 설정 원칙:** 특정 디바이스의 해상도 규격에 맞춰 중단점을 정하기보다는, 화면을 줄이거나 늘릴 때 콘텐츠의 레이아웃이 깨지기 시작하는 지점을 기준으로 설정해야 한다 [10]. 실무에서는 통상적으로 모바일(480px 이하), 태블릿(481~1024px), 데스크톱(1200px 이상) 등과 같은 구간을 활용한다 [2, 6, 10]. +- **렌더링 성능 최적화 (Optimizing Render Blocking):** 브라우저는 CSS 파싱을 완료하기 전까지 화면 렌더링을 차단하지만, 미디어 쿼리를 활용하면 이 문제를 완화할 수 있다 [4]. HTML `` 태그에 `media` 속성을 명시하여 인쇄용(print)과 같이 당장 필요하지 않은 스타일 시트를 분리하면, 브라우저가 해당 파일을 다운로드하더라도 렌더링 과정을 차단하지 않아 페이지 로딩 속도를 향상시킬 수 있다 [4, 5, 11]. +- **뷰포트 한계와 컴포넌트 중심 설계로의 진화:** 뷰포트 기반 미디어 쿼리는 화면 전체 크기에 반응할 뿐, 컴포넌트가 실제로 속해 있는 부모 컨테이너의 가용 공간을 인식하지 못하는 근본적인 한계를 지닌다 [12]. 따라서 디자인 시스템이나 모듈화된 설계를 위해, 2026년 현재는 부모 컨테이너의 크기에 맞춰 컴포넌트가 스스로 형태를 변경하는 컨테이너 쿼리(Container Queries)와 미디어 쿼리를 병행해서 사용하는 것이 표준으로 자리 잡았다 [12-14]. + +## 🔗 Knowledge Connections +- **Related Topics:** [[반응형 디자인]], [[Container Queries]], [[Mobile-First Design]], [[CSS Performance Optimization]] +- **Projects/Contexts:** [[실무에서 CSS 관리하는 방법]], [[디자인 시스템 개념]] +- **Contradictions/Notes:** 소스에서는 뷰포트 기반의 미디어 쿼리만으로는 완벽한 재사용 컴포넌트를 만드는 데 제약이 있다고 지적한다. 사이드바나 모달 등 다양한 컨텍스트(공간)에 독립적으로 반응해야 하는 컴포넌트를 설계할 때는 미디어 쿼리보다 컨테이너 쿼리를 사용하는 것이 더 적합하며, 이는 최근 반응형 디자인의 패러다임이 페이지 수준에서 컴포넌트 수준으로 이동했음을 보여준다 [12, 14-16]. + +--- +*Last updated: 2026-04-26* \ No newline at end of file diff --git a/10_Wiki/Topics/Frontend_Mastery/CSS Performance Optimization.md b/10_Wiki/Topics/Frontend_Mastery/CSS Performance Optimization.md new file mode 100644 index 00000000..c91e1717 --- /dev/null +++ b/10_Wiki/Topics/Frontend_Mastery/CSS Performance Optimization.md @@ -0,0 +1,35 @@ +# [[CSS Performance Optimization]] + +## 📌 Brief Summary +CSS 성능 최적화는 브라우저의 렌더링 경로에서 병목 현상을 유발하는 렌더링 차단 요소를 줄이고, 연산 비용이 높은 리플로우(Reflow)와 리페인트(Repaint)를 최소화하여 웹페이지의 반응성과 로딩 속도를 향상시키는 과정입니다 [1-4]. "예쁘게" 만드는 것을 넘어 "유지보수 가능하게" CSS를 설계하려면 불필요한 스타일 제거, 애니메이션의 GPU 가속 활용은 물론, CSS Modules나 Tailwind CSS처럼 런타임 오버헤드가 적은 도구를 선택하여 번들 크기와 아키텍처 성능을 동시에 관리하는 실무적 접근이 필수적입니다 [5-8]. + +## 📖 Core Content + +* **렌더링 차단 방지 및 파일 최적화** + * 브라우저가 CSS를 다운로드하고 CSSOM(CSS Object Model)을 구축하기 전까지 페이지 렌더링이 차단됩니다 [2]. 이를 방지하기 위해 미디어 쿼리(media queries)를 활용하여 인쇄용이나 특정 화면 크기에만 필요한 스타일을 별도의 파일로 분리해야 합니다 [9, 10]. + * 사용하지 않는 CSS(Dead code)를 제거하고, 사람이 읽기 위해 추가된 공백을 지우는 압축(Minify) 작업을 거쳐 파일 크기를 줄여야 합니다 [2, 11]. + * `rel="preload"`를 사용하면 폰트, CSS 파일, 이미지 등 핵심 자산을 조기에 다운로드하여 사용자가 화면을 빠르게 볼 수 있도록 렌더링을 최적화할 수 있습니다 [12-14]. + +* **리플로우(Reflow)와 리페인트(Repaint) 최소화** + * 가시성이나 배경색 변경과 같은 시각적 변화는 **리페인트**를 발생시키며, 너비, 높이, 마진 등 요소의 기하학적 형태나 레이아웃이 변경되면 전체 또는 일부 페이지 레이아웃을 다시 계산해야 하는 **리플로우**가 발생해 심각한 성능 저하를 초래합니다 [4, 15]. + * 리플로우 영향을 줄이려면 자바스크립트로 여러 인라인 스타일을 반복적으로 조작하지 말고, 미리 정의된 외부 클래스 하나를 조작하여 한 번의 리플로우만 발생하게 해야 합니다 [16, 17]. DOM 트리의 가장 하단(자식) 노드에서 클래스를 변경하는 것이 리플로우 범위를 최소화하는 데 효과적입니다 [18]. + +* **애니메이션 성능 최적화 전략** + * 애니메이션에 `width`, `height`, `margin` 등의 레이아웃 속성을 사용하면 지속적인 리플로우와 리페인트를 유발하여 화면이 끊기는(Janky) 현상이 발생합니다 [19]. 대신 레이아웃에 영향을 주지 않는 `transform`과 `opacity` 속성을 사용하여 브라우저의 GPU 가속(Compositing)을 활용해야 합니다 [6, 20, 21]. + * `box-shadow`, `filter`, `border-radius`와 같이 브라우저 연산 비용이 높은 속성을 사용한 애니메이션과, 무거운 배경 이미지 및 불필요한 무한 반복 루프 애니메이션을 피해야 합니다 [21-24]. + * 자주 변경되는 요소에는 `will-change` 속성을 부여하여 브라우저가 사전에 렌더링 최적화를 준비하게 할 수 있지만, 너무 많은 요소에 남용하면 역효과가 나므로 주의가 필요합니다 [25, 26]. + +* **실무적 관점: 최신 CSS 아키텍처와 성능 비교** + * CSS 관리 방식을 선택할 때 런타임 성능과 번들 크기를 반드시 고려해야 합니다 [7]. 런타임 CSS-in-JS(예: styled-components, Emotion) 라이브러리는 자바스크립트 실행 중 CSS를 파싱하고 주입해야 하므로 런타임 오버헤드가 발생하고 파일 크기가 커져 성능이 떨어질 수 있습니다 [27-30]. + * 반면 **Tailwind CSS**는 유틸리티 클래스를 사용하여 실제로 쓰인 스타일만 빌드에 포함시키므로 번들 크기를 극적으로 줄일 수 있으며(5~20kb), 런타임 비용이 발생하지 않습니다 [8, 31]. + * **CSS Modules** 역시 빌드 시에 고유 클래스명을 정적으로 생성하므로 캡슐화(스코핑)를 보장하면서도 런타임 오버헤드가 없어 성능 친화적인 아키텍처를 구현할 수 있습니다 [5, 8, 32]. + +## 🔗 Knowledge Connections +- **Related Topics:** [[CSS 구조 설계 방식]], [[BEM]], [[CSS Modules]], [[Tailwind vs 일반 CSS 비교]], [[애니메이션 (transition / keyframes)]] +- **Projects/Contexts:** [[실무에서 CSS 관리하는 방법]], [[대규모 프론트엔드 프로젝트 아키텍처]] +- **Contradictions/Notes:** + - CSS-in-JS는 동적인 스타일링과 개발자 편의성을 제공하지만 성능(번들 크기 및 런타임 비용)에서는 CSS Modules나 Tailwind CSS에 비해 단점이 큽니다 [8, 27-29]. + - 모바일이나 저사양 기기에서 애니메이션을 구현할 때는 시각적인 '부드러움(Smoothness)'을 고집하기보다는 CPU 자원을 아끼기 위해 의도적으로 픽셀 이동 단위를 조정하여 '속도(Speed)'를 챙기는 형태의 타협도 성능 최적화 방법으로 제안됩니다 [33]. + +--- +*Last updated: 2026-04-26* \ No newline at end of file diff --git a/10_Wiki/Topics/Frontend_Mastery/CSS Variables.md b/10_Wiki/Topics/Frontend_Mastery/CSS Variables.md new file mode 100644 index 00000000..901e1463 --- /dev/null +++ b/10_Wiki/Topics/Frontend_Mastery/CSS Variables.md @@ -0,0 +1,27 @@ +# [[CSS Variables]] + +## 📌 Brief Summary +CSS Variables(사용자 지정 속성, Custom Properties)은 JavaScript 없이도 동적인 스타일 제어를 가능하게 하는 모던 CSS의 표준 기능입니다. 과거 Sass와 같은 전처리기(Preprocessor)에 의존해야 했던 변수 기능을 CSS 자체에 내장하여, 런타임 오버헤드를 최소화하면서도 전역적인 테마(Theming) 관리 및 상태 기반 스타일링을 쉽게 만들어 줍니다. 특히 대규모 애플리케이션에서 디자인 토큰을 구현하고 유지보수하기 쉬운 아키텍처를 구축하는 데 핵심적인 역할을 수행합니다. + +## 📖 Core Content +* **모던 CSS 표준으로의 진화와 동적 스타일링:** + CSS 사용자 지정 속성은 과거 전처리기의 전유물이었던 변수 기능을 표준 CSS에 도입한 주요 개선 사항입니다 [1]. 이를 통해 JavaScript의 개입 없이도 동적인 스타일링이 가능해졌으며, 컨테이너 쿼리와 함께 순수 CSS의 부흥(Renaissance)을 이끄는 핵심 기술로 자리 잡았습니다 [2, 3]. + +* **디자인 토큰(Design Tokens) 구현의 핵심:** + 웹 환경에서 디자인 토큰을 코드로 구현할 때 CSS 변수가 적극적으로 활용됩니다 [4]. 효과적인 디자인 시스템을 구축하기 위해 CSS 변수는 주로 3단계 계층 구조를 가집니다 [5]. + 1. **글로벌 토큰 (Primitives):** 컨텍스트 없는 원시 값 (예: `--blue-500: #3b82f6`) + 2. **별칭/시맨틱 토큰 (Alias):** 의미와 목적을 부여한 값 (예: `--color-primary: var(--blue-500)`) + 3. **컴포넌트 토큰:** 특정 UI 요소에 종속된 값 (예: `--button-bg: var(--color-primary)`) + 이와 같이 변수를 참조 연결하는 방식을 통해, 시맨틱 토큰의 값만 교체하여 손쉽게 테마 변경(다크 모드 등)을 적용할 수 있습니다 [6]. + +* **유지보수 가능한 모던 아키텍처와의 결합:** + 글로벌 단위에서 테마 변수를 CSS 사용자 지정 속성으로 관리하고, 개별 컴포넌트의 스타일은 CSS Modules를 통해 격리하는 하이브리드 아키텍처가 효율적인 실무 접근법으로 권장됩니다 [7, 8]. CSS 변수는 CSS Modules와 결합하여 런타임 오버헤드를 최소화하면서도 동적인 스코프 스타일링을 가능하게 합니다 [2]. + 또한 CSS Modules 단독으로는 JavaScript의 상태(State) 데이터를 스타일에 직접 주입하기 어렵다는 단점이 존재하는데, CSS 사용자 지정 속성을 인라인으로 전달함으로써 이 한계를 우회할 수 있습니다 [9]. 나아가 Linaria와 같은 Zero-Runtime CSS-in-JS 환경에서는 정적 CSS를 빌드 타임에 추출하고 동적 상태 제어는 CSS 변수에 위임하여 렌더링 성능을 최적화합니다 [10]. + +## 🔗 Knowledge Connections +- **Related Topics:** [[Design Tokens]], [[CSS Modules]], [[Zero-Runtime CSS-in-JS]] +- **Projects/Contexts:** [[Design Systems]], [[Frontend Architecture]] +- **Contradictions/Notes:** 소스에 따르면 CSS 사용자 지정 속성은 SCSS와 같은 기존 전처리기의 정적 변수나, 런타임 단계에서 스타일을 주입하는 기존 CSS-in-JS가 지닌 성능 저하 문제를 동시에 극복할 수 있는 이상적인 대안으로 평가받습니다 [1, 10]. + +--- +*Last updated: 2026-04-26* \ No newline at end of file diff --git a/10_Wiki/Topics/Frontend_Mastery/CSS 구조 설계 방식.md b/10_Wiki/Topics/Frontend_Mastery/CSS 구조 설계 방식.md new file mode 100644 index 00000000..b0d176c8 --- /dev/null +++ b/10_Wiki/Topics/Frontend_Mastery/CSS 구조 설계 방식.md @@ -0,0 +1,24 @@ +# [[CSS 구조 설계 방식]] + +## 📌 Brief Summary +CSS 구조 설계 방식은 웹 프론트엔드 프로젝트가 대규모로 확장됨에 따라 발생하는 전역 네임스페이스 충돌, 특수성(specificity) 전쟁, 그리고 CSS 비대화(bloat) 문제를 해결하고 코드의 유지보수성을 확보하기 위한 방법론입니다 [1]. 전통적인 BEM과 같은 수동적인 네이밍 규칙부터, 빌드 시점에 자동으로 로컬 스코프(scope)를 분리하는 CSS Modules, 유틸리티 퍼스트(Utility-first) 접근을 취하는 Tailwind CSS 등 다양한 패러다임으로 진화해 왔습니다 [2], [3], [4]. 현대의 CSS 아키텍처는 단순한 시각적 장식을 넘어, 팀 협업 환경에서 예측 가능하고 확장 가능한 컴포넌트 기반 시스템을 구축하는 것을 핵심 목적으로 합니다 [5], [6], [7]. + +## 📖 Core Content +* **전통적 모듈화 방법론 (BEM 구조):** + BEM(Block Element Modifier)은 클래스 이름을 통해 캡슐화를 모방하는 엄격한 네이밍 규칙입니다 [8]. UI를 독립적인 '블록(Block)', 그 내부의 '엘리먼트(Element)', 상태나 외형 변화를 나타내는 '모디파이어(Modifier)'로 분류하여 구조화합니다 [9], [10], [11], [12]. 이를 통해 선택자의 깊이를 얕게(flat) 유지하고 낮은 결합도와 높은 응집도를 촉진합니다 [12]. 하지만 대규모 프로젝트에서는 개발자의 실수로 인한 전역 충돌의 위험이 여전히 존재하며, 사용하지 않는 데드 코드(dead code)를 자동으로 제거하기 어렵다는 한계가 있습니다 [13]. +* **자동화된 스코핑과 캡슐화 (CSS Modules):** + CSS Modules는 빌드 도구를 통해 고유한 해시(hashed) 클래스명을 생성함으로써 자동으로 로컬 스코프를 보장합니다 [3], [14]. SCSS와 같은 기존 프리프로세서와 잘 호환되며 전통적인 CSS 작성 방식을 그대로 유지할 수 있습니다 [15], [16]. 스타일 유출이나 충돌을 원천적으로 방지하여 유지보수성을 크게 향상시키며, 제로 런타임(Zero-runtime)으로 동작하여 런타임 성능 저하가 없습니다 [15], [17]. +* **유틸리티 퍼스트 접근법 (Tailwind CSS):** + Tailwind CSS는 사전에 정의된 단일 목적의 작은 유틸리티 클래스들을 조합하여 HTML이나 JSX 내에서 직접 스타일을 작성하는 방식입니다 [18], [4]. 디자인 시스템의 일관성을 강제하기 쉽고, JIT(Just-In-Time) 컴파일러를 통해 사용된 클래스만 빌드 결과물에 포함시켜 프로덕션 CSS 번들 크기를 획기적으로 줄여줍니다 [19], [4], [20]. 다만, 마크업이 매우 장황해지고(verbose) 임의의 값(arbitrary values)이 남용될 우려가 있으며, 컴포넌트 전반의 스타일을 변경할 때 유지보수가 까다로울 수 있습니다 [19], [21], [20]. +* **런타임 기반 스타일링의 한계 (CSS-in-JS):** + Styled-components나 Emotion과 같은 CSS-in-JS는 JavaScript 코드 내에 스타일을 작성하여 컴포넌트 로직과 스타일을 함께 배치하는 방식입니다 [22], [23]. 동적 테마 적용이나 props를 활용한 스타일링에 매우 유리하지만, 런타임에 CSS를 파싱하고 주입해야 하므로 성능 오버헤드와 자바스크립트 번들 크기 증가가 발생합니다 [24], [25], [26], [23]. 특히 최근의 React Server Components(RSC) 환경에서는 컨텍스트(Context) 기반의 CSS-in-JS가 호환되지 않는 치명적인 문제가 있어, 빌드 시점에 정적 CSS를 생성하는 Vanilla Extract 같은 제로 런타임 도구나 CSS Modules, Tailwind로 전환되는 추세입니다 [27], [28], [29]. +* **실무에서의 혼합 전략 (Hybrid Approach):** + 규모가 큰 엔지니어링 팀들은 단일 도구에 얽매이지 않고 각 방식의 장점을 결합하여 사용하기도 합니다 [30]. 예를 들어, 전반적인 레이아웃과 간격에는 개발 속도가 빠른 Tailwind CSS를 적용하고, 복잡한 애니메이션이나 정밀한 제어가 필요한 컴포넌트에는 CSS Modules나 SCSS를 결합하여 사용하는 하이브리드 전략을 채택함으로써 개발 생산성과 애플리케이션 성능을 동시에 최적화할 수 있습니다 [31], [32], [30], [33]. + +## 🔗 Knowledge Connections +- **Related Topics:** [[BEM]], [[CSS Modules]], [[Tailwind CSS]], [[CSS-in-JS]], [[유틸리티 퍼스트(Utility-first)]] +- **Projects/Contexts:** [[대규모 프론트엔드 프로젝트 아키텍처]], [[디자인 시스템 기반 컴포넌트 개발]], [[React Server Components(RSC) 환경의 스타일링 최적화]] +- **Contradictions/Notes:** Tailwind CSS는 클래스 네이밍에 대한 고민을 줄이고 빠른 프로토타이핑을 가능하게 하여 일관성과 CSS 번들 사이즈 최적화에 기여하지만 [19], [4], 개발자에 따라서는 인라인 스타일을 작성하는 것과 다름없어 HTML 마크업을 심각하게 어지럽히고 추상화 레이어를 불필요하게 추가한다는 강한 비판도 존재합니다 [34], [35], [19], [20]. 반면, CSS-in-JS는 컴포넌트 캡슐화에 매우 효과적이나 [22], 런타임 비용 및 서버 컴포넌트 호환성 이슈로 인해 2025년 기준 신규 아키텍처에서는 지양되고 CSS Modules가 더 안정적인 대안으로 추천되기도 합니다 [24], [36], [27], [37]. + +--- +*Last updated: 2026-04-26* \ No newline at end of file diff --git a/10_Wiki/Topics/Frontend_Mastery/CSS 성능 최적화(CSS Performance Optimization).md b/10_Wiki/Topics/Frontend_Mastery/CSS 성능 최적화(CSS Performance Optimization).md new file mode 100644 index 00000000..a25b6c58 --- /dev/null +++ b/10_Wiki/Topics/Frontend_Mastery/CSS 성능 최적화(CSS Performance Optimization).md @@ -0,0 +1,22 @@ +# [[CSS 성능 최적화(CSS Performance Optimization)]] + +## 📌 Brief Summary +CSS 성능 최적화는 웹 페이지의 렌더링을 차단하는 요소를 줄이고 불필요한 리플로우(Reflow)와 리페인트(Repaint) 연산을 최소화하여 빠르고 매끄러운 사용자 인터페이스를 제공하는 과정입니다 [1-3]. 선택자 단순화, CSS 파일 분할 및 에셋 로딩 최적화, 하드웨어 가속(GPU)을 활용한 애니메이션 최적화 등을 포함합니다 [4-7]. 궁극적으로 브라우저의 렌더링 파이프라인 부담을 줄여 사용자 경험과 유지보수성을 동시에 향상시키는 것을 목적으로 합니다 [1, 3, 8]. + +## 📖 Core Content +* **렌더링 블로킹 및 CSSOM 최적화:** + 브라우저가 화면을 그리기 위해서는 DOM과 CSSOM 트리를 모두 구성해야 하므로, CSS는 기본적으로 렌더링을 차단(Render-blocking)합니다 [9]. 이를 최적화하기 위해 미디어 쿼리(`media` 속성)를 사용하여 인쇄용이나 특정 화면용 CSS를 모듈 단위로 분리하면 초기 렌더링 차단 시간을 줄일 수 있습니다 [4, 10]. 또한, 사용하지 않는 CSS를 제거하고 코드를 최소화(Minify) 및 압축해야 하며, 복잡성을 낮춘 단순한 선택자를 작성하여 파싱 시간을 줄이는 것이 중요합니다 [4, 8, 11]. 중요한 CSS 파일이나 폰트는 ``를 활용해 조기에 로딩하는 것이 권장됩니다 [5]. +* **리플로우(Reflow)와 리페인트(Repaint) 최소화:** + 요소의 너비, 높이, 마진 등 레이아웃에 영향을 주는 변경은 화면 전체나 일부를 다시 계산하는 리플로우를 유발하며, 이는 브라우저 성능에 가장 큰 비용을 발생시킵니다 [2, 3, 12, 13]. 배경색이나 가시성 등 시각적 요소의 변경은 리페인트를 유발합니다 [2, 14]. 이러한 연산을 최소화하려면 여러 인라인 스타일을 설정하는 것을 피하고 DOM 트리의 가장 낮은 하위 레벨에서 클래스를 변경해야 합니다 [15, 16]. 또한, 자바스크립트를 이용해 DOM에 대해 읽기와 쓰기를 반복하는 '레이아웃 스래싱(Layout thrashing)'을 방지하기 위해 DOM 업데이트를 일괄 처리(Batch)하는 기술이 필요합니다 [17-19]. +* **애니메이션 최적화:** + `width`, `height`, `box-shadow` 와 같이 리플로우나 과도한 리페인트를 유발하는 속성의 애니메이션은 피해야 합니다 [7, 12, 20]. 대신 레이아웃 재계산을 유발하지 않는 `transform`이나 `opacity` 속성을 활용하면 브라우저가 애니메이션 처리를 GPU에 위임(하드웨어 가속)하여 60fps의 부드러운 성능을 확보할 수 있습니다 [7, 21-23]. 과도한 수의 동시 애니메이션이나 거대한 배경 이미지 사용은 지양해야 하며, 상태가 변할 특정 요소에는 `will-change` 속성을 주어 브라우저가 사전에 최적화할 수 있게 힌트를 제공할 수 있습니다 [20, 24-26]. +* **렌더링 격리(Containment) 활용:** + CSS Containment 모듈의 `contain`이나 `content-visibility` 속성을 사용하면, 브라우저가 페이지의 특정 컨테이너를 다른 DOM 요소와 분리하여 독립적으로 렌더링 최적화를 수행하도록 지시할 수 있습니다 [27, 28]. 화면에 보이기 전까지는 해당 컨테이너의 레이아웃과 렌더링을 생략할 수 있어 성능이 크게 향상됩니다 [28]. + +## 🔗 Knowledge Connections +- **Related Topics:** [[애니메이션 (transition / keyframes)]], [[CSS 구조 설계 방식]], [[리플로우와 리페인트(Reflows & Repaints)]], [[CSS Modules]] +- **Projects/Contexts:** [[실무에서 CSS 관리하는 방법]] +- **Contradictions/Notes:** 컴포넌트 기반 아키텍처에서 Styled-components와 같은 런타임 CSS-in-JS 방식은 동적 스타일링에 유리하지만, 브라우저 런타임에 CSS를 파싱하고 주입해야 하므로 성능 오버헤드와 렌더링 속도 저하를 유발할 수 있습니다 [29, 30]. 반면 성능이 중요한 환경에서는 정적 CSS를 생성하는 CSS Modules나 Tailwind CSS 같은 Zero-runtime 방식이 성능 상 더 권장됩니다 [31-34]. 또한 브라우저 최적화를 돕는 `will-change` 속성은 성능 문제를 미리 방지하고자 너무 많은 요소에 남용할 경우 오히려 브라우저의 리소스를 소모해 성능 저하를 일으킬 수 있으므로 최후의 수단으로만 사용해야 합니다 [24, 25]. + +--- +*Last updated: 2026-04-26* \ No newline at end of file diff --git a/10_Wiki/Topics/Frontend_Mastery/CSS 애니메이션 성능(CSS Animation Performance).md b/10_Wiki/Topics/Frontend_Mastery/CSS 애니메이션 성능(CSS Animation Performance).md new file mode 100644 index 00000000..c7eb0d9d --- /dev/null +++ b/10_Wiki/Topics/Frontend_Mastery/CSS 애니메이션 성능(CSS Animation Performance).md @@ -0,0 +1,20 @@ +# [[CSS 애니메이션 성능(CSS Animation Performance)]] + +## 📌 Brief Summary +CSS 애니메이션 성능(CSS Animation Performance) 최적화는 웹 애플리케이션에서 애니메이션이 브라우저의 렌더링 엔진에 미치는 부하를 줄여 끊김 없는(jank-free) 부드러운 사용자 경험을 제공하기 위한 기술적 접근입니다. 레이아웃 재계산(Reflow)과 화면 다시 그리기(Repaint)를 유발하는 속성의 애니메이션을 피하고 GPU 가속을 활용할 수 있는 속성으로 대체하는 것이 핵심입니다. 최적화되지 않은 애니메이션은 기기의 리소스를 낭비하고 렌더링 속도를 늦춰 전반적인 유지보수성과 UX를 크게 저해할 수 있습니다 [1-3]. + +## 📖 Core Content +* **Reflow 및 Repaint를 유발하는 속성 애니메이션 피하기**: `width`, `height`, `margin`, `padding`, `top`, `left`, `bottom`, `right`와 같은 기하학적 형태나 레이아웃에 영향을 주는 속성은 브라우저의 레이아웃 재계산(Reflow 또는 Layout thrashing)과 다시 그리기(Repaint)를 유발하여 성능을 크게 저하시킵니다 [3-6]. +* **GPU 가속을 활용한 속성(Transform, Opacity) 사용**: 레이아웃 변경을 피하기 위해 `width`나 `height` 대신 `transform`(`scale`, `translateZ()`, `rotate3d()`)을, 색상 변화 대신 `opacity`와 `filter`를 사용해야 합니다 [6-9]. 이를 통해 브라우저가 애니메이션 작업을 기본 스레드에서 기기의 GPU로 넘겨 처리(Compositing)하게 함으로써 렌더링 성능을 향상시킬 수 있습니다 [7-9]. +* **비용이 많이 드는 시각적 속성 자제**: `box-shadow`, `border-radius`, `filter` 등의 속성이나 거대하고 복잡한 배경 이미지의 애니메이션은 브라우저의 블렌딩 및 합성 리소스를 매우 많이 소모하므로 사용을 최소화해야 합니다 [9-11]. 복잡한 이미지 대신 SVG나 단순한 CSS 그레이디언트를 활용하는 것이 훨씬 부드럽고 빠른 애니메이션을 보장합니다 [12]. +* **애니메이션 개수 및 무한 루프 제한**: 한 번에 너무 많은 요소를 동시에 애니메이션하거나 불필요한 무한 루프(`infinite`)를 돌리면 시스템 리소스가 고갈되고 초당 프레임(FPS)이 떨어집니다 [10, 13, 14]. 화면에 보이지 않는 요소의 애니메이션은 `animation-play-state`를 이용해 일시 정지시키고, 필수적인 UI 요소에만 제한적으로 애니메이션을 적용해야 합니다 [3, 13, 14]. +* **`will-change` 속성의 전략적 사용**: 애니메이션이 예상되는 요소에 `will-change` 속성을 부여하면, 브라우저가 미리 렌더링 최적화(예: GPU 레이어 분리)를 준비할 수 있게 힌트를 줄 수 있습니다 [8, 13, 15]. 단, 과도하게 사용할 경우 오히려 브라우저의 성능 문제를 일으킬 수 있으므로 최후의 수단으로만 사용해야 합니다 [11, 15]. +* **타이밍 및 성능 테스트**: 부드럽고 자연스러운 느낌을 위해 애니메이션 지속 시간은 보통 200~500ms로 짧게 유지하고 선형적(Linear) 전환보다는 Easing 함수(`ease-in-out` 등)를 사용해야 합니다 [16]. 배포 전에는 Chrome DevTools의 Performance Panel과 Layer Profiler 등을 활용하여 프레임 드롭이나 렌더링 병목 현상을 검증해야 합니다 [6, 17]. + +## 🔗 Knowledge Connections +- **Related Topics:** [[Reflow와 Repaint(Reflows and Repaints)]], [[GPU 가속(GPU Acceleration)]], [[CSS 구조 설계 방식]], [[반응형 디자인]] +- **Projects/Contexts:** [[대규모 프론트엔드 프로젝트의 CSS 최적화(Performance Optimization in CSS Architecture)]], [[UX 개선을 위한 애니메이션 통합(Integrating Animation in UX)]] +- **Contradictions/Notes:** 소스 자료들은 UI에서 애니메이션이 사용자 경험(UX)을 향상하고 브랜드 개성을 살리는 중요한 소통 수단이라고 권장하지만, 동시에 목적 없는 과도한 애니메이션이나 성능을 고려하지 않은 구현은 사용자에게 인지적 과부하를 주거나 기기 성능을 떨어뜨려 오히려 심각한 경험 저하를 낳을 수 있다고 주의를 주고 있습니다 [2, 16, 18]. 따라서 "예쁘게" 만드는 것을 넘어 "유지보수 가능하고 최적화된(Performant)" 상태를 유지하는 것이 강조됩니다. + +--- +*Last updated: 2026-04-26* \ No newline at end of file diff --git a/10_Wiki/Topics/Frontend_Mastery/CSS 애니메이션 최적화(CSS Animations Optimization).md b/10_Wiki/Topics/Frontend_Mastery/CSS 애니메이션 최적화(CSS Animations Optimization).md new file mode 100644 index 00000000..3128aca6 --- /dev/null +++ b/10_Wiki/Topics/Frontend_Mastery/CSS 애니메이션 최적화(CSS Animations Optimization).md @@ -0,0 +1,31 @@ +# [[CSS 애니메이션 최적화(CSS Animations Optimization)]] + +## 📌 Brief만 Summary +CSS 애니메이션 최적화는 웹 인터페이스의 애니메이션이 브라우저 성능을 저하시키거나 사용자 경험을 해치지 않도록 구현하는 기법입니다. 불필요한 레이아웃 재계산(Reflow)과 화면 다시 그리기(Repaint)를 유발하는 속성 사용을 피하고, GPU 가속 및 브라우저 최적화 힌트를 활용하여 화면의 버벅거림(Jank) 현상을 방지합니다. 이를 통해 모바일 및 저사양 기기에서도 부드럽고 응답성 높은 인터페이스를 유지보수 가능하게 설계할 수 있습니다. + +## 📖 Core Content +**리플로우(Reflow)와 리페인트(Repaint) 최소화** +* 웹 브라우저에서 성능을 가장 크게 저하시키는 주요 원인은 리플로우(레이아웃 재계산)와 리페인트(시각적 요소 재렌더링)입니다 [1-3]. +* 애니메이션을 적용할 때 `width`, `height`, `margin`, `padding`, `top`, `bottom`, `left`, `right` 등 요소의 기하학적 크기나 위치를 변경하는 속성은 리플로우를 유발하므로 애니메이션에 사용하는 것을 피해야 합니다 [4-6]. +* 대신 레이아웃에 영향을 주지 않는 `transform`(예: `scale`, `translateZ()`)과 `opacity` 속성을 활용하면 리플로우와 리페인트를 방지할 수 있습니다 [6-8]. + +**고비용 속성 및 과도한 애니메이션 회피** +* `box-shadow`, `filter`, `border-radius`와 같은 속성은 렌더링에 많은 자원을 소모하므로 애니메이션 적용 시 성능 병목 현상을 일으킬 수 있어 가급적 피하는 것이 좋습니다 [8, 9]. +* 크고 복잡한 비트맵 배경 이미지를 애니메이션화하는 것은 성능을 크게 저하시키므로, 해상도에 독립적이고 가벼운 SVG나 간단한 CSS 그라디언트를 활용하는 것이 효율적입니다 [10, 11]. +* 무수히 많은 요소를 동시에 애니메이션 처리하거나 불필요한 무한 루프(`infinite`)를 적용하면 프레임 속도(FPS)가 급격히 떨어집니다 [9, 12, 13]. 화면에서 보이지 않는 상태일 때는 `animation-play-state`를 사용해 애니메이션을 일시 정지하는 방식으로 자원을 아껴야 합니다 [1, 13]. + +**GPU 가속 및 브라우저 최적화 기능 활용** +* `transform`과 `opacity`를 사용하면 브라우저가 애니메이션 처리를 메인 스레드에서 분리하여 GPU로 넘기는 컴포지팅(Compositing) 과정을 거치게 되어 성능이 대폭 향상됩니다 [7, 8, 14]. +* 문서의 흐름에서 벗어난 `position: absolute` 또는 `position: fixed` 요소에 애니메이션을 적용하면, 주변 요소의 레이아웃에 영향을 미치지 않기 때문에 전체 리플로우 대신 덜 비용이 드는 리페인트만 발생시킵니다 [15-17]. +* `will-change` 속성을 사용하면 브라우저에 어떤 요소가 변경될지 미리 힌트를 주어 렌더링 최적화를 준비하게 할 수 있습니다 [12, 18, 19]. 또한 JS 기반 애니메이션을 쓴다면 브라우저의 리페인트 주기와 동기화되는 `requestAnimationFrame`을 사용해야 합니다 [19]. + +**접근성(Accessibility) 고려** +* 과도한 움직임은 전정기관 장애가 있는 사용자 등에게 불편함이나 멀미를 유발할 수 있습니다 [20, 21]. 이를 방지하기 위해 `prefers-reduced-motion` 미디어 쿼리를 사용하여 사용자의 OS 설정에 따라 애니메이션을 줄이거나 끄도록 제어해야 합니다 [20-22]. + +## 🔗 Knowledge Connections +- **Related Topics:** [[Reflow와 Repaint(리플로우와 리페인트)]], [[GPU 가속 및 Compositing]], [[웹 접근성 및 prefers-reduced-motion]] +- **Projects/Contexts:** [[실무에서의 프론트엔드 성능 최적화]], [[유지보수 가능하고 확장 가능한 CSS 아키텍처 설계]] +- **Contradictions/Notes:** 브라우저의 성능을 끌어올리기 위해 `will-change` 속성을 사용할 수 있지만, 이 속성 자체도 자원을 소모하므로 불필요하게 많은 요소에 남용할 경우 오히려 브라우저를 과부하에 빠뜨려 성능 저하를 유발할 수 있습니다. 따라서 기존의 성능 문제를 해결하기 위한 '최후의 수단'으로만 엄격히 제한하여 사용해야 합니다 [10, 12, 18]. 또한 애니메이션을 부드럽게 하기 위해 1px 단위로 조작하는 것이 보기에는 좋을 수 있으나, 저사양 기기에서는 CPU를 과도하게 사용하게 되므로 차라리 3px 단위로 조작하여 매끄러움을 약간 타협하고 렌더링 속도를 확보하는 것이 실무적으로 좋은 해결책이 될 수 있습니다 [17]. + +--- +*Last updated: 2026-04-26* \ No newline at end of file diff --git a/10_Wiki/Topics/Frontend_Mastery/CSS 애니메이션 최적화(Optimizing CSS Animations).md b/10_Wiki/Topics/Frontend_Mastery/CSS 애니메이션 최적화(Optimizing CSS Animations).md new file mode 100644 index 00000000..9ff324a5 --- /dev/null +++ b/10_Wiki/Topics/Frontend_Mastery/CSS 애니메이션 최적화(Optimizing CSS Animations).md @@ -0,0 +1,28 @@ +# [[CSS 애니메이션 최적화(Optimizing CSS Animations)]] + +## 📌 Brief Summary +CSS 애니메이션 최적화는 웹 페이지 내 애니메이션이 성능 저하나 끊김(Jank) 현상 없이 부드럽게 실행되도록 브라우저의 렌더링 과정을 개선하는 기법입니다 [1, 2]. 브라우저의 레이아웃 재계산(Reflow)과 화면 다시 그리기(Repaint)를 유발하는 속성 사용을 피하고, GPU 가속을 활용할 수 있는 속성을 중점적으로 사용하는 것이 핵심입니다 [3-5]. 이를 통해 사용자에게 쾌적하고 반응성 높은 인터페이스(UX)를 제공하는 동시에 디바이스의 리소스 소모를 최소화할 수 있습니다 [1, 6, 7]. + +## 📖 Core 기Content +* **Reflow 및 Repaint 유발 속성 최소화** + 웹 브라우저의 렌더링 파이프라인에서 애니메이션 최적화의 가장 큰 적은 레이아웃 변형(Reflow)과 재도색(Repaint)입니다 [8]. `width`, `height`, `margin`, `padding`, `top`, `left`, `align-items` 등의 속성을 애니메이션 처리하면 브라우저가 매 프레임마다 레이아웃을 다시 계산해야 하므로 성능이 크게 저하됩니다 [3, 5]. 또한 `box-shadow`, `border-radius`, `filter`와 같이 렌더링 비용이 많이 드는 속성 역시 무거운 컴퓨팅 연산을 요구합니다 [3, 9]. 따라서 위치 이동이나 크기 조절이 필요할 때는 Reflow를 유발하지 않는 `transform`(예: `scale`, `translate`)과 `opacity` 속성을 사용하는 것이 권장됩니다 [4, 9, 10]. + +* **GPU 가속 활용 (Compositing)** + 메인 스레드에서 처리되는 애니메이션 작업을 기기의 GPU로 넘기면 성능, 특히 모바일 기기에서의 성능을 크게 향상시킬 수 있습니다 [4, 11]. `transform: translateZ()`나 `rotate3d()` 같은 3D 변환 속성, `opacity`, 그리고 별도의 렌더링 레이어를 갖는 요소(`