# [[Prop Drilling|Prop Drilling]]

## 📌 Brief Summary
Prop Drilling은 실제로 해당 데이터가 필요하지 않은 여러 중간 컴포넌트들을 거쳐 계층적으로 데이터를 전달하는 안티 패턴을 의미합니다 [1]. 주로 깊게 중첩된 하위 컴포넌트에 상태나 데이터를 전달해야 할 때 발생합니다 [1]. React 생태계에서는 이 문제를 해결하기 위해 내장된 Context API나 외부 상태 관리 라이브러리를 활용합니다 [1, 2].

## 📖 Core Content
*   **작동 방식 및 원인:** Prop Drilling은 데이터를 부모 컴포넌트에서 깊이 중첩된 자식 컴포넌트로 전달하기 위해, 중간에 위치한 모든 컴포넌트의 props를 통해 데이터를 통과시키는 방식입니다 [1].
*   **구조적 문제점:** 이 패턴은 중간 컴포넌트들이 자신에게 필요 없는 데이터를 단지 전달(transport)하기 위한 목적으로 취급하게 만들며, 이는 코드의 복잡성을 높이고 유지보수를 어렵게 만듭니다 [1].
*   **React의 내장 해결책:** React는 이러한 현상을 해결하기 위해 'Context API'를 도입했습니다. 이를 통해 컴포넌트 트리의 모든 레벨을 거치지 않고도 전역 관심사(global concerns) 데이터를 직접적으로 하위 컴포넌트와 공유할 수 있습니다 [1, 3, 4].
*   **파생 상태 처리의 한계:** Redux나 Zustand가 파생 상태를 위한 선택자(derived selectors)를 지원하는 것과 달리, Context는 파생 상태를 관리할 때 여전히 Prop Drilling 방식에 의존하게 되거나 불필요한 리렌더링을 피하기 어려운 기능적 한계가 있습니다 [5].

## ⚖️ Trade-offs & Caveats
Prop Drilling을 피하기 위해 가장 먼저 고려되는 Context API는 빈번하게 변경되는 상태를 다룰 때 심각한 성능 제약(Trade-off)을 동반합니다 [6, 7]. Context 값의 일부만 변경되어도 해당 Context를 구독하는 모든 컴포넌트가 불필요하게 전체 리렌더링(re-render)을 수행하게 됩니다 [6, 8]. 

따라서 장바구니나 실시간 데이터 등 빈번하게 변경되는 상태에 대해 Prop Drilling을 피하겠다고 무작정 Context API를 사용하면 애플리케이션의 성능 저하(Re-render storm)를 초래할 수 있습니다 [9, 10]. 이러한 경우에는 선택자(Selector) 기능을 통해 필요한 상태 변경 시에만 리렌더링을 발생시키는 Zustand나 Redux를 사용하는 것이 최적화 측면에서 필수적인 반대 급부의 해결책이 됩니다 [7, 11].

## 🔗 Knowledge Connections

### Related Concepts

#### [기반 기술/해결책]
- [[Context API|Context API]]
  - 연결 이유: Prop Drilling 문제를 해결하기 위해 React에서 자체적으로 도입한 내장 데이터 전달 메커니즘이기 때문입니다 [1].
  - 이 개념을 통해 더 깊게 이해할 수 있는 부분: props를 일일이 넘기지 않고 컴포넌트 트리에 데이터를 브로드캐스트하는 원리와 그에 따른 리렌더링 한계를 이해할 수 있습니다 [6, 12].

#### [상태 관리 도구/대안]
- Zustand
  - 연결 이유: Prop Drilling의 대안인 Context API가 갖는 리렌더링 성능 문제를 극복할 수 있는 경량 상태 관리 라이브러리이기 때문입니다 [2, 7].
  - 이 개념을 통해 더 깊게 이해할 수 있는 부분: 선택자(Selector) 패턴을 활용해 필요한 상태의 변경에만 컴포넌트를 리렌더링하도록 스마트하게 구독(subscribe)하는 구조를 이해할 수 있습니다 [7, 13].
