플레이어 컨트롤러, 폰 블루프린트

플레이어가 키를 누르면 캐릭터가 움직입니다. 이 단순한 동작 뒤에는 입력을 받는 객체와 월드에서 실제로 움직이는 객체가 따로 있습니다. 둘을 하나로 생각하고 그래프를 짜면, 캐릭터가 죽고 다시 태어나는 순간 입력이 엉뚱한 대상으로 가거나 점수가 사라지는 문제가 생깁니다.

앞 글에서 게임 모드와 두 스테이트로 규칙과 상태를 나눴다면, 이 글에서는 플레이어 조작의 흐름을 나눕니다. 입력을 받아 해석하는 플레이어 컨트롤러(Player Controller)와, 월드에서 행동하는 폰(Pawn)과 캐릭터(Character)의 역할을 살펴보고, 컨트롤러가 폰을 조종하는 빙의(Possess)와 재스폰 흐름을 따라갑니다.

---

플레이어 컨트롤러: 플레이어의 뜻을 받는 객체

플레이어 컨트롤러는 마우스, 키보드, 게임패드 같은 플레이어의 입력을 받아 폰을 조종하고, UI와 카메라처럼 플레이어 한 명에게만 필요한 기능을 다루는 클래스입니다. 공식 문서는 플레이어 컨트롤러를 폰과 그 폰을 조종하는 사람 사이의 연결 지점으로 설명합니다. 그래서 폰은 죽고 다시 태어나며 바뀔 수 있지만, 플레이어 컨트롤러는 게임이 이어지는 동안 그대로 남습니다.

네트워크에서는 서버가 모든 플레이어의 플레이어 컨트롤러를 가지고, 각 클라이언트에는 자신이 소유한 플레이어 컨트롤러만 있습니다. 다른 플레이어의 컨트롤러가 모든 클라이언트에 복제되는 구조가 아니므로, 다른 플레이어의 정보를 보여 주려면 앞 글의 플레이어 스테이트를 씁니다.

플레이어 컨트롤러가 맡는 일은 다음과 같습니다.

• 입력 처리: 마우스 클릭, 키보드, 게임패드 입력을 처리할 수 있습니다. 입력 바인딩은 폰이나 캐릭터에도 둘 수 있으므로, 어느 쪽에서 어떤 입력을 처리할지 정해 둡니다.
• 폰 조종: 빙의할 폰을 정하고 그 폰에 이동, 공격 같은 명령을 내립니다. 플레이어가 죽어 새 폰으로 재스폰될 때도 플레이어 컨트롤러는 유지됩니다.
• 카메라: 플레이어 시점의 카메라를 다룹니다.
• UI: 위젯을 화면에 띄우고, 마우스 커서를 표시하거나 숨기고, 버튼 클릭 같은 UI 상호작용을 처리합니다.
• 네트워크 통신: 멀티플레이어에서 플레이어의 요청을 서버로 보내는 통로가 됩니다.
• HUD: 플레이어에게 정보를 표시하는 HUD(Heads-Up Display)를 만들고 관리합니다.

공식 문서는 입력을 어디에 둘지에 대한 기준도 줍니다. 단순한 게임이라면 폰에 입력을 두어도 되지만, 한 클라이언트에서 여러 플레이어가 함께 하거나 실행 중에 조종할 캐릭터를 바꿔야 한다면 플레이어 컨트롤러가 입력을 받고 폰에 명령을 내리는 편이 낫다는 것입니다. 이 글의 예제는 이 방식대로 플레이어 컨트롤러가 입력의 뜻을 해석하고, 폰이 월드에서 행동하도록 나눕니다.

플레이어 컨트롤러 블루프린트 만들기

콘텐츠 브라우저에서 마우스 오른쪽 버튼을 눌러 Blueprint Class를 고르고, 부모 클래스로 PlayerController를 선택한 뒤 PC_MyPlayer처럼 이름을 짓습니다. 그다음 게임 모드 블루프린트 GM_MyGame을 열어 Class Defaults를 누르고, 디테일 패널의 Classes 섹션에서 Player Controller Class를 PC_MyPlayer로 바꿉니다.

