| 일 | 월 | 화 | 수 | 목 | 금 | 토 |
|---|---|---|---|---|---|---|
| 1 | 2 | 3 | 4 | |||
| 5 | 6 | 7 | 8 | 9 | 10 | 11 |
| 12 | 13 | 14 | 15 | 16 | 17 | 18 |
| 19 | 20 | 21 | 22 | 23 | 24 | 25 |
| 26 | 27 | 28 | 29 | 30 | 31 |
- New Input System
- 이벤트 버스
- Visual Studio Installer
- 테이블 데이터
- 상태 패턴
- Canvas Scaler
- Object Pool
- unity
- 기술면접
- Render Mode
- Dependency Injection
- 의존성 주입
- 데이터 형식
- 추상 팩토리 패턴
- 구글 스프레드 시트
- event bus
- Unity 기술면접
- 유니티
- 프로젝트 생성
- github desktop
- 개발
- Abstract Factory Pattern
- 스타일 지침
- 구글플레이콘솔
- C#
- Di
- 오브젝트 풀
- MVP 패턴
- 콘솔 앱
- 게임 디자인 패턴
- Today
- Total
DevDino
[Unity 기술면접] 객체지향 설계 5대 원칙(SOLID) 본문
목표
유니티 환경에서 객체지향 5대 원칙(SOLID)
객체지향 설계 5대 원칙(SOLID)
좋은 게임 아키텍처를 설계하기 위해서는 코드를 유연하고 유지보수하기 쉽게 작성하는 것이 핵심입니다. SOLID 원칙은 이를 달성하기 위한 5가지 객체지향 설계 핵심 원칙을 의미합니다.
특히 유니티 환경에서는 하나의 컴포넌트(MonoBehaviour)에 여러 기능이 무분별하게 집중되어 코드가 엉키기 쉬우므로, 이 5대 원칙을 설계에 적용하는 습관을 들이는 것이 매우 중요합니다.
1. 단일 책임 원칙(SRP, Single Responsibility Principle)
하나의 클래스는 단 하나의 책임(역할)만 가져야 한다는 원칙입니다.
- 핵심: 코드가 변경되어야 하는 이유는 단 하나여야 하며, 이를 통해 코드의 가독성을 높이고 버그 발생 확률을 줄입니다.
- 적용 예시: Player 스크립트 하나에 이동 로직, 체력 UI 갱신 로직, 효과음 재생 로직을 전부 넣지 않습니다. 개별 기능을 스크립트로 쪼개어 각각이 하나의 역할만 수행하도록 만듭니다.
2. 개방-폐쇄 원칙(OCP, Open/Closed Principle)
소프트웨어 요소는 확장에는 열려(Open) 있고, 수정에는 닫혀(Closed) 있어야 한다는 원칙입니다.
- 핵심: 기존의 코드를 변경하지 않고도 시스템의 기능을 확장할 수 있는 유연한 구조를 만듭니다.
- 적용 예시: 게임의 새로운 무기(검, 활, 마법 등)를 추가할 때, WeaponManager 스크립트를 열어서 switch문을 계속 덧붙이는 것이 아닙니다. Weapon이라는 추상 클래스나 인터페이스를 만들고, 새로운 무기는 이를 상속받아 구현하도록 설계하여 기존 코드의 수정 없이 무기를 확장합니다.
3. 리스코프 치환 원칙(LSP, Liskov Substitution Principle)
부모 클래스가 들어갈 자리에 자식 클래스를 넣어도 프로그램이 원래 의도대로 정상 작동해야 한다는 원칙입니다.
- 핵심: 다형성을 안전하게 사용하기 위한 원칙으로, 자식 클래스가 부모 클래스의 기존 규약을 무시하거나 시스템 흐름을 깨지 않도록 보장합니다.
- 적용 예시: 부모 클래스 Item에 아이템을 파는 Sell() 메서드가 있다고 가정합니다. 무기나 포션은 이를 상속받아 골드를 정상적으로 반환합니다. 하지만 절대 팔 수 없는 QuestItem이 Item을 상속받은 뒤, 상점 시스템이 item.Sell()을 호출했을 때 프로그램 에러를 뿜어내며 게임을 멈추게 만든다면 원칙 위배입니다. 부모의 기능을 온전히 대체할 수 없다면, 상속 대신 팔 수 있는 아이템만 ISellable 인터페이스를 가지도록 분리해야 합니다.
4. 인터페이스 분리 원칙(ISP, Interface Segregation Principle)
자신이 사용하지 않는 메서드에 의존하지 않도록 인터페이스를 기능별로 잘게 쪼개야 한다는 원칙입니다.
- 핵심: 거대한 인터페이스 하나보다 구체적인 여러 개의 인터페이스를 두어, 클래스가 불필요한 구현을 강요받지 않게 합니다.
- 적용 예시: 수십 개의 기능이 뭉쳐진 ICharacter 인터페이스 하나를 쓰기보다, 이동을 위한 IMovable, 공격을 위한 IAttackable, 인벤토리를 위한 IInventory 등으로 분리합니다. 이렇게 하면 움직일 수만 있는 NPC는 IMovable만 상속받고 불필요한 공격 로직은 구현하지 않아도 됩니다.
5. 의존성 역전 원칙(DIP, Dependency Inversion Principle)
구체적인 클래스(구현체)가 아닌 추상화(인터페이스 등)에 의존해야 한다는 원칙입니다.
- 핵심: 모듈 간의 결합도를 낮추어 코드의 유연성과 테스트 용이성을 극대화합니다.
- 적용 예시: GameManager가 콘솔에 로그를 찍기 위해 ConsoleLogger라는 구체적인 클래스를 직접 참조하게 하지 않습니다. 대신 ILogger라는 인터페이스에 의존하게 만들면, 나중에 파일로 로그를 저장하는 FileLogger로 변경하더라도 GameManager의 코드는 수정할 필요가 없습니다.
'Unity > 기술면접' 카테고리의 다른 글
| [Unity 기술면접] Unity 데이터 저장/불러오기 (0) | 2026.01.16 |
|---|---|
| [Unity 기술면접] C# 델리게이트(Delegate)와 이벤트(Event)의 차이점 (0) | 2026.01.15 |
| [Unity 기술면접] Unity Input System (0) | 2026.01.14 |
| [Unity 기술면접] OnCollision vs OnTrigger (0) | 2026.01.12 |
| [Unity 기술면접] Unity Collider vs Rigidbody (1) | 2026.01.09 |