# [[React Development]]

## 📌 Brief 소스 Summary
React Development는 사용자 인터페이스를 구축하기 위한 효율적이고 유연한 JavaScript 라이브러리 활용 기술이다 [1]. 최근의 프론트엔드 엔지니어링에서는 컴포넌트 최적화, 상태 관리 메커니즘, 확장 가능한 아키텍처(Feature-Sliced Design) 및 자동 메모이제이션 도구(React Compiler)를 결합하여 복잡한 대규모 애플리케이션을 구축하는 방향으로 발전하고 있다 [2-4]. 효과적인 개발과 확장을 위해서는 관심사의 명확한 분리, 엄격한 네이밍 규칙, 그리고 성능 최적화에 대한 체계적인 접근이 필수적이다 [5-8].

## 📖 Core Content
*   **아키텍처 및 폴더 구조**: 애플리케이션의 규모가 커짐에 따라 파일 유형별 분리보다 도메인이나 기능(Feature) 중심으로 폴더를 구성하는 것이 권장된다 [9, 10]. 현대적인 구조론인 Feature-Sliced Design(FSD)은 앱을 App, Pages, Widgets, Features, Entities, Shared 등의 레이어로 나누고, 상위 레이어가 하위 레이어에만 의존하도록 단방향 규칙을 강제한다 [11-13].
*   **상태 관리 메커니즘**: 상태의 빈도와 복잡성에 따라 도구를 분리하는 것이 추세다 [14]. 테마나 로케일처럼 자주 변하지 않는 글로벌 상태는 내장 Context API를 사용하고, 자주 변경되어 불필요한 리렌더링을 막아야 하는 상태는 선택자(selector)를 제공하는 Zustand 같은 경량 라이브러리를 사용한다 [15-18]. 거대한 팀과 복잡한 비동기 로직이 얽혀 있는 경우 Redux가 구조화를 돕고, 서버 API 상태 동기화는 TanStack Query(React Query)가 담당한다 [19-21].
*   **성능 및 렌더링 최적화**: 2025년 기준 도입된 React Compiler는 빌드 타임에 AST를 분석하여 `useMemo`, `useCallback`, `React.memo` 등 수동 메모이제이션을 자동으로 처리하고 불필요한 렌더링을 방지한다 [3, 22, 23]. 런타임 성능을 위해서는 `React.lazy`와 `Suspense`를 활용한 코드 스플리팅을 적용하며, Vite 환경에서는 `manualChunks`를 통해 벤더(vendor) 라이브러리를 분할하여 번들 크기를 최적화한다 [24-26].
*   **에러 처리와 메모리 관리**: 하위 컴포넌트 트리의 렌더링 에러로 인해 앱 전체가 하얗게 질리는 현상을 막기 위해 Error Boundary를 사용해 Fallback UI를 보여주고 격리한다 [27, 28]. 런타임 중의 메모리 누수(예: 클로저에 묶인 참조, 분리된 DOM 노드 등)는 Chrome DevTools의 Heap Snapshot 및 Allocation Timeline을 활용해 모니터링하고 수정한다 [29-31].
*   **컨벤션 및 소프트웨어 공학 원칙**: React 함수형 컴포넌트에도 SOLID(특히 단일 책임 원칙, SRP)와 DRY, KISS, YAGNI 원칙을 적용해 거대한 컴포넌트를 분리해야 한다 [32-34]. 파일명은 OS 호환성을 고려해 `kebab-case`를, 컴포넌트 이름은 `PascalCase`를, 함수와 훅은 `camelCase`를 사용하는 것이 표준 네이밍 컨벤션이다 [5, 35-37].

