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

[아키텍처/기반 기술]

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

8.9 KiB Raw Blame History