숏컷 코드

Context
  -> 현재 전략 참조
  -> 필요 시 다른 전략으로 교체

MeleeAttack / RangedAttack / MagicAttack

문법과 예시

switch 분기는 행동 종류가 늘어날수록 본체 클래스를 비대하게 만든다

플레이어 공격, 적 이동, 타겟 선정이 모두 한 클래스의 switch나 if 체인으로 커지기 시작하면, 새 행동을 추가할 때마다 본체를 뜯어야 합니다. 전략 패턴은 바뀌는 알고리즘만 별도 객체로 감싸서 교체 가능하게 만듭니다. 그러면 context는 "지금 어떤 전략을 쓰는가"만 알고, 각 전략이 실제 행동을 수행합니다.

// switch 기반
if (attackMode == Melee) { ... }
else if (attackMode == Ranged) { ... }
else if (attackMode == Magic) { ... }

// strategy 기반
currentAttackStrategy.Execute(user, target);

전략 패턴은 "같은 목표, 다른 방법"일 때 가장 잘 맞는다

전략은 상태 패턴과 비슷해 보이지만 질문이 다릅니다. 전략은 "같은 목적을 여러 방법으로 달성하는가"에 가깝습니다. 예를 들어 공격은 모두 "피해를 준다"는 공통 목표가 있지만, 근접/원거리/마법은 방법이 다릅니다. 반면 상태 패턴은 "지금 객체가 어떤 mode에 있는가"가 중심입니다. 그래서 Idle/Jump/Fall은 상태에 가깝고, Chase/Patrol/Search는 상황에 따라 전략 또는 상태가 될 수 있습니다.

Unity에서는 ScriptableObject 전략과 런타임 객체 전략을 나눠서 볼 수 있다

디자이너가 손대는 값 중심 전략은 ScriptableObject 자산으로 두기 좋고, 런타임 내부 상태를 많이 가지는 전략은 객체 인스턴스로 두는 편이 자연스럽습니다. 이 구분을 안 하면 asset이 런타임 상태를 품거나, 반대로 모든 설정을 코드로만 바꿔야 하는 불편이 생깁니다. 전략은 "교체 가능한 알고리즘"이고, 그 알고리즘의 데이터와 상태를 어디에 둘지까지 함께 봐야 합니다.

전략을 너무 잘게 쪼개면 교체보다 조합 관리가 더 어려워진다

전략 패턴의 실패는 보통 남용에서 나옵니다. 아주 작은 차이까지 전략 클래스로 나누면, 실제로는 파라미터 하나면 될 일을 타입 폭발로 바꾸게 됩니다. 행동 규칙이 본질적으로 다를 때만 전략으로 분리하고, 단순한 수치 차이는 데이터 파라미터로 처리하는 편이 더 단순합니다.

장점은 OCP와 테스트 용이성, 단점은 클래스 수와 통신 설계다

전략 패턴의 장점은 기존 코드를 거의 건드리지 않고 새 능력이나 행동을 추가할 수 있다는 점입니다. 각 행동이 분리된 클래스로 존재하므로 테스트도 쉬워집니다. 반면 전략 객체 수가 늘어나면 관리 복잡도가 올라가고, 전략이 이벤트나 UI 같은 다른 시스템과 어떻게 통신할지 신중히 설계하지 않으면 결합도가 다시 높아집니다.

능력 시스템 말고도 이동, AI, 공격, 난이도 조정까지 확장 가능하다

전략은 능력 시스템뿐 아니라 이동 방식 교체, AI 순찰/공격 정책, 무기 유형 전환, 적응형 난이도 조정처럼 "같은 목적을 다른 방식으로 달성"하는 곳이면 대부분 후보가 됩니다. 그래서 전략 카드는 능력 패턴 하나로 좁히기보다 gameplay 알고리즘 교체 패턴으로 이해하는 편이 맞습니다.

전략 패턴을 고를 때 핵심

특이 케이스와 주의할 점

실패 예시
- WalkSpeed5, WalkSpeed6, WalkSpeed7 같은 전략 타입을 계속 추가

결과
- 실제 알고리즘 차이는 없는데 타입만 늘어남
- 밸런스 조정이 클래스 교체 문제로 바뀜