📱 [최신] Don't Trust the Super-App — 러시아 국영 MAX 사례로 증명된 슈퍼앱의 '구조적 감시' 능력 (2026)

논문 정보

연구 배경 — 10년간 '신뢰받는 중개자'로 가정해온 슈퍼앱

슈퍼앱(super-app)은 하나의 호스트 앱 안에 서드파티 미니앱을 임베드해 결제·교통·정부 서비스까지 한 앱에서 쓰게 하는 모바일 아키텍처다. 위챗(WeChat)이 대표적이며, 지난 10년의 보안 연구는 슈퍼앱 생태계를 다루면서도 슈퍼앱 자체는 늘 '신뢰할 수 있는 중개자(trusted intermediary)'로 전제해왔다.

이 논문은 그 전제 자체에 도전한다. 논문이 드는 근거는 구체적이다.

• 중국 위챗: 미니앱 전반에 걸친 사용자 활동을 수동적으로 대규모 추적하는 것이 이미 확인됐다.
• 러시아 MAX: 모회사가 온라인 발언에 대한 국가 기소와 깊이 얽혀 있다고 보고됐다.
• 이란 Bale: 국가 지원을 받아 세계에서 가장 긴 인터넷 셧다운 상황에서도 동작했다.
• 베트남 Zalo: 월 7,900만 사용자를 대상으로 확대된 데이터 수집 약관을 적용하며, 사이버보안법에 따라 정부 데이터 요청에 응할 법적 의무를 진다.

"수억 명의 사용자가 독립적이고 샌드박스화된 서비스라고 믿는 것을 쓰면서, 실제로는 단일 앱 안에서 완전히 동작하고 있다." — 논문 본문

핵심 아이디어 — 능력은 '버그'가 아니라 아키텍처 그 자체다

논문의 위협 모델은 명확하다. 악의적이거나, 혹은 국가에 의해 강제된 슈퍼앱 호스트를 가정하고, 호스팅되는 미니앱은 선의(정상 서비스 제공)라고 본다. 즉 호스트가 악해지는 순간 어떤 피해가 가능한지를 따진다.

• 미니앱은 OS 수준 정체성이 없다: 자체 앱 패키지도, UID도, 전용 저장 디렉터리도 없다. 호스트의 OS 정체성과 샌드박스 안에서 전부 돌아간다.
• WebView가 곧 실행 샌드박스: 호스트가 WebView(Android) / WKWebView(iOS)를 인스턴스화하고 설정하면서, 그 안에서 돌 미니앱의 실행 환경을 통째로 쥔다. 카메라·연락처·위치 같은 네이티브 권한도 OS가 아니라 호스트의 브리지 계층이 중개한다.
• JavaScript 브리지가 중심축: 호스트↔미니앱 통신의 단일 통로를 호스트가 소유한다. 따라서 미니앱이 "내 코드는 안전하다"고 주장해도, 실행·저장·인증·통신을 모두 남의 손 위에서 하는 구조다.
• Android의 사각지대: Android는 슈퍼앱을 그냥 '평범한 앱'으로 취급한다. 호스트가 미니앱에 대해 갖는 특권적 가시성과 제어력을 모델에 담지 못한다 — 논문이 말하는 '아키텍처적 블라인드 스팟'이다.

사례 연구 — 러시아 MAX: 왜 이 앱이 최적의 표본인가

• 강제 보급 규모: MAX는 2025년 3월 VK가 출시한 국영 메신저로, 결제·학교·정부 서비스를 흡수하도록 설계됐다. 채팅 앱을 넘어 하나의 국가 인프라를 겨냥한 슈퍼앱이다.
• 설치 급증 = 경쟁 앱 차단과 동기화: 논문의 Google Play 설치 통계(2025-06 ~ 2026-06)에서 2025년 8월 중순 7일 이동평균 설치량이 하루 약 82만 3천 건까지 치솟는다. 이는 로스콤나조르(러시아 통신 감독기관)가 왓츠앱·텔레그램의 음성·영상 통화를 제한한 시점과 정확히 겹치며, 이후 MAX가 한때 러시아 앱 순위 1위가 됐다. 참고로 텔레그램 차단율은 2026년 95%까지 올랐다.
• 분석 자체를 방해하는 설계: 러시아 내 배포용 APK(러시아 휴대폰에 사전 설치)와 Google Play 버전이 서로 다르고, 다수 미니앱은 러시아 네트워크에서만 동작한다. MAX는 VPN API 신호·SIM 메타데이터·GPS 좌표·기기 식별자를 교차 참조해 위치를 탐지하므로 해외에서의 체계적 분석이 어렵다.
• 어떻게 측정했나: Android 기기에 Frida로 MAX를 계측(instrumentation)하고 트래픽을 통제된 지점으로 터널링해 평문 로그를 수집했다. 이어 바이너리 RPC 프로토콜을 역공학했는데, 각 메시지가 10바이트 헤더(매직 0x0a) + MessagePack 인코딩 본문 구조라 일반 MITM 프록시로는 파싱이 불가능했다. 총 90개 미니앱(의료·정부 서비스·은행/금융·통신·커머스·교육·관광)을 실제로 조작하며 로그를 수집·상관 분석했다.

