---
id: "wiki-2026-0507-102"
title: "소프트웨어_설계_원칙_및_디자인_패턴"
category: "[[10_Wiki/Topics]]"
status: "verified"
canonical_id: "self"
aliases: ["Software Design Principles", "Design Patterns", "SOLID", "DRY", "KISS", "YAGNI", "GoF Patterns", "디자인 패턴", "설계 원칙", "클린 코드"]
duplicate_of: "none"
source_trust_level: "A"
confidence_score: 1.0
tags: ["Programming", "Software Engineering", "Design Patterns", "SOLID", "Clean Code"]
raw_sources: ["SOLID_Principles.md", "Design_Patterns.md", "DRY_Principle.md", "Clean Code.md"]
last_reinforced: "2026-05-07"
github_commit: "pending"
---

# 소프트웨어_설계_원칙_및_디자인_패턴

## 📌 한 줄 통찰 (The Karpathy Summary)
> "코드는 한 번 작성되지만 수만 번 읽힌다." 인간의 인지 한계를 극복하고 변화의 파동을 국소화하기 위해, 검증된 구조(Design Patterns)와 엄격한 규율(SOLID/Clean Code)을 적용하여 '읽기 쉽고 고치기 쉬운' 생태계를 구축하는 지침서.

---

## 📖 구조화된 지식 (Synthesized Content)

**추출된 패턴:**
> 설계의 본질은 **'추상화'**와 **'결합도 관리'**에 있다. SOLID 원칙이 클래스 레벨의 올바른 의존성 방향을 제시한다면, 디자인 패턴은 반복되는 문제 상황에 대한 검증된 구조적 해답을 제공한다. 이 둘의 조화는 시스템의 부패를 막는 가장 강력한 방어선이다.

**세부 내용:**

### 1. 5대 핵심 설계 원칙: SOLID
- **SRP (단일 책임 원칙):** 클래스는 단 하나의 변경 이유만 가져야 함. 책임이 명확하면 테스트와 재사용이 용이함.
- **OCP (개방-폐쇄 원칙):** 확장에는 열려 있고 수정에는 닫혀 있어야 함. 인터페이스와 다형성을 활용하여 기존 코드를 건드리지 않고 기능을 추가.
- **LSP (리스코프 치환 원칙):** 서브타입은 언제나 기반 타입으로 교체 가능해야 함. 상속 관계에서 부모의 계약을 어기지 않는 일관성 보장.
- **ISP (인터페이스 분리 원칙):** 클라이언트가 사용하지 않는 메서드에 의존하지 않도록 거대 인터페이스를 구체적인 여러 개로 분리.
- **DIP (의존성 역전 원칙):** 고수준 모듈은 저수준 모듈의 구현이 아닌 추상화(Interface)에 의존해야 함.

### 2. 주요 디자인 패턴 (GoF 기반)
- **생성 패턴 (Creational):** 객체 생성 과정을 추상화.
  - **Singleton:** 인스턴스를 하나만 생성하고 전역 접근 제공.
  - **Factory Method:** 객체 생성을 서브클래스에 위임.
  - **Builder:** 복잡한 객체 생성을 단계별로 분리.
- **구조 패턴 (Structural):** 클래스/객체 조합을 통한 더 큰 구조 형성.
  - **Adapter:** 서로 다른 인터페이스를 연결하는 중개자.
  - **Decorator:** 객체에 동적으로 새로운 책임을 추가.
  - **Facade:** 복잡한 서브시스템에 대한 단순화된 인터페이스 제공.
- **행위 패턴 (Behavioral):** 객체 간의 책임 할당과 알고리즘 교류.
  - **Observer:** 상태 변화를 관찰자들에게 통지.
  - **Strategy:** 런타임에 알고리즘을 교체 가능하게 함.
  - **Command:** 요청을 객체로 캡슐화하여 매개변수화 및 취소 지원.

