배경

이번 코드 리뷰에서는 단순히 “기능이 동작하는가”보다,
협업 환경에서 코드가 얼마나 읽기 쉽고 유지보수 가능한지에 대한 피드백을 많이 받았다.

특히 언리얼 멀티플레이 프로젝트는 시스템 규모가 커질수록:

• 초기화 순서
• 리플리케이션
• 라이프사이클
• 객체 책임 분리
• 성능 관리

같은 요소들이 계속 얽히기 때문에,
구현 자체보다 코드 스타일과 구조가 더 중요해질 수 있다는 이야기가 인상적이었다.

이번 피드백들을 다음 프로젝트에서는 실제 코딩 습관 자체로 반영하는 걸 목표로 잡게 됐다.

---

코드 품질과 첫 인상

기능보다 먼저 보이는 건 코드 스타일

이번 리뷰에서 가장 크게 들었던 이야기는
“구조나 리팩토링 이전에 코드 자체가 지저분하면 안 된다”는 부분이었다.

충분히 더 깔끔하게 작성할 수 있는 코드인데도:

• 함수가 너무 길거나
• 네이밍이 일관되지 않거나
• 책임 분리가 안 되어 있거나
• 불필요한 분기와 null 체크가 많으면

코드만 봤을 때:

“실무에서도 이런 식으로 작성하겠구나”

라는 인상을 남기게 된다고 하셨다.

반대로 코드 품질이 올라갈수록:

• 협업 신뢰도 증가
• 코드 리뷰 속도 증가
• 유지보수 비용 감소
• 면접 코드 리뷰 통과 가능성 증가

같은 부분들이 같이 올라간다고 하셨다.

그래서 다음 프로젝트에서는 적어도 하나 정도는:

• 구조
• 네이밍
• 책임 분리
• 데이터 흐름

까지 정말 깔끔하게 관리한 시스템을 만들어보는 걸 목표로 잡아보기로 했다.

---

프로젝트 구조와 파일 관리

Public / Private 폴더 분리

언리얼 기본 구조처럼:

• Public
• Private

폴더를 나누긴 했지만,
리뷰에서는 이 구조는 모듈 dependency를 강하게 관리해야 하는 대규모 구조에서 의미가 크다고 하셨다.

현재 프로젝트 규모에서는 오히려:

• 파일 탐색 어려움
• 구조 파악 시간 증가

같은 문제가 더 커질 수 있다고 하셨다.

그래서 무조건 엔진 구조를 따라가기보다는:

• 기능 단위
• 역할 단위
• 시스템 단위

로 폴더를 정리하는 방향도 충분히 괜찮다는 걸 느꼈다.

---

코드 배치와 클래스 정리

라이프사이클 순서대로 코드 배치

BeginPlay, Tick, EndPlay 같은 라이프사이클 함수들이
호출 흐름 순서대로 정리되어 있으면 코드 리딩이 훨씬 편하다는 피드백을 받았다.

예를 들면:

public:
protected:
private:

접근 지정자 자체보다도:

• 생성자
• BeginPlay
• Tick
• EndPlay
• Override
• 일반 함수
• 콜백
• 변수

순서 흐름이 중요하다고 하셨다.

특히 BeginPlay는 Protected: 영역에 두는 식으로
언리얼 스타일을 맞추는 것도 이야기 나왔다.

---

Region이 필요할 정도면 분리 시점

언리얼 코드 특성상:

• 함수
• 변수
• 함수
• 변수

가 섞이면서 클래스가 비대해지는 경우가 많다.

그런데 리뷰에서는:

region으로 접어야 할 정도면 이미 분리 시점이다

라는 이야기가 인상적이었다.

특히:

• PlayerController
• GameMode
• Manager 클래스

들이 만능 클래스가 되기 쉽기 때문에:

• Component 분리
• Utility 분리
• Subsystem 분리

를 초반부터 의식하는 게 중요하다고 느꼈다.

---

네이밍 관련 피드백

Resolve 접두어 남용하지 않기

기존에는:

ResolveCommandMeta()

같은 이름을 자주 사용했는데,
리뷰에서는 Resolve는:

• 충돌 해결
• 둘 중 하나 선택
• 모호성 해소

같은 상황에서만 쓰는 게 자연스럽다고 하셨다.

대부분의 경우는:

• Get
• Find
• Calculate

정도가 더 명확하다고 하셨다.

---

클래스 이름과 함수명 의미 중복 제거

예를 들어:

UTWPlayerSelectionVisualComponent::GetSelectionVisualData()

보다는:

GetVisualData()

처럼 클래스 컨텍스트에서 이미 의미가 드러나면
함수명은 줄여도 충분하다는 이야기를 들었다.

---

bIs 대신 b만 사용

언리얼에서는 이미 b 접두가 bool 의미를 가지기 때문에:

bIsVisible

보다는:

bVisible

형태가 더 자연스럽다고 하셨다.

