---
id: wiki-2026-0508-prop-drilling
title: Prop Drilling
category: Frontend
status: needs_review
canonical_id: self
aliases: []
duplicate_of: none
source_trust_level: A
confidence_score: 0.92
tags: [auto-wikified, technical-documentation, merged, frontend]
raw_sources: []
last_reinforced: 2026-05-08
github_commit: pending
inferred_by: Claude Opus 4.7 (auto-normalize 2026-05-08)
tech_stack:
  language: unspecified
  framework: unspecified
---

# Prop Drilling


## 📌 한 줄 통찰 (The Karpathy Summary)
Prop Drilling은 React나 Vue와 같은 컴포넌트 기반 프레임워크에서, 특정 상태나 데이터를 필요로 하는 하위 컴포넌트에게 전달하기 위해 그 데이터를 실제로는 사용하지 않는 여러 중간 계층의 컴포넌트들을 거쳐 프로프(Props)로 계속 내려보내는 현상을 의미합니다 [1, 2]. 이는 컴포넌트 트리가 깊어질수록 코드를 번거롭고 유지보수하기 어렵게 만드는 주요 원인 중 하나가 됩니다 [2]. 프레임워크들은 이러한 문제를 해결하기 위해 Context API, Provide/Inject, 복합 컴포넌트(Compound Components) 패턴 및 중앙 집중식 전역 상태 관리 도구 등을 활용합니다 [1, 3-6].

## 📖 구조화된 지식 (Synthesized Content)
*   **발생 원인과 구조적 한계**
    여러 컴포넌트가 동일한 상태를 공유해야 할 때, 공통 조상 컴포넌트로 상태를 끌어올린(Lifting state up) 후 프로프(Props)를 통해 하위로 전달하는 방식을 취하게 됩니다 [2]. 그러나 엔터프라이즈 애플리케이션 등 규모가 커져 5~6계층 이상의 깊은 컴포넌트 트리가 형성되면, 중간 컴포넌트들은 자신에게 필요 없는 데이터까지 전달받아 하위로 넘겨야만 하는 Prop Drilling 문제가 발생합니다 [1, 2]. 이는 단일 모놀리식 컴포넌트가 너무 많은 프로프를 받아 처리하게 되는 'API 스프롤(Sprawl)' 현상과도 연결됩니다 [3].

*   **React 생태계의 해결 패턴**
    *   **Context API:** 데이터를 컴포넌트 트리의 모든 레벨에서 수동으로 프로프를 통해 전달할 필요 없이, 하위 컴포넌트가 직접 데이터에 접근할 수 있게 하여 Prop Drilling 문제를 해결합니다 [5].
    *   **복합 컴포넌트(Compound Components) 패턴:** 다수의 하위 컴포넌트가 Context를 통해 암시적으로 상태를 공유하여 하나의 응집된 기능을 수행하도록 설계하는 방식입니다 [3, 6]. 부모 컴포넌트에 무수히 많은 프로프를 전달하는 대신, 조립 가능한 하위 컴포넌트들을 유연하게 제공함으로써 Prop Drilling을 효과적으로 방지합니다 [3, 6].

*   **Vue 생태계의 해결 패턴**
    *   **Provide / Inject:** 의존성 주입 시스템을 활용하여 상위 제공자(Provider)에서 깊이 중첩된 소비자(Consumer) 컴포넌트로 데이터나 서비스를 '순간이동(Teleport)' 시키듯 직접 전달합니다 [1]. 이를 통해 중간 컴포넌트들의 코드베이스를 깔끔하고 기능에 집중된 상태로 유지할 수 있습니다 [1].
    *   **중앙 집중식 상태 관리:** 공유 상태를 컴포넌트 외부로 추출하여 전역 싱글톤으로 관리함으로써, 컴포넌트 트리의 위치와 상관없이 상태에 접근하거나 액션을 트리거할 수 있게 하여 Prop Drilling을 근본적으로 방지합니다 [7]. 현재 Vue 생태계에서는 타입 추론이 뛰어나고 보일러플레이트가 적은 Pinia가 이를 위해 적극 권장됩니다 [4, 8, 9].

