성공한 Unity 빌드가 왜 상태 미확인이었을까

성공한 빌드와 기록의 상태가 달랐습니다

Entity Forge에서 Windows 빌드가 성공했는데도 날짜별 이력에는 unknown이 남았습니다. 파일이 만들어진 사실과 Unity가 반환한 최종 결과, 저장된 JSON의 상태가 서로 맞지 않았습니다. 이력을 보고 이전 빌드를 고르려면 성공 여부를 믿을 수 있어야 하므로, 화면 문구보다 결과를 수집하는 순서를 먼저 확인했습니다.

재현 환경은 Unity 6000.0.83f1과 Entities 1.3.15를 사용하는 새 프로젝트였습니다. 일반 오브젝트 10,000개가 있는 씬을 BuildPipeline으로 빌드하고, 최종 Unity 결과를 날짜별 JSON과 로그에 대조했습니다. 수정 전 이력의 unknown을 실제 실패로 해석하면 안 되는 상황이었습니다.

콜백이 실행됐다고 최종 결과는 아니었습니다

원인은 OnPostprocessBuild에서 아직 Unknown인 BuildReport 결과를 즉시 저장한 데 있었습니다. 빌드 과정에서 호출되는 콜백과 전체 빌드가 종료되는 시점을 같은 것으로 취급한 것입니다. 최종 상태가 정해지기 전에 이력을 남기면, 뒤에서 빌드가 성공해도 이미 저장한 행에는 중간 값이 남습니다.

대기 중인 보고서를 보존하고 BuildPipeline이 종료된 뒤 최종화하도록 바꿨습니다. 성공 모드 설정도 실제 성공했을 때만 저장합니다. 이전 빌드의 최종화가 다음 빌드 시작과 겹치는 경우에는 이전 작업부터 처리하도록 순서를 정리했습니다.

아래는 원문에 기록된 수정 순서를 설명한 도표입니다. 실제 메서드 전체를 옮긴 코드나 모든 실패 경로를 나타낸 상태 머신은 아닙니다.

flowchart LR
  A["빌드 후처리 콜백"] --> B["보고서 보존"]
  B --> C["BuildPipeline 종료"]
  C --> D["최종 결과 확인"]
  D --> E["JSON과 로그 상태 기록"]

실제 재빌드와 이력을 맞춰 봤습니다

수정 뒤 재빌드에서 Unity는 Succeeded, 오류는 0개를 반환했고 JSON의 상태도 succeeded였습니다. 씬 1개와 자동 변환 대상 10,000개를 확인했으며, 빌드 기록 탭의 해당 날짜를 눌러 같은 로그가 열리는지도 대조했습니다. 화면에서 성공이라고 보이는 것만으로 검증을 끝내지 않았습니다.

현재 어셈블리 7개 컴파일과 패키지 402개 대조도 통과했습니다. 수정 후 재빌드에 걸린 시간은 41.87초로 기록돼 있습니다. 이 시간은 이번 실행의 값이지 모든 프로젝트에서 같은 속도로 빌드된다는 뜻은 아닙니다.

기록을 고치는 일과 과거를 바꾸는 일은 다릅니다

이번 결과는 새 빌드의 최종 상태와 저장된 기록이 일치한다는 근거입니다. 기존 이력을 일괄 수정하거나, 과거의 Unknown 항목이 모두 성공이었다고 판단한 작업은 아닙니다. 이전 행을 복구하려면 해당 실행의 최종 로그나 산출물을 별도로 확인해야 합니다.

또한 빌드 상태 기록이 맞아졌다고 전체 성능 개선이나 출시 UI 검증까지 끝난 것은 아닙니다. 원문에서도 두 작업은 미완료로 구분했습니다. 이번 수정의 핵심은 더 낙관적인 상태를 표시하는 것이 아니라, Unity가 판단을 끝낸 시점의 값을 이력에서도 같은 의미로 보존하는 데 있습니다.

작업 근거

• 개발 기록 원문