# [[Modern Scalable Frontend Architecture|Modern Scalable Frontend Architecture]]

## 📌 Brief Summary
현대적이고 확장 가능한 프론트엔드 아키텍처는 고성능 런타임 최적화, 모듈식 컴포넌트 구조, 중앙 집중화된 디자인 토큰 시스템을 결합하여 대규모 웹 애플리케이션을 구축하는 방법론입니다 [1, 2]. React 생태계가 서버 컴포넌트(RSC) 기반으로 전환됨에 따라 [[CSS-in-JS|CSS-in-JS]]에서 Tailwind CSS와 같은 유틸리티 및 빌드 타임 기반 스타일링으로의 이동이 두드러지고 있습니다 [1, 3, 4]. 또한 Atomic Design, 복합 컴포넌트([[Compound Components|Compound Components]]) 패턴과 모노레포(Monorepo) 및 [[Feature-Sliced Design|Feature-Sliced Design]](FSD) 아키텍처를 통해 확장성과 코드 유지보수성을 극대화합니다 [5-7].

## 📖 Core Content

**1. 스타일링 패러다임: [[styled-components|styled-components]] vs Tailwind CSS**
*   **Styled-components의 한계:** Styled-components와 같은 런타임 CSS-in-JS는 동적인 스타일링과 컴포넌트 기반 접근 방식으로 우수한 개발자 경험을 제공하지만, 브라우저에서 [[JavaScript|JavaScript]]를 실행해 스타일을 생성하므로 성능 오버헤드가 발생합니다 [4, 8, 9]. 특히 React Context에 의존하기 때문에 서버에서 정적 HTML을 렌더링하는 [[React Server Components|React Server Components]](RSC)와 본질적으로 호환되지 않는 단점이 있습니다 [3, 10].
*   **Tailwind CSS의 성능 우위:** Tailwind CSS는 빌드 타임에 정적 CSS를 생성하는 유틸리티 우선(Utility-first) 접근 방식을 취하여 런타임 오버헤드가 없고 RSC와 뛰어난 호환성을 보여줍니다 [4, 11]. JIT(Just-In-Time) 컴파일러를 통해 사용된 클래스만 번들에 포함하므로 [[Core Web Vitals|Core Web Vitals]] 최적화에 유리합니다 [4, 12]. 예를 들어, Kiwi.com의 경우 Styled-components에서 Tailwind로 마이그레이션한 후 모바일 환경에서 FID(First Input Delay)를 75.9%, INP(Interaction to Next Paint)를 58.4% 줄이는 극적인 성능 향상을 달성했습니다 [13, 14]. 
*   **Tailwind v4의 진화:** 새로운 Tailwind v4는 JavaScript 기반의 설정에서 벗어나 네이티브 CSS 변수를 활용하는 "CSS-first" 아키텍처(@theme 지시어 사용)를 도입하였으며, Rust 기반의 Oxide 엔진을 통해 빌드 속도를 10배 이상 향상시켰습니다 [15-17].

**2. 확장 가능한 UI 컴포넌트 설계 패턴**
*   **복합 컴포넌트 (Compound Components):** 단일 컴포넌트에 수많은 Prop을 전달하는 대신, `Accordion.Item`, `Accordion.Header`처럼 관련된 하위 컴포넌트들이 React Context를 통해 상태를 암시적으로 공유하는 패턴입니다 [5, 18, 19]. 이는 사용자가 레이아웃을 자유롭게 구성할 수 있게 하면서도 로직의 은닉성을 보장합니다 [20, 21].
*   **[[Headless Components|Headless Components]]:** 로직(상태 관리, 접근성 등)만을 제공하고 시각적 마크업은 개발자가 직접 정의하도록 하는 패턴입니다 [22, 23]. Tailwind CSS와 결합하면 프레임워크에 종속되지 않는 고도로 커스터마이징된 UI 라이브러리를 만들 수 있습니다 [22].
*   **Atomic Design:** UI를 가장 작은 단위인 원자(Atoms)부터 분자(Molecules), 유기체(Organisms), 템플릿(Templates), 페이지(Pages)로 계층화하여 조립하는 모델로, 일관성 있고 재사용 가능한 디자인 시스템을 구축하는 뼈대가 됩니다 [24-26].
*   **[[Overrides Pattern|Overrides Pattern]]:** Uber의 Base Web 시스템처럼, 컴포넌트 내부의 모든 요소에 대한 식별자를 제공하여 필요 시 기본 스타일과 기능을 완전히 덮어씌울 수 있도록 하는 강력한 커스터마이징 패턴입니다 [27-29].

