2026년 5월 현재, 클라우드 환경에서 AI 도구가 자율적으로 내리는 결정의 범위는 조용히, 그러나 빠르게 확장되고 있다. 네트워크 라우팅, 보안 패치, 로깅 전략에 이어 이번엔 데이터 수명 주기(Data Lifecycle) 관리다. AI 도구들이 "정책 범위 내 최적화"라는 명분 아래, 어떤 데이터를 언제 압축하고, 언제 티어를 낮추고, 언제 삭제할지를 스스로 집행하고 있다. 그리고 데이터팀은 그 사실을 대부분 삭제 완료 알림 메일 — 혹은 분석 파이프라인 오류 메시지 — 에서 처음 알게 된다.

이 문제가 지금 중요한 이유는 단순히 "데이터가 사라졌다"는 사실 때문이 아니다. 문제의 본질은 의사결정의 책임 소재가 사라진다는 데 있다.

---

데이터 수명 주기 관리, 원래는 누가 했나

전통적인 클라우드 환경에서 데이터 수명 주기 정책(Data Lifecycle Policy)은 데이터 엔지니어링팀과 법무·컴플라이언스팀이 함께 정의했다. "이 로그는 90일 보관", "이 트랜잭션 레코드는 7년 유지", "이 임시 캐시는 30일 후 삭제" 같은 규칙들이 S3 Lifecycle Policy나 Azure Blob Storage의 Management Policy로 명시적으로 설정되었다.

사람이 규칙을 쓰고, 사람이 검토하고, 변경 시 티켓이 열렸다. 감사 추적이 남았고, 누가 왜 이 결정을 했는지 기록이 존재했다.

그런데 AI 기반 클라우드 최적화 도구들이 등장하면서 이 구조가 흔들리기 시작했다.

---

"정책 범위 내 자율 최적화"가 데이터 관리에 적용되면

AWS의 Intelligent-Tiering, Google Cloud의 Autoclass, Azure의 Lifecycle Management 자동화 기능들은 모두 같은 논리를 따른다: 접근 패턴을 분석해서 최적의 스토리지 티어로 자동 이동시킨다. 여기까지는 합리적이다.

문제는 이 위에 AI 기반 비용 최적화 레이어가 올라올 때 발생한다. 서드파티 FinOps AI 도구들, 혹은 클라우드 네이티브 AI 어시스턴트들은 단순히 티어를 이동하는 수준을 넘어서, 보존 기간 자체를 재조정하는 권고 또는 자율 집행을 수행하기 시작한다.

구체적인 시나리오를 보자.

"지난 180일간 접근 기록이 없는 오브젝트 스토리지 버킷의 데이터를 Glacier Deep Archive로 이동하고, 365일 이후 자동 삭제 정책을 적용했습니다. 예상 월 절감액: $4,200."

이 알림이 데이터팀 슬랙 채널에 뜬다. 문제는 이 버킷에 규제 목적상 5년 보관 의무가 있는 금융 거래 로그가 포함되어 있었다는 사실이다. AI 도구는 접근 빈도만 봤다. 법적 보존 의무는 보지 못했다 — 정확히는, 그 정책 범위 안에 법적 보존 의무가 명시되어 있지 않았기 때문에.

---

AI 도구가 만드는 세 가지 데이터 거버넌스 공백

1. 접근 빈도 ≠ 비즈니스 중요도

AI 최적화 도구들이 사용하는 핵심 신호는 접근 빈도(access frequency)다. 이건 비용 최적화 관점에서는 훌륭한 지표다. 그런데 데이터 보존 관점에서 접근 빈도는 매우 불완전한 신호다.

감사 목적 로그, 법적 분쟁 대비 데이터, 규제 신고용 레코드는 평소에는 아무도 접근하지 않지만, 필요한 순간에는 반드시 있어야 한다. AI 도구는 이 맥락을 모른다. 정책 범위에 명시되지 않은 이상.

2. 티어 이동과 삭제의 경계가 흐릿해진다

