기능을 수정한 뒤 에디터에서 여러 번 확인하고 완료라고 생각했다. 그런데 테스트용 Android 기기에 설치하자 첫 화면부터 다른 결과가 나왔다. 에디터에서는 존재하던 파일을 찾지 못했고 네이티브 플러그인을 호출하는 부분도 조용히 실패했다. 같은 프로젝트인데 무엇이 달라진 건지 답답했다.
원인을 찾으며 “실행된다”를 하나의 성공으로 묶지 않고 단계별로 나누기 시작했다.
빌드, 설치, 실행은 서로 다른 증거였다
Unity 빌드가 성공해도 APK가 기기에 설치되지 않을 수 있고, 설치돼도 시작 직후 권한이나 라이브러리 문제로 종료될 수 있었다.
스크립트 컴파일 성공
-> 플랫폼 빌드 성공
-> 패키지 설치 성공
-> 앱 시작 성공
-> 대상 기능 동작 성공
-> 재실행 후 상태 유지
어느 단계까지 확인했는지를 기록하니 “빌드는 됐다”라는 말의 범위가 분명해졌다.
파일 경로를 에디터 기준으로 생각했다
개발 PC의 상대 경로가 기기에서도 같을 거라고 가정한 코드가 있었다. 읽기 전용 리소스와 앱이 쓸 수 있는 영구 저장 영역도 달랐다. Unity가 제공하는 플랫폼별 경로를 사용하고 파일 존재와 디렉터리 준비를 확인했다.
string path = Path.Combine(
Application.persistentDataPath,
"settings.json");
Directory.CreateDirectory(Path.GetDirectoryName(path));
WebGL처럼 파일 시스템 자체가 다르게 추상화되는 플랫폼은 별도 저장 구현을 사용했다.
기기 로그가 실제 실행을 보여줬다
에디터 콘솔에는 Android 런타임의 권한 거부나 네이티브 예외가 보이지 않았다. 기기 로그에서 앱 프로세스와 관련된 줄을 확인하고, 앱 코드에도 플랫폼과 버전, 실행 단계를 남겼다. 계정 값이나 토큰은 로그에 넣지 않았다.
개발 빌드와 배포에 가까운 빌드는 최적화와 코드 제거 설정도 달랐다. 리플렉션에 의존한 직렬화가 한쪽에서만 실패할 수 있다는 점도 알게 됐다.
테스트 환경을 기능의 일부로 봤다
예전에는 구현이 끝난 뒤 마지막에 기기에서 눌러보는 것이 테스트였다. 이제는 플랫폼 기능을 건드릴 때 어떤 기기와 빌드 설정에서 확인할지를 작업 초반에 정했다.
에디터 성공은 여전히 빠르고 중요한 확인이었다. 다만 최종 사용 환경의 증거를 대신하진 못했다. 이 경험 이후 완료라는 말을 할 때 코드, 빌드, 실제 실행 중 어디까지 봤는지 함께 설명하는 습관이 생겼다.