# [[Scalable React Applications]]

## 📌 Brief 시 Summary
확장성 있는 리액트 애플리케이션(Scalable React Applications)은 코드베이스와 팀의 규모가 커지더라도 유지보수성, 성능, 명확한 아키텍처 경계를 유지할 수 있도록 설계된 프론트엔드 시스템을 의미합니다 [1, 2]. 이를 달성하기 위해 개발자들은 단순한 파일 유형별 폴더 구조를 넘어 비즈니스 기능(Feature) 중심의 모듈식 아키텍처를 채택하며 [3, 4], 엄격한 명명 규칙과 클린 코드 원칙(SOLID, DRY)을 준수합니다 [5, 6]. 또한 상태 관리(State Management) 라이브러리의 적절한 선택과 렌더링 최적화 기술을 통해 복잡한 UI에서도 성능 저하를 방지합니다 [7, 8].

## 📖 Core Content

*   **아키텍처 및 폴더 구조 (Architecture & Folder Structure)**
    리액트는 구조에 대한 강제성이 없기 때문에, 앱이 확장될 때 아키텍처가 붕괴되는 경우가 빈번합니다 [1]. 작은 규모에서는 컴포넌트나 훅을 파일 유형별로 모으는 평면적인 구조(Flat Structure)가 작동하지만, 앱이 커지면 기능(Feature) 단위로 구조를 묶는 것이 필수적입니다 [9, 10]. 특히 2025년 프론트엔드 생태계에서는 모듈간의 결합도를 낮추는 **Feature-Sliced Design (FSD)**이 강력한 해결책으로 제시됩니다 [11, 12]. FSD는 앱을 `app`, `pages`, `widgets`, `features`, `entities`, `shared`의 계층으로 나누고, 상위 계층에서 하위 계층으로만 의존하도록 단방향 의존성 규칙을 강제하여 우발적인 코드 결합을 방지합니다 [13, 14].

*   **효율적인 상태 관리 (State Management)**
    상태 관리는 애플리케이션의 크기에 따라 도구를 신중히 선택해야 합니다. React에 내장된 Context API는 테마나 다국어 설정처럼 자주 변경되지 않는 정적 데이터 공유에는 탁월하지만, 값이 변경될 때마다 하위의 모든 구독 컴포넌트를 리렌더링시키는 치명적인 단점이 있습니다 [15-17]. 반면 Zustand는 선택자(Selector) 패턴을 통해 필요한 상태 조각만 구독할 수 있어 리렌더링을 방지하며, 중대형 프로젝트에서 훌륭한 대안이 됩니다 [16, 18, 19]. 10명 이상의 개발자가 참여하거나 비동기 처리 로직이 얽힌 거대한 앱에서는 보일러플레이트가 있더라도 예측 가능성을 강제하는 Redux(및 RTK Query)를 사용하는 것이 오류를 방지하는 표준적인 접근입니다 [20-22]. 또한, 서버 상태는 TanStack Query를 활용하여 클라이언트 상태와 분리하는 것이 권장됩니다 [16].

*   **성능 최적화 전략 (Performance Optimization)**
    현대의 확장성 있는 앱은 사용자 경험(UX)과 직결되는 초기 로딩 및 런타임 성능 최적화가 필수입니다 [23, 24]. 초기 번들 크기를 줄이기 위해 `React.lazy`와 `Suspense`를 활용한 라우트 및 컴포넌트 단위의 코드 스플리팅을 적용해야 합니다 [25-28]. 런타임 최적화를 위해서는 무분별한 리렌더링을 막기 위해 `React.memo`, `useCallback`, `useMemo`를 전략적으로 사용하되, 참조 안정성(Reference Stability)을 해치는 JSX 내 익명 함수 사용을 지양해야 합니다 [29-31]. 또한 방대한 목록을 렌더링할 때는 DOM 팽창을 막기 위해 가상화(Windowing/Virtualization) 기법을 사용하며, 리스트 렌더링 시에는 고유하고 안정적인 `key` 값을 제공해야 합니다 [24, 32, 33].

*   **클린 코드 원칙 및 명명 규칙 (Clean Code & Naming Conventions)**
    리액트 컴포넌트는 단일 책임 원칙(SRP)을 준수해 한 가지 일만 하도록 300줄 이하로 작게 유지해야 합니다 [34]. 비즈니스 로직이 중복되면 Custom Hook으로 추출하여 DRY(Don't Repeat Yourself) 원칙을 지키되, 오버엔지니어링(KISS, YAGNI 원칙 위배)은 피해야 합니다 [35, 36]. 파일 명명 규칙 역시 협업 시 매우 중요합니다. 운영체제 간의 대소문자 구분 충돌을 막기 위해 파일명과 폴더명은 `kebab-case`를 주로 사용하고 [37-39], 리액트 컴포넌트명은 `PascalCase` [39, 40], 변수와 Props, 이벤트 핸들러(`handle`, `on` 접두사 사용)는 `camelCase`를 사용해야 코드의 가독성과 일관성을 확보할 수 있습니다 [41, 42].

## 🔗 Knowledge Connections
- **Related Topics:** `[[Feature-Sliced Design (FSD)]]`, `[[State Management (Context API, Zustand, Redux)]]`, `[[Performance Optimization (Memoization, Code Splitting)]]`, `[[Clean Code Principles (SOLID, DRY, KISS, YAGNI)]]`
- **Projects/Contexts:** `[[Modern Frontend Engineering 2025]]`, `[[Scalable React Folder Structure]]`
- **Contradictions/Notes:** 소스에 따르면 "Context API"는 상태 관리 도구라기보다는 데이터 전달(Transport) 메커니즘에 가깝고, 상태가 빈번하게 업데이트되는 규모에서는 전체 리렌더링(re-render storm) 문제를 야기하기 때문에 사용할 때 주의가 필요합니다 [43-45]. 또한, 소스들은 "Zustand"가 유연하고 가벼워 스타트업이나 중형 프로젝트에 가장 적합한 옵션임을 강조하지만, 팀 규모가 커지고 매우 복잡한 앱(1000개 이상의 컴포넌트)을 다룰 경우에는 엄격한 패턴을 강제하는 Redux가 더 나은 대안이 될 수 있다고 조언합니다 [46-49].

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