feat: Wiki 지식 자산 업데이트 - UX Scenarios, Frontend, Game Design, Topics 추가 [2026-05-08]
This commit is contained in:
@@ -1,16 +1,29 @@
|
||||
---
|
||||
category: Unified
|
||||
id: wiki-2026-0508-compound-components
|
||||
title: Compound Components
|
||||
category: 10_Wiki/Topics
|
||||
status: needs_review
|
||||
canonical_id: self
|
||||
aliases: []
|
||||
duplicate_of: none
|
||||
source_trust_level: A
|
||||
confidence_score: 0.92
|
||||
tags: [auto-consolidated, technical-documentation]
|
||||
title: [[Compound Components|Compound Components]]
|
||||
last_updated: 2026-05-02
|
||||
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
|
||||
---
|
||||
|
||||
# [[Compound Components|Compound Components]]
|
||||
|
||||
## 📌 Brief Summary
|
||||
## 📌 한 줄 통찰 (The Karpathy Summary)
|
||||
컴파운드 컴포넌트(Compound Components) 패턴은 React에서 부모 컴포넌트와 자식 컴포넌트들이 암묵적인 상태와 동작을 공유하며 하나의 응집된 단위로 함께 작동하도록 하는 설계 패턴이다.[1, 2] 이 패턴을 사용하면 수많은 prop을 전달해야 하는 문제를 피하고, 개발자가 네이티브 HTML 요소를 사용하듯 유연하게 UI를 구성(compose)할 수 있다.[1, 3] 마치 레고 블록처럼 부모 컴포넌트가 기본 구조와 규칙을 제공하고 자식 컴포넌트들을 자유롭게 조립하여 확장 가능한 사용자 인터페이스를 구축할 수 있게 해준다.[4]
|
||||
|
||||
## 📖 Core Content
|
||||
## 📖 구조화된 지식 (Synthesized Content)
|
||||
* **설계 철학 및 멘탈 모델의 전환**
|
||||
* 기존의 Prop 기반(Prop-Driven) API는 요구사항(레이아웃 변경, 조건부 동작 등)이 추가될 때마다 Prop이 폭발적으로 증가하여 유지보수가 어렵고 컴포넌트 내부가 파악하기 힘든 '블랙박스'가 되는 문제가 있습니다 [5-7].
|
||||
* 합성 컴포넌트는 이를 '구성 중심(Composition-Driven)' 모델로 전환하여, 컴포넌트는 상태와 규칙만 관리하고 레이아웃과 구조의 결정권은 이를 사용하는 소비자(Consumer)에게 일임합니다 [7, 8].
|
||||
@@ -38,13 +51,13 @@ last_updated: 2026-05-02
|
||||
- **서브컴포넌트의 캡슐화와 종속성**: 이 패턴에서 생성되는 서브컴포넌트들은 오직 부모 컴포넌트의 컨텍스트 내부에서만 의미를 가진다.[7] 부모 컴포넌트의 범위를 벗어나 독립적으로 존재하거나 사용되지 않는 헬퍼(helper) 컴포넌트로 설계되어 우발적인 오용을 방지하고 코드의 발견성을 높인다.[7]
|
||||
- **주요 적용 대상**: 이 패턴은 드롭다운, 모달, 탭, 테이블 등 자식 컴포넌트가 부모 컴포넌트의 로직에 의존하면서도 다양한 형태의 렌더링이 필요한 복잡한 UI 요소를 개발할 때 빛을 발한다.[2, 8, 9] ShadCN, Material UI, Radix UI와 같은 유명한 디자인 시스템 및 컴포넌트 라이브러리들이 이 패턴을 채택하고 있다.[8]
|
||||
|
||||
## ⚖️ Trade-offs & Caveats
|
||||
## ⚠️ 모순 및 업데이트 (Contradictions & Updates)
|
||||
컴파운드 컴포넌트 패턴은 직관적이고 커스터마이징하기 쉬운 복잡한 API를 구축하는 데 훌륭한 장점을 제공하지만, 몇 가지 명확한 단점과 제약 사항이 존재한다.[10]
|
||||
- **상태 관리의 복잡성 증가**: 여러 컴포넌트가 상태를 공유해야 하므로 내부적인 상태 처리 로직이 단일 컴포넌트 구조보다 다소 복잡해질 수 있다.[11]
|
||||
- **서브컴포넌트의 오용 위험**: 서브컴포넌트는 부모 컴포넌트와 의미론적(semantically)으로 연결되어야 하므로 무작위로 부착해서는 안 된다.[12] 특히 서브컴포넌트만을 개별적으로 재수출(re-export)하는 것을 피해야 한다.[12] 만약 부모 컴포넌트의 컨텍스트 내에서 변경 사항이 생겼을 때, 개별 서브컴포넌트만 사용하는 소비자(consumer)가 이를 인지하지 못하면 치명적인 오류가 발생할 수 있다.[12]
|
||||
- **과도한 패턴 적용(Over-engineering) 경계**: 애플리케이션의 모든 컴포넌트를 컴파운드 컴포넌트 패턴으로 만들려고 시도해서는 안 된다.[12] 자식 컴포넌트의 렌더링 구조가 중요하고 소비자에게 유연성을 제공해야 하는 상황에서만 선택적으로 적용하는 것이 권장된다.[12]
|
||||
|
||||
## 🔗 Knowledge Connections
|
||||
## 🔗 지식 연결 (Graph)
|
||||
- **Related Topics:** [[Render Props|Render Props]], Headless Components, Context API, [[Atomic Design|Atomic Design]]
|
||||
- **Projects/Contexts:** [[Radix UI|Radix UI]], Headless UI, [[MUI|MUI]]
|
||||
- **Contradictions/Notes:** 합성 컴포넌트는 매우 유연하고 강력한 패턴이지만, 하위 컴포넌트의 구성을 소비자가 자유롭게 바꿀 수 있기 때문에 의도치 않게 접근성이나 일관된 UX를 해칠 수 있습니다. 따라서 디자인 시스템에서는 안전한 조합의 경계(Safe composition [[Boundaries|Boundaries]])를 정의하고 문서화하는 것이 필수적입니다 [15, 17]. 또한 단순하고 고정된 레이아웃을 가진 컴포넌트에서는 일반적인 Prop 기반 접근법이 훨씬 간단하고 안전합니다 [16].
|
||||
@@ -95,4 +108,53 @@ last_updated: 2026-05-02
|
||||
|
||||
|
||||
## 📌Brief 단기 요약
|
||||
합성 컴포넌트(Compound Components)는 여러 개의 연관된 하위 컴포넌트들이 암시적으로 상태를 공유하며 하나의 응집력 있는 단위로 동작하도록 설계하는 React 컴포넌트 패턴입니다 [1, 2]. 단일 컴포넌트에 수십 개의 Prop을 밀어 넣어 비대해지는 것을 방지하고, 기능과 책임을 여러 컴포넌트에 분산시킵니다 [3, 4]. 이는 HTML의 `<select>`와 `<option>` 태그처럼 직관적이고 선언적인 API를 형성하여 뛰어난 유연성과 재사용성을 제공합니다 [1, 4].
|
||||
합성 컴포넌트(Compound Components)는 여러 개의 연관된 하위 컴포넌트들이 암시적으로 상태를 공유하며 하나의 응집력 있는 단위로 동작하도록 설계하는 React 컴포넌트 패턴입니다 [1, 2]. 단일 컴포넌트에 수십 개의 Prop을 밀어 넣어 비대해지는 것을 방지하고, 기능과 책임을 여러 컴포넌트에 분산시킵니다 [3, 4]. 이는 HTML의 `<select>`와 `<option>` 태그처럼 직관적이고 선언적인 API를 형성하여 뛰어난 유연성과 재사용성을 제공합니다 [1, 4].
|
||||
|
||||
## 🤖 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: 무엇을 하면 안 되는가 + 이유 + 대신 무엇을)*
|
||||
Reference in New Issue
Block a user