AI와 함께 핵심 게임 메커니즘 만들기

작은 기능을 하나씩 완성하는 개발 리듬

이 장부터는 언리얼을 '구경하는 단계'에서 벗어나 실제로 게임다운 기능을 붙여 나갑니다. 입력을 받고, 캐릭터가 움직이고, 공격이 맞고, 체력이 줄고, 아이템을 줍습니다. 말로 쓰면 단순하지만, 게임 개발에서는 이 다섯 가지가 거의 모든 장르의 뼈대가 됩니다.

여기서 중요한 것은 한 번에 거대한 시스템을 만들지 않는 것입니다. AI에게도 마찬가지입니다. "3D 액션 게임 전투 시스템을 만들어줘"라고 던지면 그럴듯한 답은 오지만, 실제 프로젝트에 붙이면 어디서부터 고쳐야 할지 막막해질 수 있습니다. 대신 우리는 다음과 같은 짧은 리듬으로 움직입니다.

• 목표를 한 문장으로 정합니다.

• 필요한 에셋, 변수, 이벤트를 먼저 나열합니다.

• 블루프린트 노드 흐름을 작게 만듭니다.

• 플레이해서 검증합니다.

• 이상한 점을 AI에게 설명하고 다시 좁혀 고칩니다.

이 리듬은 Unity에서 코루틴 하나, MonoBehaviour 하나씩 붙여 가던 방식과 비슷합니다. 다만 언리얼에서는 입력, 이동, 충돌, 데미지, 데이터가 각각 엔진의 정해진 시스템과 연결됩니다. 그 구조를 존중하면 블루프린트가 깔끔해지고, AI에게도 훨씬 정확히 일을 시킬 수 있습니다.

이번 장에서 만들 시스템은 최종 프로젝트인 3D 액션 어드벤처 미니게임의 기반입니다. 플레이어는 이동하고, 점프하고, 대시하고, 공격합니다. 적이나 오브젝트는 맞으면 체력이 줄고, 죽거나 파괴됩니다. 아이템은 데이터 테이블에 정의하고, 인벤토리에는 최소한의 정보만 저장합니다. 여기까지 만들면 게임은 아직 작지만 이미 "플레이 가능한 구조"를 갖습니다.

Enhanced Input으로 입력부터 분리하기

UE 5 계열에서는 기존 입력 시스템보다 Enhanced Input을 기준으로 생각하는 편이 좋습니다. Epic 문서에서도 Enhanced Input의 핵심 요소를 Input Action, Input Mapping Context, Input Modifier, Input Trigger 네 가지로 설명합니다.¹ 이름은 길지만 개념은 간단합니다. Input Action은 플레이어가 하려는 행동이고, Input Mapping Context는 그 행동을 어떤 키나 버튼에 연결할지 담은 묶음입니다. Modifier는 입력값을 뒤집거나 보정하는 장치이고, Trigger는 눌렀는지, 누르고 있는지, 일정 시간 이상 눌렀는지를 판단하는 조건입니다.

Unity식으로 비유하면 Input Action은 Unity Input System의 Action에 가깝고, Mapping Context는 특정 상황에서 활성화되는 Action Map처럼 볼 수 있습니다. 평상시 조작, 인벤토리 조작, 차량 조작을 서로 다른 컨텍스트로 나누면 런타임에 입력 체계를 바꾸기 쉽습니다.

먼저 Content Browser에 Input 폴더를 만들고 다음 에셋을 준비합니다.

IMC_Player 안에서는 IA_Move에 WASD를 연결합니다. W와 S는 앞뒤 축, A와 D는 좌우 축이 되도록 Modifier에서 Negate와 Swizzle을 적절히 사용합니다. 처음에는 설정이 낯설 수 있지만, 핵심은 하나입니다. 키보드의 네 개 키를 최종적으로 하나의 2D 벡터로 만드는 것입니다. W를 누르면 Y가 1, S를 누르면 Y가 -1, D를 누르면 X가 1, A를 누르면 X가 -1이 되면 됩니다.

