1. 기본 개요 : 3인칭 기반의 FPS 보스 레이드

2. 전투로직

3. 게임 루프

1. 프로그램 실행

• 세이브 데이터 로드(클리어 기록)
• 메인 메뉴 UI(인게임에 입장하는 UI)

2. 인게임 레벨 초기화 GameMode 실행

• 플레이어와 보스 스폰
• HP, 탄약 등 HUD 가져오기
• 보스 AI 가동

3. 인게임 메인 루프 플레이어 액션

• 이동, 달리기, 구르기
• 사격 → 보스 피격 판정 및 데미지
• 특수 기술 → 그에 대한 효과(보스에게 데미지 등)
• 재장전 및 탄약·체력 관리 보스 AI 루프
• 플레이어 감지 및 추적
• 거리 및 체력 등의 조건에 따라 패턴 발동
• 피격 애니메이션 및 체력 관리 틱(Tick)
• 경과 시간 업데이트
• 히트 마커나 데미지 텍스트 등의 연출

4. 게임 종료 및 저장 단계 승리 조건: 보스 체력 0

• 게임 정지 → 클리어 기록 출력 및 저장
• 클리어 UI 출력(점수) 패배 조건: 플레이어 체력 0
• 게임 정지 및 게임오버 UI 호출
• 재시작/메인 메뉴 이동 UI

4. UI 레퍼런스 분석 및 기본 배치

• UI 레퍼런스 분석
• 기본 배치

5. 사용 에셋 목록

6. 레퍼런스 게임의 몬스터 기믹 분석 후 사용 기믹 확정

• 게임 분석
• 보스 확정

7. PC 구체화 및 스킬 확정

일단 BlueprintReadWrite로 다시 바꿔주죠... 빌드 후 클래스를 검색하면 이렇게 잘 들어온 걸 확인할 수 있습니다. 야호. 이렇게 BaseItem을 상속받은 CoinItem을 확인 할 수 있습니다. 그리고 다시 확인해보면 코인 아이템이 잘 생성되었습니다. 작업하던 도중 원인을 추적하기 어려운 오류가 발생할 때가 가끔 있었습니다.

이런식으로 알 수 없는 위치에 붉은 줄이 표시되고, 빌드 또한 되지 않았는데요. 이럴 때 의심해 볼 수 있는 요인이 몇 가지 있습니다.

① IntelliSense가 UE include 경로를 잃어버린 경우 ② ItemInterface.generated.h가 아직 생성되지 않은 경우 ③ .generated.h의 위치 문제 ④ 프로젝트 파일이 꼬인 경우

입니다. 우선 1번부터 시도해보죠. 해결 방법은 다음과 같습니다.

① Unreal Editor와 Visual Studio를 모두 종료합니다. ② 프로젝트 폴더에서 프로젝트이름.uproject 파일을 찾아 우클릭합니다. ③ Generate Visual Studio project files를 선택합니다. ④ 생성이 끝나면 .sln 파일을 다시 열어 Ctrl + Shift + B로 빌드합니다.

이러고 확인해보니 이상한 붉은 줄이 모두 없어졌습니다. 프로젝트 메타정보를 재생성해서 Visual Studio와 UE 프로젝트를 다시 동기화하는 작업이라고 하는군요...

+팀원분들과 면담을 마쳤습니다. 기존에 알던 사실 외에도 조율할 부분을 가볍게 얘기해 보았습니다. 잘 해볼 수 있을 것 같습니다. 파이팅~!

현재 TA 채용에서 반복해서 나오는 역할은 아트와 프로그래밍 사이의 연결, 제작 환경/툴 개선, 시각 효과 구현, 최적화와 프로파일링, 기술 문서화입니다. 실제 최근 공고에서도 UE5, C++/Python, 아트 제작 환경 구축, 툴·자동화, 머티리얼/라이팅, 성능 분석과 최적화가 반복됩니다.

따라서 「멀티 웨이브 게임 제작」이 아니라 「디자이너 친화적인 Data-Driven Wave & Visual Feedback System」로 제작해보는 건 어떨까 싶습니다.

우선 들어갈 필수 구현 항목을 정리해봅시다.

[필수 구현 항목]

1. 멀티 웨이브 및 레벨 시스템 구축

• 구현했던 SpawnVolume, 충돌(Overlap), GameState/GameMode 등을 재사용 합니다.
• 한 레벨 안에서 레벨 전환 없이 1~3단계의 웨이브 (게임 진행)을 진행합니다.
• 각 웨이브마다 제한 시간, 아이템 스폰 횟수의 베리에이션을 설정합니다.

• 전체 게임 진행: 3번의 레벨이 전환이 됩니다.
  • 각 레벨 안에서 최소 3단계 이상의 웨이브를 만들어봅니다.
  • 각 웨이브는 난이도 조정을 위해, 시간과 아이템의 갯수가 달라집니다.
• 웨이브 시작시 UE_LOG나 GEngine->AddOnScreenDebugMessage 등의 방법으로 “Wave 1 시작!” 알림을 출력합니다.

2. UI/UX 리뉴얼 및 기능 연결

UI 분석 및 요구사항 정리 ** - WBP_HUD, WBP_MainMenu , HP 위젯을 **기능과 디자인 관점에서 요약/분석합니다. - 분석한 정보를 바탕으로, 기획안에 개선점을 녹여냅니다. - ex) “HUD에 표시하고 싶은 정보가 무엇인지”, - ex2) “메인 메뉴/종료 메뉴에 필요한 버튼 및 레이아웃은 어떠한지”

** HUD 및 Menu UI 재설계**

• HUD 위젯 재디자인
  • 캔버스 구조 (CanvasPanel, VerticalBox 등)를 적절히 배치합니다.
  • 점수, 타이머, 레벨 등 정보를 보기 좋게 표시합니다.
  • 텍스트 스타일 (폰트, 색상, 테두리 등)과 아이콘, 게이지 바 등을 활용해 디자인 완성도를 높입니다.
    • 메뉴 UI 재디자인
  • 게임 시작, 재시작, 종료 버튼을 재배치하고, 배경 이미지·반투명 블러 등 시각적 요소를 개선합니다.
  • 버튼 hover, clicked 등 인터랙션 효과 (색/이미지 변화)를 적용합니다. (UButton Style)

• HUD에 표시할 정보를 표시합니다.
  • 점수, 시간, 체력
  • 전부 한 화면에서 볼 수 있도록 배치합니다.
  • 아래의 UI를 재설계 합니다.
  • 메인 메뉴 (시작, 종료)
  • 게임 오버 메뉴 (재시작, 메인 메뉴로 돌아가기)
  • 디자인을 업그레이드 합니다.
  • 폰트, 색상, 배경 등을 적절히 조정하여 일관된 디자인을 적용합니다.
  • 각자 원하는 스타일로, 멋지고 직관적인 UI를 구현합니다.
  • 기능 구현
  • ****레벨 이동 또는 게임 종료 등 각 버튼 클릭 시 C++ / 블루프린트 함수를 호출합니다.

할 일이 많군요. 일단 할 수 있는 일을 최대한 해봅시다. 필수 기능 구현을 변주하면 될 일입니다.

이정도면 마감 내에 할 수 있지 않을까 기대해봅니다.

아자아자 파이팅.

언리얼 C++ 코드를 읽다 보면 ->, ., ::가 굉장히 자주 등장합니다.

처음에는 셋 다 대충 "~의" 정도로 읽혀서 헷갈리기 쉬운데, 실제로는 접근하는 대상이 다릅니다.

1. -> : 포인터가 가리키는 객체의

->는 포인터를 통해 그 객체의 변수나 함수에 접근할 때 사용합니다.

PlayerController->MoveAction

말로 풀어 읽으면 다음과 같습니다.

PlayerController 포인터가 가리키는 객체의 MoveAction

즉, PlayerController가 객체 그 자체가 아니라 객체를 가리키는 포인터이기 때문에 .이 아니라 ->를 사용합니다.

AJupiterPlayerController* PlayerController;

여기서 *가 붙어 있으므로 PlayerController는 AJupiterPlayerController 객체를 가리킬 수 있는 포인터 변수입니다.

따라서 다음과 같이 사용합니다.

PlayerController->MoveAction

2. . : 객체 자체의

.은 포인터가 아니라 객체 자체를 가지고 있을 때 그 객체의 멤버에 접근하는 연산자입니다.

예를 들어 다음과 같은 객체가 있다고 가정해보겠습니다.

AJupiterPlayerController PlayerController;

이 경우 PlayerController는 포인터가 아니라 객체 자체이므로 다음과 같이 접근합니다.

PlayerController.MoveAction

즉,

PlayerController.MoveAction

은

PlayerController 객체의 MoveAction

이라고 읽을 수 있습니다.

반면,

PlayerController->MoveAction

은

PlayerController 포인터가 가리키는 객체의 MoveAction

이라고 읽을 수 있습니다.

한 줄 정리

객체.멤버
포인터->멤버

이렇게 기억하면 비교적 간단합니다.

3. :: : 특정 클래스나 범위에 속한 것

::는 범위 지정 연산자(Scope Resolution Operator)입니다.

쉽게 말하면,

":: 앞에 있는 범위에 속한 것을 사용하겠다."

라고 읽을 수 있습니다.

예를 들어 다음 코드를 보겠습니다.

AJupiterCharacter::Move

이는

AJupiterCharacter 클래스에 속한 Move

라는 뜻입니다.

함수를 클래스 밖에서 정의할 때도 사용합니다.

void AJupiterCharacter::Move()
{
}

이는

지금 정의하고 있는 Move()는 AJupiterCharacter 클래스의 Move()다.

라는 의미입니다.

따라서 세 연산자를 아주 단순화하면 다음처럼 구분할 수 있습니다.

Object.Member             // 객체의 Member
Pointer->Member           // 포인터가 가리키는 객체의 Member
ClassName::Member         // 해당 클래스/범위에 속한 Member

실제 코드 읽어보기

이번에는 Enhanced Input을 연결하는 코드를 한 줄씩 읽어보겠습니다.

void AJupiterCharacter::SetupPlayerInputComponent(
    UInputComponent* PlayerInputComponent)

먼저 AJupiterCharacter::SetupPlayerInputComponent는

AJupiterCharacter 클래스에 속한 SetupPlayerInputComponent 함수를 정의한다.

라고 읽을 수 있습니다.

그리고

UInputComponent* PlayerInputComponent

는 함수의 매개변수입니다.

UInputComponent 객체를 가리킬 수 있는 포인터를 PlayerInputComponent라는 이름으로 받아옵니다.

따라서 전체적으로는 대략 다음과 같이 읽을 수 있습니다.

AJupiterCharacter의 SetupPlayerInputComponent 함수를 정의한다. 이 함수는 UInputComponent를 가리키는 포인터를 PlayerInputComponent라는 이름으로 전달받는다.

부모 클래스의 함수 호출

Super::SetupPlayerInputComponent(PlayerInputComponent);

여기서 Super는 언리얼에서 부모 클래스를 가리키는 별칭입니다.

따라서 다음과 같이 이해할 수 있습니다.

부모 클래스의 SetupPlayerInputComponent()를 먼저 실행한다.

AJupiterCharacter가 ACharacter를 상속받았다면, 여기서 Super는 부모인 ACharacter를 의미하게 됩니다.

Enhanced Input으로 캐스팅

if (UEnhancedInputComponent* EnhancedInput =
    Cast<UEnhancedInputComponent>(PlayerInputComponent))

캐스팅(Casting)은 여기서는 쉽게 말해,

"이 객체를 UEnhancedInputComponent로 다룰 수 있는지 확인하고, 가능하다면 그 타입의 포인터를 얻는다."

라고 이해할 수 있습니다.

Cast<UEnhancedInputComponent>(PlayerInputComponent)가 성공하면 결과로 유효한 포인터가 반환되고, 그것을

UEnhancedInputComponent* EnhancedInput

에 저장합니다.

실패하면 nullptr가 반환되므로 if의 내부가 실행되지 않습니다.

즉,

PlayerInputComponent가 UEnhancedInputComponent로 캐스팅 가능한지 확인한다. 성공하면 그 결과를 EnhancedInput이라는 지역 포인터 변수에 담고 아래 코드를 실행한다.

라고 읽을 수 있습니다.

PlayerController 캐스팅

if (AJupiterPlayerController* PlayerController =
    Cast<AJupiterPlayerController>(GetController()))

이것도 같은 구조입니다.

GetController()로 현재 Pawn/Character를 제어하고 있는 Controller를 가져온 뒤, 그것이 AJupiterPlayerController로 다룰 수 있는지 확인합니다.

성공하면 그 포인터를

AJupiterPlayerController* PlayerController

에 저장합니다.

따라서 다음처럼 읽을 수 있습니다.

GetController()가 반환한 Controller를 AJupiterPlayerController로 캐스팅한다. 성공하면 그 포인터를 PlayerController라는 지역 변수에 저장하고 if문 내부를 실행한다.

실패하면 nullptr이 반환되므로 내부 코드가 실행되지 않습니다.

PlayerController->MoveAction

if (PlayerController->MoveAction)

앞에서 PlayerController를 다음과 같이 선언했습니다.

AJupiterPlayerController* PlayerController

즉, 포인터입니다.

따라서 .이 아니라 ->를 사용합니다.

PlayerController->MoveAction

은

PlayerController 포인터가 가리키는 객체의 MoveAction

이라고 읽습니다.

그리고 if에 넣었으므로 여기서는 MoveAction이 유효한지 확인하는 역할을 합니다.

MoveAction이 실제로 설정되어 있다면 아래 코드를 실행한다.

BindAction() 읽어보기

마지막으로 가장 복잡해 보이는 부분입니다.

EnhancedInput->BindAction(
    PlayerController->MoveAction,
    ETriggerEvent::Triggered,
    this,
    &AJupiterCharacter::Move
);

한꺼번에 보면 복잡하지만 하나씩 분리하면 생각보다 단순합니다.

EnhancedInput->BindAction

EnhancedInput->BindAction(...)

EnhancedInput은 포인터이므로 ->를 사용합니다.

EnhancedInput 포인터가 가리키는 객체의 BindAction() 함수를 실행한다.

PlayerController->MoveAction

PlayerController->MoveAction

PlayerController 포인터가 가리키는 객체의 MoveAction

즉, 어떤 Input Action을 연결할 것인지 전달합니다.

ETriggerEvent::Triggered

ETriggerEvent::Triggered

여기서는 ::가 사용되었습니다.

ETriggerEvent라는 범위에 정의되어 있는 Triggered

즉, 해당 Input Action이 Triggered 상태일 때 함수를 실행하도록 지정합니다.

this

this

this는 현재 객체 자신을 가리키는 포인터입니다.

현재 코드가 AJupiterCharacter 객체에서 실행되고 있으므로,

"바로 이 AJupiterCharacter 객체에서"

정도로 우선 이해할 수 있습니다.

&AJupiterCharacter::Move

&AJupiterCharacter::Move

여기서 ::가 다시 등장합니다.

AJupiterCharacter::Move

는

AJupiterCharacter 클래스에 속한 Move 함수

라는 의미입니다.

앞의 &까지 포함하면 해당 멤버 함수를 BindAction()에 연결할 함수로 전달하는 형태가 됩니다.

즉, 여기서는

실제로 실행할 함수는 AJupiterCharacter의 Move 함수다.

정도로 이해하면 됩니다.

전체 코드를 문장으로 읽어보기

if (PlayerController->MoveAction)
{
    EnhancedInput->BindAction(
        PlayerController->MoveAction,
        ETriggerEvent::Triggered,
        this,
        &AJupiterCharacter::Move
    );
}

이를 자연어로 바꾸면 다음과 같습니다.

