S3에서 파일을 지웠는데 버킷 삭제는 여전히 실패한다. '파일 하나 삭제'와 '버킷 비우기', '버킷 자체 삭제'를 같은 동작으로 생각하면 당황스럽다. 버킷은 객체를 담는 공간이고, 객체는 그 안의 파일에 해당한다. 버킷을 없애려면 먼저 안에 남은 것을 확인해야 한다.
S3 객체 삭제와 버킷 삭제는 무엇이 다를까?
예를 들어 demo-assets 버킷에 index.html과 app.css가 있다고 하자. index.html만 삭제하면 버킷과 app.css는 남는다. '비우기'는 버킷 안의 객체를 대상으로 하고, '버킷 삭제'는 그 뒤에 담는 공간을 제거한다.
| 단계 | 버킷 안의 객체 | 버킷 |
|---|---|---|
| 시작 | index.html, app.css | 존재 |
index.html 삭제 | app.css | 존재 |
| 버킷 비우기 | 없음 | 존재 |
| 버킷 삭제 | 없음 | 없음 |
아래 그림처럼 '객체 0개'와 '버킷 없음'은 서로 다른 결과다. 삭제 버튼 하나로 두 단계를 건너뛰지는 못한다.
비웠는데도 버킷 삭제가 실패하면 어디를 볼까?
먼저 삭제하려는 버킷 이름과 계정을 다시 확인한다. 비슷한 이름의 테스트 버킷을 고른 줄 알았는데 실제 서비스 자산을 담은 버킷이면 되돌리기 어려울 수 있다. 다음으로 객체 목록을 새로 고침해 남은 객체가 있는지, 비우기 작업에서 실패한 객체가 없는지 본다. 다른 업로드 작업이 진행 중이면 확인 사이에 객체가 다시 들어올 수도 있다.
버저닝을 켠 버킷은 눈에 보이는 현재 객체만 없어도 이전 버전과 삭제 마커가 남을 수 있다. 이때 일반적인 객체 삭제를 반복하는 것만으로는 버킷을 비우지 못한다. 콘솔의 비우기 동작이 무엇을 제거하는지, 보존해야 할 버전이 있는지 먼저 확인하자. AWS의 버킷 비우기 안내는 버전과 삭제 마커도 버킷 삭제 전에 제거해야 한다고 설명한다.
삭제 전에 연결된 서비스를 어떻게 확인할까?
버킷이 정적 웹 호스팅이나 다른 서비스의 원본이면 객체를 지우는 순간 사용자 요청이 실패할 수 있다. 먼저 어떤 서비스가 이 버킷을 읽고 쓰는지 확인하고, 필요한 데이터를 별도로 보관한 뒤, 연결을 전환하거나 중단할 순서를 정한다. 버킷 비우기는 시험 삼아 눌러 볼 버튼이 아니다.
삭제가 실패했을 때는 '권한이 없나?'만 보지 말고, 대상 버킷 → 남은 객체·버전 → 비우기 실패 내역 → 계속 쓰는 서비스 순서로 확인하면 원인을 좁히기 쉽다. 실제 계정의 삭제 작업은 별도의 승인과 복구 계획 아래에서 진행하자.
핵심 요약
S3에서 객체를 지우는 일과 버킷을 지우는 일은 다르다. 버킷 삭제 전에는 객체뿐 아니라 버전·삭제 마커와 실패한 비우기 작업까지 확인해야 한다. 무엇보다 삭제 대상과 연결된 서비스를 먼저 확인하자.
작성자
기초 개념을 구현과 검증, 실제 운영 판단까지 연결해 기록합니다.

