AWS의 백업 시스템도 뚫린 이유, 전쟁이 클라우드의 약점을 드러냈다
📺 원본 영상: AWS의 백업 시스템도 뚫린 이유, 전쟁이 클라우드의 약점을 드러냈다
🎙️ 채널: 안될과학 Unrealscience
📅 정리 일자: 2026-09-19
⚠️ Note: 본 리포트는 제공된 STT 기반 리포트의 문맥과 표현을 검수한 것이다. 원본 음성·STT 전문·영상 화면은 직접 확인하지 않았으므로 STT 오인식 여부를 확정하지 않았다. 사건의 날짜·피해 규모·기업 발표·법령 관련 내용은 강연자의 설명을 재구성한 것으로 별도의 원문 대조를 거치지 않았다.[?]는 원문 대조가 필요한 수치나 시점을 나타내며, 표기가 없는 정보까지 외부 검증을 마쳤다는 뜻은 아니다.
개요
클라우드의 안정성은 데이터를 여러 곳에 복제하는 기술에서 나오지만, 그 복제본들이 같은 재난에 노출되어 있다면 분산의 효과는 크게 줄어든다. 이 영상에서 항성은 중동 지역 AWS 데이터 센터에 대한 공격과 일부 데이터의 복구 불가 사례를 출발점으로, 가용 영역과 리전의 차이, 저장 서비스마다 다른 복제 범위, 전쟁이 장애의 독립성 가정을 무너뜨리는 과정을 설명한다. 이어 우크라이나의 데이터 이전과 에스토니아의 데이터 대사관을 통해, 디지털 기록을 지키는 일이 저장 기술뿐 아니라 지리·법·국가 운영의 문제이기도 하다는 점을 짚는다.
클라우드가 멈춘 자리에는 물리적인 건물이 있었다
강연자가 소개하는 사건의 출발점은 2026년 3월 1일이다. 영상에 따르면 이날 아랍에미리트의 AWS 데이터 센터 두 곳이 드론 공격을 받았고, 바레인에서도 데이터 센터 인근에 떨어진 드론으로 시설 피해가 발생했다. 아랍에미리트에서는 공격에 따른 파손에 화재가 겹쳤으며, 소방 당국이 진화를 위해 건물의 전력과 비상발전기를 차단해야 했다. 소화 과정에서는 일부 장비가 물에 젖었기 때문에, 시설은 충격·화재·전력 중단·수해가 중첩된 상황에 놓였다는 설명이다.
이 장면은 클라우드라는 이름이 가리는 물리적 현실을 드러낸다. 우리가 사진과 문서를 클라우드에 올려도, 실제 데이터는 특정 건물 안의 하드디스크나 SSD에 기록된다. 서버를 새로 구매하고 건물을 복구하는 일과, 파괴된 저장 장치 속 정보를 되살리는 일은 서로 다르다. 다른 곳에 살아남은 복사본이 없다면, 장비의 교체만으로 데이터까지 복원할 수는 없다.
영상은 AWS가 장기간 복구를 시도한 뒤 9월 15일[?] 일부 리소스와 데이터의 복구 불가를 알렸다고 전한다. 강연자가 설명한 대상은 바레인 리전에만 남아 있던 일부 데이터와, 아랍에미리트 리전의 특정 가용 영역에만 저장되어 있던 일부 데이터다. 여기서 중요한 것은 복구 불가의 범위를 구분하는 일이다. 강연의 설명을 모든 AWS 서비스나 모든 고객의 데이터가 소실되었다는 의미로 확대해서는 안 되며, 별도 복사본이 남아 있지 않은 데이터가 어떤 위험에 놓이는지 보여주는 사례로 읽어야 한다.
가용 영역과 리전은 서로 다른 크기의 장애에 대비한다
강연자는 AWS의 지리적 운영 단위를 리전(Region)과 가용 영역(Availability Zone, AZ)으로 나누어 설명한다. 리전은 서비스를 제공하는 지역 단위이며, 하나의 리전 안에는 여러 가용 영역이 존재한다. 하나의 AZ에는 하나 이상의 데이터 센터가 포함되므로, AZ 하나가 반드시 건물 하나를 의미하는 것은 아니다. 영상에서 소개한 아랍에미리트와 바레인 리전은 각각 세 개의 AZ로 구성되어 있다.
이 구조의 목적은 한 시설의 문제가 다른 시설까지 함께 멈추게 할 가능성을 낮추는 데 있다. 강연자는 같은 리전의 AZ들이 최대 약 100km 정도 떨어져 있고, 전력·냉각·네트워크도 가능한 한 분리된다고 설명한다. 동시에 AZ들은 지연시간이 짧은 전용망으로 연결되어 데이터를 빠르게 복제하고 서비스 전환을 지원한다. 물리적으로 떨어뜨려 장애를 격리하면서도, 통신 측면에서는 충분히 가깝게 유지하려는 설계인 셈이다.
그러나 이러한 분리가 모든 종류의 위험을 같은 수준으로 차단하지는 않는다. 한 건물의 화재를 피하는 데 충분한 거리가 광역 정전이나 전쟁을 피하는 데도 충분하다고 볼 수는 없기 때문이다. 영상의 설명을 설계 관점에서 해석하면, 분산의 효과는 복사본 사이의 거리뿐 아니라 대비하려는 사건의 범위에 따라 달라진다. 건물 수준의 사고를 견디는 구조와 지역 전체의 마비를 견디는 구조는 구분해서 평가해야 한다.
S3와 EBS의 차이 — 클라우드에 저장했다는 말만으로는 부족하다
강연은 저장 서비스에 따라 데이터가 복제되는 범위가 다르다는 점을 강조한다. S3 Standard는 사진이나 문서 같은 객체를 보관하는 저장 서비스로 소개되며, 업로드된 데이터는 같은 리전의 최소 세 개 AZ에 걸쳐 보관된다고 설명한다. 이 구조에서는 한 AZ에 문제가 생겨도 다른 AZ에 데이터가 남아 있도록 설계된다. 다만 여러 AZ에 보관된다는 설명을 다른 나라나 다른 리전에도 자동으로 복사된다는 뜻으로 이해해서는 안 된다.
반면 EBS는 AWS에서 사용하는 서버에 연결하는 디스크에 가까운 저장 공간이다. 강연자에 따르면 EBS도 개별 저장 장치의 고장에 대비해 데이터를 복제하지만, 그 복제 범위는 기본적으로 하나의 AZ 안에 머문다. 따라서 장비 하나의 고장과 AZ 전체의 상실은 전혀 다른 문제다. 같은 AZ 안에 여러 복사본이 있어도 그 영역 전체가 피해를 입으면, 복사본들이 동시에 접근 불가 또는 손상 위험에 놓일 수 있다.
이때 강연자가 제시하는 대비책이 스냅샷(Snapshot)이다. EBS 볼륨의 특정 시점 데이터를 저장한 스냅샷은 영상의 설명상 같은 리전의 여러 AZ에 걸쳐 보관되므로, 원래 볼륨이 있던 AZ에 문제가 생겼을 때 복구 수단이 된다. 그러나 리전 전체가 위험해지는 상황까지 고려한다면, 그 스냅샷을 다른 리전으로 복사하거나 별도의 원격 백업을 마련해야 한다. 백업이 존재하는지와 그 백업이 원본과 같은 사건에서 살아남을 수 있는지는 별개의 질문이다.
| 저장 방식 | 영상에서 설명한 보관 범위 | 보호 범위를 이해할 때의 핵심 |
|---|---|---|
| S3 Standard | 같은 리전의 최소 세 개 AZ | 다중 AZ 보관과 다른 리전으로의 복제는 구분해야 한다 |
| EBS 볼륨 | 기본적으로 하나의 AZ 내부에서 복제 | 개별 장비 고장에 대한 대비를 AZ 전체 상실에 대한 대비로 볼 수 없다 |
| EBS 스냅샷 | 같은 리전의 여러 AZ | 원본 AZ 밖의 복구 수단이지만 리전 전체 위험은 별도로 고려해야 한다 |
| 다른 리전의 백업 | 고객이 설정한 별도 리전 | 원격 복사본의 구성과 비용, 운영 방식을 고객이 검토해야 한다 |
이 차이를 바탕으로 보면 영상 제목의 “백업 시스템도 뚫렸다”는 표현은 구체적으로 해석할 필요가 있다. 본문이 설명하는 핵심은 보안 침입으로 모든 백업이 파괴되었다는 이야기가 아니라, 일부 데이터의 복제·백업 범위가 실제 피해 범위 밖까지 뻗어 있지 않았다는 문제다. 서비스 내부의 복제, 별도로 생성하는 복구 지점, 다른 리전에 보관하는 백업은 각각 다른 역할을 한다. 따라서 클라우드의 안정성을 판단하려면 사업자의 이름뿐 아니라 사용하는 서비스와 설정된 보호 범위를 함께 확인해야 한다.
10억분의 1이라는 계산을 무너뜨린 독립성의 조건
영상은 분산 설계의 효과를 설명하기 위해 간단한 확률 모형을 제시한다. 어느 한 시점에 AZ 하나가 장애 상태일 확률을 임의로 0.1%, 즉 1,000분의 1로 가정하고, 세 AZ의 장애가 서로 완전히 독립적이라고 둔다. 이 조건에서는 세 곳이 동시에 장애 상태일 확률을 각각의 확률을 곱해 구할 수 있다. 강연자는 이때 사용한 0.1%가 실제 AWS의 장애 확률이 아니라 설명을 위한 가상의 값임을 명시한다.
[ P(\text{세 AZ의 동시 장애}) = 0.001 \times 0.001 \times 0.001 = 10^{-9} = \frac{1}{1{,}000{,}000{,}000} ]
이 계산에서 결정적인 조건은 복사본의 개수보다 장애의 독립성이다. 한 AZ가 장애를 겪었다는 사실이 다른 AZ의 장애 가능성을 바꾸지 않아야 단순한 곱셈이 성립한다. 따라서 이 결과를 실제 서비스의 연간 장애율이나 데이터 손실 확률로 그대로 옮겨 사용할 수는 없다. 영상의 예시는 어디까지나 특정 시점의 독립적인 장애를 가정했을 때 분산이 어떤 효과를 내는지 보여준다.
강연자가 설명하는 공통 원인 장애(Common-cause Failure)는 바로 이 가정을 흔드는 상황이다. 광역 정전, 통신망 장애, 공통 소프트웨어 오류, 홍수, 지진, 전쟁은 여러 시설에 동시에 영향을 줄 수 있다. 특히 같은 공격 주체가 한 지역의 시설들을 잇따라 노린다면, 하나의 AZ가 공격받았다는 사실은 다른 AZ도 위험하다는 신호가 된다. 이 경우에는 각 시설의 장애를 서로 무관한 사건으로 간주할 수 없다.
영상에 따르면 아랍에미리트에서는 여러 AZ가 영향을 받았고, 바레인에서는 피해가 이어지면서 리전 전체를 사용할 수 없게 되었다. 이러한 설명이 가리키는 문제는 개별 시설의 신뢰성만 높여서는 해결되지 않는다. 복사본이 여러 개라도 하나의 원인으로 함께 사라질 수 있다면, 그 복사본들은 해당 위험에 대해 충분히 독립적이지 않다. 분산 설계의 핵심은 저장 장소의 숫자와 함께, 그 장소들이 공유하는 실패 원인을 줄이는 데 있다.
다른 리전으로 옮기면 해결되는가 — 거리·비용·규제의 제약
강연자는 다른 리전에 복사본을 두는 기술 자체는 이미 가능하다고 설명한다. 중동의 데이터를 유럽이나 아시아처럼 멀리 떨어진 곳에 보관할 수도 있지만, AWS가 모든 고객의 데이터를 다른 리전까지 일괄적으로 자동 복사하는 것은 아니다. 고객이 필요한 백업 방식을 설정하고 그에 따른 비용을 부담해야 한다. 따라서 원격 백업의 부재를 단순히 기술의 부재로 설명할 수는 없다.
서비스를 빠르게 전환하려는 목적까지 더해지면 거리의 문제가 복잡해진다. 강연은 지연시간이 짧은 가까운 리전이 운영상 유리할 수 있지만, 가까운 지역들은 동일한 전쟁의 영향권에 놓일 수 있다고 지적한다. 영상에서 설명하는 당시 걸프 지역의 AWS 리전은 바레인과 아랍에미리트였으며, 사우디아라비아 리전은 2026년 12월[?] 개설 예정으로 언급된다. 아랍에미리트에서 바레인으로 복사본을 분산했더라도, 두 위치가 같은 분쟁 범위에 속한다면 전쟁 위험까지 충분히 분리했다고 보기 어렵다는 논리다.
또 다른 제약은 데이터의 국외 이전에 관한 규정이다. 강연자는 아랍에미리트의 의료 데이터와 금융·정부 데이터, 바레인의 개인정보를 사례로 들어 해외 이전에 분야별 조건이나 승인 절차가 적용될 수 있다고 설명한다. 이는 기술적으로 가능한 복제가 조직의 운영이나 제도 측면에서는 즉시 실행하기 어려울 수 있음을 뜻한다. 다만 영상은 이번에 복구하지 못한 고객 데이터가 실제로 규제 때문에 해외에 백업되지 않았는지는 공개되지 않았다고 분명히 선을 긋는다.
이 구분은 사건을 이해하는 데 중요하다. 규제는 일반적인 설계 제약으로 논의할 수 있지만, 공개되지 않은 개별 고객의 손실 원인으로 단정해서는 안 된다. 영상의 설명에서 도출되는 실무적 함의는 재난이 발생하기 전에 데이터별 보관 조건과 이전 가능 범위를 확인해야 한다는 것이다. 장애가 일어난 뒤에야 해외 이전의 가능 여부를 검토하면, 기술적 복구 작업과 제도적 판단이 동시에 필요해질 수 있다.
백업이 살아남는 것과 서비스가 재개되는 것은 다르다
영상은 바레인 리전의 고객 상당수가 첫 피해 이후 다른 리전으로 이전하기 시작했다고 전한다. 강연자에 따르면 3월 첫 번째 AZ가 피해를 입은 뒤 AWS가 이전을 권고했고, 많은 고객이 4월 두 번째 AZ가 멈추기 전에 서비스와 데이터의 이동을 마쳤다. 별도의 백업이 남아 있는 경우에는 이를 이용한 복구도 이루어졌다고 설명한다. 이 대목은 피해가 한 번에 끝나는 사건뿐 아니라, 시간이 흐르며 확대되는 상황에도 대응 계획이 필요하다는 점을 보여준다.
기술적으로 해석하면 데이터의 보존과 서비스의 운영 재개는 연결되어 있지만 동일하지는 않다. 원격지에 복사본이 남아 있으면 정보를 되살릴 가능성은 확보되지만, 그 정보로 실제 서비스를 다시 제공하려면 실행 환경과 연결 구성을 준비해야 한다. 반대로 서비스 전환을 빠르게 할 수 있는 구조라도, 필요한 데이터가 손실되었다면 정상적인 운영을 이어가기 어렵다. 영상이 데이터 이전과 서비스 이전을 함께 언급하는 이유를 이 차이에서 이해할 수 있다.
따라서 백업 정책은 복사 작업의 성공 여부만으로 평가하기 어렵다. 강연의 사례를 바탕으로 보면, 실제 피해 범위 밖에 데이터가 남는지와 그 데이터를 이용해 업무를 재개할 수 있는지를 함께 따져야 한다. 복구 수단이 존재한다는 사실과 그것을 필요한 시점에 사용할 수 있다는 사실 사이에는 운영상의 준비가 놓인다. 클라우드의 복원력은 저장 기능 하나가 아니라, 보관·이전·복구·운영 재개의 연결에서 결정된다.
우크라이나의 사례 — 데이터를 옮기려면 제도도 움직여야 한다
강연은 중동 사례와 대비해 2022년 우크라이나의 데이터 이전을 소개한다. 당시 우크라이나는 일부 정부·민간 데이터를 국내 서버에 보관하도록 규정하고 있었지만, 러시아의 침공을 앞둔 2월 17일 의회가 클라우드 서비스법을 통과시켰다고 설명한다. 침공 이후에는 계엄 상황에서 국가정보시스템과 공공전자 등록부를 해외 클라우드 서버에서도 운영할 수 있도록 추가 조치가 이루어졌다고 전한다. 이 사례에서 기술의 사용 범위를 넓힌 것은 저장 장비만이 아니라 제도적 변화였다.
대용량 데이터를 옮기는 과정에서는 AWS Snowball이 활용되었다. 강연자는 이를 데이터를 담아 클라우드로 이전할 수 있도록 만든 견고한 물리적 저장 장치로 설명한다. 영상에 따르면 침공 당일 우크라이나 정부와 AWS가 장비 반입을 논의했으며, 이틀 뒤 장비가 폴란드 크라쿠프에 도착한 후 우크라이나 현장으로 전달되었다. 클라우드로의 이동이 물리적 장비의 운송을 통해 이루어졌다는 점은 디지털 인프라가 현실의 물류와 연결되어 있음을 보여준다.
영상은 그해 6월 무렵까지[?] 42개 정부기관과 24개 대학을 비롯한 학교·민간 기업의 필수 데이터 10페타바이트 이상이 AWS 클라우드로 이전되었다고 설명한다. 해당 시점과 기관 수·데이터 규모가 같은 집계 기준에 따른 것인지는 원문 대조가 필요하다. 여기서 핵심은 전송한 데이터의 크기만이 아니다. 행정·교육·산업을 떠받치는 기록을 국내 시설과 동일한 물리적 위험에서 벗어나게 했다는 데 의미가 있다. 강연의 맥락에서 우크라이나 사례는 데이터 보호를 위해 기술적 실행 능력과 국외 이전을 허용하는 제도가 함께 필요하다는 점을 보여준다.
상용 데이터 센터가 공격 대상이 된다는 것
강연자는 이란 국영 매체가 AWS 시설을 적의 군사 정보 활동을 지원하는 대상으로 지목한 혁명수비대의 주장을 보도했다고 전한다. 그러나 공격받은 아랍에미리트와 바레인 시설이 실제로 미군의 군사 데이터를 보관하거나 AI 연산을 처리했는지는 공개 자료만으로 확인할 수 없다고 설명한다. 공격 주체가 제시한 명분과 해당 시설의 실제 역할은 구분해야 한다. 상용 클라우드가 군사 분야에 사용된다는 일반적인 사실만으로 특정 시설의 용도를 확정할 수는 없다는 것이다.
영상은 이러한 구분을 국제인도법의 설명으로 이어간다. 강연자의 설명에 따르면 민간 데이터 센터가 군사 목표로 평가되려면 실제 군사 작전에 대한 기여와, 파괴 또는 무력화로 얻을 수 있는 명확한 군사적 이익을 따져야 한다. 군사 목표로 판단되는 경우에도 예상되는 민간 피해와 피해를 줄이기 위한 조치를 검토해야 한다고 덧붙인다. 이는 영상에서 제시한 일반적인 법적 설명이며, 이 리포트가 개별 공격의 적법성을 판정하는 것은 아니다.
이 대목이 클라우드 논의에서 중요한 이유는 하나의 사업자가 다양한 고객의 업무를 지원하기 때문이다. 군사적 활용에 관한 주장이 등장하더라도, 특정 시설에는 별개의 민간 서비스와 기록이 함께 의존할 수 있다. 그러므로 시설의 역할과 민간 피해를 구체적으로 확인하는 과정이 필요하다. 강연은 데이터 센터를 군사·민간 중 하나로 단순하게 묶기보다, 시설별 사실관계를 구분해야 한다는 입장을 유지한다.
서버를 파괴하지 않아도 데이터 센터는 멈춘다
물리적 방어의 관점에서 데이터 센터는 크고 고정되어 있으며 위치를 숨기기 어렵다는 특징을 갖는다. 강연자는 공격받은 시설들이 폭발을 견디도록 요새화되거나 전용 방공망을 갖춘 구조가 아니었다는 연구자의 지적을 소개한다. 그러나 취약성은 서버 건물의 외벽에만 있지 않다. 서버가 정상적으로 작동하려면 전력 공급과 열 배출이 동시에 유지되어야 하기 때문이다.
강연은 서버가 사용하는 전기에너지가 결국 거의 모두 열로 전환된다는 점을 설명한다. 따라서 전기를 공급하는 것만큼 발생한 열을 지속해서 외부로 내보내는 일이 중요하다. 무정전 전원 장치(UPS), 비상발전기, 예비 냉각설비가 있어도 이들까지 기능을 잃으면 서버는 과열과 손상을 피하기 위해 출력을 낮추거나 정지해야 한다. 영상에서 소개한 화재 진압을 위한 전력·발전기 차단은 서버를 직접 파괴하지 않아도 서비스가 중단될 수 있음을 보여준다.
외부 기온이 높은 환경은 냉각 문제를 더욱 중요하게 만든다. 영상은 현지 시설이 기후를 고려해 설계되더라도 냉각 시스템이 멈췄을 때의 영향이 클 수 있다고 설명한다. 따라서 시설 보호는 저장 장치만 감싸는 것으로 끝나지 않고, 전력과 냉각 등 운영에 필요한 전체 체계를 포함해야 한다. 비교적 값싼 공격 수단이 고가의 인프라를 멈출 수 있다는 강연의 지적도 이러한 의존 관계에서 나온다.
지하화와 분산 건설 — 건물을 지켜도 외부 연결은 남는다
강연자는 아랍에미리트가 기존의 대규모 AI 데이터 센터 건설 계획을 재검토하고 있다고 전한다. 영상에서 소개된 계획은 아부다비의 약 26㎢ 부지에 최대 5GW 규모의 단지를 조성하는 것이며, 그중 1GW 규모의 초기 컴퓨팅 클러스터는 이미 건설에 들어간 상태라고 설명한다. 이어 강연자가 인용한 로이터 보도에 따르면, 한곳에 집중하려던 시설을 여러 지역에 나누는 방안이 검토되고 있다. 이는 시설 규모를 키우는 문제와 전체 기능을 한 번에 잃지 않도록 하는 문제가 별개임을 드러낸다.
영상에는 요격 장비와 전파방해 장비, 폭발에 강한 콘크리트, 산악 지역 내부의 시설 구축도 대응 방안으로 등장한다. 그러나 강연자는 데이터 센터를 지하나 산속에 넣는다고 모든 취약성이 사라지는 것은 아니라고 설명한다. 수십에서 수백 메가와트의 전력을 소비하는 서버가 내놓는 열을 주변 암반에만 계속 흘려보내는 데에는 한계가 있다. 결국 냉각수·공기·열교환기를 통해 열을 외부로 배출해야 하며, 전력선과 통신망 역시 외부에 연결되어야 한다.
이 설명에서 도출되는 함의는 시설 방호와 데이터 분산이 서로 다른 위험을 줄인다는 것이다. 건물의 방호 수준을 높이면 직접적인 물리 피해를 줄이는 데 도움이 될 수 있지만, 외부 공급 체계의 중단이나 광역 재난까지 모두 해결하지는 못한다. 반대로 데이터를 멀리 복제해 두어도 현재 시설의 서비스 중단 자체를 막는 것은 아니다. 어느 한 방법만으로 완전한 보호를 기대하기보다, 보호하려는 대상과 실패 범위를 구체적으로 나누어 설계해야 한다.
데이터 대사관 — 국경 밖에서도 국가 기록을 통제하는 방식
강연이 마지막으로 소개하는 사례는 에스토니아의 데이터 대사관(Data Embassy)이다. 영상에 따르면 에스토니아는 2017년 룩셈부르크와 협정을 맺고, 현지 데이터 센터에 주민등록부와 토지 등기부 같은 국가 핵심 데이터의 백업을 보관하는 체계를 만들었다. 목적은 자국 내 데이터 센터가 사이버 공격이나 전쟁으로 멈추더라도 주요 국가 서비스를 이어갈 수 있도록 하는 데 있다. 국가의 기록을 보호하는 위치와 국가의 영토를 반드시 일치시키지 않는 접근이다.
이 체계에서 핵심은 해외에 서버를 두는 것만이 아니다. 강연자는 일반적인 외교 공간은 아니지만 협정에 따라 대사관에 준하는 면책과 보호를 받으며, 서버와 데이터는 에스토니아 정부가 직접 통제한다고 설명한다. 물리적 보관 장소를 분산하면서 통제권과 보호 조건을 제도적으로 확보하려는 구성이다. 따라서 데이터 대사관은 원격 백업에 관한 기술적 선택이자 국가 간 협정에 관한 선택으로 소개된다.
우크라이나 사례와 함께 읽으면 데이터 주권의 의미도 입체적으로 드러난다. 국외에 데이터를 보관하는 행위가 언제나 통제권의 포기를 뜻하는 것은 아니며, 반대로 모든 데이터를 국내에 두는 것만으로 국가 기록의 지속성이 보장되는 것도 아니다. 강연의 사례에서 중요한 것은 누가 데이터를 통제하고, 어떤 법적 조건 아래 보관하며, 국내 시설이 사라져도 활용할 수 있는가이다. 데이터의 위치와 통제권, 재난 이후의 사용 가능성을 함께 고려해야 한다는 의미다.
마무리 / 핵심 정리
이 영상이 드러내는 클라우드의 약점은 모든 데이터가 결국 특정 장소의 물리 장치에 의존한다는 사실이다. 가용 영역의 분리와 데이터 복제는 개별 장비 고장이나 국지적 장애에 대비하는 중요한 수단이지만, 여러 시설을 함께 위협하는 전쟁에서는 그 보호 범위를 다시 살펴야 한다. 강연의 확률 예제가 보여주듯, 여러 복사본이 높은 신뢰성으로 이어지려면 그 복사본들의 실패가 충분히 분리되어 있어야 한다. 복사본의 수만 세는 방식으로는 공통 원인 장애를 평가하기 어렵다.
또한 원격 백업은 기술만으로 완성되지 않는다. 저장 서비스의 특성, 다른 리전으로의 복제 설정, 비용, 지연시간, 국외 이전 규정, 복구 이후의 운영 준비가 함께 맞물린다. 우크라이나의 데이터 이전과 에스토니아의 데이터 대사관은 이러한 문제가 기업의 시스템 설계를 넘어 국가의 지속성으로 이어질 수 있음을 보여준다. 데이터 보호의 핵심 질문은 “몇 개를 복사했는가”와 함께 “하나의 사건이 그 복사본들을 동시에 없앨 수 있는가”여야 한다.
📚 출처 및 참고
| 구분 | 내용 |
|---|---|
| 원본 영상 | AWS의 백업 시스템도 뚫린 이유, 전쟁이 클라우드의 약점을 드러냈다 |
| 채널 | 안될과학 Unrealscience |
| 리포트에 기재된 STT 범위 | 00:00–12:48 |
| 리포트 작성 | 2026-09-19 |
| 작성 방식 | 제공된 YouTube 영상 STT 기반 리포트의 문맥 교정 및 서술형 에디팅 |
| 자료 확인 범위 | 제공된 리포트와 스크린샷 목록만 검토. 원본 음성·STT 전문·영상 화면·외부 원문은 별도로 확인하지 않음 |
| 수치 검수 | 0.1% = 0.001 및 세 독립 사건의 동시 발생 확률 10⁻⁹ = 10억분의 1 계산 확인. 원문 대조가 필요한 일부 시점에 [?] 표시 |
| 스크린샷 | 제공된 6개 항목 모두 로컬 경로만 있고 webUrl이 없어 삽입하지 않음 |
| 영상에서 언급한 외부 자료 | AWS 발표, 로이터 보도, 이란 국영 매체 보도, 관련 법령과 국가 간 협정 |
💬 본 리포트는 제공된 영상 STT 기반 리포트를 검수한 것이다. 사건·수치·법령에 관한 설명은 기존 리포트에 기재된 강연자의 서술을 따랐으며, 기술적 해석은 본문에서 구분했다. 정확한 발언과 화면 자료는 원본 영상을 참조할 수 있다. 제공된 스크린샷 목록의 시점은 설명 주제를 기준으로 선정한 화면 확인 후보이며, 실제 화면에 어떤 자료가 표시되는지는 확인하지 않았다.
영상 주요 장면
02:24 - 가용 영역의 물리적 분리와 저지연 전용망 연결을 설명하는 구간. 리전과 AZ 구조 관련 화면 확인 후보.
03:21 - EBS 스냅샷이 여러 AZ에 걸쳐 보관되는 방식을 설명하는 구간. 볼륨 복제와 스냅샷의 보호 범위 관련 화면 확인 후보.
04:01 - 세 AZ의 동시 장애 확률 계산 후 가정값의 의미를 설명하는 구간. 0.1%와 10억분의 1 계산 관련 화면 확인 후보.
07:53 - 우크라이나 정부기관과 대학 등의 데이터 이전 규모를 설명하는 구간. 10페타바이트 이상 이전 사례 관련 화면 확인 후보.
10:49 - 아랍에미리트의 5GW 데이터 센터 계획을 여러 지역에 분산하는 방안을 설명하는 구간. 건설 계획 관련 화면 확인 후보.
11:54 - 에스토니아 데이터 대사관의 보호와 통제 방식을 설명하는 구간. 해외 국가 데이터 백업 관련 화면 확인 후보.