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

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

본질: 인터페이스 분리 원칙은 요구사항과 품질 속성을 구조와 경계의 언어로 바꾸는 설계 기준이다.

가치: 구조 결정의 근거를 명확히 하여 성능·유지보수성·확장성 같은 품질 속성을 균형 있게 맞춘다.

판단 포인트: 경계를 어디에 두고 어떤 품질 속성을 우선할지 분명히 해야 올바른 구조 선택이 가능하다.

Ⅰ. 개요 및 필요성

인터페이스 분리 원칙은 클라이언트는 자신이 사용하지 않는 메서드에 의존하지 않아야 한다. (인터페이스를 작고 구체적으로 분해)를 구조적 의사결정 관점에서 정리하는 설계 주제다. 이 원리나 개념이 필요한 이유는 요구사항 변화에 비해 구조적 기준이 느슨하고 품질 속성 상충이 방치되는 상황이 반복되기 때문이다. 기능 요구사항만 보고 바로 구현에 들어가면 초기 개발은 빨라 보이지만, 나중에는 작은 변경도 여러 모듈을 동시에 흔드는 구조적 비용으로 되돌아온다.

설계감리에서 인터페이스 분리 원칙은 '멋진 구조'를 말하기 위한 주제가 아니라, 어떤 품질 속성을 왜 우선했는지 설명하기 위한 기준이다. 그래서 정의를 외우는 것보다, 어디서 경계를 긋고 무엇을 고정하며 무엇을 유연하게 남길지를 이해하는 것이 더 중요하다.

┌──────────────┐   ┌──────────────┐   ┌──────────────┐
│ Requirement  │──▶│ Decision     │──▶│ Structure    │
└──────────────┘   └──────┬───────┘   └──────┬───────┘
                          │                  │
                          └──────▶ Quality Attribute

이 다이어그램은 요구사항이 그대로 코드가 되는 것이 아니라, 중간의 설계 결정과 책임 분할을 거쳐 구조와 품질 속성으로 연결된다는 점을 보여 준다.

📢 섹션 요약 비유: 도시계획에서 도로 폭과 건물 배치를 먼저 정해야 나중에 교통 체증을 줄일 수 있는 것과 같다.

Ⅱ. 아키텍처 및 핵심 원리

인터페이스 분리 원칙을 실제 설계 원리로 쓰려면 어떤 구성요소가 변할 수 있고, 어떤 부분은 안정적으로 유지되어야 하는지를 먼저 구분해야 한다. 이때 중요한 것은 계층 이름보다 변경 이유와 의존 방향이다.

요소	역할	설계 포인트
ISP	문제를 구조적 관점으로 번역하는 입력	이해관계자 관심사와 제약을 함께 담아야 함
Concern	핵심 구조 결정을 내리는 축	변경 비용과 품질 속성 상충점을 함께 봐야 함
Decision	경계와 책임을 분리하는 장치	의존 방향이 뒤집히면 원칙이 무너짐
Boundary	구조 효과를 검증하는 기준	성능, 보안, 유지보수성처럼 측정 가능한 척도가 필요

설계 원리는 보통 '좋은 말'처럼 보이지만, 실제로는 트레이드오프를 정면으로 다루는 규칙이다. 예를 들어 유연성을 높이기 위한 추상화는 초기 복잡도를 올릴 수 있고, 단순화를 택하면 향후 확장 비용이 커질 수 있다. 따라서 인터페이스 분리 원칙은 정답을 주는 공식이 아니라, 우선순위를 드러내는 판단 프레임으로 읽어야 한다.

📢 섹션 요약 비유: 건축 설계도처럼, 방의 크기보다 배관과 동선 경계를 먼저 잡아야 공사가 꼬이지 않는다.

Ⅲ. 비교 및 연결

인터페이스 분리 원칙은 인접 원칙이나 단기 구현 방식과 비교할 때 실제 경계가 드러난다. 겉으로 비슷해 보여도 어떤 변경을 격리하는지, 어떤 품질 속성을 우선하는지에 따라 선택이 달라진다.

비교 축	인터페이스 분리 원칙	기능 우선의 단기 설계
출발점	요구사항을 구조적 책임으로 번역한다	기능 구현의 즉시성에 더 무게를 둔다
변경 대응	경계와 추상화로 파급 범위를 줄인다	수정 시 연쇄 변경이 쉽게 발생한다
품질 속성	성능·보안·유지보수성의 상충을 의식한다	단기 완료에 집중해 장기 비용이 숨기기 쉽다
감리 포인트	문서와 코드가 같은 구조 원칙을 따르는지 본다	구현 결과만 보고 원인 구조를 놓치기 쉽다

