kyvv 님의 블로그

최종 프로젝트 Esport Team Maker 회고

kyvv — Fri, 12 Sep 2025 10:59:47 +0900

ESport Team Maker 프로젝트 회고: 효율적인 데이터 관리와 사용자 경험 개선

1. 프로젝트 개요

프로젝트 이름: ESport Team Maker
개발 기간: 25.6 ~ 25.8 (8주)
참여 인원: 기획 2 / 개발 4

2. 주요 기능 및 개발 과정

본 프로젝트에서는 본인은 ESport 팀을 구성하고 운영하는 과정을 시뮬레이션하는 과정에서 다음과 같은 핵심 기능들을 구현하고, 효율적인 데이터 관리 및 사용자 경험 개선에 집중했습니다.

2.1. 싱글톤 패턴 기반의 일정 관리 시스템

고민: 게임 내 씬 전환 시 일정 정보 유실 방지, 효율적인 일정 관리
해결: 싱글톤 클래스를 활용하여 일정 관리 시스템을 구축했습니다. 씬 전환에 관계없이 일정 정보 및 게임 내 날짜를 유지하고 관리할 수 있도록 했습니다.
구현:
- 각 일정은 인터페이스 상속 대신 부모-자식 상속 구조로 설계하여 유지보수 및 확장성을 용이하게 했습니다. 새로운 일정을 추가하거나 기존 일정을 수정할 때 코드 변경 범위를 최소화할 수 있도록 했습니다.
결과: 게임의 흐름을 끊김 없이 유지하고, 다양한 일정들을 효율적으로 관리할 수 있었습니다.

2.2. CSV -> Scriptable Object 변환 시스템

고민: 기획 단계에서 데이터 변경에 따른 개발 부담 증가
해결: 기획자가 직접 데이터를 수정하고, 빠르게 게임에 반영할 수 있도록 CSVImporter 스크립트를 개발했습니다.
구현:
- CSV 파일을 Scriptable Object로 변환하는 기능을 구현하여, 데이터 수정 후 빠르게 SO들을 수정하여 빌드 테스트를 진행했습니다.
결과: 기획자와 개발자 간의 협업 효율성을 높이고, 데이터 변경에 유연하게 대처할 수 있었습니다.

2.3. JSON 기반 게임 진행 상황 저장 시스템

고민: 게임 진행 상황 및 시스템 정보의 안전하고 효율적인 저장 및 관리
해결: JSON 포맷을 사용하여 게임 진행 상황과 시스템 정보(사운드 설정 등)를 저장하고 관리하는 시스템을 구축했습니다.
구현:
- 간단한 암호화(XOR 변환)를 적용하여 사용자가 데이터 파일을 임의로 조작하는 것을 방지했습니다.
결과: 게임 진행 상황을 안전하게 저장하고, 사용자에게 쾌적한 게임 환경을 제공할 수 있었습니다.

2.4. 큐(Queue)를 활용한 뉴스 피드 시스템

고민: 경기 일정 수행 후 뉴스 피드를 순서대로 보여주는 기능 구현
해결: 큐 자료구조를 활용하여 뉴스 피드가 추가된 순서대로 표시되도록 구현했습니다.
결과: 게임의 몰입도를 높이고, 사용자에게 여러 팀의 경기 결과를 별도의 UI 팝업 없이도 전달할 수 있었습니다.

3. 느낀점

ESport Team Maker 프로젝트를 진행하면서 데이터 관리의 중요성을 다시 한번 깨달았습니다. 특히, CSV -> Scriptable Object 변환 시스템을 통해 기획자와의 협업 효율성을 높이고, 개발 과정을 단축할 수 있었습니다. 앞으로 프로젝트를 진행할 때 데이터 관리 시스템을 더욱 효율적으로 구축하고, 사용자 경험을 개선하기 위한 다양한 시도를 해봐야겠습니다.

JPS 길 찾기

kyvv — Tue, 9 Sep 2025 23:09:24 +0900

