chore: Clean up 00_Raw directory by moving processed files to 00_Processed

00_Raw/00_Processed/Next.js App Router 환경에서의 확장 가능한 프론트엔드 스타일링 및 UI 컴포넌트 아키텍처 설계.md

@@ -0,0 +1,33 @@
+# [[Next.js App Router 환경에서의 확장 가능한 프론트엔드 스타일링 및 UI 컴포넌트 아키텍처 설계]]
+
+## 📌 Brief Summary
+Next.js App Router 환경에서는 React Server Components(RSC)의 도입으로 인해 컨텍스트(Context)에 의존하는 런타임 CSS-in-JS 방식보다 빌드 타임에 정적 CSS를 생성하는 Tailwind CSS나 CSS Modules, vanilla-extract의 사용이 성능 및 호환성 면에서 적극 권장됩니다 [1-3]. 확장 가능한 UI를 구축하려면 디자인 토큰(Design Tokens)을 활용해 중앙 집중식 스타일링을 적용하고, Atomic Design, Compound Components, Headless Components 등의 패턴을 조합하여 유지보수성과 레이아웃의 유연성을 높여야 합니다 [4-8]. 또한, 대규모 프로젝트에서는 Feature-Sliced Design(FSD)과 같은 아키텍처 방법론을 모노레포(Monorepo)와 결합하여 모듈 간의 결합도를 낮추고 예측 가능한 코드베이스 구조를 설계하는 것이 필수적입니다 [9, 10].
+
+## 📖 Core Content
+
+*   **Next.js App Router와 스타일링 패러다임 변화**
+    *   Next.js 15의 App Router는 브라우저로 JavaScript를 전송하지 않고 서버에서 독점적으로 실행되는 **React Server Components(RSC)를 기본으로 사용**합니다 [11].
+    *   이로 인해 기존 React Context에 의존하던 런타임 CSS-in-JS(예: Styled Components, Emotion)는 RSC 환경에서 작동 제약과 서버 직렬화 오버헤드가 발생할 수 있습니다 [1, 2, 12, 13]. 
+    *   따라서 App Router 환경에서는 런타임 비용이 없고 정적 CSS를 생성하는 **Tailwind CSS, CSS Modules, 또는 vanilla-extract가 가장 적합한 방식**으로 평가받고 있습니다 [3, 14, 15].
+    *   Styled Components v6 이상은 RSC를 지원하여 별도의 지시어 없이 `<style>` 태그를 삽입하는 방식을 제공하지만, 여전히 동적 인터폴레이션보다는 데이터 속성(data attributes)을 활용한 정적 스타일링 적용이 권장됩니다 [13, 16].
+
+*   **디자인 토큰(Design Tokens) 기반 시스템**
+    *   확장 가능한 스타일링을 위해서는 **원시 값(Base/Primitive Tokens), 의미론적 값(Semantic Tokens), 그리고 컴포넌트 토큰(Component Tokens)**의 3단계 계층으로 설계된 디자인 토큰 시스템을 도입해야 합니다 [5, 17-19].
+    *   Tailwind CSS v4는 `@theme` 지시어와 기본 CSS 변수를 활용한 **CSS-first 아키텍처**를 도입하여 자바스크립트 설정 없이도 런타임 테마 전환과 빠르고 타입 안전한 디자인 토큰 관리를 훌륭하게 지원합니다 [20-23].
+
+*   **확장 가능한 UI 컴포넌트 패턴**
+    *   **Atomic Design:** 컴포넌트를 원자(Atoms), 분자(Molecules), 유기체(Organisms), 템플릿(Templates), 페이지(Pages) 단위로 세분화하여 일관성과 재사용성을 확보하는 방법론입니다 [24-26].
+    *   **Compound Components:** 단일 컴포넌트에 수많은 Prop을 넘기는 대신, 부모와 자식 컴포넌트가 Context를 통해 상태를 공유하며 선언적으로 UI를 조합하는 패턴입니다(예: Accordion, Tabs) [4, 7, 27, 28]. 이 패턴은 **뛰어난 레이아웃 유연성을 제공하고 Prop Drilling을 방지**합니다 [4, 8, 29].
+    *   **Headless Components:** 로직, 상태 관리, 접근성 기능만을 제공하고 스타일링은 전적으로 개발자에게 위임하는 방식입니다. 이를 Tailwind CSS와 결합하면 유연하고 확장 가능한 커스텀 컴포넌트 라이브러리를 구축할 수 있습니다 [8, 30].
+
+*   **프론트엔드 아키텍처 및 모노레포(Monorepo) 구조**
+    *   규모가 커지는 애플리케이션에서는 단순히 컴포넌트를 폴더로 나누는 것을 넘어, 명확한 API 경계가 있는 **Feature-Sliced Design (FSD)**과 모노레포 구조를 결합하는 것이 유리합니다 [9, 10, 31].
+    *   FSD는 코드베이스를 Shared, Entities, Features, Widgets, Pages, App 계층으로 엄격하게 분리하여, 각 계층의 역할과 의존성 방향을 일방향으로 강제함으로써 복잡한 스파게티 코드를 방지하고 유지보수성을 극대화합니다 [10, 32, 33].
+
+## 🔗 Knowledge Connections
+- **Related Topics:** [[React Server Components]], [[Design Tokens]], [[Atomic Design]], [[Compound Components]], [[Feature-Sliced Design (FSD)]], [[Tailwind CSS v4]], [[CSS-in-JS]]
+- **Projects/Contexts:** [[Next.js 15 App Router 환경의 프론트엔드 프로젝트]], [[대규모 모노레포(Monorepo) 기반의 확장 가능한 UI 컴포넌트 시스템 구축]]
+- **Contradictions/Notes:** Styled Components를 필두로 한 런타임 CSS-in-JS는 높은 개발자 경험(DX)과 동적 런타임 스타일링을 제공한다는 장점이 있지만, React Server Components 환경에서는 컨텍스트 부재로 인한 제약 및 JavaScript 런타임 오버헤드를 발생시켜 Core Web Vitals 최적화에 불리하다는 강력한 단점을 지닙니다 [1, 15, 34, 35]. 반면 Tailwind CSS는 JSX 내부의 클래스 이름이 매우 길어지는(Class Soup) 단점이 존재하지만, 제로 런타임 비용과 RSC 환경과의 완벽한 호환성 덕분에 엔터프라이즈 환경에서의 성능 면에서 더 우수한 평가를 받고 있습니다 [3, 14, 36, 37].
+
+---
+*Last updated: 2026-04-26*