Structural

Structural

Structural Design Patterns 는 소프트웨어 설계에서 객체 및 클래스 구조의 조합과 관계 맺음을 중심으로, 효율적이고 유연한 구조 구축을 돕는 패턴 집합이다.
Adapter, Bridge, Composite, Decorator, Facade, Flyweight, Proxy 등 7 가지가 대표적이며, 각 패턴은 시스템의 복잡성을 줄이고, 코드의 유연성과 확장성을 높인다.
Adapter 는 이질적 인터페이스를 연결하고, Bridge 는 추상화와 구현을 분리하며, Composite 는 계층적 구조를 관리한다. Decorator 는 동적으로 기능을 확장하고, Facade 는 복잡한 서브시스템을 단순화하며, Flyweight 는 메모리 공유를 통한 최적화를, Proxy 는 접근 제어 및 지연 초기화를 제공한다.
구조 패턴을 활용하면 다양한 객체와 클래스가 상호작용하는 복잡한 시스템에서도 일관성 있고 유지보수하기 쉬운 아키텍처를 설계할 수 있다.

배경 & 목적

• 배경: 복잡한 서브시스템, 비호환 인터페이스 증가, 중복 코드 등의 구조적 복잡성 해결 필요성 대두.
• 목적:
  • 클래스 간 상속보다 조합 (composition) 을 통한 느슨한 결합 실현
  • 인터페이스 호환성 제공 (Adapter)
  • 기능 확장/변경의 유연성 (Decorator, Bridge)
  • 메모리/성능 최적화 (Flyweight)
  • 시스템 복잡성 폐쇄 공간 (Facade), 접근 제어 (Proxy)

필요성

• 복잡한 시스템에서 객체 간의 관계를 명확하게 정의하고 관리하기 위해
• 코드의 중복을 줄이고 재사용성을 높이기 위해
• 시스템의 유지보수성과 확장성을 향상시키기 위해

핵심 개념

구조 패턴은 객체와 클래스의 조합을 통해 더 큰 구조를 형성하는 방법을 제공하여, 시스템의 유연성과 효율성을 높이는 디자인 패턴이다. 이러한 패턴은 객체 간의 관계를 단순화하고, 코드의 재사용성과 유지보수성을 향상시키는 데 중점을 둔다.

기본 개념

• 객체 합성 (Object Composition): 여러 객체를 결합하여 새로운 기능을 만드는 방식
• 구조적 추상화 (Structural Abstraction): 복잡한 시스템을 단순한 인터페이스로 감싸는 기법
• 어댑터 (Adapter): 호환되지 않는 인터페이스를 연결하는 중간 계층
• 래퍼 (Wrapper): 기존 객체를 감싸서 새로운 인터페이스를 제공하는 패턴

심화 개념

• 브리지 패턴 (Bridge Pattern): 추상화와 구현을 분리하여 독립적 변화 허용
• 컴포지트 패턴 (Composite Pattern): 부분 - 전체 계층 구조를 트리로 표현
• 플라이웨이트 패턴 (Flyweight Pattern): 메모리 효율성을 위한 객체 공유 메커니즘
• 데코레이터 체이닝 (Decorator Chaining): 여러 데코레이터를 연쇄적으로 적용하는 기법

패턴 적용의 결과와 트레이드오프

각 구조 패턴 적용 시의 주요 트레이드오프를 분석하겠습니다:

주요 기능 및 역할

1. 구조적 조합 (Structural Composition)

classDiagram
    class Component {
        +operation()
    }
    class Leaf {
        +operation()
    }
    class Composite {
        -children: Component[]
        +add(Component)
        +remove(Component)
        +operation()
    }
    
    Component <|-- Leaf
    Component <|-- Composite
    Composite o-- Component

2. 인터페이스 적응 (Interface Adaptation)

classDiagram
    class Target {
        +request()
    }
    class Adapter {
        -adaptee: Adaptee
        +request()
    }
    class Adaptee {
        +specificRequest()
    }
    
    Target <|-- Adapter
    Adapter --> Adaptee

기능별 역할:

• 구조 변환: 객체 구조를 클라이언트 요구에 맞게 변환
• 인터페이스 통합: 서로 다른 인터페이스를 통합된 형태로 제공
• 접근 제어: 객체 접근을 제어하고 추가 기능 제공
• 성능 향상: 객체 생성과 메모리 사용을 최적화