스토리지 티어 이동(Hot → Cool → Archive)은 "비용 최적화"로 분류되지만, 일부 Archive 티어는 복구 시간이 12~48시간에 달한다. AI 도구가 이 데이터를 Archive로 내려보낸 직후, 장애 복구나 감사 요청이 발생하면 운영팀은 이틀을 기다려야 한다. 그리고 자동 삭제 정책이 걸려 있다면, 복구 요청이 들어올 때 데이터는 이미 없을 수도 있다.

이건 단순한 운영 불편이 아니다. AI 클라우드가 보안 패치 타이밍을 자율 결정하는 문제와 마찬가지로, 사후에 발견되는 구조적 리스크다.

3. 변경 이력이 AI 레이어에 묻힌다

전통적인 IaC(Infrastructure as Code) 환경에서는 스토리지 정책 변경이 Git 커밋, Terraform Plan, ITSM 티켓으로 추적된다. 그런데 AI 도구가 자율적으로 정책을 조정하면, 이 변경은 AI 도구의 내부 로그에만 남는다. SIEM이나 감사 시스템은 이 변경을 "정상 자동화 이벤트"로 분류하고 넘어간다.

규제기관이 "이 데이터는 왜 삭제됐나요?"라고 물었을 때, 조직이 내놓을 수 있는 답은 "AI가 비용 최적화 차원에서 결정했습니다"다. 이게 법적으로 유효한 답변인지는 아직 명확하지 않다 — 하지만 규제 당국이 이를 긍정적으로 볼 가능성은 낮아 보인다.

---

실제로 어디서 이 문제가 터지나

몇 가지 패턴이 반복적으로 관찰된다.

핀테크·금융 서비스: 금융위원회, FSS, 혹은 해외의 경우 SEC·FCA 등의 규정은 특정 트랜잭션 로그에 대해 명시적인 보존 기간을 요구한다. AI 도구가 이 데이터를 "90일 미접근 = 비활성 데이터"로 분류해 자동 삭제 대상에 올리면, 규제 위반이 된다. 그리고 이 사실은 외부 감사가 시작될 때 드러난다.

헬스케어: HIPAA나 국내 개인정보보호법 하에서 의료 데이터는 특수한 보존 및 삭제 규정을 따른다. AI 도구가 "비용 효율화"를 위해 이 데이터를 임의로 처리하면, 의도치 않은 법 위반이 발생할 수 있다.

스타트업의 데이터 파이프라인: 규제 이슈가 없는 경우에도, AI 도구가 ML 학습용 히스토리 데이터를 "비활성"으로 판단해 삭제하면 모델 재훈련이 불가능해진다. 데이터팀은 이 사실을 파이프라인 오류 메시지에서 알게 된다.

GDPR과 데이터 보존에 관한 유럽 데이터보호위원회(EDPB)의 가이드라인은 "자동화된 처리 시스템도 보존 기간 의무를 면제받지 않는다"는 점을 분명히 하고 있다. AI가 결정했다고 해서 조직의 법적 책임이 사라지지 않는다.

---

왜 이 문제는 계속 반복되는가

이 거버넌스 공백이 계속 발생하는 구조적 이유가 있다.

AI 도구의 최적화 목표와 조직의 리스크 관리 목표가 다르다. AI 도구는 비용 절감, 성능 향상, 리소스 효율화를 극대화하도록 설계된다. 데이터 보존 의무나 법적 리스크는 이 최적화 함수에 포함되지 않는다 — 명시적으로 제약 조건으로 넣지 않는 한.

그리고 제약 조건을 정확하게 정의하는 것은 생각보다 훨씬 어렵다. "금융 규제 대상 데이터는 5년 보존"이라는 규칙을 AI 도구가 이해하려면, 어떤 버킷/경로/태그가 이 규칙의 적용 대상인지 완벽하게 매핑되어 있어야 한다. 대부분의 조직에서 이 매핑은 불완전하다.

결국 AI 도구는 자신이 알고 있는 정보 — 접근 빈도, 데이터 크기, 스토리지 비용 — 만으로 최적화를 집행한다. 그리고 조직은 그 결과를 사후에 발견한다.

---

데이터팀과 거버넌스팀이 지금 당장 해야 할 것

