Interface Segregation Principle

Interface Segregation Principle

인터페이스 분리 원칙 (ISP, Interface Segregation Principle) 은 SOLID 설계 원칙 중 하나로, 클라이언트가 자신이 사용하지 않는 메서드에 의존하지 않도록 인터페이스를 작고 특정 목적에 맞게 분리하는 것을 강조한다. 하나의 커다란 인터페이스를 여러 개의 구체적이고 목적에 맞는 작은 인터페이스로 분리함으로써 클라이언트가 불필요한 의존성을 갖지 않도록 하는 객체지향 설계 원칙이다.
ISP 를 적용하면 불필요한 의존성과 구현을 방지하고, 시스템의 모듈화, 유지보수성, 테스트 용이성, 유연성이 크게 향상된다. ISP 는 대규모 시스템, 마이크로서비스, 프론트엔드 컴포넌트 뿐만 아니라 실무의 API 설계, 모듈화, 리팩토링 과정에서 널리 적용된다.

핵심 개념

클라이언트 (사용자, 구현 클래스) 가 사용하지 않는 메서드에 의존하거나 구현을 강요받지 않도록, 인터페이스를 작고 구체적으로 분리하는 설계 원칙이다.

기본 개념

• 인터페이스 분리: 큰 인터페이스를 작고 구체적인 역할별 인터페이스로 나누는 것
• 클라이언트 특화: 각 클라이언트가 실제로 사용하는 메서드만 포함하는 인터페이스 제공
• 의존성 최소화: 불필요한 메서드에 대한 의존성을 제거하여 결합도 감소

심화 개념

• 역할 인터페이스 (Role Interface): 분리된 작은 단위의 인터페이스
• 컴포지션을 통한 통합: 여러 작은 인터페이스를 조합하여 복합 기능 제공
• 어댑터 패턴 연계: 레거시 인터페이스 적용 시 ISP 위반 해결 방안

배경 및 목적

배경:

• Robert C. Martin 이 1996 년 C++ Report 에서 최초 제시
• Xerox 프린터 소프트웨어 개발 과정에서 발견된 문제 해결을 위해 고안
• 대규모 소프트웨어 시스템에서 인터페이스 비대화 문제 해결 필요성 대두

목적 및 필요성:

• 클라이언트의 불필요한 의존성 제거
• 시스템의 결합도 감소 및 응집도 향상
• 인터페이스 변경 시 영향 범위 최소화
• 코드의 재사용성 및 테스트 용이성 향상

주요 기능 및 역할

핵심 기능:

• 인터페이스의 역할별 분리
• 클라이언트별 최적화된 인터페이스 제공
• 필요 없는 메서드 구현 강요 방지
• 시스템 간 느슨한 결합 구현
• 변경 영향도 격리

주요 역할:

• 시스템 복잡도 관리
• 코드 유지보수성 향상
• 개발 생산성 증대
• 시스템 확장성 보장

특징

• 결합도 감소: 불필요한 의존성 제거.
• 모듈화: 각 역할별로 인터페이스 분리.
• 유지보수성·확장성·테스트 용이성: 코드 변경/확장/테스트가 쉬움.

작동 원리

graph TD
    A[큰 인터페이스] --> B[인터페이스 분석]
    B --> C[역할별 분류]
    C --> D[작은 인터페이스들]
    D --> E[클라이언트별 구현]
    
    F[클라이언트 A] --> G[인터페이스 A]
    H[클라이언트 B] --> I[인터페이스 B]
    J[클라이언트 C] --> K[인터페이스 C]
    
    G --> L[구현체]
    I --> L
    K --> L

핵심 원칙:

1. 분리의 원칙: " 하나의 일반적인 인터페이스보다 여러 개의 구체적인 인터페이스가 낫다 "
2. 최소 의존성 원칙: 클라이언트는 사용하지 않는 메서드에 의존하지 않아야 함
3. 역할 기반 설계: 각 인터페이스는 명확한 역할과 책임을 가져야 함

작동 과정:
4. 기존 큰 인터페이스의 메서드들을 역할별로 분석
5. 클라이언트의 사용 패턴에 따라 인터페이스 분류
6. 각 역할에 맞는 작은 인터페이스 생성
7. 클라이언트는 필요한 인터페이스만 의존
8. 구현체에서 여러 인터페이스를 조합하여 구현

