앱 MVP 저장공간: 원본·캐시·공유 파일을 나누는 5가지 기준
앱 MVP 저장공간: 원본·캐시·공유 파일을 나누는 5가지 기준
앱에서 사진 한 장을 내려받거나 문서를 업로드할 때, 그 파일이 언제까지 남아야 하는지를 먼저 정하지 않으면 기능은 쉽게 흔들립니다. 사용자가 다시 볼 원본까지 캐시처럼 지우거나, 잠깐 보여 줄 미리보기를 영구 보관하면 삭제·재다운로드·앱 삭제 뒤의 안내가 서로 어긋납니다.
이 글은 Android MVP에서 파일을 저장할 때 사용자 가치, 다른 앱과의 공유, 임시성, 재다운로드 가능성, 삭제 경로를 나누는 기준을 정리합니다. 특정 앱의 데이터 보존, 개인정보 보호, 손실 방지, 스토어 심사 결과를 보장하지 않습니다. 실제 데이터 분류와 보관 기준은 서비스 정책과 기능 특성에 맞춰 별도로 결정해야 합니다.
먼저 정할 질문: 이 파일은 앱이 지워져도 사용자가 기대할 자산인가?
Android는 앱만 쓰는 파일을 위한 앱 전용 저장소와 다른 앱도 접근할 수 있는 공유 저장소를 구분합니다. Android Developers는 사용자가 앱을 지운 뒤에도 사진처럼 계속 접근할 것을 기대하는 파일은 앱 전용 저장소에만 두지 말고 적절한 공유 미디어 컬렉션에 저장하라고 안내합니다. 반대로 앱 안에서만 의미가 있는 설정 파일이나 다시 내려받을 수 있는 화면 자원까지 공유 저장소에 둘 이유는 별도 검토가 필요합니다.
따라서 “파일 저장”을 한 상태로 부르기보다, 파일마다 다음 질문에 답하는 편이 좋습니다. 사용자가 앱 밖에서도 써야 하는가, 앱을 삭제한 뒤에도 남아야 하는가, 서버나 원본에서 다시 받을 수 있는가, 다른 앱에 전달해야 하는가, 임시 사본이 사라져도 화면이 복구되는가입니다. 이 답이 저장 위치와 삭제 안내를 결정합니다.
기준 1: 원본 사용자 자산과 앱 내부 작업 파일을 같은 정책으로 다루지 않습니다
사용자가 촬영한 사진, 내려받아 보관하겠다고 한 문서, 다른 앱과 공유할 결과물처럼 독립적인 가치를 가진 파일은 ‘앱을 위한 부속물’인지 먼저 확인해야 합니다. Android의 저장소 개요는 공유할 의도가 있는 미디어는 공유 저장소, 앱 안에서만 의미가 있는 파일은 앱 전용 저장소에 두는 방향을 설명합니다.
반면 API 응답을 가공한 중간 파일, 다시 만들 수 있는 썸네일, 다음 화면으로 넘길 임시 첨부본은 앱 내부 작업일 수 있습니다. 중요한 것은 파일 확장자보다 독자적 사용자 가치입니다. 같은 이미지라도 사용자가 저장해 두길 기대하는 최종 결과물과 목록에서 잠시 보일 미리보기는 같은 수명주기를 가질 필요가 없습니다.
기준 2: 캐시는 ‘남아 있을 수도 있는 복사본’으로만 사용합니다
캐시는 빠른 표시나 반복 다운로드 감소에 유용할 수 있지만, 원본의 유일한 보관 장소가 되어서는 곤란합니다. Android Developers는 내부 캐시 디렉터리의 파일이 앱 삭제 때 제거되며, 저장 공간이 부족하면 그보다 먼저 삭제될 수 있다고 설명합니다. 읽기 전에 파일 존재 여부를 확인하고, 앱이 캐시를 직접 관리해야 한다는 안내도 함께 제공합니다.
MVP 화면에서는 캐시 유무를 곧바로 ‘콘텐츠 삭제’로 번역하지 않는 흐름을 준비합니다. 캐시가 없으면 서버에서 다시 가져올 수 있는지, 사용자가 다시 선택해야 하는지, 네트워크가 없으면 어떤 상태를 보여 줄지 나눠야 합니다. 캐시 정리 버튼을 둔다면 무엇이 사라지고 무엇은 남는지를 사용자에게 분명히 안내하는 편이 좋습니다.
우리 앱 MVP의 파일·캐시·삭제 기준을 함께 정리하기
기준 3: 앱 전용 영구 파일도 ‘앱 삭제 뒤 사라질 수 있음’을 기록합니다
‘영구 파일’이라는 말은 앱이 설치된 동안의 수명일 수 있습니다. Android의 앱 전용 저장소 문서는 앱을 제거하면 그 위치에 둔 파일도 삭제된다고 설명합니다. 그래서 로그인 세션을 복구하는 데 필요한 로컬 파일, 오프라인에서 보려는 자료, 작성 중인 초안처럼 앱 전용 영구 영역에 둘 항목은 앱 삭제·기기 변경·재설치 뒤의 복구 방식을 별도로 결정해야 합니다.
여기서 서버 동기화를 넣는다고 자동으로 복구가 보장되는 것은 아닙니다. 어떤 데이터가 서버에 실제 저장되는지, 사용자가 동기화를 끌 수 있는지, 저장이 끝나기 전에 앱이 종료되면 무엇을 보여 줄지, 다시 로그인했을 때 어떤 시점의 데이터를 불러올지를 제품 흐름으로 정해야 합니다. 저장 위치는 그 흐름을 구현하는 수단이지, 복구 정책 자체는 아닙니다.
기존 글 앱 MVP 파일 내보내기: 저장·공유·삭제를 나누는 5가지 기준은 사용자가 고른 저장 위치로 결과물을 내보내는 흐름에 집중합니다. 이번 글은 내보내기 전부터 앱 안에 존재하는 원본·앱 전용 데이터·캐시의 수명과 복구 경계를 정하는 글입니다.
기준 4: 외부 앱 전용 저장소는 접근 가능 상태를 별도로 확인합니다
앱 전용 외부 저장소는 큰 파일을 다룰 때 후보가 될 수 있지만, 항상 접근 가능하다고 가정하면 안 됩니다. Android Developers는 외부 저장소가 물리적 볼륨일 수 있어 제거되거나 읽기 전용 상태가 될 수 있으므로, 읽기·쓰기에 앞서 상태를 확인하라고 안내합니다. 기능의 기본 동작에 꼭 필요한 데이터라면 내부 저장소나 데이터베이스 같은 다른 선택지를 검토할 이유입니다.
이 경계는 오류 안내에도 영향을 줍니다. “파일이 없습니다”라는 하나의 문구 대신 저장소를 사용할 수 없는 상태, 캐시가 정리된 상태, 원본을 다시 받아야 하는 상태, 사용자가 다시 선택해야 하는 상태를 구별합니다. 각 상태에 따라 재시도·재다운로드·재선택 중 가능한 행동을 하나씩 제시하면 운영 문의에서도 원인을 덜 추측하게 됩니다.
기준 5: 삭제와 재다운로드는 파일 삭제 명령이 아니라 사용자 경험의 상태 전환입니다
파일을 지우는 동작은 적어도 네 가지 질문을 남깁니다. 사용자가 삭제를 요청했는가, 로컬 복사본만 지우는가, 서버 원본도 지우는가, 다음에 다시 열면 자동으로 받는가입니다. 이 질문을 합치면 “캐시 비우기”가 사용자의 저장된 자료까지 지우는 것처럼 보이거나, 실제로는 네트워크가 필요한데 즉시 열릴 것처럼 안내할 수 있습니다.
작게 시작하는 MVP라면 파일마다 복잡한 상태표를 만들 필요는 없습니다. 다만 최종 사용자 파일, 앱 전용 데이터, 캐시, 공유된 결과물에 대해 보관 위치·소유 주체·삭제 주체·복구 경로·화면 안내를 한 줄씩 남겨 보세요. 외주 인수나 기능 확장 때도 ‘무엇을 지웠는가’와 ‘무엇을 다시 만들 수 있는가’를 다시 확인할 수 있습니다.
출시 전 점검표
사용자가 앱 삭제 뒤에도 기대할 파일과 앱 안에서만 의미가 있는 파일을 구분했는가?
캐시가 사라져도 원본·서버·재선택 중 어떤 복구 경로가 있는지 정했는가?
앱 전용 영구 파일이 앱 삭제·재설치 뒤에 사라질 수 있음을 화면과 정책에서 어떻게 다룰지 결정했는가?
외부 앱 전용 저장소를 쓴다면 읽기·쓰기 전 접근 가능 상태를 확인하는가?
삭제 버튼이 로컬 사본, 서버 원본, 공유된 결과물 중 무엇에 영향을 주는지 분명한가?
캐시 없음·저장소 사용 불가·재다운로드 필요·재선택 필요 상태에 각각 다음 행동이 있는가?
저장공간 설계의 핵심은 파일을 많이 보관하는 것이 아니라, 사용자가 기대한 파일과 앱이 잠깐 필요로 한 복사본을 섞지 않는 데 있습니다. 이 경계를 먼저 기록하면 캐시 정리, 재로그인, 기기 교체, 앱 삭제 같은 장면을 기능마다 다시 추측하지 않고 검토할 수 있습니다.
자주 묻는 질문
캐시에 둔 파일은 항상 다음 실행에서도 남아 있나요?
아닙니다. Android는 저장 공간이 부족하면 캐시 파일을 더 일찍 제거할 수 있다고 안내합니다. 캐시는 남아 있으면 활용할 수 있는 복사본으로 보고, 없을 때의 재다운로드·재선택·안내 경로를 별도로 준비하는 편이 좋습니다.
사용자가 만든 사진은 앱 전용 저장소에 두면 안 되나요?
앱 삭제 뒤에도 사용자가 계속 접근할 것을 기대하는 사진이라면, Android Developers는 적절한 공유 미디어 컬렉션을 사용하라고 안내합니다. 다만 어떤 파일이 독립적인 사용자 자산인지와 실제 공유·삭제 정책은 서비스별로 판단해야 합니다.
앱 전용 영구 파일은 왜 앱 삭제 뒤 사라질 수 있나요?
Android의 앱 전용 저장소에 둔 파일은 앱 제거 시 삭제됩니다. 따라서 재설치 뒤에도 필요할 데이터는 실제 동기화 범위와 복구 흐름을 따로 정해야 하며, 이 글만으로 특정 복구 결과가 보장되지는 않습니다.
캐시 비우기와 계정 데이터 삭제를 하나의 버튼으로 만들면 되나요?
두 동작은 영향 범위가 다를 수 있습니다. 캐시 비우기는 로컬 임시 복사본, 계정 데이터 삭제는 서버 원본이나 서비스 접근과 연결될 수 있으므로, 무엇이 지워지고 무엇이 남는지와 다음 접근 방법을 분리해 안내하는 편이 좋습니다.
출처
Android Developers, Access app-specific files (2026-09-20 확인)
Android Developers, Data and file storage overview (2026-09-20 확인)
Android Developers, Access media files from shared storage (2026-09-20 확인)
발행일: 2026-09-20 · 작성: 유인어스 정책자금·정부지원사업 인사이트