JPS는 A* 알고리즘에서 개선된 버전의 길 찾기 알고리즘이다.
A*가 시작 지점부터 계속해서 노드를 생성하면서 목적지까지의 길을 찾아가는 반면 JPS는 이 노드 생성의 시행 횟수를 줄이고자 나왔다. 그로 인해 탐색 범위가 더 많아졌다는 단점이 존재하게 되었지만 메모리 활용 측면에서 노드 생성의 횟수가 줄어드는 이점이 더 큰 경우가 많기 때문에 활용성이 더 좋다고 할 수 있다.
아래는 윈도우 창으로 A*와 JPS를 시각화한 결과물의 사진이다.

A* 길찾기 알고리즘

표시된 칸이 전부 생성된 노드, 노란색 칸은 방문한 노드이며 아래의 JPS와 비교했을 때 생성 및 탐색하는 노드 수가 확연히 많다

JPS를 활용한 길찾기 결과

경로 탐색 일부 코드 - 노드의 메모리 사용량을 줄여보기 위해 탐색 조건인 reason을 UCHAR로 1바이트만 사용하도록 한 후 비트 연산으로 분기를 나눔

우측 방향 탐색 코드 - JPS 노드 생성 조건에 맞을 경우 중단, 그 외에는 계속 탐색

06/18 TIL 프로젝트 마무리 및 발표 자료 정리

kyvv — Wed, 18 Jun 2025 23:27:49 +0900

트러블 슈팅

플레이어 동기화
[발생]

플레이어 입장시 Host 환경 기준으로 입장한 플레이어들의 입력이 반영되지 않음

[원인]

플레이어 Object들이 각 Client 환경 내에서 개인 환경에 대한 입력 권한을 기준으로 입력을 처리하고 무시하면서 Host 환경에 있는 플레이어 Object들의 입력 처리가 이루어지지 않았음
그로 인해 Host 측으로 움직임이 동기화가 이루어지지 않아 Client에서는 움직임이 입력은 되지만 Host 환경에서는 입력 처리가 되지 않아서 움직이지 않게 되었고, 이로 인해 Client 오브젝트들이 Host에서 고정되는 현상이 생겼음

[개선 시도]

Fusion에 기본 제공 기능이 있는지 파악 시도
입력 값은 각 플레이어 고유 적용되도록 제한이 걸려 있는 상황에서 움직임까지 제한할 필요 없다는 판단

[해결 완료]

SIMPLE KCC 라는 Fusion2 제공 기능을 통해 캐릭터 컨트롤러 동기화를 맞추고 있다는 공식 문서와 멀티 환경에서 입력값이 넘어오는 것을 공식 문서 및 디버깅으로 확인한 후 우측의 코드를 주석 처리함으로써 해결

카메라 핸들

[발생]

- 시네머신을 적용하여 카메라 구현하였으나 총기 반동이 원활하지 않음

[원인]

- 시네머신에서 다른 방식으로 로테이션 값을 처리하여 고정됨.
- 또한 모든 캐릭터 조작을 담당하는 ProcessInput 함수에서 좌우이동, RefreshCamera에서 상하이동을 따로 구현되어 있는 걸 발견.
- 카메라 조작 메소드 RefreshCamera 함수 추적 해보니 여러 곳에 사용되고 있으나 동작하지 않음. (코드 가독성 문제 발생)
- 카메라 움직임이 일반구현 → 서버구현 → 시네머신구현 등 다른 사람들의 손을 걷치며, 서로 다른 방식으로 구현한 것으로 판단됨.

[개선 시도]

- 총기 반동 적용을 위해 기본 카메라만 이용
- 카메라 조작 메서드 RefreshCamera가 오용된 부분을 제거 및 재정의

[해결 완료]

- RefreshCamera 에 상하좌우 회전코드를 전부 작성하여 가독성 상승. ProcessInput 함수에 넣어 플레이어 조작에 포함됨을 표현.

프로젝트를 진행하면서 fusion2에 대해 파악한 점
- 네트워크 오브젝트로 동기화를 맞추고자 한다면 자식부터 부모까지 네트워크 오브젝트가 붙어있어야지 동기화가 잘 이루어진다- 캐릭터의 메인 카메라에 네트워크 오브젝트가 붙게 된다면 레이 캐스트를 카메라 기준으로 쏠 시, 호스트-클라이언트 환경에서는 클라의 ray가 다른 캐릭터(주로 호스트)의 카메라로 동기화가 이루어진다- InputAuthority : 현재 클라이언트가 이 객체에 대해서 입력(컨트롤)이 가능한가- StateAuthority : 이 객체가 호스트 환경에 있는지