패턴별 역할

특징

1. 합성 중심 설계 (Composition-oriented Design)

   • 상속보다 합성을 선호하는 설계 철학
   • 런타임에 객체 관계 변경 가능
   • 다중 상속의 복잡성 회피

2. 투명성 (Transparency)

   • 클라이언트가 구현 세부사항을 알 필요 없음
   • 단일 객체와 복합 객체의 일관된 인터페이스
   • 구조적 복잡성 은닉

3. 적응성 (Adaptability)

   • 기존 클래스를 수정하지 않고 새로운 기능 추가
   • 다양한 환경과 요구사항에 유연하게 대응
   • 점진적 시스템 발전 지원

핵심 원칙

1. 개방 - 폐쇄 원칙 (Open-Closed Principle)

   • 확장에는 열려있고 수정에는 닫혀있는 설계
   • 새로운 기능 추가 시 기존 코드 수정 최소화

2. 인터페이스 분리 원칙 (Interface Segregation Principle)

   • 클라이언트가 사용하지 않는 메서드에 의존하지 않도록 설계
   • 작고 응집된 인터페이스 선호

3. 의존성 역전 원칙 (Dependency Inversion Principle)

   • 구체적인 클래스보다 추상화에 의존
   • 고수준 모듈이 저수준 모듈에 의존하지 않도록 설계

작동 원리 및 방식

• 패턴별 특화된 구조 설계
  • Adapter: 인터페이스 호환
  • Bridge: 추상화와 구현 분리
  • Composite: 트리 구조로 객체 통합
  • Decorator: 동적 기능 확장
  • Facade: 복잡한 시스템 단순화
  • Flyweight: 메모리 효율성
  • Proxy: 객체 접근 제어

작동 원리 다이어그램 (text)

1
2

Client ---> [Structural Pattern] ---> [Target Object]
           (Adapter, Bridge, Composite, Decorator, Facade, Flyweight, Proxy)

주요 원리

구조 패턴의 작동 원리를 다이어그램으로 설명하겠습니다:

graph TD
    A[클라이언트 요청] --> B{패턴 유형}
    B -->|Adapter| C[인터페이스 변환]
    B -->|Decorator| D[기능 추가]
    B -->|Facade| E[복잡성 은닉]
    B -->|Proxy| F[접근 제어]
    
    C --> G[기존 객체]
    D --> H[래핑된 객체]
    E --> I[서브시스템]
    F --> J[실제 객체]
    
    G --> K[변환된 결과]
    H --> L[확장된 기능]
    I --> M[단순화된 인터페이스]
    J --> N[제어된 접근]

작동 방식:

1. 요청 수신: 클라이언트로부터 작업 요청 수신
2. 패턴 적용: 해당하는 구조 패턴 메커니즘 동작
3. 구조 변환: 객체 구조를 요구사항에 맞게 변환
4. 결과 반환: 변환된 결과를 클라이언트에게 반환

Structural vs. Creational/Behavioral

핵심 차이점 요약:

• Create: 어떻게 객체를 만들 것인가
• Structural: 만들어진 객체들끼리 어떻게 구성·관계 맺을 것인가
• Behavioral: 구성된 객체들이 어떻게 상호작용하고 행동하게 할 것인가

구조 패턴의 종류 및 비교

비교 분석이 반드시 필요한 패턴 조합

Adapter vs. Bridge vs. Decorator

의도와 사용 시점, 확장 방법이 다르다

• Adapter는 호환되지 않는 기존 시스템을 변환해서 사용하려고 할 때.
• Bridge는 기능과 구현을 독립적으로 확장하고자 할 때.
• Decorator는 동적으로 기능을 조합하여 추가하고자 할 때 가장 유용하다.

공통 시나리오: “Notification System”

• 기본적으로 Slack, Email, SMS 로 알림을 보냄
• Adapter: 기존 시스템에 새 알림 방식을 맞추기 위해 사용
• Bridge: 알림 유형과 전송 방식을 분리해 유연하게 조합
• Decorator: 알림에 기능을 점진적으로 추가 (ex. 로그, 암호화)

Adapter Pattern

목적: 기존 인터페이스를 클라이언트가 기대하는 방식으로 변경

구조:

• Target: 클라이언트가 기대하는 인터페이스 (ex. Notifier)
• Adaptee: 기존 시스템 클래스 (ex. LegacySlack)
• Adapter: Adaptee 를 감싸고 Target 인터페이스를 구현

