# [[Functional Programming in React]]

## 📌 Brief Summary
React에서의 함수형 프로그래밍은 사용자 인터페이스(UI)를 상태(State)와 속성(Props)의 순수 함수(Pure function)로 표현하는 아키텍처 패러다임입니다 [1]. 클래스 기반 컴포넌트에서 벗어나 함수형 컴포넌트와 Hooks를 활용하여 상태 및 부작용(Side effects)을 관리하며, 이를 통해 코드의 예측 가능성과 테스트 용이성을 극대화합니다 [2, 3]. 불변성(Immutability)을 유지하고 렌더링 중 부작용을 배제하는 것이 이 패러다임이 정상적으로 동작하기 위한 핵심 규칙입니다 [4].

## 📖 Core Content
*   **순수 함수로서의 UI (UI as Pure Functions):** 
    React의 JSX와 선언적 렌더링 구조는 UI를 컴포넌트 트리의 관점에서 생각하도록 권장하며, 각 컴포넌트는 상태와 props를 받아 UI를 반환하는 순수 함수 역할을 수행합니다 [1]. 이는 코드의 예측 가능성을 높이고 테스트를 쉽게 만듭니다 [1].
*   **함수형 컴포넌트와 Hooks 패러다임:** 
    React 생태계는 과거의 클래스 기반 설계에서 함수형 프로그래밍 구조로 전환되었습니다 [3]. 함수형 컴포넌트 내에서 상태(State)와 부작용을 제어하기 위해 React Hooks(`useState`, `useEffect` 등)가 도입되었으며, 이는 비즈니스 로직과 렌더링을 깔끔하게 분리하는 강력한 수단을 제공합니다 [2, 5]. 
*   **불변성과 부작용 격리 (Immutability & Side-effect Isolation):** 
    함수형 React의 기본 규칙은 렌더링 과정 중 데이터의 불변성을 유지하고 부작용을 배제하는 것입니다 [4]. 데이터 통신이나 구독과 같은 부작용은 `useEffect` 훅 내부로 명시적으로 격리하여, 렌더링 자체는 순수하게 유지해야 합니다 [6, 7].
*   **고차 컴포넌트 (Higher-Order Components, HOC):** 
    함수형 프로그래밍의 고차 함수 개념을 차용한 패턴으로, 하나의 컴포넌트를 인자로 받아 추가적인 기능을 부여한 새로운 컴포넌트를 반환하는 함수입니다 [8]. 이를 통해 컴포넌트 간의 로직을 함수 수준에서 재사용할 수 있습니다 [8].

## ⚖️ Trade-offs & Caveats
*   **렌더링 주기와 참조 안정성(Reference Stability) 문제:** 함수형 컴포넌트는 렌더링 시마다 함수 내부의 모든 변수와 함수를 새로 생성합니다 [9, 10]. JSX 내부에 익명 함수나 인라인 객체를 남용하면, 얕은 비교(Shallow comparison)를 수행하는 자식 컴포넌트(`React.memo` 등)에 매번 새로운 참조가 전달되어 불필요한 리렌더링을 유발하는 부작용이 있습니다 [11, 12].
*   **오래된 클로저 (Stale Closures):** 함수형 패러다임에서 비동기 작업 등을 수행할 때, 함수가 과거의 렌더링 시점의 상태를 "기억"하는 클로저 특성으로 인해 최신 상태가 반영되지 않는 버그(Stale Closures)가 발생하기 쉽습니다 [13, 14].
*   **최적화 도구의 남용 (Overhead of Memoization):** 불필요한 렌더링을 막기 위해 `useCallback`, `useMemo` 등을 무분별하게 사용하면, 의존성 배열을 비교하고 캐싱하는 비용이 컴포넌트를 단순히 다시 렌더링하는 비용보다 오히려 더 커져 성능을 저하시킬 수 있습니다 [12, 15].
*   **부작용 정리 누락으로 인한 메모리 누수:** `useEffect` 내부에서 발생한 구독(Subscription)이나 이벤트 리스너 등을 반환(cleanup) 함수로 정리하지 않으면, 함수형 컴포넌트가 언마운트된 후에도 참조가 남아 애플리케이션의 성능을 저하시키는 심각한 메모리 누수를 초래합니다 [7, 16, 17].

## 🔗 Knowledge Connections

### Related Concepts

#### [아키텍처/기반 기술]
- [[Pure Function]]
  - 연결 이유: React의 렌더링 철학은 UI를 상태와 Props의 순수 함수로 취급하는 것에서 출발합니다 [1].
  - 이 개념을 통해 더 깊게 이해할 수 있는 부분: 입력값이 동일하면 항상 동일한 UI를 렌더링해야 한다는 원칙과 React Compiler가 작동하기 위한 전제 조건 [1, 4].
- [[Immutability]]
  - 연결 이유: React가 컴포넌트의 변경 사항을 감지(Diffing)하고 렌더링 최적화를 수행하기 위한 필수 규칙입니다 [4, 18].
  - 이 개념을 통해 더 깊게 이해할 수 있는 부분: 상태를 직접 수정하지 않고 새로운 참조를 반환해야만 `React.memo`와 같은 최적화가 올바르게 작동하는 원리 [11, 18].