모든 네트워크 프리팹은 fusion에서 실행 시 config 파일로 올라가 등록이 되며, runner.spawn(네트워크 프리팹)/despawn을 통해 생성/삭제를 할 수 있으며 이는 네트워크에 동기화를 맞춰준다

06/05 FSM + BT / 개인 과제 FSM 작성하기

kyvv — Thu, 5 Jun 2025 22:21:15 +0900

오늘 배운 것

유니티에서 FSM과 BT를 조합하여 게임 캐릭터의 AI를 설계하는 구조에 대해 학습했다.

핵심 개념 정리

1. FSM (Finite State Machine, 유한 상태 기계)

캐릭터의 "상태(state)"를 명확하게 구분하고, 상태 전이 조건을 통해 제어함.
예시 상태: Idle, Patrol, Chase, Attack, Die 등
각 상태는 고유한 로직과 전이 조건을 가짐.

2. BT (Behavior Tree, 행동 트리)

상태 내부에서의 세부 행동들을 계층적 트리 구조로 표현함.
트리 노드는 선택(Selector), 순차(Sequence), 조건(Condition), 행동(Action) 등으로 구성.
복잡한 AI 로직을 분기와 반복 구조로 간결하게 표현 가능.

FSM + BT 조합 구조

FSM	상위 레벨에서 전체 캐릭터의 상태를 결정. (예: 공격, 추적, 순찰 등)
BT	각 상태(FSM State) 내에서 세부 행동을 정의. (예: 공격 중에도 회피, 스킬 선택 등 판단 포함)

[ FSM ]
└── IdleState
└── PatrolState
    └── [BT] -> Waypoint 탐색 → Move → 다음 Waypoint
└── ChaseState
    └── [BT] -> 적 탐지 → 추적 → 시야 확인
└── AttackState
    └── [BT] -> 사거리 확인 → 스킬 선택 → 공격 or 후퇴

⚙️ 유니티 구현 방식 예시

✅ FSM 구현

IState 인터페이스 정의 → 상태별 클래스(IdleState, ChaseState) 구현
StateMachine 클래스에서 상태 전이 및 현재 상태 관리

public interface IState
{
    void Enter();
    void Update();
    void Exit();
}

✅ BT 구현

간단한 노드 기반 구조 정의 (BTNode, Selector, Sequence, Condition, Action)
각 노드에서 Evaluate() 함수로 결과 반환 (Success, Failure, Running)

public abstract class BTNode
{
    public abstract BTResult Evaluate();
}

✅ 통합 사용 예

// FSM에서 상태 전이
if (enemyDetected)
    stateMachine.ChangeState(new ChaseState());

// 각 상태 내부에서 BT 사용
public class AttackState : IState
{
    private BTNode attackTree;

    public void Enter()
    {
        attackTree = new Selector(
            new SkillAttackNode(),
            new MeleeAttackNode(),
            new RetreatNode()
        );
    }

    public void Update()
    {
        attackTree.Evaluate();
    }

    public void Exit() { }
}

✅ 장점

FSM으로 전체 흐름 제어, BT로 세부 행동 제어 → 명확한 역할 분리
재사용성, 유지보수성 뛰어남 (특히 BT는 복잡한 행동도 모듈화 가능)

⚠️ 유의점

FSM 상태 전이가 많아질 경우 전이 조건 정리가 필요 → 전이 테이블 도입 권장
BT가 깊어질수록 성능 및 디버깅 부담이 커질 수 있음 → 시각화 도구 활용 고려

✍️ 오늘의 인사이트

단일 FSM이나 단일 BT만 사용하는 것보다, 두 구조를 역할에 따라 조합했을 때 훨씬 더 유연하고 명확한 AI 설계를 할 수 있다. 특히 복잡한 전투 AI에서는 FSM으로 큰 흐름을 관리하고, BT로 세밀한 판단을 나누는 것이 효과적이다.

참고 자료

Unity AI Programming - FSM vs BT 비교
GDC 강연: Behavior Trees for Next-Gen AI
책: Game AI Pro 시리즈

-개인 과제 FSM 제작 현황

