누적 학습 시간 : 502시간 34분

📅 2026-06-09

CH3 개인과제

Enhanced Input System의 구조와 차이점 분석

출처 : 에이타니

핵심 요점

Enhanced Input System의 공식 구성 요소: Input Action, Input Mapping Context, Input Modifier
기존 시스템과의 차이: 프로젝트 설정에만 의존하지 않고, Input Mapping Context를 통해 런타임에 입력을 유연하게 관리할 수 있어요.
전용 컴포넌트 사용: Enhanced Input Component를 통해 Input Action을 바인딩하고 관리해요.

Enhanced Input System의 핵심 구성 요소

Input Action은 게임에서 수행할 수 있는 논리적인 동작(예: 점프, 이동)을 정의합니다. 이것이 플레이어 입력의 최종 목표예요.

Input Mapping Context는 물리적 입력(키보드, 게임패드)을 Input Action으로 연결하는 매핑 규칙의 집합입니다. 같은 Action이라도 여러 Context를 통해 다양한 입력 방식을 지원할 수 있어요.

Input Modifier는 입력 값이 Action에 전달되기 전에 그 값을 변환하거나 조정하는 역할을 합니다. 데드존 설정, 범위 조정, 부호 반전 등이 여기에 해당해요.

기존 입력 시스템과의 구조적 차이

기존 시스템은 프로젝트 설정(Project Settings)의 Input 섹션에서 Action Mappings 또는 Axis Mappings에 키를 직접 등록했습니다. 입력 관리가 프로젝트 설정에만 집중되어 상대적으로 단순했지만, 유연성이 제한적이었어요.

Enhanced Input System은 Input Mapping Context라는 별도의 에셋을 통해 입력 매핑을 관리합니다. 덕분에 프로젝트 설정뿐만 아니라 런타임에도 Context를 활성화·비활성화하거나 우선순위(Priority)를 조정할 수 있어서 훨씬 더 복잡하고 유연한 입력 관리가 가능해요.

입력 처리 흐름

Enhanced Input System에서는 Enhanced Input Component를 사용하여 Input Action을 바인딩합니다. BindAction 함수를 통해 Input Action 에셋과 콜백 함수를 연결하면, 입력이 발생할 때 등록된 함수가 호출되는 방식이에요.

흐름은 다음과 같습니다: 물리적 입력 → Input Mapping Context에서 Action으로 변환 → Input Modifier로 값 조정 → Enhanced Input Component의 바인딩된 콜백 함수 실행.

헷갈리기 쉬운 지점

'Input Handler'는 Enhanced Input System의 공식 구성 요소가 아니라, 기존 입력 시스템에서 일반적으로 사용되던 용어라는 점을 기억해 두세요.

개념 정리

Enhanced Input System은 더 많은 유연성을 제공하는 대신 구조적으로는 더 복잡합니다. 하지만 Input Action, Input Mapping Context, Input Modifier라는 세 가지 핵심 요소의 역할을 명확히 이해하면, 어떤 입력 관리 상황에도 대응할 수 있어요.

PlayerController와 GameInstance의 역할 이해

핵심 요점

PlayerController: 플레이어의 입력을 받아 Pawn을 조종하는 객체예요. 게임 중 플레이어의 의도를 실행하는 역할을 맡아요.
GameInstance: 게임 전체 생명주기 동안 유지되는 싱글톤 객체예요. 게임이 시작될 때 생성되고 끝날 때까지 살아있으면서 전역 데이터를 관리해요.
두 객체는 서로 다른 계층에서 작동하므로 접근 방식도 달라요.

접근 경로의 차이

PlayerController는 게임 월드(World) 내에서 활동하는 객체지만, GameInstance는 World 레벨보다 상위에서 전체 게임을 관리하는 객체예요. 따라서 PlayerController나 Pawn에서 GameInstance에 접근하려면 반드시 World를 거쳐야 한다는 점이 중요해요.

GetGameInstance()를 PlayerController에서 직접 호출할 수는 없고, 대신 GetWorld()->GetGameInstance()처럼 World 객체를 먼저 얻은 후 GameInstance에 접근해야 한답니다.

헷갈리기 쉬운 지점

같은 게임 내 객체라고 해서 모든 것에 직접 접근할 수 있다고 생각하기 쉬워요. 하지만 계층 구조가 있으므로 상위 객체로 먼저 거쳐야 한다는 점을 기억해야 해요.

이번에 놓쳤던 부분 다시 정리

PlayerController에서 GameInstance로 바로 가는 게 아니라, PlayerController → World → GameInstance 순서로 접근해야 해요. 이는 게임의 객체 계층이 명확하게 구분되어 있기 때문이에요. GameInstance는 World 레벨에서 관리되므로, World 객체를 먼저 참조한 후에야 GameInstance를 얻을 수 있다는 뜻이랍니다. 이렇게 계층을 존중하면서 접근하면 의도치 않은 버그를 줄이고, 게임의 구조도 더 잘 이해할 수 있어요.