사소해 보이지만 이런 네이밍 통일이
프로젝트 전체 인상을 꽤 많이 바꾼다는 걸 느꼈다.

---

생성자와 초기화 관련 피드백

생성자에서 분기 최소화

생성자에서:

if (GetRootComponent())

같은 분기를 타는 코드에 대한 피드백도 받았다.

생성자는:

• 객체 생성 순서
• 부모 → 자식 초기화 흐름

이 굉장히 중요하기 때문에
가능하면 단순한 초기화만 수행하는 게 좋다고 하셨다.

특히 생성자에서:

• Virtual 함수 호출
• 상태 의존 분기
• 복잡한 로직

은 위험할 수 있다고 하셨다.

---

부모 생성자에서 Virtual 호출 금지

객체 생성 시점은:

• 부모 생성자 호출
• 자식 생성자 호출

순서이기 때문에,
부모 생성자에서 Virtual 함수 호출 시
자식 상태가 아직 초기화되지 않은 문제가 생길 수 있다고 하셨다.

그래서 엔진 내부도:

• Initialize 계열 함수
• PostInitProperties
• OnRegister

같은 전용 초기화 타이밍을 따로 사용하는 경우가 많다고 하셨다.

---

라이프사이클 관리

BeginPlay에서 World Null 체크 제거

기존에는 습관적으로:

if (!GetWorld())
{
    return;
}

를 넣는 경우가 많았는데,
BeginPlay 시점은 월드가 이미 존재하는 상황이라
보통은 불필요한 코드라고 하셨다.

오히려 치명적인 문제면:

check(GetWorld());

처럼 즉시 터뜨리는 게 디버깅에 더 도움이 된다고 하셨다.

---

EndPlay와 Destroy 역할 구분

이 부분은 꽤 새롭게 느껴졌다.

기존에는 정리 코드를 Destroy에 넣는 경우가 있었는데:

• Destroy → 명시적 제거
• EndPlay → 실제 종료 처리

개념으로 나눠서 사용해야 한다고 하셨다.

즉:

• BeginPlay 등록
• EndPlay 해제

패턴이 기본이라는 느낌이었다.

---

Utility와 공통 함수 관리

Fragment 접근 래핑

MassEntity Fragment 접근을 매번 직접 쓰기보다:

UTWMassUtility::GetHealthFragment()

같은 Utility 함수로 감싸는 방향을 추천받았다.

특히 팀 프로젝트에서는:

• 접근 방식 통일
• 실수 감소
• 코드 가독성 증가

효과가 크다고 하셨다.

---

Blueprint Function Library 적극 활용

반복적으로 사용하는 기능들은:

• Blueprint Function Library
• Utility Static Class

형태로 모아서 관리하는 게 좋다고 하셨다.

특히:

• Enum 변환
• DataTable 조회
• UI Text 변환
• 태그 조회

같은 부분들은 공통화 가치가 높다고 느꼈다.

---

데이터 관리 방식

FName 하드코딩 줄이기

기존에는:

FName("Enemy")

형태를 자주 사용했는데,
태그들은 별도 헤더나 클래스에 모아놓고 쓰는 게 좋다고 하셨다.

예시 느낌:

namespace TWTags
{
    static const FName Enemy;
}

실수도 줄고 유지보수도 쉬워진다고 하셨다.

---

GameplayTag 적극 활용

액터 태그 기반 조회는 어쩔 수 없는 상황이 아니면 지양하는 게 좋다고 하셨다.

반면 GameplayTag는:

• ini 기반 관리 가능
• Enum처럼 사용 가능
• 데이터 기반 구조화 가능

해서 충분히 괜찮은 방식이라고 하셨다.

---

String 대신 Enum 사용

상태나 이유를 문자열로 직접 관리하기보다:

enum class EEnqueueUnitResult

형태로 정의하고,
UI에서는 Enum에 맞는 Text를 매핑하는 방식이 더 좋다고 하셨다.

특히:

• 다국어 대응
• UI 변경
• 디버깅
• 유지보수

측면에서 장점이 크다고 느꼈다.

---

Enum 값 구성 방식은 Unreal 스타일에 맞추기

기존에는 단순히:

bool CanEnqueue(...);

형태 대신 Enum으로 결과를 반환하는 방향에 대한 이야기로 이해했는데,
실제 피드백 의도는 Unreal에서 자주 사용하는 Enum 구성 스타일에 맞추자는 쪽에 가까웠다.

특히 언리얼에서는 보통:

enum class EEnqueueUnitResult : uint8
{
    None = 0,
    Success,
    QueueFull,
    InvalidUnit,
    Max
};

형태처럼:

• None = 0
• 마지막 Max 추가

패턴을 많이 사용한다고 하셨다.

이렇게 구성하면:

• 기본 초기값 관리가 쉬워지고
• Enum Count 계산 가능하고
• 반복문이나 배열 인덱싱 처리 편하고
• UEnum::GetValueAsString
• StaticEnum<>()
• Enum Utility 함수