이제 만든 Mapping Context를 실제 플레이어에게 등록해야 합니다. 블루프린트에서는 보통 플레이어 Character의 BeginPlay에서 Get Controller를 가져오고, Player Controller로 캐스팅한 뒤, Local Player Subsystem을 얻어 Add Mapping Context를 호출합니다. Epic의 Add Mapping Context API는 특정 로컬 플레이어 서브시스템에 입력 매핑 컨텍스트를 추가하고 우선순위를 지정하는 흐름으로 사용됩니다.²

다만 실전에서는 BeginPlay와 Possessed의 차이를 알아 두는 것이 좋습니다. 싱글플레이 Third Person 템플릿처럼 단순한 구조라면 Character의 BeginPlay에서 등록해도 대체로 잘 동작합니다. 하지만 캐릭터가 런타임에 교체되거나, 리스폰되거나, 멀티플레이를 고려한다면 PlayerController 쪽에서 Possess 이후 등록하는 편이 안정적입니다. 입력은 '몸'보다 '조종자'에 가깝기 때문입니다.

AI에게 이 작업을 맡길 때는 이렇게 요청하면 좋습니다.

UE 5.6 블루프린트 기준으로 Third Person Character에 Enhanced Input을 설정하려고 합니다. IA_Move, IA_Look, IA_Jump, IA_Attack, IA_Dash, IMC_Player를 이미 만들었습니다. BeginPlay 또는 Possessed에서 IMC_Player를 로컬 플레이어에게 등록하는 노드 흐름을 설명해 주세요. 각 노드의 실행 핀 연결과 캐스팅 대상도 함께 알려 주세요.

AI가 답을 주면 바로 따라 하기 전에 세 가지를 확인하세요. 첫째, Enhanced Input Local Player Subsystem을 제대로 가져오는가. 둘째, Add Mapping Context의 Mapping Context에 우리가 만든 IMC_Player가 들어가는가. 셋째, 우선순위가 0 또는 의도한 값으로 들어가는가.

이동과 점프: Character Movement Component를 믿으세요

언리얼의 Character 클래스에는 Character Movement Component가 붙어 있습니다. 이것은 Unity의 CharacterController와 Rigidbody 이동 로직, 그리고 일부 플레이어 이동 보정 기능이 합쳐진 것처럼 생각하면 됩니다. 직접 위치를 계속 SetActorLocation으로 밀어도 움직일 수는 있지만, 그렇게 하면 경사면, 낙하, 점프, 네트워크 이동 같은 엔진 기능을 놓치기 쉽습니다.

IA_Move가 Triggered될 때의 기본 흐름은 다음과 같습니다. Action Value를 2D 벡터로 읽고, 컨트롤러의 Yaw 회전만 뽑습니다. 그 회전에서 Forward Vector와 Right Vector를 구한 뒤, Y값은 Forward 방향에, X값은 Right 방향에 넣어 Add Movement Input을 호출합니다. 여기서 Pitch를 빼는 이유는 간단합니다. 카메라가 하늘을 보고 있어도 캐릭터가 하늘로 걸어 올라가면 안 되기 때문입니다. 이동은 수평 방향만 따라가야 자연스럽습니다.

IA_Look은 Add Controller Yaw Input과 Add Controller Pitch Input에 연결합니다. 마우스 감도가 너무 빠르거나 느리면 Action Value에 Scalar Modifier를 쓰거나, 블루프린트에서 별도의 LookSensitivity 변수를 곱해 조정합니다.

점프는 더 쉽습니다. IA_Jump의 Started 또는 Triggered에서 Jump를 호출하고, Completed 또는 Canceled에서 Stop Jumping을 호출하면 됩니다. 버튼을 누른 순간 점프하고, 버튼을 뗐을 때 점프 입력을 중단하는 구조입니다.

이제 조작감을 만지는 시간입니다. Character Movement Component의 값 몇 개만 바꿔도 캐릭터의 성격이 달라집니다.

