Refactor: Consolidate directory structure into 5 main categories and update metadata

10_Wiki/Topics_Dev/다수의 React-Next.js 애플리케이션과 공통 UI 라이브러리를 보유한 엔터프라이즈 규모의 프론트엔드 환경.md

@@ -0,0 +1,32 @@
+# 다수의 React/[[Next.js|Next.js]] 애플리케이션과 공통 UI 라이브러리를 보유한 엔터프라이즈 규모의 프론트엔드 환경
+
+## 📌 Brief Summary
+다수의 React 및 Next.js 애플리케이션과 공통 UI 라이브러리를 보유한 엔터프라이즈 환경은 주로 pnpm workspaces, [[Turborepo|Turborepo]], Nx 등과 같은 모노레포(Monorepo) 아키텍처를 통해 구축되고 관리됩니다 [1, 2]. 이러한 환경은 일관성과 재사용성을 극대화하기 위해 디자인 토큰(Design Tokens)을 기반으로 한 체계적인 디자인 시스템과 합성 컴포넌트([[Compound Components|Compound Components]]) 같은 유연한 컴포넌트 패턴을 채택합니다 [3-5]. 특히 최근의 Next.js App Router([[React Server Components|React Server Components]]) 환경에서는 성능 병목을 일으키는 런타임 CSS-in-JS(예: styled-components) 대신, 빌드 타임에 정적 CSS를 생성하는 [[Tailwind CSS|Tailwind CSS]]나 [[vanilla-extract|vanilla-extract]]와 같은 접근법을 채택하여 확장성과 렌더링 성능을 확보하는 추세입니다 [6-9].
+
+## 📖 Core Content
+
+*   **엔터프라이즈 모노레포 아키텍처 ([[Monorepo Architecture|Monorepo Architecture]])**
+    *   모노레포는 단순히 여러 폴더를 모아놓은 것이 아니라, 강제된 경계와 명시적인 의존성 그래프를 가지는 모듈형 시스템입니다 [10, 11].
+    *   보통 `apps/` 디렉터리에 배포 가능한 단위(Next.js 앱 등)를 두고, `packages/` 디렉터리에 재사용 가능한 UI 키트, 공유 설정, API 클라이언트 등을 분리하여 관리합니다 [11]. 앱은 프레임워크 의존성(React, 라우터 등)을 소유하고, 공유 패키지는 이들을 피어 의존성(peer dependency)으로 수용하여 "두 개의 React"가 번들에 포함되는 문제를 방지합니다 [12, 13].
+    *   또한, 각 패키지는 `src/index.ts`와 같은 명시적인 진입점을 통해 공개 API를 제공하며, 의도치 않은 결합을 유발하는 패키지 내부로의 깊은 임포트(Deep imports)를 엄격하게 제한합니다 [14, 15].
+
+*   **스타일링 패러다임: Styled-components vs Tailwind CSS**
+    *   **성능 및 Next.js 호환성:** 런타임 CSS-in-JS인 [[Styled Components|Styled Components]]나 Emotion은 React Context에 의존하기 때문에 브라우저에서 실행되지 않는 React Server Components (RSC 환경과 본질적으로 호환되지 않는 문제가 발생했습니다 [6, 7, 16]. [[Next.js 15|Next.js 15]]에서는 서버 렌더링 중 스타일 레지스트리를 구성하는 방식으로 지원하지만, 클래스명 하이드레이션 불일치 위험이나 런타임 오버헤드로 인한 성능 병목(CPU 비용 증가 등)이 발생할 수 있습니다 [17-19]. 
+    *   **Tailwind CSS로의 전환:** 빌드 타임에 사용된 CSS만 정적으로 생성하는 Tailwind CSS는 번들 크기(5-20kb)가 작고 런타임 비용이 없어 [[Core Web Vitals|Core Web Vitals]] 최적화(LCP, FID, INP 등)에 훨씬 유리합니다 [9, 20-22]. 특히 Tailwind CSS v4는 [[JavaScript|JavaScript]] 구성 파일(tailwind.config.js)을 대신하여 CSS 내부의 `@theme` 지시어를 사용하는 "CSS-우선(CSS-first)" 아키텍처와 훨씬 빠른 Oxide 엔진을 도입하여 엔터프라이즈 확장에 유용합니다 [23-25]. 다수의 테마와 엄격한 타입 안정성이 필요한 대규모 시스템의 경우 제로 런타임(Zero-runtime) CSS-in-JS인 `vanilla-extract`도 훌륭한 대안입니다 [21, 26].
+
+*   **확장 가능한 UI 컴포넌트 라이브러리 구축**
+    *   **합성 컴포넌트 (Compound Components):** 복잡한 레이아웃과 수많은 Prop의 전달([[Prop Drilling|Prop Drilling]])을 방지하기 위해 `Accordion`, `Accordion.Item`, `Accordion.Header`처럼 역할을 분산하는 패턴입니다 [5, 27, 28]. 부모 컴포넌트가 Context를 통해 암시적으로 상태를 공유하고 하위 컴포넌트가 동작을 수행하므로, 컴포넌트 소비자가 유연하게 레이아웃을 구성할 수 있습니다 [29-31].
+    *   **[[Overrides Pattern|Overrides Pattern]] ([[Uber Base Web|Uber Base Web]] 사례):** 우버(Uber)의 Base Web과 같은 엔터프라이즈 라이브러리는 컴포넌트의 내부 엘리먼트를 타겟팅하여 스타일, 프로퍼티 혹은 렌더링 자체를 교체할 수 있는 일원화된 `overrides` API를 제공합니다 [32-34]. 이를 통해 모든 엣지 케이스마다 새로운 prop을 추가하는 "Prop soup" 문제를 방지하고 확장성을 높입니다 [34, 35].
+
+*   **디자인 시스템과 디자인 토큰 (Design Tokens)**
+    *   일관된 UI 시스템 관리를 위해 시각적 속성(색상, 타이포그래피, 간격 등)을 기계가 읽을 수 있는 데이터 단위로 추출합니다 [36].
+    *   토큰은 확장성을 위해 3계층으로 구성됩니다: 1) 원시 토큰(Primitive: `color.blue.500`), 2) 의미론적 토큰(Semantic: `color.primary`), 3) 컴포넌트 토큰(Component: `button.background`) [37-39]. 
+    *   Tailwind v4의 CSS 변수를 활용하면, 테마나 다크 모드를 구현할 때 의미론적 토큰의 값만 변경하여 수많은 컴포넌트의 로직 수정 없이 UI 전반에 변화를 즉시 반영할 수 있습니다 [40-42].
+
+## 🔗 Knowledge Connections
+- **Related Topics:** [[Monorepo Architecture|Monorepo Architecture]], Design Tokens, Compound Components, [[React Server Components (RSC)|React Server Components (RSC]], Tailwind CSS vs Styled Components, [[Feature-Sliced Design|Feature-Sliced Design]]
+- **Projects/Contexts:** [[Uber Base Web|Uber Base Web]], [[Shopify Polaris|Shopify Polaris]]
+- **Contradictions/Notes:** 컴포넌트 스타일링 방식과 관련하여, 소스에서는 Styled-components 방식이 컴포넌트 중심의 직관적 코드 작성과 동적 스타일링에 유리하다고 인정하지만(장점), 대규모 Next.js 앱라우터(RSC) 환경에서는 런타임 오버헤드 문제와 Context 부재로 인해 아키텍처상 한계가 발생하므로 신규 프로젝트의 경우 Tailwind CSS나 [[CSS Modules|CSS Modules]], vanilla-extract를 권장하는 입장 차이를 보입니다 [6, 7, 9, 16, 26, 43]. 
+
+---
+*Last updated: 2026-04-26*