## ⚖️ Trade-offs & Caveats
*   **React Compiler의 맹점**: React Compiler가 수동 메모이제이션의 수고를 덜어주지만, TanStack Query나 React Router와 같이 렌더링마다 불안정한 객체 참조를 의도적으로 반환하는 서드파티 라이브러리를 사용할 경우 최적화 체인이 깨져 리렌더링이 발생할 수 있다 [38, 39]. 또한 최적화 과정이 블랙박스 형태이므로, 렌더링 성능 이슈 발생 시 코드에 명시된 훅을 확인하는 대신 React Profiler를 파헤쳐야 하는 등 디버깅이 더 까다로워진다 [40].
*   **Context API vs 외부 상태 관리**: Context API는 React 내장 기능으로 의존성 추가 없이 'Prop-drilling'을 해결할 수 있으나, 컨텍스트 값이 변경될 때 값을 사용하는 모든 하위 컴포넌트를 무조건 리렌더링시키는 성능적 단점이 있다 [16, 18]. 반면 Zustand 같은 라이브러리는 렌더링 성능 최적화에는 탁월하지만, 아키텍처가 너무 유연하여 대규모 팀에서는 패턴이 파편화될 수 있는 위험성을 동반한다 [17, 41]. 
*   **Error Boundary의 포착 한계**: Error Boundary는 컴포넌트의 렌더링 및 생명주기 내부의 에러는 훌륭하게 잡아내지만, 이벤트 핸들러(`onClick` 등) 내부의 로직, 비동기 콜백(`setTimeout`), 혹은 서버 사이드 렌더링(SSR) 중 발생하는 에러는 포착하지 못한다 [42, 43]. 따라서 별도의 자바스크립트 `try/catch`가 병행되어야 한다 [44].
*   **Feature-Sliced Design 도입의 부작용**: 도메인 중심으로 파일을 관리하는 방식은 대규모 시스템에서 유지보수성을 극대화하지만, 작은 규모의 앱이나 팀에서는 너무 많은 폴더 뎁스와 구조적 규칙이 과도한 엔지니어링(Over-engineering)으로 이어져 초기 개발 속도를 늦출 수 있다 [45, 46].

## 🔗 Knowledge Connections

### Related Concepts

#### [아키텍처 및 폴더 설계]
- [[Feature-Sliced Design]]
  - 연결 이유: 컴포넌트를 단순 파일 유형이 아닌 도메인/기능 스코프에 따라 분리하고 레이어 간 의존성 방향을 강제하여 React 앱의 대규모 확장성을 확보하는 아키텍처 방법론이기 때문 [11, 47].
  - 이 개념을 통해 더 깊게 이해할 수 있는 부분: 거대한 프론트엔드 시스템에서 컴포넌트 간 결합도를 낮추고 비즈니스 로직의 응집도를 높이는 설계 철학.

- [[SOLID Principles in React]]
  - 연결 이유: 단일 책임 원칙(SRP)과 인터페이스 분리 원칙(ISP) 등 전통적인 객체지향 설계 원칙을 React의 함수형 컴포넌트와 훅에 적용하여 클린 코드를 작성하는 방법을 제시하기 때문 [32, 33].
  - 이 개념을 통해 더 깊게 이해할 수 있는 부분: 너무 많은 책임을 지는 300줄 이상의 비대해진 컴포넌트를 관심사별로 분리하는 기준.

#### [상태 관리 및 최적화 도구]
- [[React Compiler]]
  - 연결 이유: `useMemo`, `useCallback`과 같은 수동 성능 최적화를 개발자가 직접 작성하지 않아도 빌드 타임에 AST를 분석해 자동으로 JSX와 계산 결과를 메모이제이션하는 2025년 주요 도구이기 때문 [3, 22, 23].
  - 이 개념을 통해 더 깊게 이해할 수 있는 부분: React의 렌더링 주기에서 불필요한 계산이 어떻게 캐싱되고 컴포넌트 트리의 업데이트를 방지하는지에 대한 빌드 단계 최적화 원리.

- [[Zustand vs Context API]]
  - 연결 이유: Context API가 초래하는 불필요한 전역 렌더링(리렌더링 폭포) 문제를 Zustand가 독립적인 스토어와 상태 선택자(Selector)를 통해 어떻게 해결하는지를 비교하는 핵심 개념이기 때문 [16, 48].
  - 이 개념을 통해 더 깊게 이해할 수 있는 부분: 전역 상태의 변경 빈도에 따라 적절한 상태 관리 도구를 선택하는 기준과 React 렌더링 비용을 줄이는 방법.

#### [디버깅 및 에러 제어]
- [[Error Boundaries]]
  - 연결 이유: 애플리케이션의 특정 UI 요소에서 발생한 자바스크립트 런타임 에러가 전체 화면을 중단시키는 것을 막기 위한 가장 핵심적인 컴포넌트 기반 예외 처리 방식이기 때문 [27, 28].
  - 이 개념을 통해 더 깊게 이해할 수 있는 부분: 선언적 UI 프레임워크에서 예측할 수 없는 오류가 발생했을 때 이를 어떻게 격리하고 Fallback 화면을 띄울 것인가에 대한 처리 패턴.

