AI 클라우드, 이제 "언제 백업하고 무엇을 복구할지"도 스스로 결정한다 — 그 판단은 당신이 승인했는가?

백업은 IT 인프라에서 가장 '조용한' 영역이다. 평소엔 아무도 신경 쓰지 않다가, 무언가 터졌을 때 비로소 그 존재가 드러난다. 그리고 지금, AI 클라우드는 이 조용한 영역에 조용히 손을 뻗고 있다. "언제 백업할지", "어떤 데이터를 얼마나 오래 보관할지", "복구 시 어떤 버전을 우선할지"까지 — AI가 스스로 판단하고 실행하는 구조로 진화하고 있다. 문제는 이 판단을 누가 승인했는가가 점점 불분명해진다는 것이다.

백업·복구는 왜 거버넌스의 사각지대였나

솔직히 말하자면, 백업·복구(Backup & Recovery) 영역은 기업 IT 거버넌스에서 오랫동안 '성실하지만 감시받지 않는 직원' 같은 위치였다. 스케줄러가 새벽 2시에 돌고, 테이프나 오브젝트 스토리지에 데이터가 쌓이고, 누군가 정책 문서에 서명한다. 그게 전부였다.

그런데 이 구조는 한 가지 전제 위에 서 있었다. 백업 정책은 사람이 명시적으로 설계하고, 변경 시엔 승인 절차를 밟는다는 전제. RPO(복구 목표 시점), RTO(복구 목표 시간), 보존 기간, 복구 우선순위 — 이것들은 모두 비즈니스 요구사항과 규정 준수 요건을 인간이 해석해서 정책으로 굳힌 산물이었다.

AI 클라우드 도구들이 이 전제를 조용히 허물고 있다.

AI가 백업 정책을 '최적화'한다는 것의 의미

AWS Backup, Azure Backup, Google Cloud Backup and DR 같은 주요 클라우드 벤더들은 이미 ML 기반의 '지능형 계층화(intelligent tiering)'와 '이상 감지(anomaly detection)'를 백업 파이프라인에 통합하고 있다. 여기까지는 "추천" 수준이었다.

그런데 최근 흐름은 다르다. Cohesity, Rubrik, Veeam 같은 엔터프라이즈 백업 플랫폼들은 AI 엔진이 백업 빈도, 보존 기간, 복구 순서를 동적으로 조정하는 기능을 '자동화'로 포장해 출시하고 있다. 예를 들어 Rubrik의 AI-powered SLA 엔진은 워크로드의 변경 빈도, 접근 패턴, 비용 효율성을 분석해 스스로 백업 정책을 재조정할 수 있다.

이게 왜 문제인가? 두 가지 시나리오를 생각해보자.

시나리오 1. 금융 서비스 기업의 핵심 DB에 대해 AI가 "접근 빈도가 낮고 변경률이 미미하다"고 판단해 백업 빈도를 일간에서 주간으로 낮춘다. 마침 그 DB가 분기 말 보고서 생성 직전에 랜섬웨어 공격을 받는다면?

시나리오 2. 복구 시나리오에서 AI가 "가장 최근 버전이 가장 안정적"이라고 판단해 자동 복구를 실행한다. 그런데 그 '최근 버전'이 이미 공격자가 오염시킨 데이터라면?

두 경우 모두, AI의 판단 근거가 감사 로그에 남아 있지 않거나 인간이 해석할 수 없는 형태라면, 사고 이후 규제 기관에 "왜 그 시점에 그 정책이 적용되었는가"를 설명하는 것이 사실상 불가능해진다.

a close up of a screen with numbers on it

Photo by Martin Sanchez on Unsplash

AI 클라우드 백업의 구조적 거버넌스 공백

이 문제의 핵심은 세 가지 공백으로 정리된다.

1. 변경 승인자의 소멸

전통적 변경 관리(ITIL 기반)에서 백업 정책 변경은 CAB(변경자문위원회) 승인이나 최소한 담당자 서명을 요구한다. SOC 2 Type II나 ISO 27001 통제 항목에서 백업 정책은 명시적으로 '문서화되고 승인된 절차'를 요구한다.

