860개 추천, 404개 댓글: 커뮤니티가 불타올랐다
2026년 7월, 구글 이슈트래커(IssueTracker)의 내부 댓글 유출 스크린샷이 공개되었습니다. 구글 ADB 팀의 핵심 유지관리자는 다음과 같이 적었습니다. “localhost 연결 역시 앱이 ADB 소켓을 이용해 권한을 상승시키는 경로임이 확인되었습니다. 차라리 wlan0 무선 네트워크 인터페이스로만 바인딩을 제한하는 것은 어떨까요?”
이 지극히 담담해 보이는 기술적 논의는 해커 뉴스(Hacker News)에서 860개의 추천과 404개의 댓글을 기록하며, 지난 10년간 안드로이드 개발자 커뮤니티에서 가장 격렬한 논쟁을 불러일으켰습니다. 논란의 핵심은 피하기 어려운 하나의 질문입니다. 이것은 진정한 보안 승급인가, 아니면 보안을 핑계로 통제하기 어려운 도구들을 제거하려는 시도인가?
개발자 옵션에 숨겨진 “뒷문”
ADB(Android Debug Bridge, 안드로이드 디버그 브릿지)는 일반 안드로이드 사용자에게는 거의 존재하지 않는 기능입니다. 설정의 “개발자 옵션”에 숨어 있으며, 개발자 옵션 자체도 “빌드 번호”를 연속 7번 터치해야 나타나는 일종의 이스터 에그입니다.
하지만 ADB의 권한은 막강합니다. 모바일 시스템의 관리자급 통로 역할을 하며, 앱 설치 및 삭제, 로그 읽기, 파일 확인, 키 입력 및 터치 동작 시뮬레이션이 가능합니다. 개발자는 앱을 디버깅할 때 사용하고, 고급 사용자는 순정 시스템에서 개방하지 않은 기능을 구현하는 데 활용합니다.
초기 ADB는 USB 케이블로 컴퓨터와 연결해야만 사용할 수 있었습니다. 안드로이드 11에서 무선 디버깅(Wireless Debugging) 기능이 도입되면서 QR 코드 페어링을 통해 Wi-Fi로 연결할 수 있게 되었습니다. 하지만 이 두 가지 방식 모두 스마트폰과 컴퓨터라는 두 대의 기기가 필요했습니다.
그러나 똑똑한 개발자들은 곧 아이디어를 떠올렸습니다. “스마트폰에서 직접 ADB 클라이언트를 실행하고, 127.0.0.1(로컬호스트)을 통해 자기 자신에게 연결하면 되지 않을까?”
이것이 바로 “기기 내 ADB”(On-Device ADB)입니다. 구글이 본래 의도한 사용 방식은 아니었지만, 이는 거대한 오픈소스 도구 생태계를 탄생시켰습니다.
Shizuku: 뜻밖에 형성된 생태계
“기기 내 ADB”를 활용한 대표적인 프로젝트가 바로 Shizuku(시즈쿠)입니다.
Shizuku가 하는 일은 한 문장으로 정리할 수 있습니다. 기기 내 ADB를 통해 시스템급 권한을 획득한 뒤, 다른 앱들이 루팅(root) 없이 이 권한을 호출할 수 있도록 중계합니다.
여전히 추상적으로 들린다면 몇 가지 구체적인 예시가 있습니다.
- Canta: 스마트폰 제조사가 사전 탑재한 삭제 불가능한 앱(제조사 전용 쇼핑몰, 지갑 앱 등)을 루팅 없이 제거할 수 있습니다.
- App Manager: 각 앱이 실제로 어떤 권한을 사용하고 어떤 파일에 접근하는지 상세히 확인할 수 있습니다.
- aShell: 스마트폰에서 터미널 창을 열고 기기 내부에서 직접 ADB 명령어를 실행할 수 있습니다.
- ShizuCallRecorder: 일부 지역에서 통화 녹음 기능이 빠진 스마트폰에 통화 녹음 기능을 구현합니다. 개발자인 Kitsumed 본인도 청각 장애로 인한 일상적 불편을 해소하기 위해 이 앱을 개발해 사용하고 있습니다.
안드로이드 오픈소스 프로젝트 개발자인 Rikka가 2019년 Shizuku를 처음 공개했을 때만 해도, 이 프로젝트가 이러한 “핵심 인프라”로 성장할 줄은 몰랐을 것입니다. 현재 구글 플레이(Google Play)를 통한 Shizuku 설치 기기만 100만 대가 넘지만, F-Droid나 GitHub에서 직접 설치하는 수많은 사용자를 고려하면 실제 사용자 수는 이를 훨씬 웃돕니다.
공격 경로: 여러 조건이 겹쳐야 가능
구글 ADB 유지관리자의 우려는 악성 앱이 기기 내 ADB의 127.0.0.1 연결을 악용하여 자신의 권한을 상승시키고, 안드로이드의 샌드박스 격리 메커니즘을 우회할 수 있다는 점입니다.
그렇다면 악성 앱이 이 방식을 성공적으로 악용하려면 몇 단계가 필요할까요?
Kitsumed의 원문 분석과 해커 뉴스 댓글 논의를 종합한 실제 공격 시나리오는 다음과 같습니다.
- 사용자가 “설정 → 휴대전화 정보”로 이동하여 “빌드 번호”를 7번 터치해 개발자 옵션을 켜야 함
- 사용자가 개발자 옵션에 직접 들어가 “USB 디버깅”을 활성화하여 ADB 데몬을 실행해야 함
- 사용자가 추가로 “무선 디버깅”을 켜거나(안드로이드 11 이상), USB로 PC에 연결해 TCP/IP 모드를 활성화해야 함
- 악성 앱이 연결을 시도할 때 화면에 팝업창이 뜨며, 사용자가 “허용”을 직접 눌러야 함
- 무선 디버깅 페어링 모드를 사용할 경우 사용자가 6자리 페어링 코드를 직접 입력해야 함
해커 뉴스 사용자 microtonal의 댓글이 가장 많은 공감을 받았습니다. “이 공격 경로는 개발자 설정과 원격 ADB가 모두 활성화되어 있어야 합니다. 99.9%의 사용자에게 이는 현실적인 공격 경로가 아닙니다. 나머지 0.1%는 자신이 무엇을 하고 있는지 잘 알고 있습니다.”
또 다른 사용자 crote는 더욱 직설적으로 지적했습니다. “일반 사용자에게 영향을 미치는 것은 사실상 불가능하며, 주의 없는 개발자만 걸려들 수 있습니다. 게다가 이는 구글 플레이 자체의 악성코드 검사가 완전히 실패했다는 전제하의 이야기입니다. 잠시만요, 사이드로딩을 제한하려 할 때 내세운 이유가 플레이 스캔 성능이 뛰어나다는 것 아니었나요?”
엔지니어링 관점에서 볼 때 CVE-2026-0073은 무선 디버깅 인증을 우회할 수 있는 실제 보안 취약점이었습니다. 하지만 이 취약점은 이미 수정이 완료되었습니다. 현재 논의 중인 제안은 취약점이 이미 해결된 이후에 기기 내 ADB 기능 자체를 아예 막아버리자는 것입니다.
악역은 누구인가?
여기서 일련의 패턴 재현을 떠올리지 않기는 어렵습니다.
지난 몇 년간 구글의 제품 결정들을 돌아보겠습니다. 크롬(Chrome)은 매니페스트 V3(Manifest V3)를 도입하며 보안을 이유로 광고 차단 확장 프로그램을 무력화했고, 안드로이드에서는 보안을 이유로 플레이 스토어 외 외부 앱 설치(사이드로딩) 권한을 축소했습니다. 매번 “보안”이 명분으로 사용되었고, 그 결과는 항상 동일했습니다. 사용자가 자신의 기기를 통제할 수 있는 범위를 줄이는 것이었습니다.
해커 뉴스 사용자 transcriptase의 한마디는 뼈를 때립니다. “광고 회사가 존재하지도 않는 보안 문제를 구실로 전 세계 80% 사용자의 광고 및 콘텐츠 차단 능력을 사실상 무력화했다는 사실이 지금도 믿기지 않습니다.”
이번 ADB 제한의 흐름도 완전히 동일합니다. 이슈트래커에는 개발자가 ADB 데몬이 수신 대기할 네트워크 인터페이스를 선택할 수 있도록 해달라는 실제 기능 요청이 있었습니다(현재는 모든 인터페이스를 수신 대기함). 이는 합리적인 개선 요청이었습니다. 하지만 ADB 유지관리자는 댓글에서 논점을 바꾸어 인터페이스 선택 제한을 **“로컬호스트 회귀 연결 완전 금지”**로 바꿔버렸습니다. 그리고 후자는 기기 내 ADB가 존재할 수 있는 근간입니다.
이 생태계 전체에서 악의적인 “악당”은 존재하지 않습니다. 진정으로 대립하는 것은 플랫폼 소유자(구글)와 실제 기기 소유자(소비자 및 개발자) 간의 권력 경계입니다. 구글은 안드로이드 생태계의 폐쇄성과 통제 가능성을 유지하려 하고, 사용자 및 개발자는 자신의 기기에 대한 실질적인 통제권을 원합니다.
희생되는 생태계
만약 이 제안이 실제로 적용된다면 정확히 무엇이 사라지게 될까요?
- Shizuku의 모든 기능: 사전 탑재 앱 삭제부터 앱 백그라운드 백그라운드 실행 차단까지 모두 마비됩니다.
- Canta, App Manager, aShell 등 Shizuku에 의존하는 수십 개의 도구들.
- libadb-android와 같은 하위 레이어의 기초 라이브러리.
- Termux 내부에서 ADB를 활용하는 모든 개발 워크플로.
Kitsumed는 블로그 원문에서 개발자들에게 저품질 댓글을 도배하기보다는 이슈트래커에 건설적인 의견을 남겨줄 것을 당부했습니다. 이러한 절제된 태도는 오히려 씁쓸한 자조처럼 느껴집니다. “이것을 막기 어렵다는 것은 알지만, 적어도 우리가 어리석어 보이지는 맙시다.”
현재 이슈트래커의 동향을 보면 해당 과제가 이미 ADB 팀의 주력 엔지니어에게 할당되어 절차가 진행 중입니다.
보안은 결코 기술만의 문제가 아니다
기기 내 ADB 차단은 한편으로는 공격 대상을 줄이는 합리적인 보안 강화 조치로 볼 수 있습니다. 하지만 다른 편에서는 “기기 소유자를 기본적으로 신뢰하지 않는다”는 신호이기도 합니다. 스마트폰을 구매했더라도 그 기기에서 어떤 코드를 실행할지 결정할 권리가 사용자에게 온전히 있는 것은 아니라는 뜻입니다.
논의 과정에서 해커 뉴스 사용자 JoshTriplett은 타협안을 제시했습니다. **“로컬호스트 연결을 기본적으로 금지하되, 재부팅 후에도 유지되며 제3자 앱이 상태를 읽을 수 없는 영구적인 설정 스위치를 제공하는 방식”**입니다. 이렇게 하면 일반 사용자의 보안을 지키면서도 고급 사용자에게 길을 열어줄 수 있습니다. 엔지니어링 측면에서도 구현하기 어려운 디자인이 아닙니다.
그러나 이 제안이 논란이 되는 이유는 바로 타협안을 선택하지 않았기 때문입니다.
2026년의 안드로이드는 힘겨운 균형을 잡고 있습니다. 한쪽에서는 유럽연합(EU)의 디지털 시장법(DMA)으로 인해 사이드로딩과 제3자 앱 스토어 개방을 강제받고 있고, 다른 한쪽에서는 구글 내부적으로 기기 하단에 대한 통제를 지속적으로 강화하고 있습니다. 기기 내 ADB 제한은 이 팽팽한 줄다리기 속에서 일반인들은 인지하지도 못한 채 쓰러지는 또 하나의 도미노일지도 모릅니다.
그림: Shizuku 무선 디버깅 설정 화면. 출처: shizuku.rikka.app
그림: Shizuku 정상 실행 화면. 출처: shizuku.rikka.app
그림: 무선 디버깅 6자리 페어링 코드 입력 화면. 출처: shizuku.rikka.app
참고 출처
- Android May Soon Restrict On-Device ADB, Affecting Shizuku, libadb and Developers — Kitsumed Blog
- Hacker News Discussion (item?id=49045159)
- Shizuku User Manual — Rikka Apps
- Google IssueTracker — ADB Feature Request
- Android Developers — ADB 공식 문서