이제 PC_MyPlayer의 이벤트 그래프에서 입력을 처리할 수 있습니다. 예를 들어 점프 입력 액션 이벤트에서 Get Controlled Pawn으로 이 컨트롤러가 지금 빙의한 폰을 가져오고, 유효한지 확인한 뒤 Character로 캐스트해 Jump를 호출합니다. 캐스트가 필요한 이유는 Jump가 Character의 기능이라서 일반 Pawn에는 없기 때문입니다. 비슷한 노드로 Get Player Pawn이 있지만, 이 노드는 플레이어 인덱스로 폰을 찾습니다. 특정 컨트롤러가 조종하는 폰이 필요할 때는 그 컨트롤러의 Get Controlled Pawn을 쓰는 편이 정확합니다.

언리얼 엔진 5.8의 기본 입력 방식인 향상된 입력(Enhanced Input)을 쓴다면, 먼저 콘텐츠 브라우저의 Input 분류에서 입력 액션 IA_Jump를 만들고, 입력 매핑 컨텍스트(Input Mapping Context) IMC_Default에 IA_Jump를 추가해 Space Bar를 묶습니다. 그리고 PC_MyPlayer의 Event BeginPlay에서 Enhanced Input Local Player Subsystem의 Add Mapping Context로 이 매핑 컨텍스트를 등록합니다. 등록하지 않으면 입력 액션 이벤트가 실행되지 않습니다.

---

폰과 캐릭터: 월드에서 행동하는 객체

폰은 컨트롤러가 빙의할 수 있는 액터입니다. 월드의 모든 오브젝트가 폰은 아니며, 폰이라고 해서 반드시 보이는 메시나 물리 시뮬레이션을 가질 필요도 없습니다. 폰은 플레이어 컨트롤러에도, AI 컨트롤러에도 빙의될 수 있으므로 같은 폰 클래스를 플레이어와 AI가 함께 쓸 수도 있습니다. 폰에도 입력 처리 로직을 둘 수 있지만, 앞에서 정한 대로 이 글에서는 폰이 월드에서의 행동을 맡습니다.

폰이 맡는 일은 다음과 같습니다.

• 월드 안의 존재: 필요에 따라 메시, 콜리전, 이동 컴포넌트를 갖춥니다.
• 이동과 상호작용: 컨트롤러의 명령을 받아 움직이고, 다른 오브젝트와 상호작용합니다.
• 빙의 대상: 플레이어나 AI가 조종할 수 있습니다.

캐릭터는 언리얼 엔진에서 가장 많이 쓰이는 폰의 자식 클래스로, 사람이나 두 발로 걷는 동물처럼 걸어 다니는 대상에 맞춰져 있습니다. 캐릭터에는 처음부터 세 가지 컴포넌트가 들어 있습니다. 걷기, 달리기, 점프, 낙하와 그 이동에 필요한 네트워크 기능을 제공하는 CharacterMovementComponent, 애니메이션을 재생할 수 있는 스켈레탈 메시 컴포넌트, 몸통을 감싸는 캡슐 콜리전입니다. 그래서 대부분의 플레이어 캐릭터와 AI NPC가 Character를 부모 클래스로 씁니다. 다만 CharacterMovementComponent가 네트워크로 처리하는 것은 이동이며, 직접 만든 공격이나 인벤토리 로직까지 자동으로 복제해 주지는 않습니다.

폰과 캐릭터 블루프린트 만들기

콘텐츠 브라우저에서 Blueprint Class를 고르고, 부모 클래스로 Pawn이나 Character를 선택합니다. 비행체, 자동차, 고정된 카메라처럼 CharacterMovementComponent의 걷기 이동이 필요 없는 대상은 Pawn에서 시작하고, 사람 형태의 플레이어 캐릭터나 AI NPC는 Character에서 시작하는 것이 알맞습니다. 이름은 BP_PlayerCharacter나 BP_EnemyCharacter처럼 짓습니다.