- [[Redux|Redux]]
  - 연결 이유: 대규모 애플리케이션에서 Prop Drilling을 방지하고 상태를 일관성 있게 관리하기 위한 산업 표준 상태 컨테이너 도구이기 때문입니다 [5, 14].
  - 이 개념을 통해 더 깊게 이해할 수 있는 부분: 파생 선택자(derived selectors)가 존재함으로써 Prop Drilling 없이 복잡한 상태와 비동기 로직을 어떻게 효율적으로 다루는지 파악할 수 있습니다 [5, 15].

### Deeper Research Questions

- Prop Drilling을 피하기 위해 Context API를 사용할 때 발생하는 불필요한 리렌더링(re-renders) 문제는 어떤 방식으로 최적화할 수 있는가? [6, 8]
- Redux와 Zustand가 제공하는 '선택자(Selector)' 기능은 Prop Drilling 방식과 비교하여 파생 상태(derived state)를 처리할 때 어떠한 아키텍처적 이점을 제공하는가? [5, 7]
- Context API가 아닌 Zustand나 Redux 같은 전문적인 상태 관리 도구를 도입하여 Prop Drilling을 해결해야 하는 애플리케이션의 복잡도 및 컴포넌트 렌더링 빈도의 정확한 기준점은 무엇인가? [10, 11]
- Prop Drilling을 단순히 회피하기 위해 모든 상태를 전역 컨텍스트(Global Context for Everything)에 넣는 안티 패턴은 시스템 아키텍처에 어떤 부작용을 일으키는가? [16, 17]
- 전역 상태가 아닌 지역 컴포넌트 트리 내에서 발생하는 Prop Drilling을 해결하기 위해, 컴포넌트 합성(Component Composition)이나 클린 코드 원칙을 적용하는 방법은 무엇인가? [18, 19]

### Practical Application Contexts

- **Implementation:** 깊게 중첩된 하위 컴포넌트에 데이터를 전달할 때, 중간 컴포넌트들이 불필요한 props를 거치지 않도록 `React.createContext()`를 활용해 데이터 제공자(Provider)와 소비자(Consumer)를 분리하여 구현합니다 [1, 12].
- **System Design:** 테마나 언어 설정과 같은 정적인 전역 관심사(global concerns)에 대한 Prop Drilling을 방지하기 위해서는 Context API를 설계에 반영하지만, 상태 변경이 잦은 영역은 Zustand나 Redux 기반의 스마트 알림 시스템(smart notification system) 구조로 설계하여 관심사와 성능을 모두 챙깁니다 [4, 13, 20].
- **Operation / Maintenance:** 성능 모니터링 툴(예: React DevTools Profiler)을 통해 Prop Drilling을 우회하고자 도입한 Context가 리렌더링 폭풍(re-render storm)을 일으키는지 추적하고, 병목 발생 시 Selector를 지원하는 상태 관리 도구로 점진적 마이그레이션(Incremental Migration)을 수행합니다 [8, 9, 21].
- **Learning Path:** React 입문 시 데이터 흐름의 기본인 Prop Drilling의 불편함을 먼저 경험하고, 이를 해결하는 Context API를 학습한 후, 최종적으로 대규모 앱을 위한 Zustand나 Redux로 발전해 나가는 형태의 학습 경로를 밟는 것이 권장됩니다 [22].
- **My Project Relevance:** 소스에 관련 정보가 부족합니다.

### Adjacent Topics

- Re-renders
  - 확장 방향: Prop Drilling을 피하기 위한 수단(Context API)이 초래하는 부작용인 불필요한 렌더링을 방지하기 위한 메모이제이션(`React.memo`, `useMemo`, `useCallback`) 등 React 런타임 성능 최적화 기법으로의 이해 확장이 필요합니다 [3, 6, 23].

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