모바일 SDK의 의미와 기술적 성장 프로토콜 이해하기

모바일 개발에서 SDK의 의미는 무엇일까요? 모바일 엔지니어링에서 Software Development Kit의 약자인 SDK는 개발자가 애플리케이션을 구축하거나 확장하는 데 도움이 되는 라이브러리, API, 도구 및 문서 모음을 의미하며, 일반적으로 안드로이드 AAR 또는 iOS XCFramework와 같은 컴파일된 바이너리 아카이브 형태로 배포됩니다. 모바일 아키텍트가 타사 성장 및 어트리뷰션 도구를 평가할 때, 바이너리 및 빌드 통합 수준에서 SDK가 뜻하는 바를 정확히 이해하는 것은 패키지 비대화를 방지하고, 전파 의존성 충돌을 피하며, 콜드 스타트 안정성을 유지하는 데 필수적입니다. 모바일 어트리뷰션 및 딥 링크 플랫폼인 Openinstall은 샌드박스 간 라우팅, 채널 트래킹, 파라미터 복원 메커니즘을 안드로이드 및 iOS 빌드 툴체인용으로 설계된 네이티브 클라이언트 라이브러리로 패키징합니다.

모바일 시스템 아키텍처에서 SDK는 단순한 호출 가능한 애플리케이션 프로그래밍 인터페이스(API) 그 이상입니다. 컴파일 타임 링킹 과정에서 컴파일된 바이트코드 또는 머신코드 조각, 리소스 테이블, 매니페스트 선언을 호스트 애플리케이션의 실행 가능 패키지에 통합하는 배포 가능한 빌드 아티팩트입니다.

네이티브 모바일 바이너리 컴파일에서 SDK의 의미

약어 그 이상: 소프트웨어 개발 키트를 모바일 앱에 링크할 때 발생하는 일

입문 수준에서 SDK라는 약어는 소스 코드 라이브러리, 명령줄 컴파일러, 하드웨어 디버거, 코드 샘플을 포괄하는 일반적인 용어인 소프트웨어 개발 키트를 뜻합니다. 그러나 모바일 시스템 아키텍처 담당자와 릴리스 엔지니어에게 실질적인 SDK의 의미는 타사 라이브러리가 컴파일 과정에서 호스트 애플리케이션을 물리적으로 어떻게 변경하는지에 따라 정의됩니다. SDK의 광범위한 정의와 스테이트리스 웹 API와의 운영상의 차이점에 대해서는 기초 가이드인 소프트웨어 개발 키트가 모바일 어트리뷰션과 성장을 이끄는 방법을 참고하세요.

클라이언트가 요청을 생성하고 응답을 처리하는 동안 서버 측 인프라를 통해 노출되고 네트워크를 통해 호출되는 원격 웹 API와 달리, 모바일 SDK는 호스트 프로젝트의 빌드 시스템(안드로이드의 Gradle 또는 iOS의 Xcode, CocoaPods, Swift Package Manager)에 직접 수용됩니다. 일단 링크되면 SDK의 코드는 고립된 외부 서비스로 존재하지 않으며, 그 클래스, 심볼, 설정 규칙은 최종 사용자에게 배포되는 애플리케이션 바이너리의 일부가 되어 호스트 앱의 프로세스 메모리, 권한, 앱스토어 또는 구글 플레이 준수 책임을 공유하게 됩니다.

컴파일, 바이트코드 DEX 패키징 및 네이티브 링킹 모델

안드로이드와 iOS는 서로 다른 런타임 아키텍처를 사용하므로, 빌드 툴체인은 세 가지 고유한 컴파일 및 링킹 경로를 통해 모바일 SDK 바이너리를 통합합니다.

