# [[React Applications|React Applications]]

## 📌 Brief Summary
현대 프론트엔드 엔지니어링에서 React 애플리케이션은 개발자 인체공학(developer ergonomics)과 브라우저 런타임 성능 간의 균형을 맞추기 위해 정교한 아키텍처를 요구합니다 [1]. 확장 가능한 애플리케이션을 구축하기 위해서는 [[Tailwind CSS|Tailwind CSS]]와 Styled Components 같은 스타일링 패러다임의 장단점을 이해하고, 디자인 토큰을 활용한 일관된 테마 구성과 재사용 가능한 UI 컴포넌트 설계가 필수적입니다 [2-4]. 또한, 대규모 프로젝트에서는 모노레포(Monorepo) 아키텍처와 [[Feature-Sliced Design|Feature-Sliced Design]](FSD) 방법론을 도입하고, Next.js의 [[React Server Components|React Server Components]](RSC) 렌더링 전략에 맞춘 최적화가 중요하게 다뤄지고 있습니다 [5-7].

## 📖 Core Content
- **스타일링 패러다임 (Tailwind CSS vs [[styled-components|styled-components]]):**
  Tailwind CSS는 유틸리티 퍼스트(utility-first) 접근 방식을 취하며, 빌드 타임에 정적 CSS를 생성하여 런타임 오버헤드가 없고 번들 크기가 작습니다(5~20kb) [2, 8-10]. 반면 Styled Components는 [[CSS-in-JS|CSS-in-JS]] 라이브러리로, 템플릿 리터럴을 사용해 컴포넌트에 스타일을 캡슐화하지만 런타임에 JavaScript를 실행하여 CSS를 주입하므로 CPU 및 성능 오버헤드가 발생합니다 [10-13]. 특히 Styled Components는 React Context에 의존하기 때문에 서버 컴포넌트(RSC) 환경과 근본적으로 호환되지 않는 문제가 제기되어, RSC를 지원하는 [[Next.js 15 App Router|Next.js 15 App Router]] 환경에서는 Tailwind CSS나 정적 CSS 모듈이 더 권장됩니다 [14-18]. 실제 기업 사례(예: Kiwi.com)에서는 Styled Components에서 Tailwind CSS로 마이그레이션한 결과, 모바일 환경에서 First Input Delay(FID)가 약 75.9% 감소하는 등 [[Core Web Vitals|Core Web Vitals]] 성능이 크게 향상되었습니다 [19, 20].

- **디자인 토큰([[Design Tokens|Design Tokens]])과 테마(Theming):**
  디자인 토큰은 색상, 타이포그래피, 간격 등 UI의 기본 시각적 DNA를 중앙 집중화하여 일관성을 유지하고 확장을 용이하게 합니다 [3, 21, 22]. 효과적인 관리를 위해 토큰은 원시 값(Primitive tokens), 목적 기반의 시맨틱 토큰(Semantic tokens, 예: `color.primary`), 특정 컴포넌트용 토큰(Component tokens)의 세 가지 계층으로 구조화해야 합니다 [23-25]. 최신 [[Tailwind CSS v4|Tailwind CSS v4]]는 JavaScript 설정 대신 CSS 우선(CSS-first) 아키텍처인 `@theme` 디렉티브를 채택하여, 디자인 토큰을 네이티브 CSS 변수로 노출하고 동적 테마 전환(다크 모드 등)을 손쉽게 구현할 수 있도록 지원합니다 [26-28].

- **재사용 가능한 UI 컴포넌트 설계 패턴:**
  React 컴포넌트의 재사용성을 높이려면 단일 책임 원칙(Single Responsibility)을 준수하고, 속성(prop)을 최소화하며 명확한 API 계약을 설정해야 합니다 [29, 30]. 복잡한 UI를 다룰 때는 여러 하위 컴포넌트(`Accordion.Header`, `Accordion.Body` 등)가 Context를 통해 상태를 암시적으로 공유하는 컴포넌트 합성([[Compound Components|Compound Components]]) 패턴을 사용하여 깊은 속성 전달("Prop Drilling")을 방지할 수 있습니다 [31-34]. 이 밖에도 마크업 없이 로직만 캡슐화하는 헤드리스(Headless) 컴포넌트나 Uber의 Base Web에서 사용하는 오버라이드(Overrides) 패턴은 컴포넌트 내부 요소의 스타일과 기능을 개발자가 자유롭게 교체할 수 있도록 하여 높은 확장성을 제공합니다 [35-38]. 또한 뷰 레이어를 원자(Atoms), 분자(Molecules), 유기체(Organisms), 템플릿(Templates), 페이지(Pages)로 나누는 아토믹 디자인([[Atomic Design|Atomic Design]]) 방법론은 일관된 디자인 시스템을 구축하는 데 매우 효과적입니다 [39-41].

- **확장 가능한 프론트엔드 아키텍처 (Scalable [[Frontend|Frontend]] [[Architecture|Architecture]]):**
  대규모 React 애플리케이션은 의존성 관리와 빌드 시간 최적화를 위해 [[Turborepo|Turborepo]], Nx, pnpm workspaces 등을 활용하는 모노레포(Monorepo) 아키텍처를 자주 채택합니다 [42-44]. 모노레포 내부의 코드를 구성할 때는 Feature-Sliced Design(FSD) 방법론을 적용하여 코드를 Shared, Entities, Features, Widgets, Pages, App 등 명확한 계층으로 나누고, 상위 계층에서 하위 계층으로만 의존성이 흐르도록 엄격한 공개 API(Public API) 규칙을 강제하는 것이 유지보수성에 유리합니다 [6, 45, 46].

## 🔗 Knowledge Connections
- **Related Topics:** [[Tailwind CSS|Tailwind CSS]], Styled Components, Design Tokens, [[Compound Components|Compound Components]], Atomic Design, [[React Server Components|React Server Components]], Monorepo Architecture, [[Feature-Sliced Design|Feature-Sliced Design]]
- **Projects/Contexts:** [[Next.js 15 App Router|Next.js 15 App Router]], Uber Base Web, [[Shopify Polaris|Shopify Polaris]]
- **Contradictions/Notes:** 소스에 따르면 Styled Components는 컴포넌트 단위의 캡슐화와 동적인 테마 적용에 매우 강력하지만, 렌더링 시 JavaScript 실행 비용(런타임 택스)이 발생하고 React [[Server Components|Server Components]](RSC) 환경에서는 원활히 작동하지 않는 단점이 있습니다 [12, 14, 47]. 반면 Tailwind CSS는 성능과 번들 크기 면에서 매우 우수하지만, 여러 유틸리티 클래스가 직접 삽입됨에 따라 HTML 마크업이 지저분해지는 "class soup" 문제가 발생할 수 있으므로, 적절한 재사용 가능한 컴포넌트 추상화가 필수적이라고 권고합니다 [48-50].

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