코드 예시:

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20
21

# 기존에 존재하던 Slack API
class LegacySlack:
    def post_message(self, text: str):
        print(f"[LegacySlack] {text}")

# 클라이언트가 기대하는 인터페이스
class Notifier:
    def send(self, message: str):
        raise NotImplementedError()

# Adapter: LegacySlack → Notifier 변환
class SlackAdapter(Notifier):
    def __init__(self, slack: LegacySlack):
        self.slack = slack

    def send(self, message: str):
        self.slack.post_message(message)

# 사용 예
notifier = SlackAdapter(LegacySlack())
notifier.send("System alert!")

Bridge Pattern

목적: 알림 종류와 전송 방식을 분리하여 조합의 유연성 확보

구조:

• Implementor: 전송 방식 (Email, SMS 등)
• Abstraction: 알림 종류 (Alert, Notification 등)
• 런타임에 다양한 조합 가능

코드 예시:

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28

# 구현 계층
class MessageSender:
    def send(self, message: str):
        raise NotImplementedError()

class EmailSender(MessageSender):
    def send(self, message: str):
        print(f"[Email] {message}")

class SmsSender(MessageSender):
    def send(self, message: str):
        print(f"[SMS] {message}")

# 추상화 계층
class Notification:
    def __init__(self, sender: MessageSender):
        self.sender = sender

    def notify(self, content: str):
        raise NotImplementedError()

class AlertNotification(Notification):
    def notify(self, content: str):
        self.sender.send(f"[ALERT] {content}")

# 사용 예
email_alert = AlertNotification(EmailSender())
email_alert.notify("High CPU usage")

Decorator Pattern

목적: 기능을 동적으로 확장 (ex. 로깅, 보안, 전처리)

구조:

• Component: Notifier 인터페이스
• ConcreteComponent: 기본 전송 기능
• Decorator: 기능을 감싸고 확장

코드 예시:

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33

# 기본 인터페이스
class Notifier:
    def send(self, message: str):
        raise NotImplementedError()

# 기본 구현
class BasicNotifier(Notifier):
    def send(self, message: str):
        print(f"[Basic] {message}")

# Decorator 베이스
class NotifierDecorator(Notifier):
    def __init__(self, notifier: Notifier):
        self._notifier = notifier

    def send(self, message: str):
        self._notifier.send(message)

# 구체적 데코레이터: 로그 기록 추가
class LoggingNotifier(NotifierDecorator):
    def send(self, message: str):
        print("[Log] Sending message…")
        super().send(message)

# 구체적 데코레이터: 암호화 추가
class EncryptedNotifier(NotifierDecorator):
    def send(self, message: str):
        encrypted = f"ENCRYPTED({message})"
        super().send(encrypted)

# 사용 예
notifier = LoggingNotifier(EncryptedNotifier(BasicNotifier()))
notifier.send("Deploy complete")

Decorator vs. Proxy

구조는 유사하지만, **의도 (intent)**와 역할 (role) 에서 본질적인 차이가 있다.

• Decorator: 기능을 점진적으로 쌓기 위한 동적 확장 도구
  • 목적: 기능 추가
  • 특징: 중첩 가능, 조합 가능, 항상 위임
• Proxy: 객체의 접근을 제어하거나 최적화하는 패턴
  • 목적: 접근 통제 및 지연 처리
  • 특징: 실제 객체 대신, 조건부 위임

공통 시나리오: " 파일 읽기 시스템 "

• 클라이언트는 read() 메서드로 파일 내용을 읽고자 한다.
  • Decorator는 기능을 확장 (예: 로깅, 암호화)
  • Proxy는 접근 제어 (예: 인증, 캐싱) 또는 대리 처리 (예: 네트워크 요청, 지연 로딩) 목적이다.

• Decorator는 " 이 기능도 추가하고 싶다 " 일 때,
• Proxy는 " 이 요청을 막거나 통제해야 해 " 일 때 사용.

Decorator Pattern

목적: 기존 객체의 기능을 확장하거나 추가하면서도 구조를 변경하지 않음

코드 예시:

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33

# Component interface
class FileReader:
    def read(self) -> str:
        raise NotImplementedError()

# Concrete Component
class BasicFileReader(FileReader):
    def read(self) -> str:
        return "file contents"

