앱 MVP 파일 내보내기: 저장·공유·삭제를 나누는 5가지 기준
앱 MVP 파일 내보내기: 저장·공유·삭제를 나누는 5가지 기준
앱에서 PDF, 견적서, 리포트처럼 사용자가 가져갈 파일을 만들 때 “파일 생성 성공”만 완료 조건으로 두면 곧 문제가 생깁니다. 앱 안에서만 잠깐 쓸 파일인지, 사용자가 원하는 위치에 보관할 문서인지, 다시 열 수 있어야 하는지, 앱을 지운 뒤에도 남아야 하는지를 구분하지 않았기 때문입니다. Android는 앱 전용 저장소와 공유 저장소, 그리고 사용자가 시스템 선택기로 고른 문서 위치를 서로 다른 모델로 다룹니다.
먼저 답하면, 앱 기능에만 필요한 중간 파일은 앱 전용 저장소로 두고, 사용자가 보관·이동·공유할 결과물은 사용자가 고른 위치에 새 문서를 만드는 흐름을 우선 검토하는 편이 명확합니다. 이 글은 Android MVP에서 파일을 생성하는 제품·QA 기준입니다.
파일 보존·권한·보안·심사 통과나 사업 성과를 보장하지 않습니다. 사용자가 올린 파일을 선택·검증하는 범위는 앱 MVP 문서 업로드 기준, 다른 앱으로 보내는 범위는 앱 MVP 공유 기능 기준에서 따로 확인할 수 있습니다.
먼저 답: ‘앱만 쓰는 파일’과 ‘사용자가 가진 파일’은 저장 위치부터 다릅니다
Android의 앱 전용 저장소는 해당 앱만 사용하는 파일을 위한 위치입니다. 내부 저장소는 다른 앱이 접근하면 안 되는 민감한 정보를 둘 수 있는 위치로 안내되며, 앱 전용 파일은 앱을 제거하면 함께 삭제됩니다. 예를 들어 리포트를 만들기 위한 임시 이미지, 재시도 중인 변환 결과, 로그인한 동안만 필요한 첨부 준비 파일은 앱 전용 후보가 될 수 있습니다.
반면 사용자가 나중에 파일 앱에서 찾거나, 메일·메신저·다른 서비스로 옮길 PDF라면 앱이 자기 폴더에만 저장했다고 “내보내기 완료”라고 말하기 어렵습니다. 공유 문서·다운로드 파일에는 Storage Access Framework를 통해 사용자가 고른 위치에 새 파일을 만들 수 있습니다. 이 구분은 기술 구현만의 문제가 아니라, 사용자에게 “이 파일은 앱을 지워도 남는가”와 “어디에서 다시 찾는가”를 설명하는 제품 결정입니다.
기준 1: 생성 목적을 임시·앱 보관·사용자 보관으로 먼저 나눕니다
MVP 요구사항에 파일 이름과 확장자만 적지 말고, 각 파일에 생성 목적을 붙이세요. 임시 파일은 작업이 끝나면 정리할지, 앱 전용 보관 파일은 어떤 화면에서 다시 읽을지, 사용자 보관 파일은 시스템 선택기에서 저장 위치를 고르게 할지를 분리합니다. 같은 PDF여도 서버 전송 전 미리보기와 고객이 저장한 견적서는 보존 책임이 다릅니다.
실무에서는 ‘누가 다시 찾아야 하는가’가 빠른 기준이 됩니다. 앱 기능만 다시 읽으면 되는 파일은 앱 전용 후보입니다. 사용자가 파일 관리자나 다른 앱에서 관리해야 하는 결과물은 공유 저장소·문서 선택기 후보입니다. 구조화된 설정값이나 여러 항목을 조회하는 데이터는 파일로 뭉치기보다 별도의 저장 방식을 검토해야 합니다. 위치를 정하기 전에 이 질문을 기록하면 불필요한 넓은 저장소 접근을 요구하는 설계를 줄일 수 있습니다.
기준 2: ‘저장’ 버튼은 앱 폴더 복사가 아니라 사용자의 위치 선택까지 포함합니다
Android의 Storage Access Framework는 시스템 파일 선택기를 통해 사용자가 문서 제공자와 특정 위치·문서를 고르는 방식입니다. 새 파일을 만들 때는 ACTION_CREATE_DOCUMENT를 사용해 저장 위치를 고르게 할 수 있습니다.
이 흐름에서는 앱이 고른 위치가 아니라 사용자가 선택한 URI에 읽기·쓰기 권한을 받습니다. 문서 공유가 필요한 MVP라면 앱 화면의 ‘PDF 만들기’와 시스템 선택기의 ‘저장 위치 확정’을 별도 상태로 남기세요.
같은 이름의 파일이 이미 있다고 해서 시스템 선택기가 기존 파일을 덮어쓴다고 가정하면 안 됩니다. Android 문서는 새 문서 만들기가 기존 파일을 덮어쓰지 않으며, 이름이 같으면 괄호와 번호를 붙여 저장한다고 안내합니다. 따라서 완료 화면에는 앱이 제안한 파일명과 사용자가 실제 선택한 URI·표시 이름을 구분해 기록하고, 같은 이름을 다시 생성했을 때의 안내도 QA에 넣는 편이 안전합니다.
기준 3: 다시 열기 기능은 URI 접근 지속 여부와 파일 존재 여부를 별도로 봅니다
사용자가 고른 문서에 대한 기본 URI 권한은 기기 재시작 전까지 유지됩니다. 앱이 재시작 뒤에도 같은 문서를 다시 열어야 한다면, 시스템이 제공하는 지속 가능한 URI 권한을 가져오는 흐름을 검토할 수 있습니다. 하지만 지속 권한을 얻었다고 파일이 영구히 존재한다는 뜻은 아닙니다. 문서가 이동되거나 삭제되면 앱은 다시 권한을 요청해야 할 수 있습니다.
그래서 ‘내보낸 파일 다시 열기’는 저장 성공 여부 하나로 끝내면 안 됩니다. 앱이 저장한 URI, 마지막으로 확인한 시점, 현재 열기 가능 여부, 사용자가 파일을 옮기거나 지웠을 때의 안내를 각각 나누세요.
원격 문서 제공자는 파일 크기 같은 메타데이터를 즉시 알 수 없을 수도 있으므로, 화면에 값이 없다고 실패라고 단정하지 않는 처리도 필요합니다. 이는 Android가 보장하는 UI 규칙이 아니라, 문서 접근 실패를 정확히 설명하기 위한 편집·제품 판단입니다.
기준 4: 폴더 전체 접근은 파일 하나를 고르는 일과 다른 권한입니다
여러 파일을 반복해서 다루는 파일 관리·미디어 제작 기능은 사용자가 특정 디렉터리 트리를 선택하도록 하는 ACTION_OPEN_DOCUMENT_TREE를 검토할 수 있습니다. 이때 앱이 접근할 수 있는 범위는 사용자가 선택한 디렉터리와 하위 항목으로 제한됩니다. 파일 하나를 내보내는 MVP에 곧바로 폴더 전체 접근을 붙일 이유는 아닙니다.
또한 Android 11 이상에서는 이 방식으로 내부 저장소 루트, 신뢰할 수 있는 SD 카드 루트, Download 디렉터리 같은 일부 위치를 선택하도록 요청할 수 없습니다. 따라서 “다운로드 폴더에 항상 저장한다” 또는 “모든 파일을 관리한다”는 약속을 요구사항에 먼저 넣기보다, 실제로 필요한 파일 수·반복 작업·사용자 선택 범위를 적어 보세요. 기능이 문서 한 건 내보내기라면 개별 새 문서 생성 흐름이 더 작은 권한 경계가 될 수 있습니다.
기준 5: QA는 생성·선택·재접근·삭제를 같은 성공으로 묶지 않습니다
파일 기능의 테스트 결과를 “내 폰에서 PDF가 열렸다” 한 줄로 남기지 마세요. 앱 전용 파일 생성, 시스템 선택기 취소, 사용자 위치 선택, 같은 파일명, 앱 재시작 뒤 다시 열기, 외부에서 이동·삭제한 뒤 안내를 나눠 확인해야 합니다. 앱 전용 파일은 앱 제거 시 함께 삭제되고, 사용자가 선택한 공유 문서는 앱 제거 뒤에도 남을 수 있으므로 제거·재설치 검증도 같은 시나리오가 아닙니다.
판단 항목 | 최소 기록 | 확인 질문 |
|---|---|---|
파일 목적 | 임시·앱 보관·사용자 보관 | 누가 어디에서 다시 찾아야 하나? |
저장 위치 | 앱 전용 또는 사용자 선택 URI | ‘저장’이 위치 선택 완료까지 포함하는가? |
파일명 | 제안명·실제 표시명·MIME 유형 | 같은 이름일 때 덮어쓰기를 가정하지 않는가? |
재접근 | URI 권한·마지막 확인·실패 안내 | 재시작·이동·삭제 뒤를 구분하는가? |
정리 | 임시 파일 삭제 기준·앱 제거 시 동작 | 사용자 보관 파일을 앱이 임의로 지우지 않는가? |
출시 전 한 장 체크리스트
각 파일이 앱 기능용인지, 사용자가 보관할 결과물인지 명시했는가?
사용자 보관 파일은 시스템 선택기에서 위치를 확정하는 흐름을 검토했는가?
같은 이름 생성이 기존 파일 덮어쓰기라는 가정을 요구사항에서 제거했는가?
재시작 뒤 다시 열기와 외부 이동·삭제 뒤 안내를 별도 QA로 뒀는가?
폴더 전체 접근이 정말 필요한지, 문서 한 건 선택으로 충분한지 확인했는가?
파일 내보내기는 버튼 하나가 아니라 보관 책임을 어디에 둘지 정하는 흐름입니다. 유인어스는 민간 사업 지원 서비스이며, 이 글은 특정 앱의 저장 보안, 파일 보존, 개인정보 적합성, 스토어 심사 또는 사업 결과를 보장하지 않습니다. 실제 제품의 파일 종류, 대상 Android 버전, 문서 제공자와 최신 Android 공식 문서를 기준으로 범위를 결정하세요.
자주 묻는 질문
앱에서 만든 PDF는 Download 폴더에만 저장해야 하나요?
그렇지 않습니다. 앱 기능만 쓰는 파일은 앱 전용 저장소 후보가 될 수 있고, 사용자가 보관할 문서는 Storage Access Framework로 사용자가 선택한 위치에 새 문서를 만들 수 있습니다. 파일 목적과 사용자가 다시 찾을 장소를 먼저 정하세요.
ACTION_CREATE_DOCUMENT로 같은 이름을 저장하면 기존 파일이 바뀌나요?
Android 문서는 이 동작이 기존 파일을 덮어쓰지 않는다고 안내합니다. 같은 이름이면 시스템이 괄호와 번호를 붙여 새 파일을 만들 수 있으므로, 앱이 제안한 이름과 실제 결과를 구분해 안내하세요.
사용자가 고른 문서는 앱을 껐다 켜도 다시 열 수 있나요?
기본 URI 권한과 재시작 뒤 지속 접근은 구분해야 합니다. 앱은 지속 가능한 URI 권한을 검토할 수 있지만, 사용자가 문서를 옮기거나 삭제하면 다시 권한을 요청해야 할 수 있습니다.
문서 한 개를 내보내는데 폴더 전체 권한이 필요한가요?
대개는 아닙니다. 폴더 트리 접근은 여러 파일을 다루는 별도 사용 사례입니다. 한 건의 결과물을 저장하는 MVP라면 사용자가 새 문서의 위치를 고르는 흐름으로 필요한 범위를 더 작게 둘 수 있는지 확인하세요.
확인한 공식 출처
Android Developers · Data and file storage overview — 2026-09-18 확인
Android Developers · Access documents and other files from shared storage — 2026-09-18 확인
Android Developers · Access app-specific files — 2026-09-18 확인