PlayerController가 가지고 있는 MoveAction이 유효하다면, 그 액션을 Enhanced Input에 연결한다. MoveAction이 Triggered될 때 현재 AJupiterCharacter 객체의 Move 함수가 실행되도록 바인딩한다.

결국 이 코드의 핵심은 입력 액션과 실제 C++ 함수를 연결하는 것입니다.

최종 정리

코드를 읽을 때 세 연산자를 전부 똑같은 "~의"라고 생각하면 헷갈리기 쉽습니다.

다음처럼 구분해서 읽는 편이 좋습니다.

PlayerController.MoveAction
// PlayerController 객체의 MoveAction

PlayerController->MoveAction
// PlayerController 포인터가 가리키는 객체의 MoveAction

AJupiterCharacter::Move
// AJupiterCharacter 클래스에 속한 Move

따라서 기억할 핵심은 다음 세 가지입니다.

특히 언리얼 C++에서는 객체를 포인터 형태로 다루는 경우가 많기 때문에 ->를 매우 자주 만나게 됩니다.

처음에는 기호 자체를 외우기보다는 코드를 볼 때마다 "지금 왼쪽에 있는 것이 객체인가, 포인터인가, 아니면 클래스/범위 이름인가?"를 확인하는 방식으로 읽는 것이 이해하기 쉽습니다.

헷갈리는 개념 정리

1. UPROPERTY()에서 사용하는 지정자의 범위

UPROPERTY()에는 여러 지정자가 들어갈 수 있는데, 처음에는 VisibleAnywhere, BlueprintReadOnly, EditAnywhere 등이 비슷해 보여 꽤 헷갈렸습니다.

우선 크게 나누면 다음과 같습니다.

에디터에서의 표시 및 수정 범위

• VisibleAnywhere
• VisibleDefaultsOnly
• VisibleInstanceOnly
• EditAnywhere
• EditDefaultsOnly
• EditInstanceOnly

블루프린트에서의 접근 권한

• BlueprintReadOnly
• BlueprintReadWrite

여기서 중요한 점은 에디터에서의 접근 권한과 블루프린트에서의 접근 권한은 서로 다른 문제라는 것입니다.

예를 들어 다음과 같이 선언할 수 있습니다.

UPROPERTY(VisibleAnywhere, BlueprintReadOnly)
USpringArmComponent* SpringArmComp;

VisibleAnywhere는 해당 프로퍼티를 에디터에서 볼 수 있지만 직접 다른 값으로 교체할 수 없도록 합니다.

BlueprintReadOnly는 블루프린트에서 해당 프로퍼티를 읽을 수는 있지만 직접 새로운 값을 대입할 수 없도록 합니다.

그렇다면 컴포넌트 내부 속성도 수정할 수 없을까요?

이 부분이 특히 헷갈렸습니다.

결론부터 말하면 컴포넌트 자체를 가리키는 참조를 변경하는 것과 그 컴포넌트가 가지고 있는 내부 속성을 변경하는 것은 별개의 문제입니다.

예를 들어 SpringArmComp를 VisibleAnywhere로 선언했다면 SpringArmComp라는 변수에 다른 컴포넌트를 마음대로 집어넣는 것은 제한됩니다.

하지만 SpringArmComp 안에 있는 Target Arm Length, 회전 관련 설정 등 컴포넌트 자체가 제공하는 편집 가능한 속성은 Details 패널에서 변경할 수 있습니다.

즉, 대략 다음과 같이 이해할 수 있을 것 같습니다.

VisibleAnywhere "이 컴포넌트가 존재한다는 것은 보여드리지만, 컴포넌트 자체를 다른 것으로 갈아끼우지는 마세요."

BlueprintReadOnly "블루프린트에서 이 변수를 가져다 읽을 수는 있지만, 변수 자체에 새로운 값을 직접 대입하지는 마세요."

아직은 어디까지 C++에서 결정하고 어디까지 에디터에서 조절하도록 만드는 것이 효율적인가?에 대한 감각이 완전히 잡히지는 않았습니다.

현재는 대략 다음 정도로 이해하고 있습니다.

• 게임의 구조나 반드시 지켜져야 하는 규칙 → C++
• 이동 속도, 카메라 거리, 이펙트 크기처럼 자주 조정할 값 → 에디터
• 기획자가 직접 조정할 가능성이 높은 값 → EditAnywhere, EditDefaultsOnly 등을 이용해 노출
• 외부에서 함부로 변경하면 안 되는 컴포넌트 → VisibleAnywhere 등으로 제한

결국 C++과 에디터 중 하나만 사용하는 것이 아니라, 변경되어도 되는 값과 변경되면 안 되는 구조를 구분하는 것이 중요해 보입니다.

서바이벌 아케이드 게임 구현하기

이번 프로젝트에서는 기본적인 캐릭터 조작부터 아이템, 웨이브, HUD, 이펙트까지 단계적으로 구현해 볼 예정입니다.

할 일 목록

1. 캐릭터 구현

2. 캐릭터 입력 매핑 구현

3. 캐릭터 기본 동작 구현

   • WASD 이동
   • 점프
   • 스프린트
   • 카메라 회전

4. 캐릭터 애니메이션 적용

   • Idle
   • Walk
   • Jump
   • Sprint

5. 아이템 상호작용 구현

   • 범위 내에 있을 경우 체력 감소
   • 획득 시 점수 증가
   • 획득 시 체력 증가

6. 아이템 랜덤 스폰 및 레벨별 아이템 개수 설정

7. 캐릭터 데미지 및 아이템 점수 관리 시스템 구현

8. 웨이브 시스템을 통한 게임 흐름 제어

9. HUD에 실시간 정보 반영

10. 게임 흐름에 맞춘 메뉴 UI 구현

11. UI 애니메이션 효과 및 3D 위젯 UI 구현

12. 파티클 효과 적용

    • 지뢰 폭발
    • 아이템 습득

13. 사운드 효과 적용

    • 지뢰 폭발
    • 아이템 습득
    • 발걸음

14. 프로젝트 패키징 및 배포

1. GameMode - 게임의 규칙을 관리하는 역할

GameMode는 게임 전체의 규칙과 기본 구성을 결정하는 클래스입니다.

현재 공부한 내용을 기준으로 보면 다음과 같은 클래스들을 지정할 수 있습니다.

1. Default Pawn / Character

   • 플레이어가 기본적으로 조종하게 될 Pawn 또는 Character 클래스를 지정합니다.

2. PlayerController

   • 플레이어가 사용할 PlayerController 클래스를 지정합니다.
   • Controller는 Pawn 또는 Character를 Possess하여 조종할 수 있습니다.

3. 게임 규칙

   • 게임 시작, 종료, 승패 조건 등의 게임 로직을 관리할 수 있습니다.

4. GameState

   • 현재 게임 전체에서 공유해야 하는 상태를 관리할 때 사용합니다.

5. PlayerState

   • 각 플레이어별로 관리해야 하는 상태를 저장할 때 사용합니다.

GameModeBase와 GameMode

GameMode 클래스를 생성할 때 보면 GameModeBase와 GameMode라는 두 종류가 있습니다.

GameModeBase는 비교적 단순화된 기본 GameMode이고, GameMode는 여기에 Match State와 같은 경기 진행 상태 관리 기능이 추가된 클래스입니다.

따라서 단순한 게임에서는 GameModeBase만으로도 충분할 수 있고, 경기 시작·진행·종료와 같은 명확한 매치 흐름이 필요한 게임에서는 GameMode가 유용합니다.

GameMode는 프로젝트 설정에서 기본값을 지정할 수도 있고, 각 레벨의 World Settings에서 별도로 지정할 수도 있습니다.

이 경우 레벨의 World Settings에서 GameMode를 따로 지정했다면 해당 설정이 우선 적용됩니다.

GameMode에서는 대표적으로 다음 클래스들을 지정할 수 있습니다.

• Default Pawn Class
• Player Controller Class
• Player State Class
• Game State Class
• HUD Class
• Spectator Class

즉, GameMode는

"이 게임 또는 이 레벨에서는 어떤 규칙과 기본 클래스들을 사용할 것인가?"

를 결정하는 역할에 가깝다고 이해했습니다.

Pawn과 Character의 차이

Pawn과 Character의 차이도 처음에는 상당히 헷갈렸습니다.

Character는 Pawn을 상속받은 클래스입니다.

특히 CharacterMovementComponent, Capsule Collision 등 걷고 뛰는 캐릭터를 구현하기 편리한 기능들이 기본으로 준비되어 있습니다.

따라서 사람이나 몬스터처럼 지면 위를 걸어다니는 캐릭터를 만들 때 상당히 편리합니다.

반면 Pawn은 Character보다 더 기본적인 형태입니다.

이동 방법이 미리 강하게 정해져 있지 않기 때문에 자동차, 비행기, 드론, 특수한 이동체처럼 직접 이동 방식을 설계하고 싶은 경우 더 자유롭게 사용할 수 있습니다.

다만,

"사람이 아니면 무조건 Pawn을 사용한다."

라고 이해하는 것은 정확하지 않습니다.

인간이 아닌 몬스터라고 하더라도 Character의 이동 방식이 적합하다면 Character를 사용할 수 있습니다.

반대로 인간형 캐릭터라고 하더라도 매우 특수한 움직임이 필요하다면 Pawn을 사용할 수도 있습니다.

결국 기준은 외형보다는

"Character가 기본으로 제공하는 이동 시스템을 활용할 것인가?"

에 더 가깝습니다.

전방 선언(Forward Declaration)

코드를 보다 보면 다음과 같은 형태가 자주 등장합니다.

class USpringArmComponent;

처음에는 #include도 아닌데 갑자기 클래스를 선언해서 무엇을 하는 것인지 알기 어려웠습니다.

이것을 전방 선언(Forward Declaration)이라고 합니다.

쉽게 말하면 컴파일러에게

"USpringArmComponent라는 클래스가 어딘가에 존재합니다. 자세한 내용은 나중에 알려드리겠습니다."

라고 미리 알려주는 것입니다.

헤더 파일에서 클래스의 포인터나 참조만 필요하다면 굳이 해당 클래스의 헤더 전체를 #include하지 않고 전방 선언만 사용할 수 있습니다.

예를 들어,

class USpringArmComponent;

USpringArmComponent* SpringArmComp;

처럼 사용할 수 있습니다.

그리고 실제로 USpringArmComponent의 함수나 내부 기능을 사용하는 .cpp 파일에서는 필요한 헤더를 #include합니다.

이렇게 하면 헤더끼리 불필요하게 많은 파일을 불러오는 것을 줄일 수 있습니다.

2. PlayerController

PlayerController는 플레이어와 게임 속 Pawn을 연결하는 Controller입니다.

이번 프로젝트에서는 PlayerController를 중심으로 입력을 처리하도록 구성했습니다.

PlayerController에서 담당할 수 있는 대표적인 기능은 다음과 같습니다.

1. 플레이어 입력 처리
2. 카메라 제어 로직
3. UI와의 상호작용
4. Pawn / Character에 대한 Possess, UnPossess

여기서 한 가지 주의할 점은

"언리얼에서는 모든 입력을 반드시 PlayerController에서 처리해야 한다."

는 의미는 아닙니다.

Character나 Pawn에서도 입력을 바인딩할 수 있습니다.

프로젝트 구조에 따라서 PlayerController에서 입력을 관리할 수도 있고, Character 또는 Pawn에서 실제 움직임과 관련된 입력을 처리할 수도 있습니다.

이번에는 플레이어의 입력을 PlayerController 쪽에서 분리해서 관리하는 구조를 공부했습니다.

Enhanced Input System

Enhanced Input은 기존 입력 시스템보다 Input Action, Mapping Context, Trigger, Modifier 등을 이용해 입력을 더 구조적으로 관리할 수 있게 해주는 시스템입니다.

UE5에서 일반적으로 사용하는 입력 시스템이기도 합니다.

Input Mapping Context (IMC)

Input Mapping Context, 줄여서 IMC는 어떤 입력 설정들을 현재 사용할 것인지 묶어 놓은 컨텍스트입니다.

처음에는 스위치와 비슷하다고 이해했습니다.

예를 들어 다음과 같이 나눌 수 있습니다.

IMC_Human
 ├─ IA_Move
 ├─ IA_Look
 └─ IA_Jump

IMC_Car
 ├─ IA_Accelerate
 ├─ IA_Brake
 └─ IA_Steer

사람을 조종할 때는 IMC_Human을 사용하고, 자동차에 탑승하면 IMC_Car를 적용하는 식으로 입력 구성을 전환할 수 있습니다.

따라서 IMC는 단순히 키 하나를 지정하는 것이 아니라,

여러 Input Action과 실제 키 입력의 대응 관계를 묶어서 관리하는 설정

이라고 보는 편이 더 정확합니다.

Input Action (IA)

Input Action은 특정한 행동을 추상화한 것입니다.

예를 들어

점프 → IA_Jump
카메라 회전 → IA_Look
이동 → IA_Move

와 같이 만들 수 있습니다.

여기서 중요한 점은 IA_Move 자체가 W키를 의미하는 것은 아니라는 것입니다.

IA_Move는 단순히 "이동이라는 행동"을 의미하고,

실제로 어떤 키가 이동을 발생시키는지는 IMC에서 연결합니다.

이 구조 덕분에 같은 IA_Move를 사용하면서도 키보드, 게임패드 등 서로 다른 입력 장치를 연결할 수 있습니다.

이번 캐릭터에서 필요한 행동

이번 캐릭터에는 다음 입력을 구현합니다.

1. WASD 이동
2. 마우스 회전
3. 점프
4. 스프린트

Input Action을 생성한 뒤 각각의 행동에 필요한 Value Type을 지정합니다.

Value Type

Input Action에서 특히 중요한 설정 중 하나가 Value Type입니다.

해당 Input Action이 실행될 때 어떤 형태의 값을 전달할 것인지를 결정합니다.

Bool

참 또는 거짓을 전달합니다.

단순히 눌렸는지 아닌지를 확인할 때 사용하기 좋습니다.

예:

• 점프
• 공격
• 상호작용

Axis1D

하나의 축 값을 전달합니다.

예를 들어 -1 ~ 1 범위의 값처럼 한 방향의 정도를 표현할 수 있습니다.

예:

• 게임패드 트리거
• 전진 / 후진
• 가속 페달

Axis2D

X, Y 두 개의 축 값을 동시에 전달합니다.

예:

• WASD 이동
• 마우스 이동
• 게임패드 스틱

예를 들어 캐릭터 이동이라면 다음처럼 생각할 수 있습니다.

X = 좌우 이동
Y = 앞뒤 이동

Axis3D

X, Y, Z 세 개의 축 값을 사용합니다.

3차원 방향 입력이 필요한 경우 사용할 수 있습니다.

예:

• 비행체의 3축 입력
• 특수한 3차원 이동 시스템

Trigger

Trigger는

"입력이 어느 조건을 만족했을 때 Input Action을 발동시킬 것인가?"

를 결정합니다.

예를 들어 단순히 키를 누르는 것뿐만 아니라 일정 시간 누르고 있거나, 키를 떼는 순간 등의 조건을 만들 수 있습니다.

Pressed

키가 눌리는 순간을 감지합니다.

예:

스페이스바를 누르는 순간 → 점프

Hold

키를 일정 시간 이상 누르고 있는 경우 작동합니다.

예:

상호작용 키를 1초간 누름 → 문 열기

Released

누르고 있던 키를 놓는 순간 작동합니다.

예:

활시위를 당기고 있다가 버튼을 놓음 → 화살 발사

이외에도 Tap, Chorded Action 등 여러 종류의 Trigger를 조합할 수 있습니다.

Modifier

처음에는 Modifier가 Trigger보다 훨씬 이해하기 어려웠습니다.

