[📚정보] [뉴비를 위한] 상속에 대해 알아보자 - 문제편

[태보미(taebomi)]

면.접 준비하다보니 과거에 작성했던 접근 제한자 글이 떠올랐어요.

본인도 뉴비지만 파인만 기법을 사용할 겸, 더 뉴비일때 잘 와닿지 않던 개념들을 쉽게 이해했으면 하는 바람으로 글을 작성했어요.

AI 딸깍하면 정보 나오는거 아님? 이라고 생각할 수도 있지만, 배경 지식이 있어야 딸깍이 가능한 거라고 생각해요.

게다가 긍정 편향, 환각 등 뉴비 입장에서 치명적인 문제들이 인갤에서도 발견되고요.

+상속

객체지향 프로그래밍의 특징인 추상화, 상속, 다형성, 캡슐화 중에서 먼저 상속에 대해 알아보도록 해요.

뉴비 입장에서 가장 자주 마주치고, 치명적인 문제가 발생할 수 있는 요소거든요.

❓상속이란?

사실 유니티를 사용한다면 상속과 이미 한 몸이나 다름없어요.

cs 파일을 생성하면 바로 상속을 확인할 수 있어요.

자신의 클래스를 구현할 때 기본적으로 MonoBehaviour 를 상속받아 구현하거든요.

+기능

상속의 장점이라고 듣던 '속성과 기능의 재사용과 확장'을 우리 모두 이미 사용해봤어요.

MonoBehaviour 를 상속받아 gameObject, transform 등의 속성과 GetComponent 등의 기능을 재사용할 수 있었어요.

거기에 우리가 필요로 하는 damage라는 속성과 Attack()이라는 기능을 추가해서 확장을 했고요.

참고사항

사실, Awake / Update / OnTriggerEnter 등의 생명주기 함수는 상속받은 함수가 아니에요.

상속으로 받았더라면, private void Awake()가 아니라 protected override void Awake() 로 사용했을거예요.

그랬더라면 컴파일 에러 덕분에 뉴비들이 자주 겪는 오타 문제도 발생할 일이 없었을 거에요.

Awaek 로 작성한다음 왜 실행이 안되지 당황하는 것처럼요.

그렇다면 이건 어떻게 동작하는 걸까요?

'사용하지 않는 Update 함수는 지워라' 라는 말 자주 들어보셨을 거예요.

유니티 엔진은 스크립트를 처음 불러올 때 '리플렉션' 으로 해당 함수가 있는지 한 번 확인하고, 있는 것들만 목록으로 담아둬요.

그리고 그 목록을 매 프레임 호출하고요.

즉, 빈 Update 함수를 만들어두면 목록에 포함돼서 아무 일도 안 하면서 호출 비용만 나가는 거예요.

그런데 왜 이걸 상속으로 안 했을까요?

상속이었다면 모든 스크립트가 부모의 빈 Update()를 갖게 돼요.

엔진은 이를 전부 호출하게되므로 위에서 말한 방식보다 성능적으로 손해를 보게 돼요.

어쨌든 뉴비는 그냥 상속이랑은 다른 개념이구나 하고 넘어가면 충분해요.

⛓+제약

'상속은 정말 좋은 거군요!' 라고 생각할 수 있지만, 크나큰 문제를 뉴비가 겪을만한 예시로 알아보아요.

우리는 위에서 구현했던 Weapon 클래스를 상속받아 Sword라는 무기를 구현했어요.

잘 작동했고, 이후 패리와 방어 기능을 가진 무기가 필요해져서 구현했어요.

Parry 함수를 가진 ParryableSword를 구현하고, Block 함수를 가진 BlockableSword를 구현했어요.

이 또한 잘 작동했어요.

시간이 흘러 패링과 블록이 모두 가능한 검을 만들게 되었어요.

ParryableSword와 BlockableSword를 상속받으려고 보니, 아뿔싸!

C#은 다중 상속을 지원하지 않아요.

C++은 되는데 C++++로 업그레이드 된 C#은 어째서...?

어째서 C#은 편부모인 거시야...

충격을 받은 뉴비는 하는 수없이 ParryableBlockableSword를 Sword를 상속받아 구현했어요.

(방패로 막는다가 아니라 검으로 막는다!)

잘 동작하는 것을 보며 뉴비는 기분이 좋았지만, ThrowableSword가 구현하고 싶어졌어요.

그런데 던지면서 패링도 되는 검도 만들고, 방어되면서 던질 수 있는 검도 만들려고 보니 만들어야 하는 클래스가 산더미처럼 불어났어요.

하지만 강인한 의지를 가진 뉴비는 결국 해내고 말았어요.

이후, 검 외에 총, 활도 Weapon을 상속받으며 다양한 클래스를 생성했어요.

시간이 흘러 기획이 추가되었고, 내구도 시스템을 만들고 싶어졌어요.

Weapon 클래스에 durability 변수와 각 무기에 따라 내구도를 감소시킬, abstract ConsumeDurability이라는 함수를 추가했어요.

일반 무기는 단순하게 공격 시에 durability를 감소시키면 되었어요.

하지만 다른 여러 요소가 섞인 무기들에게는 엄청난 문제가 발생해버렸어요.

ParryableSword 는 공격 외에 패링 시에도, ParryableBlockableSword는 패링과 방어, 공격 시에 구현을 해야하는 등 경우의 수가 엄청나게 많아졌어요.

게다가 ThrowableSword 는 던진 파워에 따라 내구도가 깎여야 하고요.

중복되는 코드가 여기저기 파편화되고, 모든 상속받은 클래스들을 판단하며 구현해줘야하기 시작했어요.

게다가 ConsumeDurability 함수가 존재하지만, 패링, 블록, 던지기는 각자 알아서 내구도를 깎고 있고요.

