Claude Code가 DataTalks.Club 프로덕션에서 terraform destroy를 실행했습니다

2026년 2월 26일 오후 11시 직전, Claude Code 에이전트가 DataTalks.Club의 강좌 플랫폼을 운영하는 AWS 계정에 대해 terraform destroy를 실행해 프로덕션 스택을 삭제했다. 여기에는 VPC, ECS 클러스터, 로드 밸런서, 배스천 호스트, Amazon RDS의 PostgreSQL 데이터베이스가 포함되었다. 이 플랫폼에는 이 플랫폼을 통해 진행된 모든 과정의 2.5년치 학생 제출물, 숙제, 프로젝트, 리더보드 항목이 있었으며, 자동 RDS 백업도 같은 순간에 사라져 콘솔에는 복원할 수 있는 것이 아무것도 보이지 않았다. DataTalks.Club을 운영하고 2026년 3월 6일 1인칭 사후 분석 글을 게시한 Alexey Grigorev는 약 24시간 후에 데이터를 되찾았는데, 이는 AWS 지원팀이 그의 계정에서는 볼 수 없었던 내부 스냅샷을 찾아냈기 때문이었다. 출처 목록과 신뢰도 등급을 포함한 전체 기록은 Orca AI Incident Archive에 있으며, 이 아카이브가 색인하는 다른 에이전트로 인한 인프라 사고들과 함께 있습니다.

증거 기반은 회자되는 이야기들이 시사하는 것보다 좁으며, 사건 전개를 말하기 전에 분명히 짚을 가치가 있다. 여기서 구체적인 내용은 모두 그리고레프에게서 나온다. AI Incident Database에는 이 사건에 관한 보고서가 두 건 실려 있다. 그의 Substack 게시글 "How I Dropped Our Production Database and Now Pay 10% More for AWS"와 Tom's Hardware가 2026년 3월 7일 Bruno Ferreira가 쓴 기사이며, 두 번째는 첫 번째의 요약이다. 인시던트 관리 회사 Rootly가 게재한 인터뷰는 그리고레프 본인의 말로 세부 내용을 보탠다. Anthropic의 성명도, AWS의 성명도, 이 사건에 대한 규제 당국의 조사 결과도 공개되지 않았다. 무엇이 삭제되었는지에 대해서는 모든 설명이 일치한다. 회자된 이야기가 그가 실제로 쓴 내용과 어긋나는 부분에 대해서는 이 기사가 어느 것이 사실이고 어느 것이 회자된 이야기인지 밝힌다.

그것을 가능하게 한 두 가지 결정

마이그레이션은 평범한 작업이었다. Grigorev는 AI Shipping Labs 사이트를 GitHub Pages에서 AWS로 옮기고, 이어서 Django로 재작성하기를 원했다. 두 번째 환경을 구축하는 대신, 그는 이미 DataTalks.Club의 Zoomcamp 과정을 뒷받침하는 강좌 플랫폼을 관리하던 Terraform 구성에 해당 사이트를 추가했다. 이 플랫폼은 2.5년 전까지 거슬러 올라가는 제출물, 숙제, 프로젝트, 리더보드 항목을 보관하는 시스템이다. 그는 게시글에서 절감액을 월 $5~$10로 제시하며, 에이전트가 이 구성에 반대했다고 기록한다. "Claude는 내가 그것을 따로 유지해야 한다며 나를 말리려 했다." 그러나 그는 또 다른 VPC를 원하지 않았기 때문에, 모든 것을 기존 VPC에 넣으라고 에이전트에 지시했다.

두 번째 결정은 더 조용히 내려졌다. Terraform의 상태 파일은 이미 존재하는 것에 대한 기록이다. Grigorev는 최근 새 컴퓨터로 옮겼지만 그 파일을 이전하지 않았고, 그래서 2월 26일 밤 10시쯤 배포가 시작되었을 때 계획은 계정이 비어 있다고 가정하고 인프라의 복제본을 만들기 시작했다. 그는 생성 중인 리소스의 긴 목록을 보고 apply를 중단한 뒤 이유를 물었다. 그가 말하는 바로는, 에이전트의 답변은 Terraform이 아무것도 존재하지 않는다고 믿고 있었다는 것이었다.

파괴

