Cloudflare R2 장애로 다시 보는 오브젝트 스토리지 내구성: 가용성과 무엇이 다른가
🤖 AI Summary
2026년 8월 7일, Cloudflare의 오브젝트 스토리지 R2에서 ENAM(미 동부) 리전 일부 버킷의 쓰기가 약 두 시간 실패하는 장애가 있었습니다. Cloudflare는 이를 가용성 문제로 분류했고, 8월 9일 영향받은 모든 버킷이 완전 복구됐다고 밝혔죠. 다만 한 이용자는 커뮤니티에 자신의 약 67GB 버킷이 복구되지 않았다고 신고했고, R2 팀 엔지니어는 확인 중이라고 답했습니다. 여기서 중요한 건 이 손실이 아직 고객의 주장일 뿐 Cloudflare가 확인한 사실은 아니라는 점입니다. 이 사건은 스토리지에서 가용성과 내구성이 다른 축이라는 사실을 다시 보게 합니다. 데이터가 잠시 안 보이는 것과 영영 사라지는 것은 전혀 다른 문제이고, 운영자가 정말 두려워해야 할 쪽은 후자예요. 근거는 Cloudflare 공식 상태 페이지와 커뮤니티 원문입니다.
블로그 목차
무엇이 있었나: R2 ENAM 쓰기 장애 타임라인
조사 시작(8월 7일 18:42): ENAM 리전의 소수 R2 버킷에서 가용성에 영향을 주는 문제를 조사 중이라고 알렸습니다.원인 규명(8월 7일 22:54): 원인을 파악하고 추가 영향을 완화했으며, ENAM 일부 버킷의 쓰기가 14:52부터 17:02 사이 영향을 받았다고 밝혔죠.대부분 복구(8월 8일 23:28): 거의 모든 버킷의 가용성이 복구됐고, 해당 시간대에 멀티파트 업로드로 올라간 소수 객체만 아직 접근이 안 된다고 전했어요.완전 복구(8월 9일 02:35): 멀티파트 업로드 객체를 포함해 영향받은 모든 버킷의 가용성이 완전히 복구됐다고 종료했습니다.
핵심만 보면 ENAM 리전 일부 버킷의 쓰기가 약 두 시간(14:52~17:02) 실패했고, 그 시간대에 멀티파트로 업로드된 일부 객체가 한동안 보이지 않다가 이틀 뒤 모두 복구됐습니다. Cloudflare 기준으로는 데이터가 사라진 것이 아니라 일시적으로 접근이 안 됐다가 되돌아온 가용성 사건이죠. 참고로 이 기간(8월 7일부터 14일까지) Cloudflare 상태 페이지에는 R2 외에도 크고 작은 장애가 여러 건 함께 기록됐습니다.
데이터는 정말 사라졌나: 신고와 공식 발표 사이
Cloudflare의 공식 발표는 완전 복구였지만, 커뮤니티에서는 결이 다른 목소리가 있었습니다. 한 이용자가 자신의 ENAM 버킷(약 67GB, 이미지 생성 환경의 영구 저장소로 쓰던 곳)이 장애 이후 S3 호환 API로 접근되지 않는다며, Cloudflare가 사건을 종료 처리했는데도 버킷이 돌아오지 않았다고 신고했죠. 한 커뮤니티 자원봉사자는 계정별 사안이니 지원 티켓을 열라고 안내했고, 이어 R2 팀 엔지니어가 팀과 함께 확인 중이며 곧 결과를 알리겠다고 답했습니다.
여기서 표현을 분명히 해 둘 필요가 있습니다. 이 시점 기준으로 데이터 손실은 한 이용자의 신고이지, Cloudflare가 확인한 사실이 아닙니다. 오히려 공식 상태 페이지는 모든 버킷이 완전 복구됐다고 밝히고 있죠. 신고자의 계정이 신규이고 게시물도 단 한 건이라는 점 역시 함께 감안할 대목이죠. 그럼에도 이 신고가 눈길을 끄는 이유는 따로 있어요. 만약 사실이라면 그것은 가용성 문제가 아니라 내구성 문제가 되기 때문이에요. 잠시 안 보이는 것과 영영 사라지는 것은, 스토리지에서 무게가 완전히 다른 사건입니다.
가용성과 내구성은 다른 축이다
오브젝트 스토리지를 볼 때 자주 뭉뚱그리는 두 지표가 있습니다. 가용성(Availability)은 지금 데이터에 접근할 수 있는가이고, 내구성(Durability)은 데이터가 사라지지 않고 보존되는가입니다. 방향이 다르죠. 서버가 잠시 응답하지 않아 파일을 못 받는 것은 가용성 저하이고, 저장해 둔 파일 자체가 소실되는 것은 내구성 실패죠. 오브젝트 스토리지의 기본 구조가 낯설다면 오브젝트 스토리지 입문 글에서 버킷·객체·수명주기를 먼저 짚어 볼 수 있습니다.
업계가 스토리지를 광고할 때 흔히 내세우는 수치가 11개의 9, 즉 99.999999999%의 내구성입니다. 저장된 객체가 1년 동안 유실될 확률이 사실상 없다는 통계적 설계 목표로, AWS S3가 제시하면서 널리 알려졌어요. 반면 가용성 목표치는 보통 이보다 낮게, 몇 개의 9 수준으로 잡혀요. 즉 스토리지 사업자도 잠깐의 접근 불가는 있을 수 있지만 데이터를 잃지는 않겠다는 쪽에 방점을 둡니다. 이번 R2 사건이 공식적으로 가용성 장애로 분류되고 모두 복구로 종료된 것도 이 틀에서 이해할 수 있어요.
문제는 내구성이 통계적 약속이지 절대적 보장은 아니라는 점입니다. 리전 단위 장애, 복구 과정의 인덱스 손상, 운영 실수 같은 변수는 그 확률 밖에서 일어날 수 있습니다. 그래서 신고 한 건의 진위와는 별개로, 이번 사건은 내구성 수치를 맹신하지 말고 스스로의 대비를 갖추라는 신호로 읽는 편이 안전합니다.
스토리지 운영자가 지금 점검할 것
정리하면 대비는 몇 가지로 좁혀지죠. 첫째, 한 사업자, 한 리전에만 중요한 데이터를 두지 않기입니다. 단일 리전 장애는 드물지만 이번처럼 실제로 일어나며, 대체 위치가 없으면 복구를 온전히 사업자에게 맡기게 되죠. 둘째, 독립된 백업입니다. 같은 계정, 같은 사업자 안의 복제만으로는 계정 단위나 복구 과정의 문제를 피하기 어려우니, 3-2-1 원칙처럼 물리적·논리적으로 분리된 사본을 두는 편이 안전하죠.
셋째, 복구가 실제로 되는지 주기적으로 검증하는 일입니다. 백업은 있는데 정작 복원이 안 되는 경우가 의외로 많죠. 넷째, 사업자의 내구성·가용성 SLA를 수치가 아니라 의미로 읽는 습관이에요. 11개의 9가 유실 제로를 보장하는 문구가 아니라 확률적 설계 목표라는 점을 알고 나면, 어디까지 사업자에 기대고 어디부터 내 몫으로 둘지 선이 분명해집니다. 대형 사업자의 다른 장애가 어떻게 번졌는지 궁금하다면 AWS CloudFront 장애 글도 함께 볼 만합니다.
이것만 기억하세요
2026년 8월 7일 Cloudflare R2의 ENAM 리전 일부 버킷 쓰기가 약 두 시간 실패했고, Cloudflare는 이를 가용성 장애로 보고 8월 9일 완전 복구를 발표했습니다. 한 이용자가 약 67GB 미복구를 신고했지만 이는 고객의 주장이며 Cloudflare가 확인한 손실은 아닙니다. 스토리지에서 가용성(지금 접근 가능한가)과 내구성(데이터가 보존되는가)은 다른 축이고, 정말 두려워할 쪽은 내구성입니다. 11개의 9는 절대 보장이 아니라 확률적 목표이니, 단일 리전 의존을 피하고 독립 백업과 복구 검증을 갖춰 두는 것이 핵심입니다.
자주 묻는 질문 (FAQ)
Q. Cloudflare R2 장애는 무슨 일이었나요?
2026년 8월 7일 ENAM 리전 일부 R2 버킷의 쓰기가 약 두 시간 실패한 가용성 장애입니다. Cloudflare는 8월 9일 멀티파트 업로드 객체를 포함해 영향받은 모든 버킷이 완전 복구됐다고 밝혔습니다.
Q. 정말 데이터가 사라졌나요?
확정된 사실이 아닙니다. 한 이용자가 약 67GB 버킷이 복구되지 않았다고 커뮤니티에 신고했지만, Cloudflare 공식 상태 페이지는 완전 복구를 밝혔고 R2 팀 엔지니어는 확인 중이라고만 답했습니다. 현재로서는 고객의 주장이지 Cloudflare가 확인한 손실은 아닙니다.
Q. 가용성과 내구성은 어떻게 다른가요?
가용성은 지금 데이터에 접근할 수 있는지, 내구성은 데이터가 사라지지 않고 보존되는지를 뜻합니다. 잠시 접근이 안 되는 것과 영영 사라지는 것은 스토리지에서 전혀 다른 사건이며, 이번 R2 사건은 공식적으로 가용성 장애로 분류됐습니다.
Q. 11개의 9(99.999999999%)면 안심해도 되나요?
그렇지 않습니다. 11개의 9는 유실이 없다는 절대 보장이 아니라 확률적 설계 목표입니다. 리전 단위 장애나 복구 과정의 인덱스 손상, 운영 실수 같은 변수는 그 확률 밖에서 일어날 수 있으므로, 수치만 믿고 대비를 생략하지 않는 편이 안전합니다.
Q. 운영자는 무엇을 대비해야 하나요?
한 사업자·한 리전에만 데이터를 두지 않고, 독립 백업(3-2-1)과 복구 검증을 갖추는 것이 기본입니다. 사업자의 내구성·가용성 SLA는 절대 보장이 아니라 확률적 목표로 읽어야 합니다.
