기업의 재해 복구 전략은 왜 이렇게 재앙적인가? : zum 뉴스

기업 재해 복구(DR) 전략의 냉혹한 진실 중 하나는 이를 제대로 테스트할 믿을 만한 방법이 사실상 존재하지 않는다는 점이다. 물론 기업은 메커니즘 자체는 충분히 테스트할 수 있지만, 실제로 재해가 발생해 복구 계획이 가동되고 30만 명의 직원과 수백만 명의 고객이 시스템과 상호작용하기 전까지는 모든 게 불확실하다.

IT 리서치 기업 인포테크 리서치 그룹(Info-Tech Research Group)의 수석 자문 이사 프랭크 트로바토는 환경 변화가 실제 상황에서 대부분의 재해 복구 체계가 실패하는 주된 이유라고 말했다.

SaaS의 기하급수적 성장은 조직이 DR과 전체적인 회복력을 다루는 방식을 근본적으로 바꾸어 놓았다. 트로바토는 “기업은 SaaS 장애 복구를 통제할 수 없고, 자체적으로 웜 스탠바이 환경으로 페일오버할 수도 없다. 이는 매우 큰 취약점”이라고 지적했다. 트로바토는 “예를 들어 M365가 장애를 일으키면 조직의 내부·외부 커뮤니케이션은 물론, 팀즈 채널과 셰어포인트, 원드라이브에서 관리되는 프로젝트 업무까지 모두 영향을 받는다. 조직은 상황을 통제할 수 없고, 업체가 문제를 해결해 주길 기다릴 수밖에 없다”라고 설명했다.

요약하면, 서드파티 위험은 업체가 제 역할을 해주길 기대하는 것만으로는 해결되지 않는다.

트로바토는 “SaaS 업체가 백업과 DR 베스트 프랙티스를 따르고 있다고 가정해서는 안 된다. SaaS 업체는 자신들이 서비스를 호스팅하는 클라우드 플랫폼의 탄력성에 기대고 있을 뿐이다. 애저, AWS, GCP가 아무리 높은 가용성을 약속하더라도 이들 플랫폼은 모두 장애를 겪은 적이 있고, 데이터 손실 위험도 존재한다”라고 설명했다.

제대로 시험되지 않는 DR 계획

기업 내부의 정치적 관점에서 보더라도 DR을 책임지는 IT 관리자가 의미 있는 ‘진짜 테스트’를 피하고 싶은 이유는 충분하다. 위험 대비 보상 구조로 보면 더욱 분명해진다. 이들은 복구 환경을 실제로 가동해야 하는 재난이 앞으로 몇 년은 일어나지 않을 것이라고 판단하며, 그때가 되면 자신은 이미 자리를 옮겼을 것이라고 기대한다. 결국 이는 일종의 도박인 셈이다.

만약 실제 재난 상황을 충실히 재현한 테스트가 진행된다면, 그것이 기술적으로 가능하다고 가정하더라도 결과는 두 가지뿐이다. 복구 환경이 제대로 작동하거나, 아니면 실패하거나. 모든 것이 정상적으로 작동한다고 해도 관리자가 특별한 보상을 받을 가능성은 거의 없다. 반면 복구 환경이 실패하면 다양한 책임과 문제가 관리자에게 돌아온다. 그렇다면 굳이 스스로 그런 위험을 초래할 이유가 있을까?

포레스터의 수석 애널리스트 브렌트 엘리스는 “사람들은 자신이 마련해 둔 전략과 워크플로우를 테스트하는 것을 두려워한다. 현재 갖춰진 DR 전략이 실제로 효과를 발휘할 것이라는 확신이 없기 때문”이라고 말했다.

IT 솔루션 업체 엠마 테크놀로지스(Emma Technologies) CEO 드미트리 파넨코프도 “CIO는 장애 상황에서 30만 명의 직원의 움직임을 시뮬레이션할 수 없다. 결국 중요한 테스트는 핵심 애플리케이션이 몇 주간의 고립을 견딜 수 있느냐인데, 지금으로서는 대부분 기업이 이를 충족하지 못한다”라고 지적했다.

