재해복구(DR)는 기업 IT 거버넌스에서 가장 엄숙한 영역 중 하나다. 데이터센터가 불타거나 랜섬웨어가 시스템을 잠가버리는 최악의 순간, "지금 복구를 시작하라"는 결정은 반드시 권한 있는 인간의 판단에서 나와야 했다. 그런데 AI 클라우드 자동화가 그 판단을 조용히 가져가고 있다. 2026년 현재, 주요 클라우드 플랫폼에 내장된 AI 도구들은 장애 감지부터 페일오버 실행, 워크로드 재배치, 심지어 복구 완료 선언까지 일련의 과정을 인간의 명시적 승인 없이 처리하는 방향으로 빠르게 진화하고 있다.

문제는 속도가 아니다. 복구가 빠를수록 좋다는 건 누구나 안다. 문제는 그 결정이 누구의 이름으로, 어떤 근거로, 어떤 승인을 받아 실행됐는가를 나중에 증명할 수 없다는 것이다.

재해복구가 특별한 이유: 최악의 순간에 내려지는 최대 권한의 결정

일반적인 클라우드 자동화와 DR 자동화는 본질적으로 다르다. 스케일링 자동화는 서버를 한 대 더 추가하는 결정이다. 하지만 DR 자동화는 다음과 같은 결정들을 포함한다.

프라이머리 데이터베이스를 오프라인으로 전환하고 세컨더리를 마스터로 승격
수백 개의 워크로드를 다른 리전 또는 다른 클라우드로 이동
백업 데이터를 특정 시점으로 롤백 — 즉, 그 이후에 생성된 데이터는 사라짐
비상 접근 권한을 임시로 확장 — 평시엔 금지된 권한이 열림
외부 파트너 시스템과의 연결을 강제로 재구성

이 결정들 하나하나는 평시라면 변경관리위원회(CAB), 법무팀, CISO의 승인이 필요한 수준의 변경이다. 그런데 DR 상황에서는 "빠른 복구"라는 명분 아래 이 모든 과정이 AI의 자율 판단으로 압축 실행된다.

더 심각한 것은 타이밍이다. 재해 상황은 정의상 최대 스트레스, 최소 가시성, 최소 인력이 동시에 겹치는 순간이다. 시스템이 다운됐을 때 감사 로그를 실시간으로 검토하는 사람은 없다. AI가 무엇을 결정했는지 확인할 여유가 없다. 그리고 복구가 끝나고 나면, 그 결정들은 이미 돌이킬 수 없는 사실이 되어 있다.

AI 클라우드 DR 자동화의 현실: 무엇이 이미 일어나고 있나

Server rack with blinking green lights

Photo by Domaintechnik Ledl.net on Unsplash

AWS, Azure, GCP 모두 2024~2025년을 기점으로 AI 기반 DR 기능을 대폭 강화했다. 이름은 다르지만 구조는 비슷하다. 이상 감지 → 영향 범위 분석 → 복구 계획 수립 → 실행 — 이 파이프라인을 AI가 자율적으로 처리한다.

AWS의 경우 Amazon Route 53 Application Recovery Controller와 AWS Resilience Hub가 결합되면서, 사전에 정의된 복구 목표(RTO/RPO)를 충족하기 위해 자동 페일오버를 실행할 수 있다. 인간이 "승인" 버튼을 누르지 않아도 된다. 사전에 정책을 설정해두면 AI가 그 정책의 해석자이자 실행자가 된다.

Azure의 Azure Site Recovery는 이미 수년 전부터 자동 페일오버를 지원했지만, 최근 Copilot 기반 기능이 통합되면서 복구 계획 자체를 AI가 동적으로 재구성하는 방향으로 진화하고 있다. 단순히 "미리 짜둔 계획을 실행"하는 것이 아니라, 상황에 따라 계획을 수정하고 실행하는 것이다.

GCP의 경우 Backup and DR 서비스와 Vertex AI 기반 이상 감지가 연동되면서, 데이터 손상이나 랜섬웨어 감지 시 자동 격리 및 복구 절차를 트리거할 수 있다.

