AI 에이전트에게 terraform/gcloud를 맡겼더니 운영 환경과 백업까지 함께 삭제되었다 —— 10만 명의 학습 기반이 사라진 실제

AI 코딩 에이전트(Claude Code, Cursor, Copilot 등)에게 terraform, gcloud, aws와 같은 클라우드 도구를 맡기고 있는 분들을 위한 글입니다. 로컬 파일이 삭제되는 사고는 잘 알려져 있지만, 에이전트에게 클라우드 도구를 맡기면 삭제되는 것이 파일이 아니라 인프라 그 자체가 됩니다. 가상 머신, 데이터베이스, 그리고 그 백업까지 한꺼번에 날아갑니다.

실제로 발생한 사례를 한 건 자세히 살펴본 후, 로컬에서 지금 바로 실행할 수 있는 방지책을 정리합니다.

데이터 공학을 10만 명 이상에게 가르치고 있는 DataTalks.Club의 운영자가 2026년 2월에 경험을 공개했습니다 (본인의 포스트모템(Post-mortem), Tom's Hardware 보도, AI Incident Database #1424). 보고에 따르면 흐름은 다음과 같았습니다.

다른 작은 프로젝트를 기존 운영 인프라에 함께 올리려다가, 작업 도중에 컴퓨터를 교체했습니다. 그때 terraform 상태 파일(현재 어떤 인프라가 있는지 terraform에게 알려주는 핵심 기록)을 옮기는 것을 잊었습니다. 그래서 terraform plan을 실행하자, 이미 존재해야 할 자원이 '새로 생성될 것'이라고 표시되었습니다. 상태 파일이 수중에 없었기 때문에 terraform이 기존 인프라를 알지 못하게 된 것입니다.

여기서 운영자는 에이전트에게 "중복된 자원만 찾아내서 삭제해 줘"라고 요청했습니다. 그런데 에이전트는 terraform destroy를 실행했습니다. 상태 파일이 가리키는 모든 것을 삭제하는 명령입니다. 결과적으로 운영 환경의 VPC, 데이터베이스, 컨테이너 기반, 그리고 2년 반 동안 쌓인 약 194만 행의 기록이 한꺼번에 삭제되었다고 보고되었습니다.

결국 클라우드 회사 측에 사용자 화면에서는 보이지 않는 내부 백업이 남아 있어 24시간 후에 복구할 수 있었다고 합니다. 운이 좋았던 경우입니다.

이 사례에서 배울 수 있는 점은 단순히 terraform destroy가 위험하다는 것만이 아닙니다. 보고서를 읽어보면 세 가지 깊은 원인이 겹쳐 있습니다.

• 상태의 불일치가 삭제의 에스컬레이션을 초래했다. "중복만 삭제해 줘"라는 지시가 상태 파일의 결락으로 인해 "전부 삭제"로 변질되었습니다. 인간은 제한적인 청소를 부탁했지만, 에이전트는 전체 철거를 선택했습니다.
• 백업이 운영 환경과 동일한 휘말림 범위에 있었다. 자동 백업이 삭제된 것과 동일한 terraform 구성으로 관리되고 있었습니다. 그래서 운영 환경이 삭제되자 백업도 함께 삭제되었습니다. "백업을 하고 있으니 괜찮다"는 논리가 동일한 한 번의 작업으로 무효화되는 구조입니다.
• 파괴 명령에 인간의 승인 관문이 없었다. 에이전트가 확인 없이 terraform destroy까지 실행할 수 있었습니다.

이 세 가지는 클라우드를 다루는 사람이라면 누구에게나 해당될 수 있습니다. 상태 파일을 다른 머신으로 옮기는 것을 잊거나, 과도한 권한의 키를 에이전트에게 넘겨주거나, 자동 승인을 활성화한 채로 실행하는 것 등은 모두 드문 일이 아닙니다.

같은 계통의 사고는 한 건만이 아닙니다. GitHub의 이슈 기록에서도 클라우드 가상 머신을 외부 전송 실패 직후에 삭제하여 3일 치의 학습 성과와 GPU 비용을 잃은 사례(#69724)나, 클라우드 저장소 이동 실패를 묵인한 채 무조건 삭제해 버린 사례(#70024)가 보고되어 있습니다. 공통점은 **"전송이나 이동이 성공했는지 확인하지 않은 채, 다음 단계인 삭제를 실행한다"**는 연쇄 작용입니다.

클라우드 회사 측의 방어책(삭제 보호, 조직 정책, 상태 파일을 원격 저장소에 보관 등)은 각사의 공식 문서에 망라되어 있습니다. 여기서는 그것과는 별개로, 에이전트를 구동하는 로컬 측에서 지금 바로 실행할 수 있는 방어책에 집중하겠습니다.

가장 효과적인 방법은 terraform destroy나 gcloud ... delete, kubectl delete와 같은 파괴적인 명령을 에이전트가 실행하기 전에 막는 것입니다. Claude Code라면 PreToolUse hook을 통해 명령 문자열을 확인하고, 파괴적인 형태라면 종료 코드 2로 중단시킬 수 있습니다.

#!/bin/bash
# block-cloud-destroy.sh — 클라우드 파괴 명령 실행 전 차단 (matcher는 "Bash|PowerShell")
INPUT=$(cat)
...

{
"hooks": {
"PreToolUse": [
...

여기서 한 가지 함정을 짚고 넘어가겠습니다. Google Cloud Storage의 삭제는,

gcloud storage rm

(대상 삭제) 또는 gcloud storage rb

(버킷 삭제)라는 짧은 단어를 사용합니다. delete나 remove가 아닙니다. 따라서 "delete나 remove를 포함하는 명령어를 차단한다"라는 단순한 방식으로 작성하면, 스토리지(Storage) 삭제만은 감시망을 빠져나가게 됩니다. 위의 hook에서는 delete·destroy 계열과는 별도로, rm·rb 계열을 명시적으로 추가했습니다.

이 hook은 명령어 문자열의 형태를 보고 차단합니다. 따라서 각 클라우드의 SDK를 통해 프로그램 내부에서 삭제하는 경로 나, 브라우저 관리 화면을 통한 수동 조작은 추적할 수 없습니다. 문자열을 감시하는 방어책은 "전형적인 형태"에는 강하지만, "다른 경로"에는 약하다는 숙명을 가지고 있습니다. 그렇기 때문에 다음 두 가지와 조합해야 합니다.

#70024 형태(이동 에러를 무시하고 삭제로 진행하는 방식)는 종료 코드(Exit Code)를 확인하는 것만으로도 방지할 수 있습니다.

# 위험: 에러를 무시하고 무조건 삭제로 진행함
gcloud storage mv gs://src/* gs://dst/ >/dev/null 2>&1
gcloud storage rm -r gs://src # 이동이 실패하더라도 삭제됨
...

그리고 DataTalks 사례의 가장 큰 교훈은, 백업을 운영 환경과 동일한 파괴 범위에 두지 않는 것입니다. 백업본을 운영 환경을 삭제하는 것과 동일한 구성 및 동일한 권한 아래에 두면, 한 번의 파괴로 둘 다 날아가 버립니다. 백업은 다른 장소, 다른 권한 아래에 두어야 합니다. 이는 클라우드 측의 설정 문제이므로, 각 사의 공식 문서(삭제 보호 또는 상태 파일(State file)을 원격 저장소로 옮기는 절차 등)를 따라 설정하시기 바랍니다. 저는 이 글에서 제 로컬 환경에서 실제로 실행하여 확인할 수 있는 범위 내에서만 단정적으로 기술하고 있습니다. 클라우드 측의 방어책은 직접 검증하지 않았으므로 공식 문서로 안내하는 것에 그칩니다.

자동 승인을 활성화한 상태로 클라우드 도구를 에이전트에게 맡기지 마세요. 파괴 명령만큼은 인간이 plan의 내용을 확인한 후 직접 실행해야 합니다. DataTalks 운영자도 사후에 이 방침으로 변경했다고 밝혔습니다.

• 에이전트에게 클라우드 도구를 넘겨주면, 사라지는 것이 파일이 아니라 인프라 그 자체가 됩니다. 가상 머신, 데이터베이스, 그리고 백업까지 한꺼번에 날아갑니다 (DataTalks의 사례에서는 운영 환경과 백업이 동일한 파괴 범위에 있었다고 보고되었습니다).
• 공통적인 트리거는 두 가지입니다. 상태(State)의 불일치가 "제한된 정리"를 "전체 파괴"로 에스컬레이션시키는 것, 그리고 전송 성공을 확인하지 않은 채 삭제로 진행하는 것입니다.
• 로컬에서 실행할 수 있는 방어책은 3단계입니다. (1) PreToolUse hook을 통해 파괴 명령 실행 전에 차단한다. (2) 삭제 전에 전송을 확인하고, 백업은 다른 파괴 범위에 둔다. (3) 파괴 명령은 인간이 승인한다.

로컬 hook을 처음부터 작성하는 것이 번거롭다면, 무료로 공개된 cc-safe-setup에 terraform destroy를 차단하는 terraform-guard.sh와, gcloud·az의 파괴 명령(스토리지의 rm·rb 포함)을 차단하는 cloud-cli-guard.sh가 포함되어 있습니다. 읽기 전용인 list, describe, cp는 차단하지 않습니다.

한 단계 더 나아가 파일 소실부터 운영 데이터베이스 삭제, 클라우드 자원 삭제에 이르기까지 Claude Code의 사고를 체계적으로 방지하고 싶다면, 실기 검증을 거친 가이드를 Zenn의 책(¥800)으로 정리해 두었습니다. 클라우드 자원 삭제 장(제43장)에도 이 글의 내용을 포함해 두었습니다.

이 기사 중 다른 사람에게 발생한 사고(DataTalks의 terraform destroy, 이슈 #69724·#70024)는 당사자의 포스트모템(Post-mortem)이나 보도, GitHub 이슈 보고를 바탕으로 전언으로서 작성되었습니다. 제가 단정적으로 기술하고 있는 것은, 직접 실행하여 확인한 hook의 동작(terraform destroy·gcloud ... delete·gcloud storage rm/rb·kubectl delete는 종료 코드 2로 중단시키고, list·describe·cp는 중단시키지 않는 것)뿐입니다. 클라우드 서비스 제공업체 측의 방어 기제는 제 환경에서 재현하여 확인하지 않았으므로, 단정하지 않고 공식 문서로 안내하고 있습니다.