IT 리서치 기업 그레이하운드 리서치(Greyhound Research)의 수석 애널리스트 산칫 비르 고기아도 “이런 테스트가 성공적으로 끝난다고 해도 경력에 큰 도움이 될 가능성은 없다. 기업은 프레젠테이션 슬라이드 상으로 완성돼 보이는 DR 전략을 과신하지만, 실제 혼란이 닥치면 대부분 무너진다. 문제는 복구의 정의가 잘못 설정된 데서 시작된다. 인프라가 다시 작동하는 것만으로는 충분하지 않으며, 비즈니스가 실제로 계속 운영될 수 있어야 진정한 복구인데, 많은 기업이 이 격차를 메우지 못하고 있다”라고 말했다.

고기아는 “대부분 DR 계획은 실제 장애를 처리하기보다 감사 대응을 만족시키는 데 초점을 둔다. 테스트 역시 얕고 수개월씩 건너뛰기 일쑤며, 현실성을 제거한 상태로 진행된다. IT 부서는 시스템이 응답하는지만 확인할 뿐, 수천 명의 사용자가 예측 불가능하게 움직이고 서비스 레이어가 서로 얽히며 의사결정권자들이 압박 속에서 우왕좌왕할 때 어떤 일이 발생하는지는 아무도 지켜보지 않는다”라고 설명했다.

이어 “테스트 시나리오는 전체 페일오버, 실제 트래픽, 여러 팀의 참여, 페일백까지 포함해 현실적이어야 한다. 현실 세계의 혼란스러움을 반영하지 않는다면 조직은 아무 준비도 한 것이 아니다. 주요 DR 테스트 도구조차 같은 문제에서 자유롭지 않다”라고 덧붙였다.

대부분의 DR 도구, 심지어 DRaaS(Disaster Recovery as a Service)도 IT 자산의 일부만 보호한다. ”이라고 설명했다. 고기아는 “도구 범위는 예산이나 구현 편의성에 맞춰 좁게 설정되며, 전체적인 복구를 보장하도록 설계되지 않는다. 클라우드 의존도가 높은 환경에서는 팀이 탄력성이 자동으로 확보돼 있다고 잘못 가정하는 바람에 상황이 더 악화한다. 실제로는 페일오버 경로를 구성하지 않았거나, 지역 간 복제도 이루지 않았거나, 페일오버 후 워크로드 검증도 하지 않은 경우가 많다”라고 말했다.

또한 “주권 클라우드(sovreign cloud) 전략이 지정학적 리스크를 완화하는 데는 의미가 있을 수 있지만, 운영 현실성 문제를 해결하지는 못한다”라고 지적했다.

DR 테스트의 가장 큰 결함은 인프라가 곧 서비스라는 잘못된 가정이다. 대부분 기업은 시스템이 부팅되는지, 데이터를 복구할 수 있는지, 대시보드가 초록색 상태인지 정도만 확인한다. 하지만 이는 복구가 아니다. 정적인 체크리스트에 불과하다. 고기아는 “실제 재난 상황에서는 시스템이 온라인 상태가 되더라도 사용자가 접근하지 못하는 일이 빈번하다. 인증 루프, 잘못된 트래픽 라우팅, 불명확한 커뮤니케이션, 혼란스러운 사용자 행동 등 수많은 장애 요소가 발생한다. 테스트가 놓치고 있는 것은 10만 명의 사용자가 불완전한 정보를 바탕으로 행동하고, 내부 팀이 분절된 프로세스 속에서 허둥대며 만들어내는 ‘엔트로피’”라고 강조했다.

DR 실패를 키우는 서드파티 의존성과 조직 내 사일로

대다수 기업의 DR 전략에는 더 깊은 구조적 문제가 존재한다. 대표적인 예가 여러 대형 클라우드 서비스를 조합해 사용하는 방식이다. 가령 “구글이 장애를 일으켜도 마이크로소프트와 AWS가 동시에 멈출 가능성은 낮다”라는 논리다. 하지만 이런 가정은 공통되는 서드파티 의존성을 현실적으로 고려하지 못한다는 점에서 오류가 있다. 클라우드플레어와 크라우드스트라이크 사례가 이미 이를 명확하게 보여준 바 있다.