강의에서 작성한 코드를 활용해서 필요한 기능만 빼서 사용하려고 했으나, 일부분만 보고 사용하기에는 전체 구조를 파악하기가 어려워져 그냥 처음부터 만들어 나가기로 결정했다.
만들면서 헷갈리는 부분을 강의 코드에서 도움 받는 형식으로,, 이것 때문에 쓸데 없이 시간을 많이 허비했지만, 그래도 전체 코드를 훑어 볼 수 있었던 시간이 되었다. 일단 주말동안 추가 작업은 피할 수가 없구나..

06/04 TIL 두트윈(feat. 메서드 체이닝)

kyvv — Wed, 4 Jun 2025 22:10:17 +0900

"두트윈(DOTween)"은 Unity용 고성능 트위닝(tweening) 라이브러리로, 오브젝트의 이동, 회전, 크기, 색상, 알파 값 등의 애니메이션을 간단하고 직관적으로 처리할 수 있게 해줍니다.
(DOTween은 Demigiant에서 만든 라이브러리입니다.)

✅ DOTween의 주요 특징

특징설명

고성능	Unity 내부에서 메모리를 최소화하고 빠르게 작동하도록 최적화되어 있음.
간편한 문법	메서드 체이닝 기반의 직관적인 API 제공.
다양한 트위닝 지원	위치, 회전, 스케일, 컬러, 알파, UI 등 다양한 요소 애니메이션 지원.
시퀀스 지원	여러 트윈을 순차적으로 또는 동시에 실행 가능.
시간 스케일 무시 가능	SetUpdate(true)로 Time.timeScale = 0일 때도 동작 가능.
Play, Pause, Kill, Restart 등 제어 기능 풍부	애니메이션 상태를 제어하는 다양한 함수 지원.

✅ 기본 사용법 예시

1. 초기 설정

Unity 패키지 매니저 또는 Asset Store에서 설치.
또는 Tools > DOTween Utility Panel에서 설치 완료 확인 후 Setup.

2. 위치 트윈 (Transform 이동)

transform.DOMove(new Vector3(5, 0, 0), 1f); // 1초 동안 (5,0,0)으로 이동

3. 회전 트윈

transform.DORotate(new Vector3(0, 180, 0), 2f);

4. 스케일 트윈

transform.DOScale(Vector3.zero, 1f); // 1초 동안 점점 작아짐

5. 색상 트윈 (SpriteRenderer 등)

spriteRenderer.DOColor(Color.red, 1f);

✅ 메서드 체이닝 예시

transform.DOMoveX(3f, 1f)
         .SetEase(Ease.InOutBounce)
         .SetLoops(2, LoopType.Yoyo)
         .OnComplete(() => Debug.Log("Move done!"));

SetEase: 애니메이션 곡선
SetLoops: 반복 설정 (횟수, 타입)
OnComplete: 완료 시 콜백

✅ Sequence 사용 예시 (복합 애니메이션)

Sequence seq = DOTween.Sequence();
seq.Append(transform.DOMoveX(3f, 1f))
	.Append(transform.DOScale(2f, 0.5f))
    .Join(transform.DORotate(new Vector3(0, 180, 0), 1f))
    .AppendCallback(() => Debug.Log("Sequence Done"));

Append: 순차 실행
Join: 병렬 실행
AppendCallback: 중간에 함수 삽입

✅ 주의점 및 팁

항목설명

DOTween 초기화 필수	설치 후 DOTween Utility Panel에서 Setup DOTween 필수.
PlayMode에서도 잘 동작함	TimeScale 0에서도 애니메이션 가능 (SetUpdate(true))
오브젝트가 파괴되면 트윈도 중단됨	SetAutoKill(false)로 방지하거나, Kill() 사용 권장.
GC 최소화됨	성능에 민감한 프로젝트에서도 부담이 적음.
UI 지원	RectTransform.DOAnchorPos, CanvasGroup.DOFade 등 UI 요소도 트윈 가능

✅ 대표적인 트윈 함수 정리

함수설명

DOMove, DOMoveX/Y/Z	위치 이동
DORotate, DOLocalRotate	회전
DOScale, DOScaleX/Y/Z	스케일
DOColor	색상 변경
DOFade	알파 변경
DOFillAmount	이미지 채우기
DOAnchorPos	UI 위치 이동
DOText	텍스트 애니메이션 (TextMeshPro 등)