실증된 5가지 능력 — '아무 흔적 없이' 가능하다

• ① 미니앱 UI 캡처: MAX 프로세스 내부에서 View.draw(Canvas)를 호출해 미니앱 화면을 그대로 덤프할 수 있음을 확인했다. 소프트웨어 View의 한계로 일관되진 않았지만 약 73%의 시도에서 성공했다 — 화면 녹화·스크린샷을 막아둔 뱅킹 미니앱에도 적용 가능한 경로다.
• ② 미니앱 로컬 스토리지 읽기/쓰기: 호스트가 같은 프로세스·같은 저장 영역을 쥐고 있으므로 미니앱의 로컬 데이터에 자유롭게 접근한다.
• ③ 임의 JavaScript 주입: 미니앱 런타임에 호스트가 JS를 밀어 넣어 미니앱의 로직을 그 자리에서 바꿀 수 있다.
• ④ 네트워크 트래픽 중개: 미니앱의 모든 통신이 호스트 브리지를 통과하므로, 호스트가 이를 관찰·변조·재작성한다.
• ⑤ 무음 사용자 사칭(silent impersonation): 인증 컨텍스트를 조작해 사용자 본인인 것처럼 미니앱에 요청을 보낼 수 있다. 미니앱 입장에서는 정상 사용자로 보인다.

논문의 결론은 이 능력들이 MAX 고유의 결함이 아니라는 점이다. 설계상 호스트에게 부여된 아키텍처적 특권이므로 어떤 슈퍼앱에서도 동일하게 발현된다. 위협 모델도 '국가 강제'에 한정되지 않는다 — 호스트가 단순히 악의적이어도 성립한다.

권고와 한계 — 미니앱이 호스트와 '독립적으로' 신뢰를 세울 수 있게

• 투명성: 사용자에게 보이는 투명성 메커니즘(user-facing transparency)을 추가해, 호스트가 미니앱과 무엇을 주고받는지 관측 가능하게 만들 것.
• 감사 가능성: 슈퍼앱↔미니앱 통신에 대한 감사(auditability)를 보장할 것.
• 아키텍처 격리: 미니앱이 슈퍼앱과 무관하게 독립적으로 신뢰를 수립할 수 있도록 격리를 강화할 것 — 즉 모바일 OS와 앱스토어 차원의 개입이 필요하다는 것이 논문의 최종 주장이다.
• 한계: 단일 사례(MAX)에 대한 정성적·역공학 기반 분석이며, 90개 미니앱은 전체 생태계의 표본이다. 계측은 Frida 기반이므로 '이벤트 추출과 심볼릭 추상화'에 대한 신뢰 가정이 붙는다. 또한 공격 표면의 실증이 목적이므로, 방어(권고)는 방향 제시 수준이고 정량 평가는 아니다.
• 실무적 함의: 미니앱 개발자·앱스토어 심사자·모바일 OS 벤더 모두에게 시사점이 크다. "서드파티 미니앱 = 격리된 서비스"라는 사용자 인식과 실제 권한 구조가 다르며, 특히 정부가 통제하는 슈퍼앱이 금융·정부 서비스를 흡수할 때 그 차이는 감시 인프라로 직결된다.

출처

• 원문(arXiv:2609.11814, 2026-09-10 제출 · CC BY 4.0): arxiv.org/abs/2609.11814
• PDF 전문: arxiv.org/pdf/2609.11814
• HTML 전문(본문 표·수치 출처): arxiv.org/html/2609.11814v1
• DOI(DataCite): doi.org/10.48550/arXiv.2609.11814