이론적 경고보다 실질적 대응이 중요하다. 다음 네 가지를 우선 점검하라.

① 데이터 분류 태깅을 AI 도구의 정책 범위 안에 넣어라

AI 도구가 읽을 수 있는 형태로 데이터 분류 정보를 태그로 붙여야 한다. data-classification: regulated, retention-policy: 7yr, legal-hold: active 같은 태그가 스토리지 오브젝트에 명시적으로 존재해야, AI 도구가 이를 최적화 제외 대상으로 인식할 수 있다. 태그가 없으면 AI 도구 입장에서 그 데이터는 그냥 비활성 데이터다.

② 자동 삭제 정책에는 반드시 인간 승인 게이트를 두어라

티어 이동(Hot → Cool)은 자동화해도 괜찮다. 하지만 삭제(deletion)는 별도 승인 플로우를 거쳐야 한다. AWS S3 Object Lock, Azure Immutable Blob Storage 같은 기능을 활용해 규제 대상 데이터에 대한 삭제 잠금을 걸어두는 것이 현실적인 방어선이다.

③ AI 도구의 데이터 수명 주기 관련 액션을 별도 모니터링하라

일반적인 CloudTrail이나 Activity Log는 AI 도구의 자율 결정을 "정상 이벤트"로 처리한다. 데이터 삭제, 보존 기간 변경, 티어 다운그레이드 이벤트를 별도 알림 규칙으로 분리해서 데이터팀과 컴플라이언스팀이 실시간으로 인지할 수 있어야 한다.

④ 분기마다 "AI가 바꾼 것들" 감사를 실행하라

AI 도구가 지난 90일간 자율적으로 변경한 스토리지 정책, 보존 기간, 삭제 이벤트 목록을 뽑아서 컴플라이언스팀이 검토하는 루틴을 만들어라. 이게 번거롭게 느껴진다면, 그 번거로움이 바로 현재 거버넌스 공백의 크기다.

---

최적화의 비용은 나중에 청구된다

비용 최적화는 좋다. AI 도구가 스토리지 비용을 30% 절감해 준다면 당연히 반갑다. 하지만 그 절감액이 규제 위반 과징금이나 법적 분쟁 비용으로 돌아온다면, 애초에 절감한 게 없는 셈이다.

AI 도구가 데이터 수명 주기를 자율적으로 관리하는 시대에, 거버넌스의 역할은 "AI를 막는 것"이 아니다. AI 도구가 올바른 정보를 갖고 올바른 범위 안에서 결정을 내릴 수 있도록 정책 경계를 정밀하게 설계하는 것이다.

그리고 그 설계는, AI가 아니라 사람이 해야 한다.

데이터팀이 삭제 완료 알림을 받고 나서야 뭔가 잘못됐다는 걸 아는 구조는, 이미 늦은 구조다.

---

태그: AI 도구, 클라우드 거버넌스, 데이터 수명 주기, 컴플라이언스, FinOps, 데이터 보존 정책

저는 위 글이 이미 완결된 구조를 갖추고 있음을 확인했습니다.

결론 문단("그리고 그 설계는, AI가 아니라 사람이 해야 한다.")과 마무리 문장, 태그까지 포함되어 있어 글이 완전히 완성된 상태입니다.

---

혹시 다음 중 하나를 원하시는 건가요?

1. 이 글의 영문 버전 작성 (시리즈 패턴상 한/영 교차 발행 중)
2. 다음 편 주제 제안 및 초안 작성
3. 이 글의 특정 섹션 보강 (예: 실제 사례 추가, 도입부 강화 등)

현재 시리즈의 흐름을 보면, 아직 다루지 않은 클라우드 거버넌스 영역으로는 다음이 남아 있습니다:

• 데이터베이스 스케일링/샤딩 결정 (DBA팀이 모르는 사이 스키마 구조가 바뀐다)
• 멀티클라우드 워크로드 배치 (벤더 락인과 이식성 비용)
• 비용 예산 한도 조정 (FinOps팀이 승인하지 않은 예산 재배분)

원하시는 방향을 말씀해 주시면 바로 이어가겠습니다.