현장에서 촬영한 대용량 파일을 올리다 연결이 끊기면 처음부터 다시 보내야 할까요? 파일이 클수록 반복 업로드는 시간과 데이터 사용량을 늘립니다. 청크별 진행 위치를 확인하고 이어 보내는 경로를 설계할 수 있습니다.
업로드를 작은 단위로 나눈다
파일 전체를 한 요청으로 보내는 대신 여러 청크로 나누고 업로드 식별자와 현재 위치를 서버에 기록합니다. 연결이 끊기면 서버가 확인한 위치부터 다시 보냅니다.
클라이언트가 보냈다고 생각하는 위치와 서버가 실제 저장한 위치는 다를 수 있습니다. 재개 시 서버 상태를 먼저 조회하고 일치하지 않는 청크를 안전하게 재전송합니다.
파일의 정체성을 확인한다
같은 이름의 다른 파일을 이어 붙이면 손상된 결과가 나옵니다. 파일 크기, 해시 또는 선택한 파일의 안정된 식별 정보를 확인합니다.
계정이 바뀌거나 업로드 권한이 회수된 경우 오래된 업로드 ID를 그대로 사용할 수 없어야 합니다. 이어 보내기도 새로운 접근 요청입니다.
완료와 사용 가능을 구분한다
마지막 청크가 도착해도 합치기와 무결성 검사, 악성 파일 검사, 업무 등록이 남을 수 있습니다. 화면에는 전송 완료와 처리 완료를 다른 상태로 보여 줍니다.
부분 파일을 완성본처럼 다운로드하게 하지 않습니다. 보관 기한이 지난 미완료 청크는 별도 정리 정책을 적용합니다.
가상 사례: 80%에서 끊긴 점검 영상
점검 영상의 대부분을 보낸 뒤 통신이 끊겼다고 가정해 봅시다. 재개를 지원하면 서버가 확인한 마지막 위치 뒤부터 보낼 수 있습니다.
서버가 청크 일부만 저장했다면 클라이언트가 가진 80% 표시를 믿지 않습니다. 이 수치는 설명을 위한 가상 예시입니다.
실패 조건을 시험한다
같은 청크의 중복 전송, 순서 변경, 앱 종료, 저장 공간 부족, 서버 재시작을 시험합니다. 완성 파일의 크기와 체크섬을 확인합니다.
업로드가 끝난 뒤 사용자가 어느 기록에 파일을 붙였는지 추적할 수 있어야 합니다. 재개 기능은 전송 기술과 업무 연결을 함께 완성해야 합니다.
현장에 적용할 때의 순서
- 업로드 ID와 서버 위치를 기록한다
- 재개 때 서버 상태를 먼저 조회한다
- 완성 파일의 무결성을 검증한다
주의할 실패: 클라이언트의 진행 표시만 믿고 청크를 이어 보내면 파일 중간이 비거나 중복될 수 있다.
관찰할 지표: 재개 성공률과 검증 실패·미완료 청크를 추적한다.
적용 전 체크리스트
- 재개 시 서버가 확인한 위치를 기준으로 삼는가
- 업로드 소유자와 파일 정체성을 재검증하는가
- 전송 완료와 검증 완료를 구분하는가
참고 자료
tus Resumable Upload Protocol. tus 프로토콜은 업로드 재개와 위치 확인 방식을 설명합니다. 파일 검사와 업무 등록은 별도 애플리케이션 절차입니다.
이미지와 도식은 이해를 돕기 위한 개념 시각화입니다. 특정 고객의 실제 설비·데이터·화면을 재현한 것이 아닙니다.
#이어올리기 #대용량업로드 #청크업로드 #모바일앱 #현장앱 #파일무결성 #네트워크복구 #앱아키텍처 #재시도 #업무시스템