### Deeper Research Questions

- React Compiler가 빌드 시점에 코드를 자동 메모이제이션함에도 불구하고, 개발자가 `useMemo`나 `useCallback`을 의도적으로 수동 배치해야 하는 구체적인 엣지 케이스는 무엇인가?
- 대규모 애플리케이션에서 Feature-Sliced Design(FSD)을 적용할 때, 여러 기능(Feature) 도메인이 공통적으로 상호작용해야 하는 교차 관심사(Cross-cutting Concerns) 문제는 어떻게 해결해야 하는가?
- 상태 업데이트 빈도가 높은 데이터는 Zustand로, 정적 설정은 Context API로 관리할 때, 두 상태 시스템 간의 데이터를 동기화하거나 결합하여 컴포넌트에 주입하는 모범적인 하이브리드 아키텍처는 무엇인가?
- 이벤트 리스너의 미해제나 클로저로 인해 발생하는 메모리 누수(Memory Leaks) 현상을 Chrome DevTools의 힙 스냅샷(Heap Snapshot) 기능으로 탐지하고 개선하는 구체적 절차는 무엇인가?
- Vite 기반의 React 프로젝트에서 `manualChunks`를 활용한 의존성 분할이 Core Web Vitals (LCP, INP) 개선에 미치는 영향을 측정하고 분석하는 최적화 프로세스는 무엇인가?

### Practical Application Contexts

- **Implementation:** React 컴포넌트를 생성할 때 운영체제 간 빌드 오류를 방지하기 위해 파일과 폴더명은 `kebab-case`(예: `user-profile.tsx`)를 사용하고 컴포넌트와 인터페이스 명은 `PascalCase`를 따른다. 너무 많은 책임을 갖는 컴포넌트는 SRP에 따라 뷰와 로직으로 분리한다 [5, 33, 35, 36].
- **System Design:** 코드를 파일 유형(`components`, `hooks`)별로 단순 나열하지 않고 `features/auth/`와 같이 비즈니스 기능별 모듈로 묶어 결합도를 낮추는 Feature-Sliced Design 구조를 채택한다. 각 기능 폴더는 `index.ts`를 통한 Public API만 노출해 캡슐화를 강화한다 [10, 11, 32, 49].
- **Operation / Maintenance:** 컴포넌트 크래시를 대비하여 독립적인 단위(예: 차트, 폼)마다 Error Boundary를 씌워 장애를 격리하고, 에러 모니터링 플랫폼(Sentry, LogRocket)을 연동하여 런타임 안정성을 확보한다. 또한 메모리 프로파일링으로 Detached DOM Node가 있는지 주기적으로 감시한다 [29, 50-52].
- **Learning Path:** React 기초 동작과 컴포넌트 분리를 이해한 뒤 → Context API를 이용해 전역 상태를 다루다가 발생하는 리렌더링 이슈를 체감 → Zustand나 Redux 같은 상태 도구를 학습 → 메모리 누수 디버깅 및 React Compiler, FSD 같은 시스템 아키텍처 스케일업 순으로 심화 학습한다 [53].
- **My Project Relevance:** React 레거시 코드를 리팩토링할 경우, 제일 먼저 렌더링 비용을 높이는 과도한 Context API를 Zustand로 마이그레이션하고, 거대한 컴포넌트 트리를 단일 책임 원칙에 맞춰 분리하여 팀 단위 협업과 테스트가 용이한 아키텍처로 탈바꿈할 수 있다.

### Adjacent Topics

- [[Core Web Vitals & Web Performance]]
  - 확장 방향: 프론트엔드의 성능 최적화(코드 스플리팅, 레이지 로딩)가 실제 사용자의 화면 표출 속도(LCP)와 상호작용 속도(INP) 등 브라우저 지표와 어떻게 직결되는지 모니터링 기술과 연계하여 탐구 [54, 55].

- [[Vite & Rollup Bundling Strategies]]
  - 확장 방향: React 작성 코드가 운영 환경에 배포되기 전 Vite와 Rollup을 통해 어떻게 ES 모듈 파싱과 청크 분할(`manualChunks`)이 이루어져 캐싱 효율을 극대화하는지 빌드 도구 관점에서 탐구 [22, 25].

---
*Last updated: 2026-04-30*