# [[확장 가능한 프론트엔드 아키텍처 구축|확장 가능한 프론트엔드 아키텍처 구축]]

## 📌 Brief Summary
확장 가능한 프론트엔드 아키텍처란 애플리케이션의 규모와 복잡성이 증가하더라도 유지보수성, 성능, 일관성을 잃지 않도록 코드베이스와 UI 컴포넌트를 구조화하는 방법론입니다 [1]. 이를 위해 [[Tailwind CSS|Tailwind CSS]]나 CSS-in-JS와 같은 적절한 스타일링 패러다임을 선택하고, 디자인 토큰을 통해 시각적 일관성을 유지합니다 [1, 2]. 또한 아토믹 디자인(Atomic Design), 복합 컴포넌트([[Compound Components|Compound Components]]) 같은 패턴으로 재사용 가능한 UI를 구축하며, 모노레포(Monorepo)와 FSD([[Feature-Sliced Design|Feature-Sliced Design]])를 활용하여 모듈 간의 의존성을 엄격하게 관리합니다 [3-6].

## 📖 Core Content

**1. 스타일링 패러다임과 디자인 토큰 (Styling Paradigms & [[Design Tokens|Design Tokens]])**
*   **Tailwind CSS vs [[Styled Components|Styled Components]]:** 최신 프론트엔드 아키텍처에서는 런타임 성능과 브라우저 효율성이 핵심적인 요소입니다 [1]. Tailwind CSS는 유틸리티 퍼스트 및 빌드 타임(정적 CSS) 접근 방식을 취하여 제로 런타임 오버헤드와 작은 번들 사이즈를 자랑하며, 특히 React Server Components(RSC) 환경에서 강력한 호환성을 보여줍니다 [7-9]. 반면 Styled Components(CSS-in-JS)는 컴포넌트와 스타일이 함께 위치해 동적 스타일링에 유리하지만, 서버 컴포넌트 환경에서는 React Context 사용이 불가능하여 추가적인 설정([[Style Registry|Style Registry]])이 필요하고 런타임 성능 비용이 발생합니다 [10-12].
*   **디자인 토큰 시스템:** 일관된 UI 확장을 위해 디자인 결정을 토큰화해야 합니다 [2, 13]. 토큰은 원시 값을 나타내는 '기본 토큰(Primitive Tokens)', 의도를 표현하는 '시맨틱 토큰(Semantic Tokens)', 그리고 개별 컴포넌트 변형에 쓰이는 '컴포넌트 토큰(Component Tokens)'의 3계층 구조로 관리되어야 변경 사항이 안전하게 전파되고 테마(예: 다크 모드) 전환이 용이해집니다 [14-16]. 

**2. 컴포넌트 설계 패턴 ([[Component_Design_Patterns|Component Design Patterns]])**
*   **아토믹 디자인 (Atomic Design):** UI를 원자(Atoms), 분자(Molecules), 유기체(Organisms), 템플릿(Templates), 페이지(Pages)의 5단계 계층으로 분해하여 일관성과 재사용성을 촉진하는 방법론입니다 [3, 17]. 이를 통해 설계자와 개발자가 공통의 언어로 소통할 수 있으며, UI 시스템의 구조적 맥락을 쉽게 파악할 수 있습니다 [18, 19].
*   **복합 컴포넌트 (Compound Components) 및 헤드리스 (Headless) UI:** 복잡한 UI(예: 아코디언, 탭)가 과도한 Props([[Prop Drilling|Prop Drilling]])에 의존하는 것을 막기 위해, 책임을 여러 하위 컴포넌트로 분산시키고 React Context를 통해 암시적으로 상태를 공유하는 패턴입니다 [4, 20, 21]. 렌더링 로직과 UI 마크업을 분리하는 헤드리스 컴포넌트 패턴과 결합하면, 뛰어난 유연성과 재사용성을 지닌 확장 가능한 컴포넌트 라이브러리를 구축할 수 있습니다 [22, 23].

**3. 코드베이스 구조 및 경계 관리 (Codebase Structure & [[Boundaries|Boundaries]])**
*   **모노레포 (Monorepo):** 여러 애플리케이션과 공유 라이브러리(디자인 시스템 등)를 단일 저장소에서 관리하는 아키텍처입니다 [6]. [[Turborepo|Turborepo]]나 Nx, pnpm workspaces 같은 도구를 활용하면 로컬 의존성 연결, 작업 파이프라인 최적화 및 캐싱을 통해 대규모 프로젝트의 빌드와 CI/CD 속도를 획기적으로 향상시킬 수 있습니다 [24-26].
*   **[[Feature-Sliced Design (FSD)|Feature-Sliced Design (FSD]]:** 모노레포 내부 또는 단일 앱의 코드가 혼란스러워지는 것을 막기 위해, 코드를 Shared, Entities, Features, Widgets, Pages, App의 계층으로 나누는 아키텍처 방법론입니다 [5]. 상위 계층은 하위 계층을 임포트할 수 있지만 그 반대는 금지되며, 각 모듈은 `index.ts`를 통한 명시적인 공개 API(Public API)만을 제공하여 '깊은 임포트(Deep imports)'로 인한 모듈 간 강결합을 방지해야 합니다 [5, 27, 28].

## 🔗 Knowledge Connections
- **Related Topics:** [[Design Tokens|Design Tokens]], Atomic Design, Compound Components, [[Monorepo|Monorepo]], Feature-Sliced Design (FSD), [[Tailwind CSS|Tailwind CSS]], [[Styled Components|Styled Components]]
- **Projects/Contexts:** [[Uber Base Web|Uber Base Web]], Shopify Polaris, [[Next.js App Router|Next.js App Router]] (RSC)
- **Contradictions/Notes:** 소스 [7, 9, 29]는 대규모 및 서버 사이드(SSR/RSC) 환경에서 런타임 비용이 없고 번들 크기가 작은 Tailwind CSS(정적 유틸리티 방식)가 성능면에서 우수하다고 주장합니다. 그러나 소스 [10, 30]에서는 Styled Components가 컴포넌트 내부에서 동적 상태(Props)에 따른 스타일 변경이 필요하거나 복잡한 런타임 테마 전환이 필요한 애플리케이션에서는 높은 유연성과 개발자 경험(DX)을 제공한다고 반론하며 각 기술의 트레이드오프를 명확히 보여줍니다.

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