소프트웨어 설계 원칙: Python에서 적용하는 방법

Source: Dev.to

디자인 원칙이 중요한 이유

작은 프로젝트를 만든 뒤 6개월이 지나서 버그를 고치거나 기능을 추가하려고 한다고 상상해 보세요. 코드가 엉망이라면 무슨 일이 일어나고 있는지 파악하는 데 더 많은 시간을 쓰게 되고, 실제 문제를 해결하는 데는 시간이 부족해집니다. 좋은 디자인 원칙은 코드를 다음과 같이 만들어 줍니다:

• 읽기 쉬움
• 유지보수가 쉬움
• 미래의 변화에 유연함

가장 흔히 쓰이는 디자인 원칙 집합은 SOLID 입니다:

• Single Responsibility Principle (SRP) – 각 클래스나 함수는 하나의 역할만 가져야 합니다.
• Open/Closed Principle (OCP) – 클래스는 확장은 열려 있어야 하지만, 수정은 닫혀 있어야 합니다.
• Liskov Substitution Principle (LSP) – 서브클래스는 부모 클래스를 대체해도 프로그램이 깨지 않아야 합니다.
• Interface Segregation Principle (ISP) – 클래스가 필요 없는 메서드를 구현하도록 강요하지 않아야 합니다.
• Dependency Inversion Principle (DIP) – 고수준 모듈은 구체적인 저수준 모듈이 아니라 추상화에 의존해야 합니다.

파이썬 실전 예제

구체적으로 설명하기 위해, 사용자가 이메일이나 SMS로 알림을 받을 수 있는 알림 시스템을 만든다고 가정해 보겠습니다. 디자인 원칙을 적용하는 방법은 다음과 같습니다:

from abc import ABC, abstractmethod

# Interface defining what a Notifier should do
class Notifier(ABC):
    @abstractmethod
    def send(self, message: str):
        pass

# SRP: Each notifier has a single responsibility
class EmailNotifier(Notifier):
    def send(self, message: str):
        print(f"Sending email: {message}")

class SMSNotifier(Notifier):
    def send(self, message: str):
        print(f"Sending SMS: {message}")

# OCP & DIP: NotificationService works with any notifier
class NotificationService:
    def __init__(self, notifiers: list[Notifier]):
        self.notifiers = notifiers

    def notify_all(self, message: str):
        for notifier in self.notifiers:
            notifier.send(message)

# Using the system
email = EmailNotifier()
sms = SMSNotifier()
service = NotificationService([email, sms])
service.notify_all("Your order has been shipped!")

원칙 적용 방식

• SRP: 각 클래스는 하나의 작업(이메일 전송 또는 SMS 전송)만 담당합니다.
• OCP: 새로운 알림 채널(예: WhatsApp)을 NotificationService를 수정하지 않고도 추가할 수 있습니다.
• DIP & ISP: NotificationService는 구체적인 클래스가 아니라 Notifier 인터페이스에 의존합니다.

이 구조는 시스템을 유연하게, 확장하기 쉽게, 그리고 깨끗하게 유지해 주며, 규모가 커져도 관리가 용이합니다.

결론

디자인 원칙을 적용하는 것은 단순한 권고사항이 아니라 코드의 품질과 수명을 위한 투자입니다. SRP, OCP, DIP 및 기타 SOLID 원칙을 따르면 코드를 이해하기 쉬워지고, 수정이 안전해지며, 확장성이 높아집니다.

목표는 오늘 작동하는 소프트웨어를 만드는 것에 그치지 않고, 내일도 복잡함 없이 성장하고 적응할 수 있는 시스템을 구축하는 것입니다. 처음부터 이러한 원칙을 채택하면 프로젝트가 더 깔끔해지고, 변경이 간단해지며, 협업도 원활해집니다.