• 안드로이드 관리형 바이트코드 컴파일 (Java/Kotlin에서 DEX로): 안드로이드에서 SDK 내부의 Java 및 Kotlin 소스 코드는 먼저 JVM 바이트코드(.class 파일)로 컴파일됩니다. 호스트 애플리케이션이 빌드될 때 안드로이드의 D8 및 R8 컴파일러는 호스트 앱과 링크된 모든 SDK의 .class 바이트코드를 Dalvik Executable(.dex) 파일로 변환하며, R8은 코드 축소, 최적화 및 난독화를 수행하여 사용되지 않는 메서드를 제거합니다.
• iOS 네이티브 정적 링킹 (정적 아카이브 .a에서 Mach-O로): iOS에서 SDK가 정적 라이브러리(.a) 또는 정적 프레임워크로 배포될 때 네이티브 링커(ld)는 컴파일된 머신코드 오브젝트 파일(.o)을 추출하여 호스트 애플리케이션의 메인 Mach-O 실행 가능 바이너리에 직접 병합합니다. 정적 링킹은 콜드 앱 시작 시 런타임 동적 로더 오버헤드를 없애고, 링킹 시점에 사용되지 않는 심볼을 데드 코드 스트리핑을 통해 제거합니다.
• 동적 프레임워크 및 공유 네이티브 라이브러리 (.framework / .dylib 및 JNI .so): iOS에서 동적 프레임워크로 패키징된 SDK는 애플리케이션 아카이브의 Frameworks/ 디렉터리 내부에 번들로 제공되며, 앱이 실행될 때 애플의 동적 링커(dyld)에 의해 메모리로 로드됩니다. 안드로이드에서는 SDK 내부의 사전 컴파일된 C 또는 C++ 네이티브 코드가 Java Native Interface(System.loadLibrary)를 통해 로드되는 공유 객체(.so) 라이브러리로 패키징됩니다. 동적 프레임워크는 iOS 앱 확장 간의 코드 공유를 허용하지만, 시작 시점에 수많은 동적 프레임워크를 로드하면 main() 실행 이전의 dyld 리베이스 및 바인딩 오버헤드가 증가합니다.

빌드 시스템이 SDK 코드, 리소스, 매니페스트 및 호스트 앱 기능을 통합하는 방식

빌드 파이프라인 동안 호스트 툴체인은 호스트 프로젝트의 보안 설정과 함께 SDK의 패키지된 메타데이터를 처리합니다.

• 안드로이드 매니페스트 병합: 모든 안드로이드 .aar 라이브러리에는 SDK에 필요한 권한이나 컴포넌트를 선언하는 AndroidManifest.xml이 포함되어 있습니다. Gradle 컴파일 과정에서 안드로이드 매니페스트 병합기는 SDK의 매니페스트 노드를 호스트 애플리케이션의 매니페스트와 결합합니다. SDK가 번들 매니페스트에 불필요한 권한을 선언한 경우, tools:node="remove"를 사용하여 명시적으로 제거하지 않으면 최종 병합된 매니페스트로 해당 권한이 상속됩니다.
• iOS 호스트 기능 및 엔타이틀먼트: 안드로이드 매니페스트와 달리, 범용 링크용 com.apple.developer.associated-domains와 같은 iOS 시스템 엔타이틀먼트는 타사 XCFramework에서 호스트 앱으로 자동 병합되지 않습니다. 대신 개발자는 Xcode에서 호스트 애플리케이션 타겟에 필요한 기능을 명시적으로 활성화하고, Apple Developer 포털에서 승인된 프로비저닝 프로필로 앱 바이너리에 서명해야 합니다.
• 릴리스 아티팩트 패키징: 안드로이드에서는 호스트 애플리케이션을 스토어 릴리스용으로 빌드할 때, 직접 설치 가능한 애플리케이션 패키지가 아닌 안드로이드 앱 번들(.aab)이 배포 아티팩트로 사용됩니다. Google Play 앱 번들 전달은 .aab를 사용자에게 전달되는 기기별 .apk 패키지로 처리합니다. iOS에서는 Xcode가 실행 파일과 포함된 프레임워크를 컴파일 및 서명하여 앱스토어 배포용 .ipa 아카이브로 만듭니다.

모바일 SDK 아티팩트의 해부학: 안드로이드 AAR 및 iOS XCFramework 패키지 내부

안드로이드 AAR 아카이브 내부: 바이트코드, 매니페스트, 리소스 및 네이티브 라이브러리

Android 아카이브(AAR) 해부학에 관한 Google 안드로이드 개발자 가이드에 따르면, AndroidManifest.xml은 .aar 아카이브에서 유일하게 필수적인 항목이며, classes.jar, R.txt, res/, 네이티브 .so 라이브러리, proguard.txt를 포함한 다른 항목들은 선택 사항이며 라이브러리 구현에 따라 다릅니다.