**3. 디자인 토큰([[Design Tokens|Design Tokens]])과 동적 테마**
*   확장 가능한 디자인 시스템을 위해 색상, 타이포그래피, 여백 등의 시각적 속성을 **원시 토큰(Primitive Tokens)**(예: `color.blue.500`), **시맨틱 토큰(Semantic Tokens)**(예: `color.primary`), **컴포넌트 토큰**으로 나누어 3계층 구조로 관리합니다 [30-33].
*   이러한 계층 구조를 통해 컴포넌트 코드는 그대로 둔 채 시맨틱 토큰의 참조값만 변경하여 다크 모드, 고대비 모드, 다양한 브랜드 테마를 런타임에 동적으로 전환할 수 있습니다 [34-36]. 토큰은 [[Style Dictionary|Style Dictionary]] 등을 이용해 JSON 형식에서 CSS 변수 등으로 자동 변환하여 단일 진실 공급원([[Single_Source_of_Truth|Single Source of Truth]])을 유지합니다 [37, 38].

**4. 모노레포와 구조적 아키텍처**
*   **Monorepo 도구:** 대규모 프론트엔드 프로젝트에서는 [[Turborepo|Turborepo]], Nx, pnpm workspaces를 활용한 모노레포 아키텍처가 채택됩니다. 이를 통해 공통 도구(Lint, TS Config)를 단일화하고 의존성 캐싱을 활용해 CI/CD 파이프라인과 빌드 속도를 개선합니다 [6, 39, 40].
*   **[[Feature-Sliced Design (FSD)|Feature-Sliced Design (FSD]]:** 코드를 Shared, Entities, Features, Widgets, Pages, App의 6가지 계층으로 분리하고, 상위 계층에서 하위 계층으로만 의존성이 흐르도록 제한합니다. 이 엄격한 단방향 의존성 규칙은 대규모 팀 협업 시 아키텍처의 유지보수성과 예측 가능성을 크게 높입니다 [7, 41, 42].
*   **거버넌스와 자동화:** Uber는 UI 컴포넌트의 실제 사용 비율을 감지하는 옵저버빌리티 도구(Base Counter)와, [[Figma|Figma]] 콘솔 MCP를 이용해 AI 에이전트가 디자인 스펙 문서를 자동 생성하는 파이프라인을 구축해 대규모 디자인 시스템의 거버넌스와 확장성을 확보했습니다 [43-46].

## 🔗 Knowledge Connections
- **Related Topics:** [[Tailwind CSS|Tailwind CSS]], Styled-components, React Server Components (RSC, [[Compound Components|Compound Components]], Atomic Design, Design Tokens, [[Monorepo|Monorepo]], [[Feature-Sliced Design (FSD)|Feature-Sliced Design (FSD]]
- **Projects/Contexts:** [[Next.js 15 App Router|Next.js 15 App Router]], Kiwi.com Migration, Uber Base Web, [[Shopify Polaris|Shopify Polaris]]
- **Contradictions/Notes:** 소스에 따르면 Styled-components는 컴포넌트 단위의 동적 스타일링에 훌륭한 개발자 경험을 제공하지만 [8, 47], [[React Server Components (RSC)|React Server Components (RSC]]에서 Context 사용이 불가능하다는 구조적 한계와 런타임 성능 저하 문제로 인해 2025년 이후의 새로운 Next.js 프로젝트에서는 빌드 타임에 작동하는 Tailwind CSS, CSS Modules, 또는 [[Zero-Runtime CSS-in-JS|Zero-Runtime CSS-in-JS]]([[vanilla-extract|vanilla-extract]])의 사용이 강하게 권장됩니다 [4, 9, 10, 48].

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