141. 디자인 패턴 개요 (Design Pattern Overview)

핵심 인사이트 (3줄 요약)

본질: 디자인 패턴 (Design Pattern)은 객체지향 설계에서 반복되는 문제를 이름·구조·의도로 정리한 재사용 가능한 해법 템플릿이다.

가치: 팀이 같은 어휘로 설계 의도를 공유하고, 결합도·중복·변경 파급을 줄이는 구조적 기준을 제공한다.

판단 포인트: 패턴은 외워서 붙이는 장식이 아니라 변화 원인과 협력 구조가 반복될 때 선택하는 설계 도구다.

Ⅰ. 개요 및 필요성

GoF (Gang of Four) 이전에도 좋은 설계 관행은 있었지만, 문제는 좋은 구조를 어떻게 반복 가능하게 공유하느냐였다. 프로젝트마다 비슷한 결합도 문제, 객체 생성 문제, 역할 분배 문제가 다시 나타났고, 경험 많은 설계자들은 이를 패턴이라는 이름으로 추상화했다.

┌──────────────────────────────────────────────────────────────────────┐
│                  반복 문제와 패턴의 등장 배경                        │
├──────────────────────────────────────────────────────────────────────┤
│ 요구사항 변화 ──▶ 임시 수정 누적 ──▶ 클래스 얽힘 ──▶ 유지보수 비용 증가 │
│        │                                                           │
│        └────────────▶ 경험 추상화 ──▶ 패턴 이름 ──▶ 재사용 가능한 해법 │
│                                   │                                │
│                                   └──▶ 팀 공통 언어 형성           │
└──────────────────────────────────────────────────────────────────────┘

디자인 패턴이 필요한 이유는 세 가지다. 첫째, 반복 문제를 매번 새로 풀지 않기 위해서다. 둘째, 클래스 간 결합을 제어하기 위해서다. 셋째, 설계 의도를 이름으로 전달하기 위해서다. 그래서 패턴은 코드 조각보다 언제 왜 이 구조를 쓰는가를 설명하는 문법에 가깝다.

📢 섹션 요약 비유: 디자인 패턴은 장인이 혼자만 알던 목공 비법을 표준 도면으로 바꿔, 누구나 같은 품질의 가구를 만들게 하는 것과 같다.

Ⅱ. 아키텍처 및 핵심 원리

디자인 패턴은 보통 네 가지 요소로 읽는다: 이름(Name), 문제(Problem), 해결책(Solution), 결과(Consequences). 이 네 요소가 있어야 패턴이 단순 구현 팁이 아니라 구조적 의사결정 문서가 된다. GoF는 이를 생성(Creational), 구조(Structural), 행위(Behavioral) 세 범주로 정리했다.

┌──────────────────────────────────────────────────────────────────────┐
│                   디자인 패턴의 기본 해석 프레임                     │
├──────────────────────────────────────────────────────────────────────┤
│ Name ───────▶ 패턴을 부르는 공통 어휘                              │
│ Problem ────▶ 어떤 반복 문제에서 쓰는가                            │
│ Solution ───▶ 객체/클래스 책임을 어떻게 배치하는가                  │
│ Consequence▶ 유연성, 복잡도, 성능의 트레이드오프는 무엇인가         │
│                                                                      │
│               ┌──────────────┬──────────────┬──────────────┐         │
│               │ 생성 패턴     │ 구조 패턴     │ 행위 패턴     │         │
│               │ create        │ compose      │ interact     │         │
│               └──────────────┴──────────────┴──────────────┘         │
└──────────────────────────────────────────────────────────────────────┘

구성 요소	의미	실무 해석
Name	패턴을 식별하는 이름	리뷰·문서·대화에서 설계 의도를 빠르게 공유
Problem	적용 맥락과 제약	현재 문제가 반복적이며 구조적 문제인지 확인
Solution	책임 분배와 협력 구조	클래스 관계와 의존 방향을 설계 기준으로 삼음
Consequences	장단점과 비용	복잡도 증가를 감수할 만큼 효과가 있는지 판단

패턴의 핵심은 구현 상세가 아니라 변화 지점을 분리하는 구조에 있다. 같은 인터페이스와 합성 구조라도, 어떤 변화를 격리하려는지에 따라 전혀 다른 패턴이 된다.

📢 섹션 요약 비유: 패턴 해석 프레임은 요리 레시피의 이름, 재료, 조리법, 맛의 특징을 함께 보는 것과 같아서, 메뉴 이름만 따라 하는 실수를 막아 준다.

Ⅲ. 비교 및 연결

디자인 패턴은 설계 원칙, 프레임워크, 아키텍처 패턴과 자주 혼동된다. 하지만 이들은 초점과 적용 범위가 다르다. 디자인 패턴은 클래스·객체 수준의 반복 구조를 다루고, 원칙은 판단 기준을, 프레임워크는 이미 구현된 뼈대를, 아키텍처 패턴은 시스템 수준 구성을 다룬다.