## ⚠️ 모순 및 업데이트 (Contradictions & Updates)
*   **복합 컴포넌트 및 Context 패턴의 제약사항**
    Prop Drilling을 피하기 위해 복합 컴포넌트 패턴이나 Context를 사용할 경우, 하위 컴포넌트가 부모 Context 범위를 벗어난 곳에서 사용되면 조용한 런타임 오류나 혼란을 초래할 수 있습니다 [10]. 따라서 하위 컴포넌트가 부모 외부에서 사용될 때를 대비해 명확한 에러를 던지도록 가드(Guard) 로직을 구현해야 합니다 [10, 11]. 또한, 프로프를 단순히 전달하는 방식과 비교하여 상태 처리 및 추적 난이도가 상승할 수 있다는 단점이 존재합니다 [12, 13].

*   **의존성 주입(Provide/Inject) 패턴의 이름 충돌 및 상태 흐름 관리**
    대규모 팀에서 Provide/Inject를 사용할 때 주입 키(Injection key)로 단순 문자열을 사용하면 다른 모듈에 의해 실수로 덮어씌워지는 이름 충돌(Naming collisions)이 발생할 수 있습니다 [14]. 이를 방지하려면 고유한 `Symbol`을 사용하는 것이 모범 사례입니다 [14]. 또한, 데이터 흐름의 예측 가능성을 유지하기 위해 하위 컴포넌트가 제공된 값을 임의로 변경하게 두지 말고, 상태와 함께 '설정자(Setter)' 함수를 제공하여 변경 로직을 중앙화해야 합니다 [14].

*   **전역 상태 관리 사용 시의 설계적 부담과 SSR 이슈**
    Prop Drilling을 피하고자 전역 상태(Store)를 도입할 때, 임의의 컴포넌트가 전역 상태를 무분별하게 변경하게 방치하면 장기적인 유지보수성이 심각하게 저하됩니다 [15]. 상태 변경 로직은 명확한 의도를 표현하는 액션(Action) 메서드를 통해 중앙 집중화되어야 합니다 [15]. 특히 SSR(서버 사이드 렌더링) 환경에서는 상태가 싱글톤으로 처리될 경우 여러 요청 간에 상태가 공유되어 데이터가 유출되는 크로스 리퀘스트(Cross-request) 오염 문제가 생길 수 있으므로, Pinia와 같이 요청마다 새로운 인스턴스를 생성하는 구조를 사용해야 합니다 [9, 16].

---
*Last updated: 2026-05-03*

## 📚 Legacy Insights & Additional Context
> [!NOTE]
> Below is content merged from previous versions of this documentation.

## 📌 한 줄 통찰 (The Karpathy Summary)
Prop Drilling(프롭 드릴링)은 React 애플리케이션에서 데이터를 전달하기 위해 중간 단계의 여러 컴포넌트를 거쳐 prop을 하위로 계속 내려보내는 현상을 의미합니다. 이로 인해 컴포넌트에 수많은 prop이 생성되고 '구성 지옥(configuration hell)'이 발생하여 UI의 유연성이 떨어질 수 있습니다 [1, 2]. 이러한 문제를 해결하기 위해 React에서는 [[Context API|Context API]]나 [[Compound Components|Compound Components]] 같은 패턴을 활용하여 프롭 드릴링을 방지합니다 [2, 3].