그다음에 이어진 것은 정리 작업이었지만, 그것은 결국 사고로 번졌다. 그리고리예프는 에이전트에게 AWS CLI를 통해 어떤 리소스가 새로 생성된 중복이고 어떤 것이 프로덕션인지 파악하게 한 뒤, 새로 생성된 것만 삭제하라고 요청했다. 그 작업이 실행되는 동안 그는 이전 머신으로 돌아가 상태 파일이 들어 있는 Terraform 폴더를 아카이브로 만들고, 그 아카이브를 복사해 옮긴 다음, 에이전트에게 그 경로를 지정해 두 리소스 집합을 비교할 수 있게 했다. 그의 설명에 따르면 그는 에이전트가 아카이브의 압축을 푸는 것을 알아차리지 못했고, 그 안에 있던 더 오래된 파일, 즉 프로덕션 리소스를 기술하던 파일로 활성 상태 파일을 교체하는 것도 알아차리지 못했다.

그 상태가 갖춰지자 에이전트의 다음 제안은 나름의 논리를 따랐다. Grigorev가 인용한 게시물에서 그것은 이렇게 말한다. “나는 그렇게 할 수 없다. terraform destroy를 하겠다. 리소스가 Terraform을 통해 생성되었으므로, AWS CLI를 통하는 것보다 Terraform을 통해 파괴하는 것이 더 깔끔하고 간단할 것이다.” 그는 동의하고 Rootly에 말했다. “그래, Claude가 terraform destroy를 실행했고 나는 그것을 봤지만 멈추지 않았다.” 그는 또한 상태 교체에 대해 “상태가 교체된 줄은 몰랐다”라고 말했다. 그 명령은 오후 11시쯤 자동 승인으로 실행되었기 때문에, 두 번째로 묻기 위해 멈추는 일은 없었다.

두 가지 설명은 에이전트의 제안을 서로 다르게 표현한다 — Rootly 인터뷰에서는 이를 "이걸 하나씩 삭제하는 건 지루하니까, 그냥 terraform destroy를 실행하면 어떨까?"라고 전한다 — 하지만 둘 다 같은 형태를 설명한다. destroy가 정리 작업으로 제안되었고, 중복 항목만이 대상 범위에 있다고 믿은 운영자가 그것을 실행하도록 내버려 두었다는 것이다. 이 실패의 메커니즘은 에이전트가 명령을 오해했다는 데 있지 않다. 그것은 에이전트가 프로덕션을 기술한 상태 파일로부터 올바르게 추론하고 있었고, 운영자는 그 파일이 변경되었다는 것을 알 방법이 없었다는 데 있다.

무엇이 파괴되었나요?

에이전트가 이제 작업하던 상태 파일이 프로덕션을 설명하고 있었기 때문에, destroy는 프로덕션 삭제를 계획했습니다. Grigorev는 무엇이 삭제되었는지 나열합니다:

• 전체 환경을 담고 있던 VPC.

• 애플리케이션을 실행하는 ECS 클러스터.

• 그 앞에 있는 로드 밸런서.

• 프라이빗 네트워크에 접근하는 데 사용되는 배스천 호스트입니다.

• 강좌 플랫폼의 데이터를 보관하는 Amazon RDS 데이터베이스.

• 위의 모든 항목을 복구 가능하게 해야 했던 자동 RDS 스냅샷.

마지막 항목은 장애를 데이터 손실 공포로 바꾼 바로 그 항목이다. Rootly 인터뷰에서 Grigorev의 설명은 AWS에서 관리형 데이터베이스를 삭제하면 연관된 자동 백업도 함께 제거된다는 것이다. 게시물에서 AWS 지원팀은 그의 데이터베이스와 모든 스냅샷이 삭제되었다는 점, 그리고 "API 요청이 AWS에 모든 것을 삭제하라고 분명히 알렸다"는 점을 그에게 확인해 주었다. 삭제가 어떤 경로로 전파되었든, 오후 11시에 중요했던 효과는 이것이었다. 그가 의존해 오던 사본이 원본과 동일한 작업으로 제거되었다.

24시간 회복

첫 번째 문제는 백업이 사라진 것처럼 보인다는 점이었고, 두 번째 문제는 그중 하나는 사라지지 않았다는 점이었다. Grigorev는 매일 새벽 2시에 스냅샷이 생성된다는 것을 알고 있었다. RDS 콘솔에서는 아무것도 찾지 못했지만, RDS 이벤트 목록에는 여전히 백업이 생성되었다고 표시되었고, 해당 항목을 클릭해 들어가도 아무것도 열리지 않았다. 그는 스냅샷이 삭제된 것인지 아니면 단순히 보이지 않게 된 것인지 알 수 없었다.