Unity 개발자라면 여기서 '스크립트로 직접 Lerp하고 싶다'는 충동이 올 수 있습니다. 하지만 처음에는 컴포넌트가 제공하는 값을 최대한 활용하세요. 언리얼은 캐릭터 이동에 대해 이미 많은 가정을 갖고 있고, 그 가정을 따라갈 때 다른 시스템과 충돌이 적습니다.

대시: Tick 없이 짧고 강한 이동 만들기

대시는 액션 게임의 첫 번째 손맛입니다. 구현 방식은 여러 가지가 있지만 입문 단계에서는 Launch Character를 사용하는 방식이 가장 이해하기 쉽습니다. 현재 캐릭터의 전방 방향을 구하고, 여기에 Dash Strength를 곱해 Launch Velocity로 넣습니다. Z값은 0으로 두면 수평 대시가 됩니다.

필요한 변수는 많지 않습니다. DashStrength, DashCooldown, CanDash 정도면 충분합니다. IA_Dash가 Started될 때 CanDash가 true인지 확인합니다. true라면 CanDash를 false로 바꾸고, Launch Character를 호출합니다. 그다음 Timer를 걸어 DashCooldown 시간이 지나면 CanDash를 다시 true로 만듭니다.

초보자가 자주 하는 실수는 Tick으로 쿨다운을 직접 줄이는 것입니다. 물론 가능하지만, 단순한 대시 쿨다운에는 Timer가 더 깔끔합니다. Tick은 매 프레임 실행되므로 필요하지 않은 로직이 계속 돕니다. 반면 Timer는 시간이 되었을 때만 이벤트를 호출합니다.

AI에게는 이렇게 시키세요.

Third Person Character 블루프린트에 대시를 추가하고 싶습니다. Enhanced Input의 IA_Dash Started에서 실행합니다. 변수는 DashStrength float 1200, DashCooldown float 0.8, CanDash bool true를 사용합니다. Launch Character 기반으로 만들고, 대시 후 Timer로 쿨다운을 복구하는 노드 흐름을 알려 주세요. Tick은 사용하지 말아 주세요.

마지막 문장이 중요합니다. "Tick은 사용하지 말아 주세요." AI는 종종 가장 직관적인 방법을 고르기 때문에, 피하고 싶은 방식도 함께 적어야 합니다.

공격 판정: 발사체와 라인 트레이스

공격은 크게 두 가지 방식으로 시작할 수 있습니다. 하나는 실제 발사체 Actor를 스폰하는 방식이고, 다른 하나는 보이지 않는 선을 쏘아 맞았는지 검사하는 라인 트레이스 방식입니다.

발사체 방식은 눈에 보이는 탄환, 화살, 마법 구체처럼 이동 시간이 있는 공격에 잘 맞습니다. BP_Projectile을 만들고 Sphere Collision, Static Mesh 또는 Niagara 이펙트, Projectile Movement Component를 붙입니다. 공격 입력이 들어오면 캐릭터의 손, 총구, 혹은 카메라 앞 위치에서 Projectile을 Spawn Actor로 생성합니다. 발사체는 날아가다가 Hit 또는 Overlap 이벤트가 발생하면 데미지를 주고 사라집니다.

라인 트레이스 방식은 총알처럼 즉시 맞는 공격, 근접 공격의 간단한 판정, 상호작용 검사에 좋습니다. 시작 지점과 끝 지점을 정하고 Line Trace By Channel을 호출합니다. 맞았다면 Hit Result에서 맞은 Actor, 위치, 노멀 정보를 꺼낼 수 있습니다.

충돌은 언리얼 입문자가 가장 많이 헤매는 부분입니다. "분명 맞았는데 이벤트가 안 온다"는 말은 거의 항상 충돌 설정 문제입니다. Collision Preset, Object Channel, Trace Channel, Response가 서로 맞아야 합니다. 발사체가 적을 Overlap하도록 만들었다면 발사체의 Collision은 Generate Overlap Events가 켜져 있어야 하고, 적의 Collision Response도 해당 채널에 Overlap으로 반응해야 합니다.

AI가 만들어 준 공격 블루프린트는 반드시 다음을 확인하세요.

• Spawn Transform의 위치와 회전이 올바른가.

• Projectile Collision이 실제로 적과 Overlap 또는 Block하는가.

