Android 로컬 네트워크 권한: Google Play의 새 정책과 picker 우선 설계

전체 네트워크 대신 사용자가 고른 기기에 연결하는 방식을 표현한 생성형 개념 이미지다. 실제 Android 화면이 아니다.

Android 앱이 같은 Wi-Fi의 기기에 연결하려면 권한 하나만 추가하면 될까. 이제는 “권한이 필요한가”보다 “사용자가 고른 기기만으로 기능을 제공할 수 있는가”를 먼저 검토해야 한다. Google Play가 2026년 10월 29일 발표한 로컬 네트워크 권한 정책은 이 판단을 배포 심사의 설명 대상으로 만든다.

이 글은 공개 정책과 Android 공식 문서를 바탕으로 한 준비 가이드다. 실제 앱을 수정하거나 기기에서 실행한 결과는 아니다.

새로 발표된 것은 OS 기능이 아니라 Play의 사용 요건이다

Android 17의 로컬 네트워크 보호 자체를 이번 발표의 신기능으로 소개하면 안 된다. 이번 변화는 ACCESS_LOCAL_NETWORK를 어떤 앱이 요청할 수 있는지에 대한 Google Play 정책이다. API 37 이상을 대상으로 하는 앱은 핵심 기능에 필요하고 기기 선택기로 충족할 수 없을 때 이 권한을 요청할 수 있다. 요청 이유와 선택기가 부족한 이유를 Play Console에 설명해야 한다. 10월 29일 공식 정책 발표

일정은 다음처럼 분리해서 읽는다.

• 2026년 10월 29일: 정책 발표.

• 2027년 6월: 해당 권한을 포함한 앱에 Play Console 신고서 제출 안내 예정.

• 2027년 8월 25일: Android 17 이상을 대상으로 하는 적용 대상 앱의 정책 준수 의무화.

공식 도움말에는 Console에서 30일 자동 연장을 제공한다고 적혀 있다. 연장을 기본 개발 일정으로 잡거나, 발표 직후 모든 앱이 중단되는 것처럼 해석하지 않는 편이 좋다. 정책 일정과 신고 안내

OS에서 연결되는 조건과 배포 가능한 조건은 다르다

Android 17에서는 target SDK 37 이상 앱의 로컬 네트워크 접근이 기본적으로 제한된다. 광범위한 접근에는 새 런타임 권한을 사용하고, 시스템이 중개하는 선택 경로는 별도로 검토한다. 이 동작 조건은 앞서 본 2027년 Play 정책 시행일과 같은 것이 아니다.

공식 가이드는 target SDK 36 이하에서는 기존 INTERNET 권한으로 로컬 네트워크 접근이 가능하며, 이 경우 새 권한을 미리 추가하거나 요청하지 말라고 설명한다. 단순히 코드에 권한 요청을 넣기 전에 기기 OS, target SDK, 실제 접근 방식을 함께 확인해야 한다. Android 로컬 네트워크 권한 가이드

또한 앱 코드에서 직접 소켓을 만들지 않았다고 영향이 없는 것은 아니다. 로컬 주소에 접근하는 라이브러리나 호스트 앱의 WebView도 점검 대상이 될 수 있다. 같은 문서는 제한이 네트워크 스택에서 적용된다고 설명한다.

한 기기를 고르는 기능이라면 picker부터 검토한다

NsdManager는 mDNS 기반 서비스 탐색에 시스템 선택기를 사용할 수 있다. 핵심은 DiscoveryRequest.FLAG_SHOW_PICKER다.

아래는 선택기 요청 객체를 만드는 문서 기반의 짧은 예시다. 전체 연결 코드가 아니며, 컴파일·실행은 확인하지 않았다.

_http._tcp는 예시 서비스 유형이다. 실제 기기가 광고하는 서비스 유형에 맞춰야 한다. 이후 지원되는 NsdManager 탐색 또는 서비스 콜백 API에 요청을 전달하고, 선택 결과·취소·실패 처리를 연결한다.

사용자가 고른 서비스에 대해서는 반환된 네트워크와 호스트 주소를 이용하는 접근이 허용된다. 이를 LAN 전체에 대한 허가로 해석하면 안 된다. 공식 API 문서는 재연결이나 주소 변경 시 콜백으로 최신 주소를 얻고, IP 주소를 고정 저장하지 않도록 안내한다. API가 SDK Extensions로 제공될 수 있으므로 메서드의 지원 범위도 확인해야 한다. NsdManager 공식 API 문서

“우리 앱은 IoT 앱이니까 예외”라는 판단도 충분하지 않다. 한 대를 선택해 제어하는 기능과 여러 기기를 지속적으로 관리하는 기능은 필요한 접근 범위가 다르다. 핵심 기능과 picker의 기술적 한계를 구체적으로 설명하는 것이 중요하다.

구현 전에 남길 작은 설계 기록

다음은 공식 양식이 아니라 이 글에서 제안하는 검토 틀이다.

예를 들어 “기기 연결”보다 “사용자가 선택한 프린터로 문서를 전송한다”가 검토에 유리하다. 반대로 자동 검색이 편하다는 이유만으로 모든 기기의 지속적 탐색이 핵심 기능이라고 단정해서는 안 된다.

신고 문구를 먼저 꾸미기보다 제품 요구사항, 실제 네트워크 호출, 선택기 가능 여부가 일치하는지 확인한다. 공개 정책의 예시 목록에 들어간다는 사실만으로 심사 통과를 보장하지 않는다.

검증은 성공 경로보다 권한이 없는 상태에서 시작한다

다음은 권장 테스트 항목이며 이 글에서 실행한 결과가 아니다.

1. 새 설치와 기존 설치의 권한 상태를 각각 기록한다.

2. 사용자가 기기를 선택했을 때 선택한 대상에만 의도한 연결을 시도하는지 확인한다.

3. 선택을 취소하거나 권한을 거부했을 때 무한 재시도·빈 화면·잘못된 성공 표시가 없는지 확인한다.

4. 앱 설정에서 권한을 철회한 뒤 재진입해 안내와 대체 경로를 점검한다.

5. Wi-Fi 재연결과 기기 주소 변경 후 이전 IP에 매달리지 않는지 확인한다.

6. 앱 코드뿐 아니라 연결 SDK와 WebView가 시작하는 요청도 함께 추적한다.

성공 기준은 권한 창을 띄웠다는 사실이 아니다. 필요한 기기에 연결되고, 허용되지 않은 상태도 사용자에게 정확히 설명하며, 배포 정책에서 그 접근 범위를 정당화할 수 있는 상태다.

2026년 10월 30일 확인한 공개 문서 기준이다. 정책 일정과 API 지원 범위는 실제 배포 전에 원문에서 다시 확인해야 한다.