Android 사이드로딩 딜레마: 보안 vs 사용자 자유

구글이 Play 스토어 밖에서 앱을 설치하는 과정을 눈에 띄게 더 어렵게 만들었습니다. 새 절차에 따르면 Google Play Protect 검증을 거치지 않은 사이드로딩 앱은 24시간을 기다려야 하며, 그 동안 APK가 스캔을 위해 구글 서버에 업로드됩니다. 서드파티 소스에서 앱을 설치하면 하루 꼬박 기다린 뒤에야 쓸 수 있는 셈이죠. 보안상의 이유는 단순합니다. 악성코드가 심긴 APK는 실제로 큰 문제이고, 특히 사이드로딩이 흔한 지역에서는 더 그렇습니다. 개발자와 파워 유저들의 반응은... 그다지 호의적이지 않습니다.

이번 변화는 Android가 출범 이래 줄곧 안고 온 긴장 관계의 한가운데에 있습니다. 사용자에게 원하는 앱을 자유롭게 설치할 권한을 주면서, 그 방법을 잘 모르는 사용자도 보호하려면 어떻게 해야 할까요? Android는 18년 동안 이 질문에 답을 계속 다듬어 왔고, 그 답은 계속 바뀌고 있습니다.

Android 앱 설치 방식의 간략한 역사

초기 Android는 사실상 무법지대였습니다. 어떤 앱이든 한 번의 탭으로 어떤 소스에서든 설치할 수 있었죠. 설정의 'Unknown Sources(알 수 없는 출처)' 토글은 전역 스위치였습니다. 이걸 켜면 기기의 모든 앱이 APK를 설치할 수 있었습니다. 단순하고 사용자에게 힘을 실어 주는 방식이었지만, 보안 측면에서는 악몽이었습니다.

Android 8(Oreo, 2017)에서는 소스별 권한으로 바뀌었습니다. 전역 토글 대신 각 앱이 개별적으로 '알 수 없는 앱 설치' 권한을 요청해야 하게 된 것이죠. 브라우저에는 APK 설치를 허용하면서도 이메일 클라이언트에는 허용하지 않을 수 있게 됐습니다. 손상된 앱의 피해 범위를 줄여 준다는 점에서 확실한 개선이었습니다.

Android 13에서는 제한된 설정(restricted settings)이 추가됐습니다. 사이드로딩된 앱은 추가 확인 대화상자를 거치지 않고서는 특정 민감한 API(접근성 서비스, 알림 리스너 등)에 접근할 수 없게 됐습니다. 논리는 이렇습니다. Play 스토어 밖의 앱은 검증을 거치지 않았으니, 가장 강력한 권한에 쉽게 접근하면 안 된다는 것이죠.

이제 24시간 검증 기간이 또 하나의 마찰 계층을 더합니다. 변경이 거듭될 때마다 사이드로딩은 더 어려워지고, 그때마다 실제 보안 데이터가 정당화 근거로 제시됩니다. 문제는 이런 마찰이 누적되어 '사용자 보호'의 선을 넘어 '사용자를 Play 스토어로 몰아넣기'가 되었느냐는 것입니다.

사이드로딩이 실제 보안 문제인 이유

구글의 우려를 무시하기 전에 짚어 둘 점이 있습니다. 사이드로딩된 악성코드는 실재하고 대규모로 일어나는 문제입니다. 구글 자체 데이터에 따르면 Play 스토어 밖에서 설치된 앱은 Play 스토어 앱보다 악성코드를 포함할 가능성이 50배 높습니다. 동남아시아처럼 서드파티 앱 스토어가 인기 있는 시장에서는, Play 스토어 사용이 지배적인 시장보다 악성코드 감염률이 훨씬 높습니다.

공격 방식은 씁쓸할 정도로 효과적입니다. 사용자는 WhatsApp, SMS, 이메일 등으로 '은행 보안 업데이트', '폰 정리 앱', '무료 프리미엄 앱' 링크가 담긴 메시지를 받습니다. 그러면 APK를 내려받고, 보안 경고를 무시한 채(경고를 무시하도록 길들여졌으니까요) 설치합니다. 악성코드는 (역시 사용자를 설득해서) 접근성 서비스 권한을 얻고, 은행 자격 증명을 훔치거나 SMS 인증 코드를 가로채거나 기기를 암호화해 몸값을 요구합니다.