• Hit Actor가 자기 자신일 때 무시하는 처리가 있는가.

• 데미지 처리 로직이 특정 캐릭터 클래스에 과하게 묶이지 않았는가.

• 한 번 맞은 뒤 Destroy Actor가 너무 빨라 이펙트나 사운드가 끊기지 않는가.

체력과 데미지: Actor Component로 분리하기

이제 맞았을 때 체력이 줄어야 합니다. 가장 쉬운 방법은 플레이어 블루프린트와 적 블루프린트 안에 각각 CurrentHealth, MaxHealth 변수를 넣는 것입니다. 하지만 이 방식은 금방 지저분해집니다. 플레이어, 적, 파괴 가능한 상자, 보스, 훈련용 더미가 모두 체력을 가져야 한다면 같은 로직을 계속 복사해야 합니다.

더 나은 선택은 Actor Component입니다. BP_HealthComponent를 만들고, 체력이 필요한 Actor에 붙입니다. 이렇게 하면 체력 시스템은 캐릭터의 종류와 독립됩니다. Unity의 컴포넌트 사고방식에 익숙한 독자라면 오히려 반가운 구조입니다.

BP_HealthComponent에는 다음 변수를 둡니다.

BeginPlay에서는 CurrentHealth를 MaxHealth로 초기화합니다. 데미지 값이 들어오면 CurrentHealth에서 빼고, 0과 MaxHealth 사이로 Clamp합니다. 체력이 바뀌면 OnHealthChanged 이벤트 디스패처를 호출합니다. CurrentHealth가 0 이하이고 아직 IsDead가 false라면 IsDead를 true로 바꾸고 OnDeath 이벤트 디스패처를 호출합니다.

이벤트 디스패처를 쓰면 체력 컴포넌트가 UI, 애니메이션, 사운드를 직접 알 필요가 없습니다. UI는 OnHealthChanged를 구독해서 체력바를 바꾸면 되고, 캐릭터는 OnDeath를 구독해서 래그돌이나 사망 애니메이션을 실행하면 됩니다.

요청 예시는 다음과 같습니다.

BP_HealthComponent Actor Component를 블루프린트로 만들고 싶습니다. 변수는 MaxHealth, CurrentHealth, IsDead를 사용합니다. 함수 또는 커스텀 이벤트 ApplyHealthDamage(DamageAmount)를 만들고, 체력이 변하면 OnHealthChanged, 사망하면 OnDeath 이벤트 디스패처를 호출하게 해 주세요. 이 컴포넌트는 플레이어, 적, 파괴 가능한 오브젝트에 재사용할 것입니다.

AI가 답을 주면 컴포넌트 안에서 특정 캐릭터 클래스로 Cast하는지 확인하세요. Cast To BP_PlayerCharacter가 들어가 있다면 재사용성이 깨집니다. 체력 컴포넌트는 플레이어를 몰라야 합니다. Owner만 알면 됩니다.

아이템과 인벤토리: 데이터는 밖에, 보유량은 안에

인벤토리는 욕심을 내기 쉬운 시스템입니다. 드래그 앤 드롭 UI, 장비 슬롯, 퀵슬롯, 아이템 등급, 무게 제한, 저장과 로드까지 생각하면 갑자기 거대한 프로젝트가 됩니다. 하지만 지금 필요한 것은 미니게임에서 아이템을 줍고, 몇 개 가지고 있는지 관리하고, 필요할 때 효과를 적용하는 정도입니다.

핵심 원칙은 "아이템 정의 데이터와 플레이어의 보유 데이터를 분리한다"입니다. 아이템 정의는 변하지 않는 정보입니다. 포션의 이름, 아이콘, 최대 보유 수량, 회복량 같은 것입니다. 반면 보유 데이터는 플레이어가 지금 포션을 몇 개 가지고 있는지에 대한 정보입니다.

먼저 구조체 ST_ItemDefinition을 만듭니다.