이 모든 기능의 공통점: "누가 이 복구를 승인했는가"라는 질문에 대한 답이 없다. 있다면 "AI가 정책에 따라 실행했습니다"뿐이다.

거버넌스 공백: 감사관이 마주치는 세 가지 벽

DR 자동화가 실행된 후 감사관이 들어온다고 가정하자. 그들이 마주치는 현실은 다음과 같다.

첫 번째 벽: 승인 주체의 부재

전통적인 DR 절차에는 반드시 DRP(재해복구계획) 발동 권한자가 있다. 보통 CTO, CISO, 또는 지정된 DR 코디네이터다. 그들의 서명이 있어야 복구가 시작된다. 이 서명은 단순한 절차가 아니라, "나는 이 상황을 인지했고, 이 복구가 적절하다고 판단했으며, 그 결과에 책임진다"는 법적·조직적 선언이다.

AI 자동화는 이 선언을 없앤다. 로그에는 "시스템이 임계값을 초과하여 자동 복구가 실행됨"이라고 적혀 있다. 누가 그 임계값을 설정했는지, 그 설정이 현재 비즈니스 맥락에 여전히 적합한지는 로그에 없다.

두 번째 벽: 데이터 레지던시와 규제 준수의 충돌

AI 클라우드 DR 시스템이 "가장 빠른 복구"를 위해 워크로드를 다른 리전으로 이동시켰다고 하자. 그런데 그 리전이 GDPR 적용 범위 밖이라면? 또는 금융 규제상 국내 데이터가 해외 서버에 저장되는 것이 금지된 경우라면?

AI는 RTO를 최소화하는 방향으로 최적화됐을 뿐, 데이터 레지던시 규제를 실시간으로 해석하지 않는다. 물론 사전에 제약 조건을 설정할 수 있다. 하지만 그 설정이 최신 규제를 반영하고 있는지, 예외 상황을 모두 커버하는지는 별개의 문제다.

국내 금융권의 경우 금융보안원 가이드라인은 재해복구 절차에서 핵심 의사결정의 인간 승인을 명시적으로 요구한다. AI가 자동 실행한 DR이 이 요건을 충족하는지는 현재 회색지대에 있다고 보인다.

세 번째 벽: 롤백 불가능한 결정의 감사 불능

가장 심각한 문제는 데이터 롤백이다. AI가 "이 시점의 백업이 최적"이라고 판단하고 복구를 실행하면, 그 이후 시점의 데이터는 사라진다. 이 결정은 되돌릴 수 없다.

만약 AI가 선택한 복구 시점이 실제로는 이미 손상된 데이터를 포함하고 있었다면? 또는 규제 보존 의무가 있는 데이터가 그 과정에서 삭제됐다면? 감사관은 "왜 그 시점을 선택했는가"를 물을 것이고, 답은 "AI의 알고리즘이 그렇게 판단했습니다"가 된다.

이것은 단순한 기술적 문제가 아니다. 쿠팡 데이터 유출 사례에서 확인할 수 있듯, 데이터 관련 거버넌스 실패는 분기 단위의 막대한 재무적 손실과 직결된다. DR 자동화의 거버넌스 공백은 평시엔 보이지 않다가 사고가 터진 후에야 그 비용이 드러난다.

"정책 기반 자동화"의 함정: 승인을 앞으로 당기면 해결되는가

AI DR 자동화를 옹호하는 측의 가장 흔한 반론은 이것이다: "사전에 정책을 설정하고 승인했으니, 그 정책에 따른 자동 실행도 승인된 것이다."

이 논리는 표면적으로 합리적이다. 하지만 세 가지 이유에서 거버넌스 관점의 해답이 되지 못한다.

첫째, 정책 설정 시점과 실행 시점 사이의 맥락 변화. 6개월 전에 설정한 DR 정책이 오늘의 비즈니스 맥락, 규제 환경, 시스템 구성을 반영하고 있다는 보장이 없다. 인간 승인자는 실행 시점의 맥락을 판단에 반영할 수 있지만, 정책 기반 AI는 그럴 수 없다.

둘째, 정책의 해석 범위. AI는 정책을 문자 그대로 해석하지 않는다. 머신러닝 기반 시스템은 정책의 의도를 추론하고, 명시되지 않은 상황에 대해 판단을 내린다. 이 "해석"이 정책 설정자의 의도와 일치한다는 보장은 없다.

