bluemsi/2nd
1
0
Fork 0
Code Issues Pull Requests Actions Packages Projects Releases Wiki Activity
Files
5d4f85424e386a02e7c70d1d69af0b836e7479f3
2nd/10_Wiki/Topics/소프트웨어_설계_원칙_및_디자인_패턴.md
T

7.4 KiB
Raw Blame History

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

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

📌 한 줄 통찰 (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)

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

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

🔗 지식 연결 (Graph)

🕓 변경 이력 (Changelog)

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

💻 코드 패턴 (Code Patterns)

패턴 1: (TODO: 이 프로젝트 컨벤션 반영한 구조 스켈레톤)

# TODO

🤔 의사결정 기준 (Decision Criteria)

선택 A를 써야 할 때:

  • (TODO)

선택 B를 써야 할 때:

  • (TODO)

기본값:

(TODO)

❌ 안티패턴 (Anti-Patterns)

  • [안티패턴]: (TODO: 무엇을 하면 안 되는가 + 이유 + 대신 무엇을)
Reference in New Issue View Git Blame Copy Permalink