Refactor: Consolidate directory structure into 5 main categories and update metadata
This commit is contained in:
@@ -0,0 +1,43 @@
|
||||
# [[대규모 프론트엔드 프로젝트의 확장성 있는 구조 및 스타일링 시스템 설계|대규모 프론트엔드 프로젝트의 확장성 있는 구조 및 스타일링 시스템 설계]]
|
||||
|
||||
## 📌 Brief Summary
|
||||
대규모 프론트엔드 프로젝트에서 CSS는 단순한 시각적 장식이 아닌 유지보수성과 확장성을 보장하기 위한 엄격한 엔지니어링 규율의 영역으로 진화했습니다 [1]. 이를 위해 모듈화된 프로젝트 디렉토리 설계와 BEM, CSS Modules, Tailwind 등의 구조화된 스타일링 방법론을 도입하고, Flexbox와 CSS Grid를 목적에 맞게 결합하여 렌더링 성능을 최적화해야 합니다 [2-4]. 또한, 컨테이너 쿼리(Container Queries)를 통한 컴포넌트 단위의 반응형 웹 구현과 디자인 토큰(Design Tokens)을 활용한 디자인 시스템 구축이 확장 가능한 아키텍처의 필수 요건입니다 [5, 6].
|
||||
|
||||
## 📖 Core Content
|
||||
|
||||
* **기능(Feature) 기반의 확장성 있는 프로젝트 아키텍처**
|
||||
대규모 프로젝트에서는 컴포넌트, 훅(Hooks), 유틸리티(Utils)를 파일 유형별로 묶지 않고 비즈니스 기능(Feature)이나 도메인(Domain)별로 묶는 도메인 주도 아키텍처를 도입해야 합니다 [4, 7, 8]. FSD(Feature-Sliced Design)와 같은 구조를 활용하면 UI 컴포넌트, API 호출, 관련 CSS 모듈을 하나의 디렉토리 내에 응집력 있게 격리할 수 있어 결합도를 낮추고 유지보수성을 극대화할 수 있습니다 [9-11].
|
||||
|
||||
* **CSS 구조 설계 방식 및 방법론**
|
||||
* **BEM (Block, Element, Modifier):** 컴포넌트를 독립적이고 재사용 가능한 'Block', 종속적인 'Element', 상태를 나타내는 'Modifier'로 분리하여 클래스명을 짓는 방법론입니다 [12, 13]. CSS의 전역 스코프 충돌을 막고 선택자 중첩을 최소화하지만, 개발자의 수동 관리에 의존하므로 규모가 커지면 유지보수 비용이 증가할 수 있습니다 [14, 15].
|
||||
* **CSS Modules:** 빌드 시 고유한 해시(Hash)가 포함된 클래스 이름을 자동으로 생성하여 완벽한 로컬 스코프(Local Scope)와 캡슐화를 제공합니다 [16-19]. 네이티브 CSS 문법을 그대로 사용할 수 있고 런타임 오버헤드가 없다는 장점이 있습니다 [17, 20].
|
||||
* **Tailwind CSS (Utility-first):** 미리 정의된 단일 목적의 유틸리티 클래스를 마크업에 조합하여 UI를 구축하는 방식입니다 [21, 22]. 디자인 일관성을 강제하며 사용하지 않는 클래스를 자동 제거하여 CSS 번들 크기의 무한한 증가를 방지하지만, HTML이 복잡해질 수 있습니다 [23, 24].
|
||||
* **런타임 CSS-in-JS의 한계:** Styled-components나 Emotion 같은 런타임 기반 CSS-in-JS는 동적 스타일링에 강력하지만, 성능 오버헤드와 2025/2026년 기준 React Server Components(RSC) 환경과의 비호환성 문제로 인해 점차 지양되거나 Zero-runtime 도구(Vanilla Extract 등)로 전환되고 있습니다 [25-27].
|
||||
|
||||
* **레이아웃 전략: Flexbox와 CSS Grid 혼합 사용**
|
||||
* **Flexbox (1차원 정렬):** 하나의 행(Row) 또는 열(Column) 방향의 정렬과 공간 분배에 특화되어 있습니다 [3, 28]. 내용물에 맞추어 공간이 유연하게 변하는 '콘텐츠 중심(Content-out)' 설계를 바탕으로 버튼 그룹이나 내비게이션 등 작은 컴포넌트 단위에 최적화되어 있습니다 [29, 30].
|
||||
* **CSS Grid (2차원 레이아웃):** 행과 열을 동시에 제어하며 전체 페이지의 구조를 잡는 '레이아웃 중심(Layout-in)' 설계에 강력합니다 [30-32]. 최적의 아키텍처는 큰 뼈대와 겹치는 구조를 CSS Grid로 구현하고, 각 Grid 셀 내부 요소의 정렬을 Flexbox로 처리하는 혼합 방식입니다 [33, 34].
|
||||
|
||||
* **차세대 반응형 디자인 패러다임**
|
||||
* **Container Queries:** 브라우저 뷰포트(Viewport) 너비에 의존하던 기존의 미디어 쿼리(Media Queries)와 달리, 부모 컨테이너의 크기에 따라 컴포넌트 스스로 레이아웃을 재구성하게 합니다. 이로 인해 컴포넌트의 독립적인 재사용이 가능해집니다 [5, 35-37].
|
||||
* **Fluid Typography:** 폰트 크기 조절 시 하드 코딩된 중단점 대신 CSS `clamp()` 함수와 상대 단위(rem, vw, cqi)를 사용하여, 기기 화면에 맞게 최소 및 최대 크기 사이에서 폰트가 부드럽게(Fluid) 크기 변환되도록 구현합니다 [38-40].
|
||||
|
||||
* **디자인 시스템 및 디자인 토큰(Design Tokens)**
|
||||
확장 가능한 디자인 시스템을 위해 시각적 속성을 코드로 추상화한 디자인 토큰을 활용합니다 [6, 41].
|
||||
1. **Global Tokens (Primitives):** 특정 문맥 없는 핵심 색상/수치 값 (예: `--blue-500: #3b82f6`) [42, 43].
|
||||
2. **Alias Tokens (Semantic):** 의도를 부여한 토큰 (예: `--color-primary: var(--blue-500)`) [42, 43].
|
||||
3. **Component Tokens:** 특정 컴포넌트에 한정된 토큰 (예: `--button-bg: var(--color-primary)`) [43, 44].
|
||||
이러한 계층을 바탕으로 Style Dictionary 등을 사용하면 웹, iOS, Android 코드 베이스 전반에 통일된 토큰을 자동 배포할 수 있습니다 [45, 46].
|
||||
|
||||
* **애니메이션(Motion UX) 및 성능 최적화**
|
||||
UI 애니메이션은 사용자의 인지 부하를 줄이고 피드백을 전달하는 기능적(Functional) 목적으로 사용되어야 합니다 [47-49].
|
||||
* 성능 문제의 주범인 브라우저의 레이아웃 재계산(Reflow/Layout)과 페인트(Repaint)를 유발하는 `width`, `height`, `margin`, `box-shadow` 등의 애니메이션은 지양해야 합니다 [50-54].
|
||||
* 대신 GPU 가속이 가능하여 Composite 단계만 거치는 `transform` 및 `opacity` 속성을 사용하여 부드러운 초당 60프레임(60fps)을 달성해야 합니다 [54-56].
|
||||
|
||||
## 🔗 Knowledge Connections
|
||||
- **Related Topics:** [[Feature-Sliced Design (FSD)|Feature-Sliced Design (FSD)]], [[CSS Modules|CSS Modules]], [[Tailwind CSS|Tailwind CSS]], [[BEM|BEM]], [[CSS Grid|CSS Grid]], [[Flexbox|Flexbox]], [[Container Queries|Container Queries]], [[Design Tokens|Design Tokens]], [[Reflow and Repaint|Reflow and Repaint]], [[Fluid Typography|Fluid Typography]]
|
||||
- **Projects/Contexts:** [[Next.js App Router|Next.js App Router]], [[React Server Components (RSC)|React Server Components (RSC)]]
|
||||
- **Contradictions/Notes:** 스타일링 방법론에 있어서 Tailwind CSS는 유틸리티 조합을 통해 일관성을 높이고 불필요한 번들을 제거해주지만 클래스명이 장황해지는 단점이 있습니다. 반면, HTML의 시각적 복잡도를 피하고 SCSS의 논리 구조나 로컬 스코핑을 선호하는 팀은 CSS Modules 적용을 강력히 선호하는 등 개발팀의 성향이나 프로젝트 레거시에 따라 기술 선택에 대한 논쟁과 하이브리드 조합이 존재합니다 [23, 57-60].
|
||||
|
||||
---
|
||||
*Last updated: 2026-04-26*
|
||||
Reference in New Issue
Block a user