Open/Closed Principle

Open/Closed Principle

Open/Closed Principle(개방 - 폐쇄 원칙, OCP) 은 SOLID 설계 원칙 중 하나로, 소프트웨어의 구성 요소 (클래스, 모듈, 함수 등) 는 " 확장에는 열려 있고, 변경에는 닫혀 있어야 한다 " 는 원칙이다. 즉, 새로운 기능이 필요할 때 기존 코드를 수정하지 않고 확장만으로 기능을 추가할 수 있도록 설계해야 한다. 이를 통해 시스템의 안정성, 유지보수성, 확장성을 확보하며, 다양한 디자인 패턴 (전략 패턴, 데코레이터 패턴 등) 과 추상화 기법을 활용해 실무에 적용된다.

핵심 개념

기본 개념

• 개방성 (Openness): 새로운 기능이나 동작을 추가하기 위한 확장 가능성
• 폐쇄성 (Closedness): 기존 코드의 수정 없이 안정성 유지
• 소프트웨어 엔티티 (Software Entity): 클래스 (Class), 모듈 (Module), 함수 (Function) 등
• 추상화 (Abstraction): 인터페이스나 추상 클래스를 통한 의존성 역전

심화 개념

• 다형적 개방 - 폐쇄 원칙 (Polymorphic OCP): 상속 대신 인터페이스 기반 구현
• 전략적 폐쇄 (Strategic Closure): 완전한 폐쇄는 불가능하므로 전략적 선택
• 의존성 역전 (Dependency Inversion): 구체적 구현이 아닌 추상화에 의존
• 느슨한 결합 (Loose Coupling): 독립적인 구현체들 간의 결합도 최소화

배경

Open/Closed Principle 의 역사적 발전 과정은 두 단계로 나뉜다:

Meyer 의 원래 정의 (1988)

Bertrand Meyer 가 1988 년 “Object-Oriented Software Construction” 저서에서 최초로 제시했다. Meyer 는 모듈이 확장에는 열려있고 사용에는 닫혀있어야 한다고 정의했으며, 이를 구현 상속 (Implementation Inheritance) 을 통해 달성하려 했다.

다형적 재정의 (1990 년대)

1990 년대에 Robert C. Martin 과 다른 연구자들이 상속의 문제점을 인식하고, 추상화된 인터페이스를 사용하는 " 다형적 개방 - 폐쇄 원칙 (Polymorphic Open/Closed Principle)" 으로 재정의했다. 이는 구현 상속 대신 인터페이스 기반 다형성을 활용한다.

목적 및 필요성

주요 목적

1. 코드 안정성 확보: 검증된 기존 코드의 수정 위험 최소화
2. 확장성 제공: 새로운 요구사항에 대한 유연한 대응
3. 유지보수성 향상: 변경 영향 범위 제한
4. 재사용성 증대: 모듈화된 컴포넌트의 재활용

필요성 배경

애플리케이션이 발전하면서 변경이 필요하게 되는데, 기존 코드를 수정하는 것은 애플리케이션 기능을 손상시킬 위험을 수반한다. 특히 기업 애플리케이션에서는 빠르게 변화하는 비즈니스 요구사항에 대응하기 위해 안전한 확장 방식이 필수적이다.

주요 기능 및 역할

핵심 기능

1. 확장 메커니즘: 새로운 구현체 추가를 통한 기능 확장
2. 캡슐화: 변경 가능한 부분과 안정적인 부분의 분리
3. 추상화 제공: 구체적 구현으로부터의 독립성
4. 다형성 구현: 런타임 시 적절한 구현체 선택

시스템에서의 역할

• 아키텍처 안정성: 핵심 구조의 변경 없는 기능 확장
• 개발 효율성: 기존 테스트 코드 재활용
• 품질 보증: 회귀 버그 (Regression Bug) 발생 위험 감소

특징

주요 특징

1. 이중적 성격: 동시에 열림과 닫힘을 만족
2. 추상화 의존: 인터페이스나 추상 클래스 활용 필수
3. 전략적 적용: 모든 변경에 대해 완전한 폐쇄는 불가능
4. 디자인 패턴 연계: 다양한 설계 패턴과 밀접한 관련

구현 특성

• 인터페이스 중심: 구체적 클래스보다 인터페이스에 의존
• 의존성 주입: 외부에서 구현체 제공
• 팩토리 활용: 객체 생성 로직 분리

핵심 원칙

1. 확장에 대한 개방성 (Open for Extension)

1
2
3

