첫 번째 2D 미니게임 출시 후기와 구글 플레이 스토어 등록 과정

기획부터 프로토타이핑까지: 첫 걸음의 설렘

항상 남의 게임만 즐기던 유저에서 내 게임을 만드는 개발자로 거듭나기 위한 첫 프로젝트는 작고 명확한 목표에서 시작되었습니다. "가장 단순하지만 중독성 있는 미니게임을 완성해서 스토어에 올려보자."라는 다짐이었죠. 유니티 2D 엔진을 선택한 이유는 방대한 에셋 스토어와 커뮤니티, 그리고 모바일 빌드의 편의성 때문이었습니다. 초기 기획은 간단한 터치 기반의 회피 게임이었지만, 실제 구현 과정은 생각보다 호락호락하지 않았습니다.

프로토타이핑 단계에서는 '재미'의 핵심 요소를 찾는 데 집중했습니다. 캐릭터의 이동 속도, 장애물의 생성 주기, 그리고 스코어링 시스템을 수없이 조정하며 '한 판만 더' 하고 싶게 만드는 밸런스를 찾기 위해 노력했습니다. 이 과정에서 유니티의 ScriptableObject를 활용해 게임의 밸런스 데이터를 외부 파일로 분리하여 관리하는 법을 배웠고, 이는 추후 유지보수에 큰 도움이 되었습니다.

싱글톤 패턴을 활용한 게임 매니저 구현

미니게임의 전체적인 흐름(시작, 진행, 종료, UI 업데이트)을 제어하기 위해 GameManager 시스템을 구축했습니다. 전역적으로 접근 가능하면서도 상태를 일관되게 관리하기 위해 싱글톤 패턴을 적용했습니다. 아래는 당시 프로젝트에서 사용했던 핵심 매니저 코드의 구조입니다.

using UnityEngine;
using UnityEngine.Events;

public class GameManager : MonoBehaviour
{
    public static GameManager Instance { get; private set; }

    public enum GameState { Ready, Playing, GameOver }
    public GameState CurrentState { get; private set; }

    public UnityEvent OnGameStart;
    public UnityEvent OnGameOver;

    private int score = 0;

    void Awake()
    {
        if (Instance == null) Instance = this;
        else Destroy(gameObject);
    }

    public void StartGame()
    {
        score = 0;
        CurrentState = GameState.Playing;
        OnGameStart?.Invoke();
    }

    public void AddScore(int amount)
    {
        if (CurrentState != GameState.Playing) return;
        score += amount;
        UIManager.Instance.UpdateScore(score);
    }

    public void EndGame()
    {
        CurrentState = GameState.GameOver;
        OnGameOver?.Invoke();
    }
}

이러한 구조를 통해 각 오브젝트들(플레이어, 적, 아이템)이 서로 복잡하게 얽히지 않고 매니저를 통해 소통하게 함으로써 코드의 가독성과 확장성을 확보할 수 있었습니다.

모바일 최적화: 1MB라도 줄이기 위한 사투

PC에서는 문제없이 돌아가던 게임이 모바일 빌드 후에는 프레임 드랍이 발생하거나 용량이 비정상적으로 커지는 문제가 발생했습니다. 이를 해결하기 위해 여러 최적화 기법을 도입했습니다.

• Sprite Atlas 활용: 개별 이미지를 하나의 큰 텍스처로 합쳐 Draw Call을 획기적으로 줄였습니다.
• 오디오 압축 설정: 배경음은 Vorbis, 효과음은 ADPCM 방식으로 설정하고 모노(Mono) 전환을 통해 용량을 확보했습니다.
• IL2CPP 빌드: C# 코드를 C++로 변환하여 실행 속도를 높이고 보안을 강화했습니다.
• 안드로이드 App Bundle(AAB): 유저의 기기 사양에 맞는 리소스만 다운로드되도록 하여 설치 용량을 최적화했습니다.

구글 플레이 스토어 등록과 끝없는 검수의 늪

개발만큼이나 힘들었던 과정은 스토어 등록이었습니다. 단순히 빌드 파일을 올리는 것으로 끝나는 줄 알았는데, 개인정보처리방침 작성, 디지털 서명(Keystore) 관리, 다양한 해상도의 스크린샷 제작, 그리고 콘텐츠 등급 분류 등 넘어야 할 산이 많았습니다.

특히 첫 제출 후 '메타데이터 정책 위반'으로 거절(Reject)당했을 때는 눈앞이 캄캄해지기도 했습니다. 앱 설명 문구에 부적절한 키워드가 포함되었다는 이유였죠. 가이드를 꼼꼼히 다시 읽고 수정하여 재심사를 요청한 끝에 드디어 '출시됨' 상태를 보았을 때의 쾌감은 잊을 수 없습니다. 내부 테스트 트랙을 활용해 지인들에게 먼저 배포하고 피드백을 받아 수정했던 과정이 검수 통과에 큰 역할을 했습니다.

출시 후 느낀 점: 시작이 반이다

첫 게임 출시를 통해 배운 가장 큰 교훈은 "완벽한 게임보다 완성된 게임이 가치 있다"는 것입니다. 머릿속으로만 그리던 거창한 기획보다, 실제로 마켓에 올라가 유저가 다운로드할 수 있는 작은 결과물이 저에게는 더 큰 성장 동력이 되었습니다.

이제 첫 단추를 끼웠을 뿐입니다. 이번 프로젝트에서 겪은 시행착오와 기술적 데이터들을 바탕으로, 다음 프로젝트에서는 더 탄탄한 아키텍처와 매력적인 게임 플레이를 선보일 수 있도록 노력하겠습니다. 1인 개발자의 길은 외롭지만, 제가 만든 세상을 누군가 즐겨준다는 것만큼 가슴 벅찬 일은 없으니까요.

심화 분석: 기술적 도전과 해결책

기술적 구현의 디테일

저는 이번 개발 과정에서 모든 기능을 모듈화하여 독립적으로 테스트할 수 있는 환경을 구축했습니다. 이는 추후 기능 확장이나 버그 수정 시 발생할 수 있는 사이드 이펙트를 최소화하는 데 큰 역할을 했습니다. 또한 문서화를 병행하여 기술 부채가 쌓이는 것을 방지했습니다.

프로젝트의 성공은 기술력뿐만 아니라 팀 내 원활한 커뮤니케이션과 체계적인 파이프라인 구축에 달려 있습니다. 자동화된 빌드 시스템과 코드 리뷰 프로세스는 개발 속도를 비약적으로 높여줍니다.

성능 벤치마크 및 최적화 지표

협업 툴 도입 이후 작업 히스토리 추적 시간이 50% 단축되었으며, 휴먼 에러로 인한 빌드 실패율이 눈에 띄게 줄어들었습니다.

실무 적용 시 주의사항

완벽한 설계를 추구하기보다 빠르게 프로토타입을 만들고 피드백을 수용하는 애자일(Agile)한 자세가 1인 개발자에게는 특히 중요합니다.

LYSC Studio

1인 게임 개발과 웹 기술에 관심이 많은 개발자입니다. 경험을 통해 배운 것을 공유하고, 함께 성장하는 것을 즐깁니다.