충돌 이벤트 처리와 충돌 타입 구분

핵심 요점

• 충돌 타입은 두 가지: Overlap(겹침 감지)과 Block(물리적 충돌)
• 성능 차이가 있어요: Block은 물리 계산을 수행하고, Overlap은 단순 감지만 해요
• 용도에 맞게 선택: 트리거나 감지 영역에는 Overlap, 실제 물리 반응이 필요하면 Block을 사용해요

Overlap과 Block의 차이

Overlap은 두 객체가 겹쳤는지만 확인하는 단순 감지 방식이에요. 물리 계산이나 충돌 해결 과정을 거치지 않아서 연산량이 적고 가벼워요.

Block은 물리 엔진이 개입해서 충돌 해결(collision resolution)까지 수행하는 방식이에요. 두 객체가 겹치지 않도록 밀어내고, 반발력을 계산하는 등 복잡한 물리 시뮬레이션이 일어나요. 따라서 더 많은 연산이 필요해요.

언제 어떤 타입을 쓸까요?

트리거나 감지 영역처럼 "접촉했다는 신호만 필요한 경우"에는 Overlap을 써요. 가볍고 빠르니까요.

반면 벽, 바닥, 충돌할 때 밀려나야 하는 게임 오브젝트는 Block을 사용해요. 실제 물리적 반응이 필요하기 때문이에요.

헷갈리기 쉬운 부분

Overlap도 "충돌"이긴 한데, Block처럼 물리적으로 밀어내지 않는다는 점을 헷갈릴 수 있어요.

이번에 헷갈렸던 부분

혹시 Overlap과 Block을 단순히 "감지하는 거 vs 안 하는 거" 정도로만 생각했나요? 사실 둘 다 감지해요. 차이는 감지 이후에 어떤 물리 처리를 하느냐에 있어요.

Overlap은 "겹쳤어" 신호만 보내고, Block은 "겹쳤어 + 물리적으로 분리해야 해" 까지 가요. 그래서 Block이 더 비싼 연산이 되는 거예요. 용도에 맞게 선택하면 게임 성능도 훨씬 좋아져요!

인터페이스와 다형성 이해

핵심 요점

• 인터페이스는 계약이에요. 함수의 선언(시그니처)만 있고 구현부는 없으며, 이를 구현하는 클래스들이 반드시 그 함수를 구현하도록 강제합니다.
• 느슨한 결합(loose coupling)을 만들어요. 클래스 간 직접 의존성을 줄이고 코드의 유연성과 유지보수성을 높입니다.
• 런타임에 결정되는 다형성이에요. 가상 함수 테이블(vtable)을 통해 실행 시점에 어떤 함수를 부를지 결정됩니다.

인터페이스의 정의와 역할

인터페이스는 단순히 함수 선언만 담는 틀이에요. 추상 클래스와 달리, 인터페이스는 다중 구현을 지원합니다. 한 클래스가 여러 인터페이스를 동시에 구현할 수 있다는 뜻이에요.

인터페이스 사용의 목적

인터페이스를 쓰는 이유는 결합도를 높이려는 게 아니라 오히려 낮추려는 거예요. 클래스 간 직접 의존성을 피하고, 코드를 더 유연하고 확장 가능하게 만듭니다. 이렇게 하면 기존 코드를 수정하지 않으면서도 새로운 기능을 추가할 수 있어요.

인터페이스를 통한 다형성

인터페이스 기반 다형성은 런타임 다형성이에요. 컴파일할 때 모든 타입이 정해지는 게 아니라, 프로그램이 실행되는 동안 실제 객체의 타입에 따라 함수 호출이 결정됩니다. 가상 함수 테이블이 이를 가능하게 해요. 약간의 성능 오버헤드가 있을 수 있지만, 얻는 유연성과 유지보수성 향상이 훨씬 더 크답니다.

헷갈리기 쉬운 지점

인터페이스와 추상 클래스를 구분하기가 쉽지 않은데, 인터페이스는 계약 역할을 하고 추상 클래스는 공통 기능을 담는 틀이라고 생각하면 좋아요.

올바른 이해 정리

인터페이스는 결합도를 높이는 게 아니라 느슨하게 만드는 도구예요. "이 인터페이스를 구현하는 어떤 클래스든 이 함수들을 가지고 있을 거야"라고 약속하는 것이죠. 덕분에 구체적인 클래스가 뭔지 몰라도 인터페이스만 알면 충분합니다. 런타임에 실제 객체를 보고 올바른 함수를 부르니까요.