### 3. 실용적 설계 원칙 (KISS, DRY, YAGNI)
- **DRY (Don't Repeat Yourself):** 지식의 중복을 배제. 모든 정보는 시스템 내에서 단일하고 권위 있는 표현을 가져야 함.
- **KISS (Keep It Simple, Stupid):** 항상 단순함을 지향. 오버엔지니어링은 유지보수의 적임.
- **YAGNI (You Aren't Gonna Need It):** 실제로 필요하기 전까지는 미래를 대비한 기능을 미리 구현하지 않음.

---

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

**언제 이 지식을 쓰는가:**
- 신규 모듈을 설계하거나 기존 스파게티 코드를 리팩토링할 포인트가 필요할 때.
- 코드 리뷰 시 "왜 이 코드가 나쁜지"에 대한 논리적 근거를 제시해야 할 때.
- 인터페이스 기반의 확장성 있는 라이브러리나 SDK를 개발할 때.

**언제 이 지식을 쓰면 안 되는가:**
- 극도의 성능 최적화가 필요한 하위 레벨 시스템 (추상화 오버헤드가 문제가 될 수 있음).
- 수명이 매우 짧은 일회성 스크립트나 실험적 코드.

**이 지식을 적용할 때의 권장 절차:**
1. **문제 식별:** 중복 코드(DRY 위반)나 거대 클래스(SRP 위반) 등 악취(Code Smell) 탐지.
2. **패턴 매칭:** 현재 상황에 적합한 디자인 패턴(예: 조건문이 너무 많으면 Strategy 패턴) 선정.
3. **추상화:** 인터페이스를 먼저 정의하고 클라이언트 코드를 작성.
4. **구현:** SOLID 원칙을 준수하며 구체 클래스 구현.
5. **검증:** 단위 테스트를 통해 각 컴포넌트가 독립적으로 작동하는지 확인.

**주의사항 또는 알려진 한계:**
- **디자인 패턴 남용:** 모든 문제에 패턴을 적용하려다 오히려 구조가 더 복잡해지는 '패턴 중독' 주의. 단순함(KISS)이 최우선임.
- **추상화 비용:** 인터페이스 증가로 인해 코드 탐색이 어려워질 수 있으므로 적절한 수준에서 타협 필요.

---

## 🧪 검증 상태 (Validation)

- **정보 상태:** verified
- **출처 신뢰도:** A
- **검토 이유:** GoF, SOLID 등 검증된 소프트웨어 공학 표준을 기반으로 통합됨.

---

## 🧬 중복 검사 (Duplicate Check)

- **기존 유사 문서:** [[SOLID_Principles]], [[Design_Patterns]], [[DRY_Principle]], [[Clean Code]], [[Singleton Pattern]], [[Observer Pattern]] 등 150여 개
- **처리 방식:** MERGE & ARCHIVE
- **처리 이유:** 개별 원칙과 패턴들이 낱개 문서로 흩어져 있어 전체적인 맥락 파악이 어려움. 이를 '설계 체계'라는 하나의 마스터 문서로 통합하여 활용성을 극대화함.

---

## ⚠️ 모순 및 업데이트 (Contradictions & Updates)

- **상속보다는 합성 (Composition over Inheritance):** 과거에는 상속(LSP)을 강조했으나, 현대 설계는 유연성을 위해 합성을 우선시함.
- **함수형 프로그래밍의 영향:** 상태를 가진 객체 패턴보다 순수 함수와 불변성을 활용한 패턴 비중 확대 중.

---

## 🔗 지식 연결 (Graph)

- **Parent:** [[10_Wiki/Topics]]
- **Related:** [[도메인_주도_설계(DDD)_및_소프트웨어_아키텍처]], [[테스트_전략_및_방법론]], [[프론트엔드_및_Nodejs_개발_워크플로우]]
- **Raw Source:** Architecture 및 Programming 폴더 내 다수 파일

---

## 🕓 변경 이력 (Changelog)

| 날짜 | 변경 내용 | 처리 방식 | 신뢰도 |
|------|-----------|-----------|--------|
| 2026-05-07 | 150개 이상의 설계 원칙/디자인 패턴 관련 문서 통합 및 v3.0 규격 적용 | MERGE | A |