🧩 Design Pattern이란?

Design Pattern은 소프트웨어 설계에서 반복해서 등장하는 문제를 해결하는 검증된 설계 방식이다.
한마디로 말하면,

“이 상황에서는 보통 이렇게 설계하면 코드가 덜 망가진다”라는 경험의 축적이다.

---

🧠 왜 이름이 Design + Pattern일까?

단어	의미
Design	설계
Pattern	반복되는 형태

즉, Design Pattern은
“반복적으로 발생하는 설계 문제에 대한 재사용 가능한 설계 템플릿”이다.

코드 한 줄의 문제가 아니라,
구조 · 책임 분리 · 확장성에 대한 이야기다.

---

🚨 패턴 없이 개발하면 생기는 문제

알림 시스템을 예로 들어보자.

• 처음엔 이메일 알림만 필요함
• → SMS 추가
• → 카카오톡 추가
• → 슬랙 추가
• → “사용자가 원하는 알림만 선택 가능하게 해주세요”

이 요구사항을 패턴 없이 처리하면 보통 이런 상태가 된다.

Order 클래스
 ├─ 이메일 발송 코드
 ├─ SMS 발송 코드
 ├─ 카카오 발송 코드
 ├─ 슬랙 발송 코드
 ├─ if 문 폭발
 └─ 생성자 파라미터 폭발

💥 이 구조의 치명적인 문제

문제	설명
수정의 연쇄 반응	알림 하나 추가할 때마다 Order 클래스 수정
테스트 지옥	이메일만 테스트해도 전체 클래스 필요
재사용 불가	SMS 기능만 떼어서 쓸 수 없음
책임 과다	Order가 너무 많은 역할을 가짐

👉 확장 불가능한 구조가 됨.

---

✨ Design Pattern 적용: Observer Pattern

Observer Pattern의 핵심은 문법이나 클래스 구조가 아니다.
“책임을 어디까지 알게 할 것인가”에 대한 사고방식의 전환이다.

“변화가 발생했을 때,
그 변화를 알아야 하는 대상들에게만 자동으로 알려주자”

---

❌ 패턴 도입 전: 왜 코드가 지옥이 되는가

디자인 패턴이 없을 때, 대부분의 코드는 이렇게 시작한다.

• Order가 이메일을 직접 보낸다
• Order가 SMS도 직접 보낸다
• Order가 카카오톡, 슬랙, 푸시 알림까지 전부 안다

즉, Order 클래스 하나가 모든 알림 방식을 “다 알고” 있다.

Order
 ├─ 이메일 발송 코드
 ├─ SMS 발송 코드
 ├─ 카카오톡 발송 코드
 ├─ 슬랙 발송 코드
 └─ 조건문 (use_email, use_sms, use_kakao, ...)

이 구조의 진짜 문제는 단순히 코드가 길다는 게 아니다.

• 🔧 알림 하나 추가 → Order 클래스 수정
• 🧪 이메일만 테스트하고 싶어도 Order 전체 필요
• ♻️ SMS 기능만 다른 프로젝트에서 재사용 불가

즉, “변경”이 Order를 계속 망가뜨린다.

---

✅ 패턴 도입 후

Observer Pattern을 적용하면 질문 자체가 바뀐다.

“Order가 알림을 어떻게 보내야 하지?” ❌
“누가 이 변화를 알아야 하지?” ✅

Order는 이제 알림 방식이 무엇인지 전혀 모른다.
그저“관심 있는 대상 목록”만 관리한다.

📐 구조 개념 (Observer Pattern)

        ┌──────────────┐
        │    Order     │
        │  (Subject)   │
        └──────┬───────┘
               │ notify()
        ┌──────┴────────────────┐
        │        Observers      │
        │  (send() 규칙만 공유)    │
        │                       │
  ┌────────────┐        ┌────────────┐
  │   Email    │        │   Kakao    │
  │ Notifier   │        │ Notifier   │
  └────────────┘        └────────────┘

• Order는 send()가 있다는 사실만 안다
• 각 알림은 자기 방식대로만 구현한다
• 새 알림 추가 시 Order 수정 ❌

---

🔥 변화 포인트

구분	패턴 미적용	Observer Pattern 적용
새 알림 추가	Order 내부 수정	새 클래스 추가만
Order 책임	주문 + 알림 전부	주문만 담당
테스트	전체 클래스 필요	알림 단위 테스트 가능
확장성	요구사항 추가가 공포	요구사항 추가가 일상

---

🧠 핵심 정리

• Observer Pattern은 알림 패턴이 아니다
• 변경되는 대상과, 그 변화를 소비하는 대상을 분리하는 패턴이다
• “누가 누구를 알아야 하는가”를 끊어내는 설계다

그래서 Design Pattern은 코드를 예쁘게 만드는 기술이 아니라,
미래의 변경 비용을 줄이기 위한 보험이다.

패턴을 외우는 것보다,
“이 코드에서 변경이 어디로 전파되는가?”를 먼저 보자.

🔍 패턴 적용 후 달라지는 점

Before	After
기능 추가 = 기존 코드 수정	기능 추가 = 클래스 추가
Order가 모든 걸 앎	Order는 알림을 모름
if 문 폭탄	다형성 활용
테스트 어려움	개별 테스트 가능

👉 이게 바로 확장에는 열려 있고, 수정에는 닫혀 있는 구조
(OCP: Open-Closed Principle)다.

---

🧠 Design Pattern을 대하는 올바른 자세

• ❌ 패턴 이름 외우기
• ❌ 무조건 패턴 적용하기

대신 이렇게 생각해야 한다.

“이 코드가 왜 점점 수정하기 어려워질까?”
“책임이 한 곳에 몰려 있지 않은가?”

패턴은 목적이 아니라 수단이다.
문제가 보일 때, 해결책으로 꺼내 쓰는 도구다.

---

📚 자주 등장하는 Design Pattern

패턴	핵심 개념
Singleton	시스템 전체에서 하나만 존재하는 객체
Factory	객체 생성을 한 곳에서 책임짐
Observer	상태 변화 알림 구조
Strategy	알고리즘을 교체 가능하게 분리
Decorator	기능을 덧붙이는 구조

---

✅ 정리

• Design Pattern은 경험이 축적된 설계 해법
• 코드를 “돌아가게” 만드는 기술이 아님
• 코드를 오래 살게 만드는 기술
• 패턴보다 중요한 건 문제 인식 능력

패턴은 외우는 게 아니라,
“아, 이 상황이구나” 하고 떠올리는 순간에 의미가 있다.