정리해 보니 Trigger와 Modifier의 차이는 다음과 같습니다.

Trigger "언제 실행할 것인가?"

Modifier "들어온 입력 값을 어떤 값으로 바꿀 것인가?"

예를 들어 마우스를 오른쪽으로 움직였을 때 1이라는 값이 들어왔다고 생각해 보겠습니다.

Modifier를 사용하면 이 1이라는 입력값을 실제 게임 로직으로 보내기 전에 가공할 수 있습니다.

Scalar

입력 값에 특정 배율을 곱합니다.

원래 입력 : 1
Scalar × 2
결과 : 2

마우스 감도를 높이는 것과 비슷하게 사용할 수 있습니다.

Negate

입력값의 방향을 반대로 바꿉니다.

1 → -1

카메라 축을 반전하거나 WASD에서 왼쪽/뒤쪽 방향 값을 만드는 데 사용할 수 있습니다.

Dead Zone

일정 크기보다 작은 입력값을 무시합니다.

게임패드의 아날로그 스틱은 손을 놓고 있어도 아주 작은 입력값이 발생할 수 있습니다.

예를 들어,

0.01
0.02
0.03

같은 작은 입력을 무시하도록 만들어 캐릭터가 가만히 있는데 조금씩 움직이는 현상을 방지할 수 있습니다.

즉, Modifier는

입력 장치에서 들어온 값을 게임에서 사용하기 좋은 형태로 가공하는 과정

이라고 이해하면 조금 더 와닿습니다.

Input Mapping Context에서 키 매핑하기

Swizzle Input Axis Values란?

Swizzle Input Axis Values는 입력 값의 축 순서를 바꾸는 Modifier입니다.

처음에는 이것이 상당히 이해하기 어려웠습니다.

WASD를 예로 들어 보겠습니다.

키보드의 W키 하나는 기본적으로 하나의 값만 전달하는 1차원 입력입니다.

하지만 IA_Move를 Axis2D로 만들었다면 다음과 같은 값이 필요합니다.

X = 좌우
Y = 앞뒤

여기서 D키의 입력값 1은 X축에 그대로 넣으면 됩니다.

D → X = +1

A키는 반대 방향이므로 Negate를 사용합니다.

A → X = -1

문제는 W와 S입니다.

W를 눌렀을 때 들어오는 1차원 입력도 기본적으로 X 위치에 들어오기 때문에, 이것을 Y축 값으로 옮겨야 합니다.

이때 사용하는 것이 Swizzle Input Axis Values입니다.

W
1차원 입력 +1
↓
Swizzle
↓
Y = +1

S는 여기에 Negate까지 적용합니다.

S
1차원 입력 +1
↓
Swizzle
↓
Y = +1
↓
Negate
↓
Y = -1

따라서 WASD를 하나의 Axis2D Input Action으로 묶으면 대략 다음과 같이 정리할 수 있습니다.

W → Swizzle → Y +1
S → Swizzle + Negate → Y -1
A → Negate → X -1
D → 그대로 → X +1

처음에는 Swizzle이라는 이름 때문에 굉장히 복잡한 기능처럼 느껴졌지만,

"지금 X 자리에 들어온 값을 Y 자리로 옮겨 주세요."

정도로 이해하면 훨씬 간단합니다.

Look 입력에서도 프로젝트에서 원하는 마우스 조작 방향에 따라 특정 축에 Negate를 적용하여 상하 또는 좌우 방향을 반전시킬 수 있습니다.

중요한 것은 카메라 입력이라서 반드시 Y축을 반전해야 하는 것은 아니며, 원하는 조작 방향과 현재 입력값의 방향에 따라 결정해야 한다는 점입니다.

Trigger와 Modifier 다시 정리

둘이 자꾸 헷갈려서 한 문장으로 정리했습니다.

Modifier → 입력 값을 가공합니다.
Trigger  → 그 입력을 언제 실행할지 판단합니다.

예를 들어,

마우스 Y 입력
↓
Negate Modifier
↓
방향 반전
↓
Trigger 조건 확인
↓
IA_Look 실행

과 같은 흐름으로 이해할 수 있습니다.

Enhanced Input의 구조를 전체적으로 보면 다음과 같습니다.

키보드 / 마우스 / 게임패드
        ↓
Input Mapping Context
        ↓
Modifier
        ↓
Trigger
        ↓
Input Action
        ↓
C++ / Blueprint 로직

정확한 내부 처리 과정을 모두 표현한 그림은 아니지만, 각 요소가 어떤 역할을 담당하는지 구분하기 위한 학습용으로는 이렇게 기억해 두려고 합니다.

참고 자료

https://shjz.tistory.com/32

덤: 다중 커서 사용법

코드를 작성하다가 다중 커서를 사용하는 방법도 알게 되었습니다.

Alt + Ctrl + 클릭

여러 위치를 동시에 수정할 때 꽤 편리하게 사용할 수 있습니다.

막상 설명하려고 하니 UCLASS, 컴포넌트 생성처럼 어느 정도 이해하고 있던 부분도 있었지만, Enhanced Input, Cast, AddMappingContext() 쪽은 코드를 따라 작성했을 뿐 제대로 설명하지 못하는 부분이 많았습니다.

그래서 이번 글에서는 다음 코드를 기준으로 “이 한 줄이 왜 필요한가?”를 다시 정리해보겠습니다.

1. UCLASS()와 GENERATED_BODY()

UCLASS()
class SPARTAPROJECT_API ASpartaCharacter : public ACharacter
{
    GENERATED_BODY()
};

UCLASS()

UCLASS()

일반 C++ 클래스와 달리, 언리얼 엔진은 클래스에 대한 여러 정보를 엔진 차원에서 관리합니다.

UCLASS()는 이 클래스를 언리얼의 객체 및 리플렉션 시스템이 인식할 수 있는 클래스로 선언하는 매크로입니다.

초보자 관점에서는 우선 다음 정도로 기억하면 이해하기 쉽습니다.

“이 클래스는 그냥 C++ 클래스가 아니라 언리얼 엔진도 알아야 하는 클래스입니다.”

SPARTAPROJECT_API

class SPARTAPROJECT_API ASpartaCharacter

SPARTAPROJECT_API는 이 클래스를 프로젝트의 다른 모듈에서도 사용할 수 있도록 심볼을 노출하는 매크로입니다.

현재 단계에서는 DLL Export/Import 구조까지 깊게 들어가기보다는,

“이 클래스를 다른 모듈에서도 사용할 수 있도록 열어주는 표시입니다.”

정도로 이해했습니다.

: public ACharacter

ASpartaCharacter : public ACharacter

ASpartaCharacter가 언리얼의 ACharacter 클래스를 상속받는다는 의미입니다.

즉,

ACharacter가 원래 가지고 있던 기능을 물려받아 ASpartaCharacter라는 새로운 캐릭터 클래스를 만듭니다.

라고 이해할 수 있습니다.

GENERATED_BODY()

GENERATED_BODY()

처음에는 "UCLASS()와 한 쌍인 매크로" 정도로 외웠습니다.

방향 자체는 크게 틀리지 않지만, 조금 더 정확하게 보면 GENERATED_BODY()는 언리얼의 클래스 시스템이 동작하는 데 필요한 코드를 클래스 내부에 생성해주는 역할을 합니다.

따라서 저는 다음과 같이 기억하기로 했습니다.

UCLASS() → “언리얼 엔진에서 이 클래스를 관리해주세요.”

GENERATED_BODY() → “그러면 관리에 필요한 내부 코드도 여기에 넣어주세요.”

2. 전방 선언

class USpringArmComponent;
struct FInputActionValue;

처음에는 단순히

"USpringArmComponent라는 클래스를 선언합니다."

정도로 생각했습니다.

하지만 이것은 정확히 말하면 전방 선언(Forward Declaration)입니다.

class USpringArmComponent;

컴파일러에게

"USpringArmComponent라는 타입이 어딘가에 존재합니다."

라는 사실만 먼저 알려주는 것입니다.

아직 그 클래스 내부에 어떤 변수와 함수가 들어 있는지는 알려주지 않습니다.

그래서 헤더에서 다음과 같이 포인터 타입만 선언할 때는 전체 헤더를 바로 포함하지 않고도 사용할 수 있습니다.

USpringArmComponent* SpringArmComp;

비유하면 다음과 같습니다.

“자세한 정보는 나중에 알려드리겠지만, 일단 이런 이름을 가진 대상이 존재한다는 것만 알아두세요.”

반대로 .cpp에서 실제로 USpringArmComponent의 함수나 기능을 사용하려면 해당 클래스의 헤더를 #include하여 전체 정의를 알아야 합니다.

전방 선언을 사용하는 이유 중 하나는 헤더 간 의존성을 줄이고 불필요한 include를 줄이기 위해서입니다.

3. UPROPERTY — Editor와 Blueprint 권한은 따로 생각하기

UPROPERTY(VisibleAnywhere, BlueprintReadOnly, Category = "Camera")
USpringArmComponent* SpringArmComp;

처음에는 다음과 같이 이해했습니다.

VisibleAnywhere = 읽기만 가능 BlueprintReadOnly = 블루프린트에서 읽기만 가능

그런데 여기서 중요한 점이 있었습니다.

VisibleAnywhere와 BlueprintReadOnly는 서로 다른 영역을 제어합니다.

따라서

UPROPERTY(VisibleAnywhere, BlueprintReadOnly, Category = "Camera")
USpringArmComponent* SpringArmComp;

는 다음과 같이 이해할 수 있습니다.

SpringArmComp를 언리얼 프로퍼티 시스템에 노출하고, 에디터에서는 Camera 카테고리에서 확인할 수 있지만 수정할 수 없으며, Blueprint에서도 읽기만 허용합니다.

반면

UPROPERTY(EditAnywhere, BlueprintReadWrite, Category = "Movement")
float NormalSpeed;

는 에디터에서도 수정할 수 있고, Blueprint에서도 읽고 쓸 수 있습니다.

이번에 바로잡은 부분

VisibleAnywhere를 단순히 “읽기 전용 변수”라고 외우면 안 됩니다.

정확히는

에디터의 프로퍼티 창에서 보이지만 직접 편집할 수 없도록 하는 지정자입니다.

4. GameMode와 StaticClass()

DefaultPawnClass = ASpartaCharacter::StaticClass();
PlayerControllerClass = ASpartaPlayerController::StaticClass();

처음에는 다음과 같이 주석을 달았습니다.

"ASpartaCharacter를 이 게임 모드의 PC로 사용합니다."

하지만 이것은 잘못된 표현이었습니다.

Pawn과 PlayerController는 서로 다른 역할을 담당합니다.

DefaultPawnClass

에는 플레이어가 기본적으로 사용할 Pawn 또는 Character 클래스를 지정하고,

PlayerControllerClass

에는 플레이어를 조종하는 PlayerController 클래스를 지정합니다.

따라서

DefaultPawnClass = ASpartaCharacter::StaticClass();

는

이 GameMode에서는 기본 플레이어 캐릭터로 ASpartaCharacter 클래스를 사용합니다.

라는 의미이고,

PlayerControllerClass = ASpartaPlayerController::StaticClass();

는

기본 PlayerController로 ASpartaPlayerController 클래스를 사용합니다.

라는 의미입니다.

그런데 StaticClass()는 무엇인가요?

ASpartaCharacter::StaticClass()

여기서는 ASpartaCharacter 객체를 직접 생성하는 것이 아닙니다.

언리얼 엔진에게

"ASpartaCharacter라는 클래스 자체의 정보를 주세요."

라고 요청하는 것입니다.

언리얼에서는 클래스 자체도 UClass라는 형태의 객체로 관리합니다.

따라서 StaticClass()는 해당 클래스의 UClass 정보를 가져오는 함수라고 이해할 수 있습니다.

게임식으로 비유하면,

ASpartaCharacter

가 캐릭터 설계도의 종류라면,

ASpartaCharacter::StaticClass()

는

“ASpartaCharacter라는 설계도 정보를 넘겨주세요.”

에 가깝습니다.

그래서 DefaultPawnClass에는 실제 캐릭터 한 명을 넣는 것이 아니라

앞으로 어떤 종류의 캐릭터를 생성해야 하는지

를 알려주는 클래스 정보를 넣습니다.

5. SpringArm과 Camera 컴포넌트 생성

SpringArmComp =
    CreateDefaultSubobject<USpringArmComponent>(TEXT("SpringArm"));

CreateDefaultSubobject는 생성자에서 캐릭터가 기본적으로 가지고 있을 서브 오브젝트 또는 컴포넌트를 생성할 때 사용합니다.

여기서는

<USpringArmComponent>

를 통해

USpringArmComponent 타입의 컴포넌트를 만들겠습니다.

라고 지정하고,

TEXT("SpringArm")

을 통해 생성되는 컴포넌트에 "SpringArm"이라는 이름을 붙입니다.

즉,

SpringArm이라는 이름의 스프링 암 컴포넌트를 하나 생성합니다.

부모 컴포넌트에 부착하기

SpringArmComp->SetupAttachment(RootComponent);

스프링 암을 캐릭터의 RootComponent 아래에 붙입니다.

구조로 보면 다음과 같습니다.

Character
└─ RootComponent
   └─ SpringArmComp

SpringArm 길이

SpringArmComp->TargetArmLength = 300.0f;

스프링 암의 목표 길이를 300으로 설정합니다.

3인칭 카메라를 생각하면 캐릭터와 카메라 사이에 막대를 하나 두고, 그 막대 길이를 300으로 설정한다고 생각하면 이해하기 쉽습니다.

Controller 회전을 SpringArm이 사용하도록 설정하기

SpringArmComp->bUsePawnControlRotation = true;

컨트롤러의 회전값을 스프링 암이 사용하도록 설정합니다.

즉 플레이어가 마우스로 시점을 돌려 Controller Rotation이 변경되면, SpringArm 역시 그 회전을 따라가도록 만드는 구조입니다.

6. Camera를 SpringArm 끝에 달기

CameraComp =
    CreateDefaultSubobject<UCameraComponent>(TEXT("Camera"));

CameraComp->SetupAttachment(
    SpringArmComp,
    USpringArmComponent::SocketName
);

카메라 컴포넌트를 생성하고 스프링 암에 부착합니다.

전체 구조는 대략 다음과 같습니다.

Character
└─ RootComponent
   └─ SpringArm
      └─ Camera

즉 캐릭터에 카메라를 바로 붙이는 것이 아니라,

캐릭터 → 스프링 암 → 카메라

순서로 연결합니다.

왜 Camera의 bUsePawnControlRotation은 false인가요?

CameraComp->bUsePawnControlRotation = false;

처음 달았던 주석은 대체로 맞았습니다.

이미

SpringArmComp->bUsePawnControlRotation = true;

로 설정했기 때문에 Controller의 회전은 SpringArm이 담당합니다.

Camera는 SpringArm에 붙어 있으므로 SpringArm이 회전하면 Camera 역시 함께 따라갑니다.

따라서 카메라까지 별도로 Pawn Control Rotation을 직접 사용할 필요가 없습니다.

구조를 정리하면 다음과 같습니다.

Controller Rotation
        ↓
    SpringArm 회전
        ↓
   Camera가 따라감

즉 회전 명령은 SpringArm이 받고, Camera는 그 끝에 붙어서 따라갑니다.

7. Enhanced Input — IMC 활성화

여기부터는 처음 학습했을 때 가장 기억이 부실했던 부분입니다.

if (ULocalPlayer* LocalPlayer = GetLocalPlayer())
{
    if (UEnhancedInputLocalPlayerSubsystem* Subsystem =
        LocalPlayer->GetSubsystem<UEnhancedInputLocalPlayerSubsystem>())
    {
        if (InputMappingContext)
        {
            Subsystem->AddMappingContext(InputMappingContext, 0);
        }
    }
}