새로운 동작이나 기능을 추가할 수 있어야 함
              ↓
인터페이스나 추상 클래스를 통한 새로운 구현체 추가

2. 수정에 대한 폐쇄성 (Closed for Modification)

1
2
3

기존의 소스 코드를 변경하지 않아야 함
           ↓
검증된 코드의 안정성 보장

구조 및 아키텍처

아키텍처 다이어그램

graph TB
    subgraph "Client Layer"
        CL[Client Code]
    end
    
    subgraph "Abstraction Layer"
        INT[Interface/Abstract Class]
        FAC[Factory/Registry]
    end
    
    subgraph "Implementation Layer"
        IMPL1[Implementation 1]
        IMPL2[Implementation 2]
        IMPL3[Implementation 3]
        IMPLN[Implementation N]
    end
    
    CL --> INT
    CL --> FAC
    FAC --> INT
    
    INT --> IMPL1
    INT --> IMPL2
    INT --> IMPL3
    INT --> IMPLN
    
    style CL fill:#e1f5fe
    style INT fill:#f3e5f5
    style FAC fill:#fff3e0
    style IMPL1 fill:#e8f5e8
    style IMPL2 fill:#e8f5e8
    style IMPL3 fill:#e8f5e8
    style IMPLN fill:#e8f5e8

작동 원리

sequenceDiagram
    participant Client
    participant Factory
    participant Interface
    participant ConcreteImpl
    
    Client->>Factory: Request Implementation
    Factory->>ConcreteImpl: Create Instance
    Factory-->>Client: Return Interface Reference
    Client->>Interface: Call Method
    Interface->>ConcreteImpl: Delegate to Implementation
    ConcreteImpl-->>Interface: Return Result
    Interface-->>Client: Return Result

구현 기법

인터페이스 기반 구현 (Interface-based Implementation)

정의: 공통 인터페이스를 정의하고 여러 구현체를 제공하는 방식
구성:

• 인터페이스 정의
• 구체적 구현 클래스들
• 클라이언트 코드
  목적: 다형성을 통한 확장성 제공
  실제 예시:

 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

// 인터페이스 정의
public interface PaymentProcessor {
    void processPayment(double amount);
}

// 구현체들
public class CreditCardProcessor implements PaymentProcessor {
    public void processPayment(double amount) {
        // 신용카드 결제 로직
    }
}

public class PayPalProcessor implements PaymentProcessor {
    public void processPayment(double amount) {
        // PayPal 결제 로직
    }
}

// 클라이언트 코드
public class OrderService {
    private PaymentProcessor processor;
    
    public OrderService(PaymentProcessor processor) {
        this.processor = processor;
    }
    
    public void processOrder(double amount) {
        processor.processPayment(amount); // 수정 없이 확장 가능
    }
}

전략 패턴 구현 (Strategy Pattern Implementation)

정의: 알고리즘을 캡슐화하여 런타임에 선택할 수 있도록 하는 방식
구성:

• 전략 인터페이스
• 구체적 전략 클래스들
• 컨텍스트 클래스
  목적: 알고리즘의 동적 교체 및 확장
  실제 예시:

 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

// 전략 인터페이스
class SortingStrategy {
    sort(data) {
        throw new Error("Must implement sort method");
    }
}

// 구체적 전략들
class QuickSort extends SortingStrategy {
    sort(data) {
        // 퀵소트 구현
        return data.sort((a, b) => a - b);
    }
}

class MergeSort extends SortingStrategy {
    sort(data) {
        // 머지소트 구현
        return this.mergeSort(data);
    }
}

// 컨텍스트
class DataProcessor {
    constructor(strategy) {
        this.strategy = strategy;
    }
    
    processData(data) {
        return this.strategy.sort(data);
    }
}

플러그인 아키텍처 (Plugin Architecture)

정의: 핵심 시스템을 수정하지 않고 외부 모듈을 통해 기능을 확장하는 방식
구성:

• 핵심 프레임워크
• 플러그인 인터페이스
• 플러그인 로더
• 개별 플러그인들
  목적: 시스템 전체 재배포 없는 기능 확장
  실제 예시:

 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

class PluginInterface:
    def execute(self, data):
        raise NotImplementedError

class PluginManager:
    def __init__(self):
        self.plugins = {}
    
    def register_plugin(self, name, plugin):
        self.plugins[name] = plugin
    
    def execute_plugin(self, name, data):
        if name in self.plugins:
            return self.plugins[name].execute(data)

