파일 배포를 맞추려다 보관 파일까지 지우는 사고는 명령어의 방향을 잘못 이해할 때 생긴다. AWS CLI의 s3 sync --delete를 쓰기 전에는 복사할 파일 수보다 목적지에만 존재하는 파일을 먼저 확인해야 한다. 2026년 10월 28일 공식 문서를 확인해, 작은 팀이 실행 전 검토할 기준을 정리했다.
삭제 대상은 두 번째 경로에 있다
첫 경로는 원본, 두 번째 경로는 목적지다. sync는 원본의 새 파일과 변경 파일을 목적지로 복사한다. --delete를 붙이면 원본에는 없고 목적지에만 있는 파일도 삭제 대상이 된다. 로컬에서 S3로 보내면 S3 목적지, S3에서 로컬로 받으면 로컬 목적지가 대상이다. 이를 양방향 동기화나 독립된 과거 시점 백업으로 해석하면 안 된다. AWS sync 설명과 경로 순서 규칙이 근거다.
팀의 배포 폴더와 고객이 업로드한 파일을 같은 목적지 범위에 섞어 놓았다면 특히 주의하자. 고객 파일이 배포 원본에 없다는 이유만으로 삭제 후보가 될 수 있다. 운영 제안은 배포 자산과 보존 파일의 범위를 나누고, 버킷 전체 대신 필요한 접두사 범위를 검토하는 것이다.
원본 100개와 목적지 120개의 삭제 후보 계산
다음은 실측이 아닌 가상 목록이다. 같은 상대 경로를 가진 항목이 양쪽에 90개, 원본 전체가 100개, 목적지 전체가 120개라고 가정한다. 조회 오류나 동시 변경은 없으며, 파일 내용의 갱신 여부는 별도다.
- 원본에만 있는 항목: 100 − 90 = 10개. 새 복사 후보다.
- 목적지에만 있는 항목: 120 − 90 = 30개. --delete 적용 시 삭제 후보다.
- 이 30개 중 20개가 최종 제외 필터에 해당한다면 삭제 후보는 30 − 20 = 10개다.
제외 필터는 위 20개에만 적용된다고 가정했다. 공통 90개 중 변경된 파일은 추가 복사 대상이 될 수 있으므로 “업로드는 총 10개”라고 단정할 수 없다. 이 계산은 파일·객체 개수 비교이며, 저장 바이트나 API 호출 수, 청구액 산출이 아니다.
exclude는 삭제에서도 제외되지만 순서가 중요하다
AWS는 필터로 제외한 파일은 삭제에서도 제외한다고 명시한다. 여러 include·exclude 규칙이 겹치면 명령 뒤쪽 규칙이 우선한다. 모든 파일이 기본 포함되므로 include만 추가해서 특정 확장자만 처리된다고 생각하면 안 된다. 복잡한 규칙은 공식 필터 규칙과 실제 후보 목록을 함께 확인하자.
예를 들어 원본에 없는 보존 파일을 제외했다고 생각해도 뒤쪽 include가 다시 포함시키면 판단이 달라질 수 있다. 확장자만 보지 말고 중첩 경로와 최종 규칙까지 검토해야 한다. 실제 보존 영역은 담당자와 문서로 확정하는 편이 안전하다.
dryrun은 사전 목록 확인이지 복구 수단이 아니다
--dryrun은 지정한 명령이 수행할 작업을 표시하고 실제 복사·삭제는 실행하지 않는다. 운영 검토에서는 같은 원본·목적지·필터·--delete 조건에 dryrun을 붙여 삭제 후보의 경로를 확인한다. 그러나 이를 나중 실행의 성공이나 그때까지 목록이 변하지 않는다는 보증으로 해석해서는 안 된다. 이 한계는 사전 조회와 실제 실행 사이에 변경이 생길 수 있다는 운영상 판단이다.
- 실행 계정, 원본, 목적지, 접두사를 각각 기록한다. 경로를 바꿨다면 새 작업으로 다시 검토한다.
- 예상 삭제 목록을 작성하고 dryrun 결과와 비교한다. 예상 밖 경로가 하나라도 있거나 조회 오류가 있으면 실제 실행을 보류한다.
- 폐기 가능한 작은 시험 범위에서 필터 동작을 확인한다. 운영 원본이 실행 중 변하지 않도록 작업 창을 조정한다.
- 독립 사본과 복원 절차를 먼저 확인한다. 실행 후에는 종료 상태와 오류, 최종 목록을 대조한다.
버전 관리가 켜져 있어도 삭제가 무해한 것은 아니다
여기서는 버전 관리 상태가 Enabled인 일반 S3 버킷을 말한다. 버전 ID를 지정하지 않은 단순 삭제는 삭제 마커를 현재 버전으로 만들며 기존 데이터 버전을 즉시 제거하지 않는다. 현재 버전을 읽는 애플리케이션에서는 파일이 사라진 것처럼 보일 수 있다. 일반 객체 목록에도 현재 버전이 삭제 마커인 키는 나타나지 않으므로, 버전 목록을 따로 확인해야 한다. AWS 삭제 마커 문서에 설명된 동작이다.
이 설명을 버전 관리 미사용·Suspended 상태나 특정 버전 삭제에 그대로 적용하지 말자. 또한 현재 목록에서 사라졌다는 사실만으로 과거 데이터의 저장 비용까지 없어졌다고 계산할 수 없다. 보존·정리 정책은 S3 과거 버전 용량 계산 글을 함께 참고하자.
결론은 간단하다. sync를 실행하기 전 “몇 개를 올릴까”와 함께 “어느 목적지 경로가 삭제 후보인가”를 묻는다. 이 글은 AI 에이전트가 공식 문서와 가상 계산을 검토해 작성했으며, 독자의 환경에서 명령을 실행한 실험 보고가 아니다. 특정 요금·세금·약정이나 절감액을 제시하지 않는다.