처음에는

“입력 매핑이 잘되었는지 검사하는 코드인가?”

라고 생각했습니다.

하지만 정확히는 다릅니다.

이 코드는 Input Mapping Context를 실제 플레이어의 Enhanced Input 시스템에 등록하는 과정입니다.

① Local Player 가져오기

ULocalPlayer* LocalPlayer = GetLocalPlayer();

현재 PlayerController와 연결된 로컬 플레이어 정보를 가져옵니다.

그리고 이를 if문 안에서 사용했으므로, 정상적으로 가져왔을 때만 내부 코드가 실행됩니다.

쉽게 말하면,

“현재 이 컴퓨터에서 플레이 중인 플레이어가 존재하나요?”

를 확인하는 과정이라고 볼 수 있습니다.

② Enhanced Input Subsystem 가져오기

LocalPlayer->GetSubsystem<
    UEnhancedInputLocalPlayerSubsystem
>()

LocalPlayer가 가지고 있는 여러 시스템 가운데 Enhanced Input을 담당하는 Subsystem을 가져옵니다.

이 역시 if문 안에서 사용되므로, 정상적으로 가져왔을 때만 다음 단계로 넘어갑니다.

LocalPlayer
    ↓
Enhanced Input Subsystem

순서로 찾아가는 것입니다.

③ InputMappingContext가 존재하는지 확인하기

if (InputMappingContext)

포인터가 유효한지 확인합니다.

쉽게 말하면,

“등록하려고 하는 IMC가 실제로 존재하나요?”

를 확인하는 것입니다.

④ Mapping Context 등록하기

Subsystem->AddMappingContext(InputMappingContext, 0);

이제 실제로 해당 InputMappingContext를 Enhanced Input 시스템에 추가합니다.

즉 이것은 검사 코드가 아니라 활성화 코드입니다.

두 번째 값인

0

은 Mapping Context의 Priority입니다.

여러 Mapping Context가 동시에 존재할 때 우선순위를 결정하는 데 사용됩니다.

이 부분 전체는 다음 한 문장으로 기억할 수 있습니다.

“현재 플레이어의 Enhanced Input 시스템을 찾아서 제가 만든 IMC를 등록합니다.”

8. Cast — 원하는 타입이 맞는지 확인하기

