To The Core

처음으로 기획부터 개발, 런칭까지 완주해본 게임입니다. 레퍼런스 게임(Beat Stomper)을 개선하면 자동으로 더 재밌어질 거라 생각했는데, 실제로는 개선만으로 체감 재미가 크게 바뀌지 않을 수 있다는 걸 경험했습니다.

상점과 펫 같은 시스템을 추가하고, 한 번의 실수로 즉시 실패하는 구조(위에서 아래로 내려가며 긴장감을 유지)를 넣어 변주를 만들려 했지만, 기대했던 만큼 플레이 경험이 크게 달라지진 않았습니다.

결국 재미를 만드는 건 기능 추가 자체가 아니며 아이디어만으로는 재미있는 게임을 만들 수 없다는 것을 배운 계기가 됐습니다.

성능 최적화를 위해 Object Pooling(오브젝트 풀링)을 적용했습니다. 반복적으로 생성/파괴되는 오브젝트에서 발생할 수 있는 GC 스파이크와 프레임 흔들림을 줄여 플레이 감각을 안정화하는 게 목표였습니다.

다만 최적화는 "많이 할수록 무조건 좋은 것"이 아니라, 상황에 맞게 선택해야 하는 트레이드오프(Trade-off)라는 걸 체감했습니다. 풀링을 과하게 적용하면 메모리 점유, 코드 복잡도, 디버깅 난이도 같은 비용이 커질 수 있었고, 이 경험을 통해 프로파일링(Profiling)으로 병목을 먼저 확인한 뒤 필요한 구간에만 적용하는 접근의 중요성을 확실히 알게 됐습니다.

개발을 직접 하면서 "동작만 되게" 만드는 것과 "확장/유지보수가 되게" 만드는 것의 차이를 체감했습니다. 기능을 그때그때 붙이는 방식보다, 함수(Function) 단위 분리, 모듈/컴포넌트(Component)화, 상태(State)와 데이터 흐름(Data Flow) 정리, 책임 분리(Separation of Concerns)가 결과적으로 개발 속도와 안정성에 큰 영향을 준다는 걸 알게 됐습니다.

이 과정은 기획에도 도움이 됐는데, 구현 관점에서 스코프를 더 현실적으로 쪼개고, 시스템 간 의존성을 고려해 우선순위를 정하고, "지금 넣을 기능 vs 나중에 넣을 기능"을 구분하는 판단이 훨씬 명확해지는 계기가 됐습니다.

당시에는 Git 같은 버전관리 도구 없이, 프로젝트를 압축해서 메일로 주고받는 방식으로 작업했습니다. 초반에는 규모가 작아서 할 만했지만, 기능이 늘어나고 파일이 많아지면서 변경 사항이 서로 꼬이고 충돌이 누적돼서 생산성이 급격히 떨어졌습니다.

특히 "어느 파일이 최신인지", "무슨 변경이 언제 들어갔는지", "충돌이 났을 때 뭘 기준으로 합칠지"를 추적하는 비용이 커지면서, 개발 시간의 상당 부분이 구현이 아니라 정리/복구에 쓰이기도 했습니다. 이 경험은 버전관리가 선택이 아니라 필수 인프라라는 걸 강하게 체감하게 만든 계기였고, 이후 작업에서 변경 이력 관리와 안전한 통합(머지)의 중요성을 명확히 이해하게 됐습니다.