# Decorator base class
class FileReaderDecorator(FileReader):
    def __init__(self, reader: FileReader):
        self.reader = reader

    def read(self) -> str:
        return self.reader.read()

# Logging 기능을 추가한 데코레이터
class LoggingFileReader(FileReaderDecorator):
    def read(self) -> str:
        print("[LOG] Reading file…")
        return self.reader.read()

# 암호화 해제를 추가한 데코레이터
class DecryptionFileReader(FileReaderDecorator):
    def read(self) -> str:
        data = self.reader.read()
        return f"decrypted({data})"

# 사용 예시
reader = DecryptionFileReader(LoggingFileReader(BasicFileReader()))
print(reader.read())

1
2

[LOG] Reading file…
decrypted(file contents)

Proxy Pattern

목적: 원래 객체에 대한 접근을 제어하거나, 대리 객체로서 처리하는 구조

코드 예시

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27

# Subject interface
class FileReader:
    def read(self) -> str:
        raise NotImplementedError()

# RealSubject
class RealFileReader(FileReader):
    def read(self) -> str:
        return "file contents"

# Proxy
class ProtectedFileReader(FileReader):
    def __init__(self, user: str):
        self.user = user
        self.real_reader = RealFileReader()

    def read(self) -> str:
        if self.user != "admin":
            return "Access Denied"
        return self.real_reader.read()

# 사용 예시
user_reader = ProtectedFileReader("guest")
print(user_reader.read())  # Access Denied

admin_reader = ProtectedFileReader("admin")
print(admin_reader.read())  # file contents

Composite vs. Decorator

• Composite 은 구조적 계층 구성에 적합하며, 전체를 하나처럼 다루기 위한 패턴이다.
• Decorator 는 기능 추가를 위한 래핑 패턴으로, 기존 코드 변경 없이 동작을 확장한다.
• 두 패턴 모두 Component 인터페이스 를 공유하지만, 구조적 목적 vs. 행동 확장이라는 명확한 차이를 가진다.

공통 시나리오: UI 구성 요소 (Component UI)

• Component 인터페이스를 기반으로 UI 요소를 구성
• Composite은 **계층적 구조 (트리 구조)**를 표현
• Decorator는 기능을 확장 (동적 부가기능)

• UI 구성 시 Panel, Layout, Container 처럼 트리 구조가 필요한 경우 → Composite
• 버튼에 Border, Shadow, Tooltip 등을 선택적으로 덧씌우는 경우 → Decorator

Composite Pattern

목적: 부분 - 전체 구조를 동일하게 다루기 위해 (즉, Leaf 와 Composite 를 같은 방식으로 처리)

코드 예시

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40

from abc import ABC, abstractmethod

# Component 인터페이스
class UIComponent(ABC):
    @abstractmethod
    def render(self, indent: int = 0):
        pass

# Leaf
class Button(UIComponent):
    def __init__(self, name: str):
        self.name = name

    def render(self, indent: int = 0):
        print(" " * indent + f"Button: {self.name}")

# Composite
class Panel(UIComponent):
    def __init__(self, name: str):
        self.name = name
        self.children: list[UIComponent] = []

    def add(self, component: UIComponent):
        self.children.append(component)

    def render(self, indent: int = 0):
        print(" " * indent + f"Panel: {self.name}")
        for child in self.children:
            child.render(indent + 2)

# 사용 예시
root = Panel("Root")
file_panel = Panel("File")
file_panel.add(Button("Open"))
file_panel.add(Button("Save"))

root.add(file_panel)
root.add(Button("Exit"))

root.render()

1
2
3
4
5

Panel: Root
  Panel: File
    Button: Open
    Button: Save
  Button: Exit

Decorator Pattern

목적: 기능을 동적으로 확장하기 위해 객체를 감싸는 구조 (컴포넌트를 계층적으로 감싸며 기능을 추가)

코드 예시:

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39

from abc import ABC, abstractmethod

# Component
class UIComponent(ABC):
    @abstractmethod
    def render(self):
        pass

# Concrete Component
class Button(UIComponent):
    def __init__(self, name: str):
        self.name = name

    def render(self):
        print(f"Button: {self.name}")

# Decorator Base
class ComponentDecorator(UIComponent):
    def __init__(self, component: UIComponent):
        self.component = component

    def render(self):
        self.component.render()

