# [[Scalable Frontend Architecture]]

## 📌 Brief Summary
확장 가능한 프론트엔드 아키텍처(Scalable Frontend Architecture)는 애플리케이션의 규모와 복잡성이 증가하더라도 유지보수성, 성능, 일관성을 유지할 수 있도록 설계된 구조적 접근 방식입니다 [1-3]. 이를 위해 모노레포(Monorepo) 도구와 기능 분할 설계(Feature-Sliced Design, FSD), 아토믹 디자인(Atomic Design) 같은 방법론을 활용하여 UI 컴포넌트와 비즈니스 로직의 명확한 경계를 설정합니다 [3-6]. 더불어, 디자인 토큰(Design Tokens)과 재사용 가능한 컴포넌트 패턴(예: Compound Components, Headless UI)을 도입해 확장성을 높이고, Tailwind CSS와 같은 유틸리티 우선(Utility-first) 스타일링으로 런타임 성능을 최적화하는 것을 핵심으로 합니다 [7-10].

## 📖 Core Content
*   **모듈화 및 디렉토리 아키텍처 (Monorepo & FSD):** 확장 가능한 프론트엔드 환경을 구축하기 위해 다수의 조직이 의존성 관리에 유리한 모노레포(Turborepo, Nx, pnpm workspaces 등) 환경을 채택하고 있습니다 [3, 11]. 모노레포 아키텍처는 코드 결합도를 낮추고 응집도를 높이는 '기능 분할 설계(Feature-Sliced Design, FSD)' 방법론과 결합될 때 강력한 확장성을 발휘합니다 [3, 6]. FSD는 코드베이스를 Shared(원시 UI, 토큰), Entities(도메인 데이터), Features(비즈니스 로직), Widgets, Pages의 계층적 구조로 분리하여 거대한 '공유(shared) 폴더'가 난잡해지는 것을 방지하고 명시적인 공개 API(Public API)만을 사용하도록 강제합니다 [5, 12].
*   **확장 가능한 UI 컴포넌트 패턴:** 확장이 용이한 프론트엔드 컴포넌트는 단일 책임 원칙(Single Responsibility)을 준수하고, 부모-자식 간 명시적 계약을 보장해야 합니다 [13, 14]. 이를 구현하기 위해 **컴파운드 컴포넌트(Compound Components)** 패턴이 널리 쓰이는데, 이는 여러 하위 컴포넌트(예: 탭, 아코디언)가 하나의 Context를 통해 암시적으로 상태를 공유하도록 하여 구성의 유연성을 확보합니다 [15-18]. 더 나아가 디자인과 로직을 분리한 **헤드리스 컴포넌트(Headless Components)** 패턴은 복잡한 상태 관리와 접근성 기능만을 제공하고 스타일링 권한을 온전히 소비자에게 위임하여 재사용성을 극대화합니다 [10, 19, 20]. 이러한 컴포넌트를 설계할 때는 원자(Atom)부터 페이지(Page) 단위로 UI를 조립해 나가는 **아토믹 디자인(Atomic Design)** 구조를 통해 체계적인 계층을 형성할 수 있습니다 [4, 21, 22].
*   **디자인 토큰(Design Tokens)과 테마 확장성:** 확장 가능한 UI 시스템에서는 하드코딩된 값 대신 디자인 토큰을 단일 진실 공급원(Single Source of Truth)으로 사용합니다 [23, 24]. 토큰은 **원시 토큰(Primitive Tokens - 예: 색상 헥스 코드), 시맨틱 토큰(Semantic Tokens - 예: color.primary), 컴포넌트 토큰(Component Tokens)**의 3계층 구조로 관리하는 것이 모범 사례입니다 [25-28]. Style Dictionary와 같은 도구를 활용하여 JSON 기반 토큰을 CSS 변수로 자동 변환해 React 컴포넌트에 적용하면, 다크 모드와 같은 동적 테마를 애플리케이션 전반에 손쉽게 확장할 수 있습니다 [29-31].
*   **스타일링 패러다임과 성능 최적화:** 최신 React 애플리케이션(Next.js App Router 및 React Server Components 환경)에서 성능 확장을 위해 스타일링 패러다임이 Styled-components 같은 런타임 CSS-in-JS에서 Tailwind CSS 등의 빌드 타임(Build-time) 프레임워크로 이동하고 있습니다 [2, 32-34]. Tailwind CSS v4는 `@theme` 디렉티브를 도입한 CSS 우선(CSS-first) 아키텍처와 CSS 변수를 활용하여 런타임 오버헤드(JavaScript 실행 비용)를 제거하고 코어 웹 바이탈(Core Web Vitals) 성능을 비약적으로 끌어올리는 확장성을 제공합니다 [35-38].

## 🔗 Knowledge Connections
- **Related Topics:** [[Monorepo Architecture]], [[Feature-Sliced Design (FSD)]], [[Atomic Design]], [[Compound Components]], [[Headless Components]], [[Design Tokens]], [[Tailwind CSS]], [[React Server Components (RSC)]], [[CSS-in-JS]]
- **Projects/Contexts:** [[Next.js App Router]], [[Uber Base Web Design System]], [[Shopify Polaris]]
- **Contradictions/Notes:** 소스 [9, 33, 34]의 아티클들은 Styled-components와 같은 런타임 기반 CSS-in-JS가 React Server Components(RSC) 환경에서 Context 사용 불가로 인해 호환되지 않으며 성능 오버헤드가 커 Tailwind CSS로 마이그레이션해야 한다고 주장합니다. 하지만 소스 [39, 40]의 Styled-components 공식 릴리스 노트에 따르면, v6.3.0 이상부터는 RSC 환경을 자동 감지하여 `'use client'` 지시어 없이도 인라인 `<style>` 태그를 방출하고 React 19의 기능으로 이를 중복 제거하도록 지원하는 등 RSC 비호환성 문제를 자체적으로 해결하려는 기능이 추가되었습니다.

---
*Last updated: 2026-04-26*