2nd/10_Wiki/Topics_Dev/Design_Patterns.md

---
id: P-REINFORCE-WIKI-DEV-DESIGN-PATTERNS
title: "디자인 패턴과 객체 지향 설계 템플릿 (Design Patterns)"
category: "10_Wiki/💻 Topics_Dev"
status: verified
canonical_id: ""
aliases: ["디자인 패턴", "Design Patterns", "생성 패턴", "구조 패턴", "행위 패턴"]
duplicate_of: ""
source_trust_level: A
confidence_score: 1.0
tags: ["Design_Patterns", "OOP", "Refactoring", "Code_Quality", "Software_Design"]
raw_sources: ["Datacollector_Export_2026-05-02"]
last_reinforced: 2026-05-02
github_commit: ""
---

# [[디자인 패턴과 객체 지향 설계 템플릿 (Design Patterns)]]

## 1. 개요
디자인 패턴은 소프트웨어 설계 과정에서 반복적으로 발생하는 문제들에 대해 검증된 공통의 해결책이자 설계 템플릿이다. 이는 특정 코드를 그대로 복사하는 것이 아니라, 문제를 해결하기 위해 자신의 상황에 맞춰 커스터마이징할 수 있는 일반적인 청사진을 제공한다. 개발 팀 내에서는 디자인 패턴을 통해 복잡한 설계 의도를 단일 용어로 소통할 수 있는 강력한 '공통 언어'로 활용한다.

## 2. 주요 분류 체계 (GoF 기반)
- **생성 패턴 (Creational Patterns)**: 객체의 생성 메커니즘을 추상화하여 시스템을 유연하게 만드는 패턴.
  - *예: 싱글톤(Singleton), 팩토리 메서드(Factory Method), 빌더(Builder), 추상 팩토리(Abstract Factory).*
- **구조 패턴 (Structural Patterns)**: 클래스나 객체를 조합하여 더 큰 구조를 형성하고 결합도를 낮추는 패턴.
  - *예: 어댑터(Adapter), 퍼사드(Facade), 데코레이터(Decorator), 프록시(Proxy), 컴포지트(Composite).*
- **행위 패턴 (Behavioral Patterns)**: 객체 간의 책임 분산과 알고리즘의 통신 방식을 정의하는 패턴.
  - *예: 옵저버(Observer), 전략(Strategy), 커맨드(Command), 상태(State), 템플릿 메서드(Template Method).*

## 3. 엔지니어링 가치
- **코드 독해 가속화**: 낯선 코드베이스에서 `Strategy`나 `Facade`와 같은 패턴 명칭을 발견하는 즉시 해당 클래스의 역할과 상호작용 방식을 추론할 수 있어 인지적 부하 급감.
- **유지보수성 향상**: 결합도는 낮추고 응집도는 높이는 검증된 구조를 적용함으로써, 요구사항 변경 시 기존 코드의 수정을 최소화하고 안전하게 확장 가능.
- **검증된 설계 자산**: 수십 년간 엔지니어링 커뮤니티에서 검증된 최적의 구조를 재사용함으로써 설계 오류와 시행착오를 대폭 줄임.

## 4. 트레이드오프 및 주의사항
- **오버엔지니어링의 위험**: 단순한 문제에 복잡한 패턴을 억지로 끼워 맞추는 행위는 오히려 코드의 가독성을 해치고 불필요한 추상화 계층만 늘릴 수 있음 (패턴 지상주의 경계).
- **언어적 한계와 패턴의 소멸**: 현대적인 프로그래밍 언어들은 과거 디자인 패턴으로 해결하던 많은 문제를 언어 자체의 기능(함수형 프로그래밍, 일급 객체 등)으로 내재화하고 있어, 패턴의 필요성을 비판적으로 검토해야 함.
- **코드 중복과 변질**: 패턴을 기계적으로 적용하다 보면 유사한 구조의 코드가 반복될 수 있으며, 시간이 흐름에 따라 초기 의도와 다르게 변질된 패턴은 기술적 부채가 됨.

## 5. 지식 연결 (Related)
- [[Architecture_Styles]]: 디자인 패턴이 적용되는 더 큰 규모의 시스템 구조.
- [[SOLID_Principles]]: 디자인 패턴의 근간이 되는 객체 지향 설계의 5대 원칙.
- [[Code_Smells]]: 패턴이 잘못 적용되었거나 해체가 필요한 징후들.

## 🧪 검증 상태 (Validation)
- **정보 상태**: 검증 완료 (Verified)
- **출처 신뢰도**: A
- **검토 이유**: 소프트웨어의 미시적 구조를 체계화하고 팀 간의 설계 의사소통 효율을 극대화하기 위한 객체 지향 설계 표준 정립.