셋째, 감사 요건의 본질. ISO 22301(비즈니스 연속성 관리), SOC 2, 국내 정보보호 관리체계(ISMS-P) 등 주요 규제 프레임워크는 단순히 "승인이 존재했는가"가 아니라 "권한 있는 개인이 해당 시점의 상황을 인지하고 판단했는가"를 요구한다. 사전 정책 설정은 이 요건의 대리물이 될 수 없다.

AI 클라우드 DR 거버넌스를 재설계하는 실질적 접근

이 문제의 해법은 AI 자동화를 제거하는 것이 아니다. DR 상황에서 속도는 실제로 중요하다. 해법은 자동화의 속도와 거버넌스의 요건을 동시에 충족하는 구조를 설계하는 것이다.

1. DR 자동화의 의사결정 계층 분리

모든 DR 결정이 동일한 승인 요건을 가질 필요는 없다. 다음과 같은 계층 구조가 현실적이다.

자율 실행 허용: 헬스체크 재시작, 트래픽 재라우팅, 임시 캐시 플러시 등 가역적이고 범위가 제한된 조치
비동기 알림 후 실행: 단일 리전 내 페일오버 등 규제 리스크가 낮은 조치 — 실행 후 즉시 지정 승인자에게 통보, 일정 시간 내 거부 가능
동기 승인 필수: 리전 간 데이터 이동, 백업 롤백, 비상 권한 확장 — 반드시 지정 승인자의 명시적 확인 후 실행

2. "AI 결정 이유서" 자동 생성 의무화

AI가 DR 결정을 내릴 때마다 인간이 읽을 수 있는 형식의 결정 이유서를 자동 생성하도록 설계해야 한다. 이 이유서에는 다음이 포함돼야 한다.

어떤 지표가 임계값을 초과했는가
어떤 대안을 고려했고 왜 이 옵션을 선택했는가
이 결정이 어떤 정책 조항에 근거했는가
예상되는 영향 범위와 롤백 가능성

이것은 단순한 로그가 아니다. 감사관이 "누가 왜 이 결정을 내렸는가"를 재구성할 수 있는 서술형 감사 증거다.

3. DR 정책의 정기적 재승인 사이클

AI가 실행하는 DR 정책은 최소 분기 1회, 주요 시스템 변경 시마다 권한 있는 승인자의 재검토와 재승인을 받아야 한다. 이 재승인 기록이 "AI 자동화의 위임 근거"가 된다. 단, 이 재승인이 형식적 체크박스가 되지 않도록 실질적인 변경사항 요약과 리스크 평가를 함께 제시해야 한다.

4. 포스트-DR 거버넌스 리뷰의 의무화

복구 완료 후 24시간 이내에 DR 거버넌스 리뷰를 의무적으로 실시해야 한다. 이 리뷰에서는 AI가 내린 모든 결정을 인간이 사후 검토하고, 각 결정의 적절성을 평가하며, 이의가 있는 결정에 대해서는 공식 기록을 남긴다. 이 과정 자체가 감사 증거가 된다.

규제 환경의 변화: 인간 책임을 요구하는 흐름

2025~2026년 글로벌 규제 환경은 AI 자동화에 대한 인간 책임 요건을 강화하는 방향으로 움직이고 있다. EU AI Act는 고위험 AI 시스템에 대해 "인간 감독(human oversight)" 요건을 명시하고 있으며, 금융·의료·핵심 인프라 분야의 자동화 의사결정에 대해 특히 엄격한 기준을 적용한다.

국내에서도 개인정보보호위원회와 금융위원회는 자동화된 의사결정 시스템에 대한 투명성과 설명 가능성 요건을 강화하는 추세다. DR 자동화가 개인정보를 포함한 데이터의 처리 방식을 변경하는 경우, 이는 자동화된 개인정보 처리 결정으로 해석될 가능성이 있다.

흥미로운 비교 사례로, 신약 개발 분야의 AI 자동화에서도 유사한 거버넌스 질문이 제기된다. AI가 분자 설계를 자율적으로 수행할 때 "누가 이 결정에 책임지는가"라는 문제는 DR 자동화와 구조적으로 동일하다. 기술 도메인은 달라도, 자율 AI 결정에 대한 인간 책임 귀속의 문제는 공통적이다.

