컴포넌트 원칙은 정답이 없다: 상황별로 달라지는 REP·CCP·CRP 예시

REP·CCP·CRP는 항상 동시에 완벽히 만족시킬 수 없고, 프로젝트의 **상황(라이프사이클 단계, 우선순위, 팀 목표)**에 따라 무엇을 우선시할지 달라진다. 아래에 상황별로 어떤 원칙을 지키는 게 좋은지, 그리고 이유를 정리해봤다.

---

1. 프로젝트 초기 (스타트업/PoC/빠른 프로토타이핑 단계)

• 우선시할 원칙: CCP (공통 폐쇄 원칙)
• 이유:
  • 이 시기에는 재사용성보다 빠른 변화 대응이 중요하다.
  • 시장 피드백이나 요구사항이 자주 바뀌므로, 변경이 함께 일어나는 것들을 묶어 두면 유지보수가 쉽다.
  • “재사용”을 고려해 너무 잘게 나누면 오히려 불필요한 배포/설계 부담이 커짐.
• 예시:
  • Order + Coupon 같이 같이 바뀌는 기능을 한 컴포넌트로 두어, 정책 변경 시 빠르게 대응 가능하게 한다.

---

2. 프로젝트 성장기 (팀 확장, 코드베이스 커짐)

• 우선시할 원칙: CRP (공통 재사용 원칙)
• 이유:
  • 여러 팀이 병렬로 작업하기 시작하면서 불필요한 의존성이 큰 부담이 된다.
  • CRP를 무시하면 작은 기능만 써도 거대한 컴포넌트에 의존해야 하고, 빌드/배포 파이프라인이 자주 깨짐.
  • 따라서 “실제로 같이 쓰이는 코드”끼리만 묶어서, 재빌드/재배포를 최소화해야 함.
• 예시:
  • Order + Payment는 묶되, Review는 별도로 분리.
  • 리뷰 기능 때문에 주문/결제 컴포넌트를 매번 다시 빌드하는 부담을 없앰.

---

3. 프로젝트 성숙기 (재사용/파생 프로젝트 발생, 라이브러리화 필요)

• 우선시할 원칙: REP (재사용/릴리즈 등가 원칙)
• 이유:
  • 이 단계에서는 프로젝트 자체뿐 아니라 다른 프로젝트/서비스에서도 재사용하기 시작한다.
  • 같은 기능을 매번 복사/붙여넣기 하면 유지보수 악몽이 되므로, 재사용 단위 = 릴리즈 단위를 맞추는 게 중요하다.
  • 버전 관리와 배포 단위를 표준화하면 팀 간 협업/재사용이 훨씬 쉬워진다.
• 예시:
  • “회원가입 모듈”을 하나의 릴리즈 단위(패키지)로 만들어서, 다른 서비스에서도 그대로 가져다 쓰도록 한다.

---

4. 언제나 기본적으로 고려해야 하는 원칙

• **CRP (공통 재사용 원칙)**는 기본적으로 항상 신경 써야 한다.
  • 왜냐하면 불필요한 의존성은 곧바로 빌드/배포 비용으로 직결되기 때문이다.
  • “안 써도 되는 걸 가져오게 만드는 설계”는 대부분 장기적으로 발목을 잡는다.

---

요약표

프로젝트 단계 우선 원칙 이유

초기 (빠른 반복)	CCP	변경에 잘 대응해야 하므로, 같이 바뀌는 걸 묶는 게 효율적
성장기 (팀 확장)	CRP	불필요한 의존성 줄여서 빌드/배포 부담 감소
성숙기 (재사용 필요)	REP	릴리즈 단위와 재사용 단위를 일치시켜 유지보수/확장성 확보
항상	CRP	불필요한 의존성은 언제나 문제이므로 기본적으로 고려해야 함