“클라우드에 올려 뒀으니 잃어버릴 일은 없겠지.” 많은 분들이 이렇게 생각하시죠. 휴대폰 사진도, 가게 장부도, 회사 서버도 요즘은 대부분 ‘클라우드’라는 남의 큰 컴퓨터에 맡겨 둡니다. 그런데 어제(11월 10일) 러시아 최대 IT 기업 얀덱스(Yandex)가 내놓은 발표는 이 믿음에 작은 물음표를 붙였습니다.
지난 10월 드론 공격으로 데이터센터 3곳이 피해를 입은 뒤, 얀덱스는 자사 클라우드 서비스 얀덱스 클라우드(Yandex Cloud)에 맡겨진 고객 데이터의 97.16%를 되살렸지만, 나머지 2.84%는 영영 되찾을 수 없다고 밝혔어요. 이유는 두 가지였습니다. 장비가 심하게 부서졌고, 그 고객들이 백업을 켜 두지 않았다는 것. 반대로 백업 기능을 쓴 고객은 데이터를 100% 지켰다고 합니다. 오늘은 이 숫자가 무슨 뜻인지, 그리고 우리 집 사진과 회사 파일을 지키려면 무엇을 확인해야 하는지 쉽게 풀어 보겠습니다.
한눈에 보기: 무슨 일이 있었나
| 항목 | 내용 |
|---|---|
| 누구 | 얀덱스(Yandex) — 검색·지도·택시·결제·클라우드를 함께 하는 러시아 최대 IT 기업 |
| 어디 | 얀덱스 데이터센터 6곳 중 3곳: 사소보(랴잔주), 칼루가, 블라디미르 |
| 언제 | 10월 8일·9일·11일 드론 공격 (러시아 측은 우크라이나 공격으로 발표) |
| 피해 | 사소보·블라디미르는 완전 가동 중단, 칼루가는 일부 모듈 파손 |
| 발표 | 11월 10일(현지) — 고객 데이터 97.16% 복구, 2.84% 영구 손실 |
| 살아남은 쪽 | 얀덱스 클라우드의 백업 도구를 쓴 고객은 100% 보존 |
| 달라지는 점 | 앞으로 새 가상 서버(VM)를 만들면 백업이 기본으로 켜짐 (원하면 끌 수 있음) |
클라우드는 결국 어딘가에 있는 진짜 건물 속 진짜 컴퓨터입니다. 아무리 “구름”이라는 예쁜 이름을 붙여도, 건물에 불이 나거나 전기가 끊기면 그 안의 하드디스크도 함께 위험해져요. 이번 일은 그 당연한 사실을 아주 큰 규모로 보여 준 사례입니다.
한 달 동안의 흐름
| 날짜(현지) | 무슨 일 |
|---|---|
| 10월 8일 새벽 | 사소보 데이터센터 화재, 완전 중단. 클라우드 ‘가용영역’ 하나(ru-central1-b)가 멈춤 |
| 10월 9일 | 칼루가 데이터센터 피격, 일부 설비 고장. 얀덱스는 다른 러시아 클라우드 업체 3곳과 손잡고 고객 데이터 이전·백업을 우선 지원 |
| 10월 11일 새벽 | 블라디미르 데이터센터 전력 차단 후 완전 중단. 클라우드는 ‘비상 모드’로 운영, 고객들에게 “다른 재해 복구 계획을 가동하라”고 안내 |
| 10월 중순 | 검색·택시·지도·결제(얀덱스 페이)·음성비서 ‘알리사’ 등 서비스 장애. 얀덱스 서버에 기대던 쇼핑몰·인터넷 업체 등 다른 회사 서비스도 함께 흔들림 |
| 10월 23일 | 새 위치에서 클라우드 일부 재가동, 단계적으로 고객 접근 재개 |
| 11월 10일 | 최종 집계 발표: 97.16% 복구 / 2.84% 복구 불가, 백업 기본 켜기 도입 |
‘2.84%’는 적은 숫자일까?
100개 중 3개도 안 되니 별것 아닌 것처럼 들리죠. 그런데 이건 전체 고객 데이터의 비율이라는 점이 중요합니다. 얀덱스 클라우드는 올해 중반 기준 약 6만 4천 곳의 기업 고객이 쓰던 서비스예요. 러시아 매체들은 클라우드 전체 규모를 바탕으로, 사라진 양이 수만~10만 테라바이트(TB), 파일 수천만 개에 이를 수 있다는 추정을 내놓기도 했습니다. 이 수치는 회사가 공식 확인한 숫자는 아니라서 “그만큼 클 수도 있다”는 정도로 받아들이시면 됩니다.
그리고 개인 입장에서 보면 비율은 의미가 없어요. 2.84%가 골고루 조금씩 사라진 게 아니라, 백업이 없던 일부 고객에게는 자기 데이터의 100%일 수 있기 때문입니다.
| 숫자 | 제대로 읽는 법 |
|---|---|
| 97.16% 복구 | 부서지지 않은 장비, 다른 곳에 복제돼 있던 데이터, 고객 백업 등을 모아 되살린 비율 |
| 2.84% 손실 | 장비가 완전히 망가졌고, 다른 곳에 사본도 없던 데이터. 돈을 더 들여도 되돌릴 수 없음 |
| 백업 사용 고객 100% | “백업이 있으면 건물이 무너져도 살 수 있다”는 가장 강력한 증거 |
| 약 6만 4천 고객 | 피해 고객 수가 아니라 전체 고객 규모. 실제 손실 고객 수는 공개되지 않음 |
클라우드 회사가 알아서 지켜 주는 거 아니었어?
여기서 많은 분들이 헷갈립니다. 클라우드 회사가 데이터를 ‘여러 벌’ 보관해 주는 건 맞아요. 하드디스크 하나가 고장 나도 데이터가 사라지지 않도록, 보통 같은 건물이나 같은 지역 안에서 자동으로 복제해 둡니다. 하지만 이건 “부품 하나가 고장 날 때”를 대비한 것이지, “건물 전체가 불타는 경우”까지 다 막아 주지는 않습니다.
쉽게 비유하면 이렇습니다. 은행 금고 안에서 서랍 두 칸에 나눠 넣어 둔 것은 서랍 하나가 고장 날 때는 안전하지만, 은행 건물이 통째로 무너지면 두 칸 다 위험하죠. 다른 지점 금고에 하나 더 맡겨 둬야 진짜 안심할 수 있어요. 이 “다른 지점에 하나 더”가 바로 백업입니다.
| 용어 | 쉬운 뜻 | 막아 주는 것 | 못 막는 것 |
|---|---|---|---|
| 복제(이중화) | 같은 데이터를 실시간으로 여러 디스크에 동시에 저장 | 디스크·서버 한 대 고장 | 실수로 지운 파일(사본도 같이 지워짐), 건물 전체 사고 |
| 가용영역(AZ) | 같은 지역 안에서 전기·냉방을 따로 쓰는 독립된 데이터센터 묶음 | 건물 하나 정전·화재 | 내 서버를 한 영역에만 둔 경우, 여러 곳이 동시에 다치는 경우 |
| 백업 | 특정 시점의 데이터를 따로 떼어 다른 곳에 보관한 사본 | 삭제·랜섬웨어·건물 파괴 | 백업을 안 켰거나, 백업도 같은 장소에 둔 경우 |
| 재해 복구(DR) | 멀리 떨어진 다른 지역에서 서비스를 다시 켤 수 있게 준비해 두는 계획 | 지역 전체 마비 | 평소에 연습해 보지 않은 계획 |
이번 사고는 짧은 기간에 여러 데이터센터가 연달아 다쳤다는 점에서 특히 심각했습니다. 가용영역을 나눠 두는 것도 “한 번에 여러 곳이 다칠 일은 드물다”는 가정 위에 서 있는데, 그 가정이 흔들린 거예요.
‘책임 공유’라는 약속, 내 몫은 어디까지?
아마존(AWS), 마이크로소프트, 구글 같은 클라우드 회사들은 모두 ‘책임 공유 모델(Shared Responsibility Model)’이라는 원칙을 이야기합니다. 건물·전기·서버 같은 바탕은 클라우드 회사가, 그 위에 올린 데이터와 설정은 고객이 책임진다는 뜻이에요. 백업을 켤지 말지도 대부분 고객이 고르는 선택지입니다. 얀덱스도 이전까지는 백업을 고객이 직접 켜야 했고, 이번 일을 겪고 나서야 “새로 만드는 서버는 기본으로 켜 두겠다”고 바꾼 것이죠.
| 누구 몫? | 클라우드 회사 | 고객(나·우리 회사) |
|---|---|---|
| 건물·전기·냉방·보안 요원 | ✅ | — |
| 서버·디스크 고장 대비 복제 | ✅ | — |
| 백업 기능 켜기·보관 기간 정하기 | 도구 제공 | ✅ 직접 선택 |
| 서버를 여러 가용영역·지역에 나눠 두기 | 선택지 제공 | ✅ 직접 설계 |
| 실수로 지운 파일, 잘못된 설정 | — | ✅ |
| 복원 연습 | — | ✅ |
한 가지 기억할 점은, 회사들이 사고 뒤 이용료를 면제해 주더라도 사라진 데이터 자체는 돈으로 되돌릴 수 없다는 겁니다. 얀덱스도 피해 보상 차원에서 10월 말까지 클라우드 요금을 받지 않기로 했지만, 날아간 2.84%는 그대로 사라졌어요.
남의 일 같지 않은 우리나라 사례
우리도 비슷한 일을 겪었습니다. 원인은 다 달랐지만 교훈은 같아요. 한 건물에 몰아 두면, 그 건물이 멈출 때 모두 멈춘다는 것입니다.
| 사례 | 원인 | 남긴 교훈 |
|---|---|---|
| 2022년 10월 판교 데이터센터 화재(카카오 장애) | 배터리실 화재로 전원 차단 | 데이터는 남아 있어도, 다른 곳에서 바로 켤 준비가 없으면 며칠씩 서비스가 멈춤 |
| 2025년 9월 국가정보자원관리원 대전 화재 | 배터리 이전 작업 중 화재 | 공무원 업무용 저장소 ‘G드라이브’처럼 따로 백업이 없던 자료는 복구가 어려웠음 |
| 2026년 10월 얀덱스 데이터센터 피격 | 드론 공격으로 여러 곳 동시 파손 | 백업 쓴 고객은 100% 생존, 안 쓴 고객 일부는 영구 손실 → “백업 기본 켜기”로 정책 변경 |
백업의 기본 공식, 3-2-1 규칙
전문가들이 수십 년째 권하는 가장 쉬운 공식이 있습니다. 3-2-1 규칙이에요. 숫자 세 개만 기억하시면 됩니다.
| 상황 | 사본 3개 | 매체 2종 | 멀리 1개 |
|---|---|---|---|
| 개인(가족 사진) | 휴대폰 원본 + 외장 SSD + 클라우드 사진 백업 | 외장 SSD와 클라우드 | 클라우드 사본(집 밖에 있음) |
| 작은 가게(장부·고객 명단) | PC 원본 + USB/NAS + 클라우드 드라이브 | NAS와 클라우드 | 클라우드 또는 다른 장소에 둔 USB |
| 회사(서버·DB) | 운영 서버 + 같은 지역 다른 가용영역 백업 + 다른 지역(리전) 백업 | 디스크 스냅숏과 별도 저장소 | 다른 지역 또는 다른 클라우드 회사 |
요즘은 여기에 “0”을 하나 더 붙여 3-2-1-1-0이라고도 해요. 1개는 지울 수 없게 잠가 둔 사본(랜섬웨어 대비), 0은 복원 시험에서 오류 0개라는 뜻입니다. 백업은 “만들었다”가 아니라 “되살려 봤다”까지 해야 완성이에요.
자주 하는 오해 바로잡기
| 오해 | 사실 |
|---|---|
| “클라우드에 있으면 백업이 된 것” | 클라우드는 보관 장소일 뿐, 백업 기능은 따로 켜야 하는 경우가 많아요. |
| “동기화 폴더면 백업이다” | 동기화는 원본을 지우면 사본도 같이 지워집니다. 휴지통·버전 기록 보관 기간을 꼭 확인하세요. |
| “큰 회사 클라우드는 절대 안 망가진다” | 이번처럼 여러 데이터센터가 동시에 다칠 수도 있어요. 확률은 낮아도 0은 아닙니다. |
| “백업은 회사 IT팀 일” | 휴대폰 사진, 개인 문서는 내가 안 켜면 아무도 안 켜 줍니다. |
| “전쟁 지역 얘기라 상관없다” | 원인이 드론이든 화재·정전·랜섬웨어든 결과는 같아요. ‘건물이 멈추는 날’을 대비하는 게 핵심입니다. |
오늘 밤 5분 점검표
| 순서 | 확인할 것 | 어디서 보나요 |
|---|---|---|
| 1 | 휴대폰 사진 백업이 켜져 있나 | 아이폰: 설정 → 내 이름 → iCloud → 사진 / 안드로이드: 구글 포토·삼성 클라우드 설정 |
| 2 | 중요한 파일이 한 곳에만 있지는 않나 | 계약서·가족 사진·업무 장부는 외장 저장장치나 다른 클라우드에 한 벌 더 |
| 3 | 가게·회사 클라우드 서버의 자동 백업 | 클라우드 관리 화면의 ‘백업’ 또는 ‘스냅숏’ 메뉴에서 일정이 잡혀 있는지 |
| 4 | 백업이 원본과 다른 장소에 있나 | 같은 가용영역·같은 건물이면 함께 다칠 수 있어요. 다른 영역·지역으로 복사 설정 |
| 5 | 복원 연습 | 파일 하나를 골라 실제로 되살려 보기. 한 번이라도 해 봐야 비상시에 당황하지 않아요 |
정리하며
이번 얀덱스 발표에서 가장 기억해야 할 문장은 이것입니다. “백업을 쓴 고객은 100% 보존됐다.” 같은 건물, 같은 사고를 겪었는데 운명을 가른 건 기술력이 아니라 설정 버튼 하나였어요. 클라우드는 정말 편리한 도구지만, “맡겼으니 끝”이 아니라 “다른 곳에 한 벌 더”까지가 내 몫입니다.
오늘 자기 전에 휴대폰 설정에서 사진 백업이 켜져 있는지 한 번만 확인해 보세요. 5분이면 충분하고, 그 5분이 언젠가 10년치 추억을 지켜 줄지도 모릅니다.