플레이어 캐릭터는 게임 모드에 연결합니다. GM_MyGame의 Class Defaults에서 Classes 섹션의 Default Pawn Class를 BP_PlayerCharacter로 바꾸면, 게임이 시작될 때 이 클래스의 폰이 스폰되어 플레이어 컨트롤러에 빙의됩니다. AI 캐릭터는 게임 모드가 아니라 그 캐릭터 블루프린트의 Class Defaults에서 Pawn 섹션의 AI Controller Class로 어떤 AI 컨트롤러가 빙의할지 정합니다. 이 설정은 비헤이비어 트리의 기본 이해에서 AI를 구성할 때 다뤘습니다.

---

빙의와 재스폰의 흐름

플레이어 컨트롤러와 폰은 빙의(Possess)와 빙의 해제(UnPossess)로 연결됩니다. Possess는 컨트롤러가 특정 폰을 빙의해 조종 권한을 얻는 과정이고, UnPossess는 지금 조종하던 폰의 권한을 놓는 과정입니다. 기본 게임 모드는 플레이어가 게임을 시작할 때 지정된 폰을 스폰하고 빙의시킵니다. 네트워크 게임에서 Possess는 서버가 실행해야 하며, 플레이어가 죽었다고 엔진이 알아서 다시 스폰해 주지는 않으므로 게임 모드의 RestartPlayer 같은 흐름을 직접 호출하도록 만들어야 합니다.

한 판의 흐름을 따라가 보면 다음과 같습니다. 게임이 시작되면 GM_MyGame이 BP_PlayerCharacter를 스폰하고, PC_MyPlayer가 이 폰을 Possess합니다. 플레이어가 이동 키를 누르면 PC_MyPlayer가 입력을 받아 폰에 이동 입력을 넘기고, BP_PlayerCharacter의 CharacterMovementComponent가 실제 이동을 계산합니다. 플레이어가 죽으면 BP_PlayerCharacter는 파괴되지만 PC_MyPlayer는 계속 남습니다. 재스폰 때는 GM_MyGame이 새 BP_PlayerCharacter를 스폰하고, 기존의 PC_MyPlayer가 이 새 폰을 다시 Possess합니다. 점수와 스탯을 담은 PS_MyPlayer도 이 과정에서 그대로 쓰이므로, 재스폰 뒤에도 점수가 처음으로 돌아가지 않습니다.

재스폰은 같은 컨트롤러가 새 Pawn을 제어하는 흐름입니다

동일 PC1이 사망 전 PawnA를 제어하다가 제거/재스폰 후 PawnB를 제어한다. PlayerState 점수 유지와 현재 Pawn 재조회 시점을 구분한다.

PLAYER IDENTITY · CURRENT PAWN

재스폰은 같은 컨트롤러가 새 Pawn을 제어하는 흐름입니다

이 예제는 같은 게임 세션에서 Pawn A를 잃고 Pawn B를 새로 만드는 재스폰입니다. 두 그림은 다른 시점이며, PC 1이 동시에 두 Pawn을 제어한다는 뜻이 아닙니다.

1 · 사망 전

동일PC와현재Pawn의제어관계이시점은PC1→PawnA의단일제어관계다. 다른시점과연결한동시제어가아니다.

PC 1

현재 제어

Pawn A

2 · 재스폰 후

동일PC와현재Pawn의제어관계이시점은PC1→PawnB의단일제어관계다. 다른시점과연결한동시제어가아니다.

PC 1

현재 제어

Pawn B

컨트롤러 · Pawn · 플레이어 상태를 분리합니다

Pawn 교체 뒤 Get Controlled Pawn을 다시 조회·검증합니다. 이 재스폰 설계의 PlayerState는 점수를 유지하지만, 디스크 저장이나 모든 레벨 이동의 영속성을 뜻하지 않습니다.

서버에는 각 플레이어의 PC가, 클라이언트에는 자신의 PC가 있습니다. 사망만으로 자동 재스폰되는 것이 아니라 RestartPlayer 등의 경로를 구현합니다.

이 예의 조건

• 본문과 원 도표에 제시된 사례의 입력·조건을 사용합니다. 설명용 수치나 독립 비교 경로는 각 단계에 표시합니다.
• 현재 상태·값과 전환 근거의 위치는 모든 단계에서 같습니다. 조건이 맞지 않거나 실행되지 않은 경로를 성공한 동작으로 해석하지 않습니다.

관계도의 보충 설명

원 도표의 제목·노드·관계·조건·주석

