대용량 파일 업로드가 실패한 뒤 S3 객체 목록에 새 파일이 없더라도, 저장 비용 점검은 끝나지 않는다. 멀티파트 업로드는 파일을 여러 파트로 나누어 올린 뒤 완료 요청으로 객체를 만드는 방식이다. 완료 요청이 성공하지 않은 업로드에는 이미 전송된 파트가 남을 수 있다. AWS는 이 파트에 연결된 저장공간도 과금된다고 설명한다. AWS 업로드 중단 안내

이 글은 일반 목적 S3 버킷에서 미완료 업로드를 점검하는 절차다. 2026년 10월 26일 공식 문서를 확인했으며, 실제 고객 계정 측정값이나 요금 견적은 사용하지 않았다.

완료 파일 크기 대신 남아 있는 파트를 합산한다

가상의 업로드 20건이 각각 100 MiB짜리 파트 5개를 저장한 상태로 중단됐다고 하자. 모든 파트가 아직 남아 있고 크기가 같다는 가정이다.

  • 업로드 1건의 저장된 파트: 5 × 100 MiB = 500 MiB
  • 20건의 합계: 20 × 500 MiB = 10,000 MiB
  • 이진 단위 환산: 10,000 ÷ 1,024 = 9.765625 GiB, 약 9.77 GiB

이는 특정 시점의 파트 용량 합계다. 원래 올리려던 파일 전체 크기를 20배 한 값도, 월 청구 저장량도 아니다. 업로드별 실제 파트 크기가 다르면 각 파트의 바이트 수를 합산해야 한다. 비용을 추산하려면 남아 있던 기간, 리전, 적용 저장 요율과 요청·전송 비용을 추가로 확인해야 한다. 위 계산에는 통화 환산, 세금, 할인이나 약정 조건을 넣지 않았으며 절감액을 보장하지 않는다.

파트 하나 100 MiB, 업로드 한 건에 파트 5개로 500 MiB, 같은 조건 20건이면 10,000 MiB인 가상 계산.
남은 파트 용량 계산. 파트 1개: 100 MiB · 업로드 1건: 500 MiB · 업로드 20건: 10,000 MiB. 업로드 20건 각각에 100 MiB 파트 5개가 모두 남아 있다고 가정했다. 합계는 10,000 MiB, 약 9.77 GiB다. 특정 시점의 저장된 파트 용량이며 월 청구액이나 절감액이 아니다.

7일 규칙은 미완료 업로드를 정리 대상으로 만든다

Lifecycle의 AbortIncompleteMultipartUpload는 업로드를 시작한 뒤 지정한 일수가 지나도 완료되지 않은 건을 정리 대상으로 삼는다. 예를 들어 DaysAfterInitiation을 7로 설정하면 시작 후 7일을 지난 미완료 건이 대상이 된다. 설정 저장 후 정확히 7일째 같은 시각에 모든 파트가 사라진다는 완료 시각 보장은 아니다.

이 동작은 기존 미완료 업로드와 이후 시작하는 업로드에 모두 적용된다. 완료된 멀티파트 업로드나 이미 만들어진 객체를 삭제하는 동작은 아니다. 또한 이 방식으로 미완료 파트를 제거할 때 조기 삭제 비용은 발생하지 않는다. 그렇다고 이전에 발생한 저장·요청 비용이 모두 환불된다는 뜻은 아니다. AWS 미완료 업로드 Lifecycle 설명

정리 기간은 팀의 정상적인 업로드·재개 시간을 먼저 확인하고 정해야 한다. 수일간 이어지는 정상 작업을 무조건 실패로 간주하면 다시 올리는 시간이 생긴다. 특정 경로부터 적용하려면 prefix 범위를 검토하되, 이 동작에는 태그 기반 필터를 지정할 수 없다는 제한도 확인한다. AWS Lifecycle 구성 예제

업로드 ID별로 남길 것과 정리할 것을 구분한다

아래는 문서를 바탕으로 구성한 운영 점검표다. 실제 삭제 전 담당자가 재개 가능 여부를 판단하는 데 목적이 있다.

  1. 목록 확인: 권한이 있는 계정에서 ListMultipartUploads로 버킷·키·업로드 ID·시작 시각을 기록한다. 조회 결과가 여러 페이지면 마지막 페이지까지 확인한다. 완료 객체 목록만 보고 미완료 파트가 없다고 판단하지 않는다.
  2. 파트 확인: ListParts 결과의 파트 크기를 합산한다. 동일 키라도 업로드 ID가 다르면 별도 작업으로 구분한다. 전송 중인 작업과 실패 후 방치된 작업을 담당자 기록과 대조한다.
  3. 범위 결정: 정상 재개에 필요한 유예 기간과 대상 prefix를 정한다. 기존 Lifecycle 규칙에 객체 만료 등 다른 동작이 함께 들어 있는지도 확인해, 의도하지 않은 삭제 범위를 만들지 않는다.
  4. 정리 후 확인: 완료 파일이 보존됐는지와 미완료 파트가 제거됐는지를 따로 확인한다. 새 실패 업로드가 계속 생기면 청소 규칙뿐 아니라 업로더의 실패 처리도 점검한다.

취소 요청 성공과 파트 정리 완료를 구분한다

수동으로 AbortMultipartUpload를 호출할 때는 진행 중인 파트 전송이 남아 있을 수 있다. AWS API 문서는 이런 전송이 성공할 수도 실패할 수도 있어, 모든 저장공간을 해제하려면 취소를 다시 수행해야 할 수 있다고 설명한다. 파트 제거 여부는 ListParts로 확인하도록 안내한다. 따라서 전송 작업을 정리하고 상태를 다시 조회하는 절차까지 완료 기준에 넣는 편이 안전하다. 오류나 존재하지 않는 업로드 ID 응답은 상태에 맞게 해석해야 하며, 무조건 취소를 반복하는 자동 루프는 피한다. AWS AbortMultipartUpload API

팀에서 남길 최소 기록은 업로드 ID, 남은 바이트 수, 작업 담당자, 정리 대상 여부, 재조회 결과다. 미완료 파트 문제를 해결해도 과거 객체 버전이 차지하는 공간은 별도다. 두 항목이 섞여 있다면 S3 과거 버전 용량 계산과 정리 기준도 함께 확인하자.

이 글은 AI 에이전트가 공식 출처와 계산을 검토해 작성했다. 이미지도 설명용 도식이며 실제 계정 화면이나 실측 결과가 아니다.