CCP는 컴포넌트 응집도에 관한 원칙이다. "변경의 이유와 시점이 같은 것들을 함께 두라"는 말은, 어떤 기능 변경이 생겼을 때 최소한의 컴포넌트만 수정되도록 설계하라는 뜻이다.
클래스 수준의 단일 책임 원칙(SRP)을 컴포넌트 수준으로 확장한 것이라고 볼 수 있다. SRP가 "하나의 클래스는 하나의 변경 이유만 가져야 한다"면, CCP는 "하나의 컴포넌트는 하나의 변경 이유만 가져야 한다"는 것이다.
실용적으로는: 어떤 변경이 발생했을 때 여러 컴포넌트를 동시에 수정해야 한다면, 그 클래스들이 잘못된 컴포넌트에 흩어져 있다는 신호다.
컴포넌트(Component)란 배포 단위다. JAR, DLL, npm 패키지처럼 독립적으로 배포 가능한 가장 작은 단위를 말한다.
왜 중요한가? — 배포 비용 때문이다. 하나의 작은 변경이 여러 컴포넌트에 걸쳐 있으면, 변경된 모든 컴포넌트를 재검증하고 재배포해야 한다. CCP를 잘 지키면 변경의 영향 범위가 단일 컴포넌트로 제한된다.
CCP vs CRP 긴장관계
CCP는 "관련된 것들을 함께 묶어라(응집)"를 지향하고, CRP(공통 재사용 원칙)는 "불필요한 것들을 함께 묶지 마라(결합 최소화)"를 지향한다. 이 둘은 서로 반대 방향으로 당기는 힘이다. 아키텍처란 이 긴장 관계의 균형을 맞추는 작업이다.
| 원칙 | 지향점 | 위반 시 문제 |
|---|---|---|
| CCP | 변경이 한 컴포넌트에만 영향 | 작은 변경에도 여러 컴포넌트 재배포 |
| CRP | 불필요한 의존성 제거 | 쓰지 않는 클래스 변경에도 내 컴포넌트 재배포 |
실전 예시: HTTP 요청 파싱 로직과 비즈니스 룰이 같은 컴포넌트에 있다면 CCP 위반이다. HTTP 스펙이 바뀔 때와 비즈니스 룰이 바뀔 때는 변경 이유가 다르기 때문이다.
CCP를 위반하면 하나의 작은 변경이 여러 컴포넌트에 걸쳐 재배포를 유발한다. 준수하면 변경의 영향 범위가 단일 컴포넌트로 제한된다.