다이어그램

• Fat Interface: 여러 역할을 한 인터페이스에 몰아넣으면, 불필요한 메서드 구현, 예외 처리, 결합도 증가, 코드 복잡성 유발.
• 역할별 인터페이스 분리: 각 역할 (프린트, 스캔, 팩스 등) 별로 인터페이스를 분리하여, 필요한 기능만 구현하도록 설계.

classDiagram
    class LargeInterface {
        +method1()
        +method2()
        +method3()
        +method4()
    }
    
    class RoleInterfaceA {
        +method1()
        +method2()
    }
    
    class RoleInterfaceB {
        +method3()
        +method4()
    }
    
    class Implementation {
        +method1()
        +method2()
        +method3()
        +method4()
    }
    
    class ClientA {
    }
    
    class ClientB {
    }
    
    ClientA --> RoleInterfaceA
    ClientB --> RoleInterfaceB
    Implementation ..|> RoleInterfaceA
    Implementation ..|> RoleInterfaceB

구성요소 정리 (Interface Segregation Principle 관점)

구현 기법

인터페이스 분리 기법

정의: 큰 인터페이스를 역할별로 나누는 기법
구성: 기존 인터페이스 분석 → 역할 분류 → 작은 인터페이스 생성
목적: 클라이언트별 최적화된 인터페이스 제공

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

// ISP 위반 예시
interface MultifunctionDevice {
    void print();
    void scan();
    void fax();
    void copy();
}

// ISP 적용 예시
interface Printer {
    void print();
}

interface Scanner {
    void scan();
}

interface FaxMachine {
    void fax();
}

interface Copier {
    void copy();
}

역할 기반 인터페이스 설계

정의: 각 인터페이스가 명확한 역할을 갖도록 설계
구성: 역할 정의 → 책임 할당 → 인터페이스 명세
목적: 높은 응집도와 낮은 결합도 달성

컴포지션 패턴 적용

정의: 여러 작은 인터페이스를 조합하여 복합 기능 제공
구성: 기본 인터페이스들 → 조합 로직 → 통합 인터페이스
목적: 유연한 기능 확장 및 재사용성 향상

장점과 단점

단점 해결 방법

• 자동화 도구 활용: IDE 의 리팩토링 기능을 활용한 인터페이스 분리 자동화
• 점진적 적용: 기존 시스템에 단계적으로 ISP 적용
• 문서화 강화: 인터페이스 간 관계와 역할을 명확히 문서화
• 패키지 구조화: 관련 인터페이스들을 논리적으로 그룹화

도전 과제

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

실무 적용 예시

ISP 위반 예제

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

# device.py
from abc import ABC, abstractmethod

class ISmartDevice(ABC):
    @abstractmethod
    def turn_on(self):
        pass

    @abstractmethod
    def turn_off(self):
        pass

    @abstractmethod
    def set_temperature(self, temp):
        pass

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

# light.py
from device import ISmartDevice

class Light(ISmartDevice):
    def turn_on(self):
        print("Light turned on.")

    def turn_off(self):
        print("Light turned off.")

    def set_temperature(self, temp):
        raise NotImplementedError("Light does not support temperature control.")

문제점:

• Light 클래스는 set_temperature() 를 구현해야 하지만 실제로는 해당 기능이 없음
• 이는 ISP 위반. 필요하지 않은 기능에 대한 강제 의존 발생

ISP 를 적용한 개선

역할별 인터페이스 분리

1. 인터페이스 정의

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

   # interfaces.py from abc import ABC, abstractmethod class IControllable(ABC): @abstractmethod def turn_on(self): pass @abstractmethod def turn_off(self): pass class IHeatable(ABC): @abstractmethod def set_temperature(self, temp): pass

2. 구현 클래스

   1 2 3 4 5 6 7 8 9

   # light.py from interfaces import IControllable class Light(IControllable): def turn_on(self): print("Light turned on.") def turn_off(self): print("Light turned off.")

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

   # boiler.py from interfaces import IControllable, IHeatable class Boiler(IControllable, IHeatable): def turn_on(self): print("Boiler turned on.") def turn_off(self): print("Boiler turned off.") def set_temperature(self, temp): print(f"Boiler temperature set to {temp}°C.")