# 구체 데코레이터: 테두리 추가
class BorderDecorator(ComponentDecorator):
    def render(self):
        print("Drawing border…")
        super().render()

# 구체 데코레이터: 그림자 효과
class ShadowDecorator(ComponentDecorator):
    def render(self):
        print("Applying shadow…")
        super().render()

# 사용 예시
decorated = BorderDecorator(ShadowDecorator(Button("Save")))
decorated.render()

1
2
3

Drawing border…
Applying shadow…
Button: Save

Flyweight vs. Proxy vs. Composite

Flyweight, Proxy, Composite는 모두 구조적 패턴이지만, 목적과 적용 대상이 다르다.

• Flyweight: 많은 수의 유사 객체가 존재할 때 메모리 절약을 위해 공유 구조로 설계.
• Proxy: 객체 접근 자체를 지연, 제어, 보호하는 용도. 객체 생성과 접근 시점을 제어.
• Composite: 여러 객체를 트리 구조로 구성하고, 개별 객체와 그룹을 동일하게 처리할 수 있게 함.

공통 주제: 그래픽 도형 시스템

• 다양한 도형 (Circle, Rectangle) 을 화면에 그릴 수 있다.

이 시스템에서:

• Flyweight: 동일 속성을 공유하여 메모리 최적화
• Proxy: 렌더링을 제어하거나 지연 처리
• Composite: 여러 도형을 그룹핑해서 함께 다루기

• Flyweight → 객체 수가 많고 속성이 반복될 때 메모리 최적화
• Proxy → 객체 접근을 제어하거나 지연/보호/로깅
• Composite → 복잡한 구조를 트리 구조로 표현하고 전체 - 부분을 동일하게 처리

Flyweight Pattern

목적: 공통된 상태 (state) 를 공유하여 객체 수와 메모리 사용을 줄임

코드 예시

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28

# Flyweight: 공유 가능한 속성만 보관
class ShapeFlyweight:
    def __init__(self, color: str):
        self.color = color  # 공유 상태

    def draw(self, x: int, y: int):
        print(f"Drawing {self.color} shape at ({x}, {y})")

# Flyweight Factory
class ShapeFactory:
    _cache = {}

    @classmethod
    def get_shape(cls, color: str):
        if color not in cls._cache:
            cls._cache[color] = ShapeFlyweight(color)
        return cls._cache[color]

# 사용 예시
shape1 = ShapeFactory.get_shape("red")
shape2 = ShapeFactory.get_shape("red")
shape3 = ShapeFactory.get_shape("blue")

shape1.draw(10, 20)
shape2.draw(30, 40)
shape3.draw(50, 60)

print(shape1 is shape2)  # True

• 동일한 색상 (color) 을 가진 도형은 하나의 인스턴스를 공유
• 위치 (x, y) 는 **외부 상태 (Non-shared state)**로 전달됨

Proxy Pattern

목적: 객체 접근을 통제하거나 지연 처리, 로깅, 캐싱 등을 수행

코드 예시

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28

# 실제 도형 객체
class RealImage:
    def __init__(self, filename: str):
        self.filename = filename
        self._load_image()

    def _load_image(self):
        print(f"Loading image from {self.filename}…")

    def draw(self):
        print(f"Drawing image: {self.filename}")

# Proxy: 지연 로딩 구현
class ImageProxy:
    def __init__(self, filename: str):
        self.filename = filename
        self._real_image = None

    def draw(self):
        if self._real_image is None:
            self._real_image = RealImage(self.filename)
        self._real_image.draw()

# 사용 예시
img = ImageProxy("logo.png")
print("Image created, but not loaded yet.")
img.draw()  # 여기서 로딩 발생
img.draw()  # 두 번째는 캐시 사용

• **실제 객체 (RealImage)**의 생성과 작업을 프록시가 제어
• 불필요한 리소스 낭비를 방지하거나 접근 제어에 활용 가능

Composite Pattern

목적: 객체들을 트리 구조로 구성하여 부분 - 전체 관계를 동일하게 처리

코드 예시:

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43

from abc import ABC, abstractmethod

# 공통 인터페이스
class Graphic(ABC):
    @abstractmethod
    def draw(self):
        pass

# Leaf
class Circle(Graphic):
    def draw(self):
        print("Drawing Circle")

class Rectangle(Graphic):
    def draw(self):
        print("Drawing Rectangle")