## 📖 구조화된 지식 (Synthesized Content)
- **Prop-Driven API의 한계**: 컴포넌트 설계 초기에는 prop을 통한 데이터 전달이 문제가 없어 보일 수 있으나, 레이아웃 변경이나 조건부 동작 등 요구사항이 늘어날 때마다 prop이 폭발적으로 증가하게 됩니다 [1]. 이렇게 레이아웃과 동작을 prop에 하드코딩하게 되면, 작은 변경에도 시스템이 무너지기 쉬운 강한 결합(coupling)이 발생합니다 [4].
- **프롭 드릴링 회피를 위한 Compound Components 패턴**: Compound Components 패턴은 관련된 하위 컴포넌트들을 그룹으로 제공하여, 명시적인 프롭 드릴링 없이 암시적으로 상태를 공유할 수 있게 해줍니다 [2]. 예를 들어 Accordion 컴포넌트를 만들 때, 각 하위 요소에 상태를 prop으로 내리지 않아도 구조 자체가 직관적인 API 역할을 합니다 [2].
- **[[React Context|React Context]]의 활용**: 컴포넌트 간의 깊은 프롭 드릴링을 피하고 복합 UI(Compound UIs) 전체에서 공유 상태를 관리하기 위해 내부적으로 React의 Context를 사용합니다 [3, 5]. 이 때 Context는 공개 API가 아닌 내부적인 규약(Internal Contract)으로 사용되며, 소비자는 프롭을 전달하거나 상태를 관리할 필요 없이 컴포넌트를 조합(Composition)하는 데 집중할 수 있습니다 [5-7].
- **조합(Composition) 중심 설계**: 컴포넌트가 어떻게 보여야 하는지 prop으로 전부 지시하는 대신, 컴포넌트에게 상태와 규칙만 부여하고 소비자가 유연하게 레이아웃 구조를 짤 수 있도록 함으로써 프롭 드릴링 문제를 근본적으로 해결할 수 있습니다 [6].

## 🔗 지식 연결 (Graph)
- **Related Topics:** [[Compound Components|Compound Components]], [[React Context|React Context]], Component Composition
- **Projects/Contexts:** 공유 UI 라이브러리 및 디자인 시스템 구축, 확장 가능한 React 컴포넌트 설계
- **Contradictions/Notes:** 제공된 소스에는 Prop Drilling이 발생하는 구체적인 안티 패턴 코드나 깊은 기술적 원리에 대한 정보는 다소 부족하며, 주로 Compound Components와 Context를 활용하여 프롭 드릴링을 '회피'하는 방법과 그 장점 위주로 설명되어 있습니다.

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

## 🤖 LLM 활용 힌트 (How to Use This Knowledge)

**언제 이 지식을 쓰는가:**
- *(TODO)*

**언제 쓰면 안 되는가:**
- *(TODO)*

## 🧪 검증 상태 (Validation)

- **정보 상태:** needs_review
- **출처 신뢰도:** A
- **검토 이유:** *(P-Reinforce Phase 1 자동 정규화. 본문 검증 필요.)*

## 🧬 중복 검사 (Duplicate Check)

- **기존 유사 문서:** *(TODO: 인덱서 클러스터 리포트 참조)*
- **처리 방식:** UPDATE (자동 정규화)
- **처리 이유:** Phase 1 정규화 — 옛 템플릿/누락 필드 보강.

## 🕓 변경 이력 (Changelog)

| 날짜 | 변경 내용 | 처리 방식 | 신뢰도 |
|------|-----------|-----------|--------|
| 2026-05-08 | P-Reinforce Phase 1 정규화 (frontmatter + 헤더 표준화) | UPDATE | A |

## 💻 코드 패턴 (Code Patterns)

**패턴 1:** *(TODO: 이 프로젝트 컨벤션 반영한 구조 스켈레톤)*

```text
# TODO
```

## 🤔 의사결정 기준 (Decision Criteria)

**선택 A를 써야 할 때:**
- *(TODO)*

**선택 B를 써야 할 때:**
- *(TODO)*

**기본값:**
> *(TODO)*

## ❌ 안티패턴 (Anti-Patterns)

- **[안티패턴]:** *(TODO: 무엇을 하면 안 되는가 + 이유 + 대신 무엇을)*