경쟁사 Android 앱이 어떤 SDK, 광고 네트워크, API를 쓰는지 알아내는 법

본문

앱을 설치하는 데는 10초면 충분하지만, 그 앱이 어떻게 돈을 버는지는 알 수 없습니다. 이 글은 그 간극을 메우는 방법, 즉 Play Store URL 하나에서 출발해 SDK 목록, 광고 네트워크, API 엔드포인트까지 뽑아내는 전체 워크플로우를 무료 도구만으로 설명합니다. Mac이나 Linux에서 동작하고 루팅된 디바이스도 필요 없습니다. 전제 조건은 APK를 확보하는 것인데, APKMirror나 APKPure 같은 신뢰할 수 있는 미러, 또는 개발자 자신의 번들에서 bundletool로 추출해 로컬에 보관하되, 분석이 목적이므로 재배포는 하지 말 것을 당부합니다.

Manifest만으로 답되는 절반의 질문

APK는 사실 ZIP 파일입니다. unzip -l로 패키지 구성을 확인하고 AndroidManifest.xml을 aapt2 dump나 apktool로 읽으면 이미 많은 정보가 나옵니다. 권한만 봐도 수익화 의도가 보이는데, AD_ID, ACCESS_FINE_LOCATION, POST_NOTIFICATIONS, BILLING, RECEIVE_BOOT_COMPLETED 같은 권한이 대표적입니다. 선언된 서비스와 리시버에는 광고 SDK가 등록한 백그라운드 컴포넌트가 알아볼 수 있는 이름으로 남아 있고, Adjust, AppsFlyer, Facebook 같은 어트리뷰션 SDK는 앱 ID를 <meta-data> 블록에 평문으로 넣습니다. minSdk와 targetSdk는 앱이 얼마나 활발히 유지보수되는지 보여주는 빠른 신호입니다. 저자는 사람들이 묻는 질문의 절반이 이 단계에서 이미 답된다고 말합니다.

jadx + grep으로 광고 SDK 식별하기

앱을 재빌드하는 게 아니라 문자열, 클래스명, 의존성만 필요합니다. apktool d로 리소스와 smali를 풀고, jadx로 grep 가능한 Java 유사 소스를 얻습니다. 난독화된 앱은 이름이 다 바뀌지만 SDK 연동 코드는 거의 난독화되지 않는데, SDK 벤더가 자기 클래스명을 그대로 배포하고 앱이 그 이름을 호출해야 하기 때문입니다. 여기서 grep으로 AdMob(com.google.android.gms.ads), Meta Audience Network(com.facebook.ads), AppLovin/MAX(com.applovin), Unity Ads, ironSource/LevelPlay, Vungle·Chartboost·AdColony, 어트리뷰션(Adjust·AppsFlyer·Kochava), 분석·크래시(Amplitude·Mixpanel·Sentry)를 찾습니다.

다만 진짜 답과 grep 결과를 가르는 디테일이 세 가지 있습니다. 첫째, 클래스명이 존재한다고 그 네트워크가 실제로 동작하는 건 아닙니다. 초기화 호출과 미디에이션 설정(applovin_settings, MAX_Ad_Unit, 리모트 설정 키)을 확인해야 합니다. 둘째, 일부 SDK는 런타임에 로드되는 숨겨진 DEX 형태로 assets/에 들어 있어 classes.dex grep으로는 잡히지 않습니다. 셋째, SDK 개수가 아니라 미디에이션 어댑터(com.applovin.mediation.adapters.*, com.google.ads.mediation.*) 개수를 세어야 실제로 노출 경쟁에 참여하는 네트워크를 알 수 있습니다.

API 엔드포인트 히스토그램과 실제 발견 사례

리소스와 코드에서 https?:// 패턴을 뽑아 호스트명별로 카운트를 정렬하면 엔드포인트 목록이 나옵니다. 이를 벤더 자체 게이트웨이(first-party)와 SDK 엔드포인트(third-party)로 나누면 되는데, 흥미로운 구조와 '남겨두면 안 되는 것들'은 주로 first-party 쪽에 있습니다.

저자는 공개한 teardown 중 세 가지 발견을 소개합니다. 첫째, 광고 네트워크 6개를 하이브리드 헤더비딩+워터폴 방식으로 동시에 돌리는 앱입니다. 미디에이션 어댑터 6개에 서버 제어 설정(ScannerRewardRatio.xml, 리모트 엔드포인트)이 붙어 있어 업데이트 배포 없이 네트워크 가중치를 조정할 수 있는 구조로, 미디에이션 스택을 만든다면 생산성 카테고리의 참조 아키텍처라고 평가합니다. 둘째, Facebook Audience Network가 약 5MB의 audience_network.dex로 assets/에 숨겨져 런타임에 로드되는 사례입니다. 베이스 APK를 작게 유지하려고 콜드 스타트 수백 ms를 감수한 의도적 트레이드오프이며, 단순 classes.dex grep으로는 완전히 놓칩니다. 셋째, 샌드박스/스테이징 호스트 6개가 프로덕션에 그대로 남은 사례로, 취약점 자체는 아니지만 그 팀의 배포 방식을 보여주며, 출시 전에 -dev, -staging, -test를 grep해야 한다는 교훈을 줍니다.

같은 워크플로우로 인증 제공자(한 앱에서 지역 특화 포함 7개를 찾았다고 함), API 응답의 암호화 계층, Topics·Attribution·Ad ID 같은 프라이버시 API가 선언만 됐는지 실제 연결됐는지도 확인할 수 있습니다. 앱이 네이티브·하이브리드·Flutter인지는 lib/*.so, flutter_assets/, classes.dex 개수로 판별합니다.

주의점은 두 가지입니다. 모든 분석은 특정 APK 버전의 스냅샷이므로 버전 코드와 날짜를 함께 기록하지 않으면 결과가 조용히 낡습니다(버전 드리프트). 그리고 번들된 SDK와 실제 사용되는 SDK는 다르므로, 비즈니스 판단에 쓸 내용은 초기화와 도달 가능성까지 확인해야 합니다.

저자는 appxray.blackorange.org에 CamScanner(306MB XAPK, 27개 split APK, 6개 네트워크 미디에이션)와 Duolingo teardown을 무료로 공개해 두었고, 원하면 Play Store 링크를 보내 약 2시간 만에 앱당 $29(3개 이상이면 $19)에 리포트를 받는 유료 서비스도 운영합니다. 글 말미에 이 서비스를 파는 팀이 쓴 글이라고 명시하면서, 방법론 자체는 무료로 완결되어 있으니 직접 실행하거나 공개 샘플로 결과물 품질을 먼저 판단할 수 있다고 밝힙니다.

원문: dev.to / 번역·요약: Trawling