AI가 SLA 정책을 동적으로 재조정할 때, 이 변경은 변경 티켓 없이, 명시적 승인자 없이 발생한다. 시스템 로그에는 "AI engine adjusted backup frequency: daily → weekly, reason: low change rate detected"라는 한 줄이 남을 수 있다. 이것이 감사 증거로 충분한가? 대부분의 규정 준수 프레임워크에서 답은 '아니오'다.

2. 복구 우선순위 결정의 블랙박스화

재해 복구(DR) 시나리오에서 복구 순서는 BIA(비즈니스 영향 분석)에 따라 사전에 정의된다. 어떤 시스템을 먼저 살릴 것인가는 단순한 기술적 판단이 아니라 비즈니스 연속성 전략과 법적 의무를 반영한 의사결정이다.

AI 기반 복구 오케스트레이션 도구들이 이 순서를 '실시간 상황'에 맞게 재조정하기 시작하면, 사전에 승인된 DR 계획과 실제 실행이 어긋나는 상황이 발생한다. PCI DSS 12.10.1은 인시던트 대응 계획이 "문서화되고 테스트된" 것이어야 한다고 요구한다. AI가 런타임에서 계획을 바꾼다면, 그 계획은 더 이상 "테스트된" 것이 아니다.

3. 데이터 보존 정책의 자율 단축

GDPR, 개인정보보호법, 금융감독원 지침 등은 특정 데이터의 최소 보존 기간을 명시한다. 동시에 GDPR의 '삭제권(Right to Erasure)'은 특정 데이터의 최대 보존 기간에도 압박을 가한다.

AI가 비용 최적화 목적으로 보존 기간을 단축하거나, 반대로 "자주 접근되는 데이터라 장기 보존이 효율적"이라는 판단으로 보존 기간을 연장한다면 — 이 두 경우 모두 규정 위반 가능성이 있다. 그리고 그 판단이 AI에 의해 자율적으로 내려졌다면, 기업은 "우리가 의도한 바가 아니었다"고 항변하기 어렵다. 규정 위반에는 의도가 면죄부가 되지 않는다.

실제로 어떤 일이 벌어지고 있나

2025년 Gartner 보고서에 따르면, 엔터프라이즈 백업 플랫폼의 40% 이상이 이미 ML 기반 정책 자동화 기능을 탑재하고 있으며, 이 비율은 2026년까지 60%를 넘어설 것으로 보인다. 그러나 같은 보고서는 이 자동화 기능에 대한 거버넌스 프레임워크를 갖춘 기업은 20%에 불과하다고 지적한다.

더 흥미로운 건 현장의 목소리다. 국내 한 금융지주 계열 IT 담당자는 최근 컨퍼런스에서 이런 말을 했다. "AI 백업 도구가 알아서 최적화해준다고 해서 도입했는데, 6개월 후 감사에서 '이 정책 변경은 누가 승인했냐'는 질문에 답을 못 했다. 로그는 있는데 승인 기록이 없었다."

이것이 지금 현장에서 실제로 일어나는 일이다. 도구는 작동한다. 최적화도 된다. 그런데 거버넌스의 언어로 설명할 수 없는 의사결정들이 쌓여간다.

이 문제는 배포 파이프라인, IAM, 자율 복구, 옵저버빌리티, 스케일링, 연산 자원 배분, 트래픽 라우팅, 설정 관리, 네트워킹, 비용 관리, 패치 관리에 이르기까지 AI 클라우드 자동화가 닿는 모든 영역에서 반복되는 패턴이다. 백업·복구는 그 마지막 퍼즐 조각 중 하나다. 이 거버넌스 공백이 어떻게 기업 전략과 투자 구조에까지 영향을 미치는지는 Microsoft OpenAI 투자 구조의 이면 — 10-Q에 묻힌 한 문단이 말하는 것에서도 다른 각도로 확인할 수 있다.

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