✅ C++에서 메서드 체이닝을 사용하는 대표 사례

1. C++ iostream (입출력 스트림)

#include <iostream>

int main() {
	std::cout << "Hello, " << "world!" << std::endl;
    return 0;
}

std::cout은 operator<<를 체이닝할 수 있도록 설계되어 있음.
operator<<는 참조(보통 ostream&)를 반환하므로, 다음 호출이 이어질 수 있음.

std::ostream& operator<<(std::ostream& os, const char* str);

2. C++ 사용자 정의 클래스에서의 메서드 체이닝

class Builder { 
	public: Builder& setA(int val) { a = val; return *this; } 
    
    Builder& setB(int val) { b = val; return *this; } 
    
    void print() const { std::cout << "A: " << a << ", B: " << b << '\n'; } 
    
    private: int a = 0; int b = 0; 
}; // 사용 예시 Builder obj; obj.setA(10).setB(20).print();

✅ C#에서 메서드 체이닝을 사용하는 대표 사례

1. StringBuilder (System.Text)

using System.Text;

var sb = new StringBuilder();

sb.Append("Hello ")
  .Append("World!")
  .AppendLine();
    
Console.WriteLine(sb.ToString());

Append, AppendLine 등이 모두 StringBuilder 자신을 반환합니다.

2. LINQ 메서드 체이닝

using System.Linq;

var result = Enumerable.Range(1, 10)
					   .Where(x => x % 2 == 0)
                       .Select(x => x * x)
                       .ToList();

foreach (var x in result) Console.WriteLine(x);

Where, Select, ToList 등 LINQ 메서드들이 체이닝 가능하도록 IEnumerable을 반환.

요약 비교

언어체이닝 사용 예반환 방식

C++	std::cout, 사용자 정의	참조 (&) 또는 포인터 (*this)
C#	StringBuilder, LINQ	자기 자신 또는 IEnumerable

06/02 팀프로젝트 마무리 및 새롭게 배워갈만한 부분

kyvv — Mon, 2 Jun 2025 21:06:10 +0900

어드레서블을 통한 리소스 관리 / 비동기 호출을 통한 로딩씬 UI 구현

Behavior Tree를 활용한 상태 제어(FSM 혼합 사용 가능함)
싱글톤 클래스의 템플릿(제네릭)

확장 메서드를 사용하여 반복적 코드 축약

자세한 내용들은 시간이 날 때 한 번 정리할 필요가 있음(당장은 개인 인강과 제공된 강의를 수강할 예정)

05/30 TIL SpawnManager 역할 고민, 낮/밤 사이클 전환, NavMesh SamplePosition

kyvv — Fri, 30 May 2025 22:21:37 +0900

SpawnManager 리팩토링 및 역할 확장

❓ 의문점

SpawnManager가 오브젝트 풀만 관리하면 되는가?
씬 전환 시 프리팹 참조를 잃었을 때 다시 로드해야 하는가?

✅ 해결점

기존 역할에 "스폰 위치 지정" 기능을 추가하면서 더 강력한 SpawnManager로 확장 가능.
씬 전환 후 ScriptableObject의 참조는 유지되지만, 해당 프리팹은 로딩 상태에 따라 풀/딕셔너리에 재세팅 필요.

예시

csharp

복사편집

// Init 시 매번 prefab 재세팅 ItemData data = ResourceManager.Instance.GetResource<ItemData>(key); if (data != null) prefabs[key] = data.prefab;

낮/밤 사이클에서 빛 오브젝트 전환

❓ 의문점

Light.intensity로 오브젝트를 SetActive() 하면 왜 낮/밤 빛이 동시에 켜지는가?

✅ 해결점

float 비교 (== 0.15f)는 오차 때문에 불안정.
명확한 낮/밤 시간 구간 (time) 기준으로 켜고 끄는 것이 더 안정적.

예시

csharp

복사편집

bool isDayTime = time >= 0.25f && time <= 0.75f; sun.SetActive(isDayTime); moon.SetActive(!isDayTime);

Input System - 숫자 키 1~7 처리

❓ 의문점

