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

  1. 본질: GoF 행위 패턴 (Behavioral Patterns)은 객체나 클래스 간의 알고리즘과 책임 분배를 다루는 11가지 디자인 패턴으로, 객체 간의 통신 방식과 복잡한 제어 흐름을 캡슐화하여 유연성과 재사용성을 높인다.
  2. 가치: 행위 패턴은 알고리즘·동작·상태·통신을 객체로 캡슐화하여, 런타임에 동적으로 동작을 교체하거나 객체 간 통신을 표준화할 수 있어, 비즈니스 규칙 변경에 유연하게 대응하는 설계를 가능하게 한다.
  3. 판단 포인트: 행위 패턴 선택의 핵심은 '무엇을 캡슐화하는가?'다. 알고리즘 교체(전략), 상태별 동작(상태), 요청 객체화(커맨드), 단계 순서 고정(템플릿 메서드), 이벤트 통지(옵저버), 요청 체인(책임 연쇄), 중재 통신(미디에이터) 중 요구사항에 맞는 패턴을 선택한다.

Ⅰ. 개요 및 필요성

GoF의 'Design Patterns'(1994)은 23가지 패턴을 생성(Creational), 구조(Structural), 행위(Behavioral) 세 범주로 분류한다. 행위 패턴은 11가지로 가장 많은데, 이는 객체 간의 상호작용이 소프트웨어 설계에서 가장 복잡한 문제이기 때문이다.

행위 패턴이 해결하는 핵심 문제: ① 조건 분기(if-else, switch)의 캡슐화 → 전략·상태 패턴, ② 객체 간 직접 참조 최소화 → 옵저버·미디에이터 패턴, ③ 실행 취소(Undo)·재실행(Redo) 구현 → 커맨드 패턴, ④ 알고리즘의 공통 골격 재사용 → 템플릿 메서드 패턴.

┌─────────────────────────────────────────────────────────────┐
│            GoF 행위 패턴 11가지 분류                         │
├─────────────────────────────────────────────────────────────┤
│  알고리즘 캡슐화                                            │
│  ├─ Strategy (전략): 알고리즘군 교환 가능하게 캡슐화        │
│  └─ Template Method (템플릿 메서드): 알고리즘 골격 정의     │
│                                                             │
│  상태·요청 캡슐화                                           │
│  ├─ State (상태): 상태별 동작 캡슐화                        │
│  └─ Command (커맨드): 요청을 객체로 캡슐화                  │
│                                                             │
│  통신·통지                                                   │
│  ├─ Observer (옵저버): 이벤트 발행-구독                     │
│  ├─ Mediator (미디에이터): 객체 간 중재                     │
│  └─ Chain of Responsibility (책임 연쇄): 요청 체인 처리      │
│                                                             │
│  순회·접근                                                   │
│  ├─ Iterator (반복자): 컬렉션 순회 캡슐화                   │
│  ├─ Visitor (방문자): 데이터 구조와 알고리즘 분리           │
│  ├─ Interpreter (인터프리터): 언어 해석                     │
│  └─ Memento (메멘토): 객체 상태 저장·복원                   │
└─────────────────────────────────────────────────────────────┘
  • 📢 섹션 요약 비유: 행위 패턴은 사람들(객체) 간의 소통 방식을 표준화하는 프로토콜이다. 이메일(옵저버), 회의(미디에이터), 업무 지시(커맨드), 의사결정 트리(전략)처럼 각 상황에 맞는 소통 방식이 있다.

Ⅱ. 아키텍처 및 핵심 원리

행위 패턴 선택 가이드: 문제 상황에 따라 적절한 패턴을 선택하는 것이 중요하다.

항목설명포인트
알고리즘을 런타임에 교체Strategy알고리즘을 인터페이스로 캡슐화
객체 상태에 따라 동작이 달라짐State상태를 객체로 캡슐화
여러 객체에 이벤트 통지Observer발행-구독
요청을 객체로 저장·취소Command요청을 객체로 래핑
알고리즘의 공통 골격 재사용Template Method상위 클래스가 골격 정의
객체 간 직접 참조 제거Mediator중재자 객체로 통신
요청 처리자 동적 연결Chain of Responsibility처리자 체인
┌─────────────────────────────────────────────────────────────┐
│       행위 패턴 간 관계                                      │
├─────────────────────────────────────────────────────────────┤
│  Strategy ↔ State: 상태(State)는 전략(Strategy)과 구조 동일 │
│  하지만 State는 자기 자신을 교체 가능, Strategy는 외부 교체│
│                                                             │
│  Observer ↔ Mediator: 둘 다 객체 간 결합도 낮추지만        │
│  Observer는 1:N 이벤트, Mediator는 N:N 통신 중재           │
│                                                             │
│  Template Method ↔ Factory Method: 둘 다 서브클래스에 위임  │
│  Template은 알고리즘 골격, Factory는 객체 생성              │
└─────────────────────────────────────────────────────────────┘
  • 📢 섹션 요약 비유: 행위 패턴은 요리 기법(볶음, 찜, 굽기)처럼, 재료(객체)와 목적(요구사항)에 맞는 기법을 선택하여 요리(소프트웨어)를 만드는 것이다.

