데이터센터 / 보안

글로벌 칼럼 | 원숭이도 나무에서 떨어진다

Susan Bradley | Computerworld 2022.04.21
보통 솔루션 업체가 완벽하다고 생각하기 쉽다. 업체는 백업과 예비 설비를 갖췄고, 실패 없이 솔루션을 배포하는 방법을 정확히 아는 전문가도 보유하고 있다. 그런데 현실을 보면 기대와 다르다. 일반 기업보다 나은 게 없다.
 
ⓒ Getty Images Bank

최근의 몇 가지 사례를 보자. 스토리지크래프트(StorageCraft)는 중소중견기업 시장에서 오랜 기간 신뢰를 받아온 백업 소프트웨어 업체다. 쉬운 이미지 백업을 주창한 최초의 업체 중 하나로, 많은 관리형 서비스 기업이 이 업체의 제품을 추천하고 사용한다. 2021년 3월 아크서브(Arcserve)에 인수된 뒤에도 이 업체의 전반적인 운영에는 큰 변화가 없었다.

그런데 지난 3월 이 업체의 클라우드 백업 중 상당수가 영구 손실됐다. 블록스 앤 파일스(Blocks and Files) 보도에 따르면, 스토리지크래프트는 최근 정상적인 유지보수 작업 중 중요한 메타데이터가 포함된 예비 서버 어레이가 영구적으로 제거됐다. 그 결과 일부 메타데이터가 손상됐고 스토리지 환경과 DRaaS 클라우드(클라우드 서비스) 간의 핵심 링크가 끊어졌다. 엔지니어들이 노력했지만 메타데이터와 스토리지 시스템 간의 이 링크를 재설정할 수 없었고 결과적으로 데이터를 사용할 수 없게 됐다. 즉
이 업체의 협력업체가 데이터센터에서 시스템을 복제하거나 복구할 수 없음을 의미한다.

업체는 4월 16일 보고서를 통해 "영향을 받은 모든 시스템을 복구하고 있다. 모든 스로틀링이 비활성화됐고 업로드는 정상적으로 작동한다. 데이터 복제에 드는 시간은 각 고객의 업로드 대역폭과 데이터 볼륨에 따라 다르다”라고 추가로 공지했다. 그러나 클라우드 저장소에 이전 백업을 남겨두려 했던 기업 고객에는 전혀 도움이 되지 않는 내용이었다.

아틀라시안(Atlassian)의 사례도 있다. 지난 4월 4일 약 400곳의 아틀라시안 클라우드 기업 고객에서 아틀라시안 제품 전반이 완전히 작동하지 않는 장애가 발생했다. 업체가 사이트를 통해 공지한 내용은 이렇다.
 

지라(Jira) 서비스 관리 및 지라 소프트웨어를 위한 독립형 앱 중 하나인 ‘인사이트-애셋 매니지먼트(Insight – Asset Management)’는 아틀라시안 제품에 기본 기능으로 통합돼 있는데, 독립형 레거시 앱이 설치된 고객 사이트에서는 이 앱을 비활성화해야 했다. 엔지니어링팀의 원래 계획은 기존 스크립트를 사용해 이 독립형 애플리케이션의 인스턴스를 비활성화하는 것이었는데, 여기서 두 가지 중대한 문제가 발생했다.

첫째는 커뮤니케이션 부족이다. 비활성화를 요청한 팀과 비활성화를 실행한 팀 간의 커뮤니케이션이 부족했다. 팀은 비활성화할 앱의 ID를 제공하는 대신 앱이 비활성화될 클라우드 사이트 전체의 ID를 넘겼다. 둘째는 잘못된 스크립트다. 이번 사용된 스크립트는 일상적인 운영에 사용되는 ‘삭제 표시’ 기능, 그리고 규정 준수를 위해 필요할 때 영구적으로 데이터를 제거하는 데 사용하는 ‘영구 삭제’ 기능, 2가지를 모두 실행했다. 결국 팀은 잘못된 실행 모드와 잘못된 ID 목록으로 이 스크립트를 실행했고 400여 고객사의 사이트가 삭제됐다.


