---
id: wiki-2026-0508-open-closed-principle-ocp
title: Open Closed Principle (OCP)
category: 10_Wiki/Topics
status: needs_review
canonical_id: self
aliases: []
duplicate_of: none
source_trust_level: A
confidence_score: 0.92
tags: [uncategorized]
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
---

## 📌 한 줄 통찰 (The Karpathy Summary)
개방-폐쇄 원칙(Open/Closed Principle, OCP)은 소프트웨어 개체(클래스, 모듈, 함수 등)가 **확장에는 열려 있어야 하고, 수정에는 닫혀 있어야 한다**는 설계 원칙이다. 이는 기존 소스 코드를 변경하지 않고도 시스템의 기능을 확장할 수 있어야 함을 의미하며, React에서는 컴포넌트 합성(Composition)과 주입 패턴을 통해 이를 실현한다.

## 📖 구조화된 지식 (Synthesized Content)
1. **확장성과 폐쇄성 (Open & Closed)**
   - 신규 기능 추가 시 기존 코드를 건드리지 않음으로써 의도치 않은 버그 발생(Side Effects)을 원천 차단한다.
   - 기존 기능의 안정성을 유지하면서도 변화하는 요구사항에 유연하게 대응하는 것이 핵심 목적이다.
2. **React에서의 구현: 컴포넌트 합성 (Composition)**
   - 상속이 아닌 합성을 권장하는 React의 특성에 따라, `children` prop을 활용하여 외부에서 렌더링 내용을 주입받는 방식으로 확장성을 확보한다.
   - 예: 기본 Modal 컴포넌트를 수정하지 않고, 내부 콘텐츠를 `children`으로 전달하여 다양한 형태의 모달로 확장.
3. **Render Props 및 Slot 패턴**
   - 구체적인 로직이나 UI 조각을 함수나 객체 형태로 주입받아 컴포넌트 내부 소스 코드의 수정 없이 동작을 변경한다.
4. **선언적 추상화**
   - 조건문(`if/else`)을 통해 컴포넌트 내부에서 모든 케이스를 처리하는 대신, 외부에서 주입된 컴포넌트가 각자의 책임을 다하도록 설계한다.

## ⚠️ 모순 및 업데이트 (Contradictions & Updates)
- **추상화 오버헤드**: OCP를 엄격히 지키기 위해 모든 컴포넌트를 합성 구조로 만들면, 컴포넌트 트리가 깊어지고 `props` 전달 경로가 복잡해지는 'Prop Drilling'이나 인지적 부하가 발생할 수 있다.
- **KISS 원칙과의 충돌**: 단순한 기능 추가를 위해 복잡한 Render Props나 고차 컴포넌트(HOC)를 도입하는 것은 'Keep It Simple' 원칙에 어긋날 수 있으므로 적절한 균형이 필요하다.
- **초기 설계 비용**: 확장을 고려한 인터페이스 설계는 초기 개발 시간을 더 많이 소요하게 만들며, 미래에 발생하지 않을 확장을 대비하는 YAGNI 위반 가능성이 존재한다.

## 🔗 지식 연결 (Graph)
### Related Concepts (Auto-Linked)
* [[CSS-in-JS]]
* [[Inversion]]
* [[Principles]]
* [[Prop Drilling]]
* [[Render_Props]]
* [[Research]]
* [[SOLID_Principles]]
* [[Strategy]]

### Related Concepts
- **Component Composition**: OCP를 실현하는 React의 핵심 기술 (관계: 실천 방법)
- **SOLID Principles**: OCP를 포함한 5대 설계 원칙 (관계: 상위 철학)
- **Render Props / Children Prop**: 기능 주입을 위한 구체적 API (관계: 구현 도구)

### Deeper Research Questions
1. 컴포넌트 합성을 통해 OCP를 준수할 때, 깊은 트리에 의한 리렌더링 성능 저하를 방지하기 위한 메모이제이션 전략은?
2. 함수형 패러다임에서 'Dependency Injection' 개념이 OCP 구현에 어떻게 적용되는가?
3. 수백 개의 조건부 UI가 필요한 엔터프라이즈 환경에서 OCP를 지키기 위한 'Strategy Pattern'의 프론트엔드적 해석은?
4. 코드 수정 없이 확장만 허용하는 원칙이 대규모 리팩토링이나 기술 스택 교체 시에는 어떻게 유연하게 적용되어야 하는가?
5. CSS-in-JS 환경에서 스타일 확장을 OCP 관점에서 설계하는 모범 사례는?

### Practical Application Contexts
- **UI 라이브러리 설계**: 공통 버튼, 모달, 테이블 컴포넌트 제작 시 스타일과 동작을 외부에서 주입 가능하도록 설계.
- **복잡한 폼(Form) 엔진**: 새로운 입력 타입이 추가되어도 메인 폼 로직을 수정할 필요 없는 플러그인 방식 구조 구축.

### Adjacent Topics
- **Single Responsibility Principle (SRP)**
- **KISS (Keep It Simple, Stupid)**
- **Inversion of Control (IoC)**

## 🤖 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: 무엇을 하면 안 되는가 + 이유 + 대신 무엇을)*