현장 사진을 오프라인에서 잃지 않고 업로드하며 재시도 중 중복도 막는 저장·동기화 구조입니다.
왜 이 문제가 생길까
지하 설비실에서 사진을 찍은 직후 앱이 종료될 수 있습니다. 네트워크가 돌아왔을 때 같은 사진을 여러 번 전송할 수도 있습니다. '나중에 다시 시도' 버튼만 있는 앱은 사용자가 어떤 증거가 서버에 도착했는지 알기 어렵습니다.
시스템은 무엇을 구분해야 할까
촬영 직후 파일을 안정적인 앱 저장소에 먼저 기록하고, 작업 ID·로컬 파일 ID·해시·업로드 상태를 영속 큐에 남깁니다. 상태는 대기·전송 중·서버 확인·실패로 분리합니다. 서버에는 클라이언트가 만든 멱등성 키를 보내 같은 파일의 재시도가 중복 레코드를 만들지 않게 합니다. 파일 본문 전송과 최종 업무 제출의 관계도 정해야 합니다. 모든 사진이 도착하기 전에는 제출을 막을지, 임시 제출 후 보완할지 업무 위험도에 따라 선택합니다.
현장에서 적용하면
점검자가 사진 세 장을 찍고 통신이 끊겼습니다. 앱은 세 장을 기기 안에 보존하고 업로드 대기 상태를 보여 줍니다. 재연결 시 두 장이 성공하고 마지막 한 장이 시간 초과됐다면 마지막 장만 재시도합니다. 서버 응답을 받기 전에 연결이 끊겨도 같은 멱등성 키로 확인하므로 이중 등록되지 않습니다.
도입할 때 놓치기 쉬운 점
운영체제가 백그라운드 작업 시간을 제한할 수 있으므로 '항상 즉시 업로드'를 약속하면 안 됩니다. 저장 공간 부족, 사용자의 로그아웃, 사진 삭제, 기기 교체 시 대기 파일이 어떻게 되는지도 설명해야 합니다. 민감한 현장 사진은 로컬 암호화·보관 기간·권한도 함께 설계해야 합니다.
시작 전 점검할 세 가지
- 앱 강제 종료 후에도 업로드 큐가 남는가
- 중복 재시도에 같은 멱등성 키를 쓰는가
- 사용자가 서버 확인 상태를 사진별로 볼 수 있는가
참고 자료: Android WorkManager의 영속 작업 가이드
#오프라인앱 #현장사진 #업로드큐 #모바일동기화 #멱등성 #재시도 #앱아키텍처 #현장점검 #데이터보존 #모바일개발
