Client Side

[AFO_Refactor #1] Critical 버그 수정 - AnimNotify 권한 누락, Aurora 오타, 팀 비교 반전

Client Side — Wed, 10 Jun 2026 17:17:22 +0900

AFO_Refactor 개발일지 #1

Critical 버그 수정

AnimNotify 권한 누락 · Aurora 오타 · 팀 비교 반전 · BeginPlay 중복 호출 · 인코딩 변환

이번 작업 목표

#0에서 분석한 버그 목록 중 코드 수정으로 즉시 해결 가능한 것들을 먼저 정리했다. GAS 도입 전에 기존 코드의 명백한 오류들을 제거해야 리팩토링 기반이 안정적으로 잡힌다.

이번에 수정한 항목은 총 5개다.

#	버그	등급	파일
1	AnimNotify_AttackHit HasAuthority 누락	Critical	`AFAnimInstance.cpp`
2	AFAurora::StopSprint Super 오타	Critical	`AFAurora.cpp`
3	Multicast_NotifyDamage 팀 비교 반전	High	`AFAttributeComponent.cpp`
4	BeginPlay InitializeCharacterData 중복 호출	High	`AFPlayerCharacter.cpp`
5	소스 파일 인코딩 CP949 → UTF-8 with BOM	Medium	33개 파일

Fix 1 — AnimNotify_AttackHit HasAuthority 누락

문제

AnimNotify는 애니메이션이 재생되는 모든 클라이언트에서 발동된다. 멀티플레이에서 캐릭터 애니메이션은 Multicast로 모든 클라이언트에 복제되기 때문에, AnimNotify도 서버 + 모든 클라이언트에서 동시에 실행된다.

그런데 기존 코드는 권한 체크 없이 바로 DealDamage()를 호출하고 있었다.

BEFORE

void UAFAnimInstance::AnimNotify_AttackHit()
{
    if (auto Owner = TryGetPawnOwner())
    {
        if (auto Character = Cast<AAFPlayerCharacter>(Owner))
        {
            Character->DealDamage();  // HasAuthority() 체크 없음!
        }
    }
}

원인

DealDamage()는 내부에 HasAuthority() 가드가 있지만, 클라이언트에서 호출 자체가 되면 Dedicated Server 환경에서 불필요한 실행 경로가 생긴다. 특히 DealDamage() 내부 가드가 없는 버전이 혼재할 경우 크래시로 이어진다.

근본 원칙은 "서버 전용 함수는 진입부에서 차단"이다. 내부에서 막는 것보다 외부에서 먼저 막는 게 안전하다.

AFTER

void UAFAnimInstance::AnimNotify_AttackHit()
{
    APawn* Owner = TryGetPawnOwner();
    if (!Owner) return;
    if (!Owner->HasAuthority()) return;  // 서버에서만 실행

    AAFPlayerCharacter* Character = Cast<AAFPlayerCharacter>(Owner);
    if (!Character) return;

    Character->DealDamage();
}

Fix 2 — AFAurora::StopSprint Super 오타

문제

오로라 캐릭터의 StopSprint()에서 부모 함수를 잘못 호출하고 있었다. Super::StopSprint를 호출해야 하는데 Super::StartSprint를 호출하고 있었다.

BEFORE

void AAFAurora::StopSprint(const FInputActionValue& Value)
{
    Super::StartSprint(Value);  // ← StopSprint인데 StartSprint 호출
    bIsSprinting = false;
}

결과

스프린트 키를 떼면 부모의 StartSprint가 실행된다. StartSprint는 MaxWalkSpeed를 스프린트 속도로 올리는 함수이므로, 키를 떼도 빠른 속도가 유지된다. bIsSprinting = false로 플래그만 내려가고 실제 이동 속도는 복원되지 않는 버그.

AFTER

void AAFAurora::StopSprint(const FInputActionValue& Value)
{
    Super::StopSprint(Value);  // 수정
    bIsSprinting = false;
}

교훈: 캐릭터 파생 클래스가 늘어날수록 이런 복사-붙여넣기 오타가 발생하기 쉽다. 이 문제는 이후 포스팅에서 다룰 Interface 도입으로 근본적으로 해결할 예정이다. bIsSprinting을 베이스 클래스로 올리면 파생 클래스에서 이 함수를 override할 필요 자체가 없어진다.

Fix 3 — Multicast_NotifyDamage 팀 비교 반전

문제

데미지 수치 UI의 색상이 반대로 표시되고 있었다. 적을 때리면 아군 색상, 아군을 때리면 적 색상으로 뜨는 버그.

BEFORE

// 같은 팀 공격 = 적 데미지로 표시 (반전)
if (MyPS->GetTeamID() == InstigatorPS->GetTeamID())
{
    bIsEnemyDamage = true;
}

AFTER

// 다른 팀(적) 공격 = 적 데미지로 표시 (정상)
if (MyPS->GetTeamID() != InstigatorPS->GetTeamID())
{
    bIsEnemyDamage = true;
}

Fix 4 — BeginPlay InitializeCharacterData 중복 호출

문제

팀 작업 중 병합 과정에서 동일한 블록이 두 번 들어간 것으로 추정된다. DataTable에서 캐릭터 데이터를 로드하는 함수가 BeginPlay()에서 두 번 실행됐다.

BEFORE

void AAFPlayerCharacter::BeginPlay()
{
    Super::BeginPlay();

    if (!CharacterKey.IsNone())
    {
        InitializeCharacterData(CharacterKey.ToString());  // 1번째
    }

    if (!CharacterKey.IsNone())
    {
        InitializeCharacterData(CharacterKey.ToString());  // 2번째 (중복)
    }
    ...
}

결과

DataTable 로드가 두 번 실행되면서 CharacterSkills 배열이 Empty() 후 다시 채워지는 과정이 반복된다. 부작용이 숨어있는 코드다. 두 번째 블록을 제거해서 정리했다.

Fix 5 — 소스 파일 인코딩 CP949 → UTF-8 with BOM

문제

팀원들이 Windows 한국어 환경에서 작성한 파일들이 CP949(EUC-KR 계열) 인코딩으로 저장되어 있었다. BOM이 없는 상태라 UTF-8 기반 도구에서 한글 주석이 모두 깨져 보였다.

// ❌ CP949 - UTF-8 도구에서 깨짐
// ¼¹ö Àü¿ë: ½Ã°£ ¼³Á¤
void AAFGameState::SetRemainingTime(int32 NewTime)

해결

총 33개 파일(15 .cpp + 18 .h)을 UTF-8 with BOM으로 일괄 변환했다. UE5 MSVC 환경은 UTF-8 with BOM을 표준으로 처리하므로 컴파일에 영향 없다.

UTF-8 with BOM vs UTF-8 without BOM
UE5 C++ 프로젝트에서는 BOM이 있는 UTF-8을 권장한다. BOM이 없으면 MSVC가 시스템 코드페이지(한국: CP949)로 파일을 해석해 한글이 깨질 수 있다.

이번 작업에서 배운 것

AnimNotify의 실행 컨텍스트를 항상 의식해야 한다.

AnimNotify는 애니메이션이 재생되는 모든 머신에서 실행된다. Multicast로 복제된 몽타주라면 서버 + 전체 클라이언트에서 동시에 발동된다. 게임 로직(데미지, 스폰 등)은 반드시 HasAuthority()로 서버에서만 처리해야 한다.

팀 프로젝트 코드에는 병합 잔재가 남아있다.

중복 호출, 오타, 인코딩 문제는 모두 팀 작업 과정에서 발생한 전형적인 잔재다. 리팩토링 첫 단계에서 이런 것들을 먼저 정리해야 이후 구조 개선 작업이 안정적으로 진행된다.

다음 포스팅

[AFO_Refactor #2] Cast 체인 → Interface 교체

매 프레임 DarkKnight/Mage/Aurora Cast 3번을 Interface로 교체. bIsSprinting을 베이스 클래스로 올려서 파생 클래스 override 자체를 제거하는 구조 개선.

C++ STL stack / queue 완전 정리 — LIFO vs FIFO 실전편

Client Side — Tue, 9 Jun 2026 21:59:39 +0900

코딩테스트 준비 #2

C++ STL stack / queue 완전 정리 — LIFO vs FIFO 실전편

STL · stack · queue · 프로그래머스 · 올바른 괄호

목표

코딩테스트 스택/큐 유형을 C++로 풀기 위해 stack과 queue 기본 문법을 정리하고, 프로그래머스 올바른 괄호(Level 2) 문제에 직접 적용한다.

stack vs queue vs deque

STL	구조	접근 방향	범위기반 for
stack	LIFO	한쪽 끝만 (top)	❌
queue	FIFO	앞(front) / 뒤(back)	❌
deque	양방향	앞/뒤 모두 + 인덱스	✅

stack과 queue는 내부적으로 deque 기반이다. 접근 방향을 제한해놓은 것뿐이다.

stack 기본 문법

    #include <stack>

    stack<int> st;

    st.push(3);     // 위에 추가

    st.top();      // 맨 위 값 확인 (제거 안함)

    st.pop();      // 맨 위 값 제거

    st.empty();    // 비어있으면 true

    st.size();     // 원소 개수

전체 순회 방법

    // 범위기반 for 불가 → while로 꺼내야 함

    while (!st.empty())

    {

      cout << st.top() << "\n";

      st.pop();

    }

    // LIFO니까 역순 출력됨

⚠️ 빈 스택에서 pop() 하면 런타임 에러. 반드시 empty() 체크 후 pop() 해야 한다.

queue 기본 문법

    #include <queue>

    queue<int> q;

    q.push(3);     // 뒤에 추가

    q.front();     // 맨 앞 값 확인 (제거 안함)

    q.back();      // 맨 뒤 값 확인

    q.pop();       // 맨 앞 값 제거

    q.empty();     // 비어있으면 true

    q.size();      // 원소 개수

전체 순회 방법

    // 범위기반 for 불가 → while로 꺼내야 함

    while (!q.empty())

    {

      cout << q.front() << "\n";

      q.pop();

    }

    // FIFO니까 넣은 순서대로 출력됨

⚡ stack vs queue 한눈에 비교

기능	stack	queue
추가	push() → 위에	push() → 뒤에
확인	top()	front() / back()
제거	pop() → 위에서	pop() → 앞에서
순서	LIFO (역순)	FIFO (입력 순서)
코테 용도	괄호, DFS, 히스토리	BFS, 시뮬레이션

실전 적용 — 올바른 괄호

문자열이 주어질 때, 올바른 괄호 문자열인지 판별해라. ( 로 열면 반드시 ) 로 닫혀야 한다.

핵심 로직: '(' 나오면 push → ')' 나오면 스택 비어있으면 false, 아니면 pop → 루프 끝나고 스택에 남아있으면 false

    #include <string>

    #include <stack>

    using namespace std;

    bool solution(string s)

    {

      bool answer = true;

      stack<char> st;

      for (int i = 0; i < s.size(); ++i)

      {

        if (s[i] == '(')

        {

          st.push('(');

        }

        else if (s[i] == ')')

        {

          if (st.empty()) // 빈 스택에서 pop 방지

          {

            return false;

          }

          st.pop();

        }

      }

      if (!st.empty()) // 루프 끝났는데 '(' 남아있으면

      {

        answer = false;

      }

      return answer;

    }

배운 것

• stack과 queue는 범위기반 for 불가. while + empty() 체크로 순회해야 한다.

• 빈 스택/큐에서 pop()은 런타임 에러. 반드시 empty() 체크 후 pop() 해야 한다.

• stack은 DFS/괄호/히스토리, queue는 BFS/시뮬레이션에 쓴다.

• stack과 queue는 내부적으로 deque 기반이다. deque는 양쪽 끝 접근 + 인덱스 접근이 가능하다.

• size_t는 부호 없는 정수라 int와 섞으면 언더플로우 버그 발생 가능. (int) 캐스팅 습관 필요.

다음 포스팅: queue 실전 문제 + sort 정렬 정리

[AFO_Refactor #0] 프로젝트 셋업 + 코드 분석 - 팀 프로젝트를 GAS 기반으로 리팩토링하기

Client Side — Tue, 9 Jun 2026 20:12:54 +0900

AFO_Refactor 개발일지 #0

프로젝트 셋업 + 코드 분석

GitHub · CLAUDE.md · 버그 9개 발견 · GAS 리팩토링 방향

왜 이 프로젝트를 시작했나

부트캠프 팀 프로젝트로 2v2 멀티플레이 액션 게임 AFO를 만들었다. Dedicated Server 기반에 5종 캐릭터, 팀 킬 스코어 방식으로 설계했고, 패키징까지 완료했다.

그런데 문제가 있었다.

패키징 후 멀티플레이 플레이 중 크래시 발생
팀원마다 코드 스타일이 달라 구조가 통일되지 않음
스킬 DataTable 연동 미완성 (호출 타이밍 문제)
서버 권한 처리가 일관되지 않음

취업 포트폴리오로 쓰기엔 부족했다. 그래서 혼자 처음부터 구조를 뜯어고치기로 했다.

AI로 [시간단축] → 내가 [문제발견] → 내가 [구조개선] → [수치결과]

프로젝트 개요

프로젝트명	AFO_Refactor
원본	팀 프로젝트 AFO (2v2 멀티플레이 액션)
엔진	Unreal Engine 5.5 / C++
네트워크	Dedicated Server
목표	GAS 기반 전투 시스템 리팩토링 + 멀티플레이 크래시 수정
개발 기간	약 4주 (Claude Code 활용)

GitHub 세팅

원본 팀 레포는 그대로 두고, 개인 레포 AFO_Refactor를 새로 생성했다.

LFS는 사용하지 않는다. Content 폴더를 아예 올리지 않기 때문이다. 면접관이 보는 건 코드이고, 에셋은 저작권 문제도 있어서 소스만 관리한다.

# .gitignore 핵심 항목
Content/           # 에셋 (용량 크고 저작권 문제)
Binaries/          # 컴파일 결과물
Intermediate/      # 중간 빌드 파일
Saved/             # 로그, 스크린샷
DerivedDataCache/  # 에셋 캐시

코드 분석 결과 — 발견한 버그 9개

Claude Code로 소스 전체를 분석했다. AI가 분석 → 내가 원인 판단 → 우선순위 결정 순서로 진행했다.

단순 코드 리뷰만으로 Critical 버그 4개를 포함해 총 9개의 문제를 발견했다.

Critical 1 — HandleSkillHitCheck 세미콜론 버그

위치: AFPlayerCharacter.cpp

bool bHit = GetWorld()->OverlapMultiByChannel(...);

if (bHit) return;  // ← 세미콜론! 충돌 시 바로 리턴
{
    for (auto& Result : OverlapResults)  // ← if와 분리된 블록, 항상 실행됨
    { ... }
}

결과: 스킬이 적에게 맞아도 데미지가 전혀 들어가지 않는다. 세미콜론 하나가 전체 스킬 시스템을 무력화했다.

Critical 2 — AnimNotify_AttackHit 클라이언트에서 DealDamage 직접 호출

위치: AFAnimInstance.cpp

// ❌ AnimNotify는 모든 클라이언트에서 발동됨
void UAFAnimInstance::AnimNotify_AttackHit()
{
    // HasAuthority() 체크 없음!
    Character->DealDamage();  // ← 클라이언트에서도 실행됨
}

결과: Dedicated Server 환경에서 클라이언트가 서버 전용 작업을 직접 실행 → 멀티플레이 크래시의 핵심 원인 중 하나.

Critical 3 — AFAurora::StopSprint 오타

위치: AFAurora.cpp

// ❌ StopSprint인데 StartSprint 호출
void AAFAurora::StopSprint(const FInputActionValue& Value)
{
    Super::StartSprint(Value);  // ← StopSprint여야 함
    bIsSprinting = false;
}

결과: 오로라 캐릭터는 스프린트 키를 떼도 속도가 원복되지 않는다.

Critical 4 — DataTable 로드 타이밍 버그

위치: AFMage.cpp, AFDarkKnight.cpp, AFWereWolf.cpp

// ❌ OnRep_PlayerState 시점에 DataTable이 아직 null일 수 있음
void AAFMage::OnRep_PlayerState()
{
    LoadMageData();  // ← SkillDataTable이 nullptr인 채로
}

void AAFMage::LoadMageData()
{
    // nullptr 체크 없이 바로 FindRow() 진입 → 크래시
    SkillDataTable->FindRow<FMageSkillData>(...);
}

결과: 클라이언트에서 스킬 아이콘이 뜨지 않거나, nullptr 역참조로 크래시. 스킬 슬롯 DataTable 연동이 끝내 안 됐던 근본 원인이다.

High 1 — AnimInstance 매 프레임 Cast 체인

위치: AFAnimInstance.cpp NativeUpdateAnimation()

// ❌ 매 프레임 Cast 3번 실행
if (AAFDarkKnight* DK = Cast<AAFDarkKnight>(BaseChar))
    bIsSprinting = DK->bIsSprinting;
else if (AAFMage* Mage = Cast<AAFMage>(BaseChar))
    bIsSprinting = Mage->bIsSprinting;
else if (AAFAurora* Aurora = Cast<AAFAurora>(BaseChar))
    bIsSprinting = Aurora->bIsSprinting;

결과: 캐릭터 추가 시 이 함수도 수정해야 한다. 확장성 없는 구조 + 매 프레임 불필요한 Cast 비용.

High 2 — Multicast_NotifyDamage 팀 비교 로직 반대

위치: AFAttributeComponent.cpp

// ❌ 같은 팀 = 적 데미지로 표시되는 반전 로직
if (MyPS->GetTeamID() == InstigatorPS->GetTeamID())
{
    bIsEnemyDamage = true;  // ← 같은 팀인데 적 데미지?
}

결과: 아군을 공격하면 적 색상으로, 적을 공격하면 아군 색상으로 데미지 수치가 표시된다.

Medium 1 — UI EnsureUI 반복 타이머

위치: AFLobbyPlayerController.cpp

// ❌ UI가 붙은 후에도 0.2초마다 계속 실행
GetWorldTimerManager().SetTimer(
    EnsureUITimer, this,
    &ThisClass::SetupUIForCurrentMap,
    0.2f, true  // ← true = 무한 반복
);

결과: UI 셋업이 완료된 후에도 타이머가 멈추지 않는다. 이벤트/델리게이트 기반으로 교체 필요.

Medium 2 — 맵 이름 하드코딩

위치: AFLobbyPlayerController.cpp

// ❌ 맵 이름 문자열 직접 하드코딩
if (MapName == TEXT("AFOTeamSelect"))
if (MapName == TEXT("AFOCharacterSelectMap"))

결과: 맵 이름이 바뀌면 코드도 같이 수정해야 한다. DataAsset 또는 GameInstance 변수로 분리 필요.

Medium 3 — ApplySpeedBuff / AddShield 타이머 미정리

위치: 캐릭터 스킬 관련 코드

// ❌ 기존 타이머 정리 없이 재호출
// ClearTimer 없이 SetTimer 재호출
GetWorldTimerManager().SetTimer(
    SpeedBuffTimerHandle, ...
);

결과: 버프가 중첩 적용되거나 타이머가 꼬여서 버프 해제 타이밍이 부정확해진다.

버그 요약

등급	버그	영향
Critical	HandleSkillHitCheck 세미콜론	스킬 데미지 전혀 안 들어감
Critical	AnimNotify_AttackHit HasAuthority 누락	멀티플레이 크래시
Critical	AFAurora::StopSprint 오타	오로라 스프린트 속도 미복원
Critical	DataTable nullptr 역참조	스킬 슬롯 미표시 / 크래시
High	매 프레임 Cast 체인	성능 + 확장성 문제
High	팀 비교 로직 반전	데미지 색상 반대로 표시
Medium	UI 반복 타이머	불필요한 반복 실행
Medium	맵 이름 하드코딩	유지보수성 저하
Medium	타이머 미정리 패턴	버프 타이밍 부정확

️ 리팩토링 방향 및 로드맵

Phase	작업	핵심 키워드
#1	Critical 버그 수정 (세미콜론, HasAuthority, 오타)	서버 권한, 스킬 판정
#2	Cast 체인 → Interface 교체	의존성 제거, 확장성
#3	GAS 도입 — ASC + AttributeSet	GAS, 전투 시스템
#4	HP/Mana → GameplayEffect 교체	GAS, 리플리케이션
#5	스킬 → GameplayAbility 교체	GAS, 스킬 시스템
#6	DataTable 로드 타이밍 안정화	PossessedBy, nullptr 가드
#7	UI 타이머 → 이벤트 기반 교체	Delegate, 최적화
#8	드로우콜 측정 + 최적화	프로파일링, Before/After
#9	패키징 + 멀티플레이 크래시 최종 수정	Dedicated Server, 네트워크

CLAUDE.md 세팅

Claude Code가 이 프로젝트의 맥락을 이해하고 일관된 방향으로 작업할 수 있도록 CLAUDE.md를 루트에 작성했다.

IronBird 때와 달리 이번 CLAUDE.md의 핵심은 두 가지다.

알려진 버그 목록 — 파일 위치와 원인까지 명시해서 Claude Code가 맥락 없이 엉뚱한 수정을 하지 않도록
GAS 도입 계획 — 교체 대상 클래스와 추가할 모듈을 미리 정의해서 작업 방향을 고정

이번 작업에서 배운 것

코드 분석만으로도 포트폴리오 소재가 나온다.

새 기능을 추가하지 않아도 기존 코드에서 if (bHit) return; 같은 치명적인 버그를 발견하고, 원인을 정확히 짚어내는 것 자체가 실무 능력의 증명이다. 특히 팀 프로젝트 코드를 분석해서 "이 버그가 왜 생겼는지"까지 설명할 수 있으면, 면접관 입장에서 "이 사람은 남의 코드를 읽을 줄 안다"는 인상을 준다.

다음 포스팅

[AFO_Refactor #1] Critical 버그 수정 — 세미콜론 하나가 스킬 시스템을 망가뜨린 이야기

HandleSkillHitCheck 수정 + AnimNotify HasAuthority 누락 수정 + 서버 권한 처리 전면 점검까지.

C++ STL unordered_map 완전 정리 — 코딩테스트 실전편

Client Side — Tue, 9 Jun 2026 16:19:41 +0900

코딩테스트 준비 #1

C++ unordered_map 완전 정리 — 해시맵 기초부터 실전까지

STL · unordered_map · 해시맵 · 프로그래머스 · 완주하지 못한 선수

목표

코딩테스트 해시맵 유형을 C++로 풀기 위해 unordered_map 기본 문법을 정리하고, 프로그래머스 완주하지 못한 선수(Level 1) 문제에 직접 적용한다.

map vs unordered_map

항목	map	unordered_map
내부 구조	레드블랙트리	해시테이블
탐색 시간복잡도	O(log N)	평균 O(1)
키 정렬	자동 정렬됨	순서 없음
코테 기본 선택	❌	✅

코딩테스트에서는 거의 항상 unordered_map을 써라. 키 정렬이 필요한 경우에만 map을 쓴다.

기본 문법 — 핵심 4가지

1. 추가 / 증가

// 없으면 0 생성 후 +1, 있으면 +1
counter["kim"]++;
// 직접 대입 (있으면 덮어씀)
counter["kim"] = 5;

2. 존재 여부 확인 vs 값 접근

// count() → 키 존재 여부만 반환 (0 또는 1)
if (counter.count("kim") > 0) { }

// [] 연산자 → 값(int) 반환
int val = counter["kim"];

⚠️ count()는 값을 반환하는 게 아니다. 키가 있냐 없냐만 알려준다.

3. 삭제

counter.erase("kim"); // 키:값 쌍 자체가 사라짐

4. 순회

// map의 원소 자체가 pair<string, int>다
for (auto& [key, value] : counter) // C++17 구조적 바인딩
{
  // key = 키(string), value = 값(int)
}

⚡ insert vs [ ] 연산자 차이

방법	키가 이미 있을 때	코테 사용 빈도
insert()	무시됨 (기존 값 유지)	낮음
[] 연산자	덮어씀	높음 ✅

실전 적용 — 완주하지 못한 선수

마라톤 전체 참가자와 완주자 명단이 주어질 때, 완주하지 못한 선수 1명을 찾아라. 동명이인 있음.

완전탐색 → O(N²) → 시간초과

// find()로 하나씩 검색 → O(N) × N번 = O(N²)
// N=100,000이면 100억 번 연산 → 시간초과

unordered_map → O(N) → 통과

#include <string>
#include <vector>
#include <unordered_map>
using namespace std;

string solution(vector<string> participant, vector<string> completion)
{
  string answer = "";
  unordered_map<string, int> counter;

  // 1. 전체 참가자 횟수 저장
  for (auto& part : participant)
    counter[part]++;

  // 2. 완주자 횟수 차감
  for (auto& comp : completion)
    counter[comp]--;

  // 3. 횟수가 남은 사람 = 완주 못한 선수
  for (auto& [key, value] : counter)
  {
    if (value > 0)
    {
      answer = key;
      break;
    }
  }
  return answer;
}

동명이인 처리가 자동으로 되는 이유: 이름이 아닌 횟수로 추적하기 때문이다. "kim"이 참가자에 2명, 완주자에 1명 있으면 counter["kim"] = 1로 남는다.

배운 것

상황	코드
값 추가/증가	counter[key]++
값 감소	counter[key]--
존재 여부	counter.count(key) > 0
값 접근	counter[key]
순회	for (auto& [key, value] : counter)
삭제	counter.erase(key)

다음 포스팅: unordered_set으로 중복 제거하기 — 프로그래머스 폰켓몬

[IronBird #9] Android 빌드 + 실기기 프로파일링 (Galaxy S23+)

Client Side — Mon, 8 Jun 2026 00:16:39 +0900

IronBird 개발일지 #9

Android 빌드 + 실기기 프로파일링 (Galaxy S23+)

Android NDK · APK 패키징 · 실기기 수치 측정 · PC vs 모바일 비교

목표

PC에서 개발한 IronBird를 Android 기기에서 실행하고, 실기기에서 프로파일링 수치를 측정한다. PC 수치와 비교해 모바일 최적화 효과를 검증한다.

테스트 기기: Galaxy S23+ (SM-S916N) · Android 빌드 타겟: arm64-v8a · 텍스처 포맷: ETC2

Android 빌드 설정

항목	설정값
Android NDK	r27c (UE5.7 요구사항)
텍스처 포맷	ETC2 (범용 Android)
화면 방향	Portrait (세로 고정)
텍스처 스트리밍 풀	r.Streaming.PoolSize=0 (자동)
렌더링 API	Android Multi (OpenGL ES3.2 + Vulkan)

트러블슈팅

문제 1. NDK 버전 불일치로 빌드 실패

원인: Android Studio가 설치한 NDK r30이 UE5.7 허용 범위(r27c~r28c)를 초과했다.

해결: SetupAndroid.bat 실행으로 r27c 설치 후 Project Settings에서 NDK 경로를 r27c로 직접 지정.

C:\Program Files\Epic Games\UE_5.7\Engine\Extras\Android\SetupAndroid.bat

문제 2. Platform Android is not a valid platform to build

원인: UE5 엔진에 Android 플랫폼 지원 파일이 설치되지 않았다. NDK와 별개로 Epic Games Launcher에서 추가 설치가 필요하다.

해결: Epic Games Launcher → UE 5.7 옵션 → 대상 플랫폼 → Android 체크 → 설치 (약 9GB).

문제 3. 모바일에서 게임오버 터치 입력 안됨

원인: PC에서는 GetMousePosition으로 좌표를 가져왔지만 모바일 터치는 다른 입력 경로를 사용한다.

해결: BindTouch로 터치 좌표를 받아서 버튼 Rect와 비교하는 방식으로 변경.

// 터치 입력 처리 추가
void OnTouchPressed(ETouchIndex::Type FingerIndex, FVector Location)
{
  float TouchX = Location.X;
  float TouchY = Location.Y;
  // 버튼 Rect와 비교
}

문제 4. 첫 실행 시 간헐적 크래시

원인: 첫 실행 시 기기에서 셰이더를 컴파일하면서 메모리 spike 발생. 두 번째 실행부터는 캐시된 셰이더를 사용해 정상 작동.

결론: 데모 시연 시 사전에 한 번 실행해두면 문제없음.

실기기 프로파일링 결과

측정 방법: Development 빌드 콘솔(stat fps / stat unit)로 실기기에서 직접 측정

항목	PC (Before)	모바일 S23+	목표
FPS	56.91	59.40 ✅	30fps 이상
Game ms	18.01ms	3.79ms ✅	-
Draw ms	0.00ms	3.92ms	-
GPU Time	3.34ms	7.84ms	-
Draws	252	34 ✅	100 이하
메모리	4.70GB	490MB ✅	1.5GB 이하

핵심 결과: PC에서 Draws 252였던 것이 모바일에서 34로 측정됐다. PC stat 수치가 모바일 실제 렌더링 구조를 반영하지 못한다는 것을 확인했다. 모바일 최적화는 반드시 실기기에서 검증해야 한다.

배운 것

• Android 빌드는 NDK 버전과 엔진 플랫폼 파일 두 가지가 모두 맞아야 한다. 하나만 설치해서는 빌드가 안 된다.

• PC stat 수치와 모바일 실측 수치는 완전히 다르다. PC Draws 252가 모바일에서 34로 나왔다. PC에서 최적화 효과가 미미해도 모바일에서 효과가 클 수 있다.

• 터치 입력은 마우스 입력과 경로가 다르다. GetMousePosition 대신 BindTouch로 별도 처리해야 한다.

• 첫 실행 셰이더 컴파일은 모바일 개발의 공통 이슈다. 데모 시연 전 사전 실행으로 캐시를 만들어두는 것이 필요하다.

• Android Multi 빌드로 OpenGL ES3.2와 Vulkan을 동시에 지원할 수 있다. 기기가 자동으로 지원하는 렌더러를 선택한다.

IronBird 시리즈 마무리

포스팅	핵심 내용
#0~1	프로젝트 셋업, 플레이어 이동 + 터치 입력
#2~3	배경 스크롤, Object Pool (Game ms -25%, FPS +27%)
#4~5	적 스폰 시스템, 보스 3페이즈
#6~7	메인화면 + 점수 시스템, BGM + 이펙트 + 완성도
#8~9	최적화 시도 + Android 빌드 + 실기기 검증

추가 예정: Google Play Store 출시 진행 중. 심사 완료 후 링크 업데이트 예정.

[IronBird #8] 드로우콜 최적화 시도 - PC 프로파일링 결과 분석

Client Side — Fri, 5 Jun 2026 16:54:42 +0900

IronBird 개발일지 #8

드로우콜 최적화 시도 - PC 프로파일링 결과 분석

Shadow Casting · Object Pool · 콜리전 분리 · 프로파일링

목표

모바일 목표 수치(드로우콜 100 이하, FPS 30 안정)를 향해 최적화를 시도한다. PC에서 프로파일링하고 각 최적화 기법의 실제 효과를 측정한다.

최적화는 반드시 수치로 증명해야 한다. "빠를 것 같다"는 감이 아니라 Before/After 측정이 기준이다.

Before 수치

측정 환경: PC, 엔진 퀄리티 중간, 게임플레이 중 적 다수 존재

항목	수치	모바일 목표
FPS	56.91	30fps 안정
Frame	18.04ms	33ms 이하
Game	18.01ms	-
GPU Time	3.34ms	-
Draws	252	100 이하
메모리	4.70GB	1~1.5GB

최적화 시도 결과

✅ Object Pool - 효과 있음 (이전 #3에서 측정)

Game 스레드 17.35ms → 13.05ms (-25%), FPS 59 → 76 (+27%)

✅ 콜리전 아키텍처 분리 - 구조적 개선

MeshComponent NoCollision + USphereComponent hitbox 분리. FBX 복잡한 콜리전 계산 제거.

✅ 불필요한 라이팅 제거

DirectionalLight, SkyAtmosphere, VolumetricCloud, ExponentialHeightFog 제거. Unlit 머티리얼 사용으로 라이팅 연산 불필요.

⚠️ Shadow Casting Off - PC에서 효과 미미

총알·적·플레이어 MeshComponent->SetCastShadow(false) 적용. Draws 252 → 302로 오히려 증가. 이미 Unlit 머티리얼이라 Shadow 연산이 없었던 것이 원인.

✅ Object Pool 크기 축소

BulletPool 30→20개, EnemyBulletPool 15개로 축소. 초기 메모리 할당 감소.

분석

PC에서 Draws 252는 게임 오브젝트보다 씬 자체(SM_SkySphere, SkyLight 등)의 비중이 크다. 게임 오브젝트 최적화만으로는 전체 드로우콜을 100 이하로 낮추기 어렵다.

핵심 인사이트: PC stat 수치는 참고용이다. 모바일 최적화의 실제 지표는 Android 실기기에서 Unreal Insights로 측정해야 한다. PC에서 최적화 효과가 미미했던 Shadow Casting Off도 모바일 GPU에서는 다른 결과가 나올 수 있다.

배운 것

• 최적화는 항상 수치로 검증해야 한다. "효과가 있을 것 같다"는 감으로 적용하면 오히려 역효과가 날 수 있다.

• Shadow Casting Off는 Lit 머티리얼에서 효과적이다. Unlit 머티리얼에서는 이미 Shadow 연산이 없어 효과가 없다.

• PC 드로우콜과 모바일 드로우콜은 다르다. 실기기 측정 없이 PC 수치만으로 최적화 완료를 판단할 수 없다.

• Object Pool은 드로우콜보다 Game 스레드 ms에 영향을 준다. 최적화 목표에 맞는 지표를 선택해야 한다.

다음 작업

[IronBird #9] Android 빌드 + 실기기 프로파일링

Android SDK/NDK 세팅 후 실기기 빌드. Unreal Insights로 실측 수치 기록. PC와 모바일 수치 비교.

[IronBird #7] BGM + 이펙트 + 하트 아이템 + 틸팅 + UMG 메인화면

Client Side — Tue, 2 Jun 2026 14:24:28 +0900

IronBird 개발일지 #7

BGM + 이펙트 + 하트 아이템 + 틸팅 + UMG 메인화면

UAudioComponent · SpawnEmitter · UMG · 카메라 고정 · 난이도 조정

목표

게임 완성도를 높인다. BGM과 효과음으로 타격감을 살리고, 하트 아이템과 난이도 조정으로 게임성을 추가한다. 카메라를 레벨에 고정해 갤러그 스타일 시점을 완성하고, UMG로 메인화면을 교체한다.

이번 작업의 핵심은 C++ 코드로 UPROPERTY 슬롯을 노출하고, 에디터에서 에셋을 할당하는 방식으로 분리한 것이다. 코드 수정 없이 에셋만 교체할 수 있어 유지보수가 편해진다.

구현 내용

https://youtube.com/shorts/lW6pr6lhA-8?feature=share IronBird 시연영상

점수 기반 하트 스폰타이머 방식 → 1000점마다 하트 아이템 스폰으로 변경BGM 루프 재생OnAudioFinished 델리게이트로 BGM 반복 구현

항목	내용
BGM 시스템	Gameplay/Boss/GameOver/GameClear 4종, 상황별 전환
효과음	피격음, 발사음(볼륨 30%), 폭발음, 아이템 획득음
폭발 이펙트	적/보스 처치 시 SpawnEmitterAtLocation
하트 아이템	20~30초 랜덤 스폰, 획득 시 HP+1 (최대 3)
난이도 조정	0~30초 3초, 30~60초 2초, 60~90초 1.5초 스폰 간격
TypeB 편대 스폰	0.3초 간격 3대 연속 스폰 (갤러그 스타일)
카메라 고정	레벨 CameraActor 고정, SpringArm 제거
플레이어 틸팅	Y축 이동 속도 기반 Roll ±25도
UMG 메인화면	WBP_MainMenu, DrawText 방식 → UMG 교체
나이아가라 전환	ParticleSystem → NiagaraSystem 교체, Niagara 모듈 추가
타입별 점수 조정	TypeA 150점 / TypeB 50점 / TypeC 100점
보스 피격음	Boss HitSound UPROPERTY 추가

1. BGM 시스템 설계

UAudioComponent로 루프 재생하고 상황에 따라 전환하는 방식이다. UPROPERTY로 슬롯을 노출해 코드 수정 없이 에셋만 교체할 수 있다.

// BGM 전환 흐름
BeginPlay → GameplayBGM 재생
SpawnBoss() → BossBGM 전환 (null이면 유지)
게임오버 → GameOverBGM 전환
보스 처치 → GameClearBGM 전환

// 발사음은 볼륨 30%로 BGM과 균형
UGameplayStatics::PlaySoundAtLocation(
  this, ShootSound, GetActorLocation(), 0.3f);

설계 결정: 적 발사음은 의도적으로 제외했다. 적이 많아질수록 발사음이 겹쳐 BGM과 피격음이 묻히기 때문이다. 갤러그, 1945도 동일한 방식이다.

2. 카메라 고정 (갤러그 스타일)

기존 SpringArm + Camera 구조는 플레이어를 따라다녀서 화면이 같이 이동하는 문제가 있었다. 레벨에 CameraActor를 고정 배치하고 PlayerController에서 뷰를 전환하는 방식으로 해결했다.

// Before: SpringArm이 플레이어 따라다님
SpringArm->TargetArmLength = 2000.0f;

// After: 레벨 고정 카메라로 뷰 전환
ACameraActor* FixedCam = Cast<ACameraActor>(
  UGameplayStatics::GetActorOfClass(...));
SetViewTargetWithBlend(FixedCam, 0.0f);

3. 플레이어 틸팅

스켈레탈 메시 애니메이션 없이 코드로 구현했다. Y축 이동 방향에 따라 메시의 Roll 값을 조정해 기체가 자연스럽게 기우는 효과를 낸다.

// Tick에서 목표 위치와 현재 위치 차이로 기울기 계산
float TiltAngle = FMath::Clamp(
  (TargetLocation.Y - GetActorLocation().Y) * -0.05f,
  -25.0f, 25.0f);

MeshComponent->SetRelativeRotation(
  FRotator(0.0f, -90.0f, 90.0f + TiltAngle));

모바일 관점: StarSparrow는 스태틱 메시라 스켈레탈 애니메이션이 불가능하다. 코드 기반 틸팅은 별도 애니메이션 에셋 없이 구현 가능하고 모바일 성능 부담도 없다.

4. 나이아가라 전환

기존 Cascade 파티클 시스템(UParticleSystem)을 나이아가라(UNiagaraSystem)로 교체했다. UE5에서 Cascade는 레거시이며 나이아가라가 공식 파티클 시스템이다.

// Before: Cascade
UGameplayStatics::SpawnEmitterAtLocation(
  GetWorld(), ExplosionEffect, GetActorLocation());

// After: Niagara
UNiagaraFunctionLibrary::SpawnSystemAtLocation(
  GetWorld(), ExplosionEffect, GetActorLocation());

Build.cs 주의: Niagara 사용 시 IronBird.Build.cs에 "Niagara" 모듈을 반드시 추가해야 한다. 누락 시 링크 에러 발생.

5. 점수 기반 하트 스폰

기존 타이머 기반 하트 스폰은 게임 진행과 무관하게 일정 시간마다 나왔다. 점수 기반으로 변경해 게임 흐름과 연동했다.

// Before: 20~30초 랜덤 타이머
SetTimer(HeartTimerHandle, ..., FMath::RandRange(20.f, 30.f));

// After: 1000점마다 스폰
if (GS->GetScore() >= NextHeartScoreThreshold)
{
  SpawnHeartItem();
  NextHeartScoreThreshold += 1000;
}

6. BGM 루프 재생

UAudioComponent에 직접 루프 설정이 불안정해 OnAudioFinished 델리게이트로 반복 재생을 구현했다.

// BGM 재생 시 OnAudioFinished 바인딩
BGMComponent->OnAudioFinished.AddDynamic(
  this, &AIronBirdGameMode::RestartBGM);

// RestartBGM: 처음부터 다시 재생
void AIronBirdGameMode::RestartBGM()
{
  BGMComponent->Play(0.0f);
}

7. 타입별 점수 조정

타입	변경 전	변경 후	이유
TypeA	100점	150점	빠른 직선탄, 위협도 높음
TypeB	100점	50점	3대 연속 등장, 개당 점수 낮게
TypeC	100점	100점	유지

트러블슈팅

문제 1. 메인메뉴 → 게임 진입 후 마우스 이동 불가

원인: 메인메뉴에서 설정한 FInputModeGameAndUI가 레벨 전환 후에도 유지됐다. Slate가 마우스 입력을 가로채 PlayerTick의 IsInputKeyDown이 false를 반환했다.

해결: AIronBirdPlayerController BeginPlay에서 FInputModeGameOnly로 명시적 초기화.

FInputModeGameOnly GameInputMode;
SetInputMode(GameInputMode);

문제 2. WBP_MainMenu MCP 자동 생성 실패

원인: UE5.7 Python API에서 Widget Blueprint의 WidgetTree와 이벤트 그래프 편집이 차단돼 있다. MCP로 레이아웃 자동 구성이 불가능했다.

해결: C++ 코드로 UMG 위젯을 뷰포트에 추가하는 부분만 자동화하고, 위젯 내부 디자인은 에디터에서 직접 구성했다.

AI 도구의 한계를 파악하고 수동 작업으로 전환한 것도 포트폴리오 소재가 된다. "AI가 할 수 있는 것과 없는 것을 판단할 수 있는 사람"이 목표이기 때문이다.

배운 것

• UPROPERTY로 사운드/이펙트 슬롯을 노출하면 코드 수정 없이 에디터에서 에셋만 교체할 수 있다. 기획 변경에 유연한 구조다.

• FInputMode는 레벨 전환 후에도 유지된다. 레벨 시작 시 항상 명시적으로 초기화해야 한다.

• 스태틱 메시도 코드로 Roll 값을 조정하면 애니메이션 느낌을 낼 수 있다. 모바일에서 애니메이션 에셋 없이 구현하는 좋은 대안이다.

• 사운드 설계는 "무엇을 넣느냐"보다 "무엇을 뺄 것인가"가 중요하다. 적 발사음을 제외한 것이 전체 사운드 균형을 유지하는 데 핵심이었다.

• UE5.7 Python MCP API는 Widget Blueprint 내부 편집을 지원하지 않는다. AI 도구의 한계를 파악하고 빠르게 수동 작업으로 전환하는 판단이 중요하다.

다음 작업

[IronBird #8] 드로우콜 최적화 (Before/After 핵심)

머티리얼 인스턴싱, 스태틱 메시 병합으로 드로우콜을 줄이고 수치를 기록한다. 이 시리즈에서 가장 임팩트 있는 포스팅이 될 예정이다.

[Coding Test] 시뮬레이션 격자(Grid) 탐색 핵심 개념 정리 (dy, dx, Offset)

Client Side — Mon, 1 Jun 2026 18:28:05 +0900

1. 격자판 좌표가 (y, x)인 이유: 2차원 배열의 구조

일반적인 수학 좌표계에서는 가로축이 X, 세로축이 Y이므로 (x, y)로 표기하는 것이 익숙합니다. 하지만 코딩테스트의 격자판 문제는 컴퓨터 메모리의 2차원 배열을 기반으로 작동합니다.

2차원 배열 구조: Array[Row][Column] -> [행][열]
매핑 방식: 행(Row)은 위아래(가로줄)를 결정하므로 Y축이 되고, 열(Column)은 좌우(세로줄)를 결정하므로 X축이 됩니다.

따라서 코딩테스트 시뮬레이션 문제를 풀 때는 항상 (y, x) 즉 [행][열] 구조를 표준으로 삼고 접근해야 메모리 접근 효율(Cache Locality)을 높이고 버그를 줄일 수 있습니다.

2. 윗칸으로 이동하는데 y - 1인 이유: Screen Coordinate

수학 그래프에서는 위로 올라갈수록 Y값이 증가하지만, 컴퓨터 그래픽스와 2차원 배열에서는 좌측 상단(Top-Left)이 기준점 (0, 0)이 됩니다.

오른쪽으로 이동: X축 증가 (x + 1)
아래쪽으로 이동: Y축 증가 (y + 1)
위쪽으로 이동: Y축 감소 (y - 1)

텍스트를 위에서 아래로 읽어 내려가는 인간의 시선 및 메모리 주소 할당 방향과 일치하기 때문입니다. 기준점 (y, x)를 중심으로 상하좌우를 표현하면 아래 구조와 같습니다.

	(y - 1, x) [상]
(y, x - 1) [좌]	(y, x) [기준점]	(y, x + 1) [우]
	(y + 1, x) [하]

3. 방향 벡터 dy, dx에서 d의 의미

시뮬레이션 문제 해설을 보면 항상 int dy[4], int dx[4] 같은 배열이 등장합니다. 여기서 d는 변화량, 차이를 뜻하는 델타(Delta) 또는 변위(Displacement)의 약자입니다.

"현재 위치에서 다음 위치로 이동할 때 좌표가 얼마나 변화해야 하는가?"를 의미하는 상대적인 값(방향 벡터)을 상수로 묶어둔 것입니다.

C++ 4방향 탐색 표준 템플릿 코드

#include <iostream>

// 상, 하, 좌, 우 순서로 변위(Delta) 정의
const int dy[4] = { -1, 1, 0, 0 };
const int dx[4] = { 0, 0, -1, 1 };

int main() {
    int currentY = 5, currentX = 5; // 현재 위치

    for (int i = 0; i < 4; ++i) {
        int nextY = currentY + dy[i];
        int nextX = currentX + dx[i];
        
        // 이 한 줄의 반복문으로 상하좌우 4방향 이동을 모두 처리할 수 있습니다.
        std::cout << "방향 [" << i << "] 이동 결과: (" << nextY << ", " << nextX << ")\\n";
    }
    return 0;
}

이점: 수많은 if-else 분기문을 제거하여 코드 가독성을 높이고, CPU의 분기 예측 성공률을 높여 연산 오버헤드를 최적화할 수 있습니다.

4. 오프셋(Offset)이란 무엇인가?

오프셋(Offset)은 "기준점(Origin)으로부터 얼마나 떨어져 있는가?"를 나타내는 상대적인 거리나 변위를 뜻합니다. 절대적인 위치 좌표가 아니라, '상대적인 차이값'이라는 점이 핵심입니다.

1) 메모리 관점에서의 오프셋

배열 A[2]에 접근할 때, 시스템 내부적으로는 배열의 시작 주소(Base Address)에 [자료형 크기 * 인덱스]만큼의 오프셋을 더해 물리적 주소를 찾아갑니다. 이 연산이 단 한 번에 끝나기 때문에 배열의 임의 접근(Random Access) 시간 복잡도는 O(1)이 됩니다.

2) 게임 엔진 및 시뮬레이션 관점에서의 오프셋

몬스터가 플레이어를 추적하거나 캐릭터 전방에 타격 판정을 생성할 때, 캐릭터의 현재 좌표를 기준점(Base)으로 잡고, 바라보는 방향 벡터에 거리를 곱한 오프셋(Offset)을 더해 최종 목적지 좌표를 계산합니다.

최종 목적지 위치 = 기준 위치 + 오프셋

5. 요약 및 한계 인식 (Technical Insight)

[y][x] 구조와 좌상단 (0, 0) 기준의 축 방향은 메모리 구조 및 화면 렌더링 방식에 기인한 프로그래밍의 표준 규칙입니다.
dy, dx는 복잡한 분기문 없이 주변을 탐색하기 위한 변위 오프셋 상수입니다.
한계 인식: 2D 격자 시뮬레이션의 (y, x) 좌표계를 실제 3D 게임 엔진(예: Unreal Engine 5)의 월드 좌표계(X 전방, Y 우측 오른손 법칙)로 이식할 때는, 축 매핑 과정에서 축이 뒤바뀌거나 부동소수점 오차로 인한 정밀도 손실이 발생할 수 있으므로 명확한 축 변환 연산과 예외 처리가 필요합니다.

#코딩테스트 #C++ #시뮬레이션 #방향벡터 #오프셋 #게임개발자 #기본기다지기

[IronBird #6] 메인화면 + 점수 시스템 + 게임오버/클리어

Client Side — Thu, 28 May 2026 22:19:00 +0900

IronBird 개발일지 #6

메인화면 + 점수 시스템 + 게임오버/클리어

MainMenuHUD · GameState · DrawText · FInputModeGameAndUI

목표

게임의 시작부터 끝까지 순환 구조를 완성한다. 메인화면 → 게임플레이 → 게임오버/클리어 → 메인화면으로 돌아오는 흐름과 점수 시스템을 구현한다.

메인화면 → GAME START → 게임플레이 → GAME OVER/CLEAR → MAIN MENU → 메인화면

구현 내용

클래스	역할
AMainMenuHUD	IRONBIRD 타이틀, GAME START / QUIT GAME 버튼
AMainMenuGameMode	메인화면 전용 GameMode, 마우스 입력 설정
AIronBirdGameState	점수 관리 (적 100점, 보스 1000점)
AIronBirdHUD 수정	SCORE 우측상단, GAME OVER/CLEAR 오버레이, MAIN MENU 버튼
배경	SM_SkySphere + Galaxy_Mat_Inst, Tick 회전으로 스크롤 효과

Main Menu

점수 시스템 구조

// Bullet Tick → Enemy 감지 → 점수 추가
Enemy->bKilledByPlayer = true;
Enemy->ReturnToPool();

// Enemy ReturnToPool()에서
if (bKilledByPlayer)
    GS->AddScore(100);

// Boss 처치 시
GS->AddScore(1000);

트러블슈팅

문제 1. 메인화면 버튼 클릭이 동작하지 않음

원인: BeginPlay에서 FInputModeUIOnly를 설정하면 모든 마우스 입력이 Slate UI로만 전달된다. 이 모드에서는 IsInputKeyDown이 항상 false를 반환한다.

해결: FInputModeGameAndUI로 변경. 게임 입력 시스템과 Slate를 동시에 활성화해 IsInputKeyDown이 정상 동작하게 했다.

- FInputModeUIOnly InputMode;
+ FInputModeGameAndUI InputMode;
+ InputMode.SetHideCursorDuringCapture(false);

문제 2. 적 처치해도 점수가 오르지 않음

원인: Bullet 메시가 NoCollision이라 Enemy::OnOverlapBegin이 절대 호출되지 않았다. bKilledByPlayer 플래그 세팅 없이 ReturnToPool만 호출되어 점수가 항상 0이었다.

해결: Bullet Tick 수동 쿼리에서 Enemy->ReturnToPool() 직전에 bKilledByPlayer = true 추가.

+ Enemy->bKilledByPlayer = true;
Enemy->ReturnToPool();

문제 3. HDR Cubemap 텍스처를 배경 Plane에 적용 불가

원인: milkywaysky_HDR는 Cubemap 형식이라 일반 TextureSample2D 노드와 타입 불일치. Plane 메시에 직접 적용 불가.

해결: Background_Plane 제거. 레벨의 SM_SkySphere에 Galaxy_Mat_Inst 적용 후 Tick에서 X축 회전으로 별이 흘러가는 스크롤 효과 구현.

배운 것

• FInputModeUIOnly는 게임 입력을 차단한다. HUD에서 마우스 클릭을 감지하려면 FInputModeGameAndUI를 써야 한다.

• 충돌 감지 흐름이 바뀌면 플래그 세팅 위치도 같이 바뀌어야 한다. 수동 쿼리 방식은 이벤트 방식과 호출 경로가 다르다.

• HDR Cubemap은 Skybox 전용이다. 일반 메시에 적용하려면 별도 노드가 필요하다.

• GameMode Tick은 기본 비활성이다. PrimaryActorTick.bCanEverTick = true를 생성자에서 명시해야 한다.

다음 작업

[IronBird #7] 난이도 조정 + 하트 아이템 + BGM + 이펙트 + 틸팅 + HUD 정리

게임 완성도를 높이고 Android 빌드 준비.

[IronBird #5] 보스 페이즈 + 적 3종류 + 충돌 시스템 구현

Client Side — Thu, 28 May 2026 20:09:51 +0900

IronBird 개발일지 #5

보스 페이즈 + 적 3종류 + 충돌 시스템 구현

EBossPhase · USphereComponent · FBX 콜리전 · 수동 물리 쿼리

목표

3페이즈 패턴 전환 보스와 3종류 적을 구현한다. 플레이어 체력 시스템과 HUD도 추가한다. FBX 메시 교체 과정에서 예상치 못한 콜리전 문제가 발생해 충돌 시스템을 전면 재설계했다.

AI로 클래스 구조 생성 → FBX 콜리전 문제 발견 → 직접 원인 분석 → USphereComponent로 재설계

구현 내용

항목	내용
적 3종류	TypeA 직선+발사 / TypeB 지그재그 / TypeC 느린하강+부채꼴
ABoss	HP 50, EBossPhase 3단계, HomeX 사인 이동
플레이어 체력	MaxHP=3, 피격 2초 무적, TakeDamage 오버라이드
HUD	DrawText 하트 3개 + 보스 체력바 (UMG 없이)
메시 교체	StarSparrow FBX (플레이어/적/보스 색상 구분)

플레이어 비행기

TypeA, TypeB, TypeC 적 비행기

보스 비행기

1. 보스 페이즈 상태머신

Behavior Tree 없이 HP 비율 기반 단순 상태머신으로 구현했다. 모바일에서 BT는 오버엔지니어링이다.

// HP 비율로 페이즈 전환
Phase1 (HP >60%): X 고정, Y 왕복 / 1.2초마다 직선탄 5발
Phase2 (HP >30%): X 사인이동, Y 왕복 / 0.9초마다 부채꼴 5발
Phase3 (HP ≤30%): 속도 1.5배 / 0.6초마다 전체 패턴

// HomeX 기반 사인 이동 (스폰 위치 중심으로 진동)
X = HomeX + FMath::Sin(Time) * 200.0f;

모바일 관점: Behavior Tree는 틱마다 태스크를 평가해 모바일에서 부담이 크다. 보스처럼 패턴이 명확한 경우 HP 비율 기반 상태머신이 훨씬 가볍고 예측 가능하다.

트러블슈팅

문제 1. FBX 메시 교체 후 모든 충돌이 동작하지 않음 (핵심)

원인: UE5에서 FBX 임포트 시 콜리전 Shape가 자동 생성되지 않는다. 기존 Cube 메시는 내장 BoxCollision이 있어서 동작했지만, StarSparrow FBX는 물리 바디가 없어 모든 충돌이 불가능했다.

해결: MeshComponent의 콜리전을 비활성화하고 USphereComponent를 별도로 추가해 hitbox를 명시적으로 구성했다.

// MeshComponent는 비주얼 전용
MeshComponent->SetCollisionEnabled(ECollisionEnabled::NoCollision);

// 명시적 hitbox 추가
HitSphere = CreateDefaultSubobject<USphereComponent>(TEXT("HitSphere"));
HitSphere->SetupAttachment(RootComponent);
HitSphere->SetSphereRadius(80.0f);  // Enemy: 80 / Boss: 250 / Player: 70
HitSphere->SetCollisionObjectType(ECC_Pawn);
HitSphere->SetGenerateOverlapEvents(true);

문제 2. QueryOnly 컴포넌트 간 Overlap 이벤트 불안정

원인: UE5 Chaos 물리에서 QueryOnly 설정된 컴포넌트끼리는 OnComponentBeginOverlap 이벤트가 간헐적으로 발생하지 않는 경우가 있다.

해결: Bullet Tick에서 OverlapMultiByObjectType으로 직접 물리 쿼리를 실행했다.

// 이벤트 방식 대신 직접 쿼리
TArray<FOverlapResult> Overlaps;
FCollisionObjectQueryParams ObjParams(ECC_Pawn);
GetWorld()->OverlapMultiByObjectType(
    Overlaps, GetActorLocation(), FQuat::Identity,
    ObjParams, FCollisionShape::MakeSphere(50.0f), QueryParams
);

모바일 관점: Bullet Tick마다 물리 쿼리를 실행하므로 총알 수가 많을수록 비용이 증가한다. 현재 Object Pool로 최대 30개로 제한돼 있어 허용 범위지만, 탄막 슈팅이라면 LineTrace 기반이 더 효율적이다.

문제 3. FBX 메시 방향이 탑뷰 기준과 불일치

원인: FBX 모델의 전면 방향이 UE5 좌표계 기준과 달라 탑뷰에서 옆을 향하게 됐다.

해결: 에디터에서 직접 확인하며 SetRelativeRotation 값을 맞췄다.

플레이어: FRotator(0, -90, 90)
적/보스: FRotator(0, 90, 90)

배운 것

• FBX 임포트 메시는 콜리전이 없다. 항상 USphereComponent 또는 UCapsuleComponent로 별도 hitbox를 구성해야 한다.

• MeshComponent는 비주얼 전용, Collision 전용 컴포넌트를 분리하는 것이 명확한 설계다.

• UE5 Chaos에서 QueryOnly 컴포넌트 간 Overlap 이벤트는 불안정할 수 있다. 중요한 충돌은 직접 물리 쿼리로 처리하는 것이 안정적이다.

• 보스 AI는 BT 없이 HP 비율 기반 상태머신으로 충분하다. 모바일에서 BT는 불필요한 오버헤드다.

• FBX 좌표계는 엔진마다 다르다. 임포트 후 항상 에디터에서 방향을 직접 확인해야 한다.

다음 작업

[IronBird #6] 메인화면 + 게임오버 + 점수 시스템 + 회복아이템 + BGM + 이펙트 + 효과음

적 처치 시 100점, 게임오버/클리어 시 점수 표시, 메인화면 레벨 분리.