Input System에서 숫자 키를 누르면 어떤 값을 받는가?
ReadValue<int>() - 1 방식으로 0~6 인덱스를 정확히 받을 수 있는가?

✅ 해결점

Input System에서는 각 키에 별도 액션을 바인딩하거나
Key.1 ~ Key.7을 수동으로 매핑해서 처리해야 정확함.

예시

csharp

복사편집

if (Keyboard.current.digit1Key.wasPressedThisFrame) UseQuickSlot(0); // ... 반복

인벤토리 ↔ 퀵슬롯 간 아이템 이동

❓ 의문점

ItemSlot을 참조형으로 넘기면, 퀵슬롯 수량이 바뀌었을 때 인벤토리도 같이 바뀌지 않나?

✅ 해결점

참조형이라면 당연히 연결됨.
깊은 복사를 위해 new ItemSlot(otherSlot) 같은 복사 생성자를 구현해야 안전.

예시

csharp

복사편집

public ItemSlot(ItemSlot other) { this.item = other.item; this.count = other.count; }

NavMesh 랜덤 위치 지정 함수

❓ 의문점

NavMesh.SamplePosition()이 실패하는 경우가 있는가?
왜 항상 범위 내에서 결과가 나오지 않을까?

✅ 해결점

샘플링 범위 내 지형이 없다면 실패함.
반복 재시도 + range 조정으로 보완 가능.

예시

csharp

복사편집

for (int i = 0; i < 10; i++) { if (NavMesh.SamplePosition(...)) return hit.position; } Debug.LogWarning("유효한 위치를 찾지 못했습니다.");

⏳ 날짜 카운트 방식

❓ 의문점

time = (time + rate * deltaTime) % 1 구조에서 언제 날짜를 증가시켜야 할까?

✅ 해결점

prevTime > time인 순간은 0을 지나간 시점, 즉 하루가 지난 것으로 판단 가능.

예시

csharp

복사편집

if (time < prevTime) ++dayCount;

정리

단순 기능에서 역할을 확장할 땐 모듈화와 책임 분리가 핵심
Unity의 float 기반 값 비교는 절대 == 하지 말 것
Input System의 유연성은 높지만, 복잡한 키 매핑은 명시적으로 처리해야 확실
데이터 구조가 참조형일 땐, 상태 공유에 주의하고 필요시 깊은 복사 고려
NavMesh나 시간 기반 계산 등은 실패 가능성에 대한 대비 로직을 항상 포함

05/29 인벤토리 시스템 구조 개선 및 버그 수정

kyvv — Thu, 29 May 2025 21:59:54 +0900

✅ 학습 내용

PlayerInventoryController 클래스 내에서 items 리스트는 inventoryItems 리스트와 중복되는 데이터라는 사실을 파악함.
items는 ItemSlot 내부의 item과 1:1로 연결되어 있어, 모든 기능을 inventoryItems만으로 구현 가능.
불필요한 리스트(items)는 메모리 낭비 및 유지보수 부담을 야기할 수 있으므로 제거 가능.

️ 리팩토링 방향

items[index]를 전부 inventoryItems[index].item으로 변경.
외부에서 ItemData 목록이 필요할 경우:
csharp

복사편집

public IReadOnlyList<ItemData> Items => inventoryItems.Select(slot => slot.item).ToList().AsReadOnly();
ItemSlot 클래스 내 item을 public ItemData Item { get; private set; } 식으로 캡슐화할 계획.

느낀 점

구조 설계 시 중복 데이터는 가능한 줄이고, **단일 책임 원칙(SRP)**에 따라 필요한 데이터는 한 곳에서만 관리하도록 설계하는 것이 유지보수에 훨씬 유리하다.
데이터와 UI는 분리하되, 내부 구조는 최대한 단순하고 명확하게 가져가자.

버그 수정

인벤토리에서 장착 아이템을 선택할 경우, 장착 슬롯으로 옮겨가는데 이 때 장착 아이템의 우측에 있던 아이템도 함께 지워지는 문제가 발생

-> 아이템 슬롯을 클릭할 때와 장착 아이템을 선택했을 때 로직이 모두 해당 아이템을 지우도록 호출되어서 생긴 문제(장착 함수에서 당연하게도 선택된 아이템이 인벤토리에서 지워질 것이라는 예상에 작업한 내용이 위와 같은 문제를 발생시킨 것)
따라서 장착 함수 내에서 아이템을 지우는 코드를 제거하는 방향으로 합의