그다음 이 구조체를 기반으로 Data Table DT_Items를 만듭니다. Data Table은 Unity의 ScriptableObject 목록처럼 생각할 수 있습니다. 차이는 언리얼에서는 표 형태의 데이터 에셋으로 관리한다는 점입니다. 밸런스 조정이 쉬워지고, 블루프린트가 데이터로 가득 차는 것을 막을 수 있습니다.

인벤토리 내부에는 전체 아이템 정의를 복사해서 저장하지 않습니다. ST_InventorySlot 구조체를 따로 만들고 ItemID, Quantity만 둡니다. 예를 들어 플레이어가 작은 회복 물약 3개를 가지고 있다면 인벤토리에는 Potion_Small, 3만 있으면 됩니다. 이름, 아이콘, 회복량은 필요할 때 DT_Items에서 Potion_Small 행을 찾아 읽습니다.

BP_InventoryComponent에는 InventorySlots 배열을 둡니다. AddItem(ItemID, Amount) 함수는 먼저 같은 ItemID가 있는 슬롯을 찾고, MaxStack까지 채웁니다. 남는 수량이 있으면 새 슬롯을 만듭니다. RemoveItem(ItemID, Amount)는 수량을 줄이고 0이 되면 슬롯을 제거합니다. UseItem(ItemID)는 Data Table에서 해당 아이템 정의를 읽고, ItemType에 따라 효과를 적용한 뒤 수량을 하나 줄입니다.

AI에게 모든 것을 한 번에 만들라고 하지 말고 순서를 나누세요.

1단계: ST_ItemDefinition과 ST_InventorySlot에 필요한 필드를 제안해 주세요. 데이터 테이블에는 아이템 정의만 넣고, 인벤토리에는 ID와 수량만 저장하고 싶습니다.

2단계: BP_InventoryComponent의 AddItem 함수를 블루프린트 노드 흐름으로 설명해 주세요. 같은 ItemID가 있으면 MaxStack까지 더하고, 남으면 새 슬롯을 추가하는 구조로 만들어 주세요.

3단계: UseItem에서 Data Table Row를 읽어 회복 아이템이면 BP_HealthComponent에 회복을 적용하는 흐름을 설계해 주세요. 단, InventoryComponent가 특정 플레이어 클래스로 캐스팅하지 않도록 해 주세요.

이렇게 나누면 AI의 답이 훨씬 검토하기 쉬워집니다.

AI 도구와 함께 작업할 때의 현실적인 워크플로우

2026년 현재 언리얼 주변에는 블루프린트를 직접 생성하거나 편집하려는 AI 도구가 계속 늘고 있습니다. 일반 Claude나 ChatGPT는 설명과 설계에 강하고, 에디터 플러그인형 도구는 실제 에셋 생성과 그래프 편집에 강합니다. 예를 들어 AI 블루프린트 생성 도구는 자연어 요청을 변수, 함수, 노드, 연결로 바꾸어 에디터 안의 실제 블루프린트 자산을 만들 수 있다는 점을 내세웁니다.³ Aura 같은 도구도 언리얼 에디터 안에서 블루프린트 그래프를 생성하고 편집하는 워크플로우를 제공한다고 설명합니다.⁴ UnrealClaude는 UE 5.7 문맥과 MCP 도구를 통해 블루프린트, 에셋, 레벨, Enhanced Input 관련 작업을 에디터와 연결하려는 접근을 보여 줍니다.⁵

하지만 도구가 강해질수록 개발자의 검토 능력은 더 중요해집니다. AI가 만든 블루프린트가 컴파일된다고 해서 좋은 구조라는 뜻은 아닙니다. 특히 다음 항목은 직접 봐야 합니다.

• 엔진 버전에 없는 노드나 이름이 바뀐 노드를 추천하지 않았는가.

• 실행 핀이 끊겨 있어 이벤트가 실제로 흐르지 않는 곳은 없는가.

• 매 프레임 Tick에서 불필요한 검색, 캐스팅, Spawn을 하고 있지 않은가.

• 특정 클래스에 과하게 Cast해서 재사용성이 깨지지 않았는가.

• Collision Preset, Object Channel, Trace Channel이 실제 프로젝트 설정과 맞는가.