• /AndroidManifest.xml (필수): 라이브러리의 패키지 네임스페이스, 최소 지원 SDK 버전(minSdk), 필요한 시스템 권한 또는 컴포넌트 선언을 정의합니다.
• /classes.jar (선택): SDK의 공개 API 클래스 및 내부 구현 로직을 노출하는 컴파일된 Java 및 Kotlin 바이트코드(.class 파일)를 포함합니다.
• /res/ 및 /R.txt (선택): 심볼 ID 매핑과 함께 번들된 UI 레이아웃, 드로어블 에셋 또는 문자열 테이블을 포함합니다. 시각적 요소가 없는 인프라 SDK(모바일 어트리뷰션 및 딥 링크 라이브러리 등)의 경우 UI 리소스를 생략하여 불필요한 리소스 테이블 팽창을 방지합니다.
• /jni/[abi]/lib*.so (선택): 특정 CPU 애플리케이션 바이너리 인터페이스(arm64-v8a, armeabi-v7a, x86_64)를 타겟팅하는 사전 컴파일된 C 또는 C++ 네이티브 라이브러리.
• /proguard.txt (선택): 릴리스 축소 중에 보존해야 하는 SDK 클래스나 콜백 인터페이스를 호스트 앱의 난독화/최적화 도구에 지시하는 소비자 ProGuard 또는 R8 규칙.

iOS XCFramework 번들 내부: Info.plist, 플랫폼 변형 슬라이스, 헤더 및 모듈

애플 플랫폼에서 바이너리 SDK를 배포하려면 실제 물리적 iOS 기기(ARM64)와 iOS 시뮬레이터(ARM64 Apple Silicon 및 x86_64 Intel)를 실행하는 macOS 개발 기기를 모두 지원해야 합니다. 팻 바이너리 충돌 없이 멀티 플랫폼 배포를 지원하기 위해 애플은 Apple XCFramework(.xcframework) 사양을 도입했습니다. 표준 .framework 빌드는 일반적으로 특정 플랫폼 변형을 타겟팅하며 하나 이상의 지원되는 CPU 아키텍처를 포함할 수 있는 반면, .xcframework 번들은 물리적 ARM64 iOS 기기 슬라이스와 iOS 시뮬레이터 슬라이스와 같은 여러 플랫폼 및 아키텍처 변형을 단일 배포 가능 디렉터리로 패키징합니다.

• Info.plist (루트 매니페스트): 사용 가능한 모든 라이브러리 변형(AvailableLibraries)을 나열하고, SupportedPlatform(ios), SupportedPlatformVariant(시뮬레이터 대 기기), SupportedArchitectures(arm64, x86_64)를 지정합니다.
• ios-arm64/ 및 ios-arm64_x86_64-simulator/: 해당 타겟의 .framework 또는 정적 .a 바이너리를 포함하는 플랫폼별 하위 디렉터리. 아카이브 빌드 시 Xcode는 물리적 기기 슬라이스만 선택하고 최종 .ipa에서 시뮬레이터 슬라이스는 제외합니다.
• Headers/ 및 Modules/: Objective-C 및 Swift 컴파일러에 타입 정의를 노출하는 공개 Objective-C .h 헤더 파일(예: OpoInstallSDK.h) 및 Clang module.modulemap 파일.

# 예시 바이너리 디렉터리 비교: 안드로이드 .aar 대 iOS .xcframework
# 참고: .aar에서는 AndroidManifest.xml만 필수이며, 내부 XCFramework 경로는 공급업체 빌드에 따라 다를 수 있습니다.

opoinstall-android-sdk.aar                 libOpoInstallSDK.xcframework/
├── AndroidManifest.xml (필수)             ├── Info.plist
├── classes.jar (선택)                     ├── ios-arm64/
│   └── com/opoinstall/api/                │   ├── Headers/
│       ├── OpoInstall.class               │   │   └── OpoInstallSDK.h
│       ├── OpoData.class                  │   └── libOpoInstallSDK.a
│       ├── OpoError.class                 └── ios-arm64_x86_64-simulator/
│       └── ResultCallBack.class               ├── Headers/
└── proguard.txt (선택)                        │   └── OpoInstallSDK.h
                                               └── libOpoInstallSDK.a

[타사 모바일 SDK 아티팩트]
       |
       +---> 안드로이드 (.aar) ---> [AndroidManifest.xml + 선택적 classes.jar / proguard.txt]
       |                                  |
       |                                  v (Gradle 매니페스트 병합기 및 D8/R8 DEX 컴파일러)
       |                         [호스트 앱 .aab 퍼블리싱 아티팩트 -> Google Play .apk]
       |
       +---> iOS (.xcframework) -> [ios-arm64 기기 슬라이스 + ios-시뮬레이터 슬라이스]
                                          |
                                          v (Xcode 링커가 시뮬레이터 슬라이스 제거)
                                 [호스트 앱 .ipa 기기 실행 파일]