NIST의 사이버보안 프레임워크(CSF) 2.0은 복구(Recover) 기능에 대해 "복구 계획의 실행은 승인된 절차에 따라야 한다"고 명시하고 있다. AI 자동화가 이 "승인된 절차"의 요건을 충족하는지는 각 조직이 명확히 정의해야 할 과제다.

DR 자동화가 드러내는 더 큰 질문

이 시리즈에서 우리는 AI 클라우드 자동화가 IAM, 컴플라이언스, 운영 책임, 네트워크 구성, 암호화, 멀티클라우드 배치, 스토리지 라이프사이클, 비용 최적화에 이르기까지 기업 IT의 거의 모든 의사결정 영역을 조용히 장악해가는 과정을 추적해왔다.

DR 자동화는 그 중에서도 특별한 위치를 차지한다. 재해복구는 기업이 가장 취약한 순간에 가장 중요한 결정을 내리는 영역이기 때문이다. 그 순간에 "누가 결정했는가"를 증명할 수 없다면, 복구가 성공했더라도 거버넌스는 실패한 것이다.

기술은 빠르게 진화한다. 하지만 "권한 있는 인간이 맥락을 인지하고 판단했다"는 거버넌스의 본질적 요건은 AI 시대에도 변하지 않는다. 변해야 하는 것은 그 요건을 자동화 환경에서 어떻게 충족할 것인가에 대한 설계다.

AI 클라우드가 재해복구를 더 빠르고 안정적으로 만드는 것은 분명한 진보다. 하지만 그 진보가 감사 불능의 블랙박스 안에서 이루어진다면, 우리는 기술적 회복력을 얻는 대신 거버넌스 취약성을 지불하고 있는 셈이다. 그 거래의 조건을 명확히 인식하고 설계하는 것이 지금 CTO, CISO, 그리고 이사회가 해야 할 일이다.

태그: AI 클라우드, 재해복구, DR 자동화, 클라우드 거버넌스, 컴플라이언스, 감사, 비즈니스 연속성

AI 클라우드, 이제 "언제 시스템을 되살릴지"도 스스로 결정한다 — 재해복구 자동화가 지우는 거버넌스의 마지막 방어선

결론: 빠른 복구보다 중요한 것

재해복구는 오랫동안 IT 조직의 "최후 보루"였다. 모든 것이 무너졌을 때, 마지막으로 인간이 판단하고, 인간이 결정하고, 인간이 책임지는 영역. 그런데 지금 그 최후 보루에 AI가 들어서고 있다.

AWS, Azure, GCP가 제공하는 AI 기반 DR 자동화 도구들은 RTO를 시간 단위에서 분 단위로, 분 단위에서 초 단위로 줄이고 있다. 이것은 분명히 기술적 진보다. 하지만 기술적 회복력(resilience)과 거버넌스 건전성(governance integrity)은 같은 말이 아니다.

우리가 이 시리즈 전체에서 반복적으로 확인해온 패턴이 여기서도 동일하게 나타난다.

AI는 실행한다. 하지만 아무도 승인하지 않았다.

DR 자동화의 경우, 이 문제는 더욱 예리하게 드러난다. 재해 상황은 정의상 "최대 스트레스, 최소 가시성, 최소 통제력"의 순간이다. 바로 그 순간에 AI가 가장 중요한 결정들을 연속적으로 실행한다. 어느 워크로드를 먼저 복구할 것인가. 어느 리전으로 페일오버할 것인가. 어느 스냅샷 시점으로 되돌릴 것인가. 데이터 일부를 영구 삭제할 것인가.

이 결정들 각각에 대해, 사후 감사에서 규제기관이 묻는 질문은 단순하다.

"누가 이것을 승인했습니까?"

그리고 AI 자동화 환경에서 그 질문에 답할 수 있는 조직은 아직 많지 않다.

그렇다면 무엇을 해야 하는가