이런 공격이 정교한 것은 아닙니다. 사회공학 기법이 효과적이고, 대부분의 사용자가 임의의 코드를 설치하는 것의 위험 모델을 이해하지 못하기 때문에 통하는 것입니다. 구글의 입장은 사이드로딩을 느리고 번거롭게 만드는 마찰이 가장 효과적인 방어책이라는 것입니다. 사용자가 다시 생각할 시간을 주고, 구글이 APK를 스캔할 시간을 벌어 주기 때문이죠.

개발자들이 불만인 이유

개발자들의 반발은 악성코드에 관한 것이 아닙니다. 통제, 배포, 그리고 Google 생태계 밖의 사용자에게 앱을 전달하는 과정에서 점점 늘어나는 마찰에 관한 것입니다.

테스트와 개발. 개발자들은 개발 중에 계속 사이드로딩을 합니다. 테스트 빌드마다 24시간을 기다리는 건 말도 안 됩니다. 구글은 ADB(Android Debug Bridge)로 설치된 앱을 예외로 두지만, 모든 테스트 워크플로우가 ADB를 쓰는 것은 아닙니다. QA 팀, 베타 테스터, 고객사 데모에서는 APK를 직접 설치하는 경우가 많습니다.
기업 배포. MDM 솔루션으로 관리되는 내부 앱을 Play 스토어 밖에서 배포하는 기업은 추가 마찰을 겪습니다. 엔터프라이즈 MDM은 일부 제한을 우회할 수 있지만, MDM 인프라가 없는 소규모 조직은 영향을 받습니다.
대안 앱 스토어. F-Droid, Amazon Appstore, Samsung Galaxy Store 같은 정당한 배포 채널도 구글 입장에서는 모두 사이드로딩에 해당합니다. 제한이 하나 추가될 때마다 Play 스토어에 비해 이들의 사용자 경험은 나빠지는데, 이는 비판자들이 구글이 원한다고 주장하는 바로 그것입니다.
규제 준수. EU의 디지털 시장법(DMA)은 게이트키퍼(구글 포함)에게 과도한 마찰 없이 사이드로딩을 허용하도록 요구합니다. 사이드로딩을 기술적으로는 가능하게 두면서 실질적으로 더 나쁘게 만드는 것은, DMA가 막으려고 만들어진 바로 그런 형식적 준수(compliance theater)입니다.

권한 모델의 더 깊은 문제

사이드로딩 제한은 더 근본적인 문제를 임시로 덮는 응급처치일 뿐입니다. Android의 권한 모델은 사용자에게 제대로 판단할 능력이 없는 보안 결정을 요구합니다. '이 앱이 연락처에 접근하도록 허용할까요?', '이 앱이 SMS 메시지를 읽도록 허용할까요?', '이 앱이 접근성 서비스를 사용하도록 허용할까요?' 대부분의 사용자는 그 의미를 이해하지 못한 채 전부 수락하거나 전부 거부합니다.

핵심 문제는 권한이 기능에 대한 이분법적 선택으로 제시되는 반면, 사용자는 목적 기준으로 생각한다는 점입니다. 사용자는 앱이 SMS를 읽을 수 있을지 결정하고 싶은 게 아닙니다. 앱이 전화번호 인증을 하는 것(합리적)을 허용할지, 은행의 2단계 인증 코드를 가로채는 것(불합리)을 허용할지 결정하고 싶은 것이죠. 둘 다 같은 권한이 필요합니다.

<!-- AndroidManifest.xml -->
<!-- Both of these use the same permission: -->
<uses-permission android:name="android.permission.READ_SMS" />
<!-- Use case 1: Auto-fill SMS verification code during signup -->
<!-- Perfectly legitimate, saves the user time -->
<!-- Use case 2: Intercept banking 2FA codes and forward to attacker -->
<!-- Malware, obviously -->
<!-- The permission system can't distinguish between these.
The user is asked to make a security decision that requires
understanding the app's implementation, which they can't see. -->

iOS는 (규제 압력으로 제한적인 대안이 생기기 전까지) 사이드로딩 자체를 허용하지 않음으로써 이 문제를 '해결'했습니다. 결정을 사용자에게서 완전히 빼앗는 것은 정당한 접근이지만, 개발자 종속, App Store의 지대 추구, Apple이 승인하지 않은 소프트웨어를 실행할 수 없다는 비용이 따릅니다.

더 나은 시스템은 어떤 모습일까