# 플러그인 구현
class DataValidationPlugin(PluginInterface):
    def execute(self, data):
        # 데이터 검증 로직
        return data.strip() if data else ""

class DataEncryptionPlugin(PluginInterface):
    def execute(self, data):
        # 데이터 암호화 로직
        return f"encrypted_{data}"

장점과 단점

단점 해결 방법

1. 점진적 적용: 처음부터 모든 부분에 적용하지 않고 변경 가능성이 높은 부분부터 적용
2. YAGNI 원칙 준수: “You Aren’t Gonna Need It” - 실제 필요할 때까지 추상화 지연
3. 성능 프로파일링: 성능이 중요한 부분에서는 측정 후 적용 여부 결정
4. 문서화 강화: 추상화 의도와 사용법을 명확히 문서화

도전 과제

분류 기준에 따른 종류 및 유형

실무 적용 예시

OCP 위반 및 해결 예제

OCP 위반 예제

 1
 2
 3
 4
 5
 6
 7
 8
 9
10

# discount_service.py

class DiscountService:
    def calculate_discount(self, user_type, price):
        if user_type == "regular":
            return price - 1000
        elif user_type == "vip":
            return price * 0.9
        else:
            return price

• 새로운 사용자 타입이 생기면 if-elif 분기 수정 필요 → OCP 위반

OCP 적용 예제: 전략 패턴 사용

 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

from abc import ABC, abstractmethod

# 추상화 계층
class DiscountPolicy(ABC):
    @abstractmethod
    def calculate(self, price: int) -> int:
        pass

# 구체 구현
class RegularDiscount(DiscountPolicy):
    def calculate(self, price: int) -> int:
        return price - 1000

class VipDiscount(DiscountPolicy):
    def calculate(self, price: int) -> int:
        return int(price * 0.9)

# 클라이언트
class DiscountService:
    def __init__(self, policy: DiscountPolicy):
        self.policy = policy

    def apply_discount(self, price: int) -> int:
        return self.policy.calculate(price)

# 사용 예시
service = DiscountService(VipDiscount())
print(service.apply_discount(10000))  # 출력: 9000

인터페이스 기반 테스트 구조

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

# test_discount_service.py

from unittest import TestCase
from discount_service import DiscountService, RegularDiscount, VipDiscount

class TestDiscountService(TestCase):
    def test_regular_discount(self):
        service = DiscountService(RegularDiscount())
        self.assertEqual(service.apply_discount(10000), 9000)

    def test_vip_discount(self):
        service = DiscountService(VipDiscount())
        self.assertEqual(service.apply_discount(10000), 9000)

• 핵심 포인트: 구현 변경 없이 테스트 유지 가능
• 전략 교체만으로 테스트 시나리오 추가 가능

전략 패턴 기반 구조:

classDiagram
    class DiscountPolicy {
        <<interface>>
        +calculate(price)
    }

    class RegularDiscount
    class VipDiscount
    class DiscountService {
        -policy: DiscountPolicy
        +applyDiscount(price)
    }

    DiscountPolicy <|.. RegularDiscount
    DiscountPolicy <|.. VipDiscount
    DiscountService --> DiscountPolicy

활용 사례

사례 1: 결제 시스템

시나리오: 결제 시스템에서 다양한 결제 수단 (카드, 페이팔 등) 을 지원해야 하며, 새로운 결제 방식이 추가될 수 있음.
구성: PaymentStrategy 인터페이스, 각 결제 방식별 구현체, 클라이언트는 인터페이스만 의존.

시스템 다이어그램

classDiagram
    class PaymentStrategy {
      >
      +pay()
    }
    class CardPayment {
      +pay()
    }
    class PaypalPayment {
      +pay()
    }
    PaymentStrategy  PaymentStrategy

Workflow:

1. PaymentProcessor 는 PaymentStrategy 인터페이스만 의존
2. 새로운 결제 방식 추가 시, PaymentStrategy 구현체만 추가
3. 기존 PaymentProcessor 코드 수정 없이 확장

사례 2: 전자상거래 플랫폼의 할인 정책 확장

시나리오: 기존에는 고정 할인 정책만 있었지만, VIP 등급을 위한 비율 할인 정책을 추가해야 함.

기존 설계의 문제

• 할인 로직이 OrderService 에 하드코딩되어 있어 변경 시 서비스 코드 수정 필요 → OCP 위반

리팩토링 구조