# Composite
class Group(Graphic):
    def __init__(self):
        self.children: list[Graphic] = []

    def add(self, graphic: Graphic):
        self.children.append(graphic)

    def draw(self):
        print("Drawing Group:")
        for child in self.children:
            child.draw()

# 사용 예시
circle = Circle()
rect = Rectangle()

group = Group()
group.add(circle)
group.add(rect)

nested_group = Group()
nested_group.add(group)
nested_group.add(Circle())

nested_group.draw()

• Group 은 다른 도형 (Leaf 또는 Group) 을 계층적으로 포함
• 클라이언트는 개별 객체와 그룹을 동일한 방식으로 처리 가능

장점

단점과 문제점 그리고 해결방안

도전 과제 및 해결책

실무 적용 예시

활용 사례

사례 1: 웹 애플리케이션의 로깅 및 인증 기능 확장

Decorator 패턴

목적: 기존 핵심 비즈니스 로직 코드에 영향 없이 공통 관심사 모듈화

시스템 구성 다이어그램:

classDiagram
    class RequestHandler {
        +handle(request)
    }
    class AuthHandler {
        -handler:RequestHandler
        +handle(request)
    }
    class LoggingHandler {
        -handler:RequestHandler
        +handle(request)
    }

    RequestHandler <|-- AuthHandler
    RequestHandler <|-- LoggingHandler
    AuthHandler *-- RequestHandler
    LoggingHandler *-- RequestHandler

워크플로우:

1. Client 의 요청이 LoggingHandler 로 전달됨
2. LoggingHandler 가 로그를 남기고 내부 AuthHandler 로 위임
3. AuthHandler 에서 인증 검증 후 실제 RequestHandler 실행
4. 결과는 다시 AuthHandler → LoggingHandler → Client 로 반환

차이점 분석:

• Decorator 미적용 시: 인증과 로깅 코드가 핵심 핸들러에 섞여 코드 유지보수가 어려움
• Decorator 적용 시: 기능 분리가 명확하며, 인증·로깅 기능을 비즈니스 로직과 독립적으로 교체·확장 가능

사례 2: 전자상거래 플랫폼의 결제 시스템 통합

전자상거래 플랫폼에서 여러 결제 서비스 (신용카드, 페이팔, 암호화폐) 를 통합하는 사례.

시스템 구성:

graph TB
    subgraph "클라이언트"
        A[웹 애플리케이션]
        B[모바일 앱]
    end
    
    subgraph "결제 시스템"
        C[Payment Facade]
        D[Payment Adapter Factory]
        E[Credit Card Adapter]
        F[PayPal Adapter]
        G[Crypto Adapter]
    end
    
    subgraph "외부 서비스"
        H[Credit Card API]
        I[PayPal API]
        J[Crypto Exchange API]
    end
    
    A --> C
    B --> C
    C --> D
    D --> E
    D --> F
    D --> G
    E --> H
    F --> I
    G --> J

워크플로우:

1. 요청 수신: 클라이언트에서 결제 요청 전송
2. Facade 처리: Payment Facade 가 요청을 단일 인터페이스로 처리
3. Adapter 선택: Factory 패턴으로 적절한 Adapter 선택
4. 인터페이스 변환: 각 Adapter 가 외부 API 형식에 맞게 변환
5. 결과 통합: 응답을 통일된 형식으로 변환하여 반환

구조 패턴의 역할:

• Facade: 복잡한 결제 로직을 단순한 인터페이스로 제공
• Adapter: 각 결제 서비스의 서로 다른 API 를 통일된 인터페이스로 변환
• Factory: 동적으로 적절한 Adapter 인스턴스 생성

패턴 유무에 따른 차이점:

• 패턴 적용 전: 각 결제 서비스마다 별도 구현, 클라이언트 코드 복잡성 증가
• 패턴 적용 후: 통일된 인터페이스로 개발 효율성 향상, 새로운 결제 수단 추가 용이

사례 3: Adapter 패턴을 활용한 레거시 시스템 통합

시스템 구성: 기존 시스템 (OldSystem), 새로운 시스템 (NewSystem), Adapter 클래스

Workflow: Client → Adapter → OldSystem

graph LR
    Client --> Adapter
    Adapter --> OldSystem

역할: Adapter 는 OldSystem 의 인터페이스를 NewSystem 이 이해할 수 있도록 변환

유무 차이: Adapter 적용 시 시스템 통합이 용이하며, 미적용 시 직접 인터페이스 수정 필요