결국 어찌어찌 구현은 성공을 했어요.

+기획 변경

ConsumeDurability에 강화도에 따라 내구도 깎이는 계수를 추가하게 되었어요.

그랬더니 상속받은 구현체 모두가 컴파일 에러를 뿜어버리고 말았어요.

부모 클래스 하나를 바꾸었더니 수십 개의 클래스가 영향을 받아버리는 경우가 생겨버린 거에요.

더 큰 문제는 내구도가 없어도 절반의 데미지를 주는 무기가 있었는데,

Weapon 클래스에서 그것을 잊고 내구도가 없을 때 공격을 못 하도록 만들어버린거에요.

이렇게 돼버리면, 컴파일 에러도 발생하지 않는데 모든 자식의 동작이 바뀌어버려 생각하지 못한 치명적인 버그를 얻게 돼요.

(이 문제가 궁금하다면, 'Fragile Base Class' 에 대해 알아보아요.)

+역사

애초에 C#이 다중 상속만 지원했더라면 이렇게 클래스가 복잡해질 일도 없었을텐데... 어째서...?

사실 이러한 문제를 과거에서부터 겪어왔어요.

프로그래밍 언어론은 아니니깐 간단한 역사부터 알아보아요.

먼 옛날 상속이라는 개념이 등장하고 C++에서 다중 상속이 등장했어요.

'C#이 퇴보했구나...' 라고 생각할 수 있지만, 다중 상속에는 문제가 있었기 때문이에요.

방금 전 Weapon의 예시에서 생각해보면, Sword의 damage를 ParryableSword, BlockableSword 모두 가지게 되는 상황이에요.

다중 상속이 가능했더라면, 이를 상속받은 ParryableBlockableSword는 '누구의 damage를 물려받아야 하는가', 'Attack 함수는 누구의 것을 따라야 하는가' 등 모호함이 발생해버려요.

(자세한 것은 '다이아몬드 문제' 를 알아보아요.)

이러한 문제로 Java에서는 단일 상속을 강제하되, 다중 상속을 우회하는 interface라는 개념이 등장했어요.

C#은 Java의 설계를 따라가며 유사하거나 개선한 부분들이 존재해요.

(그것과 함께 interface는 다음 시간에 알아보도록 해요.)

어쨌거나 여전히 다중 상속을 사용하는 언어도 있고 아닌 언어도 존재하지만,

상속에는 우리가 위에서 봤던 근본적인 한계가 존재해요.

부모를 고치는 순간 자식 전부가 영향을 받음

그래서 찾게 된 다른 길 중 하나가 Unity의 핵심인 컴포넌트 기반 방식(Composition)이에요.

우리가 게임오브젝트에 Sprite Renderer, Rigidbody, Collider를 선택적으로 부착하는 방식이요.

MonoBehaviour를 포함한 각종 컴포넌트들이 모두 Component라는 클래스를 상속받아,

부품을 조합하는 방식을 사용해서 상속의 한계를 돌파하고자 했어요.

(물론 이 부품들도 상속을 이용해서 만들어져 있어요. 상속을 버린 게 아님.)

이후에는 심지어 Go나 Rust처럼, 아예 상속 없이 설계된 언어도 등장했답니다.

+결론

우리는 상속의 특징과 문제점에 대해 알아보았어요.

하지만 상속이 나쁘기만 했다면, 우리의 MonoBehaviour도 없었겠죠?

즉, 적절한 사용으로 코드의 재사용과 확장이라는 장점을 취하는 것이 중요한 거에요.

상속을 사용할 때 꼭 기억해야 할 기준이 있어요.

"상속은 항상 is-a관계(B는 A다)일 때 사용"

지금의 경우에는 Parry나 Block이 검의 종류가 아닌 검의 능력이었던 것처럼요.

다만, '검은 무기이다' 는 바로 와닿지만, '패링 검은 검이다' 이러면 헷갈리기 시작해요.

논리적으로 패링 검은 검이 맞으니깐요.

하지만 'Parry'는 검을 나누는 기준이 아닌 검의 능력이라는 점에 집중해야 해요.

(이 헷갈림은 SOLID 원칙 중 리스코프 치환 원칙에서도 다시 느낄 수 있어요.)

하지만 뉴비 입장에서는 잘 와닿지 않는 말이라서 이렇게 생각해보아요.

"앞으로 이 무기(클래스)의 계층이 더 늘어날까?"

늘어날 것 같다는 생각이 든다면 상속을 피하는 게 좋아요.

계층이 깊어지는 경우라면 상속이 아닌 조합이 필요한 상황일거예요.

물론 게임 개발은 기획 변경도 잦아서 확신할 수 없고, 리팩토링도 당연한거니깐 너무 두려워할 필요는 없어요.

다음에는 위에서 이야기했던 문제를 해결하는 interface에 대해 알아보아요.

내용과 관련된 뉴비를 향한 조언 환영.

근데 이런 글이 수요가 있는지 모르겠음.

좀 더 와닿게? 넓게? 알면 좋겠다고 생각하며 작성하는데 흔한 블로그 복붙글 느낌인가 싶기도 하고...

마크다운이랑 코드블록도 없어서 넘모 불편하다보니 고민. 그나마 이미지 등록 편해지고 ai로 퇴고 편해졋서!

[익명(61hmyrsdn3lp)]

[태보미(taebomi)]

[파이네(indiegamemaker)]

[태보미(taebomi)]

[211214(tomatoss)]

[태보미(taebomi)]

[불타는키보드(1bnmaker)]

[불타는키보드(1bnmaker)]

대 바이브코딩 시대라서 뉴비들이 코딩공부를 안하는게 대세긴 한 것 같음 ㅋㅋㅋㅋㅋㅋ

[태보미(taebomi)]