범위	원문
범위도표 제목	원문동일 PC와 현재 Pawn의 제어 관계
범위관계·조건 설명	원문별개의 시점에서 동일 PC1이 현재 PawnA를 제어한다. 두 Pawn에 동시에 빙의하지 않으며 이 간선은 제어 관계다.
범위관계·조건 설명	원문이 시점은 PC1→PawnA의 단일 제어 관계다. 다른 시점과 연결한 동시 제어가 아니다.
범위관계·조건 설명	원문별개의 시점에서 동일 PC1이 현재 PawnB를 제어한다. 두 Pawn에 동시에 빙의하지 않으며 이 간선은 제어 관계다.
범위관계·조건 설명	원문이 시점은 PC1→PawnB의 단일 제어 관계다. 다른 시점과 연결한 동시 제어가 아니다.

예의 값과 변화

관찰·상황	값·보충 정보	변화·이유
기존 제어 PC1이 PawnA를 제어한다.	값·보충 정보 Controller: PC1 현재 Pawn: A	변화·이유 PlayerState에 저장된 점수는 Pawn 객체와 수명이 다르다.
사망·재스폰 PawnA가 끝나고 새 PawnB가 준비된다.	값·보충 정보 Controller: 같은 PC1 PawnA: 이전 대상	변화·이유 Controller를 새로 만든다고 가정하지 않는다.
새 제어 PC1이 PawnB를 제어하고 현재 Pawn을 재조회한다.	값·보충 정보 현재 Pawn: B PlayerState: 점수 유지	변화·이유 예전 Pawn 캐시를 계속 쓰지 않도록 연결 시점을 확인한다.

재스폰은 같은 컨트롤러가 새 Pawn을 제어하는 흐름입니다

동일 PC1이 사망 전 PawnA를 제어하다가 제거/재스폰 후 PawnB를 제어한다. PlayerState 점수 유지와 현재 Pawn 재조회 시점을 구분한다.

PLAYER IDENTITY · CURRENT PAWN

재스폰은 같은 컨트롤러가 새 Pawn을 제어하는 흐름입니다

이 예제는 같은 게임 세션에서 Pawn A를 잃고 Pawn B를 새로 만드는 재스폰입니다. 두 그림은 다른 시점이며, PC 1이 동시에 두 Pawn을 제어한다는 뜻이 아닙니다.

1 · 사망 전

동일PC와현재Pawn의제어관계이시점은PC1→PawnA의단일제어관계다. 다른시점과연결한동시제어가아니다.

PC 1

현재 제어

Pawn A

2 · 재스폰 후

동일PC와현재Pawn의제어관계이시점은PC1→PawnB의단일제어관계다. 다른시점과연결한동시제어가아니다.

PC 1

현재 제어

Pawn B

컨트롤러 · Pawn · 플레이어 상태를 분리합니다

Pawn 교체 뒤 Get Controlled Pawn을 다시 조회·검증합니다. 이 재스폰 설계의 PlayerState는 점수를 유지하지만, 디스크 저장이나 모든 레벨 이동의 영속성을 뜻하지 않습니다.

서버에는 각 플레이어의 PC가, 클라이언트에는 자신의 PC가 있습니다. 사망만으로 자동 재스폰되는 것이 아니라 RestartPlayer 등의 경로를 구현합니다.

이 예의 조건

• 본문과 원 도표에 제시된 사례의 입력·조건을 사용합니다. 설명용 수치나 독립 비교 경로는 각 단계에 표시합니다.
• 현재 상태·값과 전환 근거의 위치는 모든 단계에서 같습니다. 조건이 맞지 않거나 실행되지 않은 경로를 성공한 동작으로 해석하지 않습니다.

관계도의 보충 설명

원 도표의 제목·노드·관계·조건·주석