사례 4: 하나의 데이터 처리 파이프라인

패턴 조합 예시: Adapter + Facade + Strategy

하나의 데이터 처리 파이프라인에서 다음과 같은 기능이 필요할 때:

1. 레거시 API(JSON 조회, XML 변환) 지원 → Adapter
2. 복잡한 데이터 파이프를 단일 진입점으로 노출 → Facade
3. 동적으로 알고리즘 선택 (예: 압축, 암호화 등) → Strategy

구조 다이어그램

classDiagram
    class LegacyJSONClient {
        +get_json()
    }

    class LegacyXMLClient {
        +get_xml()
    }

    class JSONToStandardAdapter {
        +get_standard()
    }

    class XMLToStandardAdapter {
        +get_standard()
    }

    class DataFacade {
        -jsonAdapter
        -xmlAdapter
        -strategy
        +processRequest(src, type)
    }

    class Strategy {
        <<interface>>
        +execute(data)
    }

    class CompressionStrategy {
        +execute(data)
    }

    class EncryptionStrategy {
        +execute(data)
    }

    DataFacade --> JSONToStandardAdapter
    DataFacade --> XMLToStandardAdapter
    DataFacade --> Strategy

    Strategy <|-- CompressionStrategy
    Strategy <|-- EncryptionStrategy

• Adapter: 레거시 데이터를 표준 데이터로 변환
• Facade: 클라이언트는 DataFacade.processRequest(…) 만 호출
• Strategy: 런타임 시 압축 또는 암호화 알고리즘 선택 적용

구현 예시

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16

# Adapter 패턴 예시
class OldSystem:
    def old_method(self):
        return "Old System Method"

class Adapter:
    def __init__(self, old_system):
        self.old_system = old_system

    def new_method(self):
        return self.old_system.old_method()

# 클라이언트 코드
old_system = OldSystem()
adapter = Adapter(old_system)
print(adapter.new_method())  # 출력: Old System Method

사례 5: 비동기/이벤트 기반 시스템에서 Structural 패턴 적용

이벤트 기반 또는 메시징 시스템에서 Structural 패턴은 다음과 같은 형태로 활용된다:

• Proxy: 메시지 큐에 대한 접근 제어, retry logic 및 circuit breaker 포함
• Decorator: 메시지 수신/발행 로깅, 메시지 변환, 엔리치먼트 용으로 메시징 핸들러 래핑
• Facade: 메시지 브로커 (RabbitMQ, Kafka 등) API 일관된 인터페이스 제공

sequenceDiagram
    participant Client
    participant LogDecorator
    participant AuthDecorator
    participant MessageHandler
    participant MQProxy

    Client->>LogDecorator: send(message)
    LogDecorator->>AuthDecorator: send(message)
    AuthDecorator->>MessageHandler: send(message)
    MessageHandler->>MQProxy: publish(message)
    MQProxy->>Broker: enqueue(message)

• 메시지에 로깅 및 인증 장치를 붙이고, MQ 접근은 Proxy 로 통제

사례 6: Microservice 환경에서 Structural 패턴 매핑 전략

API Gateway 구조

graph LR
    ExternalClient --> GatewayAdapter
    GatewayAdapter --> AuthProxy
    AuthProxy --> ServiceFacade
    ServiceFacade --> UserService
    ServiceFacade --> OrderService

• GatewayAdapter: 외부 요청 형식을 내부 모델로 변환
• AuthProxy: 인증 및 권한 검사
• ServiceFacade: 다중 서비스 호출 흐름 정리

사례 7: Adapter 패턴 적용 사례: 기존 코드와 새 인터페이스 연결

시스템 구성:

• Client → Target
• Adapter → Adaptee
• Adapter 가 기존 코드와 새 인터페이스를 연결

Workflow:

1. Client 가 Target 인터페이스 사용
2. Adapter 가 Adaptee(기존 코드) 를 호출
3. Adaptee 가 실제 기능 수행

역할:

• 기존 코드와 새 인터페이스를 연결하여 호환성 확보
• 기존 코드를 재사용할 수 있게 함

차이점:

• 패턴 미적용 시 기존 코드를 새 인터페이스에 맞게 수정해야 함
• 패턴 적용 시 기존 코드를 그대로 재사용 가능

사례 8: 대규모 금융 시스템에서 레거시 계좌 시스템과 신규 API 연동 필요

