숏컷 코드
SOLID 빠른 질문
- 책임이 하나인가
- 새 기능이 기존 switch 수정 없이 붙는가
- 대체 구현을 바꿔도 호출부가 버티는가
- 큰 인터페이스를 억지로 구현하고 있지 않은가
- 구체 타입 대신 계약에 의존하는가문법과 예시
SOLID는 "클래스를 예쁘게 나누는 법"보다 변경 비용을 줄이는 기준이다
게임 코드는 입력, 물리, 연출, UI, 저장, 네트워크가 한 흐름에 엮입니다. 이때 SOLID는 미학 규칙이 아니라 "기획이 바뀔 때 어디까지 고쳐야 하는가"를 줄이기 위한 기준입니다. 예를 들어 무기 하나를 추가할 때 기존 무기 switch를 계속 뜯어야 한다면 OCP가 약하고, HUD 갱신과 데미지 계산이 같은 클래스 안에 있다면 SRP가 약합니다.
나쁜 냄새
- PlayerController가 입력, 이동, 체력, HUD, 저장까지 다 처리
- ItemManager switch에 새 아이템 타입마다 case 추가
- EnemySpawner가 직접 AudioManager, QuestManager, UI까지 호출Unity에서는 MonoBehaviour 수명주기 때문에 원칙 위반이 더 쉽게 숨는다
Awake, Start, Update 안에 로직을 바로 쌓기 시작하면 책임이 자연스럽게 섞입니다. Inspector 연결이 편하다는 이유로 모든 참조를 한 컴포넌트에 몰아넣으면 DIP와 ISP가 약해지고,
씬에서 바로 동작한다는 이유로 구조 문제가 늦게 보입니다. Unity에서는 "씬에서 된다"와 "구조가 오래 간다"를 분리해서 봐야 합니다.
원칙마다 보는 질문이 다르다
SOLID는 한 번에 다 적용하는 체크리스트가 아니라, 문제가 생겼을 때 어느 축이 약한지 보는 프레임에 가깝습니다.
SRP
- 이 클래스가 바뀌는 이유가 하나인가
OCP
- 새 규칙 추가가 기존 분기 수정으로 이어지는가
LSP
- 부모 타입 대신 자식을 넣어도 호출부 의미가 유지되는가
ISP
- 안 쓰는 메서드까지 구현하게 강요받는가
DIP
- high-level 흐름이 구체 MonoBehaviour 구현에 직접 묶여 있는가SOLID는 패턴 카드와 같이 읽을 때 의미가 커진다
Factory, Strategy, Observer, Command 같은 패턴은 SOLID를 코드에 내려놓는 실전 수단입니다. 예를 들어 Strategy는 OCP를 돕고, Observer는 결합을 줄이며, Factory는 생성 변경을 한곳에 모읍니다. 그래서 SOLID 카드는 패턴의 상위 원리 카드로 보고, 실제 설계는 패턴 카드에서 구체화하는 편이 자연스럽습니다.
실전에서는 SRP와 DIP부터 보는 편이 가장 효과적이다
게임 코드에서 처음부터 다섯 원칙을 균등하게 적용하려 하면 과해지기 쉽습니다. 실제로는 "책임이 너무 많이 섞였는가"와 "구체 구현에 너무 직접 묶였는가"를 먼저 보는 편이 효과가 큽니다. 이 두 축이 정리되면 OCP, ISP, LSP 문제도 더 명확하게 보이기 시작합니다.
SOLID를 읽을 때 핵심
| 상황 | 먼저 볼 원칙 |
|---|---|
| 한 클래스가 입력, UI, 저장까지 다 할 때 | SRP |
| 새 타입 추가 때 기존 switch를 계속 수정할 때 | OCP |
| 인터페이스는 같지만 일부 구현이 호출 규칙을 깨뜨릴 때 | LSP |
| 큰 인터페이스에 안 쓰는 메서드가 많을 때 | ISP |
| gameplay 흐름이 특정 MonoBehaviour 구현에 고정될 때 | DIP |
| 패턴을 써도 왜 나누는지 감이 안 올 때 | SOLID 관점으로 다시 해석 |
특이 케이스와 주의할 점
흔한 실패는 SOLID를 "클래스 수를 늘리는 규칙"으로 이해하는 것입니다. 원칙이 목표가 아니라 변경 비용을 줄이는 것이 목표입니다. 아직 변경 압력이 거의 없는 작은 코드까지 과하게 추상화하면, 읽기 비용만 늘고 실제 이득은 적을 수 있습니다.
실패 예시
- 간단한 UI 패널 하나에도 interface 4개, abstract class 2개를 먼저 만듦
결과
- 변경은 거의 없는데 구조 설명 비용만 커짐
- 원칙이 아니라 형식만 남음참고 링크
1 sources