범위	원문
범위도표 제목	원문동일 PC와 현재 Pawn의 제어 관계
범위관계·조건 설명	원문별개의 시점에서 동일 PC1이 현재 PawnA를 제어한다. 두 Pawn에 동시에 빙의하지 않으며 이 간선은 제어 관계다.
범위관계·조건 설명	원문이 시점은 PC1→PawnA의 단일 제어 관계다. 다른 시점과 연결한 동시 제어가 아니다.
범위관계·조건 설명	원문별개의 시점에서 동일 PC1이 현재 PawnB를 제어한다. 두 Pawn에 동시에 빙의하지 않으며 이 간선은 제어 관계다.
범위관계·조건 설명	원문이 시점은 PC1→PawnB의 단일 제어 관계다. 다른 시점과 연결한 동시 제어가 아니다.

예의 값과 변화

관찰·상황	값·보충 정보	변화·이유
기존 제어 PC1이 PawnA를 제어한다.	값·보충 정보 Controller: PC1 현재 Pawn: A	변화·이유 PlayerState에 저장된 점수는 Pawn 객체와 수명이 다르다.
사망·재스폰 PawnA가 끝나고 새 PawnB가 준비된다.	값·보충 정보 Controller: 같은 PC1 PawnA: 이전 대상	변화·이유 Controller를 새로 만든다고 가정하지 않는다.
새 제어 PC1이 PawnB를 제어하고 현재 Pawn을 재조회한다.	값·보충 정보 현재 Pawn: B PlayerState: 점수 유지	변화·이유 예전 Pawn 캐시를 계속 쓰지 않도록 연결 시점을 확인한다.

위 그림은 같은 게임 세션에서 Pawn A를 잃고 Pawn B를 새로 만드는 재스폰을 두 시점으로 나누어 보여 줍니다. 사망 전에는 PC 1이 Pawn A를 현재 제어하고, 재스폰 뒤에는 같은 PC 1이 Pawn B를 제어합니다. 두 그림은 서로 다른 시점이며, PC 1이 두 폰을 동시에 빙의한다는 뜻이 아닙니다. 단계 그림은 이 흐름을 기존 제어, 사망과 재스폰, 새 제어의 세 단계로 따라갑니다. PC 1이 Pawn A를 제어하다가, Pawn A가 끝나고 새 Pawn B가 준비되며, 마지막으로 PC 1이 Pawn B를 제어하면서 현재 폰을 다시 조회합니다.

그림 아래의 설명은 컨트롤러, 폰, 플레이어 상태를 분리하라고 짚습니다. 폰을 교체한 뒤에는 Get Controlled Pawn을 다시 조회해 유효한지 확인해야 합니다. 이 재스폰 설계에서 플레이어 스테이트가 점수를 유지하지만, 그것이 디스크 저장이나 모든 레벨 이동에서의 보존을 뜻하지는 않습니다. 또 서버에는 각 플레이어의 컨트롤러가, 클라이언트에는 자신의 컨트롤러가 있으며, 사망만으로 자동 재스폰되지 않으므로 RestartPlayer 같은 경로를 구현해야 한다는 점도 함께 적혀 있습니다.

---

세 클래스의 역할과 수명

표의 핵심은 수명의 차이입니다. 플레이어 컨트롤러는 플레이어가 게임에 있는 동안 남고, 폰은 죽고 다시 태어날 때마다 새 인스턴스로 바뀝니다. 그래서 오래 유지해야 하는 정보와 참조를 어디에 둘지가 이 수명에 따라 정해집니다. 이렇게 클래스마다 역할을 나누면 게임 로직을 찾고 고치기 쉬워지고, 멀티플레이어에서 무엇이 어디에 존재하는지도 분명해집니다.

---

정리

• 플레이어 컨트롤러는 입력, UI, 카메라를 다루며 폰이 바뀌어도 유지됩니다. 서버에는 모든 플레이어의 컨트롤러가, 각 클라이언트에는 자신의 컨트롤러만 있습니다.
• 폰은 컨트롤러가 빙의할 수 있는 액터이고, 캐릭터는 캡슐 콜리전, 스켈레탈 메시, CharacterMovementComponent를 갖춘 폰의 자식 클래스입니다.
• 플레이어의 폰은 게임 모드의 Default Pawn Class로, AI의 컨트롤러는 캐릭터의 AI Controller Class로 지정합니다.
• Jump는 Character의 기능이므로 Get Controlled Pawn으로 얻은 폰을 Character로 캐스트한 뒤 호출합니다.
• 재스폰은 같은 컨트롤러가 새 폰을 빙의하는 흐름이며, Possess는 서버에서 실행하고 재스폰 경로는 직접 구현합니다.