시스템 구성:

• Adapter 패턴 적용: LegacyAccountService(Adaptee) 와 NewAccountAPI(Target) 사이에 AccountAdapter(Adapter) 구현

시스템 구성 다이어그램

1
2
3
4
5
6

Client ---> NewAccountAPI (Target)
                   ^
                   |
             AccountAdapter
                   |
         LegacyAccountService (Adaptee)

Workflow:

1. 클라이언트는 NewAccountAPI 인터페이스로 계좌 정보를 요청
2. AccountAdapter 가 LegacyAccountService 의 데이터를 변환해 반환
3. 클라이언트는 신규 API 만 알면 됨

역할:

• Adapter 가 레거시 시스템과 신규 시스템의 호환성 보장
• 클라이언트는 인터페이스만 알면 되고, 내부 구현 변경에 영향 없음

실무에서 효과적으로 적용하기 위한 고려사항 및 주의할 점

테스트 전략

Structural 패턴 구현 시 고려해야 할 테스트 유형:

1. 단위 테스트 (Unit Test)

   • 각 데코레이터가 기능 위임 후 후처리 로직 수행 확인
   • AuthDecorator 미인증 시 PermissionError 발생 검증

2. 통합 테스트 (Integration Test)

   • 여러 데코레이터를 조합한 핸들러 흐름 검증
   • 실행 흐름, 타이밍, 예외 전파 등 정상 처리 확인

3. 성능 테스트 (Performance Test)

   • 래핑 계층이 많은 경우 처리 지연 시간 측정
   • 성능 저하 임계점 파악 및 고도화 전략 수립

리팩토링 전략

Structural 패턴 적용 시 소스 구조를 개선하는 방법:

• 중복 제거
  • 데코레이터의 공통 위임 코드 추출 → HandlerDecorator 에 모아 재사용
• 레이어 최소화
  • 래핑 계층이 너무 많은 경우 단순화 or 한 개로 통합
• 명확한 역할 분리
  • 각 데코레이터 하나당 하나의 책임만 갖도록 리팩토링

시스템 규모 증가 시 설계 전략

1. 모듈 계층화

   • 유사한 책임끼리 묶어 도메인 별 모듈로 구성
   • 각 모듈 내부는 Composite/Decorator 등으로 구조화

2. 인터페이스 표준화

   • 외부 통신용 API 에는 Adapter 및 Facade 중심 설계

3. 기능 확장성 고려

   • 새로운 로깅, 인증, 트랜잭션 처리 등은 Decorator 또는 Proxy 로 확장

4. 중앙 집중 팩토리 +Bridge 적용

   • 크로스 플랫폼 대응 등 플랫폼/통신 방식 변경 시 유리

5. 모니터링 및 성능 계층 분리

   • Proxy 를 사용해 지연 로딩, 캐싱 계층 도입

6. 문서화 + 시각화 자동화

   • UML 생성, JSON/YAML 메타데이터 기반 Echo 시스템 시각화

최적화하기 위한 고려사항 및 주의할 점

주제와 관련하여 주목할 내용

추가 학습 필요 내용

용어 정리

참고 및 출처

공식 문서 및 이론 기반

• Design Patterns: Elements of Reusable Object-Oriented Software (GoF 원서)
• Refactoring Guru - Structural Patterns
• SourceMaking - Structural Patterns
• Wikipedia - Structural Pattern (Computer Programming)
• Martin Fowler - Facade 패턴 활용

학습 플랫폼/튜토리얼

• DigitalOcean - Gang of Four (GoF) Design Patterns
• GeeksforGeeks - Structural Design Patterns
• TutorialsPoint - Design Patterns Overview
• Stack Abuse - Structural Design Patterns in Python
• Baeldung - Proxy, Decorator, Adapter and Bridge Patterns

실무 사례 및 블로그 아티클

• TuanHaDev Blog - Structural Design Pattern Guide
• Python Plain English - Structural Patterns Guide
• BePatterns - What are Structural Design Patterns?
• DEV.to - From Problems to Solutions: Design Patterns
• Java Code Geeks - Structural Patterns and Maintainability

기업/플랫폼 공식 문서 및 커뮤니티

• Spring Framework Reference - Proxy Pattern in AOP
• Microsoft Learn - Decorator Pattern
• PlantUML - 구조 설계 시각화 도구