안드로이드, 온디바이스 ADB 제한 검토… Shizuku 생태계 흔들리나

안드로이드에서 컴퓨터 없이 휴대폰 자체적으로 ADB(Android Debug Bridge)를 활용하던 방식이 앞으로 막힐 수 있다는 우려가 제기됐다. 다만 이는 구글의 공식 발표가 아니라, 구글 이슈트래커에 올라온 진행 중인 기능 요청과 그 스레드에 달린 ADB 핵심 관리자(구글 직원)의 코멘트에서 비롯된 관측이라는 점을 먼저 분명히 해둘 필요가 있다. 이 내용을 정리한 사람은 Shizuku 기반 통화 녹음 앱 ShizuCallRecorder를 만든 개발자 Kitsumed로, 그 자신이 이번 변경의 직접적인 영향권에 있다.

온디바이스 ADB란 무엇인가

ADB는 구글이 만든 개발자용 프로토콜로, 안드로이드 기기에서 민감한 명령을 실행하고 앱과 시스템 동작을 점검할 수 있는 높은 권한을 부여한다. 원래는 USB 연결을 전제로 설계됐다. 디버깅 대상인 안드로이드 기기가 ADB 데몬(ADBD)을 실행하고, 별도의 개발용 PC가 ADB 클라이언트를 실행하는 두 기기 구조다. 그러나 두 번째 기기가 없는 상황이 흔하다 보니, Termux 같은 터미널 에뮬레이터로 휴대폰 안에서 직접 ADB 클라이언트를 띄워 로컬 데몬에 접속하는 방식이 자리 잡았다. 클라이언트와 서버가 같은 기기 안에 있으므로 연결은 루프백 주소(127.0.0.1)를 통해 이뤄진다. 저자는 이를 공식 용어가 아닌 '온디바이스 ADB'라 부른다.

이 다소 틈새적인 사용 방식이 MuntashirAkon의 libadb-android, RikkaApps의 Shizuku 같은 프로젝트를 낳았고, 나아가 App Manager, Canta, aShell, ShizuWall 등 루팅 없이도 시스템 수준 작업을 가능하게 하는 오픈소스 도구 생태계로 확장됐다. 개발자뿐 아니라 파워 유저, 그리고 프라이버시를 지키려는 사용자들이 이 방식에 의존하고 있다.

보안 이슈에서 시작된 논의

문제의 기능 요청 자체는 합리적인 취지에서 출발했다. 현재 ADBD는 휴대폰이 연결된 모든 네트워크에 자신을 노출하는데, 이 요청은 개발자가 ADBD가 어떤 인터페이스에서 대기할지 선택하게 해 노출 범위를 줄이자는 것이다. 배경에는 무선 ADB의 인증 절차를 완전히 우회할 수 있었던 보안 취약점 CVE-2026-0073이 있었다.

논란은 이 요청에 달린 ADB 핵심 관리자의 답변에서 불거졌다. 그는 로컬호스트 연결이 앱이 adbd 소켓을 통해 권한을 상승시키는 익스플로잇의 통로가 돼 왔다고 지적하며, 항상 와이파이 인터페이스인 wlan0에만 바인딩하도록 제한하는 방안을 언급했다. 그렇게 되면 온디바이스 ADB는 물론 VPN이나 이더넷을 통한 ADB, 그 밖의 여러 개발 환경이 함께 깨진다.

실무적 쟁점과 저자의 대안

저자가 지적하는 핵심은 온디바이스 ADB를 '악용 통로'로만 보는 관점의 편향이다. 악성 앱이 온디바이스 ADB로 권한을 상승시킬 수는 있어도, 연결 자체를 스스로 만들 수는 없다. ADBD를 앱이 임의로 실행할 수 없기 때문이다. CVE-2026-0073 같은 상황에서도 실제 악용은 사용자가 수동으로 USB 디버깅을 켠 뒤에야 가능하고, TCP/IP 연결까지 개발자가 손수 활성화해야 하는 시나리오도 있다.

따라서 저자는 '기본값으로 차단하는 것'과 '영구히 차단하는 것'은 다르다고 본다. 그는 재부팅 후에도 유지되고(그렇지 않으면 Shizuku 같은 도구가 무용지물이 된다) 이상적으로는 서드파티 앱이 그 상태를 읽지 못하는 영구 토글을 제안한다. 상태가 노출되면 은행 앱이나 게임이 온디바이스 ADB 활성화를 탐지해 개발자가 매번 이를 꺼야 하는 상황이 벌어진다. 다만 이 부분은 앱이 WRITE_SECURE_SETTINGS 권한을 부여받으면 우회될 여지가 있다는 점도 그는 인정한다.

그의 비유는 설득력이 있다. 사람이 마음먹으면 악성 앱을 기기 관리자로 지정하거나 접근성 권한을 내줄 수도 있지만, 그렇다고 해서 그 기능들 자체를 없애지는 않는다. 정당한 실사용이 존재하는 이상, 보안 기능을 사용자가 스스로 끄고 그에 따른 위험을 감수하도록 두는 편이 기능 대 위험의 균형에 맞는다는 것이다.

국내 실무자에게 이 논의가 시사하는 바는 분명하다. 루팅 없이 시스템 권한을 다루는 국내외 도구 상당수가 온디바이스 ADB와 Shizuku에 기대고 있고, 통화 녹음처럼 접근성 목적의 활용도 여기에 포함된다. 아직 확정된 사안이 아닌 만큼, 관련 도구에 의존하는 개발자라면 이슈 진행 상황을 주시하고 필요하면 이슈트래커에 근거 있는 피드백을 남기는 편이 좋다. 저자 역시 단순 불만이나 비난성 댓글은 오히려 논의를 닫히게 만들 수 있다며 신중한 참여를 당부한다.