---

연습 문제

1. 재스폰 뒤 점프가 되지 않는 이유

PC 1은 유지됐지만 Pawn A는 파괴되고 새 Character인 Pawn B가 빙의됐습니다. 그런데 입력 그래프는 게임 시작 때 변수에 저장해 둔 Pawn A 참조에 계속 Jump를 호출합니다. 같은 PC가 남았으니 이 참조도 Pawn B로 바뀔까요? 새 폰이 Character가 아닌 일반 Pawn이라면 무엇을 더 확인해야 할까요?

해설 보기

바뀌지 않습니다. 컨트롤러가 유지돼도, 변수에 저장한 옛 Pawn A의 참조가 저절로 새 대상을 가리키게 되지는 않습니다. Pawn A가 파괴되었으므로 이 참조는 더 이상 유효하지 않고, Jump도 실행되지 않습니다.

입력이 들어올 때마다 Get Controlled Pawn으로 현재 폰을 조회해 유효성을 검사하거나, 다시 빙의할 때 저장한 참조를 새 폰으로 갱신해야 합니다. Pawn B가 Character라면 Character로 캐스트가 성공한 뒤 Jump를 호출합니다. 일반 Pawn이라면 캐스트가 실패하므로, 실패 분기에서는 호출을 멈추고 그 폰에 맞는 이동이나 행동 방법을 따로 구성합니다. 캐스트 실패는 클래스가 다르기 때문이므로 네트워크 복제 설정을 바꿔서 해결할 문제가 아닙니다.

2. 점수를 어디에 둘까

죽을 때마다 새 폰으로 재스폰되는 게임에서 플레이어의 누적 점수를 BP_PlayerCharacter의 변수에 두었더니, 재스폰할 때마다 점수가 0이 됩니다. 왜 그럴까요? 점수를 어디로 옮겨야 할까요?

해설 보기

재스폰은 기존 폰을 고치는 것이 아니라 새 폰 인스턴스를 만드는 일이라서, 새 폰의 점수 변수는 기본값 0으로 시작합니다. 쓰러진 폰의 변수는 그 인스턴스와 함께 사라집니다.

누적 점수는 폰보다 오래 사는 객체에 두어야 합니다. 다른 플레이어에게도 보여야 한다면 플레이어 스테이트 PS_MyPlayer가 알맞고, 그렇지 않은 싱글플레이어라면 플레이어 컨트롤러에 두어도 재스폰을 넘어 유지됩니다. 어느 쪽이든 게임을 껐다 켠 뒤까지 남기려면 세이브를 따로 설계합니다.

3. 컨트롤러와 폰 중 입력을 둘 곳

한 게임에서 플레이어가 걸어 다니다가 차량에 타면 차량 폰을 조종합니다. 이동 입력을 캐릭터 블루프린트에만 두었다면 어떤 일이 생길 수 있을까요?

해설 보기

차량에 타는 순간 컨트롤러는 차량 폰을 빙의하므로, 캐릭터 블루프린트에 둔 입력 처리는 더 이상 쓰이지 않습니다. 차량에서 쓸 입력을 차량 폰에 따로 만들어야 하고, 캐릭터와 차량 모두에 필요한 입력, 예를 들어 메뉴 열기 같은 것은 두 곳에 중복될 수 있습니다.

공식 문서의 기준처럼 실행 중에 조종할 대상이 바뀐다면, 폰이 바뀌어도 남는 플레이어 컨트롤러가 공통 입력을 받고 현재 폰에 명령을 내리는 구조가 알맞습니다. 걷기나 운전처럼 폰마다 다른 동작은 각 폰이 맡게 나눌 수 있습니다.

입력을 컨트롤러와 폰 가운데 어디에 둘지에 대한 기준은 언리얼 엔진 공식 문서의 플레이어 컨트롤러에서 확인할 수 있습니다.

다음 글 블루프린트에서의 리플리케이션에서는 서버와 클라이언트가 변수와 이벤트를 주고받는 리플리케이션을 블루프린트에서 설정하는 방법을 살펴봅니다.