앱 MVP Android SDK Runtime 종료: 의존성·API 37·대체 판단을 나누는 5가지 기준
앱 MVP Android SDK Runtime 종료: 의존성·API 37·대체 판단을 나누는 5가지 기준
광고·분석·인증처럼 외부 SDK를 쓰는 Android MVP에서 “라이브러리가 빌드된다”는 사실만으로 출시 준비가 끝난 것은 아닙니다. SDK Runtime을 전제로 한 코드나 의존성이 있는 경우에는 무엇을 실제로 호출하는지, 어떤 API 수준에서 상태가 달라졌는지, 화면과 앱 사이의 경계가 어디인지, 공급사가 제시한 현재 지원 경로가 있는지를 나눠 봐야 합니다.
Android Developers의 `SdkSandboxManager` 참조는 이 클래스가 API 33에 추가됐고 API 37에서 deprecated 되었으며 SDK sandbox가 더 이상 지원되지 않는다고 명시합니다(C001). 같은 문서는 앱이 manifest의 `<uses-sdk-library>`로 의존 SDK를 선언하고, 선언한 SDK만 sandbox에 로드할 수 있었다고 설명합니다(C002).
AndroidX의 `SdkSandboxControllerCompat`도 더 이상 지원되지 않는 라이브러리로 표시됩니다(C003). 이 글은 특정 앱의 장애·심사 결과나 대체 기술을 보장하지 않습니다. 대신 MVP 팀이 영향을 확인할 때 필요한 다섯 가지 기록을 제시합니다.
먼저 답하기: ‘deprecated 표기’와 ‘우리 앱의 다음 행동’은 같은 신호가 아닙니다
API 문서에서 지원 종료 또는 deprecated를 확인했다면, 첫 행동은 코드를 성급히 바꾸는 것이 아니라 영향 범위를 분리하는 일입니다. 표시는 플랫폼 API의 상태이고, 실제 앱 영향은 앱의 target SDK, 포함된 SDK, 실제 호출, 지원 기기와 배포 계획을 함께 봐야 판단할 수 있습니다.
구분 | 확인할 질문 | 완료로 오해하기 쉬운 신호 |
|---|---|---|
의존성 | 어떤 모듈·SDK가 관련 artifact나 API를 포함하는가 | 앱 코드에 import가 보이지 않음 |
플랫폼 상태 | 어떤 API가 어떤 수준에서 deprecated·비지원인가 | 문서 제목만 읽음 |
실제 경로 | manifest·로드·통신·UI 중 무엇을 실제로 쓰는가 | 빌드가 성공함 |
대체 판단 | 공급사와 공식 문서가 현재 안내하는 경로는 무엇인가 | 이름이 비슷한 라이브러리로 교체함 |
출시 검수 | 변경 뒤 핵심 과업과 SDK별 데이터 흐름은 어떻게 확인했는가 | 테스트 기기 한 대에서 화면이 열림 |
기준 1: 먼저 ‘직접 사용’과 ‘전이 의존성’을 구분합니다
`SdkSandboxManager`는 SDK sandbox 프로세스에 SDK를 로드하고 상호작용하는 API를 제공했던 클래스입니다(C001). 앱은 manifest에서 의존 SDK를 선언하고 그 SDK만 sandbox에 로드할 수 있었다는 설명도 함께 확인할 수 있습니다(C002). 따라서 점검표는 `SdkSandboxManager`라는 문자열 검색 하나로 끝나지 않습니다.
앱 모듈, 기능 모듈, 의존성 잠금 파일, Gradle 의존성 그래프, 외부 SDK의 배포 노트, manifest 병합 결과를 각각 확인하세요. 앱 코드가 API를 직접 호출하는 경우와 광고·분석 등 공급사 SDK가 전이 의존성으로 포함하는 경우는 복구 주체와 검수 방법이 다를 수 있습니다. 확인 결과가 없으면 ‘미사용’으로 추정하지 말고 `UNKNOWN`으로 남긴 뒤 빌드 산출물과 공급사 문서로 보완하는 편이 안전합니다.
기준 2: API 37의 상태와 현재 배포 기준을 분리합니다
공식 참조에서 `SdkSandboxManager`는 API 37에서 deprecated이고 SDK sandbox는 더 이상 지원되지 않는다고 표시됩니다(C001). 패키지 요약도 `android.app.sdksandbox` 안의 여러 클래스에 같은 비지원 상태를 표시합니다(C004). 이것은 미래 출시 기준을 논의할 때 중요한 근거이지만, 문서 한 줄만으로 현재 운영 중인 모든 기기의 동작이나 특정 앱의 배포 가능 여부를 결론낼 수는 없습니다.
팀 기록에는 현재 `compileSdk`, `targetSdk`, `minSdk`, 테스트한 OS와 기기, 관련 SDK 버전, 호출된 경로를 별도 열로 둡니다. ‘API 37을 컴파일한다’, ‘API 37을 target으로 한다’, ‘API 37 기기에서 실행한다’는 서로 다른 사실입니다.
같은 표에 섞으면 누가 무엇을 바꿔야 하는지가 불명확해집니다. 플랫폼 상태는 공식 참조에서 확인하고, 실제 릴리스 영향은 앱의 빌드 설정과 공급사 지원 문서를 함께 확인한 뒤 판단하세요.
기준 3: UI 요청과 SDK 통신을 각각 검수합니다
공식 참조는 `requestSurfacePackage`가 API 35에서 deprecated 되었고 `SdkSandboxManager`를 통한 지원이 중단될 예정이므로 AndroidX Privacy Sandbox 라이브러리를 고려하라고 적고 있습니다(C005).
그러나 AndroidX의 `SdkSandboxControllerCompat` 참조는 해당 라이브러리도 더 이상 지원되지 않는다고 표시합니다(C003). 따라서 과거 문서의 대체 제안을 현재의 영구 해법으로 복사하면 안 됩니다.
이력과 코드를 검토할 때에는 화면 표시 요청, SDK 로드, 앱↔SDK 인터페이스, 오류·프로세스 종료 처리, SDK가 쓰는 네트워크·저장소 흐름을 각각 표시하세요. 화면이 보였다는 결과는 SDK가 로드됐다는 결과와 다르고, SDK가 로드됐다는 결과는 사용자의 핵심 과업이나 데이터 처리 고지까지 적절했다는 증거가 아닙니다. 각 결과를 별도 QA 항목과 이벤트로 남기면 대체 작업 후 회귀 범위를 줄이는 데 도움이 됩니다.
관련 글 앱 MVP Data safety: 권한·SDK·데이터 흐름 증빙을 나누는 5가지 기준은 Play 등록 정보에 필요한 데이터 흐름 증빙을 다룹니다. 이 글은 SDK Runtime 관련 플랫폼 지원 상태와 기술적 영향 확인을 분리하는 글입니다.
기준 4: ‘대체’는 공급사 확인 전에는 가설로 기록합니다
지원이 끝난 API나 라이브러리를 발견했을 때 가장 위험한 결론은 이름이 비슷한 다른 artifact로 바꾸면 해결된다는 가정입니다. AndroidX의 호환 컨트롤러도 지원 종료 상태이므로(C003), 팀은 사용 중인 SDK 공급사에게 현재 지원 버전과 통합 방식, 변경 시점, 지원 OS 범위, 데이터·UI 처리 변경점을 확인해야 합니다.
이 단계에서 확정할 수 없는 것은 `UNKNOWN`으로 둡니다. 예를 들어 자체 개발 SDK라면 설계 책임자가 대체 구조를 제안할 수 있지만, 서드파티 SDK라면 앱 팀이 임의로 내부 통신을 재구현해서는 안 됩니다. 공급사의 공지와 릴리스 노트, 계약된 지원 채널, 앱의 실제 의존성 결과가 모두 일치할 때만 변경 후보를 승인하세요. 이는 보안·개인정보 적합성이나 Play 심사를 보장하는 절차가 아니라, 기술 의사결정을 추적 가능하게 만드는 기록 방식입니다.
기준 5: 변경 완료와 출시 완료를 분리해 읽습니다
대체 SDK를 올리거나 관련 코드를 제거했다면 최소한 빌드, 설치, 초기 실행, SDK가 관여하는 핵심 사용자 과업, 오류 경로, 기존 데이터와 고지의 변화를 나누어 확인합니다. 테스트가 통과한 환경과 실패한 환경도 함께 남겨야 합니다. ‘의존성 업데이트 완료’는 변경 작업의 신호일 뿐이며, 제품 기능·데이터 흐름·사용자 안내·배포 심사가 모두 완료됐다는 뜻은 아닙니다.
특히 SDK와 데이터 처리를 다루는 제품은 기술 의존성 목록, SDK별 목적과 데이터 흐름, 권한·고지, 릴리스 후보 테스트 결과를 하나의 스프레드시트 행으로 압축하지 않는 편이 좋습니다. 서로 다른 검토자가 다른 근거를 재확인할 수 있게 분리해 두면, 다음 플랫폼 업데이트나 SDK 교체 때도 추정 대신 기록으로 판단할 수 있습니다.
자주 묻는 질문
SDK Runtime이 API 37에서 비지원이면 현재 앱은 즉시 멈추나요?
공식 문서의 비지원 표시는 API와 SDK Runtime의 상태를 말합니다. 실제 영향은 앱의 target SDK, 사용 중인 SDK와 호출 경로, 배포 기기, 대체 구현 여부를 따로 확인해야 하므로 문서만으로 앱 중단 여부를 단정할 수 없습니다.
SdkSandboxManager를 직접 호출하지 않으면 점검할 필요가 없나요?
직접 호출이 없더라도 의존 라이브러리나 SDK가 관련 API·호환 라이브러리를 포함하는지는 잠금 파일, 의존성 그래프, 공급사 문서와 빌드 산출물로 확인하는 편이 좋습니다.
호환 라이브러리로 바꾸면 SDK Runtime을 계속 사용할 수 있나요?
공식 AndroidX 참조는 SdkSandboxControllerCompat 라이브러리도 더 이상 지원되지 않는다고 표시합니다. 따라서 단순 치환을 완료 신호로 삼지 말고 공급사와 Android 공식 안내에 따른 현재 지원 경로를 확인해야 합니다.
SDK Runtime 점검은 개인정보 처리 검토를 대신하나요?
아닙니다. 런타임 구조의 지원 여부, SDK별 데이터 흐름, 앱의 고지와 권한, Play 등록 정보는 서로 다른 검토 대상입니다.
공식 출처
Android Developers: SdkSandboxManager — 2026-09-28 직접 확인
Android Developers: SdkSandboxControllerCompat — 2026-09-28 직접 확인
Android Developers: android.app.sdksandbox package summary — 2026-09-28 직접 확인
발행일: 2026-09-28 · 작성: 유인어스 정책자금·정부지원사업 인사이트