중단된 Unity 프로젝트는 실제보다 상태가 나빠 보일 수 있습니다. 누락된 SDK, 문서화되지 않은 빌드 단계 또는 중단된 서비스가 사용 가능한 제품을 가리고 있을 수 있습니다. 반대로 설득력 있는 데모가 심각한 출시 문제를 감출 수도 있습니다.
창업자나 프로듀서라면 다음 투자로 실제로 무엇을 이룰 수 있는지 알아야 합니다. 저는 어떤 제품을 출시하려는지, 이미 작동하는 것은 무엇인지, 완성을 막을 수 있는 문제는 무엇인지부터 확인합니다. 첫 대화에는 간단한 개요면 충분하며, 민감한 자료나 소스 코드 접근 권한을 공유하기 전에 비밀유지계약(NDA)을 맺을 수 있습니다.
01
인수받은 프로젝트 보존
저장소 이력, 마지막으로 작동한 빌드 및 설정 메모를 보관하세요. 다른 버전으로 프로젝트를 열기 전에 Unity Editor 버전과 대상 플랫폼을 기록하세요. 원본을 보존하고 별도의 작업 복사본에서 조사하세요.
첫 번째 유용한 산출물은 반복 가능한 빌드입니다. 다른 컴퓨터에서도 문서화된 절차를 따라 실행 가능한 애플리케이션을 만들 수 있어야 합니다. 실패한다면 정확한 장애 요인과 누락된 의존성을 기록합니다. ‘빌드되지 않음’은 조사할 발견 사항이지, 재작성에 충분한 근거는 아닙니다.
Unity는 업그레이드 전에 백업하고 그 이점이 작업량을 정당화하는지 평가할 것을 권장합니다. 인수받은 프로젝트의 기준선을 변경하기 전에 저도 같은 원칙을 적용합니다.
Unity: Unity 프로젝트 업그레이드02
프로젝트에 필요한 도구, 서비스와 계정 확인
에디터 버전, 렌더 파이프라인, Unity 패키지, Asset Store 에셋, 네이티브 플러그인 및 외부 SDK를 확인합니다. 빌드 도구, 백엔드 환경, 서명 접근 권한 및 필요한 계정의 관리 주체도 검토합니다.
각 핵심 의존성의 버전, 가용성, 호환성 및 책임자를 확인합니다. 문서화되지 않은 로컬 수정으로 유지되는 플러그인은 수정 없이 설치할 수 있는 플러그인과 다르게 다뤄야 합니다.
패키지 매니페스트와 잠금 파일을 프로젝트에 함께 보관하세요. Unity 잠금 파일은 해석된 패키지 의존성을 기록하며, 여러 컴퓨터에서 동일한 패키지 구성을 재현하도록 버전 관리해야 합니다. 사용할 수 없는 서비스나 누락된 소스가 C# 코드의 연식보다 복구 범위에 더 큰 영향을 줄 수 있습니다.
Unity: 의존성 해석 및 잠금 파일03
대상 기기에서 성능 테스트
‘제 컴퓨터에서는 원활하게 실행됩니다’라는 말로 모바일이나 헤드셋 준비가 입증되지는 않습니다. 저는 대표 하드웨어와 반복 가능한 시나리오를 선택합니다. 시작, 활동이 많은 게임플레이 순간, 씬 전환 및 필요한 경우 긴 세션을 확인합니다.
CPU 또는 GPU 부하, 메모리 증가, 로딩 지연 및 반복 할당을 찾아 플레이어가 체감하는 문제와 연결합니다. 비교가 의미 있도록 기기, 빌드 버전, 설정 및 절차를 기록합니다.
Unity는 대상 플랫폼에서 프로파일링할 것을 권장합니다. Editor Play Mode는 에디터와 자원을 공유하므로 기기 성능을 정확히 반영하지 않습니다. 개발 빌드는 Unity Profiler 연결을 지원합니다. 프로파일링으로 진단 방향을 잡고, 해결됐다고 판단하기 전에 의도한 릴리스 설정에서도 제안한 수정을 확인합니다.
Unity: 애플리케이션 프로파일링04
저장된 진행 상황, 구매와 분석 확인
성공적으로 실행되는 것은 호환성의 한 부분일 뿐입니다. 기존 플레이어에게는 저장된 진행 상황, 해금 콘텐츠, 구매 내역 또는 서버 측 상태가 있을 수 있습니다.
데이터가 어디에 있는지 추적하고 대표적인 이전 저장 데이터로 제안한 변경을 테스트합니다. 로딩 중단, 데이터 누락 및 마이그레이션 실패를 확인합니다. 형식이나 식별자를 바꾸기 전에 반드시 유지해야 할 것, 변경할 수 있는 것 및 복구 방식을 합의합니다.
그런 다음 전체 진행 경로를 따릅니다. 시작하고, 무언가를 획득하거나 해금하고, 저장하고, 다시 실행하고, 이어서 진행합니다. 관련 분석 이벤트의 의미와 버전 맥락을 포함해 검증합니다. 과거 추적이 신뢰하기 어렵다면 다음 릴리스에서 측정 기준선을 만들 수 있지만, 그것만으로 리텐션이 개선됐다고 자동으로 입증되지는 않습니다.
05
작동하는 작은 예제로 가장 큰 미확인 사항 테스트
대규모 코드 변경이나 재개발을 견적 내기 전에 작은 테스트를 합의합니다. 답해야 할 질문, 작업 한도와 성공으로 판단할 기준을 정합니다.
예를 들어 대표 레벨 하나가 기존 저장을 불러오고, 게임플레이 루프를 완료하고, 예상 이벤트를 전송하며, 대상 휴대전화에서 합의된 성능 한도 안에서 실행될 수 있나요?
테스트에는 출시를 막을 가능성이 가장 큰 시스템이 포함되어야 합니다. 별도의 메뉴만 다시 만드는 것으로는 플레이어 진행이나 플랫폼 서비스에 대해 알 수 있는 것이 적습니다. 작업 한도를 미리 정하고, 테스트로 확인한 사실, 실패한 부분, 아직 모르는 내용을 기록하세요.
06
확인한 결과를 바탕으로 다음 단계를 선택합니다.
제안에는 검토로 발견한 내용, 중요한 이유, 다음에 해야 할 작업이 담겨야 합니다.
- 완성
핵심 게임이 작동하며, 남은 작업을 명확하게 나열하고 예상할 수 있습니다.
다음 단계: 출시를 막는 문제를 해결하고 합의한 기능을 테스트합니다.
- 리팩터링
특정 시스템이 반복해서 오류를 일으키거나 필요한 변경을 방해합니다.
다음 단계: 코드의 한 부분을 개선하고 연결된 기능이 계속 작동하는지 확인합니다.
- 재구축
실용적인 수정 방법을 검토한 뒤에도 기존 코드로 필요한 기능을 무리 없이 지원하기 어렵습니다.
다음 단계: 대체 개발 방식을 테스트하고 기존 플레이어 데이터를 옮길 계획을 세웁니다.
작은 범위의 유료 프로젝트 검토로 다음에 무엇을 할지 결정할 수 있습니다. 시작 전에 질문, 필요한 접근 권한, 작업 한도와 결과물을 합의합니다. 작동하는 실행 버전이나 실행을 막는 이유, 우선순위별 검토 결과, 전제 조건을 명시한 다음 단계 제안을 받게 됩니다.
서로 연결된 게임플레이, 저장 및 진행의 구체적인 예시는 다음에서 살펴보세요: Polar Station Survival—여러 시스템이 연결된 게임으로, 제가 유일한 Unity 개발자였습니다.