어트리뷰션 SDK에 내장된 기술적 성장 프로토콜

이 문서에서 "기술적 성장 프로토콜"이란 단일한 공식 표준을 지칭하기보다 모바일 어트리뷰션 SDK에 의해 구현되는 네이티브 라우팅, 설치 리퍼러, 파라미터 복원 및 이벤트 보고 메커니즘 모음을 의미합니다. 이러한 메커니즘을 살펴보면 성장 팀이 단순히 웹 추적 스크립트에만 의존하지 않고 클라이언트 SDK를 바이너리에 링크하는 이유가 명확해집니다.

프로토콜 1: URI 스킴 및 유니버설 링크 또는 앱 링크 라우팅 인터셉션

사용자가 H5 웹페이지(https://links.example.com/offer?room_id=402)에서 프로모션 링크를 탭하면 모바일 성장 SDK는 이미 앱이 설치되어 있는 사용자를 위해 직접적인 인앱 라우팅을 조율합니다.

• 시스템 검증 핸드셰이크: iOS 9 이상에서는 애플 유니버설 링크가 호스트 앱의 applinks: 엔타이틀먼트와 연결된 HTTPS 호스팅 apple-app-site-association(AASA) JSON 파일을 통해 도메인 소유권을 검증합니다. 안드로이드에서는 검증된 안드로이드 앱 링크가 앱의 패키지 이름과 SHA-256 서명 인증서 지문이 포함된 호스팅된 /.well-known/assetlinks.json 디지털 에셋 링크 파일과 대조하여 검증된, 타겟 android:host와 함께 http 및 https 스킴을 모두 선언하는 <intent-filter>에서 android:autoVerify="true"를 사용합니다.
• 라이프사이클 인터셉션: IETF RFC 3986에 따라 OS가 검증된 링크 또는 대체 커스텀 URI 스킴(scheme://)을 통해 애플리케이션을 깨울 때, 네이티브 SDK는 수신된 Intent(안드로이드의 onCreate 또는 onNewIntent를 통해) 또는 NSUserActivity / UIOpenURLContext(최신 씬 기반 iOS 앱의 UISceneDelegate 또는 애플이 씬 지원 앱에 대해 지원 중단으로 표시한 레거시 UIApplicationDelegate URL 처리 메서드를 통해)를 가로채고, 쿼리 페이로드를 파싱하여 라우팅 파라미터를 호스트 앱에 전달합니다.

프로토콜 2: 마켓플레이스 설치 리퍼러 IPC 바인딩

아직 애플리케이션이 설치되지 않은 상태에서 사용자가 구글 플레이스토어로부터 다운로드하는 경우, 브라우저 쿠키는 안드로이드 OS 샌드박스를 건너 새로 설치된 앱으로 넘어갈 수 없습니다. 안드로이드에서 이 격차를 결정적으로 해소하기 위해 클라이언트 SDK는 공식 Google Play 설치 리퍼러 API를 사용하는 프로세스 간 통신(IPC) 메커니즘을 구현합니다.

최초 실행 시 SDK는 안드로이드의 Binder IPC 인터페이스를 통해 구글 플레이스토어 서비스에 바인딩하고 클릭 및 설치 시작 타임스탬프와 함께 install_referrer 문자열을 읽습니다. 구글 플레이 설치 리퍼러 API는 적격한 구글 플레이스토어 설치 흐름에 구체적으로 적용되므로, 구글 플레이 외의 안드로이드 배포판은 서버 측 H5 파라미터 매칭 또는 내장된 channelCode 메타데이터를 담은 내보낸 안드로이드 채널 패키지(APK 파일)를 활용합니다.

프로토콜 3: 비동기 파라미터 복원 및 세션 조정 핸드셰이크

애플이 구글 플레이의 설치 리퍼러에 해당하는 일반적인 URL 쿼리 파라미터 패스스루를 제공하지 않는 iOS 앱스토어 설치를 포함하여 크로스 플랫폼 웹투앱 여정의 경우, 클라이언트 SDK는 IETF RFC 9110에 따라 HTTPS를 통한 비동기 파라미터 복원 핸드셰이크를 실행합니다.

1. 설치 전 웹 컨텍스트 업로드: 사용자가 H5 공유 페이지를 방문할 때 통합 웹 JS SDK는 URL에 추가된 커스텀 파라미터(초대자 ID 또는 channelCode 등)를 파싱하고 설치 전 세션 레코드를 어트리뷰션 서버에 업로드합니다.
2. 설치 후 클라이언트 핸드셰이크: 사용자가 새로 설치된 앱을 열면 클라이언트 SDK가 초기화되어 테넌트 AppKey를 통해 등록된 애플리케이션을 식별하고 공급업체에 필요한 추가 세션 검증 또는 인증 메커니즘을 사용하여 HTTPS를 통해 어트리뷰션 서버와 통신합니다. 그런 다음 서버는 캐시된 커스텀 파라미터(data)와 채널 식별자(channelCode)를 복원하려고 시도합니다. 내장된 AppKey는 독립형 인증 비밀로 취급되어서는 안 됩니다.
3. 공급업체 메커니즘 대 플랫폼 개인정보 보호 경계: Openinstall의 공개 제품 문서는 웹 SDK가 H5 페이지에서 기기 핑거프린트와 채널 ID를 수집하고, 네이티브 안드로이드/iOS SDK가 최초 실행 시 기기 핑거프린트를 다시 수집하여 설치 소스와 일치시키는 H5 채널 및 파라미터 설치 워크플로우를 설명합니다. 애플의 사용자 개인정보 보호 및 데이터 사용 지침에 따라, 애플은 기기에서 데이터를 파생하여 사용자를 고유하게 식별하는 행위(핑거프린팅)를 명시적으로 금지하며, 금지된 핑거프린팅에 관여하는 타사 SDK를 참조하는 앱은 앱스토어 거부 위험에 처하게 됩니다. 별도로, 타사 딥 링크 또는 지연된 딥 링크 서비스가 고유 식별자를 전달하거나 광고 타겟팅, 광고 측정 또는 데이터 브로커 공유를 위해 서로 다른 회사의 앱 간에 공유 사용자 아이디를 생성할 때 앱 추적 투명성(ATT) 승인이 필요하며—ATT 동의로 인해 금지된 기기 핑거프린팅이 허용되는 것은 아닙니다. 공급업체가 iOS 매칭 메커니즘이 금지된 기기 핑거프린팅을 회피함을 입증할 수 없는 경우, 독립적으로 검증된 준수 대안이 마련될 때까지 개발자는 iOS에 해당 어트리뷰션 메커니즘을 배포해서는 안 됩니다.

프로토콜 4: 중복 제거된 채널 및 전환 이벤트 텔레메트리

설치 소스가 해결되면 SDK는 비동기 이벤트 보고 인터페이스를 제공합니다. 앱 측에서 설치 및 가입 보고를 중복 제거하고 개발자가 커스텀 전환 "효과 포인트"(saveEvent / reportEffectPoint) 또는 바이럴 공유 액션(shareCode가 포함된 reportShare)을 보고할 수 있도록 허용함으로써, SDK는 커스텀 재시도 큐 없이도 채널 성과 분석을 지원합니다. 자세한 사양과 API 정의는 Openinstall 기술 문서에서 확인할 수 있습니다.

SDK 바이너리 풋프린트 및 전파 의존성 감사

모바일 엔지니어링 및 사용자 유치에 SDK 비대화가 중요한 이유

애플의 앱 크기 줄이기(앱 스리밍) 지침에 언급된 바와 같이, 더 큰 애플리케이션 패키지는 다운로드 시간과 스토리지 요구 사항을 증가시켜 제한된 네트워크 또는 기기 환경에서 설치 완료율에 잠재적인 영향을 미칠 수 있습니다. 타사 SDK의 영향은 패키지 크기 자체로 짐작하기보다 경험적인 빌드 크기 측정과 관찰된 퍼널 지표를 통해 정량화되어야 합니다.

전파 의존성의 숨겨진 비용: 메서드 참조 제한 및 라이브러리 충돌

SDK 비대화와 빌드 불안정성의 주원인은 SDK의 핵심 어트리뷰션 로직인 경우는 드물며, 오히려 SDK가 Gradle이나 CocoaPods를 통해 호스트 프로젝트로 자동으로 끌어들이는 외부 오픈소스 라이브러리인 전파 의존성(transitive dependencies)이 원인입니다.

• 의존성 버전 충돌: 타사 SDK가 일반적인 네트워킹 또는 직렬화 라이브러리(OkHttp, Gson, Retrofit, Protobuf 등)의 특정 버전에 대한 전파 의존성을 선언하고, 호스트 애플리케이션이 동일한 라이브러리의 호환되지 않는 메이저 버전을 사용하는 경우 중복 클래스 오류로 인해 빌드가 실패하거나 런타임에 NoSuchMethodError 예외로 인해 충돌이 발생할 수 있습니다.
• DEX 메서드 참조 오버헤드: 안드로이드에서는 안드로이드 멀티덱스 기술 가이드에 따라 개별 .dex 파일이 65,536개의 메서드 참조로 제한됩니다. 이는 전체 애플리케이션 메서드 제한이라기보다는 DEX 파일당 참조 제한에 가깝습니다. multidex를 사용하면 애플리케이션이 여러 DEX 파일에 걸쳐 참조를 패키징할 수 있지만, 여전히 대규모 전파 의존성 트리를 끌어들이면 DEX 파일 수, R8 컴파일 시간, 최종 APK 크기가 증가합니다.
• 공급망 보안 표면: OWASP 모바일 애플리케이션 보안 프로젝트 표준에 따라 SDK에 의해 끌어들여진 모든 전파 라이브러리는 애플리케이션의 소프트웨어 공급망 공격 표면을 넓히며 지속적인 취약점 모니터링을 요구합니다.

결과적으로 미니멀리스트 어트리뷰션 SDK는 불필요한 외부 전파 의존성을 피하고, 대신 모바일 운영 시스템의 내장 네트워킹(HttpURLConnection / NSURLSession)과 네이티브 JSON 파서(org.json / NSJSONSerialization)에 의존해야 합니다.

Android Studio APK Analyzer 및 Xcode 앱 스리밍 리포트를 사용하여 실제 바이너리 영향 검사

엔지니어링 팀은 SDK의 풋프린트를 평가할 때 검증되지 않은 크기 주장이나 다운로드한 .zip 아카이브의 원시 압축 크기에 전적으로 의존해서는 안 됩니다. Openinstall 모바일 SDK 다운로드 센터에서 네이티브 안드로이드 및 iOS SDK 패키지(현재 v2.1.0, 2026-09-20 출시)를 배포하지만, 실제 컴파일된 바이트 델타, 전파 의존성 수, DEX 메서드 참조 증가분은 베이스라인 빌드와 SDK 통합 빌드를 비교하여 본인의 프로젝트에서 경험적으로 측정해야 합니다.

• 안드로이드 의존성 트리 및 APK Analyzer: Gradle의 의존성 태스크를 실행하여 SDK가 전파 라이브러리를 끌어들이는지 확인하고, 공식 APK Analyzer에 관한 Google 안드로이드 개발자 가이드(apkanalyzer CLI 또는 Android Studio GUI)를 사용하여 파일 크기 차이에 대한 apk compare 실행, 양쪽 빌드에서 dex references를 실행하여 메서드 참조 수 비교, 그리고 apk download-size를 실행하여 다운로드 크기 영향 추정을 수행합니다.
• 앱 스리밍 크기 리포트를 통한 iOS 베이스라인 비교: .xcframework 아카이브에는 물리적 기기와 시뮬레이터 슬라이스가 모두 포함되어 있으므로 디스크상의 원시 폴더 크기가 최종 사용자가 다운로드하는 크기와 일치하지 않습니다. 동일한 릴리스 설정을 사용하여 베이스라인 빌드(SDK 없음)와 SDK 통합 빌드 모두에 대해 Xcode Organizer에서 앱 스리밍 크기 리포트를 내보냅니다. 동일한 기기 변형에 대한 압축 및 비압축 크기를 비교하여($\Delta S = S_{\text{with SDK}} - S_{\text{baseline}}$) SDK의 증가하는 풋프린트를 추정하고 App Store Connect에서 최종 배포 크기를 확인합니다.

다음 CLI 명령어는 전파 의존성, APK 크기 델타, XCFramework 슬라이스를 감사하는 방법을 보여줍니다(아래의 xcrun lipo 경로는 예시용입니다. lipo 명령어를 구성하기 전에 항상 .xcframework 내부의 실제 Info.plist와 선택된 라이브러리 변형을 검사하세요).

# 1. 안드로이드: 원하지 않는 전파 라이브러리가 없는지 확인하기 위해 릴리스 런타임 의존성 검사
./gradlew :app:dependencies --configuration releaseRuntimeClasspath

# 2. 안드로이드: 베이스라인 및 SDK 통합 APK의 DEX 메서드 참조 수 검사
apkanalyzer dex references baseline-release.apk
apkanalyzer dex references with-sdk-release.apk

# 3. 안드로이드: 원시 APK 파일 크기 및 추정된 오버더에어 다운로드 크기 검사
apkanalyzer apk file-size with-sdk-release.apk
apkanalyzer apk download-size with-sdk-release.apk

# 4. 안드로이드: 베이스라인 APK(SDK 없음)와 SDK가 통합된 APK 비교
apkanalyzer apk compare baseline-release.apk with-sdk-release.apk

# 5. iOS: XCFramework 루트 플리스트에서 지원되는 플랫폼 및 아키텍처 변형 검사
plutil -p libOpoInstallSDK.xcframework/Info.plist

# 6. iOS: Info.plist 검사 후 특정 기기 바이너리 슬라이스에 대한 예시 lipo 확인
xcrun lipo -info libOpoInstallSDK.xcframework/ios-arm64/libOpoInstallSDK.a

모바일 SDK 바이너리 풋프린트 및 아키텍처 평가 매트릭스

헤비웨이트 모놀리식 SDK 대 미니멀리스트 어트리뷰션 SDK 비교

타사 모바일 SDK에 대한 아키텍처 검토를 수행할 때 엔지니어링 리드는 다음 다섯 가지 구조적 차원에 걸쳐 후보를 평가할 수 있습니다.

엔지니어링 팀에게 전용 성장 SDK가 필요한 시점

경량 어트리뷰션 SDK가 아키텍처 관점에서 정당화되는 시나리오

전용 모바일 어트리뷰션 및 딥 링크 SDK를 통합하는 것은 다음과 같은 조건에서 적절합니다.

• 샌드박스 간 파라미터 복원: 사용자 유치 퍼널이 H5 웹페이지, 소셜 공유 또는 QR 코드를 통해 앱스토어나 구글 플레이로 사용자를 라우팅하며, 수동 코드 입력 없이 최초 실행 시 커스텀 파라미터(추천 코드나 방 ID 등)를 복원해야 하는 경우.
• 통합된 딥 링크 라우팅 유지 관리: 팀이 다양한 모바일 브라우저와 소셜 인앱 WebView에서 유니버설 링크, 안드로이드 앱 링크, 대체 커스텀 URL 스킴을 처리하기 위해 단일 클라이언트 콜백 인터페이스를 원하는 경우.
• 다채널 H5 및 APK 패키지 트래킹: 마케팅 운영팀이 H5 채널 링크와 안드로이드 채널 패키지에 걸쳐 캠페인을 배포하고 통합된 설치, 가입, 전환 이벤트 보고를 필요로 하는 경우.

모바일 SDK 추가를 피해야 하는 시나리오

반대로 다음과 같은 상황에서는 타사 클라이언트 SDK 추가를 피해야 합니다.

• 중복된 클라이언트 기능: 제안된 SDK가 애플리케이션이 이미 네이티브 OS API나 기존 코어 라이브러리를 사용하여 깔끔하게 구현하고 있는 기능을 중복하는 경우.
• 검증되지 않은 개인정보 보호 또는 준수 태세: SDK가 현재 앱스토어 검토 지침 및 지역 데이터 보호 법률을 준수하는 것으로 독립적으로 검증할 수 없는 기기 매칭 신호(iOS의 금지된 기기 핑거프린팅 등)에 의존하는 경우.
• 순수 백엔드 분석 워크플로우: 추적해야 하는 이벤트가 인증된 백엔드 서버(정기 구독 갱신 등)에서 전적으로 발생하여 직접 서버 대 서버(S2S) HTTP API가 클라이언트 바이너리 풋프린트를 방지할 수 있는 경우.

모바일 SDK 아키텍처에 대한 일반적인 오해

• 오해 1: 다운로드한 SDK 압축 파일 크기는 앱 크기 증가량과 같다: 다운로드한 .xcframework 또는 .aar 아카이브에는 릴리스 컴파일 중에 Xcode 앱 스리밍 및 안드로이드 R8에 의해 제거되는 시뮬레이터 슬라이스, 헤더 파일, 압축되지 않은 메타데이터가 포함되어 있습니다. 베이스라인 릴리스 빌드와 SDK 통합 릴리스 빌드 간의 증가분 델타($\Delta S$)를 항상 측정하세요.
• 오해 2: 전파 의존성이 없다는 것은 개인정보 보호 감사가 필요 없다는 의미이다: 타사 오픈소스 라이브러리를 전혀 사용하지 않는 자체 완결형 SDK조차도 애플리케이션의 개인정보 보호 경계 내부에서 실행됩니다. 엔지니어링 팀은 릴리스 전에 SDK가 수집하는 모든 네트워크 요청, plist 선언, 기기 신호를 감사해야 합니다.

요약 및 바이너리 평가 체크리스트

모바일 개발에서 진정한 SDK의 의미를 이해하려면 상위 수준의 약어 정의를 넘어 컴파일된 라이브러리가 애플리케이션 바이너리에 어떻게 병합되고 기술적 성장 프로토콜을 실행하는지 살펴봐야 합니다. 잘 설계된 모바일 어트리뷰션 SDK는 바이너리 풋프린트와 전파 의존성 트리를 최소한으로 유지하면서 샌드박스 간 라우팅, 설치 리퍼러 바인딩, 파라미터 복원을 캡슐화합니다.

프로덕션 릴리스를 위해 타사 모바일 SDK를 승인하기 전에 엔지니어링 리드는 다음 바이너리 및 규정 준수 검증 체크리스트를 실행해야 합니다.

• 의존성 트리 검사: ./gradlew :app:dependencies --configuration releaseRuntimeClasspath를 실행하거나 Podfile.lock을 검사하여 SDK가 충돌을 일으키는 전파 라이브러리를 도입하는지 확인합니다.

• 컴파일 후 증가된 크기 측정($\\Delta S$): 안드로이드에서는 apkanalyzer apk compare를 사용하고 iOS에서는 베이스라인 대 통합 앱 스리밍 크기 리포트를 사용하여 베이스라인 릴리스 빌드와 SDK 통합 빌드(현재 다운로드한 아카이브인 v2.1.0 등 테스트)를 비교합니다.

• API 서명 및 클린 빌드 확인: 클린 빌드 환경에서 모든 패키지 임포트, 매니페스트 필터(안드로이드 앱 링크용 http 및 https 스킴), 라이프사이클 콜백(UISceneDelegate 대 지원 중단된 AppDelegate URL 메서드)을 확인합니다.

• 프로토콜 및 개인정보 보호 준수 감사: 모든 딥 링크 엔타이틀먼트, 설치 리퍼러 바인딩, 서버 측 매칭 신호가 금지된 기기 핑거프린트를 회피하며 현재 애플 사용자 개인정보 보호 지침 및 구글 플레이 정책을 준수하는지 공급업체와 확인합니다.

엔지니어링 팀은 Openinstall 개발자 콘솔에 테스트 애플리케이션을 등록하여 SDK 통합을 평가하고 스테이징 빌드에서 바이너리 풋프린트를 측정할 수 있습니다.

관련 자료

• 개념: 소프트웨어 개발 키트 의미, 바이너리 풋프린트, 전파 의존성, 기술적 성장 프로토콜

• 기술: 안드로이드 아카이브(.aar), 애플 XCFramework(.xcframework), Android Studio APK Analyzer, Xcode 앱 스리밍

• 표준: IETF RFC 9110 HTTP 시맨틱스, IETF RFC 3986 URI 일반 구문, OWASP 모바일 애플리케이션 보안 프로젝트

• 플랫폼 및 통합 인터페이스: Gradle 의존성 관리, 안드로이드 D8/R8 컴파일러, Xcode 링커, Google Play 설치 리퍼러 API, 애플 유니버설 링크

• 공식 문서 및 참고 자료:

  • Android 아카이브(AAR) 해부학에 관한 Google 안드로이드 개발자 가이드

  • APK Analyzer CLI에 관한 Google 안드로이드 개발자 가이드

  • 코드 축소 및 최적화(D8/R8)에 관한 Google 안드로이드 개발자 가이드

  • 멀티덱스에 관한 Google 안드로이드 개발자 가이드

  • 앱 번들에 관한 Google 안드로이드 개발자 가이드

  • 앱 링크에 관한 Google 안드로이드 개발자 가이드

  • Google Play 설치 리퍼러 API 기술 가이드

  • 멀티 플랫폼 바이너리 프레임워크 번들(XCFramework) 생성에 관한 애플 개발자 문서

  • 앱 크기 줄이기(앱 스리밍)에 관한 애플 개발자 문서

  • 유니버설 링크 지원에 관한 애플 개발자 문서

  • 애플 사용자 개인정보 보호 및 데이터 사용 지침