[Unreal Engine 5] 언리얼 엔진 인풋(Input) 아키텍처 파헤치기: F4 vs Lyra 비교 및 CS 관점의 동작 원리

📝 개요

오늘 프로젝트 코드를 리뷰하면서 "입력(Input) 처리를 어디서, 어떻게 하는 것이 가장 효율적인가?"에 대해 깊게 고민해 보았다. 우리 팀의 방식과 에픽게임즈의 모범 답안인 Lyra Starter Game의 방식을 비교해 보고, 밑바닥에서 엔진과 OS가 어떻게 소통하는지 CS 관점까지 정리해 본다.

---

1. 인풋은 어디서 처리해야 할까? (아키텍처 관점)

우리 팀의 방식 (Controller & Character 분리)

• 구현 방식: PlayerController는 UI/시스템 조작을, PlayerCharacter는 육체적 조작(이동, 공격)을 직접 담당한다.
• 👍 장점 (Pros)
  • 직관성과 빠른 개발: 구조가 단순하고 직관적이어서 소규모 프로젝트나 단일 캐릭터 중심의 액션 RPG를 빠르게 구현하는 데 최적화되어 있다.
  • 디버깅 용이: 코드의 흐름(Call Stack)을 따라가기 쉬워 에러를 찾고 고치는 과정이 단순하다.
• 👎 단점 (Cons)
  • 확장성 부족: 캐릭터가 탈것에 탑승하거나, 해당 캐릭터 껍데기를 AI 몬스터로 재활용하려고 할 때 불필요한 인풋 코드가 딸려와 구조가 꼬이기 쉽다.

Lyra 프로젝트의 방식 (Component 기반 디커플링)

• 구현 방식: Character나 Controller에 직접 코딩하지 않고, HeroComponent라는 폰 전용 부품을 만들어 인풋 처리를 전담시킨다.
  • 👍 장점 (Pros)
  • 극강의 재사용성(모듈화): 똑같은 캐릭터 껍데기를 AI로 쓸 때는 부품을 빼고, 플레이어가 조종할 때나 다른 탈것에 탈 때는 부품만 '찰칵' 붙여주면 완벽하게 작동한다.
  • 데이터 기반 제어: 하드코딩된 함수 대신 InputTag를 사용하여, 기획자가 C++ 코드 수정 없이도 GAS를 통해 스킬과 입력을 자유롭게 매핑할 수 있다.
• 👎 단점 (Cons)
  • 초기 학습 및 설계 비용: 구조가 매우 복잡해서(Over-engineering) 엔진의 깊은 이해도가 필요하며, 작은 프로젝트에 도입하면 오히려 파일 개수만 쓸데없이 많아지고 개발 속도가 저하된다.

---

2. 인풋은 언제 감지해야 할까? (타이밍 관점)

🤔 우리 팀의 방식: Tick을 활용한 폴링(Polling)

• 구현 방식: Enhanced Input에서 버튼이 눌린 상태(bool)를 저장하고, 매 프레임 Tick에서 그 상태를 검사하여 로직을 실행한다.
• 👍 장점 (Pros)
  • 상태 지속형 로직 구현이 쉬움: 버튼을 누르고 있는 동안 게이지가 차오르는 '차지 공격'이나 '연사' 같은 기능을 짤 때, 매 프레임 검사하는 방식이 생각하기 훨씬 직관적이다.
• 👎 단점 (Cons)
  • 성능 낭비와 씹힘 현상: 1초에 60~144번씩 조건문을 돌려야 하므로 CPU 리소스가 낭비된다. 또한 프레임 드랍(렉)이 발생했을 때 찰나의 입력을 떼버리면, Tick이 돌기 전에 상태가 바뀌어 입력이 무시되는(씹히는) 치명적인 단점이 있다.

Lyra의 방식: 이벤트 기반(Event-Driven)과 Delegate

• 구현 방식: Tick을 아예 쓰지 않고, 입력이 발생하는 순간 커스텀 입력 컴포넌트가 ASC에게 즉시 이벤트를 쏴버린다.
• 👍 장점 (Pros)
  • 최고의 성능 최적화: 유저가 키보드를 누르는 그 찰나에만 코드가 실행되므로 성능 낭비가 0(Zero)에 가깝다.
  • 신뢰성 보장: OS의 인터럽트 메시지를 즉시 낚아채므로 입력 누락(씹힘)이 절대 발생하지 않으며, 캐릭터 클래스에 불필요한 상태 변수(bool)들을 만들지 않아도 된다.
• 👎 단점 (Cons)
  • 메모리 관리 주의: 델리게이트(이벤트)를 바인딩해 놓고 액터가 파괴될 때 제대로 해제(Unbind)하지 않으면 댕글링 포인터(메모리 누수/크래시)가 발생할 위험이 있다.
  • 추적의 어려움: 언제 어디서 이벤트가 날아와서 함수가 실행되었는지 직관적으로 보이지 않아 로직의 흐름을 파악하기 까다롭다.

---

3. CS 관점: 게임 루프와 옵저버 패턴 (Observer Pattern)

*"입력을 기다리면 스레드가 멈춰있는(Block) 것 아닐까?"*
정답은 NO. 게임 엔진은 멈추지 않고 논블로킹(Non-blocking)으로 메시지를 확인한다.

🔄 1프레임의 생애 주기와 OS 메시지 큐

1. 하드웨어 인터럽트: 유저가 키보드를 누르면 OS(윈도우)가 입력을 낚아채서 프로그램 우체통(Message Queue)에 넣어둔다.
2. OS Pump: 언리얼 엔진은 매 프레임의 맨 처음(ProcessPlayerInput 단계)에 이 우체통을 열어본다.
3. Input Processing: 쪽지가 있으면 Enhanced Input 시스템을 거쳐 각종 이벤트를 발생시킨다.
4. Tick & Render: 이후 액터들의 게임 로직(Tick)이 돌고, 물리 엔진과 렌더링이 수행된다.

💡 우리는 왜 이중 폴링을 하고 있었을까?

엔진 밑바닥은 OS와 통신하기 위해 매 프레임 폴링(Polling)을 하는 것이 맞다.
하지만 우리 캐릭터까지 엔진에게 매 프레임 "입력 들어왔어?" 하고 묻는 것은 이중 폴링(비효율)이다.

Lyra처럼 옵저버 패턴(델리게이트/콜백)을 사용하면, 캐릭터는 가만히 자기 할 일(Tick)을 하다가 엔진이 "입력 들어왔어!" 하고 전화를 걸어줄 때만 반응하면 된다.

---

🌱 오늘의 회고 및 Next Step

• 당장 F4 프로젝트의 구조가 틀린 것은 아니다. 기한과 스케일에 맞는 최적의 선택이었다.
• 하지만 다음번 리팩토링이나 새로운 프로젝트에서는 트레이드오프를 고려하여, Tick에 의존하는 입력 처리를 과감히 지우고 Delegate를 활용한 이벤트 기반 호출로 성능과 코드 가독성을 현업 수준으로 끌어올려 봐야겠다.