105. ISP (Interface Segregation Principle, 인터페이스 분리 원칙)

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

ISP 정의: 클라이언트는 자신이 사용하지 않는 메서드에 의존하도록 강제되어서는 안 됩니다. 즉, 인터페이스는 작고 구체적으로 분리되어야 합니다.
비대한 인터페이스 방지: 하나의 뚱뚱한(Fat) 인터페이스 대신 여러 개의 특화된 인터페이스로 쪼개어, 구현 클래스의 부담을 줄입니다.
변경의 영향 최소화: 불필요한 의존성을 끊어내어, 한 기능의 변경이 사용하지도 않는 다른 클라이언트에게 영향을 미치는 부작용을 막습니다.

Ⅰ. 개요 (Context & Background)

인터페이스 분리 원칙(ISP)은 SOLID의 'I'에 해당하는 원칙으로, 로버트 C. 마틴이 제안했습니다. 여러 클라이언트가 사용할 수 있는 범용적이고 방대한 단일 인터페이스(God Interface)를 만들면, 어떤 클라이언트는 전혀 쓰지 않는 잉여 메서드까지 억지로 구현(Override)해야 하는 상황이 발생합니다. ISP는 이를 역할별로 잘게 쪼개어 응집도를 높이고 결합도를 낮출 것을 주문합니다.

Ⅱ. 아키텍처 및 핵심 원리 (Deep Dive)

인터페이스는 그 인터페이스를 사용하는 클라이언트 관점에서 설계되어야 합니다.

[ ISP Violation - Fat Interface ]
+-----------------------------------+
|     MultiFunctionDevice (MFD)     |
| + print()                         |
| + scan()                          |
| + fax()                           |
+-----------------------------------+
      ^                       ^
      |                       |
+-----|-----+           +-----|-----+
|  Copier   |           |  Printer  | -> fax(), scan()을 쓰지 않지만
| (All in 1)|           | (Only Prt)|    강제로 빈 메서드 구현 필요
+-----------+           +-----------+

[ ISP Compliant - Segregated Interfaces ]
+-----------+   +-----------+   +--------+
|  Printer  |   |  Scanner  |   |  Fax   |
| + print() |   | + scan()  |   | +fax() |
+-----------+   +-----------+   +--------+
      ^               ^             ^
      |---------------|-------------| (Copier implements all three)
                      |
                +-----------+ (Simple Printer implements ONLY Printer)

비대한 인터페이스는 구현체에게 불필요한 더미(Dummy) 코드 생성을 강요하며, 인터페이스 하나가 변경될 때 연관 없는 클래스까지 전부 다시 컴파일되어야 하는 샷건 수술(Shotgun Surgery) 문제를 야기합니다.

Ⅲ. 융합 비교 및 다각도 분석 (Comparison & Synergy)

비교 항목	ISP (인터페이스 분리 원칙)	SRP (단일 책임 원칙)
초점	'클라이언트' 관점에서의 인터페이스(행위) 분리	'클래스' 내부 관점에서의 역할(책임) 분리
적용 대상	객체 간의 통신 접점(Interface)	클래스나 모듈의 내부 구조 및 변경 이유
해결 문제	불필요한 의존성에 의한 재컴파일 및 런타임 예외 (NotSupportedException) 방지	하나의 클래스가 여러 이유로 변경되며 발생하는 결합도 증가 문제 방지
관계	인터페이스가 분리되면 자연스럽게 이를 구현하는 클래스의 책임도 분산되어 SRP를 돕게 됨	SRP가 잘 지켜진 클래스는 보통 작고 구체적인 ISP 기반 인터페이스를 가짐

Ⅳ. 실무 적용 및 기술사적 판단 (Strategy & Decision)

레거시 리팩토링: 이미 비대해진 레거시 클래스를 당장 쪼개기 힘들다면, 클라이언트 쪽에서 접근할 때 작은 인터페이스 여러 개로 해당 클래스를 래핑(Wrapping/Adapter)하여 보여주는 기법을 적용할 수 있습니다.
기술사적 설계 기준: SOA나 마이크로서비스(MSA) 환경의 API 설계 시에도 ISP 원칙을 차용하여, 컨슈머(클라이언트)별로 필요한 데이터만 반환하는 BFF(Backend For Frontend) 패턴 등을 결합하면 시스템 전반의 통신 효율을 극대화할 수 있습니다.

Ⅴ. 기대효과 및 결론 (Future & Standard)

ISP를 적용하면 시스템의 결합도를 획기적으로 낮추고, 변경에 유연하게 대응할 수 있는 가벼운 코드 구조를 만들 수 있습니다. 클라이언트 맞춤형 인터페이스 설계는 테스트 용이성(Mocking)을 크게 향상시키며, 클린 아키텍처를 지탱하는 굳건한 뼈대가 됩니다.

📌 관련 개념 맵 (Knowledge Graph)

상위 개념: SOLID 원칙, 객체지향 설계
하위/연관 개념: SRP(단일 책임 원칙), 파사드(Facade) 패턴, 어댑터(Adapter) 패턴, BFF(Backend For Frontend)

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

스위스 아미 나이프(만능칼)는 가위, 톱, 칼이 다 있어서 무겁고 쓰기 복잡해요.
그냥 종이를 자르고 싶은 아이에게는 무거운 만능칼 대신 '가위'만 딱 주는 게 훨씬 안전하고 편리해요.
이처럼 쓸데없는 기능까지 잔뜩 묶어서 주지 말고, 딱 필요한 도구(인터페이스)만 분리해서 제공하자는 것이 ISP랍니다.