앱 MVP Android StrictMode: 감지·로그·수정 범위를 나누는 5가지 기준
Android MVP를 출시 직전에 점검할 때 “StrictMode 경고가 없었다”는 말을 곧바로 안정성이나 출시 가능성으로 바꾸기 쉽습니다. 하지만 StrictMode는 개발 중 우연히 발생한 작업을 눈에 띄게 하는 도구입니다. 어떤 화면과 흐름에서, 어떤 정책으로, 어떤 위반을 봤는지 기록하지 않으면 경고 숫자만 남고 다음 수정 판단은 남지 않습니다.
이 글은 Android MVP에서 StrictMode를 성과 지표나 보안 인증처럼 쓰지 않고, 개발·QA·출시 판단 사이의 확인 기록으로 쓰는 방법을 정리합니다. 기준은 Android Developers의 StrictMode, 앱 품질, ANR 및 Android 15 동작 변경 문서입니다.
먼저 나눌 것: 탐지 신호와 사용자 결과
StrictMode는 의도치 않은 디스크·네트워크 접근처럼 개발 중 바로잡을 일을 찾는 데 쓰입니다. 특히 UI가 처리되고 애니메이션이 동작하는 메인 스레드의 I/O는 반응성에 영향을 줄 수 있어 검토 대상이 됩니다. 그렇다고 경고가 한 번도 없었다고 해서 모든 실제 기기·네트워크·계정 상태에서 문제가 없었다고 말할 수는 없습니다.
따라서 결과 기록은 두 칸으로 분리하는 편이 좋습니다. 첫째는 StrictMode가 잡은 개발 신호입니다. 둘째는 실제 출시 범위에서 수행한 사용자 흐름 QA와, 필요하다면 별도 크래시·ANR 관찰입니다. StrictMode의 발견과 사용자의 업무 완료, 스토어 심사 결과를 같은 완료 상태로 묶지 않아야 합니다.
1. 어디에서 켤지: Application 전체와 특정 화면을 구분합니다
Android 문서는 StrictMode를 Application 또는 Activity 수준에서 활성화할 수 있다고 설명합니다. MVP 팀에는 “항상 전체 앱에서 켠다” 또는 “특정 화면에서만 켠다”보다, 이번 테스트의 목적과 범위를 먼저 적는 방식이 더 실용적입니다.
예를 들어 첫 실행·로그인·목록·결제 직전 화면처럼 사용자가 기다리는 핵심 경로를 점검한다면, 그 경로가 시작되는 시점과 테스트 기기를 기록합니다. 반대로 아직 실험 중인 관리자 화면은 별도 범위로 두면, 경고가 나온 위치와 출시 판단의 관계를 과장하지 않을 수 있습니다. 범위를 정했다면 “어떤 빌드, 어떤 진입점, 어떤 계정 상태”에서 켰는지도 함께 남기세요.
2. 무엇을 볼지: ThreadPolicy와 VmPolicy를 한 항목으로 합치지 않습니다
StrictMode에는 현재 스레드에 적용되는 ThreadPolicy와 프로세스의 스레드들에 적용되는 VmPolicy가 있습니다. 둘은 같은 이름의 ‘StrictMode 설정’이지만, 확인하려는 일이 다릅니다.
ThreadPolicy에서는 메인 스레드에서의 디스크 읽기·쓰기, 네트워크 접근, 느린 호출처럼 반응성에 연결될 수 있는 작업을 확인할 수 있습니다. VmPolicy에서는 리소스 누수, 명확하지 않은 URI 권한 전달, 평문 네트워크처럼 프로세스 범위에서 볼 대상을 검토할 수 있습니다. detectAll()은 지원되는 탐지를 넓게 켜는 출발점이 될 수 있지만, 실제로 어떤 탐지가 활성화되는지는 테스트 대상 Android 버전과 정책 구성을 함께 확인해야 합니다.
이때 “모든 경고를 고쳐야 한다”는 규칙도 피하는 편이 낫습니다. Android 문서는 정상적인 활동 생명주기에서 필요한 디스크 접근도 있을 수 있다고 설명합니다. 경고의 종류, 호출 위치, 사용자 흐름 영향, 대체 가능한 구현인지 순서로 판단해야 합니다.
3. 경고를 보는 방법: 로그·재현·원인을 세 줄로 남깁니다
위반이 나오면 바로 억제 설정을 추가하기보다 다음 세 줄을 남겨 보세요.
재현 조건: 빌드 번호, 기기·OS, 시작 화면, 수행한 행동, 계정·네트워크 전제입니다.
위반 관찰: Thread 또는 VM 정책, 로그의 호출 지점, 같은 행동에서의 반복 여부입니다.
판단: 실제로 옮길 작업인지, 허용 사유가 있는지, 추가 계측이나 코드 검토가 필요한지입니다.
penaltyLog처럼 위반을 관찰하는 정책을 선택하면 테스트 중 로그에서 신호를 볼 수 있습니다. 그 로그 한 줄을 “앱이 느리다”는 결론으로 바꾸지 말고, 재현 가능한 호출 위치를 찾는 출발점으로 다루세요. Android의 앱 품질 가이드도 성능 테스트에서 StrictMode를 켜고 메인 스레드와 다른 스레드의 잠재적 문제를 확인하라고 안내합니다.
중간 점검에서 핵심 사용자 흐름과 위반 기록을 함께 정리할 필요가 있다면, 앱 MVP QA 범위를 유인어스와 점검할 수 있습니다.
4. 수정 우선순위: 메인 스레드 I/O와 ‘나중에 볼 항목’을 구분합니다
메인 스레드의 네트워크 작업은 Android 문서에서 특히 문제 가능성이 큰 사례로 언급됩니다. 먼저 사용자 행동 중 발생하는 네트워크·디스크 작업이 있는지, 화면 전환이나 입력과 동시에 일어나는지, 작업을 분리했을 때 상태 표시와 재시도 흐름이 유지되는지를 검토하세요. 수정의 완료 조건은 “코드를 옮겼다”가 아니라, 같은 재현 조건에서 신호와 사용자 흐름을 다시 확인한 것입니다.
한편 detectCleartextNetwork() 같은 VM 정책의 신호는 평문 트래픽을 탐지하는 데 도움을 줄 수 있지만, 문서상 제한과 오탐 가능성도 있습니다. 이 신호 하나만으로 전체 보안 상태나 외부 노출을 단정하면 안 됩니다. 통신 대상, 네트워크 구성, 실제 전송 경로, 관련 보안 설정을 별도의 보안 검토 항목으로 연결하세요.
Android 15 이상을 목표로 한다면 unsafe intent launch 탐지처럼 버전별 항목도 분리합니다. 해당 탐지는 Android 15 동작 변경 문서에 소개되어 있으므로, target SDK·테스트 OS·관찰한 호출을 같은 기록에 적어 두는 편이 안전합니다. 이전 버전의 결과를 그대로 확장해 해석하지 않습니다.
5. 출시 전에는 ‘경고 없음’ 대신 확인 기록을 닫습니다
StrictMode는 ANR을 진단하거나 예방하는 유일한 방법이 아닙니다. Android의 ANR 안내도 StrictMode를 개발 중 우발적인 메인 스레드 I/O를 찾는 도구로 설명합니다. 출시 전에는 아래 다섯 항목이 서로 분리되어 있는지 확인하세요.
확인 항목 | 기록할 내용 | 완료로 보지 말아야 할 것 |
|---|---|---|
테스트 범위 | 빌드, 기기·OS, 핵심 흐름, 진입점 | ‘전체 앱을 검사했다’는 포괄 표현 |
정책 | ThreadPolicy·VmPolicy, 탐지·페널티 설정 | 설정 코드가 존재한다는 사실만 |
관찰 | 위반 유형, 호출 위치, 재현 여부 | 로그 한 줄만 보고 한 결론 |
수정 | 변경 위치, 대체 방식, 재검증 결과 | 코드 이동만으로 끝난 상태 |
별도 QA | 사용자 흐름, 오류·ANR 관찰, 미검증 범위 | StrictMode 결과로 대체한 사용자 검증 |
이 표는 Android의 필수 제출 서식이 아니라, MVP 팀이 개발 신호와 출시 판단을 섞지 않기 위한 운영 예시입니다. 기능 범위가 커지거나 외주·내부 팀이 나뉘면 이 기록이 다음 릴리스의 재현 조건을 다시 만드는 데도 도움이 됩니다.
기존 테스트와 연결하는 방법
StrictMode 점검은 단독 행사로 끝내기보다 배포 전 테스트와 연결하는 편이 낫습니다. Google Play 테스트 트랙에서는 누구에게 어느 빌드를 노출할지, 어떤 피드백을 받을지 별도로 정해야 합니다. Google Play 내부·비공개·공개 테스트 트랙을 고르는 기준도 함께 보면, 개발 중 탐지 신호와 배포 대상의 피드백을 다른 기록으로 관리할 수 있습니다.
출시 빌드의 오류 해석은 난독화 매핑 파일과도 연결될 수 있습니다. Android R8 매핑 파일과 오류 해석을 준비하는 기준에서 다룬 것처럼, 어느 빌드의 어떤 산출물을 확인했는지 남기면 StrictMode 로그와 실제 오류 조사 범위를 섞지 않게 됩니다.
자주 묻는 질문
StrictMode 경고가 없으면 출시해도 되나요?
그렇게 단정할 수 없습니다. StrictMode는 개발 중 의도치 않은 작업을 찾는 도구입니다. 테스트 범위 안에서 관찰한 결과일 뿐이므로, 핵심 사용자 흐름 QA, 실제 기기·네트워크 조건, 별도 오류·ANR 확인 범위를 함께 검토해야 합니다.
detectAll()을 켜면 모든 성능 문제를 찾나요?
아닙니다. Android 문서는 detectAll()이 지원되는 탐지를 활성화하는 방법임을 설명하지만, StrictMode는 모든 디스크·네트워크 접근을 보장해서 찾는 보안 장치가 아니라고도 안내합니다. 활성 정책, 테스트 기기와 OS, 재현 경로를 기록하고 다른 성능 검토와 분리하세요.
로그에 나온 디스크 접근은 전부 제거해야 하나요?
그렇지 않습니다. Android 문서는 정상적인 활동 생명주기에서 필요한 디스크 접근도 있을 수 있다고 설명합니다. 호출 위치, 사용자 상호작용과의 동시성, 대체 구현 가능성, 재검증 결과를 보고 우선순위를 정하세요.
StrictMode로 보안 점검을 끝낼 수 있나요?
아닙니다. 평문 네트워크 탐지나 unsafe intent launch처럼 관련 신호를 볼 수 있는 항목은 있지만, 신호 하나가 전체 보안 상태를 증명하지는 않습니다. 통신·권한·서버 검증·배포 설정은 별도 근거와 범위로 검토해야 합니다.
Android MVP의 출시 전 테스트 범위와 수정 기록을 제품 상황에 맞게 정리하려면, 유인어스에 앱 MVP QA·출시 점검을 상담해 보세요.