오늘은 선거일이라 공식적인 부트캠프 일정은 쉬는 날이었다. 하지만 어딘가 마음이 편치 않았다. 프로젝트가 끝난 그 다음 날, 마음 한구석에 느껴지는 허전함과 '조금 더 해보고 싶다'는 갈증 같은 것. 결국 나는 조용히 젭에 출석 도장을 찍었다.
[문제점]
매번 새로운 프로젝트를 시작할 때마다 똑같은 셋업을 반복하는 게 비효율적이라는 생각이 들었다. 그때 문득, 2주 전 채한승 튜터님이 주셨던 피드백이 떠올랐다.
"인게임 데이터/클래스 등과의 연관성 없이 기능을 모듈화하라. Singleton의 제네릭화, EventManager처럼 재사용 가능한 기능들을 현재 프로젝트의 인게임 UI나 데이터와 최대한 연관 짓지 말고 만들어두면 다음 프로젝트에선 이미 구현된 상태에서 출발할 수 있다."
그 말이 이상하게 머릿속에 남아 있었고, 오늘이야말로 그걸 실천에 옮길 때라고 느꼈다.
[시도한 것]
Singleton<T> 클래스
MonoBehaviour 기반 제네릭 싱글톤
EventManager
문자열 키 기반의 이벤트 등록/해제/호출 기능
ClearAllEvents로 씬 전환 시 리스너 정리
SceneLoader + SceneType Enum
씬 이름 하드코딩 제거
ObjectPool<T>, ObjectPoolManager, IPoolable
제네릭 기반 풀링 시스템
키 기반으로 다양한 오브젝트 타입을 관리
GameManager + GameState Enum
게임 상태 흐름을 통합 관리
전부 인게임 UI나 특정 캐릭터/오브젝트에 엮이지 않게끔 철저히 분리했다. 목표는 "어떤 프로젝트에서도 바로 쓸 수 있는 기초 공사"였다.
[강의를 통해 얻은 인사이트]
오전에 챌린지반 OT 강의를 들었다. 김영호 튜터님은 부트캠프 이후 우리가 준비해야 할 것들에 대해 이야기해주셨다. CS, 코딩테스트, 포트폴리오, Git 잔디... 그중에서도 특히 코딩테스트에 대한 부담이 크게 와닿았다. 실력이 상향평준화된 시장에서 결국 체계적인 대비가 필수라고 느꼈다.
또 하나 인상 깊었던 강의는 Unity 프로젝트 초기 구성 강의였다. SRP, 매니저 클래스의 책임 분리, 싱글톤 적용 범위에 대한 고민을 던져주셨다.
GameManager 하나로 다 묶으면 편하지만 무거워지고, 각 매니저를 개별 싱글톤으로 만들면 분산 관리가 어렵다. 정답은 없지만 SRP를 지키는 방향으로 유연하게 판단해야 한다.
이 강의 덕분에 내가 오늘 만든 구조들이 단순히 기능의 집합이 아니라 설계 철학에 기반한 첫 시도라는 확신이 생겼다.
[배운 것]
이번 작업을 하면서 제네릭(Generic) 이라는 개념을 실용적인 방향에서 깊게 이해할 수 있었다. 특히 ObjectPool<T> 같은 구조는 내가 재사용성이라는 개념을 단순히 말로만 알고 있었다는 걸 깨닫게 했다.
또한 싱글톤이라는 디자인 패턴을 단순한 코드 암기에서 벗어나 "어디까지 싱글톤을 적용할 것인가", **"SRP(단일 책임 원칙)를 해치지 않으면서 어떻게 매니저를 조율할 것인가"**에 대해 고민하게 되었다.
예를 들어, GameManager 하나로 모든 걸 통합하면 편할 순 있지만 무거워진다. 반대로 매니저들을 다 개별 싱글톤으로 만들면 너무 분산되고 구조 파악이 어려워질 수도 있다. 결국 중요한 건 정답이 아니라 적절함, 그리고 그 안에서 책임을 분리하는 감각이라는 걸 느꼈다.
[느낀 점]
이제는 막연한 감각으로 코드를 쓰기보다는, “다음 프로젝트에서 바로 써먹을 수 있을까?”라는 질문을 스스로에게 던지게 된다. 어쩌면 오늘의 베이스 패키지는 그 질문에 대한 첫 번째 대답이 될지도 모른다.
[계획]
오늘부터 매일 TIL을 마친 후엔 코딩 테스트 한 문제를 풀기로 결심했다. 지금은 실력이 부족해도, 매일 잔디를 심고 작은 성취를 기록하다 보면 언젠가는 더 넓은 정원을 가꿀 수 있을 거라 믿는다.