자정 무렵 지원 티켓을 열었고, 프로덕션 인시던트에 대한 1시간 응답 약속을 보고 나서 계정을 AWS Business Support로 업그레이드했다. 이 업그레이드로 AWS 청구서가 약 10퍼센트 늘었는데, 그의 게시글 제목은 여기서 나왔다. 지원팀은 약 40분 만에 답변해 삭제 사실을 확인했고, AWS 측에는 스냅샷이 존재하지만 그의 콘솔에서는 볼 수 없다고 말했다. 이어서 40~60분간의 통화가 진행됐고 내부 팀으로 에스컬레이션됐다. 데이터베이스가 삭제된 지 정확히 24시간 후, AWS가 스냅샷을 복원했고 그것이 그의 콘솔에 나타났다. 그는 Terraform을 통해 그 스냅샷으로 인스턴스를 재구축했다. 기다리는 동안 그는 주변 인프라를 재구축하고 여러 로드 밸런서를 하나로 통합했다.

복원된 데이터베이스에는 1,943,200개의 행이 있었으며, 그 행들은courses_answer 테이블에 있었습니다. 그는 이 수치를 복원이 완전했다는 확인으로 인용합니다. 이 수치는 종종 손실 규모로 반복해서 언급됩니다. 그것은 한 테이블의 행 수로, 데이터가 돌아왔다는 증거로 사용된 것이지 데이터베이스 전체 합계도 아니고, 영향을 받은 학생 수를 센 것도 아닙니다 — 영향을 받은 학생 수는 어느 출처도 제시하지 않습니다.

있지 않았던 경고

여러 재전언에는 Claude가 Grigorev에게 사전에 경고했지만 무시당했다는 대목이 있다. 출처가 뒷받침하는 내용은 더 좁은 범위이며, 그 차이는 이 사건이 무엇의 사례인지를 바꾼다. 그 에이전트는 어떤 파괴도 일어나기 전에 공유 Terraform 설정에 반대하는 주장을 실제로 펼쳤고, 그 조언은 기각되었다. Grigorev의 두 진술 중 어느 것도 에이전트가 destroy가 프로덕션에 도달할 것이라고 경고했다고 서술하지 않는다. 그는 state 파일이 교체된 사실을 몰랐다고 말하며, 두 진술 모두에서 에이전트의 제안은 위험을 표시한 뒤 감수한 것으로서가 아니라 정리 작업으로 제시된다. 무시된 경고는 명령이 아니라 마이그레이션 중 더 이른 시점의 아키텍처에 관한 것이었다.

그 구분은 두 가지 서로 다른 실패를 분리한다. 위험을 인지했지만 제지당한 에이전트는 인간의 결정에 관한 거버넌스 이야기다. 세상을 기술하는 파일이 그 아래에서 바뀌었기 때문에 위험이 존재한다는 사실조차 모르는 에이전트는 상태, 권한, 승인 게이트에 관한 툴링 이야기다. Grigorev의 사례는 후자이며, 아카이브 자체의 분류도 이를 반영한다: 해당 기록은 운영자가 의도한 것에서 벗어난 에이전트 행동에 대한 아카이브의 ROGUE 태그를 달고 있고, 그 아래의 AI Incident Database 항목은 의도를 비의도적(unintentional)로 분류하며, MIT 분류 7.3인 능력 또는 견고성 부족에 따라 위험 영역을 AI 시스템 안전, 실패 및 한계로, 단계를 배포 후로 둔다. 이 데이터베이스는 엔터티 목록 앞에 "alleged"를 붙이는데, 이는 어떤 당국도 판정하지 않은 자기 보고 사례에 대한 이 데이터베이스의 표준적인 표현 방식이다.

비난은 어디로 향했나

Grigorev는 그것을 배포하지 않는다. "이 사건은 내 잘못이었다"라고 그는 쓰며 세 가지 원인을 나열한다. 그는 plan, apply, destroy를 위임 가능한 것으로 취급했고, 한 번도 테스트 복원해 본 적 없는 백업을 신뢰했으며, 데이터베이스가 너무 쉽게 삭제되었다. 그는 AWS를 기다리는 동안 데이터가 영구적으로 사라졌을 수도 있다는 점을 고려해야 했다고 언급한다. 당시 마지막 모듈을 진행 중이던 Data Engineering 과정의 경우 그는 이미 복구를 계획하고 있었고, 더 오래된 과정들의 경우 복원 실패는 곧 그것들의 종말이었을 것이다.