두 사건의 영향을 받은 직접적인 기업이 아니라고 해도 이번 사건의 교훈을 살펴볼 가치는 충분하다. 무엇보다, 계약서든 사용권 약관이든 업체와 계약할 때는 문제 발생 시 업체의 책임이 무엇이고 가용한 구제책은 무엇인지를 검토해야 한다.

두 사례에서 스토리지크래프트와 아틀라시안은 기업 고객과 계약할 때 동의한 조항에 따라 대처할 것이다. 대기업 고객이라면 계약 조건과 가용한 구제책을 어느 정도 제어할 수 있다. 하지만 소규모 기업 고객이라면 최종 사용자 사용권 계약과 이 계약에 포함된 약관에 따라 업체의 의무 사항이 정해진다. 업체와 그 서비스에 의존한다면 언젠가 잘못될 수 있음을 가정하고 계획해야 한다.

검토해야 할 핵심은 정상적인 경우의 조항이 아니라 업체가 실수를 저질렀을 때 업체의 의무에 대한 조항이다. 피해 금액을 보상하는가? 완전하거나 그에 근접한 복원을 위해 부가적인 작업을 수행하는가? 많은 경우 업체가 문제를 얼마나 빨리 인정하느냐가 데이터를 어떻게 처리할지보다 더 중요하다.

또한, 두 사건 모두 원인은 사람의 실수였다. 필자는 DOS 컴퓨터로 작업하던 시절 원래 의도했던 하위 디렉터리가 아닌 C 드라이브의 루트에서 del *.*을 입력했던 실수를 아직도 기억한다. 그때 얻은 교훈이 지금도 유효하다. 삭제와 관련된 작업을 할 때마다 필자는 항상 잠시 멈추고 실수를 대비한 백업이 있는지, 이 작업을 어디에서 하고 있는지, 그리고 올바른 파일을 삭제하고 있는지를 다시 확인한다.

개인 사용자든 컴퓨터 네트워크(온프레미스 또는 클라우드)를 다루는 사용자든 항상 전체 백업해 둬야 한다. 문제가 발생한 이후 복구할 방법을 2가지 이상 마련하는 것도 좋다. 전체 백업에서 간단한 디렉터리 복사에 이르기까지 데이터 복구 방법을 유연하게 마련해야 한다.

MSP(Managed Service Provider)가 해야 할 것도 있다. 먼저 실무자가 스크립트를 철저히 검토하도록 해야 한다. 스크립트를 재사용하면서 여전히 잘 작동할 것으로 전제하고 제대로 검토하지 않는 경우가 많다. 아틀라시안 사고의 세부 내용을 읽다 보면 안타까운 순간이 많다. 팀의 커뮤니케이션이 부족했고, 결국 지우면 안 되는 정보를 삭제했다. 인프라에 대한 중대한 변경을 계획할 때는 커뮤니케이션이 핵심이다.

업체와 기업 고객 간의 커뮤니케이션도 마찬가지다. 필자는 마이크로소프트 365 사용자인데, 보통 2가지 플랫폼을 활용해 문제를 추적한다. 마이크로소프트 365 트위터 계정은 문제가 발생할 때 알림을 보내준다(트위터 앱을 다운로드해서 상태 변경 시 푸시 알림을 수신하도록 설정하면 된다). 또는 메시지 센터에서 알림을 설정해 소식을 받는 방법도 있다. 자주 사용하는 업체 솔루션이 있다면 해당 업체가 사용자에게 최신 정보를 알리는 커뮤니케이션 채널을 운영 중인지 확인해야 한다.

정리하면, 기술을 제어하는 것은 인간의 의사 결정이고 인간은 실수한다는 점을 유념해야 한다. 실수가 일어나지 않는다고 전제해서는 안 된다. 업체도 결국은 사람이다. 업체가 실수를 저지를 때 어떻게 대처할지를 기업이 계획을 세워야 하는 이유다.
editor@itworld.co.kr

회사명 : 한국IDG | 제호: ITWorld | 주소 : 서울시 중구 세종대로 23, 4층 우)04512
| 등록번호 : 서울 아00743 등록발행일자 : 2009년 01월 19일

발행인 : 박형미 | 편집인 : 박재곤 | 청소년보호책임자 : 한정규
| 사업자 등록번호 : 214-87-22467 Tel : 02-558-6950

Copyright © 2024 International Data Group. All rights reserved.