---
id: P-REINFORCE-AUTO-4772F3
category: "[[10_Wiki/💡 Topics/Programming & Language]]"
confidence_score: 0.90
tags: [auto-reinforced]
last_reinforced: 2026-04-20
github_commit: "[P-Reinforce] Continuous Worker - 객체 지향 프로그래밍 (OOP)"
---

# [[객체 지향 프로그래밍 (OOP)]]

## 📌 한 줄 통찰 (The Karpathy Summary)
> 객체 지향 프로그래밍(OOP)은 데이터와 그 데이터를 다루는 동작(behavior)을 객체(object)라는 단위 안에 캡슐화하여 소프트웨어의 복잡성을 관리하는 프로그래밍 패러다임입니다 [1, 2]. 클래스와 상속 구조를 통해 코드 중복을 방지하고 재사용성을 높일 수 있습니다 [3]. 주로 단일 책임 원칙(SRP)을 포함한 SOLID 설계 원칙과 함께 적용되어 유지보수가 용이하고 유연한 소프트웨어 아키텍처를 구축하는 데 핵심적인 역할을 합니다 [1, 4].

## 📖 구조화된 지식 (Synthesized Content)
- **캡슐화와 관심사의 분리 (Encapsulation & SoC):** 1980년대에 본격적으로 부상한 OOP 패러다임은 데이터와 행동을 객체 내에 캡슐화하는 아이디어를 도입했습니다 [1]. 각 객체에 특정한 기능이나 관심사에 대한 책임을 부여함으로써, 시스템 구조 내에서 자연스럽게 '관심사의 분리(Separation of Concerns)'를 이끌어냈습니다 [2].
- **클래스 상속(Inheritance)과 코드 재사용:** OOP에서는 여러 클래스가 공통으로 공유하는 속성이나 동작을 하나의 기본 클래스(base class)에 배치할 수 있습니다 [3]. 다른 클래스들은 이 기본 클래스를 상속받아 기능을 이어받으므로, 코드를 중복해서 다시 정의할 필요 없이 DRY(Don't Repeat Yourself) 원칙을 효과적으로 달성할 수 있습니다 [3].
- **SOLID 설계 원칙 기반:** 소프트웨어 설계를 더 이해하기 쉽고, 유연하며, 유지보수 가능하게 만들기 위해 고안된 5가지 기본 원칙인 SOLID 원칙의 토대가 됩니다 [4]. 특히 객체와 클래스가 단 하나의 책임만 가져야 한다는 단일 책임 원칙(SRP)은 OOP의 핵심 철학을 뒷받침합니다 [1, 5].
- **구조적 한계 및 AOP를 통한 보완:** OOP 접근 방식을 따르면 기능 단위의 수직적 분리와 객체 간 책임 분리가 원활하게 이루어집니다 [6, 7]. 하지만 로깅이나 보안과 같이 시스템 전체에 흩어져 공통으로 사용되는 '횡단 관심사(Cross-Cutting Concerns)'를 모듈화하는 데에는 한계가 존재합니다 [6]. 이러한 OOP의 단점은 횡단 관심사를 수평적으로 분리해 모듈화하는 관점 지향 프로그래밍(AOP) 기술을 결합함으로써 보완할 수 있습니다 [6, 7].

## ⚠️ 모순 및 업데이트 (Contradictions & RL Update)
- **과거 데이터와의 충돌:** 자동화 엔진에 의해 매핑된 지식으로, 추후 정밀 검증 필요.
- **정책 변화:** Programming & Language 분야의 자동 자산화 수행.

## 🔗 지식 연결 (Graph)
- **Related Topics:** [[관심사의 분리 (SoC)]], [[SOLID 원칙]], [[관점 지향 프로그래밍 (AOP)]]
- **Projects/Contexts:** [[소프트웨어 시스템 설계 및 아키텍처 구축]]
- **Contradictions/Notes:** 소스에 따르면 OOP는 객체 간 책임을 분리하고 기능 단위의 수직적 분리를 달성하는 데 탁월하지만, 시스템 전반에 걸친 공통 기능(횡단 관심사)을 분리하는 데는 단점이 존재하며 이는 AOP 방식을 통해 반대/보완적으로 해결될 수 있다고 설명합니다 [6, 7].

---
*Last updated: 2026-04-18*
- Raw Source: [[00_Raw/2026-04-20/객체 지향 프로그래밍 (OOP).md]]
---