05/28 TIL Unity 매니저 싱글톤 설계 및 Resources.Load 문제 디버깅

kyvv — Wed, 28 May 2025 21:12:23 +0900

✅ 오늘 해결한 문제

SpawnManager에서 NullReferenceException 발생
Instance 호출 시 new GameObject().AddComponent<T>() 구조가 문제인가 의심했지만, 실제 원인은 Resources.Load()가 null을 반환한 상태에서 .gameObject를 호출한 것이었다.

오늘 배운 것

1. Unity에서 AddComponent 시점에 Awake가 즉시 호출됨

AddComponent<SpawnManager>() → 즉시 Awake() 호출
따라서 Awake() 안에서 Instance나 다른 매니저 참조 시 순환 참조 위험 존재
해결: Awake()에서는 참조 지양, Init() 분리해서 명시적 초기화

2. Resources.Load()는 경로가 잘못되면 null을 반환한다

.gameObject처럼 바로 접근하면 NRE 발생
항상 null 체크 필요:
실제 마주한 문제점 --> 경로 문자열에 오타로 인해서 Prefab을 찾을 수 없었음

var rock = Resources.Load<GameObject>("경로"); if (rock == null) { Debug.LogError("Prefab을 찾을 수 없습니다."); }

3. Resources.Load<GameObject>()의 반환값은 GameObject다

.gameObject를 붙이면 오히려 불필요하거나 오류 발생 가능성
즉, 아래처럼 사용하면 충분함:

var rock = Resources.Load<GameObject>("Items/Prefabs/Resource/stone");

4. 매니저 초기화는 생성(Create)과 초기화(Init)를 분리하자

Instance 생성과 초기화가 꼬이지 않도록 분리
예시:

SpawnManager.CreateIfNeeded(); SpawnManager.Instance.Init();

리팩터링 고려사항

Resources.Load()를 대체할 수 있는 Addressable 시스템 도입 고려
매니저 자동 등록 시스템: ManagerBootstrapper, IModule 인터페이스 설계 가능
오브젝트 풀을 T 타입 기반으로 설계해 재사용성 강화

05/27 TIL 오브젝트 풀에 관한 고찰

kyvv — Tue, 27 May 2025 21:15:17 +0900

✅ 오늘 배운 것

1. 프리팹이 다르면 풀도 나눠야 한다

WoodItem, RockItem처럼 ResourceItem을 상속한 클래스가 여러 개 있더라도,
프리팹(GameObject) 이 다르면 하나의 풀에서 관리하면 안 됨.
ObjectPool<T>의 createFunc는 단 하나의 프리팹으로 고정되기 때문에
나중에 다른 프리팹을 넣거나 생성하면 의도하지 않은 결과가 발생함.

2. 풀은 '타입'이 아닌 '프리팹 단위'로 관리

PoolManager<ResourceItem> 같은 구조에서 한 풀에 여러 종류의 아이템을 넣고 싶을 수 있으나,
각 프리팹마다 별개의 PoolManager를 생성하는 방식이 안전하고 명확하다.
따라서 Dictionary<GameObject, PoolManager<ResourceItem>> 혹은
Dictionary<string, PoolManager<ResourceItem>> 와 같은 구조를 사용하는 것이 좋다.

3. 프리팹 기준 키로 풀 분기 처리

if (!pools.ContainsKey(prefab)) 
{
 	pools[prefab] = new PoolManager<ResourceItem>(prefab.GetComponent<ResourceItem>(), transform);
}

프리팹 기준으로 풀을 만들어두고, 같은 프리팹이면 재사용.
다른 프리팹이 들어오면 새로 풀을 만들어 할당.

정리

구분	잘못된 예	올바른 예
풀 기준	ResourceItem 타입으로 하나의 풀	프리팹마다 PoolManager 분리
생성 방식	createFunc 하나로 여러 종류 생성	프리팹 기준으로 개별 생성 함수
사용 구조	PoolManager<ResourceItem> 하나로 다 처리	Dictionary<Prefab, PoolManager<ResourceItem>> 사용

