외부 SDK를 붙인 뒤 에디터와 테스트 기기에서는 잘 됐지만 다른 Android 기기에서 초기화 콜백이 오지 않았다. SDK 함수를 다시 호출하거나 대기 시간을 늘려도 결과가 일정하지 않았다. 기기 로그에는 설정 파일을 찾지 못했다는 네이티브 메시지가 있었고, 특정 빌드 변형에만 리소스가 포함되지 않았다.
SDK 오류라는 이름 아래 빌드 설정, 기기 환경, 앱 생명주기가 함께 있었다.
SDK 초기화 단계의 분리
단일 Initialize() 성공 여부 대신 준비 단계를 기록했다.
설정 로드
-> 네이티브 라이브러리 로드
-> SDK 인스턴스 생성
-> 권한·기기 지원 확인
-> 원격 연결
-> Ready
각 단계에서 실패 원인을 안전한 코드로 변환해 어느 경계에서 멈췄는지 알 수 있게 했다.
정상 상태로 분류한 미지원 기기
필요한 서비스가 없거나 OS 버전이 낮은 기기는 무한 재시도해도 성공하지 않는다. SDK가 제공하는 지원 여부 API를 먼저 확인하고 기능을 숨기거나 대체 흐름을 제공했다.
if (!sdk.IsSupportedDevice())
return InitResult.Unsupported;
return await sdk.InitializeAsync(cancellationToken);
일시적 네트워크 실패와 영구적인 미지원 상태를 구분했다.
앱 복귀 시 중복 초기화 방지
OnEnable, Start, 앱 포커스 복귀가 모두 초기화를 호출하는 경로가 있었다. 상태를 NotStarted, Initializing, Ready, Failed로 관리하고 진행 중에는 같은 요청을 공유했다. 로그아웃이나 앱 종료 시 SDK가 요구하는 정리 순서도 적용했다.
실패 후 재시도는 횟수와 간격을 제한하고 설정 누락 같은 오류에는 재시도하지 않았다.
SDK 버전과 앱 빌드 조합을 기록해 업데이트 전후를 비교했다. 공급자 예제 앱에서 같은 기기가 동작하는지도 확인하면 우리 연결 코드와 SDK 자체 문제를 나누는 데 도움이 됐다.
증거 기반 기기 차이 분석
“일부 기기에서 안 된다”는 말만으로는 코드, OS, 빌드를 구분하기 어려웠다. 공개 가능한 OS 버전, 앱 빌드, SDK 상태 코드, 실패 단계를 수집하고 성공 기기와 비교했다.
이 경험 뒤 외부 SDK를 블랙박스처럼 호출하지 않는다. 초기화 계약과 지원 조건, 정리 생명주기를 앱 상태 안에 명시한다. 기기에서만 보이는 오류도 단계별 증거가 있으면 추측 범위를 줄일 수 있었다.
공식 문서 기반의 추가 정리
작업 당시에는 눈앞의 오류를 먼저 고쳤지만, 이후 기술 문서와 맞춰 보며 확인 순서를 조금 더 구체화했다.
Unity 실행 순서 문서는 Awake, OnEnable, Start, Update 같은 엔진 이벤트가 어느 구간에서 호출되는지 설명한다. 하지만 로딩·성공·빈 결과·실패 같은 업무 상태의 순서까지 대신 정해 주지는 않는다. 두 종류의 순서를 섞어 생각하면 콜백이 한 프레임 늦게 왔다는 이유만으로 이전 화면 상태가 다시 살아날 수 있다.
그래서 수명주기 메서드는 상태 전이를 직접 흩어 놓는 장소보다, 한 곳에 모인 전이 함수를 호출하는 경계로 쓰는 편이 추적하기 쉬웠다.
다음에 SDK 초기화와 실제 기기 검증 같은 문제를 보면 아래 순서부터 확인하려고 한다.
- 에디터·개발 빌드·배포 빌드의 차이표
- 실제 기기 OS·모델·그래픽 API
- 초기화 실패와 기능 미지원 구분
- 캐시를 비운 재설치 검증
새 응답을 적용하기 전에 요청 식별자와 현재 선택 조건이 여전히 같은지 확인해야 오래된 응답을 버릴 수 있다.
공식 참고 자료
- Unity 2021.3 이벤트 함수 실행 순서 — MonoBehaviour 이벤트와 프레임 단계의 실행 순서
- ECMA-334 C# 언어 사양 6판 — decimal·enum·예외를 포함한 C# 언어 규칙