컴포지션 vs 상속

기본 패턴

text

Player
  - MovementComponent
  - HealthComponent
  - WeaponComponent

게임 개발에서 상속이 빠르게 무거워지는 이유는 캐릭터, 아이템, 투사체가 "한 가지 정체성"보다 "여러 기능의 조합"으로 움직이기 때문입니다. Enemy -> FlyingEnemy -> FireFlyingEnemy처럼 내려가다 보면 계층이 기능 조합을 따라가지 못합니다.
컴포지션은 기능을 작은 단위로 나눠 조합하므로, 같은 이동 로직을 플레이어와 적이 함께 쓰거나, 체력 시스템을 여러 오브젝트가 공유하기 쉬워집니다. 재사용성과 교체 가능성이 커지는 대신, 시스템 간 의존성을 정리할 책임이 생깁니다.
그렇다고 상속이 항상 나쁜 것은 아닙니다. 공통 인터페이스를 강하게 보장해야 하거나, 생명주기와 계약이 명확한 작은 계층이라면 상속이 더 읽기 쉬울 수 있습니다.
중요한 판단 기준은 "이 차이가 본질적인 종류 차이인가, 아니면 기능 조합 차이인가"입니다. 종류 차이라면 얕은 상속이 가능하지만, 기능 조합 차이라면 컴포지션이 더 오래 갑니다.
Unity가 GameObject + Component를 중심에 둔 것도 같은 이유입니다. 이 사고는 ECS, ability system, data-driven 설계로 확장될 때 특히 강해집니다.

text

상속으로 만들면:
  FireMageEnemy
  IceMageEnemy
  FireBossEnemy

컴포지션으로 만들면:
  Enemy + CastSpell(Fire)
  Enemy + CastSpell(Ice)
  Boss + CastSpell(Fire)

컴포지션을 쓴다고 자동으로 좋은 구조가 되는 것은 아닙니다. 기능을 잘게 쪼개기만 하고 의존성 규칙을 정리하지 않으면, 상속보다 더 읽기 어려운 "컴포넌트 스파게티"가 될 수 있습니다.

1 sources