숏컷 코드
text
PlayerController가
입력 / 이동 / 공격 / HUD / 저장
를 다 하면 SRP가 약하다문법과 예시
SRP의 기준은 메서드 수가 아니라 바뀌는 이유 수다
클래스가 길다고 해서 바로 SRP 위반은 아닙니다. 반대로 짧아도 입력 규칙, 이동 규칙, UI 갱신 규칙이 한곳에 섞여 있으면 책임은 여러 개입니다. 게임 코드에서 SRP를 볼 때는 "이 클래스가 어떤 변경 때문에 자주 수정되는가"를 먼저 봐야 합니다.
text
한 클래스가 동시에 자주 바뀌는 이유
- 입력 매핑 변경
- 점프 수치 변경
- HUD 표시 방식 변경
- 저장 포맷 변경Unity에서는 Inspector 편의 때문에 책임이 쉽게 몰린다
MonoBehaviour 하나에 참조를 전부 끌어와 두면 씬에서 연결은 쉽습니다. 하지만 편한 연결과 좋은 경계는 다릅니다.
PlayerController가 HealthBar, SaveService, AudioSource, InventoryView를 직접 다 쥐기 시작하면 기획 변경이 들어올 때 수정 범위가 계속 넓어집니다.
보통은 흐름 조정자와 기능 컴포넌트를 나누는 쪽이 안전하다
입력 해석, 이동 계산, 체력 적용, 애니메이션 반응, UI 표시는 성격이 다릅니다. 이때 조정자 하나가 전체 흐름을 연결하고, 실제 기능은 별도 컴포넌트나 서비스로 나누는 편이 오래 갑니다.
text
예시 분리
- PlayerInputReader: 입력 읽기
- PlayerMotor: 이동/회전
- PlayerCombat: 공격 처리
- PlayerPresenter: HUD/FX 연결SRP는 "다 쪼개라"가 아니라 응집도를 높이라는 뜻이다
무조건 파일을 잘게 쪼개면 오히려 흐름이 안 보일 수 있습니다. 같이 바뀌는 코드끼리는 붙여 두고, 다른 이유로 바뀌는 코드만 분리하는 편이 맞습니다. 그래서 SRP는 분리 규칙이 아니라 응집도 규칙으로 읽는 편이 더 실전적입니다.
SRP를 볼 때 핵심
| 상황 | 먼저 할 판단 |
|---|---|
| 입력 변경과 HUD 변경이 같은 클래스 수정으로 이어질 때 | 책임 분리 검토 |
| 같은 메서드가 물리, UI, 저장을 모두 건드릴 때 | 흐름 조정자와 기능 컴포넌트 분리 |
| 같이 자주 바뀌는 코드가 한곳에 모여 있을 때 | 그대로 유지 가능 |
| 분리 후 서로 직접 참조가 더 늘어날 때 | 경계가 잘못 잘렸는지 재검토 |
| 씬 연결 편의 때문에 모든 참조를 한곳에 몰았을 때 | Inspector 편의와 책임 경계 분리 |
특이 케이스와 주의할 점
흔한 실패는 SRP를 파일 수 늘리기 규칙으로 오해하는 것입니다. 역할은 쪼갰는데 실제 흐름은 한 기능마다 서로를 다 호출하면 응집도만 깨지고 복잡도는 더 올라갑니다.
text
실패 예시
- PlayerMoveData, PlayerMoveLogic, PlayerMoveHelper, PlayerMoveUtils로만 분리
결과
- 수정은 여전히 같이 일어나는데 파일만 많아짐
- 실제 책임 경계는 선명해지지 않음참고 링크
1 sources