Game Dev패턴과 구조

상태 패턴과 FSM

캐릭터나 UI, 전투 흐름처럼 mode가 분명한 시스템에서 상태 패턴과 finite state machine을 어떻게 적용할지 정리합니다.

마지막 수정 2026년 3월 22일

기본 패턴

text
Idle -> Run -> Jump -> Fall -> Land

설명

  • FSM은 "지금 이 객체가 어떤 mode에 있는가"를 명확하게 다루는 구조입니다. 플레이어 이동, 적 AI, 메뉴 흐름, 퀘스트 단계처럼 현재 상태에 따라 가능한 입력과 전이가 달라질 때 특히 잘 맞습니다.
  • 초보 단계에서는 ifbool 몇 개로도 버틸 수 있지만, 상태 수가 늘수록 전이 조건이 흩어지고 "이 상태에서 저 입력이 왜 먹히는지"를 추적하기 어려워집니다. 상태 패턴은 이 복잡성을 객체나 명시적 전이표로 끌어내는 데 의미가 있습니다.
  • 핵심은 상태 수를 늘리는 것이 아니라, 상태 경계를 분명하게 정의하는 것입니다. JumpFall을 나누는 이유는 이름이 예뻐서가 아니라, 허용 입력과 애니메이션, 판정 규칙이 실제로 다르기 때문입니다.
  • 반대로 모든 flag를 FSM으로 바꾸면 과합니다. 무기 장착 여부, 버프 존재 여부처럼 동시에 겹쳐 존재하는 정보는 별도 상태 데이터나 태그가 더 자연스러울 수 있습니다.
  • 좋은 FSM 카드는 "상태 목록"보다 "전이 조건"과 "상태별 책임"이 먼저 보여야 합니다. 결국 버그는 대부분 상태 정의 자체보다 전이 경계에서 터집니다.

짧은 예제

text
Idle 상태에서는 attack, move 입력 허용
Jump 상태에서는 ground-only action 금지
Land 상태에서는 짧은 recovery 후 Idle 전이

빠른 정리

항목핵심 포인트
잘 맞는 문제mode가 분명하고 전이 규칙이 있는 시스템
대표 대상플레이어 상태, 적 AI, UI 흐름, 퀘스트 단계
설계 핵심상태 이름보다 전이 조건과 책임 경계
과한 적용겹쳐 존재하는 속성까지 모두 상태로 만들기
자주 나는 버그exit/enter 처리 누락, 잘못된 전이 허용

주의할 점

상태 수를 세밀하게 나누는 것보다, "이 상태에서 무엇이 허용되고 무엇이 금지되는가"를 먼저 문장으로 정리하는 편이 훨씬 중요합니다. 정의가 흐리면 FSM도 결국 if 더미가 됩니다.

참고 링크

1 sources