[20260520] Unity ( Unity의 기본 개념 )

1. Unity의 기본 개념

1) Unity는 Component 기반 구조다.

- Unity는 객체의 기능을 상속 구조로 구성하기보다, Component 기반 구조를 사용한다.

- 상속 중심으로 설계할 때, 아래와 같은 문제가 발생할 수 있다.

 

Human
 ├─ Player
 └─ NPC

- 예를 들어, Human 이라는 최상위 클래스에 체력, 물리, 애니메이션, 렌더링, 조작 기능을 모두 넣었다고 가정한다.
- 그러면, Player 는 조작 기능이 필요하지만, NPC는 ‘조작 기능’이 필요하지 않다.
- 이처럼, 부모 클래스에 기능을 많이 넣을수록 자식 클래스가 필요하지 않은 기능까지 상속받는 문제가 생긴다.
- 즉, Unity는 기능을 거대한 부모 클래스에 몰아넣고 상속받는 방식이 아닌 필요한 기능을 Component 단위로 나누고 GameObject에 조립하는 방식을 사용한다.

---

2) GameObject

- Unity 안에서 GameObject 라는 것은 월드에 존재하는 하나의 물체를 의미한다.

- 즉, Unity에서 GameObject라는 것은 Scene안에 존재하는 기본 단위라고 할 수 있다.

 

- Unity에서 프로젝트를 생성하면 만들어지는 Camera, Directional Light, Global Volume 등등과 같은 모든 것이 GameObject다.

- GameObject 자체는 구체적인 동작을 직접 정의하지 않고, 여러 Component를 담는 컨테이너 역할을 한다.

---

3) Component 패턴

- Component는 GameObject에서 특정 기능을 제공하는 부품과 같다.

Transform → 위치, 회전 크기
Camera → 화면 렌더링
Light → 빛
Rigidbody → 물리 효과
Colider → 충돌 판정
AudioSource → 소리 재생
Script → 개발자가 직접 작성한 동작

- 즉, GameObject는 빈 껍데기이고, 실제 기능은 Component를 붙여서 만든다.

 

① 예시

- 우리가 C#에서 일반적인 클래스로 상속을 이용해 Player를 만들었다면 이렇게 생각할 수 있다.

class Player : Human
{
		 // private int Hp; 
		 // ~~~ Move();       // 이동
		 // ~~~ Attack();     // 어택
		 // Animation();      // 애니메이션
}

- 하지만 Unity에서는 보통 이런식으로 구성한다.

Player (GameObject)
 ├─ Transform
 ├─ Rigidbody
 ├─ Collider
 ├─ Animator
 ├─ PlayerController Script
 └─ Health Script

Monster GameObject
 ├─ Transform
 ├─ Rigidbody
 ├─ Collider
 ├─ Animator
 ├─ MonsterAI Script
 └─ Health Script

- 몬스터의 경우 몬스터가 필요한 Component만 다르게 붙여주면 된다.

- 이렇게 하면, Player와 Monster가 반드시 같은 부모 클래스를 공유하지 않아도 된다. 즉, 공통 기능이라는 이유만으로 부모 클래스에 몰아 넣지 말고, 붙였다 뗄 수 있는 기능은 Component로 분리해두고, 필요한 GameObject에만 붙여서 재사용하는 방식이다.

---

② Component 구조를 사용하는 이유

- Component 구조의 핵심 장점은 필요한 기능만 조립할 수 있다는 점이다.

- 상속 구조에서는 부모 클래스가 비대해지기 쉽지만, Component 구조에서는 기능을 작게 나누고, 필요한 GameObject에만 붙일 수 있다.

- 예를 들어, NPC에게 조작 기능이 필요없다면, 이동 관련 기능(PlayerController Component)를 붙이지 않으면 된다.

 

③ 주의 사항

- Component 구조가 상속을 완전히 대체하는 것은 아니다.

- Unity에서도 C# 클래스 상속은 사용이 가능하다. 하지만, GameObject 기능을 설계할 때는 역할별 Component로 나누는 방식이 더 자연스럽다.

- 또한 Component를 너무 잘게 나누면 오히려 구조 파악이 어려워진다. 따라서 기능 단위는 적절히 나누는 것이 중요하다.

---