Ⅲ. 비교 및 연결

행위 패턴의 구조 패턴·생성 패턴과의 차이: 생성 패턴은 '객체를 어떻게 만드는가', 구조 패턴은 '객체를 어떻게 조합하는가', 행위 패턴은 '객체가 어떻게 협력하는가'를 다룬다.

비교 축AB
생성 패턴어떻게 만드는가?싱글턴, 팩터리, 빌더
구조 패턴어떻게 조합하는가?어댑터, 데코레이터, 파사드
행위 패턴어떻게 협력하는가?전략, 옵저버, 커맨드
  • 📢 섹션 요약 비유: 생성 패턴은 집을 어떻게 짓는가(공법), 구조 패턴은 집을 어떻게 연결하는가(배치), 행위 패턴은 집의 거주자들이 어떻게 소통하는가(규칙)이다.

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

행위 패턴 남용의 가장 흔한 실수: ① 단순 if-else 두 개를 전략 패턴으로 과도하게 추상화, ② 상태가 두세 개인 단순한 경우에 상태 패턴 적용, ③ 관련 없는 패턴을 혼합하여 복잡성 증가. 패턴은 수단이지 목적이 아니므로, 코드를 더 복잡하게 만드는 패턴 적용은 피해야 한다.

판단 체크리스트

  1. 패턴을 적용하기 전에 문제가 명확하게 정의되어 있는가?
  2. 패턴이 코드를 더 이해하기 쉽게 만드는가, 아니면 더 복잡하게 만드는가?
  3. 선택한 패턴이 미래의 변경 사항을 수용하기 유연한가?
  4. 다른 개발자가 패턴 의도를 이해할 수 있도록 문서화되어 있는가?
  5. 패턴 간 조합 시 서로 충돌하지 않는가?
  • 📢 섹션 요약 비유: 의사가 모든 환자에게 수술(복잡한 패턴)을 처방하지 않듯, 약물(간단한 해결책)로 충분한 경우에는 패턴을 적용하지 않는 것이 옳다.

Ⅴ. 기대효과 및 결론

GoF 행위 패턴을 이해하면 복잡한 제어 흐름과 객체 간 통신을 체계적으로 설계할 수 있다. 패턴은 공통 어휘를 제공하여 팀원 간 소통을 효율화하고, 증명된 해결책으로 설계 실수를 예방한다.

한계는 패턴 학습 비용과 과도한 패턴 적용으로 인한 복잡성 증가다. "가장 좋은 코드는 읽기 쉬운 코드"라는 원칙 하에 패턴을 필요할 때만 적용해야 한다.

미래 방향으로는 ① 함수형 프로그래밍(고차 함수)이 많은 행위 패턴을 단순화, ② 리액티브 프로그래밍이 옵저버·커맨드 패턴을 함수형으로 구현, ③ AI 기반 패턴 추천 도구가 발전하고 있다.

  • 📢 섹션 요약 비유: 행위 패턴은 스포츠 전술처럼, 팀원들이 정해진 전술(패턴)을 알고 있으면 복잡한 상황에서도 빠르게 협력할 수 있다.

📌 관련 개념 맵

[GoF 23 디자인 패턴] → [행위 패턴 11가지] → [전략·상태·옵저버·커맨드·템플릿 메서드] → [함수형 패턴 단순화] → [리액티브 프로그래밍]

개념연결 포인트
SOLID 원칙행위 패턴이 OCP·SRP·DIP를 구현하는 방법
함수형 프로그래밍고차 함수로 많은 행위 패턴을 단순화
리액티브 프로그래밍옵저버 패턴의 함수형·비동기 확장
Spring AOP템플릿 메서드·데코레이터의 프레임워크 구현

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

[GoF 행위 패턴(1994)] → [리팩터링·패턴 활용법(파울러)] → [함수형 프로그래밍 패턴 대체] → [리액티브 옵저버] → [AI 패턴 추천]

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

  1. 행위 패턴은 사람들(객체)이 어떻게 소통하고 협력하는지에 관한 규칙이에요.
  2. 이메일(옵저버), 회의(미디에이터), 업무 지시(커맨드)처럼 상황에 맞는 소통 방식이 있어요.
  3. 적절한 패턴을 선택하면 복잡한 협력도 질서 있게 이루어질 수 있어요!