️ 느낀 점

처음에는 "같은 타입인데 왜 다른 풀로 나눠야 하지?"라고 생각했지만,
Unity에서 프리팹 = 생성의 기준이기 때문에 풀도 프리팹 단위로 쪼개는 것이 자연스러움.
프리팹 별로 풀이 생성되는 측면이 유지/보수 측면에서 더 유리하다.(기능별로 인터페이스를 받거나 상속 구조로 갈 수는 있긴 하다)
설계를 미리 고려하지 않으면 풀 구조가 꼬일 수 있기 때문에
프리팹 ↔ 풀의 관계를 명확히 분리하는 설계가 중요하다는 걸 체감했다.

️ 내일 할 일

SpawnManager 내에서 프리팹 기준으로 풀을 관리하는 구조 완성
ItemData에 GetPrefab() 같은 접근자를 두어 풀 등록 시 사용하기 쉽게 개선
풀 생성과 반환 시 디버깅 로그 추가로 흐름 추적

kyvv 님의 블로그

최종 프로젝트 Esport Team Maker 회고

ESport Team Maker 프로젝트 회고: 효율적인 데이터 관리와 사용자 경험 개선

1. 프로젝트 개요

2. 주요 기능 및 개발 과정

2.1. 싱글톤 패턴 기반의 일정 관리 시스템

2.2. CSV -> Scriptable Object 변환 시스템

2.3. JSON 기반 게임 진행 상황 저장 시스템

2.4. 큐(Queue)를 활용한 뉴스 피드 시스템

3. 느낀점

JPS 길 찾기

06/18 TIL 프로젝트 마무리 및 발표 자료 정리

트러블 슈팅플레이어 동기화[발생]

카메라 핸들

06/05 FSM + BT / 개인 과제 FSM 작성하기

오늘 배운 것

핵심 개념 정리

1. FSM (Finite State Machine, 유한 상태 기계)

2. BT (Behavior Tree, 행동 트리)

FSM + BT 조합 구조

⚙️ 유니티 구현 방식 예시

✅ FSM 구현

✅ BT 구현

✅ 장점

⚠️ 유의점

✍️ 오늘의 인사이트

참고 자료

06/04 TIL 두트윈(feat. 메서드 체이닝)

✅ DOTween의 주요 특징

✅ 기본 사용법 예시

1. 초기 설정

2. 위치 트윈 (Transform 이동)

3. 회전 트윈

4. 스케일 트윈

5. 색상 트윈 (SpriteRenderer 등)

✅ 메서드 체이닝 예시

✅ Sequence 사용 예시 (복합 애니메이션)

✅ 주의점 및 팁

✅ 대표적인 트윈 함수 정리

✅ C++에서 메서드 체이닝을 사용하는 대표 사례

1. C++ iostream (입출력 스트림)

2. C++ 사용자 정의 클래스에서의 메서드 체이닝

✅ C#에서 메서드 체이닝을 사용하는 대표 사례

1. StringBuilder (System.Text)

2. LINQ 메서드 체이닝

요약 비교

06/02 팀프로젝트 마무리 및 새롭게 배워갈만한 부분

05/30 TIL SpawnManager 역할 고민, 낮/밤 사이클 전환, NavMesh SamplePosition

SpawnManager 리팩토링 및 역할 확장

❓ 의문점

✅ 해결점

예시

낮/밤 사이클에서 빛 오브젝트 전환

❓ 의문점

✅ 해결점

예시

Input System - 숫자 키 1~7 처리

❓ 의문점

✅ 해결점

예시

인벤토리 ↔ 퀵슬롯 간 아이템 이동

❓ 의문점

✅ 해결점

예시

NavMesh 랜덤 위치 지정 함수

❓ 의문점

✅ 해결점

예시

⏳ 날짜 카운트 방식

❓ 의문점

✅ 해결점

예시

정리

05/29 인벤토리 시스템 구조 개선 및 버그 수정

✅ 학습 내용

️ 리팩토링 방향

느낀 점

버그 수정

05/28 TIL Unity 매니저 싱글톤 설계 및 Resources.Load 문제 디버깅

✅ 오늘 해결한 문제

트러블 슈팅

플레이어 동기화
[발생]