이 문제에 대한 해법은 "AI 자동화를 끄자"가 아니다. 그건 현실적이지도 않고, 자동화가 가져오는 운영 효율을 포기하는 것이기도 하다. 핵심은 AI의 판단을 거버넌스 언어로 번역하는 레이어를 만드는 것이다.

실무에서 바로 적용할 수 있는 세 가지 접근

첫째, AI 정책 변경에 대한 '섀도우 승인 로그' 구조 설계. AI가 백업 정책을 변경할 때, 해당 변경 내용을 자동으로 변경 관리 시스템(ITSM)에 티켓으로 생성하고, 일정 기간 내 담당자가 '사후 검토 확인'을 하는 구조를 만든다. 변경 자체는 AI가 실행하되, 감사 추적은 사람이 확인한 흔적을 남기는 방식이다. 완벽한 사전 승인은 아니지만, 현실적인 컴플라이언스 증거를 만들 수 있다.

둘째, AI 자율 실행의 '경계 조건(guardrails)'을 명시적으로 정의하고 문서화. AI가 건드릴 수 있는 백업 정책의 범위를 명확히 제한한다. 예를 들어 "백업 빈도는 일간 이하로 낮출 수 없다", "보존 기간은 규정 최소값의 110% 이하로 설정 불가" 같은 하드 제약을 코드와 정책 문서 양쪽에 명시한다. NIST SP 800-209 (Security Guidelines for Storage Infrastructure)는 이런 정책 경계 설계에 실질적인 참고 기준을 제공한다.

셋째, 복구 시나리오에서 AI 추천과 인간 최종 결정을 분리. 일상적 백업 최적화는 AI에 맡기되, 실제 복구 실행 — 특히 프로덕션 환경 복구 — 에는 반드시 명시적 인간 승인 단계를 유지한다. 자동화의 이점을 살리면서도 가장 중요한 결정 지점에서 인간의 판단을 보존하는 구조다.

기술은 판단을 대신할 수 있지만, 책임은 대신할 수 없다

기술은 단순히 기계가 아니라, 인간의 삶을 풍요롭게 하는 도구다. 그러나 도구가 아무리 정교해져도, 그 도구의 판단이 가져오는 결과에 대한 책임은 여전히 사람과 조직에 귀속된다. 규제 기관은 "AI가 그렇게 결정했다"는 답변을 받아들이지 않는다. 법원도 마찬가지다.

AI 클라우드가 백업과 복구의 의사결정권을 조용히 가져가는 지금, 기업이 해야 할 질문은 단순하다. "이 판단은 우리가 승인한 것인가? 그리고 그 증거가 있는가?"

이 질문에 자신 있게 답할 수 있는 조직만이, 다음 번 감사나 인시던트에서 흔들리지 않을 수 있다. AI가 더 많은 것을 자율적으로 결정할수록, 그 결정을 둘러싼 거버넌스 구조는 더 정교하고 의도적으로 설계되어야 한다. 이것이 AI 시대의 역설이다 — 자동화가 늘어날수록, 인간의 거버넌스 설계 역량이 더 중요해진다.

태그: AI 클라우드, 백업 자동화, 클라우드 거버넌스, 재해 복구, 컴플라이언스, 데이터 보호

이 글은 "AI 클라우드, 이제 '무엇을 백업하고 언제 복구할지'도 스스로 결정한다" 시리즈의 연장선에서, 독자들이 실무에서 바로 활용할 수 있는 체크리스트와 추가 고려사항을 정리한 보충 글입니다.

부록: 실무 점검 체크리스트 — "우리 조직의 AI 백업·복구 거버넌스는 지금 어디에 있는가"

아래 체크리스트는 보안팀, 클라우드 운영팀, 컴플라이언스 담당자가 현재 자신의 조직 상태를 빠르게 진단하는 데 활용할 수 있도록 설계했다. 각 항목에 솔직하게 답해보자.

1. 정책 가시성 (Policy Visibility)

