앱 MVP Android 로컬 네트워크: Picker·권한·차단 검수를 나누는 5가지 기준
Android MVP에서 TV, 프린터, 센서, 사내 장비처럼 같은 LAN의 기기를 찾거나 연결하려면 “인터넷이 되니 기존 코드도 계속 된다”라고 가정하면 위험합니다. Android 17(API 37) 이상을 타깃하는 앱은 로컬 네트워크 접근이 기본 차단될 수 있으므로, 기능이 실제로 LAN 접근을 쓰는지와 사용자에게 넓은 권한을 요청할 이유가 있는지를 먼저 나눠야 합니다.
핵심 답은 간단합니다. 사용자가 한 대의 기기나 출력 대상을 고르는 기능이라면 시스템이 중개하는 picker가 가능한지 먼저 확인하고, 직접 탐색·지속 연결이 핵심인 기능만 런타임 권한 경로로 설계하세요. 이후에는 “권한 창이 떴다”가 아니라 선택·거부·철회·재시작 뒤 결과까지 실제 기기에서 기록해야 합니다.
1. 먼저 ‘인터넷 통신’과 ‘로컬 네트워크 접근’을 분리합니다
웹 API 호출, 원격 서버 동기화, 일반 모바일 데이터 통신은 곧바로 같은 범주의 로컬 네트워크 접근이 아닙니다. 이 글에서 다루는 것은 같은 LAN 안의 주소·서비스를 찾거나, 그 기기와 직접 통신하는 흐름입니다. Android 문서는 로컬 주소에 대한 TCP 연결, UDP 단일·멀티캐스트·브로드캐스트, `.local` 서비스 해석 같은 경우가 영향을 받을 수 있다고 설명합니다.
따라서 요구사항 문서에는 “기기 연동” 한 줄만 남기지 말고 아래처럼 범위를 적습니다.
구분 | 팀이 확인할 질문 | 출시 전 남길 증거 |
|---|---|---|
기능 목적 | 사용자는 기기를 선택하는가, 앱이 네트워크 전체를 탐색하는가 | 핵심 사용자 흐름과 연결 대상 |
통신 경로 | 서버 경유인가, 같은 LAN으로 직접 연결하는가 | SDK·라이브러리·프로토콜 목록 |
대상 SDK | 이번 빌드가 Android 17(API 37) 이상을 타깃하는가 | 빌드 설정과 테스트 빌드 식별값 |
실패 처리 | 권한이 없거나 철회되면 어떤 화면·대안을 제공하는가 | 거부·철회 시나리오 결과 |
이 표는 권한을 반드시 요청하라는 체크리스트가 아닙니다. 오히려 불필요한 광범위 접근을 기능 요구와 혼동하지 않기 위한 분리 장치입니다.
2. 한 대를 고르는 기능은 picker 경로부터 검토합니다
Android 문서는 시스템이 중개하는 선택기를 privacy-preserving path로 제시합니다. 예를 들어 미디어 전송에는 Output Switcher, mDNS 기반 서비스 발견에는 `NsdManager`의 서비스 picker가 대안이 될 수 있습니다. 사용자가 한 대를 선택하면 앱이 네트워크 전체를 스캔하지 않고도 필요한 연결 정보를 받을 수 있는 경우가 있습니다.
여기서 MVP의 의사결정은 “picker가 더 좋아 보이는가”가 아니라 다음 질문으로 끝내는 편이 좋습니다.
사용자가 선택해야 하는 대상이 한 대 또는 제한된 목록인가?
기능이 백그라운드에서 계속 LAN을 탐색해야 하는가?
현재 사용하는 SDK가 시스템 picker 경로를 지원하는가?
picker 취소 뒤에도 핵심 흐름이 이해 가능한가?
선택한 장치에 연결된 뒤 성공·실패를 사용자가 구분할 수 있는가?
모두가 picker에 맞는다는 뜻은 아닙니다. 다만 “기기 검색”이라는 표현만으로 광범위한 권한을 먼저 설계하는 일을 막습니다. 사용자 선택으로 충분한 기능과 지속적 제어가 필요한 기능은 다른 요구사항입니다.
MVP 기능 범위와 출시 전 검수 항목을 함께 점검하기
3. 직접 LAN 통신이 핵심이라면 권한을 기능 시작 시점에 연결합니다
홈 자동화처럼 여러 기기를 지속적으로 관리하거나 직접 로컬 통신이 핵심인 기능은 넓은 접근이 필요할 수 있습니다. Android 17(API 37) 이상을 타깃할 때는 `ACCESS_LOCAL_NETWORK`를 manifest에 선언하고, 실제 LAN 접근을 시도하기 전에 승인 상태를 확인한 뒤 필요한 시점에 런타임 요청을 하는 경로를 문서가 안내합니다.
중요한 경계가 있습니다. Android 문서는 SDK 36 이하에서는 `INTERNET` 권한으로 로컬 접근이 암묵적으로 허용되는 상태를 설명하며, 이 경우에 새 권한을 미리 선언하거나 런타임 요청하지 말라고 안내합니다. 즉, 코드에 권한 분기를 넣더라도 앱이 무엇을 타깃하는지 확인하지 않은 채 Android 17용 흐름을 모든 빌드에 복사하면 안 됩니다.
권한 설명 문구에는 “더 나은 경험을 위해”처럼 추상적인 표현보다 사용자가 시작한 행동과 필요한 범위를 연결합니다. 예를 들어 “선택한 사내 장비에 연결해 상태를 표시하려면 주변 기기 접근이 필요합니다”처럼 기능·시점·대안을 함께 보여 줍니다. 이는 선택 결과나 연결 성공을 보장하는 문구가 아니라 요청 이유를 이해시키기 위한 안내입니다.
4. 거부·철회·차단은 별도의 완료 상태로 기록합니다
권한 요청이 표시된 것과 기능이 작동한 것은 다릅니다. Android 문서는 사용자가 권한을 거부하거나 설정에서 철회하는 상황을 우아하게 처리해야 하며, 이때 로컬 네트워크 트래픽이 차단된다고 설명합니다.
그래서 QA 표에는 성공만 두지 말고 아래 상태를 나눕니다.
상태 | 확인할 것 | 완료 기준의 예 |
|---|---|---|
picker 취소 | 취소가 오류로 보이지 않는가 | 원래 화면으로 돌아가고 재시도 경로가 보임 |
권한 거부 | 핵심 기능 외의 화면도 막히지 않는가 | 이유 안내와 대체 행동이 제공됨 |
권한 철회 | 설정 변경 뒤 앱이 오래된 성공 상태를 보이지 않는가 | 다음 LAN 접근에서 상태를 다시 확인함 |
LAN 차단 | 시간 초과·연결 실패가 분석 가능한가 | 사용자 메시지와 기술 로그의 범주가 분리됨 |
연결 성공 | 실제 대상과 연결됐는가 | 선택 대상·연결 결과·다음 행동이 일치함 |
위의 ‘완료 기준’은 제품별로 달라질 수 있는 예시입니다. 실제 장비 지원, 연결 범위, 재시도 횟수, 데이터 전송량은 이 문서만으로 정할 수 없습니다.
5. target SDK 전환은 실제 기기 검수와 함께 묶습니다
Android 16에서는 로컬 네트워크 보호를 opt-in으로 시험할 수 있었고, Android 17에서 SDK 37 이상 앱에 의무 적용된다고 Android 문서가 설명합니다. 따라서 target SDK를 올리는 작업을 단순 빌드 통과로 닫지 말고, LAN 연결 기능을 가진 실제 빌드에서 picker 경로와 권한 경로를 모두 검증해야 합니다.
검수 기록에는 최소한 빌드 버전, 테스트 기기·OS, target SDK, 사용한 연결 경로, 권한 상태, 사용자 선택 또는 거부, 실제 연결 결과, 재현 조건을 남깁니다. `WebView` 안에서 로컬 네트워크에 접근하는 경우 호스트 앱의 권한 상태를 상속한다는 Android 문서의 설명도 있으므로, 웹 화면을 포함한 앱이라면 네이티브만 따로 통과시키지 않는 편이 안전합니다.
네트워크 보안 구성의 TLS·도메인 설정은 별도의 판단 대상입니다. 로컬 네트워크 권한은 “같은 LAN에 접근할 수 있는가”의 문제이고, 네트워크 보안 구성은 연결 대상과 보안 규칙을 어떻게 설정하는가의 문제입니다. 두 범위를 함께 검수하되 하나의 체크로 합치지 마세요. Android 네트워크 보안 구성의 기본값·도메인·디버그 점검도 별도로 확인할 수 있습니다.
출시 전 한 장으로 정리하는 체크리스트
기능이 LAN 직접 통신인지, 원격 서버 통신인지 구분했다.
target SDK와 실제 테스트 기기/OS를 기록했다.
시스템 picker로 목적을 달성할 수 있는지 먼저 검토했다.
광범위 접근이 필요하다면 manifest·런타임 요청·거부/철회 처리를 연결했다.
취소·거부·철회·차단·성공을 서로 다른 결과로 확인했다.
사용자 안내, 기술 로그, 지원 문서의 표현이 실제 기능 범위를 넘지 않는다.
이 체크리스트는 Android 심사 통과나 기기 호환성을 보장하지 않습니다. 다만 LAN 기기 연동의 의도와 실제 접근 범위를 먼저 분리해, target SDK 전환 뒤에 원인을 알 수 없는 연결 실패가 남는 일을 줄이는 데 쓰는 운영 기록입니다.
자주 묻는 질문
Android 17을 타깃하면 모든 앱이 로컬 네트워크 권한을 요청해야 하나요?
아닙니다. 앱이 실제로 로컬 네트워크에 접근하는지 먼저 확인해야 합니다. 시스템 picker로 해결할 수 있는 사용 사례도 있으며, 직접적이고 지속적인 LAN 통신이 필요한 경우에 광범위 권한 경로를 검토합니다.
`ACCESS_LOCAL_NETWORK`는 언제 선언하고 요청하나요?
Android 문서는 SDK 37 이상 앱이 직접 로컬 네트워크 접근을 필요로 할 때 manifest 선언, 접근 직전의 승인 상태 확인, 필요한 시점의 런타임 요청을 안내합니다. SDK 36 이하 앱에 같은 요청을 미리 적용하라는 뜻은 아닙니다.
사용자가 권한을 거부하면 인터넷 기능도 모두 멈추나요?
로컬 네트워크 접근이 차단되는 상황과 일반 인터넷·모바일 네트워크 통신은 구분해서 확인해야 합니다. 제품의 실제 통신 구조와 오류 처리는 테스트로 검증하고, 거부 시에는 필요한 기능만 제한하는 대안을 설계합니다.
WebView 안의 로컬 기기 화면은 별도 권한을 받나요?
Android 문서는 로컬 네트워크 접근이 필요한 WebView 트래픽이 호스트 앱의 권한 상태를 상속한다고 설명합니다. 따라서 WebView를 포함한 실제 앱 빌드에서 권한 상태별 동작을 같이 검수해야 합니다.