classDiagram
    class DiscountPolicy {
        +calculate(price: int): int
    }
    class FixedDiscount
    class RateDiscount
    class OrderService {
        -DiscountPolicy policy
        +OrderService(policy: DiscountPolicy)
        +applyDiscount(price: int): int
    }

    DiscountPolicy <|.. FixedDiscount
    DiscountPolicy <|.. RateDiscount
    OrderService --> DiscountPolicy

Workflow:

1. OrderService 는 DiscountPolicy 에만 의존
2. FixedDiscount 또는 RateDiscount 를 주입하여 동작 결정
3. 새로운 할인 정책이 생겨도 OrderService 는 변경 없음

사례 3: E-commerce 주문 처리 시스템

시나리오: 온라인 쇼핑몰에서 다양한 결제 방식과 배송 옵션을 지원하는 주문 처리 시스템 구축

시스템 구성:

graph TB
    subgraph "주문 처리 시스템"
        OS[OrderService]
        OP[OrderProcessor]
    end
    
    subgraph "결제 모듈"
        PI[PaymentInterface]
        CC[CreditCardPayment]
        PP[PayPalPayment]
        KC[KakaoPayment]
    end
    
    subgraph "배송 모듈"
        SI[ShippingInterface]
        RS[RegularShipping]
        ES[ExpressShipping]
        DS[DroneShipping]
    end
    
    subgraph "알림 모듈"
        NI[NotificationInterface]
        EM[EmailNotification]
        SM[SMSNotification]
        PN[PushNotification]
    end
    
    OS --> OP
    OP --> PI
    OP --> SI
    OP --> NI
    
    PI --> CC
    PI --> PP
    PI --> KC
    
    SI --> RS
    SI --> ES
    SI --> DS
    
    NI --> EM
    NI --> SM
    NI --> PN

Workflow:

sequenceDiagram
    participant C as Customer
    participant OS as OrderService
    participant PF as PaymentFactory
    participant SF as ShippingFactory
    participant NF as NotificationFactory
    participant P as PaymentProcessor
    participant S as ShippingProcessor
    participant N as NotificationProcessor
    
    C->>OS: Place Order
    OS->>PF: Get Payment Processor
    PF-->>OS: Return Payment Instance
    OS->>P: Process Payment
    P-->>OS: Payment Success
    
    OS->>SF: Get Shipping Processor
    SF-->>OS: Return Shipping Instance
    OS->>S: Arrange Shipping
    S-->>OS: Shipping Arranged
    
    OS->>NF: Get Notification Processor
    NF-->>OS: Return Notification Instance
    OS->>N: Send Confirmation
    N-->>OS: Notification Sent
    
    OS-->>C: Order Confirmed

Open/Closed Principle 의 역할:

1. 확장성: 새로운 결제수단 (암호화폐 결제) 추가 시 기존 OrderService 코드 변경 없음
2. 안정성: 검증된 핵심 주문 처리 로직 보호
3. 유연성: 지역별 요구사항에 따른 다른 구현체 제공 가능
4. 테스트: 각 모듈 독립적 테스트 및 모킹 가능

실무 적용 고려사항 및 권장사항

최적화 고려사항 및 권장사항

OCP 적용 시 발생 가능한 문제 및 해결 방안

주목할 내용 정리

하위 주제로 분류해서 추가적으로 학습해야할 내용들

추가로 알아야 하거나 학습해야할 내용들

용어 정리

설계 원칙 (Design Principles)

객체지향 프로그래밍 핵심 개념 (OOP Core Concepts)

디자인 패턴 (Design Patterns)

아키텍처 및 구현 구조 (Architecture & Structural Concepts)

시스템 아키텍처 (System Architecture)

소프트웨어 공학 개념 (Software Engineering)

참고 및 출처

공식 문서 / 업계 권위

• Martin Fowler - Open/Closed Principle
• Microsoft Learn - Patterns in Practice: The Open Closed Principle
• Spring Framework Docs - Strategy Pattern 사용 사례
• NestJS Docs - Module, Provider 구조

개념 및 원칙 설명 (전문 사이트)

• Refactoring Guru - Open/Closed Principle
• freeCodeCamp - Open-Closed Principle Explained
• DigitalOcean - SOLID: First 5 Principles
• GeeksforGeeks - SOLID Principles with Real-Life Examples
• Stackify - Open/Closed Principle with Code Examples
• DZone - The Open/Closed Principle and Strategy Pattern
• Baeldung - SOLID Principles in Java
• David Skyspace - Open/Closed Principle 설명

실습/예제 중심 블로그

• Spring Framework Guru - Open Closed Principle
• Javarevisited - Strategy Pattern and OCP in Java