앱 MVP Android 앱 휴면: 권한·작업·알림 복구를 나누는 5가지 기준
Android 앱 MVP를 오래 열지 않은 사용자가 다시 돌아왔을 때, 로그인 화면은 열리는데 알림이 오지 않거나 위치·카메라 기능이 다시 권한을 묻는 상황이 생길 수 있습니다. 이를 단순히 “앱이 멈췄다”로 처리하면 원인을 잘못 짚기 쉽습니다. Android의 앱 휴면은 권한, 백그라운드 작업, 알림, 캐시를 같은 방식으로 복구하지 않습니다.
Android Developers에 따르면 Android 11 이상을 타깃으로 하는 앱이 장기간 사용되지 않으면 미사용 앱 제한이 적용될 수 있습니다(C001). Android 12 이상 환경에서의 휴면 효과에는 런타임 권한 초기화, 백그라운드 작업·알림 실행 불가, 푸시 수신 불가, 캐시 파일 삭제가 포함될 수 있습니다(C002). 기기 버전과 target SDK에 따라 효과가 다르므로, 모든 사용자가 똑같이 겪는 현상이라고 단정하면 안 됩니다.
먼저 답: 다시 열린 앱과 복구된 기능은 같은 완료가 아닙니다
사용자가 아이콘을 눌러 앱을 열면 휴면 상태에서는 벗어날 수 있습니다. 하지만 Android 문서는 이때 이전에 부여된 런타임 권한을 자동으로 다시 주지 않으며, 휴면 전에 잡아 둔 작업·알림·알림 예약도 자동으로 다시 등록하지 않는다고 설명합니다(C003). 즉 앱 실행 성공, 권한 확인, 작업 재등록, 서버 동기화, 사용자에게 보이는 완료 안내는 별도의 상태입니다.
초기 MVP에서 이 구분은 특히 중요합니다. “오랜만에 앱을 열면 자동으로 모두 정상화된다”는 문구 대신, 어떤 기능이 권한을 다시 확인하는지, 어떤 예약을 다시 만들지, 무엇은 서버 상태를 재조회해야 하는지를 제품 요구사항에 적어야 합니다. 휴면 여부만으로 결제·업로드·가입 같은 사업상 완료를 추정해서는 안 됩니다.
기준 1: 기능을 열기 직전에 현재 권한을 다시 확인합니다
권한을 한 번 받았다는 기록은 이후에도 유효하다는 보장이 아닙니다. Android의 권한 요청 가이드는 기능에 접근할 때마다 현재 권한이 부여됐는지 확인하라고 안내합니다(C004). 권한이 없으면 사용자가 선택한 기능과 필요한 권한의 이유를 먼저 설명하고, 요청 뒤에는 허용·거부·다시 묻지 않음에 맞는 다음 화면을 준비해야 합니다.
예를 들어 위치 기반 체크인을 다시 열었다면 “이전 권한 복구”라는 내부 표현보다 “현재 위치 권한 확인 → 선택 기능 실행 → 결과 검증”처럼 사용자 흐름을 나누는 편이 좋습니다. 권한 허용 callback은 위치가 실제로 읽혔다는 뜻도, 서버 저장이 끝났다는 뜻도 아닙니다. 기능 실행과 서비스 결과는 별도 기록으로 확인하세요.
기준 2: 휴면 전 예약은 다시 만들 대상을 명시합니다
앱이 다시 사용되면 새 작업·알림·알림 예약을 만들 수 있지만, 휴면 전의 예약이 자동 복원되는 것은 아닙니다(C003). 따라서 팀은 예약마다 목적과 재등록 규칙을 분리합니다. 예를 들어 동기화는 마지막 성공 시점과 서버 업무 키를 확인한 뒤 새 요청을 만들고, 사용자 약속 시간이 있는 알림은 중복 발송 여부와 다음 알림 시각을 다시 계산합니다.
여기서 WorkManager를 추가했다는 사실은 서버 업무 완료의 증거가 아닙니다. 예약 등록, 실행 관찰, 서버 처리, 사용자 화면 반영을 나눠야 합니다. 백그라운드 작업과 중복 정책 자체가 궁금하다면 앱 MVP Android WorkManager 기준도 함께 보세요. 이 글의 초점은 작업 도구 선택이 아니라 휴면 뒤 어떤 예약을 다시 설계할지입니다.
기준 3: ‘사용’으로 보는 행동과 단순 백그라운드 실행을 구분합니다
Android 문서에서는 Activity 재개, 위젯 상호작용, 알림을 눌러 상호작용하는 경우 등을 앱 사용의 예로 듭니다(C005). 반면 예약 작업 실행, 암시적 브로드캐스트 수신, 알람 예약만으로는 사용으로 보지 않는다고 안내합니다(C006). 그래서 매일 동기화가 돌아간다는 관측만으로 사용자가 앱을 열었다거나 휴면을 피한다고 판단하면 안 됩니다.
제품 분석도 같은 원칙을 따릅니다. ‘앱 열기’, ‘권한 재허용’, ‘복구 예약 생성’, ‘서버 응답 확인’, ‘사용자 기능 완료’를 하나의 활성 사용자 이벤트로 합치지 말고 목적별 이벤트와 오류 문구를 분리하세요. 그래야 휴면 영향인지, 권한 거부인지, 서버 지연인지 구분해 다음 개선을 결정할 수 있습니다.
기준 4: 예외 요청은 핵심 사용 사례가 있을 때만 설명과 함께 합니다
Android는 가족 안전 위치 보고, 서버와의 데이터 동기화, 스마트 기기 통신, 동반 기기 연결처럼 사용자가 주로 백그라운드 동작을 기대하는 경우 휴면 예외를 요청할 수 있다고 설명합니다(C007). 예외는 개발 편의를 위한 기본값이 아닙니다. 먼저 해당 동작이 사용자에게 왜 필요한지, 미사용 상태에서도 어떤 가치가 남는지, 일반 복구 흐름으로 해결할 수 없는지를 적어야 합니다.
예외를 요청하기 전에는 PackageManagerCompat.getUnusedAppRestrictionsStatus()로 제한 상태를 확인할 수 있으며(C008), 실제 요청 시에는 이유를 설명하는 UI를 보여 준 뒤 설정 화면으로 연결해야 합니다(C009). 설정 화면을 열었다고 해서 사용자가 예외를 허용했다는 뜻은 아니므로, 복귀 뒤 상태를 다시 읽고 거절 때의 대체 흐름도 준비하세요.
기준 5: 테스트는 ‘휴면 진입’과 ‘제품 복구’를 따로 끝냅니다
Android 문서는 테스트 기기에서 휴면 동작을 수동으로 유발하고 상태를 확인하는 절차를 제공합니다(C010). 하지만 시스템 상태 확인만으로 제품 QA가 끝나지는 않습니다. 대표 기능 하나를 골라 권한이 초기화된 상태, 예약이 사라진 상태, 캐시가 없는 상태, 사용자가 예외 요청을 거부한 상태에서 각각 무엇을 보여 주는지 확인하세요.
확인 층 | 질문 | 완료로 보지 말아야 할 것 |
|---|---|---|
시스템 | 현재 기기·target SDK에서 어떤 제한 상태인가 | 앱 아이콘을 한 번 연 사실 |
권한 | 기능 실행 전 현재 권한을 확인했는가 | 과거 권한 허용 이력 |
예약 | 다시 만들 작업·알림과 중복 규칙은 무엇인가 | 예약 API 호출 성공 |
서비스 | 서버가 업무 키를 처리했는가 | 앱 내부 작업 성공 상태 |
사용자 | 복구·거부·재시도 상태를 이해할 수 있는가 | 설정 화면으로 이동한 사실 |
핵심은 휴면을 없애는 데 있지 않습니다. 장기간 미사용 뒤에도 앱이 어떤 권한을 다시 묻고, 무엇을 재등록하며, 사용자가 거부했을 때 어떻게 안전하게 기능을 줄일지를 미리 정하는 데 있습니다.
휴면 뒤에도 설명 가능한 앱 MVP 복구 흐름 설계하기
공식 출처
Android Developers: App hibernation (2026-09-21 직접 확인)
Android Developers: Request runtime permissions (2026-09-21 직접 확인)
Android Developers: UnusedAppRestrictionsConstants (2026-09-21 직접 확인)
자주 묻는 질문
앱을 다시 열면 권한도 자동으로 돌아오나요?
아닙니다. Android 문서는 휴면에서 벗어나도 이전 런타임 권한을 자동으로 다시 부여하지 않는다고 안내합니다. 기능 실행 전 현재 권한을 다시 확인해야 합니다.
휴면 전 WorkManager 작업은 자동으로 재개되나요?
아닙니다. 휴면 전에 예약한 작업·알림·알림 예약은 자동으로 다시 등록되지 않습니다. 서비스별 재등록과 중복 방지 기준이 필요합니다.
백그라운드 작업이 실행되면 앱 사용으로 보나요?
항상 그렇지 않습니다. Android의 휴면 안내는 예약 작업 실행만으로는 앱 사용으로 보지 않는 예를 제시합니다.
휴면 예외는 모든 앱이 요청해야 하나요?
아닙니다. 사용자가 주로 백그라운드 동작을 기대하는 핵심 사례가 있을 때, 이유를 설명하고 사용자가 설정에서 선택하도록 해야 합니다.
발행일: 2026-09-21 · 작성: 유인어스 정책자금·정부지원사업 인사이트