#### [구현/활용 도구]
- [[React Hooks]]
  - 연결 이유: 순수 함수형 컴포넌트에 상태 유지와 부작용 처리 능력을 부여하는 핵심 구현체입니다 [2].
  - 이 개념을 통해 더 깊게 이해할 수 있는 부분: 의존성 배열(Dependency array)의 관리와 클로저(Closure)를 활용한 상태 캡처 메커니즘 [6, 19].
- [[React Compiler]]
  - 연결 이유: 함수형 컴포넌트가 React의 규칙(불변성, 부작용 없음)을 준수할 경우, 수동 메모이제이션 없이도 빌드 타임에 자동으로 코드를 최적화해 주는 도구입니다 [4, 20, 21].
  - 이 개념을 통해 더 깊게 이해할 수 있는 부분: 렌더링 결과물을 캐싱하여 수동으로 `useMemo`나 `useCallback`을 작성해야 하는 부담을 줄이는 방식 [22, 23].

### Deeper Research Questions
- React 컴파일러가 함수형 컴포넌트의 렌더링 부작용(side effects)과 불변성(immutability)을 어떤 방식의 정적 분석을 통해 검증하고 자동 메모이제이션을 수행하는가?
- 함수형 컴포넌트의 비동기 작업 처리 시 빈번하게 발생하는 '오래된 클로저(Stale Closures)' 문제는 클래스 컴포넌트의 `this` 참조 방식과 비교하여 어떤 구조적 차이에서 비롯되는가?
- React의 함수형 컴포넌트에서 참조 안정성(Reference Equality) 결여가 `React.memo`의 얕은 비교(Shallow comparison)에 미치는 구체적인 성능 저하 과정은 무엇인가?
- 함수형 기반의 대규모 애플리케이션에서 Context API와 Zustand 같은 전역 상태 관리 도구는 리렌더링 통제(Selector 패턴 유무) 측면에서 어떤 성능적 아키텍처 차이를 보이는가?
- 커스텀 훅(Custom Hooks)으로 비즈니스 로직을 추상화할 때 발생하는 DRY(Don't Repeat Yourself) 원칙과 KISS(Keep It Simple, Stupid) 원칙 간의 트레이드오프를 어떻게 조율해야 하는가?

### Practical Application Contexts
- **Implementation:** React 컴포넌트를 설계할 때 단일 책임 원칙(SRP)을 준수하여 300줄 이상의 거대한 함수를 작고 순수한 컴포넌트로 분리하고, 부작용은 `useEffect` 내부로 명시적으로 격리하여 구현해야 합니다 [3, 6, 24].
- **System Design:** 로직과 UI 렌더링 관심사를 분리하기 위해, 재사용 가능한 상태 로직은 'Custom Hooks' 디렉토리(예: `useAuth`, `useFetch`)에 모으고 순수 UI는 'Components' 폴더로 구조화하는 설계를 적용합니다 [25, 26].
- **Operation / Maintenance:** 함수형 컴포넌트 기반 애플리케이션 운영 시 메모리 누수가 의심되면, Chrome DevTools의 Memory 프로파일러를 사용하여 훅 정리(cleanup) 누락으로 인한 '분리된 DOM 노드(Detached DOM Nodes)'나 닫힌 클로저 참조를 추적하여 유지보수합니다 [7, 17, 27].
- **Learning Path:** 우선 React Hooks의 기본 규칙과 함수 생명주기(클로저, 의존성 배열)를 숙지한 뒤, 메모이제이션(`useMemo`, `React.memo`)을 통한 렌더링 최적화 기법을 배우고, 이후 상태 관리 시스템(Zustand 등) 설계로 나아가는 경로가 권장됩니다 [2, 28, 29].
- **My Project Relevance:** 오래된 클래스 컴포넌트 기반 레거시 코드를 기능형 컴포넌트와 커스텀 훅으로 리팩토링(Refactoring)하여 코드 가독성과 모듈성을 개선하고, 로직 중복을 제거(DRY)하는 실무 과정에 직결됩니다 [5, 26].

### Adjacent Topics
- [[React Hooks Pitfalls]]
  - 확장 방향: 함수형 컴포넌트에서 의존성 배열 누락, 잘못된 상태 업데이트, 정리(cleanup) 누락 등 Hooks를 사용할 때 빈번하게 겪는 안티패턴과 방어적 프로그래밍 방법 탐구 [6, 7, 19].
- [[React Performance Optimization]]
  - 확장 방향: 함수형 아키텍처에서 빈번한 리렌더링을 막기 위한 지연 로딩(`React.lazy`), 가상화(Virtualization), 그리고 수동 메모이제이션의 한계 돌파 전략 연구 [30-32].
- [[Feature-Sliced Design (FSD)]]
  - 확장 방향: 단순히 기능적(Functional)으로 분리된 컴포넌트와 훅들을 애플리케이션의 비즈니스 도메인 관점에서 계층(Layers)과 슬라이스(Slices)로 규격화하여 확장 가능한 아키텍처로 조합하는 방법론 [33-35].

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