비교 대상	디자인 패턴과의 차이	함께 보는 포인트
설계 원칙 (SOLID 등)	원칙은 기준, 패턴은 구현 가능한 구조 템플릿	원칙이 왜 필요한지 패턴이 구체화한다
프레임워크	프레임워크는 실행 가능한 뼈대, 패턴은 개념적 해법	Spring, React 내부에도 여러 패턴이 녹아 있다
아키텍처 패턴	아키텍처 패턴은 시스템 전체 수준	MVC, MSA 안에서도 GoF 패턴이 세부 구조를 이끈다
리팩토링	리팩토링은 기존 코드를 개선하는 과정	리팩토링의 목표 구조로 패턴이 자주 사용된다

즉 패턴은 혼자 존재하지 않는다. OCP (Open-Closed Principle), DIP (Dependency Inversion Principle), 리팩토링, 테스트 용이성과 연결되며, 좋은 패턴 선택은 결국 좋은 변화 관리 전략과 같다.

📢 섹션 요약 비유: 설계 원칙이 건축 법규라면 디자인 패턴은 방 배치 도면, 프레임워크는 이미 지어진 골조, 아키텍처 패턴은 도시 구획 계획에 가깝다.

Ⅳ. 실무 적용 및 기술사 판단

실무에서 패턴은 멋있어 보이기 때문에 쓰면 실패한다. 같은 요구사항이라도 변경 빈도가 낮고 구조가 단순하면 패턴보다 직관적 구현이 낫다. 반대로 생성 방식, 객체 조합, 협력 규칙이 계속 바뀌면 패턴이 장기 비용을 크게 줄인다.

기술사 답안에서는 패턴 이름 나열보다 문제-구조-효과를 연결해 설명해야 한다. 예를 들어 구체 클래스 의존이 문제이므로 생성 패턴을 적용하고, 결과적으로 OCP와 테스트 용이성이 좋아진다처럼 말할 수 있어야 한다.

판단 체크리스트

지금의 문제가 일회성 구현 이슈가 아니라 반복되는 구조 문제인가?
변경 이유가 명확하여 분리할 축을 설명할 수 있는가?
패턴 도입 후 클래스 수 증가보다 유지보수 이익이 더 큰가?
팀이 패턴 이름만 들어도 의도와 책임 분배를 이해할 수 있는가?

안티패턴 및 오답 포인트

단순 CRUD에 불필요한 계층과 패턴을 붙여 복잡도만 키우는 설계
패턴 이름은 쓰지만 실제로는 구체 클래스 의존을 그대로 남기는 설계
패턴을 암기 목록으로만 이해하고 트레이드오프 설명을 못 하는 답안
📢 섹션 요약 비유: 패턴 선택은 공구 상자에서 망치, 드라이버, 스패너를 고르는 일과 같아서, 문제에 맞는 도구를 골라야지 도구가 멋져 보여서 쓰면 안 된다.

Ⅴ. 기대효과 및 결론

디자인 패턴을 올바르게 사용하면 설계 의도가 명확해지고, 협업 언어가 생기며, 변경이 특정 지점으로 모여 유지보수성이 높아진다. 특히 객체지향 설계의 핵심인 낮은 결합도와 높은 응집도를 실무 수준에서 구현하는 데 도움이 된다.

반대로 패턴을 목적화하면 설계는 무거워진다. 따라서 결론은 패턴을 많이 아는 것보다 언제 쓰지 말아야 하는지까지 아는 것이다. 이것이 감리와 기술사 판단에서 더 높은 점수를 만드는 관점이다.

기대효과	구체적 내용
의사소통 효율	패턴 이름으로 설계 의도를 빠르게 공유
변경 파급 축소	구체 구현 변경이 전체 코드로 확산되는 것을 완화
재사용성 향상	검증된 구조를 여러 도메인에 응용 가능
리뷰 품질 향상	구조적 장단점을 공통 기준으로 토론 가능

📢 섹션 요약 비유: 디자인 패턴을 제대로 익히면 건물을 빨리 짓는 기술보다, 오래 버티는 구조를 고르는 안목이 생기는 셈이다.

📌 관련 개념 맵

개념	연결 포인트
GoF (Gang of Four)	디자인 패턴을 체계적으로 정리한 출발점
SOLID	패턴이 구현 수준에서 실현하는 설계 원칙
생성·구조·행위 패턴	디자인 패턴의 대표 분류 체계
리팩토링	패턴을 목표 구조로 삼아 코드를 개선하는 실천
안티패턴	패턴 오용 또는 잘못된 구조의 반대편 개념

📈 관련 키워드 및 발전 흐름도

반복 설계 문제
    │
    ▼
경험 축적과 명명
    │
    ▼
디자인 패턴 (Design Pattern)
    │
    ├──▶ 생성 패턴
    ├──▶ 구조 패턴
    └──▶ 행위 패턴
            │
            ▼
구조적 의사소통 · 재사용 · 유지보수성 향상

이 흐름은 개별 구현 경험이 이름 있는 설계 지식으로 바뀌고, 다시 조직의 공통 언어와 품질 향상으로 이어지는 과정을 보여 준다.

👶 어린이를 위한 3줄 비유 설명

디자인 패턴은 레고를 자주 만들다 보니 이럴 땐 이렇게 조립하면 잘 된다 하고 정리한 비법책이에요.
친구에게 여기 다리 만들 때 이 방법 쓰자라고 말하면 길게 설명하지 않아도 바로 알아들을 수 있어요.
그래서 더 튼튼하고 고치기 쉬운 장난감을 만들 수 있어요.