안드로이드 무선 디버깅을 안전하게 쓰는 법, ADB 연결·페어링·해제 순서
AI를 활용하여 생성한 이미지입니다.
무선 디버깅은 케이블을 치우는 기능이 아니라, PC를 휴대전화의 개발 도구로 계속 신뢰하게 만드는 설정입니다. 앱 설치와 로그 수집이 끝난 뒤에도 페어링된 컴퓨터가 남아 있으면 편의성과 보안 부담이 함께 남습니다. Android 11 이상은 개발자 옵션의 무선 디버깅 화면에서 페어링 코드 또는 QR 코드를 사용하며, PC와 휴대전화가 같은 Wi-Fi에 있어야 합니다.[1][2] 따라서 연결 자체보다 어느 기기를 대상으로 명령을 보내는지와 작업 후 신뢰 관계를 지우는지가 더 중요합니다.
이 글은 이미 adb를 사용할 수 있다는 전제로, USB 기준 상태 만들기, 무선 페어링, 여러 기기 구분, 끊김 진단, 해제까지의 순서를 정리합니다. 개발자 옵션 메뉴 이름은 제조사와 Android 버전에 따라 달라질 수 있으므로 실제 화면의 명칭을 우선하세요.
USB 디버깅과 무선 디버깅을 구분하세요
USB 디버깅은 케이블로 연결한 PC와 휴대전화 사이의 ADB 통신을 허용하는 설정입니다. 무선 디버깅은 그 통신을 Wi-Fi로 옮긴 것이지만, Android 11 이상에서는 예전처럼 포트 하나만 열고 시작하는 흐름이 아닙니다. 무선 디버깅 화면에서 PC를 페어링 목록에 추가한 뒤, 실제 ADB 연결을 별도로 수행합니다.[2]
두 단계가 나뉘어 있으므로 adb pair가 성공했는데도 adb devices에 기기가 나타나지 않을 수 있습니다. 페어링용 포트와 ADB 연결용 포트를 혼동하지 말고, 화면에 표시된 값을 각각 사용하세요.
연결 전 기준 상태를 확인하는 순서
- Android SDK
platform-tools의adb가 실행되는지 확인합니다. - 휴대전화의 개발자 옵션에서 USB 디버깅을 켭니다. 메뉴가 없다면 설정의 빌드 번호를 여러 번 탭해 활성화하는 방식이 일반적이지만, 정확한 위치는 제조사 문서를 확인하세요.[3]
- USB로 연결한 뒤 휴대전화 잠금을 풀고 RSA 승인 대화상자를 읽습니다. 개인 PC가 아니라면 “항상 허용”을 무심코 선택하지 않는 편이 안전합니다.[1]
- PC에서 다음 명령으로 장치 목록과 설명을 기록합니다.
adb kill-server
adb start-server
adb devices -l
상태가 device여야 명령을 보낼 수 있습니다. unauthorized라면 휴대전화의 승인 대기 상태를 확인하고, offline이면 화면 잠금·케이블·ADB 서버를 차례로 점검하세요. Windows는 제조사에 따라 OEM USB 드라이버가 필요할 수 있고, macOS는 별도 USB 드라이버가 필요하지 않은 경우가 많지만 기기별 예외는 제조사 안내를 따르는 것이 좋습니다.[1]
Android 11 이상에서 무선 페어링하기
- PC와 휴대전화를 같은 일반 Wi-Fi에 연결합니다. 게스트망이나 무선 클라이언트 격리가 켜진 네트워크는 기기 간 통신을 막을 수 있습니다.
- 휴대전화에서 개발자 옵션 > 무선 디버깅을 열고 기능을 켭니다.
- 페어링 코드로 기기 페어링을 선택해 IP 주소, 페어링 포트, 코드를 확인합니다.[2]
- PC에서 표시된 페어링 주소를 입력하고, 휴대전화의 코드를 입력합니다.
adb pair <device-ip>:<pairing-port>
adb connect <device-ip>:<adb-port>
adb devices -l
페어링 코드가 노출된 화면을 캡처하거나 다른 사람에게 전달하지 마세요. 같은 네트워크에서 디버깅을 켜 둔 채로 작업하는 것도 피하는 편이 좋습니다. 연결이 성공하면 시리얼이 <device-ip>:<adb-port> 형태로 보일 수 있습니다.
여러 기기에서 대상을 고정하는 법
에뮬레이터, USB 기기, 무선 기기가 동시에 연결되면 adb: more than one device/emulator가 발생합니다. 기본 대상을 추측하지 말고 목록에서 시리얼을 복사해 모든 명령에 -s를 붙이세요.
adb devices -l
adb -s <serial> shell getprop ro.product.model
adb -s <serial> logcat -d -t 100
앱 설치·삭제나 데이터 변경은 실행 직전에 모델명만이 아니라 시리얼, 연결 방식, 실제 화면의 기기를 함께 확인하세요. 같은 모델의 휴대전화가 두 대라면 각 기기의 무선 IP와 시리얼을 작업 기록에 남기는 것이 안전합니다.[2]
상태별 진단표
| 표시 | 가능한 원인 | 먼저 할 일 |
|---|---|---|
| 목록에 없음 | 페어링 또는 연결 미완료 | 무선 디버깅 화면의 두 포트와 adb connect를 다시 확인 |
unauthorized |
RSA 승인 대기 | 잠금을 풀고 승인 창 확인 |
offline |
네트워크 변경·끊긴 세션 | 같은 Wi-Fi인지 확인한 뒤 disconnect와 재연결 |
| 곧바로 끊김 | 게스트망·클라이언트 격리·절전 | 기기 간 통신 가능한 네트워크에서 재시도 |
재시작은 다음처럼 할 수 있지만, 이것이 휴대전화의 페어링 목록을 자동으로 지우는 것은 아닙니다.
adb disconnect
adb kill-server
adb start-server
adb connect <device-ip>:<adb-port>
adb devices -l
계속 실패하면 휴대전화의 무선 디버깅 화면에서 해당 워크스테이션을 Forget 처리한 후 처음부터 페어링합니다.
작업이 끝난 뒤 반드시 해제하세요
일회성 PC라면 무선 디버깅을 끄고, 페어링 목록에서 PC 이름을 눌러 Forget을 선택하세요. 여러 PC의 승인 관계를 한 번에 철회해야 한다면 개발자 옵션의 Revoke adb debugging authorizations를 사용할 수 있습니다.[2] 다음 작업에서 다시 RSA 승인이나 페어링이 필요할 수 있으므로, 반복 업무용 컴퓨터와 공용 컴퓨터를 같은 방식으로 남겨 두지 않는 것이 좋습니다.
한동안 개발 기능을 사용하지 않는다면 개발자 옵션 상단 스위치까지 끄는 것도 선택지입니다. 개발자 옵션이 꺼져도 사진·파일 전송 같은 일반 USB 사용과는 별개의 설정이므로, 필요한 기능만 다시 켜세요.
네트워크와 권한의 예외 상황
같은 Wi-Fi라는 조건만으로 항상 연결되는 것은 아닙니다. 회사·학교 네트워크는 무선 기기끼리 직접 통신하지 못하도록 클라이언트 격리를 적용할 수 있고, VPN이나 보안 소프트웨어가 로컬 주소 연결을 막을 수도 있습니다. 이런 경우 포트를 무작정 열기보다 신뢰할 수 있는 개발용 네트워크에서 다시 확인하세요. 외부 네트워크에 ADB를 노출하는 방식은 작업 편의보다 위험이 커질 수 있습니다.
또한 무선 디버깅을 켜는 일과 특정 앱에 필요한 권한을 부여하는 일은 별개입니다. ADB 연결이 된다고 해서 모든 앱 데이터에 접근할 수 있다는 뜻으로 확대하지 말고, 실제로 실행할 명령만 사용하세요. 테스트용 휴대전화와 개인 휴대전화를 구분하면 잘못된 설치·삭제를 줄일 수 있습니다.
자주 묻는 질문
Android 10 이하도 같은 명령을 쓰나요?
Android 11 이상에서 안내되는 무선 페어링 흐름과 다릅니다. 공식 문서는 USB 연결 후 adb tcpip 5555와 adb connect를 사용하는 별도 절차를 설명하므로, 기기와 플랫폼 도구 버전에 맞춰 확인하세요.[2]
device면 명령 대상을 확인하지 않아도 되나요?
아닙니다. device는 연결 상태를 뜻할 뿐, 사람이 의도한 휴대전화라는 뜻은 아닙니다. 여러 기기에서는 -s를 사용하고, 파괴적인 명령은 실행 전 화면과 시리얼을 다시 확인하세요.
관련 보안 설정도 같이 보고 싶다면?
ADB를 잠깐 쓰는 작업이라도 계정과 개발 기능의 신뢰 관계를 함께 관리해야 합니다. 다른 기기 보안 설정을 점검할 때는 아이폰·안드로이드 패스키 설정 글도 참고할 수 있습니다.
마무리 체크리스트
adb devices -l로 대상 시리얼을 확인했나요?- 페어링 포트와 연결 포트를 따로 입력했나요?
- 공용·게스트 Wi-Fi에서 무선 디버깅을 켜 두지 않았나요?
- 여러 기기에서는 모든 명령에
-s를 넣었나요? - 작업 후 무선 디버깅을 끄고 일회성 PC를 Forget 처리했나요?
[…] 글에서 다룬 ADB 무선 디버깅의 페어링과 해제 절차는 Android 무선 디버깅 점검 글에서 이어서 확인할 수 있어요. App Links 문제는 네트워크 연결 자체보다 […]