Input System의 Action, Action Map, PlayerInput

기본 패턴

Input Action Asset
  -> Action Map
    -> Action

PlayerInput
  -> 어떤 액션 자산을 현재 플레이어에 연결할지 관리

설명

• Input System은 키보드 키 하나를 바로 읽는 방식보다 "의도된 행동(Action)"을 중심으로 입력을 다룹니다. Jump, Move, Look, Interact처럼 게임 의미를 먼저 정의하고, 그 행동에 여러 장치를 바인딩합니다.
• Input Action Asset은 전체 입력 설계의 컨테이너이고, Action Map은 상황별 묶음입니다. 예를 들어 Gameplay, UI, Vehicle, PhotoMode처럼 맥락에 따라 map을 나누면 활성화와 비활성화가 쉬워집니다.
• Action은 실제 입력 행동 단위입니다. 값형(Vector2 이동), 버튼형(점프), 패스스루형(mouse delta)처럼 쓰임이 다르고, callback을 통해 started, performed, canceled 흐름을 받을 수 있습니다.
• PlayerInput은 이 구조를 씬 오브젝트와 연결해 주는 실전용 컴포넌트입니다. 한 플레이어의 액션 자산, control scheme, 이벤트 전달 방식을 묶어 관리할 수 있어서 규모가 커질수록 편해집니다.
• 그래서 Input System의 핵심은 API보다 모델입니다. 장치가 아니라 행동을 먼저 정의하고, 장면 상태에 따라 어떤 map을 켜고 끌지 설계하는 것이 유지보수성의 시작입니다.

어떻게 설계하면 좋은가

• 먼저 장치보다 행동 vocabulary를 정하는 것이 좋습니다. Move, Look, Jump, Interact, Pause처럼 게임이 요구하는 행동을 먼저 정하고, 그다음 장치를 붙이면 키보드와 패드 대응이 훨씬 쉬워집니다.
• Action Map은 기술적 구분보다 플레이 상태 구분으로 나누는 편이 좋습니다. Gameplay, UI, Vehicle, Dialogue처럼 상태별로 나누면 어떤 입력이 현재 유효한지 즉시 보입니다.
• PlayerInput의 이벤트 전달 방식은 프로젝트 스타일에 따라 다르게 선택할 수 있습니다. Unity Events, Send Messages, C# callback 중 어느 방식을 택할지 팀 규칙을 정해 두면 혼란을 줄일 수 있습니다.
• 액션 자산을 너무 잘게 쪼개는 것도, 모든 것을 하나의 map에 넣는 것도 둘 다 불편합니다. "같이 켜고 끄는 입력 묶음인가"를 기준으로 map 경계를 잡는 편이 실전적입니다.
• 결국 Input System에서 가장 중요한 것은 API가 아니라 가독성입니다. 디자이너와 프로그래머가 입력 구성을 함께 볼 수 있어야 하고, 장면 상태에 따라 활성 map이 무엇인지 쉽게 추론돼야 합니다.

빠른 정리

설계 기준

주의할 점