• 변수 이름은 명확하고, 디버그하기 쉬운 구조인가.

AI에게 요청할 때는 다음 형식을 기본으로 삼으면 좋습니다.

목표: 플레이어가 왼쪽 클릭으로 발사체를 쏘게 한다.
이미 있는 것: BP_PlayerCharacter, IA_Attack, BP_Projectile, BP_HealthComponent.
필요한 변수: ProjectileClass, MuzzleOffset, AttackCooldown, CanAttack.
원하는 노드 흐름: IA_Attack Started에서 쿨다운 확인 후 Spawn Actor, 발사체가 Overlap되면 Apply Damage.
검증 기준: 플레이하면 클릭할 때만 발사체가 나가고, 적에게 닿으면 체력이 줄고, 자기 자신에게는 데미지를 주지 않아야 한다.
제한: Tick 사용 금지, 플레이어 캐릭터에 체력 로직 직접 작성 금지.

이런 프롬프트는 길어 보이지만 실제로는 시간을 절약합니다. AI가 상상으로 빈칸을 채우는 대신, 우리가 정한 설계 안에서만 움직이게 만들기 때문입니다.

작은 미니 루프 완성하기

이제 이 장에서 만든 기능을 하나의 미니 루프로 묶어 보겠습니다. 플레이어는 WASD로 이동합니다. 마우스로 시점을 돌립니다. Space로 점프합니다. Shift로 대시합니다. 왼쪽 클릭으로 발사체를 쏩니다. 적 더미는 Health Component를 가지고 있고, 발사체에 맞으면 체력이 줄어듭니다. 체력이 0이 되면 사라집니다. 바닥에 놓인 포션 Actor와 Overlap하면 Inventory Component에 Potion_Small이 추가됩니다. 키 하나를 눌러 포션을 사용하면 Health Component가 회복됩니다.

이 정도면 아직 게임은 아니라고 느낄 수 있습니다. 하지만 실제로는 거의 모든 액션 게임의 기본 루프가 들어 있습니다. 입력, 이동, 공격, 충돌, 데미지, 사망, 아이템, 회복. 여기에 적 AI, UI, 사운드, 애니메이션, 레벨 디자인을 얹으면 게임이 됩니다.

마지막으로 플레이 테스트 체크리스트를 남깁니다.

• 입력이 한 번만 등록되는가. 리스폰할 때 Mapping Context가 중복 추가되지 않는가.

• 이동 방향이 카메라 Yaw를 기준으로 자연스럽게 바뀌는가.

• 점프와 대시가 동시에 눌렸을 때 이상한 속도가 나오지 않는가.

• 발사체가 자기 자신과 충돌하지 않는가.

• 데미지 처리가 Health Component를 통해 재사용 가능한가.

• 아이템 정의와 보유 수량이 분리되어 있는가.

• AI가 만든 노드를 내가 설명할 수 있는가.

마지막 항목이 가장 중요합니다. AI가 대신 만들어 줬더라도, 내가 설명할 수 없다면 아직 내 시스템이 아닙니다. 반대로 노드 하나하나를 완벽히 외우지 않아도 흐름을 설명할 수 있다면 충분합니다. 언리얼 학습에서 중요한 것은 노드 암기가 아니라 시스템 감각입니다. 입력은 입력 시스템에, 이동은 Movement Component에, 체력은 Actor Component에, 아이템 정의는 Data Table에 맡깁니다. 각 시스템의 자리를 알면 AI는 훨씬 유능한 페어 프로그래머가 됩니다.

다음 장에서는 이렇게 움직이는 게임에 시각적 완성도를 더합니다. 어두운 공간에 빛을 놓고, 표면을 살아 있게 만들고, 장면 전체를 그럴듯하게 보이게 하는 단계입니다. 조작되는 게임에서 '보여 주고 싶은 게임'으로 넘어갈 시간입니다.

참고

¹Enhanced Input in Unreal Engine

²Add Mapping Context

³AI Blueprint Generation in Unreal Engine 5 — How to Build Faster with AI

⁴Unreal AI Agent for Blueprint Generation