AI 도구가 지난 30일간 변경한 백업 정책 목록을 지금 당장 뽑아낼 수 있는가?
각 변경에 대해 "왜 변경했는가"에 해당하는 AI 추론 로그가 보존되어 있는가?
백업 정책 변경 이력이 ITSM 또는 변경 관리 시스템에 연동되어 있는가?

2. 승인 구조 (Approval Structure)

AI가 자율 실행할 수 있는 정책 변경의 범위가 명문화된 문서로 존재하는가?
해당 범위를 벗어나는 변경에 대해 자동으로 에스컬레이션(사람에게 알림)되는 구조가 있는가?
프로덕션 환경 복구 실행에 명시적 인간 승인 단계가 워크플로에 포함되어 있는가?

3. 감사 증거 (Audit Evidence)

최근 감사에서 AI 자율 변경 항목이 "승인된 변경"으로 처리되었는가, 아니면 설명하지 못한 항목으로 남았는가?
SOC 2, ISO 27001, PCI DSS 등 적용 규제에서 요구하는 변경 승인 증거를 AI 변경 건에 대해서도 제출할 수 있는가?
사후 검토 확인(post-hoc review) 프로세스가 정의되어 있고, 실제로 운영되고 있는가?

4. 복구 시나리오 (Recovery Scenario)

최근 12개월 내 재해 복구(DR) 훈련을 실시했는가?
해당 훈련에서 AI가 변경한 정책 기반으로 복구가 정상 작동함을 검증했는가?
복구 실패 시 AI 판단 오류와 인프라 오류를 구분해 원인을 추적할 수 있는 로깅 구조가 있는가?

5. 책임 귀속 (Accountability)

"이 백업 정책은 누가 승인했는가"라는 질문에 특정 사람의 이름을 답할 수 있는가?
AI 도구 벤더와의 계약서에 정책 변경 로그 보존 의무가 명시되어 있는가?
내부 감사팀 또는 CISO가 AI 자율 실행 범위를 인지하고 있으며, 이를 리스크 레지스터에 등록했는가?

10개 이상 체크하지 못한 항목이 있다면, 그것이 바로 다음 감사 또는 인시던트에서 설명하지 못하는 공백이 될 가능성이 높다.

마치며: 거버넌스는 AI 이전에 설계되어야 한다

AI 클라우드 도구들은 지금 이 순간에도 조용히, 빠르게, 그리고 선의로 백업 정책을 최적화하고 있다. 문제는 그 선의가 규제 기관의 감사 기준과 반드시 일치하지 않는다는 점이다.

거버넌스는 사고가 난 뒤에 설계하는 것이 아니다. AI가 더 많은 판단을 가져가기 전에, 조직은 먼저 "우리가 AI에게 허용하는 판단의 경계"를 스스로 정의해야 한다. 그 경계를 코드로, 문서로, 그리고 감사 증거로 남기는 것 — 그것이 AI 시대의 클라우드 거버넌스가 요구하는 새로운 역량이다.

기술은 계속 앞으로 달려간다. 거버넌스가 그 속도를 따라가지 못하면, 결국 가장 큰 비용을 치르는 것은 조직이 아니라 그 조직을 신뢰한 고객과 사용자다. 우리가 직면한 문제를 해결하는 것은 기술이지만, 그 기술을 책임지는 것은 언제나 사람이어야 한다.

이 글이 유용했다면, 시리즈의 다른 편 — AI가 자율 결정하는 클라우드 거버넌스의 각 영역(IAM, 네트워킹, 패치 관리, FinOps 등) — 도 함께 읽어보시길 권한다. 각 편은 독립적으로 읽을 수 있지만, 함께 읽으면 AI 클라우드 거버넌스의 전체 지형이 보인다.

태그: AI 클라우드, 백업 자동화, 클라우드 거버넌스, 재해 복구, 컴플라이언스, 데이터 보호, 감사 체크리스트, ITSM, 변경 관리

NOCODE TECH STACKER