또한 인터페이스 분리 원칙은 리팩토링, 테스트 전략, 아키텍처 평가(ATAM/CBAM)와도 연결된다. 구조 원칙은 코드 스타일의 문제가 아니라, 시스템 전체를 어떤 진화 경로에 올려둘지 결정하는 출발점이기 때문이다.

📢 섹션 요약 비유: 악보의 조표처럼, 처음 규칙을 잘 정해 두면 뒤의 연주가 훨씬 안정적으로 맞아 떨어진다.

Ⅳ. 실무 적용 및 기술사 판단

예를 들어 변경 요청이 잦은 서비스에서 인터페이스 분리 원칙을 적용하면, 어디까지를 고정 경계로 보고 어디를 교체 지점으로 둘지 ADR(Architecture Decision Record) 수준으로 남겨야 한다. 그래야 성능·보안·개발 속도 사이의 타협을 팀이 같은 기준으로 반복할 수 있다.

실무에서 중요한 판단은 원칙의 '순수성'이 아니라 비용 대비 효과다. 팀 역량이 낮고 시스템 수명이 짧다면 과도한 추상화보다 명시적 구조가 낫고, 반대로 서비스 수명과 변경 빈도가 높다면 초기에 경계를 잘 잡는 것이 총비용을 크게 낮춘다.

판단 체크리스트

이 구조 결정이 해결하려는 품질 속성이 문서에 명시되어 있는가?
경계가 코드, 테스트, 배포 단위까지 일관되게 반영되는가?
신규 변경이 들어왔을 때 영향을 받는 모듈 수를 설명할 수 있는가?

📢 섹션 요약 비유: 주방 동선 설계처럼, 어떤 재료를 어디에 둘지 정하면 요리 속도와 실수가 함께 줄어든다.

Ⅴ. 기대효과 및 결론

인터페이스 분리 원칙을 기준으로 설계하면 변경 이유가 모듈 경계에 반영되어, 장애 분석과 기능 확장이 모두 쉬워진다. 또한 팀 내 공통 언어가 생겨 리뷰 품질과 의사결정 속도도 함께 올라간다.

반면 어떤 원칙도 맥락 없이 절대화할 수는 없다. 과도한 분리와 추상화는 학습 비용을 높이고, 반대로 지나친 단순화는 미래 변경의 폭탄이 될 수 있다. 결국 인터페이스 분리 원칙은 '항상 이렇게 하라'는 교리라기보다, 어떤 비용을 줄이기 위해 어떤 구조를 선택했는지 설명하게 만드는 설계 기준으로 기억하는 것이 맞다.

📢 섹션 요약 비유: 교량 설계처럼, 하중을 어디에 분산할지 정해야 전체 구조가 오래 버틴다.

📌 관련 개념 맵

개념	연결 포인트
요구사항 (Requirement)	구조 결정이 해결해야 할 문제와 제약을 정의한다.
품질 속성 (Quality Attribute)	성능, 보안, 유지보수성처럼 구조 판단 기준을 제공한다.
ISP	인터페이스 분리 원칙의 경계를 실제 설계 규칙으로 드러내는 대표 개념이다.
리팩토링 (Refactoring)	원칙이 무너졌을 때 구조를 되돌리는 실천 수단이다.

📈 관련 키워드 및 발전 흐름도

[선행 개념: 요구사항]
    │
    ▼
[현재 개념: 인터페이스 분리 원칙]
    │
    ├──▶ [확장 A: ISP]
    └──▶ [확장 B: 품질 속성]
            │
            ▼
        [다음 단계: 구조 진화]

이 흐름은 문제 정의에서 구조 결정으로, 다시 품질 속성과 진화 전략으로 이어지는 설계 사고 흐름을 압축한다.

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

인터페이스 분리 원칙은 블록을 아무 데나 쌓지 말고, 튼튼하게 버틸 모양으로 먼저 나누는 규칙이에요.
처음에 자리를 잘 정해 두면 새 블록을 붙일 때 무너지지 않아요.
그래서 나중에 바꾸거나 고칠 때도 훨씬 쉬워져요.