필자는 이 시리즈에서 줄곧 "AI 자동화를 멈춰야 한다"고 주장하지 않았다. 그것은 현실적이지도 않고, 바람직하지도 않다. AI 기반 DR 자동화가 가져오는 속도와 정확성의 이점은 실질적이다. 인간이 새벽 3시에 전화를 받고 반쯤 잠든 상태로 페일오버 스크립트를 실행하는 것보다, 잘 설계된 AI 자동화가 더 나은 결정을 내릴 수 있다.

문제는 자동화 자체가 아니라, 자동화 설계 안에 거버넌스가 내재되어 있는가다.

실천적으로, 지금 당장 조직이 점검해야 할 질문들을 정리하면 다음과 같다.

첫째, DR 자동화의 의사결정 범위를 명시적으로 정의했는가? AI가 자율 실행할 수 있는 결정과, 반드시 인간 승인을 거쳐야 하는 결정을 명시적으로 구분한 문서가 존재하는가. "AI가 알아서 한다"는 기본값은 거버넌스 문서가 아니다.

둘째, AI의 DR 결정에 대한 감사 로그가 규제 요건을 충족하는가? 기술 로그(technical log)와 감사 증거(audit evidence)는 다르다. 감사에서 요구하는 것은 "언제 무슨 일이 일어났는가"가 아니라 "누가, 어떤 맥락에서, 어떤 권한으로 이 결정을 승인했는가"다. AI 추천 로그가 그 질문에 답할 수 있는가.

셋째, DR 자동화가 실행되는 동안 인간 감독자의 역할이 정의되어 있는가? "AI가 자동으로 복구한다"는 것이 "인간은 아무것도 하지 않는다"를 의미하면 안 된다. AI가 실행하는 동안 인간 감독자가 무엇을 모니터링하고, 언제 개입하며, 어떤 결정을 override할 수 있는지가 명확히 정의되어 있어야 한다.

넷째, DR 자동화 설계 자체가 변경관리 프로세스를 거쳤는가? AI 자동화 룰셋, 임계값, 우선순위 설정은 그 자체로 중요한 정책 결정이다. 이것이 누군가의 노트북에서 조용히 업데이트되고 있다면, 그것은 변경관리 없이 운영 정책이 바뀌는 것과 같다.

이 시리즈가 말하고자 했던 것

지난 수개월간 이 시리즈는 AI 클라우드 자동화가 기업 IT의 각 영역을 어떻게 조용히 재편하고 있는지를 추적해왔다. IAM에서 시작해서, 컴플라이언스, 운영 책임, 네트워크, 암호화, 멀티클라우드, 스토리지, 비용 최적화, 그리고 오늘의 재해복구까지.

각 영역에서 우리가 발견한 것은 동일한 구조적 패턴이었다.

AI는 개별 작업을 자동화하는 것에서 시작했다. 그것은 분명히 유용했다. 그러다 AI는 개별 작업들을 연결하기 시작했다. 그것도 여전히 관리 가능해 보였다. 그런데 어느 순간, AI는 그 연결된 작업들을 통해 사실상 정책 수준의 결정을 내리기 시작했다. 그리고 그 결정에는 아무도 서명하지 않았다.

이것이 2026년 현재 기업 클라우드 거버넌스가 직면한 핵심 문제다. 기술은 빠르게 앞서 나갔고, 거버넌스 설계는 그 속도를 따라가지 못했다.

필자가 이 시리즈를 통해 전달하고 싶었던 메시지는 하나다.

AI가 결정하는 것을 막을 수는 없다. 하지만 AI가 결정하도록 설계한 것은 인간이다. 그 설계에 대한 책임은 여전히 인간에게 있다.

CTO는 "우리 DR은 완전 자동화되어 있습니다"라고 자랑스럽게 말할 수 있다. 하지만 동시에 "그 자동화의 모든 결정에 대해 누가 책임지는지 저는 명확히 설명할 수 있습니다"라고도 말할 수 있어야 한다. 지금 그 두 문장을 모두 자신 있게 말할 수 있는 CTO가 얼마나 되는지, 필자는 솔직히 회의적이다.

재해는 예고 없이 찾아온다. 하지만 거버넌스 공백은 예고된 재해다. 그리고 그 재해를 막을 시간은, 지금이다.