지난 7월 28일부터 8월 20일까지, 약 한 달간 진행했던 Project Escape가 막을 내렸습니다. 짧지 않은 시간 동안 많은 시도와 고민을 거쳤고, 그 과정에서 여러 배움과 한계도 함께 마주했습니다. 이번 글에서는 프로젝트 종료 후 돌아본 개선점과 회고를 기록하려 합니다.
부족했던 점과 개선점
프로젝트 구조의 복잡도와 데이터 이동 빈도 예측 실패
이번 프로젝트에서 가장 크게 부딪힌 문제는 예상보다 복잡해진 구조와 데이터 이동의 빈도 증가였습니다.
처음에는 퀵 슬롯이 인벤토리의 역할을 겸하고 있었고, 여기서 아이템을 꺼내 손에 들고 사용하는 흐름을 단순하게 설계했습니다. 단일 책임 원칙을 지키고자, 퀵 슬롯과 Usable 관리 기능을 분리하여 Hero에 컴포넌트와 인터페이스를 부착하는 구조를 채택했지요. 당시에는 입력이 들어오면 Hero가 퀵 슬롯 매니저에서 아이템 포인터를 가져오고, 이를 Usable 매니저가 처리하는 방식이 가장 깔끔하다고 생각했습니다.
하지만 기능이 점점 추가되면서 Hero가 두 매니저를 중재해야 하는 역할이 늘어났고, 그 과정에서 퀵 슬롯 매니저와 Usable 매니저의 결합도가 높아지는 문제가 발생했습니다. 또한 언리얼에 대한 이해 부족으로, 컴포넌트가 직접 액터를 제어하지 못하고 오히려 액터가 컴포넌트를 호출해 동작을 구현하는 방식이 복잡도를 더 키웠습니다.
결과적으로, SOLID 원칙을 의식적으로 따르려 했음에도 불구하고, 데이터 이동 경로를 충분히 예측하지 못한 탓에 오히려 SOLID 원칙을 위반하는 상황까지 생겨났습니다.
향후 개선 방법
이번 프로젝트를 통해 가장 크게 느낀 점은 데이터 흐름을 사전에 충분히 예측하는 것이 얼마나 중요한가였습니다. 기능을 설계하기 전, 데이터가 어디에서 생성되고 어디로 전달되며 얼마나 자주 이동하는지를 먼저 그려보는 습관이 필요하다는 것을 깨달았습니다. 이렇게 하면 불필요하게 중재자가 늘어나거나, 특정 클래스에 과도한 책임이 집중되는 문제를 줄일 수 있습니다.
또한, 언리얼 엔진의 컴포넌트 구조에 대한 이해 부족 역시 복잡도를 키운 원인이 되었습니다. 앞으로는 액터 중심이 아니라 컴포넌트가 주도적으로 동작하는 구조를 설계하는 연습을 더 해야겠다고 생각합니다. 이를 통해 불필요한 의존성을 줄이고, 각 컴포넌트가 자신이 맡은 책임을 더 명확하게 수행할 수 있도록 만들고 싶습니다.
이번에 SOLID 원칙을 맹목적으로 적용하려다 오히려 위반하는 상황을 경험하면서, 원칙은 절대적인 답이 아니라 프로젝트 맥락 속에서 유연하게 적용해야 하는 참고 도구라는 점을 실감했습니다. 앞으로는 원칙을 무조건 지키는 데 집중하기보다, 실제로 프로젝트의 단순성과 유지보수성을 높이는 방향으로 선택하고 적용하려 합니다.
또 하나의 배움은 복잡도 관리의 중요성입니다. 새로운 기능을 추가할 때마다 기존 구조가 단순성을 유지하고 있는지 꾸준히 점검하고, 필요하다면 리팩토링을 통해 구조를 정리해야 합니다. 이 과정에서 불필요하게 늘어난 인터페이스나 중재 계층을 과감히 줄여, 추상화가 실제로 단순성을 높이는 역할을 하도록 해야 합니다.
마지막으로, 이번 경험을 통해 게임플레이와 시스템적 요구 사이의 균형을 잡는 것이 설계의 핵심이라는 것을 알게 되었습니다. 플레이어 경험을 해치지 않으면서도 유지보수 가능한 구조를 만들기 위해, 더 넓은 시야에서 객체와 시스템을 바라보고 장기적인 관점에서 설계를 고민하는 습관을 길러야 한다고 느꼈습니다.
결론
이 경험을 통해, 단순히 원칙을 지키는 것에 집착하기보다는 프로젝트 맥락에서 실질적으로 단순하고 유지보수하기 쉬운 구조가 무엇인지를 더 고민해야 함을 깨달았습니다. 또한 구조 설계 단계에서 “데이터가 얼마나 자주, 어디로 이동할 것인지”를 먼저 추론하는 것이 중요하다는 점도 배웠습니다. 앞으로는 코드를 더 넓은 시야로 바라보며, 원칙은 참고하되 실제 상황에 맞는 유연한 설계를 해 나가고자 합니다.
팀원들과의 KPT 회고
Keep
- Github Pull Request를 통한 협업으로 안전하고 빠르게 코드를 통합할 수 있었습니다.
- 일에 집중하고 필요한 말만 한 점이 좋았습니다. 서로를 깊게 알지는 못했지만, 오히려 의견을 말하기는 더 편했습니다.
- Git을 활용한 언리얼 협업이 처음임에도 다 같이 잘 완수한 점이 좋았습니다.
- 서로 필요한 것이 있으면 유기적으로 도움을 요청하여 해결한 점이 좋았습니다.
- 이번 프로젝트를 통해 Git의 브랜치, 커밋, 병합 등의 기능을 실제로 적용하면서 버전 관리의 중요성과 실질적인 사용법을 익히게 되었습니다.
- 짧은 기간에도 불구하고 팀원 모두가 끝까지 책임감을 가지고 프로젝트를 완수한 점이 좋았습니다.
Problem
- 일부 기획이 추상적으로만 맞춰져 구체적인 합의가 부족하다 보니, 구현 단계에서 생각과 다른 코드가 만들어지는 문제가 있었습니다.
- 서로가 현재 어떤 작업을 진행 중인지 쉽게 알기 어려워 마감일에 대한 불안감이 있었습니다.
- 각자 맡은 일을 진행하다 보니 속도가 더딜 경우 다른 작업도 막히는 상황이 발생했습니다.
- 기능 개발에 집중하다 보니 게임으로서의 완성도가 다소 아쉬웠습니다.
- 설계 경험이 부족하여 처음만든 설계가 프로젝트의 발목을 잡는 경우가 발생했습니다.
Try
- 다음 프로젝트에서는 세부 기획을 명확하게 작성하고, 문서화하여 공유해야겠습니다.
- PR을 자주 올리거나, 간단히 TIL처럼 하루 단위로 진행 상황을 기록하는 방식을 도입하면 좋겠습니다.
- 기능 개발이 일정 부분 끝나면 중간에 한 번 프로젝트를 main에 통합해 실제 플레이 레벨에서 테스트를 빨리 진행해야겠습니다.
- 처음부터 좋은 설계를 만들어 내는 것은 어려우니, 최대한 빠르게 문제점을 파악하여 리팩토링 해야겠습니다.