톰스 하드웨어가 그의 게시글 다음 날 발표한 평가도 실질적으로 같다. "그 오류들은 부적절한 감독 탓으로 돌릴 수 있다." 톰스 하드웨어의 비판은 그보다 더 나아가, 에이전트에 부여된 광범위한 자격 증명과 프로덕션 환경을 위해 범위가 좁혀지지 않은 권한들을 지적한다. 어떤 규제 기관, 표준 기구, 판매업체도 입장을 내놓지 않았다. 여기에는 CVE도, 취약점 공개도, 모델 탈옥도 없다. 에이전트는 속은 것이 아니라 지나치게 신뢰받은 것이다.

그 후 무엇이 달라졌나요?

Grigorev는 AWS가 아직 복원 작업을 진행 중일 때 안전장치를 구현했고, 이를 목록으로 공개했다. 그의 말과 순서대로:

• Terraform이 관리하지 않는 백업과, 데이터베이스 및 인프라 상태와 별도로 저장되는 S3 기반 사본.

• 매일 밤 복원 테스트: 오전 2시 자동 백업은 오전 3시경 새로운 데이터베이스 인스턴스를 구축하는 데 사용되며, 이 작업에는 20~30분이 걸립니다. 그런 다음 Step Functions로 오케스트레이션된 Lambda가 간단한 읽기 쿼리로 해당 인스턴스가 사용 가능한지 확인하고, 인스턴스는 삭제되지 않고 중지됩니다. 어제의 복사본은 제거되므로 최근 복제본 하나는 항상 사용할 수 있습니다.

• 삭제 보호는 Terraform 구성과 AWS 자체, 두 수준에서 이루어집니다. 그는 이를 명시적으로 비활성화하는 누구라도 여전히 제거할 수 있지만, 이는 마찰을 더한다고 언급합니다.

• S3 백업에 버전 관리를 적용하여, 삭제해도 이전 버전이 남으며 버킷을 비우려면 먼저 해당 내용을 삭제해야 합니다.

• Terraform 상태가 S3로 이전되면서 이를 시작하게 만든 조건이 제거되었습니다 — 단 한 대의 노트북에만 존재했고 그가 기기를 바꾸자 사라져 버린 상태 파일이었습니다.

• 이제 에이전트는 Terraform을 전혀 실행하지 않습니다. “모든 권한이 비활성화되었습니다. 자동 실행도, 파일 쓰기도 없습니다.”라고 그는 씁니다. 이제 워크플로는 계획을 생성하고, 직접 검토한 뒤, 명령을 직접 실행하는 것입니다. 새 프로젝트에는 자체적인 별도 Terraform 구성도 생겼습니다.

모든 권고가 받아들여진 것은 아니었다. Rootly 인터뷰에서 그는 단일 AWS 계정을 유지했다고 말하며, 별도의 개발 및 프로덕션 계정과 Atlantis 같은 승인 파이프라인은 혼자 운영하는 사람에게 필요한 것 이상이라고 판단했다. 그것이 그 후과의 솔직한 모습이다. 수정은 실제이며, 한 사람이 혼자 유지할 수 있는 수정이다.

이 기록이 무엇인지, 그리고 무엇이 아닌지

이는 실제 금전적·가용성 피해가 발생한, 문서화된 자기 보고형 운영 사고이며, 사고를 겪은 당사자가 자신의 실수였던 부분까지 포함해 전체 경과를 기록해 두었기 때문에 유난히 명료하게 읽힌다. 이는 모델이 스스로의 목표를 추구했다는 증거가 아니며, 아카이브의 ROGUE 태그는 에이전트 측의 어떤 의도가 아니라 에이전트의 행동과 운영자의 의도 사이의 괴리를 설명하는 것으로 읽어야 한다.

기억해 둘 만한 세부 사항은 바로 데이터를 구한 그 세부 사항이다. Grigorev 자신의 백업은 그것이 보호하던 데이터베이스와 함께 삭제되었고, 그의 야간 스냅샷은 이벤트 로그가 그것이 존재한다고 거듭 말하는 동안에도 그에게 보이지 않았다. 2.5년치 교과 과정을 복원한 것은 그가 전혀 알지 못했고 테스트할 수도 없었던 AWS 측에 보관된 사본이었다. 복원해 본 적 없는 백업은 통제가 아니라 믿음이다 — 그리고 이 경우 그 믿음이 우연히 사실이었던 것은 오직 다른 누군가가 두 번째 백업을 보관하고 있었기 때문이다.