같은 언리얼 내부 기능들과도 자연스럽게 맞출 수 있다고 하셨다.

특히 Max를 통해:

static_cast<int32>(EEnqueueUnitResult::Max)

형태로 전체 개수를 관리하는 패턴도 언리얼에서 자주 사용하는 스타일이라는 점이 인상적이었다.

---

DataTable과 캐싱

GetAllRows 반복 사용 줄이기

업그레이드 Row 같은 경우
매번 GetAllRows() 하는 것보다:

• 초기화 시점 캐싱
• TMap 구성
• FindRow 활용

형태가 더 좋다고 하셨다.

게임 중 반복 조회는
캐싱 구조를 먼저 고민하는 습관이 중요하다고 느꼈다.

---

성능 관련 피드백

UGameplayStatics 남용 주의

특히:

GetAllActorsOfClass
GetAllActorsWithInterface

같은 함수들은 내부적으로 전체 액터 순회를 하기 때문에
Tick이나 반복 호출에서 사용하면 성능 문제가 커질 수 있다고 하셨다.

가능하면:

• Subsystem 캐싱
• 등록 구조
• Iterator 제한

방식으로 바꾸는 게 좋다고 하셨다.

---

ISM 갱신 방식 개선

선택 링 같은 월드 UI 시스템에서:

• 매번 Clear
• 다시 Add

하는 구조보다:

• AddInstance
• RemoveInstance
• UpdateInstanceTransform

중심 구조가 더 안정적이라고 하셨다.

특히 InstanceIndex를 구조체로 관리하는 방식이 중요하다고 느꼈다.

---

멀티플레이 구조 관련

HandleStartingNewPlayer 통합

현재는:

• PostLogin
• HandleSeamlessTravelPlayer

를 나눠서 사용했는데,
HandleStartingNewPlayer 기준으로 통합하는 방향이 좋다고 하셨다.

멀티플레이는 초기화 타이밍이 가장 위험한 영역이라는 걸 다시 느꼈다.

---

PlayerState 데이터 분리

PlayerState는:

• 모두에게 보여야 하는 데이터
• Owner만 봐야 하는 데이터

를 분리해야 한다고 하셨다.

특히:

DOREPLIFETIME_CONDITION

을 활용하면:

• OwnerOnly
• SkipOwner
• InitialOnly

같은 세부 제어가 가능하다는 점도 다시 정리하게 됐다.

---

Subsystem과 엔진 기능 활용

FogManager Subsystem화

FogManager 같은 경우도
액터 형태보다:

UTickableWorldSubsystem

형태로 관리하면:

• Tick 가능
• 접근 편의성 증가
• 관리 단순화

장점이 있다고 하셨다.

---

DeveloperSettings 활용

기존에는 경로 하드코딩이나:

ConstructorHelpers::FClassFinder

를 많이 사용했는데,
UDeveloperSettings 기반 관리가 더 좋다고 하셨다.

이렇게 하면:

GetDefault<UTWGameSettings>()

형태로 언제든 접근 가능하고,
SoftPtr 기반 관리도 가능해진다고 하셨다.

---

UI와 엔진 기능 활용

MVVM 플러그인 활용

MVMM을 직접 구현했지만 MVMM의 기능적인 활용도를 적극적으로 반영하지 못했던 부분이 존재해서
언리얼 MVVM 플러그인에 일부 기능 베타지만:

• 포트나이트 등에서도 사용
• 데이터 바인딩 지원
• 콜백 구조 지원

등 장점이 있어서 적극 활용해보고 해당 부분에서 소스코드 보고 수정해서 활용하는게 괜찮을 것 같다고 하셨다..

---

엔진 기본 기능 적극 활용

커서 변경 같은 것도 직접 구현보다:

SetMouseCursorWidget()

같은 엔진 기능을 최대한 활용하는 게 좋다고 하셨다.

이번 리뷰를 통해
엔진이 제공하는 기능은 활용해서 작업 소요량을 줄이고 간단하게 구현할 수 있는 것 최대한 활용해야겠다.

---

오늘의 정리

이번 코드 리뷰에서는 단순히 기능 구현보다
“협업 기준에서 얼마나 읽기 좋은 코드인가”에 대한 피드백을 정말 많이 받았다.

특히 언리얼 멀티플레이 프로젝트는:

• 라이프사이클
• 초기화 순서
• 리플리케이션
• 성능
• 책임 분리

같은 요소들이 계속 얽히기 때문에,
초반부터 코드 스타일과 구조를 의식하는 게 굉장히 중요하다는 걸 다시 느꼈다.

다음 프로젝트에서는 적어도 한 시스템 정도는
“기능도 안정적이고 코드도 깔끔하다”는 느낌으로 끝까지 관리해보는 걸 목표로 해봐야겠다.