3. 사용 예 (main.py)

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

   # main.py from light import Light from boiler import Boiler def activate_device(device): device.turn_on() def heat_device(heater): heater.set_temperature(60) light = Light() boiler = Boiler() activate_device(light) # OK activate_device(boiler) # OK heat_device(boiler) # OK # heat_device(light) # 타입 검사 시 오류 가능 (정적 타입 도구에서)

활용 사례

사례 1: 스마트 홈 시스템

시나리오: 다양한 기기 (조명, 보일러, 도어락 등) 를 제어해야 하며, 각 기기는 기능이 상이함
문제: ISmartDevice 에 모든 기능을 넣으면, 불필요한 기능도 구현해야 함

시스템 구성도:

classDiagram
    class IControllable {
        +turnOn()
        +turnOff()
    }

    class IHeatable {
        +setTemperature(temp)
    }

    class Light {
    }

    class Boiler {
    }

    Light ..|> IControllable
    Boiler ..|> IControllable
    Boiler ..|> IHeatable

효과:

• Light 는 온/오프만 구현
• Boiler 는 온/오프와 온도 설정 기능 모두 구현

Workflow:

1. 사용자가 스마트폰 앱에서 turnOn 클릭
2. 각 기기 인터페이스에 맞게 명령 분기
3. 클라이언트는 필요한 기능만 호출

사례 2: 복합기와 단일 프린터

시나리오: 복합기 (프린터, 스캐너, 팩스 기능) 와 단일 프린터가 공존하는 시스템
구성: Printable, Scannable, Faxable 인터페이스 분리, 각 장치가 필요한 인터페이스만 구현

시스템 다이어그램:

classDiagram
    class Printable {
      +print()
    }
    class Scannable {
      +scan()
    }
    class Faxable {
      +fax()
    }
    class SimplePrinter {
      +print()
    }
    class MultiFunctionPrinter {
      +print()
      +scan()
      +fax()
    }
    SimplePrinter --|> Printable
    MultiFunctionPrinter --|> Printable
    MultiFunctionPrinter --|> Scannable
    MultiFunctionPrinter --|> Faxable

Workflow:

1. SimplePrinter 는 Printable 만 구현
2. MultiFunctionPrinter 는 Printable, Scannable, Faxable 모두 구현
3. 각 장치는 필요한 기능만 구현하며, 불필요한 메서드 구현 없음

사례 3: 전자상거래 플랫폼

시나리오: 대규모 전자상거래 플랫폼에서 주문 관리 시스템 구축
시스템 구성

• 주문 생성 서비스
• 결제 처리 서비스
• 재고 관리 서비스
• 배송 관리 서비스
• 고객 알림 서비스

graph LR
    A[주문 관리 시스템] --> B[주문 생성 인터페이스]
    A --> C[결제 처리 인터페이스]
    A --> D[재고 관리 인터페이스]
    A --> E[배송 관리 인터페이스]
    A --> F[알림 인터페이스]
    
    B --> G[주문 생성 서비스]
    C --> H[결제 처리 서비스]
    D --> I[재고 관리 서비스]
    E --> J[배송 관리 서비스]
    F --> K[고객 알림 서비스]

Workflow

1. 고객이 주문 요청
2. 주문 생성 인터페이스를 통해 주문 정보 생성
3. 결제 처리 인터페이스로 결제 진행
4. 재고 관리 인터페이스로 재고 차감
5. 배송 관리 인터페이스로 배송 준비
6. 알림 인터페이스로 고객에게 상태 알림

ISP 역할:

• 각 서비스가 자신의 책임에만 집중
• 다른 서비스의 변경이 영향을 주지 않음
• 새로운 기능 추가 시 해당 인터페이스만 확장

실무 적용 고려사항 및 주의점

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

ISP 관련 문제점 및 해결 방안

Fat Interface

문제 코드 예시:

1
2
3
4
5

class Animal:
    def fly(self): …
    def walk(self): …
    def swim(self): …
    def bark(self): …

모든 동물이 fly(), swim() 을 구현해야 하는 문제 발생

개선 코드 (ISP 적용):

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

from abc import ABC, abstractmethod

class Walkable(ABC):
    @abstractmethod
    def walk(self): pass

