GoF(Gang of Four) 디자인 패턴에 대해서 알아보자.

  GoF 디자인 패턴은 1994년, Erich Gamma, Richard Helm, Ralph Johnson, John Vlissides라는 네 명의 저자들이 『Design Patterns: Elements of Reusable Object-Oriented Software』라는 책을 통해 체계적으로 정리한 23가지 소프트웨어 설계 패턴을 의미한다. 이 네 명을 가리켜 흔히 "Gang of Four", 즉 "GoF"라고 부른다. 이들이 정리한 디자인 패턴의 목적은 객체지향 프로그래밍(OOP)의 핵심 가치를 극대화하는 데 있다. 구체적으로는 코드의 유지보수성, 확장성, 그리고 재사용성을 향상시키기 위해 설계 단계에서부터 코드 구조를 체계적으로 잡는 것을 목표로 한다. 복잡한 시스템을 개발할 때, 잘 정의된 패턴을 적용함으로써 코드의 일관성을 유지하고, 변경에 유연하게 대응할 수 있으며, 개발자가 반복적으로 직면하는 문제를 보다 효과적으로 해결할 수 있도록 한다.

 

GoF 디자인 패턴은 크게 생성(Creational) 패턴, 구조(Structural) 패턴, 행위(Behavioral) 패턴 이렇게 세 가지로 나뉜다.

 

• 생성 패턴은 객체 생성 과정을 추상화하여 시스템이 구체적인 클래스에 의존하지 않도록 한다.
• 구조 패턴은 클래스나 객체를 조합하여 보다 큰 구조를 만들 때 유연성과 효율성을 극대화한다.
• 행위 패턴은 객체 간 상호작용과 책임dmf 분담하여 시스템의 동작 흐름을 유연하게 만든다.

  이 패턴들은 상당히 오래전에 정립된 클래스 디자인 패턴이지만 지금도 여전히 강력한 힘(?)을 발휘하고 있다. 메타버스, 가상현실(VR), 인공지능(AI), 클라우드 네이티브 아키텍처 등 최신 소프트웨어 개발 영역에서도 GoF 디자인 패턴은 기본적인 설계 원칙으로서 자리 잡고 있으며, 다양한 현대 기술 스택과 통합되어 사용되고 있다. 특히, 규모가 크고 복잡도가 높은 시스템에서는 코드의 품질을 높이고 유지보수를 용이하게 하며, 팀 간 협업의 기준을 맞추는데 GoF 디자인 패턴이 필수적인 역할을 한다. 

 

왜 Gang of Four일까?

  이 패턴을 정립한 사람(저자)는 총 4명인데, 책을 발표한 후 객체지향 소프트웨어 설계 분야에서 아주 큰 영향력을 미치게 되었는데, 워낙 이 네 명이 함께 쓴 책이 유명해지다 보니 사람들이 편하게 부르기 위해 "그 네 명의 사람들"을 "Gang of Four"라는 별명을 붙여 부르게 된다. 특별히 무서운 뜻이나 정치적 의미가 있는 건 아니고, 소프트웨어 공학 역사에서는 이걸 존경과 상징 그리고 친근함을 담아 자연스럽게 부르게 되었다.

 

생성 패턴

  생성 패턴은 "객체를 어떻게 만들 것인가" 를 설계하는 패턴이다. 객체 생성 과정을 캡슐화(추상화) 하여, 시스템이 구체적인 클래스에 강하게 의존하지 않도록 하고, 결과적으로 코드의 유연성과 확장성, 유지보수성을 높이는 것을 목표로 하는 설계 패턴이다. 

 

 주요 생성 패턴군은 아래와 같다.

Singleton	하나의 인스턴스만 존재하도록 보장. 전역 접근 포인트 제공.
Factory Method	객체 생성을 서브클래스에게 위임. 상위 클래스는 생성 방식을 모름.
Abstract Factory	관련된 객체 제품군을 생성하는 인터페이스 제공. 서로 관련된 객체 묶음 생산.
Builder	복잡한 객체 생성 과정을 단계별로 분리해서 관리.
Prototype	기존 객체를 복제(clone)하여 새로운 객체를 생성.

 

구조 패턴

  구조 패턴은 클래스나 객체를 조합하여 더 크고 유연한 구조를 만드는 방법을 제시하는 디자인 패턴군이다. 주된 목적은 여러 개의 클래스를 효율적이고 일관성 있게 결합하여, 새로운 기능이나 시스템 아키텍처를 설계할 때 확장성과 재사용성을 극대화하는 데 있다. 구조 패턴은 단순히 코드를 모아놓는 것이 아니라, "어떤 방식으로 객체를 연결하고 조립하면 시스템이 더 견고하고 유연하게 진화할 수 있는가" 라는 관점에서 접근한다. 특히 대규모 시스템이나 메타버스, VR, AI 플랫폼 같이 복잡한 모듈 구성을 필요로 하는 프로젝트에서는 구조 패턴을 적용함으로써 코드의 복잡도를 줄이고, 모듈 간의 의존성을 낮추며, 유지보수와 확장성을 높이는 효과를 얻을 수 있다.

 

  주요 구조 패턴군은 아래와 같다.

Adapter	서로 다른 인터페이스를 가진 클래스를 연결. 기존 클래스를 수정하지 않고 호환성 문제를 해결
Bridge	구현부와 추상부를 분리하여 각자 독립적으로 확장가능. 플랫폼 독립적인 코드를 만들 때 매우 유용.
Composite	트리 구조(계층 구조)를 만들어, 단일 객체와 복합 객체를 동일하게 사용
Decorator	객체에 새로운 기능을 동적으로 추가할 수 있도록 함. 클래스 수정 없이 기능을 추가할 때 유용.
Facade	복잡한 서브시스템에 대해 단순한 인터페이스를 제공하여 사용자가 쉽게 사용할 수 있게 함. 시스템 복잡성을 숨기고 인터페이스를 단순화하는 데 효과적.
Flyweight	동일하거나 비슷한 객체를 공유하여 메모리 사용을 최소화. 수많은 작은 객체를 다룰 때 유용
Proxy	실제 객체에 대한 접근을 제어하는 대리 객체를 제공. 접근 제어, 지연 로딩, 프록시 서버 구현 등에 활용.

 

행위 패턴

행위 패턴은 객체 간의 상호작용과 책임 분산을 중심으로 반복적으로 발생하는 객체 간 통신 방법을 구조화한 설계 패턴이다. 객체는 일반적으로 속성(데이터) 과 행위(메서드) 를 가지고 있으며, 이러한 메서드를 통해 다른 객체와 상호작용한다. 실제 시스템 설계에서는 객체 간 기능 호출과 데이터 교환이 매우 빈번하게 일어나고, 이 과정에서 어떻게 효과적으로 협력할지, 어떻게 책임을 나눌지가 중요하다. 행위 패턴은 바로 이 "객체 간 상호작용 방법"과 "책임 분배 방법" 을 패턴화하여 정형화된 방식으로 제공한다.

 

주요 행위 패턴군은 다음과 같다.

Strategy	알고리즘을 캡슐화하여 동적으로 변경 가능하게 함
Observer	한 객체의 상태 변화가 여러 객체에 자동 전파되게 함
Command	요청을 객체로 캡슐화하여 실행 취소, 재실행 기능 지원
Mediator	객체들 간 직접 통신 대신 중재자(Mediator)를 통해 통신
Template Method	알고리즘의 뼈대를 정의하고 세부 단계는 서브클래스가 구현
Iterator	컬렉션 내부 구조를 노출하지 않고 순회 가능하게 함
State	객체 상태에 따라 행위를 동적으로 변경