앱 MVP 미디어 URI: 업로드·재시도·재선택을 나누는 5가지 기준
사진이나 영상을 선택한 뒤 업로드가 실패했을 때, 앱이 같은 파일을 다시 읽을 수 있을까요? 이 질문은 ‘사진 선택 기능을 넣을지’와 다른 문제입니다. 선택 결과로 받은 URI가 언제까지 유효한지, 백그라운드 업로드에 어떤 접근이 필요한지, 원본이 이동·삭제됐을 때 무엇을 사용자에게 다시 물을지까지 정해야 실제 MVP 흐름이 끊기지 않습니다.
먼저 답하면, 미디어 URI는 파일 경로처럼 영구적인 식별자로 가정하지 말고 선택 직후 접근·필요한 경우의 지속 접근·업로드 결과·재시도 조건·재선택 안내를 각각 기록하는 편이 안전합니다. Android의 시스템 포토 피커는 선택한 사진·영상에 범위를 제한해 접근을 주지만, 장기 작업의 접근 방식과 원본의 현재 상태까지 보장하는 것은 아닙니다.
이 글은 Android 앱 MVP에서 이미 선택된 미디어를 업로드하는 흐름을 다룹니다. 시스템 피커와 전체 미디어 권한 중 무엇을 선택할지는 앱 MVP 사진 선택 기준에서, 문서 첨부의 파일·폴더 접근 판단은 앱 MVP 문서 첨부 기준에서 별도로 확인하세요.
1. URI를 ‘내 파일’이 아니라 선택 결과로 취급합니다
Android 공식 문서는 시스템 포토 피커가 사용자가 고른 사진과 영상에만 앱 접근을 부여하는 방식을 설명합니다. 따라서 앱은 URI를 받은 직후 콘텐츠를 읽을 수 있는지 확인하되, URI 문자열만 서버에 보관하고 나중에 항상 같은 원본을 열 수 있다고 전제하면 안 됩니다. 업로드할 데이터, 선택 시각, 콘텐츠 유형, 처리 상태를 별도 기록해 두세요.
선택 직후: URI를 받아 읽기 가능 여부와 파일 처리 시작을 확인합니다.
업로드 전: 크기·형식·사용자에게 보여 줄 미리보기 규칙을 제품 요구와 맞춥니다.
업로드 중: 네트워크 실패와 접근 실패를 같은 오류 문구로 합치지 않습니다.
업로드 후: 서버에 저장된 결과 식별자와 로컬 선택 URI를 구분합니다.
이 구분은 개인정보나 원본 파일을 더 오래 보관하라는 뜻이 아닙니다. 반대로, 어떤 단계에서 어떤 접근이 필요한지 줄여 기록하려는 기준입니다. 서비스가 실제로 어떤 보관·삭제 정책을 적용하는지는 개인정보 처리방침과 서버 설계에서 별도로 확인해야 합니다.
2. 임시 접근과 장기 작업을 같은 요구사항으로 묶지 않습니다
Android의 포토 피커 문서는 기본 접근이 기기 재시작 또는 앱이 중단될 때까지일 수 있으며, 대용량 파일의 백그라운드 업로드처럼 더 긴 작업에는 지속 접근이 필요할 수 있다고 안내합니다. 이때 Android가 제공하는 범위 안에서 takePersistableUriPermission() 사용 여부를 검토할 수 있습니다. 다만 ‘지속 접근을 요청했다’는 기록이 원본이 계속 존재한다는 보장은 아닙니다.
결정 질문 | MVP에서 남길 기록 | 피해야 할 가정 |
|---|---|---|
언제 처리할까? | 선택 직후 처리인지, 나중 작업인지 | 모든 URI가 다음 실행에도 열린다는 가정 |
무엇을 저장할까? | 업로드 결과 식별자와 처리 상태 | URI만 있으면 서버 원본도 복구된다는 가정 |
실패 원인은? | 네트워크·서버·접근·원본 변경의 구분 | 모든 실패를 ‘다시 시도’로 처리하는 일 |
사용자 행동은? | 자동 재시도인지 재선택인지의 조건 | 원본 없이 무한 재시도를 하는 일 |
문서 선택에 쓰이는 Storage Access Framework도 지속 URI 권한을 설명하지만, 연결된 문서가 이동하거나 삭제되면 접근을 유지하지 못할 수 있다고 명시합니다. 그래서 장기 재처리가 제품의 핵심 요구라면, 선택권한의 수명과 서버에 정상 저장된 결과의 수명을 분리해 설계해야 합니다.
‘다시 시도’는 같은 바이트를 다시 전송할 수 있을 때의 행동입니다. 앱이 더 이상 원본을 읽지 못한다면, 정확한 다음 행동은 재시도가 아니라 사용자의 재선택입니다.
3. 업로드 상태를 사용자 행동과 연결합니다
동일한 ‘업로드 실패’ 화면이라도 다음 행동은 원인에 따라 달라집니다. 네트워크 연결이 끊긴 상태라면 이전에 읽은 데이터로 재시도를 제안할 수 있습니다. 반면 URI 접근이 거부되었거나 제공자가 원본을 더 이상 제공하지 않는다면, 다시 선택하도록 안내하는 편이 정확합니다. 서버가 이미 파일을 받았지만 응답이 끊긴 경우에는 새 업로드를 시작하기 전에 서버 처리 상태를 조회할 수 있는 설계가 중복을 줄입니다.
선택 완료: URI와 사용자 선택 사실을 기록하고 즉시 읽기 검사를 합니다.
전송 시작: 재시도 가능한 전송 단위와 취소 행동을 제품에 맞춰 정합니다.
결과 확인: 서버가 받은 파일의 상태와 화면 표시를 분리해 확인합니다.
실패 분류: 네트워크, 서버 응답, 형식 검증, URI 접근 실패를 나눕니다.
다음 행동: 재시도 가능한 경우만 재시도하고, 그렇지 않으면 재선택을 제안합니다.
여기서 파일명·EXIF·원본 경로처럼 서비스에 필요하지 않은 정보를 오류 분석에 복사하지 않도록 주의하세요. 사용자가 선택한 미디어는 민감할 수 있으므로, 운영 기록에는 오류 범주와 처리 상태처럼 최소한의 진단 정보만 남기는 편이 좋습니다.
4. 원본 변경과 앱 재시작을 별도 QA 항목으로 둡니다
URI 흐름은 정상 업로드 한 번으로 검수하기 어렵습니다. Android 공식 문서는 지속 권한을 얻었더라도 연결된 문서가 이동 또는 삭제되면 URI 접근이 유지되지 않을 수 있다고 설명합니다. MVP QA에는 적어도 앱 재시작 뒤 처리, 네트워크 단절 뒤 재개, 사용자가 원본을 지운 경우, 다른 제공자에서 선택한 경우, 서버 응답 지연을 포함하세요. 각 경우에 자동 재시도·상태 조회·재선택 중 어느 행동을 보일지 사전에 정합니다.
앱을 종료·재실행한 뒤 미완료 업로드가 어떤 상태로 보이는가?
원본을 이동·삭제했을 때 사용자가 이해할 수 있는 재선택 안내가 보이는가?
서버가 처리 완료했지만 앱이 응답을 받지 못했을 때 중복 전송을 줄이는가?
선택한 미디어의 종류·크기·제공자 차이가 오류 화면을 깨뜨리지 않는가?
이 QA는 특정 기기나 스토어 심사 결과를 보장하지 않습니다. 실제 지원 범위는 대상 Android 버전, 선택 방식, 네트워크 정책, 서버 저장 구조를 포함한 현재 빌드에서 확인해야 합니다.
5. 제품 요구를 한 장의 ‘수명 표’로 합의합니다
MVP 단계에서는 복잡한 파일 동기화보다, 어떤 순간에 사용자 선택이 다시 필요한지를 팀이 같은 기준으로 이해하는 편이 먼저입니다. 화면 또는 기능별로 선택 방식, 업로드 시작 조건, 접근을 더 오래 유지해야 하는 이유, 서버 완료 확인, 재시도 한계, 재선택 문구, 재검토 조건을 표로 남겨 두세요. SDK·OS·업로드 방식이 바뀌면 그 표를 다시 검토하면 됩니다.
핵심은 URI를 ‘한 번 받아 두면 계속 쓸 수 있는 파일 주소’로 다루지 않는 것입니다. 선택 직후의 제한된 접근, 정상 저장된 서버 결과, 재시도 가능 여부, 다시 선택해야 하는 조건을 분리하면 사용자에게 잘못된 복구 약속을 하지 않고 MVP의 실패 흐름을 더 정확히 만들 수 있습니다. 유인어스는 민간 사업 지원 서비스이며, 이 글은 특정 앱의 보안 적합성·권한 승인·스토어 심사 통과를 보장하지 않습니다.
자주 묻는 질문
사진을 선택한 URI는 앱을 다시 열어도 항상 사용할 수 있나요?
항상 그렇다고 가정하면 안 됩니다. Android 문서는 기본 접근의 수명과 지속 접근 방식을 별도로 설명합니다. 실제 선택 방식과 장기 작업 필요성을 기준으로 확인하고, 접근하지 못하면 재선택 흐름을 준비하세요.
업로드가 실패하면 무조건 자동 재시도하면 되나요?
아닙니다. 네트워크처럼 같은 데이터를 다시 전송할 수 있는 실패와 URI 접근 실패·원본 변경은 다릅니다. 원본을 읽을 수 없으면 재시도보다 재선택이 정확한 다음 행동일 수 있습니다.
지속 URI 권한을 얻으면 원본 삭제 뒤에도 접근할 수 있나요?
아닙니다. Android의 문서 안내는 지속 권한을 얻었더라도 연결된 문서가 이동하거나 삭제되면 접근이 유지되지 않을 수 있다고 설명합니다. 원본 존재와 권한 수명을 분리해 확인하세요.
서버 업로드가 끝났는지 앱 화면만으로 판단해도 되나요?
응답 지연이나 중단이 있을 수 있으므로, 제품 요구에 맞게 서버 처리 상태와 화면 표시를 구분하는 편이 좋습니다. 실제 저장·삭제·중복 방지 방식은 서버 설계와 함께 검증하세요.
확인한 공식 출처
Android Developers · Photo picker — 2026-09-19 확인
Android Developers · Access documents and other files from shared storage — 2026-09-19 확인
Android Developers · Minimize your permission requests — 2026-09-19 확인