처음 S3 버전 관리를 배울 때 많은 개발자들이 "그냥 백업 기능이구나"하고 넘어간다. 그러다 운영 환경에서 버전 관리 활성화 후 스토리지 비용이 갑자기 10배가 되는 상황을 만나거나, 삭제했다고 생각한 파일이 감사 시스템에 여전히 보이는 상황을 겪으면서 버전 관리의 실제 동작 방식을 비로소 이해하게 된다. 이 day에서는 버전 관리의 내부 메커니즘, 수명 주기 정책의 전환 그래프, 그리고 복제가 비동기로 동작하는 이유와 그 함의를 깊이 파고든다.
버전 관리를 활성화한 S3 버킷에서 객체는 단순한 키-값 쌍이 아니라 키 + 버전 ID의 조합으로 저장된다. 버전 ID는 S3가 자동 생성하는 불투명한 문자열(예: versionId: "3/L4kqtJlcpXrALLEAjahyKwzSEFI.B)이며, 모든 PUT 요청마다 새로운 버전이 생성된다.
버전 관리가 활성화되지 않았을 때 업로드된 객체의 버전 ID는 null이다. 버전 관리를 나중에 활성화해도 기존 객체의 버전 ID는 null로 유지된다. 이 점이 실무에서 자주 혼동을 만든다 — 버전 관리를 켰는데 왜 기존 파일에 버전이 없냐는 것이다.
[버전 관리 활성화 시 객체 타임라인]
PUT report.pdf → 버전 abc123 (최신)
PUT report.pdf → 버전 def456 (최신)
DELETE report.pdf → 삭제 마커 ghi789 (최신, 내용 없음)