많은 기업이 입찰에 참여하는 모든 업체에 사용 중인 서드파티 목록을 요구한다. 이는 분명 좋은 출발점이다. 그러나 너무 많은 부서가 여기에서 멈춘다. 여기서 더 나아가, 해당 서드파티가 장애를 일으킬 경우에는 어떤 비상 계획을 갖고 있는지, 실제로 장애가 발생하면 어떤 영향이 예상되는지, 장애 시 보상이나 배상 조치를 제공할 수 있는지까지 요구해야 한다.

포레스터의 엘리스는 입찰 기업에 대해 “이들은 분명히 일정 수준의 책임을 져야 한다”라고 말했다.

파넨코프 역시 같은 의견을 제시하며 “모든 상호 의존성을 이해해야 한다. 특히 서드파티가 변경되거나 새로운 서비스를 도입할 때, 그것이 기업에 어떤 영향을 미칠지 파악하는 것이 중요하다”라고 강조했다.

최근 DR 문제는 마이크로소프트가 SAP, 캡제미니, 오렌지(Orange)와 체결한 유럽 사용자용 DR 플랫폼 계약 사례에서도 드러났다. 마이크로소프트가 특정 지역 지원을 중단하라는 명령을 받을 경우를 대비한 플랫폼이었는데, 정작 핵심 마이크로소프트 서비스가 제외된 마이크로소프트 인프라는 기대만큼 유용하지 않다는 점이 확인됐다.

엘리스는 기업 DR 계획을 복잡하게 만드는 또 다른 문제로 현업(Line-of-Business, LOB) 부서에 대한 권한 확대를 꼽았다. 최근 LOB 책임자는 최신 생성형 AI 도구나 에이전트 등을 자유롭게 도입하고 실험할 수 있는 재량을 부여받고 있다. 그러나 무어 인사이트 & 스트래티지의 부사장이자 수석 애널리스트인 로버트 크레이머는 LOB 경영진이 자신들이 도입하는 기술적 변화를 모두 IT에 공유하지 않는 경우가 많다고 지적한다. 각 부서가 독자적으로 움직이면 DR 전략에 치명적인 공백이 생길 수 있다.

크레이머는 “LOB 자율성 문제는 매우 심각하다. 방향을 모른 채 다리를 건설할 수 없는 것과 같다. 각 사업 부서가 제각각 움직이면 문제가 발생할 수밖에 없다”라고 말했다.

DR 시스템이 정상적으로 작동하더라도, 직원이 백업 시스템이나 소프트웨어에 익숙하지 않으면 다운타임 대응 계획이 제대로 구현되지 않는 경우가 많다. 엘리스는 그 예로, 마이크로소프트 서비스가 중단돼 시스템이 임시 방편으로 구글 독스(Google Docs)를 사용하는 상황을 들며 “사용 환경이 완전히 다르기 때문에 페일오버가 발생하면 생산성이 급격하게 떨어진다. SaaS 플랫폼에 이르면 상황은 훨씬 더 복잡해진다”라고 말했다.

DR 플랫폼이 직면한 가장 분명한 문제는 어떤 유형의 재난이 DR 시스템 작동을 촉발할지 알 수 없다는 점이다. 재난은 단순한 인터넷 장애일 수도 있고, 사실상 모든 전력과 무선 통신을 마비시키는 지진·토네이도·해일 같은 자연 재해일 수도 있으며, 군사 공격이나 테러일 수도 있다.

재난의 범위가 어느 정도인지 역시 중요한 문제다. 미러링된 복구 환경을 800km 떨어진 곳에 구축하는 것이 적절한 선택일까? 2000km까지 떨어져 있어야 할까? 해외에 구축해야 한다면 어느 국가가 적합할까?

더 나아가 구글이나 아마존 설립자 제프 베이조스가 구상하는 우주 기반 초대형 데이터센터 논의까지 고려하면, DR 옵션에 ‘우주 시설’을 포함해야 하는 것 아니냐는 질문까지 제기된다.

물론 우리는 여전히 지구에 머물러 있다. 그러나 이곳의 IT 책임자들은 큰 사고가 자신의 재임 시기에만 일어나지 않기를 바랄 뿐이다. 이는 재앙을 기다리는 것과 다르지 않다.

dl-itworldkorea@foundryco.com