iOS의 '사이드로딩 불가' 방식도, Android의 '점점 늘어나는 마찰을 가진 사이드로딩' 방식도 이상적이지 않습니다. 더 나은 시스템이라면 여러 가지를 동시에 해결해야 합니다.

위험에 비례한 마찰. 위험한 권한을 요청하지 않고 알려진 개발자가 서명한 앱은 즉시 설치되어야 합니다. 접근성 서비스, SMS 접근, 기기 관리자 권한을 요청하는 앱은 더 엄격한 검토를 받아야 합니다. 현재 시스템은 무해한 오픈소스 계산기와 모든 권한을 요구하는 앱에 똑같은 마찰을 적용합니다.
목적에 묶인 권한. 'SMS 읽기'를 광범위하게 부여하는 대신, '인증 코드 자동 입력을 위한 SMS 읽기'처럼 특정 API 맥락에서만 쓸 수 있는 범위 제한 권한을 부여해야 합니다. Android는 SMS Retriever API로 이 방향으로 움직였지만, 대부분의 권한은 여전히 광범위하게 범위가 잡혀 있습니다.
기다리지 않는 투명한 스캔. 업로드 후 스캔하는 방식은 합리적입니다. 하지만 대부분의 스캔이 몇 분 안에 끝나는 상황에서 24시간 대기는 그렇지 않습니다. 사용자에게 스캔 결과를 보여 주고, 깨끗하면 바로 진행하게 하고, 문제가 발견되면 표시하면 됩니다.
1st-party 스토어와 서드파티 스토어의 동등성. Play 스토어가 앱을 즉시 설치할 수 있다면, 동등한 보안 검사를 구현하는 대안 스토어도 똑같이 할 수 있어야 합니다. 보안 논리가 성립하려면 제한이 안전에 관한 것이어야지 경쟁 우위를 위한 것이어서는 안 됩니다.

지금 개발자가 해야 할 일

구글의 접근 방식을 어떻게 생각하든, 실질적인 현실은 사이드로딩 마찰이 늘어나고 있고 줄어들 가능성은 낮다는 것입니다. Play 스토어 밖에서 앱을 배포한다면 이에 대비하세요.

Play App Signing 프로그램을 사용하세요. 구글의 프로그램으로 서명된 앱은 구글이 알려진 키에 대해 서명을 검증할 수 있으므로, 사이드로딩 검증 과정에서 마찰이 줄어들 수 있습니다.
개발에는 ADB를 사용하세요. ADB로 설치된 앱은 24시간 대기를 우회합니다. CI/CD 파이프라인과 테스트 워크플로우가 APK 직접 설치 대신 ADB를 사용하도록 하세요.
프로그레시브 웹 앱(PWA)을 고려하세요. 깊은 플랫폼 연동이 필요 없는 앱이라면 PWA는 앱 스토어와 사이드로딩 문제를 아예 피해 갑니다. 브라우저에서 설치되고, 자동으로 업데이트되며, 설치에 특별한 권한이 필요하지 않습니다.
대안 스토어를 운영한다면 탄탄한 스캔을 구현하세요. 강력한 보안 관행을 보여 주는 스토어는 결국 예외나 마찰 완화를 받을 수 있습니다. 규제 환경도 그 방향으로 움직이고 있습니다.
사용자에게 지연을 미리 알리세요. 배포가 사이드로딩에 의존한다면, 24시간 대기를 사용자에게 미리 알리세요. 예상된 지연은 갑작스러운 지연보다 덜 짜증스럽습니다.

Android의 개방성은 처음부터 절대적인 것이 아니라 스펙트럼이었습니다. 버전마다 그 스펙트럼은 조금씩 통제 쪽으로 이동해 왔고, 그 근거는 실제 보안 우려였지만 비즈니스 이익과 묘하게 맞아떨어진다는 비판도 받아 왔습니다. 24시간 사이드로딩 지연은 이 궤적의 최신 지점이며, 아마 마지막도 아닐 것입니다. 이를 합리적인 보호로 볼지 인위적인 마찰로 볼지는 보안과 자유 사이의 균형이 어디에 있어야 한다고 보느냐에 크게 달려 있습니다. 하지만 기술적 현실은 분명합니다. Android에서 마찰 없는 사이드로딩의 시대는 끝났고, 개발자는 그에 맞춰 배포 전략을 바꿔야 합니다.