외부 SDK를 붙인 뒤 에디터와 테스트 기기에서는 잘 됐지만 다른 Android 기기에서 초기화 콜백이 오지 않았다. 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를 블랙박스처럼 호출하지 않는다. 초기화 계약과 지원 조건, 정리 생명주기를 앱 상태 안에 명시한다. 기기에서만 보이는 오류도 단계별 증거가 있으면 추측 범위를 줄일 수 있었다.