게임 개발에서 상속보다 조합이 자주 선택되는 이유
객체지향 프로그래밍을 처음 배울 때는 상속이 자연스러운 해법처럼 보인다. 플레이어는 캐릭터다, 보스는 적이다, 마법사는 유닛이다처럼 관계를 계층으로 만들면 구조가 깔끔해 보이기 때문이다.
하지만 실제 게임 개발에서는 이 계층이 금방 무거워진다. 캐릭터 하나가 이동, 애니메이션, 물리, 인벤토리, 능력치, 입력, 네트워크 동기화까지 동시에 안기 시작하면, 상속 계층은 설계를 정리하기보다 오히려 굳혀 버리는 경우가 많다.
그래서 게임에서는 상속이 전혀 필요 없어서가 아니라, 조합이 더 자주 요구사항에 맞기 때문에 컴포넌트 중심 구조가 반복해서 선택된다.
상속이 힘들어지는 지점은 “기능 조합”이 많아질 때다
로버트 나이스트롬(Robert Nystrom)의 Game Programming Patterns는 게임 객체가 한 번에 물리, 렌더링, 입력, AI처럼 여러 영역에 걸칠 때 컴포넌트 분리가 도움이 된다고 설명한다. 게임 캐릭터는 단순히 한 종류의 객체가 아니라, 여러 시스템의 교차점에 놓인 객체이기 때문이다.
상속 구조가 어려워지는 이유는 대개 이렇다.
- 비행 적이면서 원거리 공격도 하고
- 상태 이상 면역도 있고
- 특정 맵에서는 중립 NPC처럼 행동하고
- 컷신에서는 플레이어처럼 제어되어야 할 때
이런 요구는 어느 클래스의 자식인가보다 어떤 기능을 지금 붙일 것인가의 문제에 더 가깝다. 조합은 이 질문에 더 잘 맞는다.
조합은 기능을 잘게 떼어 다시 붙이기 쉽게 만든다
유니티 공식 문서도 GameObject와 Component 관계를 설명하면서, 게임 오브젝트는 컨테이너이고 실제 기능은 컴포넌트가 제공한다고 정리한다. 이 구조는 게임 업계에서 널리 쓰이는 사고방식을 잘 보여 준다.
조합 중심 구조가 실용적인 이유는 간단하다.
- 이동 기능은 이동 컴포넌트에
- 체력은 체력 컴포넌트에
- 인벤토리는 인벤토리 컴포넌트에
- 네트워크 동기화는 네트워크 컴포넌트에
이렇게 나누면 객체 하나를 새로 만들 때도 상속 계층을 어디에 꽂을까보다 어떤 기능 묶음을 조합할까로 사고할 수 있다.
이 방식은 특히 프로토타이핑과 밸런스 변경에 강하다. 기능을 빼거나 교체하는 비용이 상대적으로 낮기 때문이다.
그렇다고 상속이 완전히 나쁜 것은 아니다
여기서 자주 생기는 오해가 있다. 조합이 좋다고 해서 상속이 틀렸다는 뜻은 아니다. 같은 책의 Subclass Sandbox 장도, 상속이 여전히 유용할 수 있지만 깊고 복잡한 계층보다는 얕고 통제된 계층이 더 다루기 쉽다고 설명한다.
상속이 잘 맞는 경우도 분명 있다.
- 공통 인터페이스가 아주 안정적일 때
- 하위 클래스들이 비슷한 수명 주기와 규칙을 공유할 때
- 행동 차이가 제한적이고, 기반 클래스가 좋은 보호막 역할을 할 때
즉 문제는 상속 자체보다 상속으로 해결하려는 범위가 지나치게 넓어질 때 생긴다.
게임에서는 수정 빈도와 협업 비용도 중요하다
게임 코드는 설계만으로 끝나지 않는다. 디자이너 요청, 밸런스 수정, 애니메이션 파이프라인, 네트워크 제약, 플랫폼 이슈가 계속 들어온다. 이때 깊은 상속 계층은 수정 지점을 넓히고, 예상치 못한 영향 범위를 키우기 쉽다.
조합 구조는 모든 문제를 해결하지는 않지만, 적어도 다음 장점이 있다.
- 기능 단위로 테스트하고 교체하기 쉽고
- 여러 사람이 다른 기능 영역을 나눠 작업하기 좋고
- 특정 객체를 변형할 때 전체 계층을 흔들 가능성이 적다
그래서 게임 개발에서는 미학적 순수함보다 변경에 버티는 구조가 더 중요해지는 경우가 많다.
핵심 정리
게임 개발에서 상속보다 조합이 자주 선택되는 이유는 유행 때문이 아니다. 게임 객체가 보통 여러 시스템의 기능을 동시에 담고 있고, 그 기능 조합이 계속 바뀌기 때문이다.
상속은 안정적인 공통 규약을 표현할 때 여전히 유용하다. 하지만 기능을 자주 붙였다 떼야 하는 게임 코드에서는 컴포넌트 중심 조합이 더 유연하고, 더 자주 실제 요구사항에 맞는다. 결국 중요한 것은 상속이냐 조합이냐의 신념 싸움이 아니라, 변경 비용이 어디에서 가장 낮아지는가를 보는 일이다.