앱 MVP Android 백업: 보존할 데이터·제외할 데이터·복원 검증을 나누는 5가지 기준
앱 MVP Android 백업: 보존할 데이터·제외할 데이터·복원 검증을 나누는 5가지 기준
Android MVP에서 “백업을 켰다”는 말은 출시 준비가 끝났다는 뜻이 아닙니다. 사용자가 새 기기로 바꾸거나 앱을 다시 설치했을 때 무엇이 남아야 하는지, 무엇은 다시 받아야 하는지, 복원 뒤 어떤 흐름을 실제로 확인할지를 따로 정해야 합니다.
먼저 답하면, Android 앱 백업은 **보존할 사용자 상태, 제외할 임시·기기 종속 상태, 전송 경로별 규칙, 복원 뒤의 핵심 행동, 재현 가능한 검증 기록**을 나눠 정할 때 검토 가능한 설계가 됩니다. 이 글은 특정 앱의 설정 완료나 복원 성공을 뜻하지 않으며, 배포 전 실제 `targetSdk`, 데이터 위치, 인증 구조, 최신 Android 문서를 함께 확인해야 합니다.
Android Developers는 새 기기나 재설치 뒤에도 사용자 경험을 이어가려면 정체성, 사용자 생성 데이터, 설정 데이터를 구분해 보존하라고 안내합니다. Auto Backup은 Android 6.0(API 23) 이상을 대상으로 대부분의 앱 파일을 기본 포함하지만, 캐시와 no-backup 위치는 기본 제외합니다. 따라서 “파일이 있다”는 이유만으로 백업 대상이라고 판단하면 안 됩니다.
기존 앱 MVP 저장공간 가이드는 원본·캐시·공유 파일의 저장 수명을 다룹니다. 이 글은 그 다음 질문, 즉 새 설치 또는 기기 전환 뒤에 어떤 상태가 복원돼야 하는지와 이를 어떻게 검증할지를 다룹니다. 화면 상태를 다시 만드는 기준은 앱 MVP 상태 복원 가이드에서 별도로 확인할 수 있습니다.
1. 먼저 ‘돌아와야 하는 사용자 경험’을 나눕니다
백업 규칙부터 쓰기보다 사용자가 다시 열었을 때 이어져야 하는 경험을 적어 보세요. Android 공식 안내는 계정·정체성, 사용자가 만든 앱 데이터, 사용자가 조정한 설정을 구별합니다. 하지만 실제 제품에서는 같은 파일 안에도 다시 만들어도 되는 값과 반드시 보존해야 하는 값이 섞일 수 있습니다.
예를 들어 아래처럼 다섯 칸으로 분리하면 논의가 쉬워집니다.
구분 | 먼저 물을 질문 | 기록 예시 |
|---|---|---|
계정 | 재로그인이 필요한가, 복원할 수 있는가? | 로그인 상태는 별도 인증 설계로 확인 |
사용자 데이터 | 사용자가 만든 내용 중 무엇이 없어지면 안 되는가? | 작성 중인 메모의 원본 여부 |
설정 | 사용자가 직접 바꾼 값인가? | 알림 켜기·끄기, 안내 화면 확인 여부 |
임시값 | 다시 생성하거나 내려받을 수 있는가? | 이미지 캐시, 재생성 가능한 목록 |
기기 종속값 | 다른 기기에서도 같은 값이 유효한가? | 기기별 식별자, 오래된 URI |
표의 예시는 특정 서비스의 실제 데이터가 아닙니다. 핵심은 ‘남아야 한다’와 ‘파일에 들어 있다’를 같은 판단으로 읽지 않는 것입니다. 특히 URI는 다른 기기에서 유효하지 않을 수 있다고 Android Developers가 안내하므로, 복원이 필요한 사용자 선택이라면 원래 URI 자체가 아닌 제목·식별 정보·재선택 흐름을 따로 설계할지 검토해야 합니다.
2. 기본 포함과 명시적 제외를 실제 저장 위치로 대조합니다
Auto Backup은 shared preferences, 앱 내부 파일, 데이터베이스, 앱 전용 외부 저장소의 파일 등을 기본 포함할 수 있습니다. 반면 `getCacheDir()`, `getCodeCacheDir()`, `getNoBackupFilesDir()` 위치는 기본 제외됩니다. 앱이 ‘캐시’라고 부르는 데이터가 실제로 어느 디렉터리에 있는지, 반대로 복원되면 곤란한 토큰·기기 식별자·디버그 파일이 기본 포함 위치에 있는지를 소스와 함께 확인해야 합니다.
포함 규칙을 하나라도 쓰면 기본 포함 범위가 바뀔 수 있습니다. 따라서 XML에 파일 하나를 추가하는 작업은 “이 파일만 남긴다”는 정책인지, “기본 대상에서 이 파일만 뺀다”는 정책인지와 함께 기록하세요. Android 12(API 31) 이상을 대상으로 하는 앱은 `data-extraction-rules`에서 cloud backup과 device-to-device transfer 규칙을 나눌 수 있습니다.
다음 네 가지를 코드 검토 표에 남겨 두면 누락을 줄일 수 있습니다.
데이터 이름과 실제 저장 위치는 무엇인가?
사용자가 잃으면 곤란한 원본인가, 다시 만들 수 있는 캐시인가?
클라우드 백업과 기기 간 전송에서 같은 규칙이 필요한가?
복원 뒤 이 값이 오래되었거나 다른 기기에 맞지 않을 때의 대체 흐름은 있는가?
3. 백업 여부와 인증·보안을 같은 완료 신호로 섞지 않습니다
복원할 수 있는 앱 데이터와 사용자가 다시 인증해야 하는 상태는 같은 질문이 아닙니다. Android Developers는 자격 증명과 인증 토큰을 일반 파일이나 shared preferences에 저장하지 말고, 별도 API를 검토하라고 안내합니다. 그러므로 “로그인이 풀리지 않는다”는 요구를 곧바로 “토큰을 백업한다”는 구현으로 바꾸지 마세요.
민감한 데이터가 있다면 저장 위치, 복원 필요성, 사용자 동의, 기기 전환 시 위험, 서버에서 다시 확인해야 하는 상태를 따로 검토해야 합니다. Auto Backup의 데이터가 암호화된다는 설명도 모든 앱의 보안 적합성이나 규정 충족을 보장하지 않습니다. 제품의 개인정보 처리, 인증 정책, 외부 SDK, 서버 권한은 별도 검토 대상입니다.
4. 클라우드 복원과 기기 간 전송을 각각 테스트합니다
Android 공식 테스트 문서는 클라우드 백업을 실행한 뒤 앱을 삭제·재설치하고, 로그인·변경한 설정·앱 데이터가 유지되는지 확인하는 흐름을 제시합니다. 또 기기 간 전송(D2D)은 별도의 조건과 절차가 있으므로, 하나의 테스트 통과만으로 두 경로가 모두 검증됐다고 쓰면 안 됩니다.
MVP 팀은 테스트마다 아래 다섯 항목을 기록해 보세요.
확인 항목 | 클라우드 복원 | 기기 간 전송 |
|---|---|---|
테스트한 앱 버전·target SDK | 실제 값 기록 | 실제 값 기록 |
테스트 데이터 | 사용자가 만든 원본·설정 구분 | 같은 기준으로 구분 |
실행 전 조건 | 백업 계정·네트워크 등 확인 | 대상 기기·전송 조건 확인 |
복원 뒤 확인 | 핵심 화면과 행동을 재실행 | 핵심 화면과 행동을 재실행 |
실패 기록 | 누락 데이터·재현 단계·다음 조치 | 누락 데이터·재현 단계·다음 조치 |
여기서 ‘로그인 성공’만 확인해서는 충분하지 않을 수 있습니다. 저장한 데이터가 정확히 복원됐는지, 이미 본 온보딩을 다시 보지 않는지, 알림 설정이 의도대로 반영되는지, 제외한 캐시가 정상적으로 재생성되는지처럼 제품의 핵심 흐름으로 확인하세요. 테스트 명령을 실행하기 전에는 실제 기기와 개발 환경의 권한·데이터 손실 영향을 팀이 검토해야 합니다.
5. 복원 성공의 정의를 출시 체크리스트에 남깁니다
백업은 자동으로 실행될 수 있고, 기기 상태와 네트워크 조건의 영향을 받습니다. 그래서 ‘오늘 백업됨’이라는 관찰과 ‘사용자에게 필요한 상태가 복원됨’이라는 제품 판단을 분리해야 합니다. Android Developers는 Auto Backup이 보통 하루 단위로 일어날 수 있지만 조건이 맞지 않으면 실행되지 않을 수 있다고 설명합니다.
출시 전에 다음 문장에 답할 수 있으면 판단 근거가 남습니다.
복원해야 하는 사용자 데이터와 설정의 목록은 무엇인가?
캐시·디버그 파일·기기 종속 식별자 중 명시적으로 제외할 대상은 무엇인가?
cloud backup과 device-to-device transfer가 달라지는 대상은 무엇인가?
삭제·재설치 또는 기기 전환 뒤 사용자가 완수해야 할 핵심 행동은 무엇인가?
실패하면 어떤 원본 기록, 로그, 재현 단계로 원인을 나눌 것인가?
유인어스는 민간 사업 지원 서비스입니다. 위 체크리스트는 Android MVP 운영 판단을 돕는 일반 정보이며, 앱 심사 통과·보안 적합성·사용자 유지·지원사업 선정이나 자금 지원을 보장하지 않습니다.
자주 묻는 질문
캐시 파일도 백업되나요?
Android Auto Backup은 `getCacheDir()`, `getCodeCacheDir()`, `getNoBackupFilesDir()` 위치를 기본 제외합니다. 다만 실제 앱의 파일 위치와 XML 규칙을 확인해야 하므로, 이름만 보고 캐시 여부를 단정하지 마세요.
Android 12 이상이면 클라우드와 기기 간 전송을 따로 정할 수 있나요?
Android 12(API 31) 이상을 대상으로 하는 앱은 `data-extraction-rules`에서 cloud backup과 device-to-device transfer 섹션을 나눌 수 있습니다. 실제 적용 범위는 기기 버전과 앱의 target SDK를 함께 확인해야 합니다.
백업이 설정돼 있으면 복원 테스트는 생략해도 되나요?
아닙니다. Android Developers는 백업 실행 후 삭제·재설치하고, 로그인·변경한 설정·데이터가 유지되는지 확인하는 테스트 흐름을 제공합니다. 제품의 핵심 행동을 기준으로 실제 복원 결과를 확인해야 합니다.
백업되면 로그인 토큰도 파일에 넣어도 되나요?
그렇게 단정하면 안 됩니다. Android Developers는 자격 증명과 인증 토큰을 일반 파일이나 shared preferences에 저장하지 말고 별도 API를 검토하라고 안내합니다. 인증·보안 정책은 백업 규칙과 별도로 설계·검토하세요.
확인한 공식 출처
Android Developers — Data backup overview: 보존할 데이터 범주, 백업 방식과 URI 유의사항을 2026-09-23 KST에 확인했습니다.
Android Developers — Back up user data with Auto Backup: 기본 포함·제외 위치, 복원 시점, Android 12 이상 규칙 분리와 테스트 관련 안내를 2026-09-23 KST에 확인했습니다.
Android Developers — Test backup and restore: 클라우드 복원 및 D2D 테스트의 검증 흐름을 2026-09-23 KST에 확인했습니다.