• 클로드 코드, 데이터베이스 및 스냅샷 포함 개발자 프로덕션 환경 삭제… 2.5년 기록 순식간에 전멸

    표면적으로는 어느 정도 행복한 결말을 맺지만, 사실은 경고의 교훈을 전해야 하는 이야기.

    article image

    에이전트 봇의 오작동 사례는 누구나 흥미롭게 접하는 주제이며, 사람들은 종종 가상의 동반자들에게 일종의 '샤덴프로이데'(Schadenfreude, 타인의 불행에서 느끼는 즐거움)를 느낍니다. 하지만 때로는 이러한 오류가 부적절한 감독에서 비롯되기도 합니다. 실제로 Alexey Grigorev는 Claude Code가 웹사이트의 수년간의 기록과 복구 스냅샷까지 삭제하게 된 전 과정을 상세히 전했습니다.

    이 이야기는 Grigorev가 자신의 웹사이트인 AI Shipping Labs를 AWS로 이전하고 DataTalks.Club과 동일한 인프라를 공유하려던 것에서 시작됩니다. Claude 자체는 이 옵션을 반대했지만, Grigorev는 두 개의 별도 환경을 유지하는 것이 번거롭거나 비용적인 면에서 이점이 적다고 판단했습니다.

    Gregory는 네트워크, 로드 밸런싱, 데이터베이스, 그리고 당연히 서버 자체까지 포함하는 전체 환경을 생성하거나 파괴할 수 있는 인프라 관리 유틸리티인 Terraform을 사용합니다. 그는 Claude에게 새로운 웹사이트 설정을 위한 Terraform 계획(plan)을 실행하도록 요청했지만, 현존하는 설정을 전체적으로 설명하는 필수 '상태 파일(state file)'을 업로드하는 것을 깜빡했습니다.

    (AWS 코딩 봇의 실수로 인한 중단 사태, 보고서에 따르면)

    Claude는 Gregory의 요청대로 Shipping Labs 사이트의 설정을 성공적으로 생성했으나, 운영자가 작업을 중간에 중지시켰습니다. 상태 파일이 누락된 상태였기에 시스템은 중복 리소스를 생성하게 되었습니다. Gregory는 상황을 해결하기 위해 Claude에게 중복 리소스를 식별하도록 요청한 후, 상태 파일을 업로드하여 상황이 정리되었다고 착각했습니다.

    (포토닉스 및 고속 데이터 이동이 다음 거대한 AI 병목 지점 / 데이터 센터 냉각 현황 / 대규모 AI 데이터 센터 구축이 에너지 공급을 압박)

    article image

    안타깝게도, Gregory는 이 시점에서 봇이 중복 리소스를 계속 정리해 주고, 그 다음에야 비로소 상태 파일을 참고하여 원래 어떻게 설정되어야 했는지를 확인해 줄 것이라 가정했습니다. Terraform이나 유사 도구들은 특히 '맹목적인 복종'과 결합될 경우 매우 가차 없을 수 있습니다. 이제 Claude가 상태 파일을 갖게 되자, 이는 논리적으로 파일의 내용에 따라 행동하며, 이번에 제대로 설정하기 위한 준비 과정으로 Terraform "destroy" 작업을 발행했습니다.

    인프라 설명에 DataTalks.Club 웹사이트가 포함되어 있었기 때문에, 그 결과 두 사이트의 전체 설정이 삭제되었습니다. 여기에는 2.5년간의 기록이 담긴 데이터베이스와 백업 목적으로 의존했던 데이터베이스 스냅샷까지 포함되었습니다. 운영자는 Amazon Business 지원팀에 연락해야 했고, 지원을 통해 데이터가 약 하루 만에 복구될 수 있었습니다.

    사후 검토(post-mortem)를 통해 Gregory는 향후 유사 사고를 방지하기 위해 몇 가지 조치를 취하고 있음을 설명했습니다. 여기에는 데이터베이스 복원 기간 테스트 설정, Terraform 및 AWS 권한에 '삭제 보호(delete protections)' 적용, 그리고 Terraform 상태 파일을 로컬 머신 대신 S3 스토리지로 이동시키는 것이 포함됩니다. 그는 또한 "AI 에이전트가 Terraform 명령을 실행하도록 과신했다"는 점을 인정하며, 이제 에이전트의 자동 실행을 막고, Claude가 제시하는 모든 계획을 수동으로 검토한 후 스스로 파괴적인 작업을 수행할 것이라고 밝혔습니다.

    이 사례를 단순히 또 다른 '멍청한 봇의 실수'로 치부하기 쉽지만, 대부분의 시스템 관리자들은 Grigorev의 접근 방식에 내재된 기본 문제점들, 즉 사실상 부하 직원에게까지 광범위한 권한을 부여한 점이나, 애초에 프로덕션 환경에서 권한을 충분히 범위 지정(scoping)하지 않은 점 등 근본적인 오류들을 간파할 것입니다.

    아마 가장 큰 교훈은, 마치 주니어 시스템 관리자가 그러하듯, Claude가 두 번째 웹사이트의 존재가 의미하는 바에 대한 '맥락(context)'을 이해할 것이라 가정하는 것의 위험성일 것입니다.

    [출처:] https://www.tomshardware.com/tech-industry/artificial-intelligence/claude-code-deletes-developers-production-setup-including-its-database-and-snapshots-2-5-years-of-records-were-nuked-in-an-instant