class Swimmable(ABC):
    @abstractmethod
    def swim(self): pass

class Dog(Walkable):
    def walk(self):
        print("Dog walks")

class Fish(Swimmable):
    def swim(self):
        print("Fish swims")

해결 전략:

• 인터페이스를 능력 (역할) 단위로 분리
• ISP (인터페이스 분리 원칙) 준수

순환 의존성

문제 코드 예시 (모듈 A ⇄ B 순환):

1
2
3
4
5

# module_a.py
from module_b import ServiceB

class ServiceA:
    def __init__(self, b: ServiceB): …

1
2
3
4
5

# module_b.py
from module_a import ServiceA

class ServiceB:
    def __init__(self, a: ServiceA): …

해결 코드 (DIP + 중재자 패턴):

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

# mediator.py
class Mediator:
    def __init__(self):
        self.a = None
        self.b = None

    def register_a(self, a): self.a = a
    def register_b(self, b): self.b = b

# service_a.py
class ServiceA:
    def __init__(self, mediator):
        self.mediator = mediator
        mediator.register_a(self)

# service_b.py
class ServiceB:
    def __init__(self, mediator):
        self.mediator = mediator
        mediator.register_b(self)

해결 전략:

• DIP (Dependency Inversion Principle)
• Mediator 패턴을 통한 간접 참조

인터페이스 일관성 부족

문제 예시:

1
2
3
4

# user_service.py
class UserService:
    def getUser(): …
    def create_user(): …

메서드 네이밍 불일치로 혼란 초래

개선 예시 (일관된 네이밍):

1
2
3

class UserService:
    def get_user(self): …
    def create_user(self): …

해결 전략:

• 네이밍 컨벤션 (snake_case, PascalCase 등) 팀 표준화
• 코드 리뷰 프로세스 강화

타입/인터페이스 폭발

문제 예시:

1
2
3
4

class AdminUserService: …
class NormalUserService: …
class GuestUserService: …
# 모두 거의 동일한 기능

개선 코드:

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

class BaseUserService(ABC):
    @abstractmethod
    def get_permissions(self): …

class UnifiedUserService(BaseUserService):
    def __init__(self, role): self.role = role

    def get_permissions(self):
        if self.role == "admin":
            return ["read", "write", "delete"]
        elif self.role == "guest":
            return ["read"]

해결 전략:

• 전략 (Strategy) 패턴 또는 공통 베이스 클래스로 통합
• 역할 기반 처리 로직으로 단순화

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

추가 학습 내용

용어 정리

참고 및 출처

공식 문서 & 저명한 참고서

• Martin Fowler - Interface Segregation Principle
• Robert C. Martin - SOLID Principles Explained
• Clean Architecture by Uncle Bob
• Effective Java - Joshua Bloch

백과사전 및 대형 커뮤니티

• Interface segregation principle - Wikipedia
• 인터페이스 분리 원칙 - 위키백과 (한국어)
• SOLID Principles - GeeksforGeeks
• Refactoring Guru - Interface Segregation Principle

실무 블로그 및 커뮤니티 글

• SOLID: I - Interface Segregation Principle (DEV)
• Unleashing the Power of Interface Segregation (DEV)
• SOLID - 인터페이스 분리 원칙 - 더블에스 Devlog
• Interface Segregation Principle 설명 - ITCode Dev Blog
• 인터페이스 분리의 원칙 - IT 위키
• Interface Segregation Principle - blog.ramoo.net
• 파이썬 인터페이스 분리 원칙 - Velog

기술 문서 & 튜토리얼

• SOLID: The First 5 Principles of Object Oriented Design - DigitalOcean
• What is Interface Segregation Principle - Startup House
• Interface Segregation with Code Examples - Stackify
• Interface Segregation Principle in Java - Baeldung
• Interface Segregation Principle (ISP) – SOLID Principles in Java - LinkedIn
• SOLID Design Principles Explained: Interface Segregation - DZone
• The Interface Segregation Principle - TheServerSide

국내 추가 자료

• SOLID 원칙 - Interface Segregation Principle - Joonas.io
• 객체지향 개발 5대 원리: SOLID - Nextree
• 마이크로서비스 아키텍처 국내 도입 사례 - Channy’s Blog