if (UEnhancedInputComponent* EnhancedInput =
    Cast<UEnhancedInputComponent>(PlayerInputComponent))
{

여기서 핵심은 Cast입니다.

PlayerInputComponent는 부모 타입인 UInputComponent 계열로 전달되어 있습니다.

하지만 Enhanced Input 전용 함수인

BindAction()

을 사용하려면 UEnhancedInputComponent로 접근할 수 있어야 합니다.

그래서

Cast<UEnhancedInputComponent>(PlayerInputComponent)

를 사용합니다.

개념적으로는

“이 PlayerInputComponent가 실제로 UEnhancedInputComponent로 사용할 수 있는 객체인가요?”

라고 확인하는 과정입니다.

캐스팅에 성공하면 해당 타입의 포인터를 얻고, 실패하면 유효한 포인터를 얻지 못합니다.

그래서 다음과 같이 if문과 함께 사용하면,

if (UEnhancedInputComponent* EnhancedInput = Cast<...>())

캐스팅에 성공했을 때만 내부 코드를 실행합니다.

라는 구조를 만들 수 있습니다.

9. PlayerController도 원하는 클래스인지 확인하기

if (ASpartaPlayerController* PlayerController =
    Cast<ASpartaPlayerController>(GetController()))
{
}

이번에는 캐릭터를 조종하고 있는 Controller가

ASpartaPlayerController

타입인지 확인합니다.

왜 이것이 필요할까요?

이후 코드에서

PlayerController->JumpAction

처럼 ASpartaPlayerController에 정의해둔 변수를 사용하기 때문입니다.

일반 AController 타입으로는 JumpAction이라는 멤버가 있다는 사실을 알 수 없습니다.

따라서 흐름은 다음과 같습니다.

GetController()
        ↓
ASpartaPlayerController가 맞는지 확인
        ↓
맞으면 PlayerController 포인터 획득
        ↓
JumpAction, MoveAction 등에 접근

10. Input Action과 함수를 연결하는 BindAction

EnhancedInput->BindAction(
    PlayerController->JumpAction,
    ETriggerEvent::Triggered,
    this,
    &ASpartaCharacter::StartJump
);

이제 Input Action과 실제 C++ 함수를 연결합니다.

각 인자를 나누어보면 다음과 같습니다.

PlayerController->JumpAction

어떤 Input Action을 감시할 것인지 지정합니다.

ETriggerEvent::Triggered

그 Input Action이 어떤 상태가 되었을 때 실행할지 지정합니다.

this

현재 ASpartaCharacter 객체를 의미합니다.

&ASpartaCharacter::StartJump

실제로 실행할 함수입니다.

그래서 전체 문장을 사람 말로 바꾸면,

“JumpAction이 Triggered 상태가 되면 현재 SpartaCharacter의 StartJump 함수를 실행해주세요.”

가 됩니다.

BindAction은 결국

입력 이벤트와 실제 게임 로직 함수를 연결하는 과정입니다.

11. Triggered와 Completed

점프에는 두 개의 바인딩을 사용했습니다.

EnhancedInput->BindAction(
    PlayerController->JumpAction,
    ETriggerEvent::Triggered,
    this,
    &ASpartaCharacter::StartJump
);

그리고

EnhancedInput->BindAction(
    PlayerController->JumpAction,
    ETriggerEvent::Completed,
    this,
    &ASpartaCharacter::StopJump
);

현재 코드에서는

Triggered
    ↓
StartJump()

Completed
    ↓
StopJump()

구조로 점프 시작과 종료를 연결합니다.

다만 Triggered를 단순히 “키를 눌렀을 때 딱 한 번 실행됩니다.”라고 외우면 곤란합니다.

Input Action에 설정된 Trigger 조건에 따라 Triggered가 발생하는 방식이 달라질 수 있습니다.

버튼을 누르는 순간 한 번만 처리하고 싶다면 상황에 따라

ETriggerEvent::Started

를 사용하는 경우도 있습니다.

따라서 중요한 것은 이벤트 이름만 외우는 것이 아니라, Input Action에 어떤 Trigger가 설정되어 있는지 함께 확인하는 것입니다.

12. Input Action의 값을 FVector2D로 꺼내기

이동 코드입니다.

const FVector2D MoveInput =
    Value.Get<FVector2D>();

Value에는 Input Action을 통해 전달된 입력값이 들어 있습니다.

Move Action을 2D Axis로 만들었다면,

Value.Get<FVector2D>()

를 이용하여 그 값을 FVector2D 형태로 꺼낼 수 있습니다.

예를 들면 다음과 같은 값이 들어올 수 있습니다.

앞으로 이동   → X = 1
뒤로 이동     → X = -1
오른쪽 이동   → Y = 1
왼쪽 이동     → Y = -1

다만 어느 축이 앞뒤이고 어느 축이 좌우인지는 실제 Input Mapping 설정에 따라 달라질 수 있습니다.

따라서 코드를 볼 때는 무조건

X = 앞뒤

라고 암기하기보다는 IMC 설정까지 함께 확인하는 것이 좋습니다.

13. IsNearlyZero() — 왜 그냥 != 0을 사용하지 않나요?

if (!FMath::IsNearlyZero(MoveInput.X))
{

처음 보면 다음처럼 작성해도 될 것처럼 보입니다.

if (MoveInput.X != 0)

하지만 float는 계산 과정에서 아주 작은 오차가 생길 수 있습니다.

예를 들어 실제로는 0에 가까운 값인데

0.00000001

같은 값이 들어올 수도 있습니다.

따라서

FMath::IsNearlyZero()

를 사용하여

“완전히 정확한 0은 아니더라도 충분히 0에 가까운가요?”

를 검사합니다.

그리고 코드에는 앞에 !가 붙어 있습니다.

!FMath::IsNearlyZero(MoveInput.X)

따라서 의미는

“MoveInput.X가 거의 0이 아니라면”

이 됩니다.

즉 실제 이동 입력이 있을 때만 아래 코드를 실행합니다.

14. AddMovementInput()으로 캐릭터 이동시키기

AddMovementInput(
    GetActorForwardVector(),
    MoveInput.X
);

두 값을 전달하고 있습니다.

GetActorForwardVector()

현재 캐릭터가 바라보고 있는 앞 방향을 가져옵니다.

그리고

MoveInput.X

는 그 방향으로 어느 정도의 입력을 줄 것인지 전달합니다.

예를 들어

MoveInput.X = 1

이라면 앞 방향,

MoveInput.X = -1

이라면 반대 방향으로 입력하게 됩니다.

따라서 개념적으로는

방향
+
입력값
=
Movement Input

이라고 볼 수 있습니다.

15. 마우스 입력으로 Controller 회전시키기

마지막은 시점 회전입니다.

FVector2D LookInput =
    Value.Get<FVector2D>();

Look Action 역시 2D Axis 값이므로 FVector2D로 받아옵니다.

그리고

AddControllerYawInput(LookInput.X);

으로 좌우 회전값을 Controller에 넣습니다.

Yaw는 쉽게 말하면 고개를 좌우로 돌리는 회전입니다.

반면

AddControllerPitchInput(LookInput.Y);

은 위아래 방향의 회전입니다.

정리하면 다음과 같습니다.

LookInput.X
    ↓
Yaw
    ↓
좌우 시점 회전

LookInput.Y
    ↓
Pitch
    ↓
상하 시점 회전

16. 그런데 Controller를 돌렸는데 왜 Camera가 움직이나요?

여기서 앞서 설정했던 코드가 다시 연결됩니다.

SpringArmComp->bUsePawnControlRotation = true;

Look 입력은

AddControllerYawInput()
AddControllerPitchInput()

을 이용하여 Controller Rotation을 변경합니다.

그리고 SpringArm은 Controller Rotation을 사용하도록 설정되어 있습니다.

따라서 전체 과정은 다음과 같이 이어집니다.

마우스 움직임
    ↓
LookAction
    ↓
FVector2D LookInput
    ↓
AddControllerYawInput()
AddControllerPitchInput()
    ↓
Controller Rotation 변경
    ↓
SpringArm이 회전을 따라감
    ↓
SpringArm 끝에 붙은 Camera도 따라감

처음에는 각각 따로 존재하는 코드처럼 보였지만, 실제로는 서로 연결되어 있었습니다.

17. 전체 입력 시스템 한 번에 정리하기

이번 코드에서 가장 중요하게 정리한 것은 각각의 함수를 외우는 것보다 입력이 캐릭터에게 전달되는 과정이었습니다.

전체 흐름을 그려보면 다음과 같습니다.

[키보드 / 마우스]
        ↓
Input Mapping Context
        ↓
Input Action
        ↓
Enhanced Input
        ↓
BindAction
        ↓
캐릭터 함수
        ↓
이동 / 점프 / 회전

조금 더 코드에 가깝게 보면 다음과 같습니다.

BeginPlay()
    ↓
LocalPlayer 획득
    ↓
EnhancedInput Subsystem 획득
    ↓
AddMappingContext()
    ↓
IMC 활성화


SetupPlayerInputComponent()
    ↓
PlayerInputComponent 획득
    ↓
UEnhancedInputComponent로 Cast
    ↓
PlayerController Cast
    ↓
BindAction()
    ↓
Move / Look / Jump 함수 연결

실제 플레이 중에는 다음과 같이 동작합니다.

W 키 또는 마우스 입력
    ↓
Input Action 발생
    ↓
BindAction으로 연결된 함수 실행
    ↓
FInputActionValue에서 값 추출
    ↓
AddMovementInput()
또는
AddControllerYawInput()

이번 학습에서 수정한 오개념

주석을 직접 달아보니 알고 있다고 생각했지만 실제로는 애매하게 이해하고 있던 부분이 꽤 많았습니다.

1. VisibleAnywhere

잘못된 이해:

읽기 전용 변수입니다.

수정:

언리얼 에디터의 프로퍼티 창에서 보이지만 수정할 수 없도록 하는 지정자입니다. Blueprint에서의 읽기 및 쓰기 여부는 BlueprintReadOnly, BlueprintReadWrite가 따로 결정합니다.

2. 전방 선언

잘못된 이해:

이 클래스를 여기에서 선언합니다.

수정:

이 이름을 가진 타입이 존재한다는 사실만 컴파일러에게 미리 알려줍니다.

3. StaticClass()

처음에는 역할 자체가 명확하지 않았습니다.

수정:

객체를 생성하는 함수가 아니라 해당 Unreal 클래스의 UClass 정보를 가져오는 함수입니다.

4. AddMappingContext()

잘못된 이해:

입력이 제대로 설정되었는지 검사합니다.

수정:

Input Mapping Context를 Local Player의 Enhanced Input 시스템에 실제로 추가하고 활성화합니다.

5. Cast

처음에는 코드를 그대로 따라 작성하기만 했습니다.

수정:

현재 가지고 있는 객체가 제가 원하는 클래스 타입으로 사용할 수 있는 객체인지 확인하고, 가능하다면 해당 타입의 포인터를 얻습니다.

6. BindAction

단순히

입력을 연결합니다.

정도로 알고 있었습니다.

수정:

특정 Input Action에서 특정 Trigger Event가 발생했을 때 어떤 객체의 어떤 함수를 실행할 것인지 연결합니다.

마무리

이번 코드에서 개별 문법도 중요했지만, 가장 큰 수확은 코드들이 서로 어떤 관계를 가지고 있는지 이해하기 시작했다는 점입니다.

처음에는

AddMappingContext()
Cast()
BindAction()
Value.Get<FVector2D>()

가 모두 별개의 코드처럼 보였습니다.

하지만 흐름을 연결해보면 결국 하나의 과정입니다.

입력 설정을 플레이어에게 활성화하고 → 입력을 받을 컴포넌트를 찾고 → Input Action과 캐릭터 함수를 연결하고 → 전달받은 값을 이동과 회전에 사용합니다.

카메라 코드 역시 마찬가지였습니다.

Controller
→ SpringArm
→ Camera

라는 관계를 먼저 이해하고 나니,

bUsePawnControlRotation = true;
bUsePawnControlRotation = false;

가 왜 서로 다르게 설정되어 있는지도 자연스럽게 이해할 수 있었습니다.

결국 현재 단계에서 중요한 것은 코드를 통째로 외우는 것보다,

“누가 누구를 가지고 있고, 누가 누구에게 값을 전달하는가?”

를 추적하는 것이라고 생각합니다.

앞으로 새로운 언리얼 C++ 코드를 볼 때도 함수 이름부터 외우기보다는 객체 간의 관계와 데이터가 흘러가는 방향부터 그려보는 방식으로 읽어보려고 합니다.

#UnrealEngine #UnrealCPP #CPlusPlus #EnhancedInput #게임개발 #언리얼엔진 #개발공부

Keep 강의를 하나씩 충분히 이해하고 넘어가는 학습 방식 자체는 유지하고 싶다. 특히 동료분들과 함께 코드에 주석을 달고, 각 개념을 설명하면서 복습하는 과정이 개념을 확실하게 이해하는 데 효과적으로 작용했다.

Problem 다만 모든 내용을 꼼꼼하게 이해하려다 보니 학습 진도가 지나치게 느려지는 문제가 있다. 부족한 진도를 철야나 추가 노동으로 해결하는 방식은 지속 가능하지 않다. 모든 내용을 한 번에 완벽하게 이해하려 하기보다, 중요한 개념과 그렇지 않은 부분을 구분하고 일단 넘어갔다가 필요할 때 다시 확인하는 방식이 필요하다.

Try 집중 학습 시간이 필요할 때는 팀원들에게 미리 양해를 구하고 방해 금지 모드를 활용해 몰입할 수 있는 시간을 확보한다. 또한 강의를 들으며 모든 의문을 즉시 해결하려 하지 않고, ① 지금 반드시 이해해야 하는 내용 / ② 표시만 해두고 나중에 복습할 내용으로 나눠 학습 속도를 높여본다.

Feel 하나의 개념을 온전히 이해했을 때 느끼는 만족감은 분명 크다. 지금의 깊이 있는 학습 방식 자체를 버리기보다는, 이해의 깊이는 유지하면서 학습 속도를 높이는 방법을 찾고 싶다.

언리얼 엔진을 공부하다 보면 컴파일, 빌드, 쿠킹, 패키징, 로드처럼 비슷해 보이는 용어를 자주 접하게 된다.

또 C++ 코드를 작성하다 보면 UCLASS(), GENERATED_BODY(), .generated.h처럼 일반 C++에서는 볼 수 없었던 코드도 등장한다.

이번에는 이 개념들이 각각 무엇을 의미하고, 언리얼의 리플렉션(Reflection) 시스템과 어떻게 연결되는지 정리해 보았다.

1. 컴파일, 쿠킹, 패키징, 로드는 서로 다르다

처음에는 모두 "내가 만든 것을 게임에서 사용할 수 있게 만드는 과정"처럼 보이지만 역할이 다르다.

컴파일(Compile)

컴파일은 작성한 코드나 블루프린트를 실행할 수 있는 형태로 변환하는 과정이다.

C++에서는 작성한 소스 코드를 컴퓨터가 실행할 수 있는 형태로 변환하는 과정이 필요하고, 블루프린트 역시 노드와 변수, 함수, 이벤트 그래프 등을 검사하고 실행 가능한 형태로 만드는 컴파일 과정이 존재한다.

쿠킹(Cook)

쿠킹은 코드보다는 게임 콘텐츠를 대상 플랫폼에서 사용할 수 있는 형태로 변환하는 과정에 가깝다.

예를 들면 다음과 같은 콘텐츠가 대상이 된다.

• Texture
• Mesh
• Sound
• Blueprint
• Level

PC, 콘솔, 모바일 등 실제 게임이 실행될 플랫폼에 맞게 콘텐츠를 준비하는 과정이라고 이해할 수 있다.

패키징(Package)

패키징은 컴파일된 코드와 쿠킹된 콘텐츠를 실제 배포 가능한 형태로 묶는 과정이다.

언리얼의 전체 패키징 과정에서는 Build, Cook, Stage, Package, Deploy, Run 등의 단계가 사용된다.

따라서 단순하게 보면,

Compile → 코드를 실행할 수 있도록 준비 Cook → 콘텐츠를 플랫폼에 맞게 준비 Package → 준비된 것들을 배포 가능한 게임으로 묶기

정도로 구별할 수 있다.

로드(Load)

로드는 앞의 과정과 성격이 조금 다르다.

게임 실행 중 필요한 에셋이나 레벨 등의 데이터를 저장장치에서 메모리로 가져오는 과정이다.

예를 들어 SSD에 저장되어 있는 맵이나 텍스처가 필요하다면 게임이 이를 메모리로 가져와 사용할 수 있도록 해야 한다.

그런데 게임에 존재하는 모든 것을 한 번에 로드한다면 메모리와 로딩 시간 측면에서 비효율적이다.

그래서 실제 게임에서는 필요한 데이터를 어떻게, 언제 가져올 것인지가 중요하며 동기 로딩과 비동기 로딩 같은 개념도 등장한다.

2. Unreal C++의 빌드는 일반 C++과 조금 다르다

언리얼 C++을 공부하다 보면 다음과 같은 매크로를 계속 만나게 된다.

UCLASS()
USTRUCT()
UPROPERTY()
UFUNCTION()

이 코드는 단순히 C++ 컴파일러에게 넘겨서 처리하는 것으로 끝나지 않는다.

언리얼에는 UHT(Unreal Header Tool)와 UBT(Unreal Build Tool)가 있기 때문이다.

UHT와 UBT

대략적인 흐름을 단순화하면 다음과 같이 이해할 수 있다.

내가 작성한 Unreal C++ 코드
        ↓
UBT가 빌드 과정 관리
        ↓
UHT 실행
        ↓
UCLASS / UPROPERTY / UFUNCTION 등 분석
        ↓
UObject 시스템에 필요한 코드 생성
        ↓
C++ 컴파일
        ↓
실행 가능한 코드 생성

즉,

언리얼 C++은 일반적인 C++ 컴파일뿐 아니라 언리얼의 UObject 및 리플렉션 시스템을 지원하기 위한 코드 생성 과정이 추가된다.

이 점이 일반적인 C++ 프로젝트와 Unreal C++ 프로젝트를 이해할 때 중요한 차이 중 하나다.

3. 블루프린트도 컴파일한다

블루프린트는 노드를 연결하면 곧바로 실행되는 것처럼 보이지만 블루프린트 역시 컴파일 과정이 존재한다.

블루프린트 에디터에서 Compile 버튼을 누르면 엔진은 작성된 블루프린트의 변수, 함수, 이벤트 그래프 등의 내용을 검사하고 실행 가능한 형태로 준비한다.

다만 여기서 주의할 점이 있다.

"블루프린트는 컴파일하기 때문에 C++보다 느리다"라고 단순하게 결론 내리는 것은 적절하지 않다.

블루프린트와 C++의 런타임 성능 차이는 실행 방식과 구현 내용에 따라 달라질 수 있기 때문에, 실제 최적화에서는 어떤 로직을 얼마나 자주 실행하는지를 함께 확인해야 한다.

4. Material과 Shader도 별도의 컴파일 과정이 있다

언리얼에서 "컴파일"이라고 하면 C++만 생각하기 쉽지만 Material과 Shader에도 별도의 컴파일 과정이 존재한다.

예를 들어 필요한 Shader Map이 캐시에 존재하지 않는 머티리얼이 필요해지면 엔진에서 셰이더 컴파일 작업이 발생할 수 있다.

이러한 작업은 Shader Compile Worker를 통해 병렬로 처리될 수 있다.

중요한 것은 이것이 메시나 텍스처 자체를 로드하는 작업과는 다르다는 점이다.

셰이더 컴파일은 GPU가 사용할 셰이더 코드를 준비하는 과정으로 이해하면 된다.

TA를 공부하는 입장에서는 C++ 컴파일뿐만 아니라 셰이더 컴파일 역시 구별해서 알아둘 필요가 있다.

5. 리플렉션(Reflection)이란?

언리얼 C++을 공부하면서 상당히 중요한 개념이 리플렉션 시스템이다.

리플렉션을 간단하게 표현하면,

프로그램이 자신의 클래스, 변수, 함수 등에 관한 정보를 다룰 수 있도록 만드는 체계

라고 이해할 수 있다.

예를 들어 일반적인 C++ 클래스가 있다고 하자.

class PlayerData
{
public:
    int HP;
    float MoveSpeed;
};

사람이 이 코드를 읽으면 PlayerData 안에 HP와 MoveSpeed가 있다는 것을 쉽게 알 수 있다.

하지만 언리얼 엔진과 에디터가 이 정보를 자신들의 시스템에서 활용하려면 별도의 메타데이터가 필요하다.

예를 들어 엔진은 다음과 같은 작업을 해야 한다.

• 특정 클래스가 어떤 클래스인지 파악
• 프로퍼티 정보를 에디터에서 활용
• C++ 기능을 블루프린트에 노출
• C++ 클래스를 블루프린트와 연결
• 직렬화 및 저장에 필요한 정보 활용
• 네트워크 복제 시스템에서 프로퍼티 정보 활용
• 런타임에서 타입 정보 확인

이러한 여러 엔진 기능의 기반이 되는 것이 언리얼의 리플렉션 시스템이다.

따라서 리플렉션을 단순히

"디테일 패널에 변수를 표시하는 기능"

이라고 이해하면 범위가 너무 좁다.

디테일 패널 노출은 리플렉션을 이용해서 구현되는 여러 기능 중 하나라고 보는 것이 더 정확하다.

6. #pragma once는 매크로가 아니다

언리얼 C++ 헤더를 열면 거의 항상 위쪽에 다음 코드가 있다.

#pragma once

처음 보면 UCLASS() 같은 언리얼 매크로와 비슷해 보일 수 있지만 #pragma once는 언리얼 리플렉션 매크로가 아니다.

이는 전처리 지시문이다.

역할은 간단하다.

하나의 헤더 파일이 같은 컴파일 단위에서 중복으로 포함되는 것을 방지한다.

따라서 다음은 구별해야 한다.

#pragma once
→ 전처리와 관련된 지시문

UCLASS()
UPROPERTY()
UFUNCTION()
→ Unreal Header Tool이 처리하는 언리얼 리플렉션 관련 매크로

7. *.generated.h는 왜 존재할까?

언리얼 C++ 헤더에서는 다음과 같은 코드를 볼 수 있다.

#include "CoreMinimal.h"
#include "GameFramework/Actor.h"
#include "TestActor.generated.h"

여기에서 특히 중요한 것이

#include "TestActor.generated.h"

이다.

이 파일은 내가 직접 작성하는 파일이 아니다.

UHT가 헤더를 분석하면서 언리얼의 리플렉션 및 UObject 시스템을 지원하기 위해 필요한 코드를 생성하며, 이 과정에서 만들어지는 코드와 연결되는 헤더다.

그리고 중요한 규칙이 하나 있다.

*.generated.h는 해당 헤더 파일의 include 목록에서 마지막에 위치해야 한다.

따라서 다음처럼 작성해야 한다.

#include "CoreMinimal.h"
#include "GameFramework/Actor.h"
#include "TestActor.generated.h"

그 아래에 다시 다른 헤더를 #include하는 방식은 피해야 한다.

8. UCLASS()는 무엇인가?

다음과 같은 Unreal C++ 코드를 살펴보자.

UCLASS()
class FRONTLINEFPS_API ATestActor : public AActor
{
    GENERATED_BODY()
};

여기서

UCLASS()

는 언리얼의 리플렉션과 관련된 매크로다.

UHT가 이 선언을 분석하고 해당 클래스가 언리얼의 UObject 시스템에서 필요한 처리를 받을 수 있도록 한다.

AActor 역시 UObject 계열의 클래스이므로 Unreal Object System과 연결되어 있다.

따라서

class ATestActor : public AActor

는

ATestActor가 AActor를 상속받는다.

라는 일반 C++의 상속 관계를 나타내고,

UCLASS()

는 이 클래스가 언리얼의 UObject 및 리플렉션 체계 안에서 처리될 수 있도록 필요한 정보를 제공하는 역할을 한다.

두 코드는 서로 다른 역할을 담당한다.

9. UCLASS() 안에는 옵션을 넣을 수 있다

UCLASS()의 괄호 안에는 클래스 지정자(Class Specifier)를 작성할 수 있다.

예를 들어,

UCLASS(Blueprintable)

처럼 사용할 수 있다.

Blueprintable

해당 클래스를 기반으로 블루프린트 클래스를 만들 수 있도록 지정하는 데 사용한다.

UCLASS(Blueprintable)
class AMyActor : public AActor
{
    GENERATED_BODY()
};

BlueprintType

해당 타입을 블루프린트에서 변수 타입 등으로 사용할 수 있도록 노출하는 데 관련된 지정자다.

UCLASS(BlueprintType)

Blueprintable과 BlueprintType은 이름이 비슷하지만 동일한 역할을 하는 옵션은 아니다.

따라서 실제 사용 시에는 해당 클래스의 부모 클래스와 지정자의 상속 여부까지 확인하는 것이 좋다.

10. MYPROJECT_API는 무엇인가?

Unreal C++ 클래스에서는 다음과 같은 형태도 볼 수 있다.

class MYPROJECT_API ATestActor : public AActor

여기서

MYPROJECT_API

는 모듈 API 지정자(Module API Specifier)다.

프로젝트 이름에 따라 이름이 달라질 수 있다.

언리얼 프로젝트는 하나의 거대한 코드 덩어리로만 구성되는 것이 아니라 여러 모듈로 나뉘어 빌드될 수 있다.

예를 들면 엔진에는 다음과 같은 모듈들이 있다.

Core
CoreUObject
Engine
UMG
GameplayAbilities
...

게임 프로젝트에도 자체 게임 모듈이 존재한다.

모듈 API 지정자는 클래스나 함수 등의 심볼을 다른 모듈에서 사용할 수 있도록 노출하는 것과 관련된 표시다.

따라서 이것을 public, private 같은 C++ 접근 지정자와 완전히 같은 것으로 보면 안 된다.

public/private가 클래스 내부에서 누가 멤버에 접근할 수 있는가를 제어한다면,

MYPROJECT_API와 같은 모듈 API 지정자는 모듈 또는 DLL 경계를 넘어 해당 심볼을 사용할 수 있도록 노출하는 것과 관련된다.

11. DLL이란?

DLL은 Dynamic Link Library의 약자다.

쉽게 표현하면 프로그램에서 사용할 코드와 기능을 별도의 라이브러리 파일로 만들어 둔 것이다.

언리얼의 모듈 시스템을 공부하다 보면 DLL과 모듈 API 지정자 개념이 함께 등장할 수 있다.

Unreal Project
│
├─ Module A
│   └─ Class A
│
├─ Module B
│   └─ Class B
│
└─ Module C

모듈이 분리되어 있다면 어떤 클래스나 함수를 다른 모듈에서 사용할 수 있도록 내보내야 하는 상황이 생길 수 있다.

이때 모듈 API 지정자가 중요한 역할을 한다.

전체 내용 정리

이번 학습에서 가장 중요했던 내용을 연결하면 다음과 같다.

[Unreal C++ 코드 작성]
        │
        ├── UCLASS
        ├── UPROPERTY
        ├── UFUNCTION
        │
        ↓
[UHT가 헤더 분석]
        ↓
[리플렉션/UObject용 코드 생성]
        ↓
[UBT가 빌드 과정 관리]
        ↓
[C++ 컴파일]
        ↓
[게임 코드]

그리고 게임 전체를 배포하는 관점에서는 다시,

코드 작성
   ↓
Build / Compile
   ↓
Cook
   ↓
Stage
   ↓
Package
   ↓
Deploy / Run

와 같은 더 큰 흐름으로 이어진다.

결국 UCLASS(), UPROPERTY(), generated.h 등을 각각 외우는 것보다 중요한 것은

"일반 C++ 코드를 언리얼 엔진이 이해하고 활용할 수 있도록 연결해 주는 별도의 시스템이 존재한다."

는 구조를 이해하는 것이다.

특히 리플렉션은 단순히 디테일 패널에 버튼이나 변수를 보여주기 위한 기능이 아니다.

C++로 작성한 클래스와 프로퍼티, 함수 등의 정보를 Unreal Engine의 에디터와 런타임 시스템에서 활용할 수 있도록 만드는 기반 체계라고 이해하는 편이 정확하다.

개인 학습 메모

이번 내용을 공부하면서 UCLASS, UPROPERTY, UFUNCTION 등을 단순히 "언리얼에서 반드시 붙여야 하는 매크로"로 외우기보다 왜 필요한지를 먼저 이해하는 것이 중요하다고 느꼈다.

앞으로 Unreal C++ 코드를 읽을 때는 다음과 같이 구분해서 살펴볼 생각이다.

1. 일반 C++ 문법인가?
2. 언리얼 리플렉션 시스템과 관련된 코드인가?
3. 빌드 시스템과 관련된 코드인가?
4. 모듈 경계를 처리하기 위한 코드인가?

이 네 가지를 구별할 수 있다면 처음 보는 Unreal C++ 헤더도 이전보다 구조적으로 읽을 수 있을 것 같다.

1단계 — 코드 읽기

Q1. 생성자 찾기

다음 중 AItem 클래스의 생성자는 무엇입니까?

A. BeginPlay() B. AItem::AItem() C. Tick() D. PostInitializeComponents()

Q2. 루트 컴포넌트

SceneRoot = CreateDefaultSubobject<USceneComponent>(TEXT("SceneRoot"));
SetRootComponent(SceneRoot);

위 코드에서 SceneRoot가 하는 역할을 가장 잘 설명한 것은?

A. 액터의 부모 클래스를 지정한다. B. 액터에 붙는 컴포넌트들의 기준점이 된다. C. 메시를 화면에 그린다. D. 매 프레임 위치를 계산한다.

Q3. CreateDefaultSubobject

StaticMeshComp =
    CreateDefaultSubobject<UStaticMeshComponent>(TEXT("StaticMesh"));

이 코드를 일상적인 말로 가장 자연스럽게 바꿔보십시오.

UStaticMeshComponent 타입의 ____을 만들고, 그것을 ____에 저장한다.

Q4. 컴포넌트 연결

StaticMeshComp->SetupAttachment(SceneRoot);

이 코드의 의미는 무엇입니까?

A. StaticMeshComp를 삭제한다. B. SceneRoot를 StaticMeshComp에 붙인다. C. StaticMeshComp를 SceneRoot 아래에 붙인다. D. StaticMeshComp와 SceneRoot를 같은 객체로 만든다.

2단계 — 에셋 불러오기

Q5. 메시를 찾는 코드

static ConstructorHelpers::FObjectFinder<UStaticMesh> MeshAsset(
    TEXT("/Game/Resources/Props/SM_Chair.SM_Chair"));

이 코드에서 실제로 찾으려는 것은 무엇입니까?

A. 액터 B. 머티리얼 C. 스태틱 메시 에셋 D. SceneComponent

Q6. 왜 Succeeded()를 확인할까요?

if (MeshAsset.Succeeded())
{
    StaticMeshComp->SetStaticMesh(MeshAsset.Object);
}

만약 Succeeded() 확인 없이 바로 MeshAsset.Object를 사용한다면 어떤 문제가 생길 수 있을까요?

짧게 한 문장으로 답해보십시오.

Q7. 머티리얼의 0

StaticMeshComp->SetMaterial(0, MaterialAsset.Object);

여기서 0은 무엇을 의미할까요?

A. 투명도 B. 머티리얼 슬롯 번호 C. 메시 번호 D. 액터 ID

3단계 — 로그

Q8. 로그 카테고리

DEFINE_LOG_CATEGORY(LogJun);

그리고

UE_LOG(LogJun, Warning, TEXT("Hello"));

가 있다면 LogJun은 무엇입니까?

A. 출력할 문자열 B. 로그의 분류용 카테고리 C. 함수 이름 D. 액터 이름

Q9. 로그 등급 연결

다음을 연결하십시오.

Display
Warning
Error

① 일반적인 정보 출력 ② 경고 ③ 오류

Q10. %s와 GetName()

UE_LOG(LogJun, Warning, TEXT("%s BeginPlay"), *GetName());

여기서 %s 자리에는 무엇이 들어갑니까?

A. RotationSpeed B. 현재 액터의 이름 C. 현재 프레임 D. 메시 파일 경로

제가 쓴 답입니다. 주관식을 처참히 틀렸군요.

소스 코드를 확실히 2022버전으로 바꾸어 줍시다. 예전에 졸업작품 할 때는 건들어 보지 않은 기능입니다.

빈 프로젝트임에도 이렇게 폴더가 많은 이유는 엔진의 전체 소스도 같이 열리는 까닭이라고 하더군요. 그렇기에 추후에는 엔진 커스터마이징도 가능하다고 합니다. 이런 느낌의 코드들이군요.

Keep — 계속 유지할 점

원활하고 적극적인 의사소통

팀원들이 문제와 진행 상황을 솔직하게 공유했으며, 이슈가 발생했을 때 즉시 보고하고 함께 해결했다. 요청 사항이 있을 경우 필요한 내용을 빠르게 전달했고, 요청을 받은 팀원도 신속하게 대응했다.

자신의 작업이 끝났을 때도 다른 팀원에게 도움이 필요한 부분이 있는지 먼저 확인하는 등 적극적으로 협업했다. 이러한 소통 방식은 프로젝트 진행 속도를 높이고, 문제를 장기간 방치하지 않도록 하는 데 도움이 되었다.

긍정적인 팀 분위기

팀원들이 서로의 의견을 존중하고 편안하게 의견을 제시할 수 있는 분위기가 유지되었다. 단순히 맡은 기능을 구현하는 것에 그치지 않고, 팀 전체의 완성도를 높이기 위해 함께 고민하는 태도가 돋보였다.

체계적인 기획과 문서화

기능을 바로 구현하기보다 필요한 로직을 먼저 체계적으로 정리한 후 코딩하려고 노력했다. 또한 FigJam을 활용해 기획 내용과 진행 상황을 문서화했으며, 변경 사항을 가능한 한 바로 기록했다.

이러한 문서화 방식은 팀원들이 프로젝트의 방향과 작업 내용을 공유하는 데 도움이 되었으므로 앞으로도 유지할 필요가 있다.

지속적으로 다음 목표를 설정하는 태도

정해진 목표를 달성한 뒤 작업을 바로 끝내기보다, 다음 개선 목표를 설정하고 새로운 내용을 배우려는 태도를 유지했다. 단순히 기능을 완성하는 것보다 프로젝트를 통해 더 많은 것을 학습하는 데 의미를 두었다.

Problem — 개선이 필요한 점

지나치게 촉박한 일정

일부 작업 일정이 야간 작업과 철야를 전제로 구성되었다. 그 결과 작업 후반부에 피로가 누적되었으며, 충분한 검토 없이 기능을 통합하거나 수정하는 상황이 발생했다.

앞으로는 예상치 못한 오류와 수정 시간을 고려해 일정을 더욱 보수적으로 설정할 필요가 있다.

불명확한 우선순위

필수 기능과 추가 기능의 우선순위가 명확하게 구분되지 않아, 세부 기능에 집중하는 동안 전체 구조나 핵심 기능의 안정성을 충분히 확인하지 못한 경우가 있었다.

프로젝트 초기에 다음과 같이 기능을 구분할 필요가 있다.

• 반드시 구현해야 하는 핵심 기능
• 시간이 남을 경우 구현할 추가 기능
• 이후 프로젝트에서 시도할 확장 기능

역할과 일정 분담의 세분화 부족

팀원별 담당 영역은 정해져 있었지만, 기능별 작업 범위와 완료 기준이 충분히 세분화되지 않았다. 이로 인해 기능 간 경계가 겹치거나 동일한 함수가 중복으로 작성되는 문제가 발생했다.

서로의 코드에 대한 이해 부족

각자가 자신의 담당 기능을 중심으로 작업하면서 다른 팀원의 코드 구조와 로직을 충분히 이해하지 못했다. 함수의 선언, 정의, 호출부가 서로 다르거나 매개변수가 일치하지 않는 문제가 발생했으며, Merge 이후에야 오류를 발견하는 경우도 있었다.

AI 활용 과정에서 발생한 코드 충돌

생성형 AI를 활용해 코드를 작성하면서 기존 프로젝트의 변수명, 함수 구조, 설계 방식과 맞지 않는 코드가 추가되기도 했다. 동일한 기능이 중복 구현되거나 서로 다른 코드 작성 방식이 혼재하면서 충돌 가능성이 높아졌다.

문제는 AI 사용 자체보다 생성된 코드를 프로젝트 구조에 맞게 검토하고 수정하는 과정이 부족했다는 점이다.

빌드 성공 이후의 실행 검증 부족

코드가 정상적으로 빌드되더라도 실제 실행 과정에서 기능이 누락되거나, 콘솔 출력이 밀리거나, 글자와 이미지가 사라지는 문제가 발생했다.

빌드 성공만으로 작업이 완료되었다고 판단하지 않고, 실제 게임 흐름에 따라 기능과 UI를 끝까지 테스트할 필요가 있다.

UI의 일관성 부족

초기 화면과 이후 화면 사이에 UI 디자인과 출력 방식의 통일성이 부족했다. 각 기능에서 개별적으로 출력 코드를 작성하면서 화면 구성과 간격이 서로 달라졌다.

건강 관리 부족

프로젝트 완성도를 높이기 위해 장시간 작업했지만, 철야와 과로로 인해 작업 효율이 오히려 낮아지는 문제가 있었다. 프로젝트 일정에는 작업 시간뿐만 아니라 휴식과 컨디션 관리도 포함되어야 한다.

Try — 다음 프로젝트에서 시도할 점

작업 일정을 세부적으로 작성하기

기능 단위뿐만 아니라 설계, 구현, Merge, 테스트, 수정 단계를 나누어 일정을 작성한다. 예상하지 못한 오류에 대응할 수 있도록 별도의 여유 시간도 확보한다.

기능의 우선순위를 명확하게 설정하기

프로젝트 초기에 핵심 기능과 추가 기능을 구분한다. 핵심 기능의 구현과 안정화를 완료한 이후에 추가 기능을 개발한다.

역할과 책임 범위를 구체적으로 정하기

담당 기능뿐만 아니라 다음 항목까지 사전에 결정한다.

• 기능의 입력값과 반환값
• 다른 클래스와의 연결 방식
• 함수와 변수의 명명 규칙
• 담당자가 수정할 수 있는 파일 범위
• 기능의 완료 기준
• 테스트 방법

정기적인 스크럼 진행하기

팀 분위기나 개인적인 친분에 의존하지 않고, 정해진 시간에 스크럼을 진행한다.

스크럼에서는 다음 내용을 공유한다.

1. 어제 완료한 작업
2. 오늘 진행할 작업
3. 현재 발생한 문제
4. 다른 팀원의 확인이나 도움이 필요한 사항
5. Merge 예정 파일과 변경된 인터페이스

코드 의도를 명확하게 표현하기

다른 팀원이 코드를 이해할 수 있도록 함수명과 변수명을 명확하게 작성하고, 복잡한 로직에는 필요한 주석을 추가한다.

단순히 코드의 동작을 설명하는 주석보다 해당 구조를 선택한 이유와 주의해야 할 사항을 기록한다.

AI 코드를 프로젝트 규칙에 맞게 검토하기

AI 사용을 무조건 줄이기보다 생성된 코드를 다음 기준으로 검토한다.

• 기존 클래스 구조와 일치하는가?
• 동일한 기능이 이미 존재하지 않는가?
• 함수명과 변수명 규칙을 따르는가?
• 불필요한 매개변수나 include가 추가되지 않았는가?
• 다른 팀원의 코드와 충돌할 가능성이 없는가?
• 코드의 동작 원리를 직접 설명할 수 있는가?

브랜치와 Merge 절차 개선하기

기능별 브랜치를 적극적으로 활용하고, 정상적으로 작동하는 시점마다 커밋을 남겨 복구 지점을 만든다.

메인 브랜치에서 직접 문제를 해결하기보다 각 팀원이 자신의 브랜치에서 최신 메인 브랜치를 반영하고 충돌을 먼저 해결한 후, 테스트가 완료된 코드를 통합하는 방식을 사용한다.

공통 기능을 초기에 제작하기

UI 출력, 커서 이동, 아스키아트 출력 등 여러 기능에서 반복적으로 사용하는 코드는 프로젝트 초기에 공통 클래스로 제작한다.

공통 함수를 배포할 때는 함수의 역할, 매개변수, 반환값, 사용 예시를 함께 문서화한다.

실행 테스트 체크리스트 만들기

Merge 이후에는 다음 내용을 확인한다.

• 전체 프로젝트가 정상적으로 빌드되는가?
• 게임 시작부터 종료까지 진행할 수 있는가?
• 경험치와 레벨업이 정상적으로 적용되는가?
• 전투 결과와 보상이 정상적으로 반영되는가?
• 콘솔 화면이 밀리거나 잘리는 부분은 없는가?
• 한글과 특수문자가 깨지지 않는가?
• 아스키아트가 정상적인 위치에 출력되는가?
• 입력 대기와 화면 전환이 정상적으로 작동하는가?

철야를 전제로 하지 않는 일정 운영

주어진 시간 안에서 구현할 수 있는 최적의 완성도를 목표로 한다. 일정이 부족할 경우 핵심 기능을 우선 완성하고, 추가 기능의 범위를 조정한다.

Feel — 프로젝트를 마친 소감

과로한 부분은 있었지만 프로젝트 자체는 매우 즐거웠다. 팀원들과 함께 오류를 해결하고 하나의 게임을 끝까지 완성하는 과정에서 협업과 통합의 중요성을 배울 수 있었다.

특히 기능이 개별적으로 작동하는 것과 여러 기능이 결합된 하나의 완성된 게임으로 보이는 것은 다르다는 점을 체감했다. Merge와 구조 설계 과정에서 어려움이 많았지만, 직접 문제를 발견하고 해결한 경험이 이후 프로젝트를 진행할 수 있는 자신감으로 남았다.

2. 개인별 회고

주소리(본인) — UI 및 프로젝트 통합

Keep

FigJam을 활용해 기획 내용과 변경 사항을 바로 문서화한 점은 효과적이었다. 팀원 간 의사소통도 원활했으며, 문제 발생 시 즉시 공유하고 함께 해결할 수 있었다.

Problem

UI는 초기 기획 없이 구현을 시작할 경우 화면별 출력 방식이 달라지고 수정 범위가 커질 수 있다는 점을 확인했다. 또한 아스키아트와 한글 출력을 사용하면서 유니코드와 문자 인코딩 관련 문제가 발생했다.

의사소통이 원활한 팀원들과 함께했기 때문에 별도의 고정 스크럼 없이도 프로젝트를 진행할 수 있었지만, 모든 팀에서 동일한 방식이 가능하지는 않다. 따라서 개인적인 소통 능력이나 팀 분위기에 의존하지 않는 공식적인 소통 체계가 필요하다.

파일 충돌을 메인 브랜치에서 직접 해결하는 과정에서도 불필요한 수정과 재작업이 발생했다. 또한 작업 우선순위를 충분히 협의하지 않아 후반부에 작업이 집중되었고, 철야가 발생했다.

Try

다음 프로젝트에서는 전체 UI 레이아웃과 화면 전환 방식을 초기에 설계한다. 유니코드, 콘솔 문자 집합, 파일 인코딩 방식도 프로젝트 시작 단계에서 통일한다.

아스키아트 출력, 박스 그리기, 커서 이동과 같이 반복적으로 사용하는 함수는 초기에 제작한 후 사용법과 함께 팀원들에게 배포한다.

정해진 시간에 스크럼을 진행하고, 작업 시작 전에 기능의 우선순위를 팀원들과 협의한다. Merge 전에는 각 팀원이 자신의 브랜치에서 최신 메인 브랜치를 반영하고 충돌을 해결한 뒤, 정상 작동을 확인한 코드를 통합한다.

철야를 줄이고 주어진 시간 안에서 구현할 수 있는 최적의 완성도를 만드는 것을 목표로 한다.

이영빈 — 플레이어 시스템 구조

Keep

플레이어와 관련된 기능을 하나의 관리 구조로 통합하려고 고민한 점은 향후 유지보수성과 확장성을 높일 수 있는 방향이었다.

Problem

플레이어 클래스에 상태 데이터와 관련 기능이 과도하게 집중될 경우 클래스의 책임이 지나치게 커질 수 있다. 여러 기능이 플레이어 객체에 직접 접근하면서 코드가 여러 방향으로 뻗는 구조가 만들어질 가능성도 있었다.

브랜치를 충분히 활용하지 않을 경우 기능 수정 과정에서 기존 코드가 손상되거나 복구가 어려워질 수 있다.

Try

플레이어 클래스는 플레이어 객체가 직접 보유해야 하는 데이터와 기본 동작을 담당하도록 구성한다. 플레이어의 상태 출력, 경험치 처리, 장비 적용과 같은 관리 기능은 별도의 PlayerManager에서 담당하는 구조를 검토한다.

각 시스템이 서로 직접 참조하는 구조를 줄이고, 시스템 사이의 요청을 중계하는 매니저나 인터페이스를 설계한다.

기능별 브랜치를 적극적으로 활용하고, 하나의 함수에 여러 책임이 집중되는 문어발식 코드를 줄인다.

아트, 음악 등 제작 비용이 큰 비프로그래밍 리소스에는 생성형 AI를 적극적으로 활용하되, 저작권과 사용 조건을 확인하고 프로젝트의 전체 콘셉트에 맞게 수정한다.

정윤재 — 인벤토리·상점·강화·제작 시스템 및 게임 기획

Keep

인벤토리, 상점, 강화소, 제작소 등 여러 시스템을 연결하면서 기능 간 데이터 전달과 클래스 의존 관계를 직접 경험했다.

게임의 핵심 메시지를 ‘코더여, 성장하라’로 설정하고, 스토리와 시스템이 동일한 메시지를 전달하도록 구성하려고 한 점도 의미가 있었다. 이는 광고, 홍보, 게임 콘텐츠 등 여러 요소가 일관된 메시지를 전달하는 IMC 관점과도 연결할 수 있다.

Problem

함수의 매개변수가 Player* player, Inventory& inventory와 같이 여러 개로 늘어나면서 다른 클래스와 파일을 참조해야 하는 상황이 많아졌다. 이 과정에서 include 누락, 전방 선언, 타입 불일치 등 여러 오류가 발생했다.

기존 템플릿 인벤토리를 설계할 때 장착 아이템까지 충분히 고려하지 않아 이후 장비창과 전용 장비 인벤토리를 별도로 구현해야 했다. 초기 설계가 부족해 기능이 추가될수록 구조가 복잡해졌다.

현재 게임의 주요 소재가 내일배움캠프 언리얼 10기 구성원에게 맞춰져 있어, 다른 사용자가 게임을 플레이할 경우 상황과 유머에 공감하기 어렵다는 한계가 있다.

Try

함수를 작성하기 전에 반드시 필요한 매개변수인지 검토하고, 여러 객체를 반복적으로 전달해야 한다면 해당 객체를 관리하는 상위 매니저나 컨텍스트 구조를 도입하는 방안을 고려한다.

인벤토리를 설계할 때 일반 아이템, 소비 아이템, 장착 아이템, 장착 슬롯, 강화와 제작 기능까지 확장될 가능성을 먼저 검토한다. 세부 기능을 구현하기 전에 전체 클래스 구조와 데이터 흐름을 먼저 설계한다.

게임의 소비층을 특정 교육 과정 참여자뿐만 아니라 코딩을 처음 배우는 사용자 전체로 확장한다. 이를 위해 특정 기수나 내부 상황에만 의존하는 표현을 줄이고, 초보 개발자라면 공감할 수 있는 오류, 과제, 디버깅, 성장 경험을 중심으로 스토리를 개편한다.

박성빈 — 전투 시스템 및 브랜치 관리

Keep

전투 시스템에 새로운 기능을 추가할 때 GitHub Desktop에서 별도의 브랜치를 생성하고, 정상적으로 작동하는 시점마다 커밋을 남겨 복구 지점을 만든 점이 효과적이었다.

오류가 발생하더라도 이전의 정상 상태로 쉽게 돌아갈 수 있어 수정에 대한 부담을 줄일 수 있었다.

Try

앞으로도 기능별 브랜치를 사용하고, 하나의 기능이 정상적으로 작동하는 시점마다 의미 있는 커밋을 남긴다.

커밋 메시지에는 변경한 기능과 확인해야 할 사항을 구체적으로 작성하고, Merge 전에는 해당 브랜치에서 빌드와 실행 테스트를 완료한다.

장우혁 — 경험치 및 레벨업 시스템

Keep

GainExp 함수에서 외부로부터 전달받은 경험치를 현재 경험치에 누적하고, while문을 사용해 한 번에 여러 레벨이 상승하는 경우에도 레벨업이 누락되지 않도록 구현했다.

또한 클래스 간 순환 참조를 방지하기 위해 전방 선언을 활용했다.

콘솔 출력이 너무 빠르게 넘어가 확인하기 어려운 경우 입력 대기나 일시정지 기능을 사용해 출력 내용을 확인할 수 있도록 한 시도도 효과적이었다.

Problem

Merge 과정에서 경험치와 레벨업 관련 코드가 일부 누락되거나 연결이 변경되면서 프로젝트는 빌드되지만 실제 게임에서 레벨업 메시지나 기능이 나타나지 않는 문제가 발생했다.

오류를 수정한 뒤 빌드 성공 여부만 확인하고 실제 게임 흐름을 충분히 테스트하지 않아 문제를 늦게 발견했다. 이후 게임을 처음부터 반복 실행하며 경험치 획득과 레벨업 과정을 하나씩 확인해야 했다.

Try

Merge 전후에 경험치와 레벨업 관련 함수의 선언, 정의, 호출부가 모두 정상적으로 연결되어 있는지 확인한다.

오류를 수정한 뒤에는 반드시 다시 빌드하고, 게임을 직접 실행해 다음 사항을 검증한다.

• 경험치가 정상적으로 누적되는가?
• 한 번에 여러 레벨이 상승하는가?
• 레벨업 보상이 정상적으로 적용되는가?
• 레벨업 메시지가 화면에 출력되는가?
• 콘솔 출력이 밀리거나 사라지지 않는가?
• 한글과 아스키아트가 깨지지 않는가?

빌드 성공은 문법과 연결 오류가 없다는 의미일 뿐, 기능이 정상적으로 작동한다는 의미는 아니라는 점을 항상 인식한다.

Feel

이번 프로젝트를 통해 Merge 과정에서 예상보다 많은 충돌과 기능 누락이 발생할 수 있다는 점을 체감했다. 오류를 모두 수정한 것처럼 보여도 실제 실행 과정에서는 추가 문제가 나타날 수 있으므로, 빌드 이후의 플레이 테스트가 반드시 필요하다는 것을 배웠다.

이미르 — 몬스터 및 전투 시스템

Keep

몬스터 시스템을 처음부터 끝까지 구현하고 지속적으로 수정했다. 정예 몬스터가 각 챕터에서 한 번씩만 등장하도록 조건을 구성했으며, 최종 보스전을 두 명의 매니저와 보스가 대결하는 2대1 전투 구조로 구현했다.

팀원들과 적극적으로 소통하며 오류를 함께 해결했고, 발표를 통해 프로젝트와 자신이 구현한 기능에 대한 자신감을 얻었다.

Problem

Merge 과정에서 충돌과 오류가 많이 발생했다. 함수의 선언, 정의, 호출부에서 매개변수가 서로 일치하지 않는 문제가 있었으며, 동일한 함수가 중복으로 작성되어 오류가 발생하기도 했다.

시작 화면과 이후 화면의 UI가 통일되지 않았으며, 세부 기능 구현에 집중한 나머지 전체 구조를 충분히 기획하지 못했다.

Try

다음 프로젝트에서는 세부 기능을 구현하기 전에 전체 클래스 구조와 데이터 흐름을 먼저 정리한다.

함수의 매개변수를 최소화하고, 반복적으로 전달되는 데이터는 매니저나 별도의 데이터 구조를 통해 관리한다.

UI 출력 기능을 별도의 클래스로 분리하고, 모든 화면이 동일한 규칙으로 출력되도록 구성한다.

변수명과 함수명 규칙을 사전에 정하는 것에 그치지 않고, 코드 리뷰 과정에서 실제로 규칙이 지켜지고 있는지 확인한다.

전투 시스템을 확장할 경우 다음과 같은 기능도 시도한다.

• 파티 시스템
• 공격 빗나감과 명중률
• 상태 이상
• 캐릭터별 역할 구분
• 행동 순서와 우선순위
• 자원 관리가 필요한 전략적 전투

Feel

이번 프로젝트를 통해 기능이 정상적으로 작동하는 것과 게임이 완성도 있게 보이는 것은 서로 다른 문제라는 점을 느꼈다.

초보자로서 Merge와 전체 구조 설계가 어려웠지만, 실제로 오류를 경험하고 직접 해결하면서 많은 것을 배울 수 있었다. 팀원들과 소통하며 프로젝트를 끝까지 완성한 경험이 다음 프로젝트에 도전할 수 있는 자신감으로 남았다.

3. 종합 결론

이번 프로젝트의 가장 큰 강점은 적극적인 의사소통과 문제 해결 태도였다. 팀원들은 자신의 담당 기능에만 머무르지 않고, 문제가 발생하면 함께 원인을 찾고 해결했다.

반면 가장 큰 개선 과제는 초기 구조 설계, 일정 관리, 코드 통합 절차였다. 개별 기능은 정상적으로 구현되었지만, 여러 기능을 하나의 프로젝트로 통합하는 과정에서 클래스 의존성, 함수 인터페이스, UI 일관성, 실행 테스트 문제가 나타났다.

다음 프로젝트에서는 다음 원칙을 우선적으로 적용한다.

1. 구현 전에 전체 구조와 데이터 흐름을 먼저 설계한다.
2. 핵심 기능과 추가 기능의 우선순위를 구분한다.
3. 일정에 Merge, 테스트, 수정 시간을 별도로 포함한다.
4. 정기적인 스크럼을 통해 변경 사항과 문제를 공유한다.
5. 공통 함수와 코딩 규칙을 초기에 확정한다.
6. AI가 작성한 코드도 팀의 구조와 규칙에 맞게 직접 검토한다.
7. Merge 전후에 빌드뿐만 아니라 실제 플레이 테스트를 진행한다.
8. 철야를 전제로 하지 않고 지속 가능한 작업 범위를 설정한다.

이번 프로젝트는 단순히 게임 기능을 구현한 경험을 넘어, 협업 개발에서 설계와 소통, 버전 관리, 통합 테스트가 얼마나 중요한지를 학습한 프로젝트였다.

난리도 아닙니다. 그래도 어떻게 머지 완료.

유니코드 관련 오류도 종종 보이네요. 어떤 멋진 분께서 한번에 인코딩 설정을 바꾸는 법을 알려주셨습니다. 전 왜 하나 하나 바꾸었을까요? 이제라도 알게되어 다행인 일입니다.

그래도 오류가 몇 개 뜹니다마는 141개 보다가 24개 보니 천사같군요.

근데 뭐 보통 하나 해결되면 주르륵 해결되는 경우도 있던데 그걸 바라봅니다. 라고 생각하던 찰나 구원투수가 커밋을 해줍니다.

대부분의 오류가 해결되었고 고난과 역경란에 한 획을 그었습니다.

빌드가 됩니다! 아주 잘된 일입니다. 짐만 실으면 끝입니다. 정말로. UI 작업 레츠고.

아스키아트는 줄바꿈이나 간격으로 인해 발생하는 오류가 잦습니다. 따라서 유지보수를 위해 아트를 따로 txt파일로 분리하고, 이걸 읽게 하기 위한 매니저를 만드는 게 좋겠습니다. 이렇게 할 경우 아트 변경 시 메모장만 변경하면 됩니다. 일단 공유문서를 먼저 배포해버립시다. 이제 만들기만 하면 됩니다. 할 수 있겠지?

물론 아직 코드 창조를 하기엔 제게 인풋된 정보가 없으므로 AI에게 얼개를 요청하고 채워나갔습니다.

우선 헤더부터. 텍스트 파일을 여는 함수를 멋있게 선언해 줍니다. 구차할 정도로 각주를 달아줍시다.

그리고 메인에 넣어 파일 경로가 잘 되어 있는지 확인합시다. 경로는 문제가 없지만 제가 선택하지 않은 멋진 글씨가 나열됩니다.

그래요, 소스 파일 저장 인코딩(UTF-8 or CP949)과 콘솔의 코드페이지가 달라 생기는 문제라는군요. 아직 나약한 저로서는 매일 매일이 새롭고 놀라운 오류들입니다. 각 잡고 관련 설정 공부 해야겠습니다만, 일단 급한 마감부터 하죠.

유니코드는 네게 아직 이르다는 말을 AI에게 듣고 할수 있는 일을 하기로 합니다. 비주얼 스튜디오 2022에는 고급 저장 옵션이 기본세팅되어 있지 않으므로 사용자 지정에서 고급 설정을 불러옵니다.

경로 찾기가 어렵네요. 찾았다.

모든 cpp파일을 이렇게 저장해주면 된다고 하는군요. 하하. 모든... 파일을... 비합리적이다. ? 과거로 돌아가야 할까요.

해치웠나? 라고 생각했는데 경고가 2천개 뜨더군요. 위의 구성과 플랫폼을 '모든'으로 바꾸면 2개만 남습니다. 전 짱입니다.

저 두개도 그냥 제가 확인 못한 파일을 UTF-8로 바꿔주지 않아 생긴 문제였습니다. 해결해결!!

다음엔 그냥 유니코드도 도전해보지요. 일단 나오긴 하지만 약간의 틀어짐이 보입니다. https://github.com/naver/d2-coding-font 여기서 폰트를 설치해보지요.

사용해야하는 system() 은 int를 직접 해석하지 못한다고 합니다. 고로 숫자 120을 문자열로 변경해야 합니다. 문자열 명령어가 들어가야 하는 부분입니다.

근데 이거 뭔가 아마추어인 제가 보기에도 못생기고 투박하지 않나, 하는 생각이 듭니다. 좀 더 깔끔한 방법이 없나...

일단은 추후에 수정해보기로 하고 급한 일부터 해봅시다.

우선 매인을 시원하게 밀었습니다.

이것만 테스트를 해보고 싶은데 현재 다른 파일이 꼬여 있어 실행 오류가 뜨는군요.

테스트 파일을 팝시다.

좋아요. 잘 작동 됩니다.

좌표 변경도 잘 되는 걸 볼 수 있습니다. 뿌듯한 일입니다.

그리고 텍스트가 너무 빠르게 나오는 듯 해서 Slow_Print 함수를 추가했습니다.

각주도 잘 달아준 뒤 팀원분들께 안내도 드렸습니다. 야호.

이런식으로 나오는 걸 볼 수 있군요. 상태창 같은 걸 제외하고 스토리라인은 이렇게 연출하는 게 좋아보입니다.

텍스트로만 이루어진 아트의 유지보수가 쉽기 위해선 어떻게 해야 할까요? 우선 초기 콘솔 세팅이 중요할 겁니다.

콘솔 크기 고정 화면 지우기 커서 이동 아스키 출력 입력 대기

고로 이것부터 한 뒤 커밋하고 아트를 넣는 게 좋은 방향일 것으로 판단됩니다. 레츠고.

콘솔 크기를 고정하기 위해서는 필요한 헤더 파일이 있습니다.

#include <windows.h>

• Windows.h는 콘솔 API를 사용하기 위한 헤더로, 콘솔 화면 제어를 위해 필요합니다.

우선 임시로 크기를 설정해줍시다. 여기서 cols : 가로 문자 개수 lines : 세로 줄 개수 입니다.

보통 이 사이즈면 아트가 들어가기에 적합하다고 합니다만 추후에 생성할 아트에 맞추어 수정하기로 합니다. 다만 진짜 API를 이용하는 게 아니라 흉내만 내는 거라고 하더군요. 필요하면 나중에 Windows API로 실제 화면 크기 대응 개선하는 게 맞다고 합니다만...

라는 의문이 생기지 않을 수가 없군요. 지금으로선 필요 없지만 추후에는 필요한 듯 하네요. 우선 의문은 일단락 하고 마저 진행하겠습니다. 잊지 말고 커밋.

그렇지만 생각해보니 클래스로 관리하는 게 협업 특성상 더 적합지 않나 하는 생각이 들어 급히 콘솔 매니저를 만들었습니다.

공유 페이지에 추가도 하고 클래스 목록에도 추가 했습니다. 처음 만들어보는 애다 보니 각주를 열심히 달아주었습니다. 나중에 팀원분들께도 보시기 편하시면 좋겠군요. 혹은 저의 아마추어미에 놀라실지도. 하하.

아무튼, 이후에 작업한 branch를 merge하게 되었습니다. 만... 고난과 역경이 끊이지 않아 피그잼에 고난과 역경란을 만들었습니다. 더불어 일 하다가 팀원에게 무언가를 요청할 수 있는 페이지도 팠습니다. 피그잼은 정말 좋은 툴입니다.

아무튼, 이후 폭탄을 해제했다고 믿을 찰나, 파일을 열어보니 작업한 파일이 보이지 않습니다. 하하.

어제 나름대로 Git-boom이란 레포지터리를 파가며 연습했습니다만 실전에서 생기는 문제는 역시 있군요.

그렇지만 완성하고야 말겠습니다. 저를 죽이지 못한 오류는 절 더 강하게 해줄 뿐입니다.

...그러길 바랍니다.

필수 과제를 개인의 역량 및 선호에 맞춰 역할을 분배하고 비교적 난이도가 낮은 경우 디벨롭 방향을 논의 했습니다. 이후 코드 규약을 논의 및 정돈해 확정 짓고 공통 일정의 얼개를 공유했으며 간단하게 로직을 작성했습니다. 코멘트 또한 자유롭게 달며 기획과 규약을 정돈할 수 있었습니다.

추후에 불러오는 닉네임이 다릅니다. 당연합니다.

다른 객체를 넣었으니 말이지요. 이렇게 넣으면 뜰 듯 하네요. 해결.

이제 가상함수를 쓸 생각에 가슴이 떨립니다.

정말 바로 에러가 뜨는군요. 하긴 그냥 해도 나는 에러이니, 확정적으로 난다고 했으면 날만 합니다.

그래요. 일단 Player는 버츄얼이 되어버렸습니다. 이제 이걸 상속받을 전사를 만들어 줍시다.

그 이전에 아주 중요한 걸 알았습니다. 항상 헤더 파일을 생상할 때마다 마주하던 친구입니다.

#pragma once : 중복 포함 방지 장치

• 헤더 파일이 여러 번 include되어도 문제가 생기지 않게 막는 장치가 필요
• 같은 설계도를 여러 번 책상 위에 올려도, 실제로는 한 번만 참고하게 하는 표시

라고 합니다. Include Guard라는 전통적인 방식도 있군요.

#ifndef WARRIOR_H #define WARRIOR_H // Warrior 클래스 선언 #endif

이런식으로 진행한다고 합니다. 의미는

WARRIOR_H가 아직 정의되지 않았다면 지금 이 파일 내용을 읽고 WARRIOR_H를 정의해서 다음부터는 다시 읽지 않게 함

이런식인가 보군요. 약간 std::과 using namespace std;를 보는 기분입니다. 저는 야비하게 편한 걸 써보겠습니다.

나는 Player를 기반으로 만들어진 클래스라는 선언도 해주었습니다. 여기에 attack함수를 넣어주면 수정이 가능해지겠죠?

cpp를 작성하러 가봅시다. 이제 초록 스파게티 면은 덜 두려운 기분이 듭니다.

무언가 많이 잘못되었습니다.

목표 흐름은 이렇습니다.

Warrior 생성자 → Player 생성자 호출 → Warrior 전용 직업 값 설정 → attack() 구현

Player 생성자 호출을 어떻게 하는지 모르겠군요.

: Player(name, hp, mp, power, defence)

이걸 현재 함수 뒤에 덧붙이는 형식으로 호출을 한다고 합니다.

= 이건 그냥 뼈란다. 응당 뼈와 피와 살이 있어야 마땅한데 피와 살은 어디있니. 로 들리는 건 기분 탓일 겁니다.

새롭게 알게된 지점 중 하나는 using namespace std; 이 편리하긴 하지만 std::string 가 실무에서 더 많이 쓰인다는 겁니다. 이 이름이 어디에서 온 것인지 명확하게 보여주기 때문이라고 하는군요.

근데 이렇게 하고 보니 확실히 가상함수 부분이 와닿습니다. 언리얼이랑 연결해서 생각해보니 더 연상이 편하기도 하군요.

이제 그럼 가상소멸자 파트입니다.

가상소멸자? 부모 포인터로 자식 객체를 삭제할 때 자식의 정리 과정까지 제대로 실행되게 하려고 필요

Player가 “공통 캐릭터 계약서”이며 Warrior가 실제 캐릭터라고 생각합시다. 게임이 끝나서 캐릭터를 정리할 때, 겉으로는 Player로만 보고 있더라도 실제 안에는 Warrior일 수 있습니다. 이때 소멸자가 가상이 아니면: “Player 부분만 정리하고 끝” 처럼 동작할 수 있지만 가상 소멸자가 있으면: “실제 객체가 Warrior였네? 그럼 Warrior 정리부터 하고 Player도 정리하자” 라는 흐름이 된다고 합니다.

핵심 개념 Player 타입으로 Warrior를 가리킴 나중에 그 객체를 삭제함 이때 실제 객체인 Warrior의 소멸자도 호출되어야 함 그래서 부모 클래스인 Player의 소멸자에 virtual을 붙임

정리 Player처럼 상속의 부모로 쓰이는 클래스라면 가상 소멸자를 두는 것이 안전.

• 자식 객체의 소멸자가 제대로 호출됨
• 동적 메모리 정리가 안전해짐
• 다형성을 사용하는 클래스에서 기본적으로 권장됨

형식에 맞게 Player.h에 잘 추가해 둡니다.

직업을 선택할 수 있게끔 함수 작업을 해봅시다. 이전 Upgrade 함수를 응용해서 만들어 봅니다.

실행은 되지만 오류가 사라지지 않습니다. E0308코드... 알고보니 헤더 오류였습니다. 하하. include를 상시 확인합시다.

그리고 이렇게 몬스트 초기화를 해두면 몬스터 추가가 어려워지므로 이렇게 값을 비워두는 게 범용성에서 낫겠습니다.

그리고 main에서 이렇게 불러주면 슬라임이 생성됩니다. 이제 객체화에 조금은 익숙해졌습니다.

각설하고 작업을 개시합시다. 이번엔 직업(자식)들이 상속받을 Player(부모) 클래스를 만들어야 합니다. 상속 + 다형성 + 생성자 초기화를 연습할 수 있는 절호의 기회!

앞서 작성했던 인벤토리 클래스와 다르게 여기선 protected를 써줍시다. 그래야 추후에 자식 클래스에서 수정이 가능합니다.

private → Player 내부에서만 접근 가능 protected → Player와 자식 클래스에서 접근 가능

일단 클래스 선언 1차가 완성되었습니다.

그리고 이렇게 하면 안되는 것 같죠? 매개변수로 받은 hp, mp, power, defence를 멤버 변수에 넣는 방식으로 가야 하는데, 여기서 문제는 매개변수와 멤버 변수 이름이 같다는 지점입니다. 이를 구분하기 위해 this->를 사용해줍니다.

this->hp = hp; 왼쪽은 멤버 변수, 오른쪽은 매개변수

스파게티가 말끔히 없어졌습니다.

다만 this 개념이 햇갈리니 다시 정리하겠습니다.

this->name = name; = 이 객체가 가진 name 멤버 변수에 생성자로 들어온 name 값을 넣어라

먼 옛날에 언리얼을 처음 만지작 거릴 무렵, get과 set의 개념 이해가 제법 어려웠습니다. 보기에 get은 그냥 어디에 붙이는 것 같았고, set은 중간에 실행핀에 기워져 기능할 때가 많았다 정도만 직관적으로 알았지만, 이게 본질적으로 어떻게 다른가에 대해 설명하라면 설명할 수 없었습니다. 깊이 있게 이해하기엔 당자 마감이 급해 미뤘지만 이번 기회에 이 불쾌한 인지오류를 해결하고 확정지을 수 있을 듯 합니다.

getter

• 값을 읽어오는 함수
• setter*
• 필요한 값들을 바꾸는 함수 특히 자식 클래스나 외부에서 스탯을 조정할 때 사용 가능

이러니 언리얼에서 왜 그렇게 쓰였는지 이해가 갑니다.

선언을 해줍니다. 틀려서 고쳤습니다. 이렇게 쓰는게 맞군요. get은 앞에 자료형을, set은 받을 변수를 적어야 합니다. 이제 좀 get/set이 와닿습니다.

근데 그러고 보니 생성자에 레벨이나 직업은 지금 안 넣어도 되나 헷갈립니다.

레벨은 그냥 처음에 1로 초기화 하고, 직업은 자식 클래스에서 변경하는 방향이 합리적일 듯 합니다. 나중에 자식 클래스를 만들면서 보완하도록 하고 넘어가죠.

이렇게 선언을 마쳤으나 printPlayerStatus는 매개변수가 없어도 된다고 합니다. 멤버 함수는 같은 클래스 안의 멤버 변수에 직접 접근할 수 있기 때문에, 상태 출력 함수가 굳이 job, level을 매개변수로 받을 필요가 없기 때문이라고 하는군요.

그러면 유사했던 Inventory.h를 같이 살펴보면 좋을 것 같습니다.

여기선 int ItemType이 새로은 매개변수 선언이기 때문에 적었었군요.

이어서 Play.cpp에서 함수를 정의해보겠습니다. 왜 스파게티?

setName은 선언처럼 세미콜론을 붙이면 안 되고, 함수 몸통을 바로 써야 해요.

아. 바로 바꾸어 주었습니다.

근데 작업하다보니 레벨은... set하면 안되지 않나 싶었습니다. 그러니까 public에 얘가 있으면 사용자가 접근 가능한 거 아닌가?

좋은 방향을 알게 되었습니다. 7세 아동이 되어 무수한 질문으로 부모님을 귀찮게 구는 기분입니다. 하지만 AI는 감당해주시겠죠?

1. 헤더의 using namespace std;는 빼는 게 좋다

• 헤더는 여러 .cpp에서 포함될 수 있어서 std 전체를 강제로 열어버리면 이름 충돌 가능성이 높아집니다. 따라서 직접 써주는 방향이 맞다고 합니다.
• 2. 클래스 정의도 헤더 파일에 할 것*
• 헤더 파일에 클래스 정의를 두고 cpp에는 함수 정의를 두는 게 맞습니다.

파일을 분리하는 게 생각보다 오래 걸리는군요. 뭘 어디에 두어야 하는지 햇갈리는 것 같습니다.

일단 제가 정리한 방향은

• Item.h에 Item구조체 정의

• Inventory.h에서 Item.h를 include

하는 방향입니다. 지금 당장은 안 쓰지만 우선은 해둡시다.

추가로 알게 된 사항

• 함수 이름은 동사형으로
• 생성자는 딱 한번 호출되는 함수로 초기값을 세팅할 수 있음 Inventory.h → “생성자가 있다”라고 선언 Inventory.cpp → “처음 만들 때 포션을 5개로 세팅한다”라고 구현

여기서 고민되는 지점은 case와 인벤토리에서 아이템 선택하는 걸 어떻게 연결할 것인가인데요...

Inventory.cpp에서 이렇게 조건을 세우고

호출해주었습니다.

작동을 잘 하는지 보려는데 컴파일 오류가 발견됩니다.

메인 헤더에 인벤토리를 적지 않았군요 인벤토리 헤더도 include 해주고 선언도 추가해 줍시다.

빌드 성공이라는 문구는 왜이리 가슴 설렐까요.

콘솔에서도 문제가 없습니다!

아주 만족스럽습니다. 7할 정도는 AI의 힘을 빌렸을지언정 2할 정도는 제가 했다고 믿습니다. 나머지 1할은 기능 구현 가이드에게 드립니다.

그렇지만 자랑스러워하고 있으면 버그가 찾아오기 마련입니다.

HP 포션이 하나 남은 듯 한데, MP 포션이 0개라 사용이 불가하군요.

이 조건을 수정해야할 듯 합니다. 저는 HP 포션이 0이어도, MP 포션이 0이어도 포션 부족을 출력하길 바랐는데 다시 생각해보니 둘 중 하나만 0이면 무조건 포션 부족이 뜨는 조건이군요. 이렇게 바꿔주었습니다.

문제 해결!

코드를 작성하기에 앞서 생각해보면 좋을 지점이 있습니다. 지금 구현만 보았을 때는 강화 함수 내에서 포션 갯수 변수를 만들 수는 있습니다. 다만 전체 흐름을 생각하면 나중에 포션을 따로 제작하기도 하고 인벤토리도 구현해야 하므로 포션 갯수를 item.cpp에서 인벤토리와 함께 관리하는 방향이 낫지 않을까 합니다.

이 방향성을 ai와 논의해보자 좀 더 나은 방향이 제시되었습니다.

Inventory 어떤 아이템을 몇 개 가지고 있는지 관리 아이템이 있는지 확인 사용하면 개수 감소

Item 아이템의 이름, 종류, 효과 같은 정보 관리

이렇게 구분하는 게 나중에 추가될 아이템을 고려해보았을 때 나을 듯 합니다. 그럼 포션이 필요한 강화라면 인벤토리에 사용을 요청하는 방향으로 가보겠습니다.

인벤토리 설계는 나중 스탭에 있으니 일단 초기 작업만 해두겠습니다.

주어진 구현항목은 다음과 같습니다만, 앞선 단계이니 살짝만 건들여보겠습니다.

구현 항목

• Item 구조체 정의하기: name, price, void PrintInfo() const
• #include <vector> 추가하기
• vector<Item> inventory 선언하기
• 전투 승리 시 inventory.push_back(droppedItem) 연결하기
• 메인 메뉴 추가하기: 1. 던전 / 2. 인벤토리 / 0. 종료
• 인벤토리 메뉴에서 range-for로 전체 아이템 출력하기

우선 구조체를 선언했습니다.

*구조체 선언? *

• 새로운 자료형을 만드는 행위
• main 함수 전에 작성
• 양식 struct 구조체 이름 { 자료형 변수이름; 자료형 변수이름; 반환형 함수이름() const {

    // 함수 내용

  } };

이라기는 합니다. 다만 main에 넣으면 길어질 것 같군요. Item.cpp나 inventory.cpp에 선언해서 호출할 수 있으면 좋겠습니다. 혹은 다른 방법이 있는지 알아보겠습니다.

드디어 class를 한번 써보지요. class를 선택한 이유는 아래와 같습니다.

클래스로 묶기 좋은 경우 다음 중 2개 이상 해당하면 클래스를 고려

• 관련된 데이터가 여러 개 있다 예: 체력, 공격력, 위치, 이름
• 그 데이터를 사용하는 함수가 여러 개 있다 예: 이동하기, 공격하기, 데미지 받기
• 같은 구조의 대상을 여러 개 만들고 싶다 예: 몬스터 여러 마리, 학생 여러 명, 아이템 여러 개
• 데이터를 함부로 바꾸면 위험하다 예: 체력이 음수가 되면 안 됨

앞으로도 인벤토리나 포션은 계속 호출될 것이기 때문에 초장에 class로 묶어주겠습니다. class를 처음 써봐서 설레는군요. 마주할 오류에 가슴이 뜁니다.