Apr 3, 2026

ISP 가이드: 인터페이스 분리 원칙은 왜 필요한가

SOLID 중 ISP, 인터페이스 분리 원칙은 처음엔 덜 눈에 띄지만, 실제로는 “역할이 너무 큰 인터페이스”가 왜 문제인지 잘 설명해주는 원칙입니다. 특히 하나의 인터페이스에 너무 많은 기능이 몰리기 시작하면 구현체와 호출부가 함께 불편해지기 쉽습니다.

이 글에서는 아래 내용을 정리합니다.

ISP가 무엇인지
왜 큰 인터페이스가 문제인지
역할별 인터페이스가 왜 더 나은지

핵심은 클라이언트는 자신이 쓰지 않는 메서드에 의존하지 않도록 인터페이스를 역할별로 나누는 것이 더 유연하다는 점입니다.

ISP란 무엇인가

간단히 말하면:

너무 큰 인터페이스 하나보다
필요한 역할에 맞는 작은 인터페이스 여러 개가 더 낫다

는 원칙입니다.

즉, 어떤 구현체나 호출자가 실제로 쓰지 않는 메서드까지 억지로 의존하게 만들지 말자는 뜻입니다.

왜 큰 인터페이스가 문제일까

인터페이스가 지나치게 커지면:

어떤 구현체는 필요 없는 메서드까지 구현해야 하고
호출자는 자신과 무관한 기능 변화에도 영향을 받을 수 있으며
역할 경계가 흐려집니다

즉, 추상화가 오히려 잡음이 되는 상황이 생길 수 있습니다.

역할별로 나누면 어떤 장점이 있을까

필요한 기능만 구현하게 됨
변경 영향이 줄어듦
테스트 대상이 더 명확해짐
구현과 사용 관계가 자연스러워짐

즉, ISP는 인터페이스를 “크게 하나 만들기”보다 “사용 관점에 맞게 자르기”에 더 가깝습니다.

입문자는 어떻게 이해하면 좋을까

아래 질문이 도움이 됩니다.

이 인터페이스를 구현하는 객체가 모든 메서드를 정말 자연스럽게 가져야 하는가
어떤 호출자는 이 메서드들 중 일부만 쓰는가
역할이 두세 개 이상 섞여 있지는 않은가

이 질문에 “아니다”가 많아지면 ISP를 떠올려볼 만합니다.

자주 하는 오해

1. 인터페이스는 무조건 작을수록 좋다

너무 잘게 쪼개면 오히려 관리가 복잡해질 수 있습니다.

2. ISP는 인터페이스를 많이 만들라는 뜻이다

핵심은 개수가 아니라 역할과 사용 관계가 자연스러운가입니다.

3. 구현체가 하나뿐이면 ISP는 의미 없다

지금 하나뿐이어도 역할이 섞여 있으면 미래의 변경 비용이 커질 수 있습니다.

FAQ

Q. 인터페이스를 어디 기준으로 나누면 좋을까

기능 자체보다 “누가 무엇을 사용하는가” 기준으로 보면 좋습니다.

Q. 너무 잘게 나누는 것이 걱정된다

그럴 수 있습니다. 작은 역할 단위가 자연스럽게 느껴질 정도까지만 나누는 것이 좋습니다.

Q. ISP와 SRP는 비슷한가

연결은 되지만 초점이 다릅니다. SRP는 책임, ISP는 인터페이스 사용 관점에 더 가깝습니다.

먼저 읽어볼 가이드

검색 유입이 많은 핵심 글부터 이어서 보세요.