⚔️ HolyDay

상대 팀을 견제하며 전장의 석상을 점령해 더 많은 신성력을 모으는 4인 멀티플레이 AOS 게임입니다. 2026년 1월부터 5월까지 4인 팀으로 졸업 작품 전시 빌드를 제작해 PlayX4 상명대학교 부스에서 관람객들에게 선보였습니다.

저는 타이틀 화면부터 본 게임 진입까지의 진행 구조, UI 레이아웃과 팝업, 경기 규칙에 변수를 주는 축복 콘텐츠, 그리고 Git 형상 관리와 에셋 정돈을 맡았습니다. 축복과 팝업의 기반 설계를 주도하고, 캐릭터 능력치 변화나 기도 애니메이션은 해당 파트 팀원의 코드와 맞물리도록 조율했습니다.

데이터와 효과 실행을 분리한 11종의 축복

전장의 연못과 상호작용하면 무작위 축복을 받아 경기 규칙이나 캐릭터 능력치가 달라집니다. 축복마다 적용 대상과 지속 조건이 제각각이라 단일 클래스의 분기문으로 처리하면 종류가 늘어날수록 유지보수가 어려워질 위험이 있었습니다.

이를 막기 위해 BlessData(ScriptableObject)에는 타입·등급·다국어 텍스트 같은 정적 속성만 담고, 실제 발동 로직은 IBlessLogic 전략 인터페이스로 분리했습니다. 팩토리 매핑을 통해 축복 타입과 생성 함수를 짝지어 두고, 일관된 인터페이스로 11종의 효과를 실행했습니다.

public interface IBlessLogic
{
    void Execute(BlessBehaviour self, NetworkObject player);
    void Destroy();
}

추첨은 먼저 등급을 결정한 뒤, 해당 등급에 속한 후보 중 하나를 고르는 2단계 방식으로 동작합니다. 등급 확률은 Mercy 20%, Grace 50%, HolyMoly 30%이며, 같은 등급 내에서는 균등 확률로 선택됩니다. 연못 오브젝트에는 INetworkInteract 인터페이스를 두어 멀티플레이 상호작용 규격에 맞췄습니다.

각 효과 인스턴스는 발동 시점에 생성하여 개별 상태 보관과 해제 책임을 스스로 갖게 했습니다. 캐릭터 스탯이나 직업군 판별이 필요한 효과는 담당 팀원에게 필요한 API 명세를 공유 받아 연동했습니다. 발동 시 객체 할당이 일어나지만, 효과별 책임과 생성 규칙을 명확히 격리할 수 있다는 점을 우선했습니다.

생성부터 해제까지 관리하는 스택형 팝업

로비·매칭·인게임·결과창 등 곳곳에서 팝업이 필요했습니다. 각 화면이 프리팹 경로를 직접 알고 생성과 파괴를 제각각 처리하면 중복 코드가 늘어나므로, 호출부에서는 PopupType 열거형만 넘기면 되는 중앙 관리자를 만들었습니다.

• PopupType과 리소스 주소의 대응 관계를 한곳에 모았습니다.
• Addressables와 UniTask로 프리팹을 비동기 로드하고, 화면에 띄우기 직전 제네릭 초기화 콜백으로 필요한 데이터를 주입했습니다.
• Stack<PopupBase>로 열린 순서를 기록해 항상 최상단 팝업부터 닫히도록 보장했습니다.
• 열기·배경 암전·입력 차단·닫기·이벤트 구독 해제·메모리 반환 과정을 단일 파이프라인으로 묶었습니다.

public async UniTask<PopupBase> Show(string address)
{
    var popup = await InstantiatePopupAsync(address);
    if (popup == null)
        return null;

    if (_popupStack.Count == 0)
    {
        SetActive(true);
        FadeBackground(true).Forget();
    }

    _popupStack.Push(popup);
    await popup.Show();
    return popup;
}

창을 닫을 때는 연출 애니메이션이 끝난 뒤 등록된 이벤트를 비우고 Addressables.ReleaseInstance()로 인스턴스를 돌려줍니다. 여러 곳에서 쓰는 에셋은 참조 카운트에 따라 안전하게 유지됩니다. 덕분에 화면마다 흩어져 있던 UI 생성 코드와 리소스 반환 누락 문제를 함께 잡았습니다.

현지화와 매니저 초기화

AI Agent를 활용해 코드에 박혀 있던 UI 문자열을 테이블 구조로 추출하고, 한국어·영어 실시간 전환 기능을 넣었습니다. 축복 설명문 역시 다국어 키를 참조하도록 개편했습니다.

주요 매니저들은 서비스 로케이터 패턴을 통해 접근 경로를 단일화하고, 씬 진입 시 초기화 순서를 명시적으로 제어했습니다. 개발 후반에는 석상 상호작용과 UI 표시 계층의 중복 코드를 걷어냈으며, Unity Profiler로 발견한 매 프레임 컴포넌트 탐색 구문을 초기 캐싱 방식으로 교체했습니다. 값 변화가 드문 UI는 이벤트 구동 방식으로 바꾸어 불필요한 갱신을 줄였습니다(성능 개선은 이러한 구조 변경 범위로 설명하며, 별도의 전후 수치 측정값은 제시하지 않습니다).

Git 병합과 팀 협업

네 명이 동시에 기능을 얹으면서 병합 충돌이 생기면, 브랜치와 커밋 내역을 대조하고 작성자와 의도를 확인해가며 코드를 합쳤습니다. 마감 직전에는 팀원별 작업물과 AI 생성 코드 사이에 어긋난 규약을 점검해 매니저 및 UI의 기반 구조에 맞게 다듬었습니다.

결과와 다음에 바꿀 점

팀원들과 끝까지 빌드를 다듬어 PlayX4 상명대학교 게임전공 부스에서 현장 시연을 마쳤습니다. 복잡한 규칙이 얽힌 멀티플레이 게임을 현장의 관람객들이 직접 플레이하는 모습을 보며 큰 동기부여를 얻었습니다.

반면 아쉬운 점도 뚜렷했습니다. 소규모 팀에서 여러 역할을 겸하다 보니 의사결정 범위가 모호해졌고, 기획 변경과 코드 스타일 차이가 뒤섞였습니다. 다음 협업에서는 네이밍·폴더 구조·브랜치 규칙을 시작 단계에 문서로 합의하고, 사양 변경 시 영향받는 파트와 먼저 검토하는 절차를 두려 합니다.

또한 핵심 로직이 싱글톤과 전체 진행 단계에 강하게 묶여 있어, 단위 기능 하나를 고쳐도 매칭부터 다시 거치며 확인해야 했습니다. 앞으로는 기능별 독립 테스트 Scene을 함께 구성해 검증 시간을 줄이고, 네트워크 라이브러리 역시 구현 난이도뿐 아니라 디버깅 편의성까지 따져보고 선택할 것입니다.

마지막으로 AI가 작성한 코드는 생산성이 높지만, 프로젝트 고유의 아키텍처에 맞는지 사람이 직접 검수하지 않으면 기술 부채가 된다는 점을 체감했습니다. 공통 설계 원칙과 금지 패턴을 팀 가이드로 정의하고, 기존 책임 분리 원칙에 부합하는지 확인한 뒤 병합하는 습관을 가져가겠습니다.